Sehr wichtiger Hinweis. Vielen, vielen, vielen Dank! 
Ich denke, darüber wird sich Dirk freuen.
ODER, ist es bedeutungslos? 
Albert
Sehr wichtiger Hinweis. Vielen, vielen, vielen Dank!
ODER, ist es bedeutungslos?
Albert
Du schreibst wieder mal in Rätseln?!
Danke für den Hinweis. Nutze zwar kein naludump und hab keine Aufnahmen geplant, aber werd es mal checken, wenn ich etwas aufnehme.
Was sagt Klaus eigentlich zu dem naludump Patch? Kann der nicht in den vdr?
Was sagt Klaus eigentlich zu dem naludump Patch? Kann der nicht in den vdr?
Klaus hat dazu mal ne klare Ansage gemacht, dass er das nicht einbaut.
hat er dazu eine Begründung geliefert?
Er will keinen Eingriff in den Datenstrom
der Link zum Patch bzw Tool:
http://www.udo-richter.de/vdr/naludump.html
Supi, da sind ja inzwischen offizielle Releases für die aktuellen vdr-versionen 2.0.4 / 2.1.2. Habe mir meinen letzten irgendwo hier aus dem Bord geklaut.
Auch wenn "nur" 3-5% gespart werden lohnt sich das doch schon. Ein aktiviertes Naludump während der Aufnahme hat noch nicht mal meinen Pentium-II-Rechner lahmgelegt. Also auch wenn es nicht in den vdr kommt - da patche ich doch gern.
was ist denn NALU???
ein satelitentransponder sendet immer mit voller datenrate / wenn dort die datenrate der sender nicht ausreicht um das ding auszulasten werden nullen hinzugefügt
(so habe ICH es zumindest verstanden)
was ist denn NALU???
ein satelitentransponder sendet immer mit voller datenrate / wenn dort die datenrate der sender nicht ausreicht um das ding auszulasten werden nullen hinzugefügt
Naja, ganz so einfach ist es nicht. Der ganze Name nalu(dump) ist schon etwas missverstaendlich. Auch werden verschiedene Sachen vermischt. Ich versuche mal eine Erklaerung...
Grundsaetzlich: Das Tool oder der Patch naludump dient zum Entfernen/Kuerzen von Filler-NAL-Units aus H.264-Datenstroemen.
Aber mal von vorne:
Jeder H.264-kodierte Datenstrom (hauptsaechlich bekannt als HD-Video) besteht aus einer Aneinanderreihung von Network-Abstraction-Layer-Units (NALU), das sind einfach mal Datenpakete. Davon gibt es verschiedene Sorten, unter anderem auch Fülldaten. Die sind eigentlich ueberfluessig, die packt man aber z.B. in den Datenstrom rein, um eine konstante Bitrate zu erreichen. Es kann ja z.B. sein, dass ein Sender gerade ein Standbild sendet, das sich auch mit bester Kodierqualitaet gar nicht mit so hoher Datenrate kodieren laesst, wie man erreichen moechte. Dann kann man diese Fuelldaten dazupacken.
Eine andere Sache ist die Uebertragung der Daten ueber DVB (z.B. Satellit). Hier werden mehrere Programme, die ja wieder aus Video- und Audiostroemen und anderen Sachen bestehen, gemeinsam ueber einen Transponder uebertragen. Dieser gesamte Transportstrom (TS) muss dabei eine konstante Datenrate haben. Aber die wird nach dem Zusammenstellen der verschiedenen Programme (Multiplexen) durch Auffuellen mit Fuell-TS-Paketen erreicht.
Die H.264-Fill-NALUs dienen also keinem echten Zweck, und sind m.E. zumindest mal eine schlechte Angewohnheit der Programmanbieter. Die einzige Erklaerung, die mir fuer diesen Unsinn einfaellt, ist, dass mit einer hohen Video-Datenrate eine besonders gute Qualitaet vorgegaukelt werden soll, obwohl sich die eigentlichen Nutz-NALUs (und damit die Bildqualitaet) durch Hinzufuegen der Filler-NALUs natuerlich ueberhaupt nicht aendern. Aber vielleicht hat ja irgendjemand eine bessere Erklaerung...
Gruss,
S:oren
ah danke
als die ÖR damals beim Frequenzwechsel von CBR (Constant Bitrate) auf VBR (Varaible Bitrate) mit statistischen Multiplexing gewechselt hatten, waren die Nalus vergleichsweise auch recht gering ( lagen zwischen 1 - 5 % bei meinen Analysen) Der statistische Multiplexer kann alle zu zu encodierenden Programmstreams vorweg in Echtzeit analysieren und so beim anschließenden Encodieren direkt Einfluss nehmen, sodass keine Nalus gebraucht werden. Meiner Meinung nach funktioniert der statistische Multiplexer nicht mehr so optimal wie anfangs.
waren die Nalus vergleichsweise auch recht gering ( lagen zwischen 1 - 5 % bei meinen Analysen)
Jetzt nicht als persoenliche Antwort, eher nochmal generell zur Klarstellung: Der ganze H.264-Strom besteht zu 100% aus NALUs. Daran ist auch ueberhaupt nichts verkehrt. Hier geht es speziell nur um den einen Typ der Filler-NAL-Units. Die sollten auch bitte so genannt werden, sonst kommt die ganze Verwirrung hier zustande...
Der statistische Multiplexer kann alle zu zu encodierenden Programmstreams vorweg in Echtzeit analysieren und so beim anschließenden Encodieren direkt Einfluss nehmen, sodass keine Nalus gebraucht werden.
Nee, Filler-NAL-Units werden nie gebraucht. Gerade beim statistischen Multiplex waere es sinnvoll, die Einzelstroeme moeglichst schlank zu halten, um vorhandene Bitratenreserven an andere Programme zu verteilen. In jedem Falle gehoeren aber Fill-Daten auf TS-Ebene (PID 0x1fff), die haben in den Elementarstroemen nichts zu suchen. Wenn irgendwer bei der Produktion vor dem Verpacken in TS die konstante Datenrate braucht, dann soll er den Mist beim Verpacken gefaelligst wieder rausloeschen. Aber wie gesagt, ich halte das eher fuer Marketing und nicht technisch begruendet.
Meiner Meinung nach funktioniert der statistische Multiplexer nicht mehr so optimal wie anfangs.
Meiner Meinung nach ist die Kodiereffizienz mittlerweile so gut, dass man brauchbare Bildqualitaet erreichen kann, ohne auf die Statistik zwischen den Programmen zu hoffen. Das vermeidet rechtliche Probleme, wenn die Statistik mal nicht funktioniert. Mit anderen Worten, keiner gibt sich Muehe mit gutem statistischen Multiplex, weil es niemand dankt und man sich umgekehrt nur Aerger einhandelt, wenn es doch selten mal zu Buffer-Ueberlaeufen kommt.
Gruss,
S:oren
ZitatDie sollten auch bitte so genannt werden, sonst kommt die ganze Verwirrung hier zustande...
bis jetzt war auch keiner hier verwirrt. Ich denke mal, alle hatten sich auch an Nalus gewöhnt.
Ansonsten für Pedanten kann auch Null Bytes oder Fülldaten gebraucht werden, wenn nalus stören.
ZitatZitat von »Argus«
Der statistische Multiplexer kann alle zu zu encodierenden Programmstreams vorweg in Echtzeit analysieren und so beim anschließenden Encodieren direkt Einfluss nehmen, sodass keine Nalus gebraucht werden.
Nee, Filler-NAL-Units werden nie gebraucht.
nichts anderes hatte ich behauptet.
Hallo,
aus o.g. Anlass habe ich das Tool mal wieder ausprobiert. Leider bekomme ich einen Segfault:
Input file: 00001.ts
Output file: 0000neu.ts
Packets: 242622 Dropped: 107428 (44%)cNaluDumper: Unexpected NALU fill data: 47
ERROR: skipped 187 bytes to sync on start of TS packet
ERROR: skipped 187 bytes to sync on start of TS packet
ERROR: skipped 187 bytes to sync on start of TS packet
...
ERROR: skipped 580 bytes to sync on start of TS packet
Speicherzugriffsfehler (Speicherabzug geschrieben)gdb sagt nicht viel:
Core was generated by `naludump 00001.ts 0000neu.ts'.
Program terminated with signal 11, Segmentation fault.
#0 0xb7592891 in memcpy () from /lib/i686/cmov/libc.so.6Ein ähnliches Programm was hier noch auf der Platte lag - nalustripper - funktioniert jedoch mit der Aufnahme.
Marcus
Danke für die Erklärung, aber warum sollte man die "Fülldaten" entfernen aus den Aufnahmen?
Als einzig logische Erklärung würde ich sagen ich spare Platz auf der Platte? Da ich nach dem anschauen (kann schon mal Jahre dauern) wieder lösche, sollte das doch eigentlich nicht nötig sein, oder?
Als einzig logische Erklärung würde ich sagen ich spare Platz auf der Platte?
Genau. Einen anderen Zweck hat das Tool / der Patch nicht.
Gruss,
S:oren
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!