[ANNOUNCE] naludump-0.1 - NALU fill data Patch

    Hallo Portal,


    Ich hab die endgültige Version 0.1 meines h.264 nalu fill data removal Tools + Patch veröffetlicht.


    Der Patch löscht NALU fill data aus h.264 Streams während der Aufnahme. Die Videostruktur wird dabei weitgehend beibehalten, nur TS-Pakete, die komplett aus NALU fill bestehen, werden entfernt. Auf HD-Kanälen mit fixer Videobandbreite kann das 40-60% der Dateigröße einsparen, ohne Bildinformationen zu verlieren.


    Der Patch wird unter Einstellungen -> Aufnahmen aktiviert, und kann für einzelne Aufnahmen mit dem Schlüsselwort NALUDUMP und NALUKEEP aktiviert bzw. deaktiviert werden.


    Vom Standalone-Tool gibt es auch eine überarbeitete Version, die die gleichen Buffer-Routinen wie der Patch verwendet, sonst aber identische Dateien erzeugen sollte.


    Für weitere Details siehe Vorgänger-Posts:
    TSDoctor für VDR? - Filler Data Entfernen
    [ANNOUNCE] naludump-0.0.1 - NALU fill data Löschtool


    Patch / Quelltext gibt's hier:


    http://www.udo-richter.de/vdr/naludump.html


    Gruß,


    Udo

    Yeah...vielen Dank!


    Gruß
    iNOB

    Zitat

    Original von Urig
    Der Patch wird unter Einstellungen -> Aufnahmen aktiviert, und kann für einzelne Aufnahmen mit dem Schlüsselwort NALUDUMP und NALUKEEP aktiviert bzw. deaktiviert werden.


    Hallo Udo,
    ich habe gestern einen Test mit Deinem "NALU fill data Patch" gemacht.
    Hat erst einmal einwandfrei geklappt mit einer Aufnahme von Arte-HD, wo ca. 30% Speicherplatz eingespart wurden. Suuper! :]


    Ich habe die Patch-Version gewählt und unter "Aufnahmen" den NALU dump aktiviert.
    Meine Frage ist, wie hast Du das gemeint, mit dem Schlüsselwort "NALUDUMP" bzw. "NALUKEEP"? Wo und wie muss ich die einstellen?


    Paulaner

    Zwei Anwendungen: Erstens, du bist besorgt, der Patch könnte die Aufnahme deiner Lieblingsserie ruinieren: Dann machst du zwei Aufnahmen, eine nach "Meine Serie~Aufnahme", die zweite nach "Meine Serie~Aufnahme NALUKEEP". Die erste ist gefiltert, die zweite ungefiltert.


    Zweitens, du bist ein Weichei, und hast den Patch sicherheitshalber deaktiviert. Dann kannst du zum Ausprobieren deine Serie einmal als "Meine Serie~Aufnahme NALUDUMP" und einmal als "Meine Serie~Aufnahme" aufnehmen. Wieder ist die erste gefiltert, die zweite - und alle normalen Aufnahmen - ungefiltert.


    Gruß,


    Udo

    Nachdem ich diesen Thread gestern zufällig entdeckt habe hab ich meinen VDR (von 1.7.13 auf 1.7.17) auf den neuesten Stand gebracht und deinen Patch gleich angewendet.
    Zum testen hab ich 10 Minuten von ORF 1 HD mit aktiviertem und ohne aktiviertem Patch aufgenommen (waren 2 Zeitgleiche Aufnahmen, also selber Inhalt). Der Unterschied waren 35MB. Hab mir die kleinere Datei mit VLC angesehen und konnte keine Fehler entdecken. Funktioniert also perfekt (und auch mit VDR 1.7.17)! Danke!

    Octopus Net S2 + DuoFlex S2
    VDR-2.3.8, Plugins: EPG-Search, VNSI-Server, satip

    ORF hat NALU-Füll Daten, aber etwas weniger.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

    Zitat von Copperhead

    OK, ich dachte immer, das nur die deutschen ÖRs NALU haben.


    Die Füll-Daten werden in unterschiedlichen Ausprägungen alle europäischen Sender haben, die nach der EBU Empfehlung in 720p senden. Aber selbst Aufnahmen von ServusTV HD (1920x1080i) enthalten Füll-Daten, sehr wenig, sind aber vorhanden ...


    Regards
    fnu

    HowTo: APT pinning

    Hallo Udo,


    die Möglichkeit die 720p Aufnahmen auf im Schnit 55% zu schrumpfen finde ich genial und nutze sie seit ca. einem Jahr durch durch das externe Programm. Seit vdr-1.7.22 nutze ich den patch (aus dem g2v-extpatch von Helau). Beides funktioniert innerhalb des VDR problemlos. Auch xbmc und vlc haben keine Probleme.


    Da ich aber dies Aufnahmen gerne auch auf einem Tegra2 Tablett nutzen möchte, wandele ich mit Handbrake:

    Code
    HandBrakeCLI -i $i  -o $DESTDIR/$(basename $i ts)m4v  -e x264 -q 20.0 -a 1 -E faac -B 128 -6 stereo -R Auto -D 3.0 -f mp4 --loose-anamorphic --modulus 16 -m -x ref=4:deblock=-2,-1:mixed-refs=0:analyse=some -w 1280 -X 1280 -Y 720 --crop autocrop --large-file >> /var/log/transcode.log 2>&1


    Jetzt wirds magisch: Aufnahmen, die ich ohne vdr-patch hinterher mit naludump schrumpfe funktionieren problemlos - Aufnahmen die mit dem Patch gleich beim Aufnehmen geschrumpft werden (und die im vdr, xbmc und vlc problemlos laufen) erzeugen in handbrake folgende Fehler:

    Das resultierende Video ist nicht mehr guckbar - da springen und ruckeln die Bilder und der Soundtrack scheint von einem Scratcher auf Crack zu stammen.


    Nach meinem nicht vorhandenen Verständinis nach, passiert im naludump das gleiche wie im patch, aber da irre ich wohl, da ich das zu 100% reproduzieren kann.


    Zu den Versionen


    Patch: g2v-ext von Helau
    naludump: 0.1 von Deiner Seite


    Gruß, Ingo

    Moin!


    Könnte es sein, dass du den nalustripper-Patch von MartenR benutzt und nicht den naludump-Patch von Udo?
    Vergleich doch mal bitte den Patch-Source.


    Lars.

    Hi,


    Lars: Du hast recht. Im ext-patch ist anderer nalu Code. Zu meiner Schande muss ich gestehen, dass ich den Patch von Udo mit dem externen Programm von Udo verglichen habe - aber keinen Blick in die Sourcen des gepatchten VDR geworfen habe...


    @udo: vergiss mein Posting, sorry.


    Gruß, Ingo

    Was bedeuten eigentlich diese Meldungen im syslog? Die hatte ich bei einem Test, bei dem auf einer S2-1600 eine Aufnahme lief, und die andere S2-1600 mittels ezap fortlaufend durch die Sender gezappt hat. Ich wollte wissen, ob das Zappen der einen die andere Karte negativ beeinflusst. Da ich diese Meldungen sonst nicht habe, nehme ich an, dass sie zeigen, dass der Stream tatsächlich gestört wurde, oder?

    Das sind zumindest Auffälligkeiten im TS-Strom. Continuity offset weist darauf hin, dass die TS-Pakete nicht aufsteigend durchnummeriert sind, was normalerweise als Hinweis gezählt wird, dass Pakete verloren gegangen sind, und Unexpected NALU fill data überprüft, ob die Fülldaten auch schön brav 0xFF Bytes sind, wie vorgeschrieben. Hier sind durch das Weglassen von TS-Paketen wohl Nutzdaten in den Fill-Block gerutscht, naludump bricht dann sofort das dumpen dieses Fill-Blocks ab.


    Gruß,


    Udo

    Gibt es für den vdr-1.7.32 schon einen angepassten Patch?


    Ich habe folgende "Rejects" bei der Datei remux.h bekommen:



    Habe das zwar irgendwie per Hand nun so reingefummelt, dass zumindest das ganze fehlerfrei kompiliert - aber als C(++) Analphabet weiß ich nicht, was ich da eigentlich tue ...

    berndb


    IMHO brauchts das gar nimmer, der Gewinn geht gegen null seit der großen Transponder Umstellung im März/April 2012, zumindest bei mir mit DVB-S2. Ich habe den Patch zwar noch drin aber abgeschaltet und siehe da, das ein oder andere kleine seltene Phänomen beim Setzen und Verschieben von Schnittmarken ist auch verschwunden ... ^^


    Regards
    fnu

    HowTo: APT pinning

    Zitat von fnu

    der Gewinn geht gegen null

    Je nach Sender spart man immer noch bis zu 26%!



    Und Probleme mit Schnittmarken gibt es bei mir nicht.

    Zitat von jrie

    Je nach Sender spart man immer noch bis zu 26%!


    Ja, es gibt leider immer noch Aussreisser nach oben, war vmtl. irgendeine Upscale Ausstrahlung, oder irgendwas mit schwarzen Rändern. Aber ich hatte auch geschrieben "geht gegen null" und nicht "ist null", lesen und verstehen ... ?(


    Deine Statistik zeigt ziemlich gut was ich meine, der Aufwand lohnt IMHO nicht mehr, früher waren die 0% die Aussreisser und bei den 1080i Sendern mit variabler Datenrate ging eh nie viel.


    Ist sicher auch eine Frage was damit macht, auf einem Server einlagern, aufnehmen/angucken/löschen oder als mkv einkochen, letztere beiden Varianten haben es im Prinzip sowieso nie benötigt.


    Zitat von jrie

    Und Probleme mit Schnittmarken gibt es bei mir nicht.


    Auch hier habe ich nix von Problemen geschrieben, sondern seltenes seltsames Verhalten beim Setzen und Verschieben von Schnittmarken, das seit dem Abschalten der Funktion nie wieder auftrat. Probleme sind was anderes ... 8)


    Regards
    fnu

    HowTo: APT pinning

    1% von 100 GB sind immerhin auch schon wieder 1GB.


    Und seltenes seltsames Verhalten ist auch ein wenig unspezifisch, um jedenfalls mir die Lust am Patch zu verderben. Ich würde es begrüßen, wenn man den Patch weiterpflegt: Wozu braucht man Füll-Daten ohne jeden Wert auf der Platte? Der eigentliche Zweck ist doch nach der Übertragung via Satellit, um da die Bitrate konstant zu halten, erfüllt?!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden