Nein, siehe Seite 4.
TSDoctor für VDR? - Filler Data Entfernen
- bbott
- Geschlossen
-
-
Da steht nix dazu...
-
Zitat
Originally posted by henfri
Sie NALUs zu entfernen scheint ja wirklich vernünftig.
Ist es geplant, das in den VDR direkt zu übernehmen?Nein. VDR schaut nur so weit in die Datein rein, wie es für die Erkennung der Framegrenzen absolut notwendig ist.
Klaus
-
Was spickt denn dagegen? Macht das Performancemässig neb großen Unterschied?
-
Zitat
Original von henfri
Was spickt denn dagegen?siehe oben --> TSDoctor für VDR? - Filler Data Entfernen
Gruß Fr@nk
-
Moin,
verstehe den Grundsatz von kls schon.
Würde mir wünschen das diese Nalustrippfunktion erst beim Schneiden einer Aufnahme mit angewandt wird.
Vielleicht im Rahmen eines Patches...
Munter bleiben, Rossi
-
Zitat
Original von kls
Wie man sieht wird ja das Thema "filler data" erkennen immer komplexer, je länger man sich damit beschäftigt. Das würde vermutlich eine Quelle ewiger Nachbesserungen und Fehlersuche.Das kann ich nicht beurteilen. Wenn das so ist, dann sollte man es vielleicht lassen.
Aber...
Zitat
Ich finde es einen völlig falschen Ansatz der Sender, solche Füllbytes in den eigentlichen Datenstrom einzubauen. Sowas sollte auf TS-Ebene gemacht werden, so daß man es durch einfaches Verwerfen der entsprechenden Pakete erledigen kann.Da wird sicher jeder zustimmen
ZitatVDR jedenfalls soll sich nicht näher mit dem Inhalt der Pakete befassen als unbedingt nötig. Evtl. sollte man sich bei den Sendern beschweren, die diesen Unsinn verzapfen...
Das wäre der richtige Weg. Der pragmatische ist es, die Nullen wegzulassen.
Ich fürchte, dass der richtige Weg lediglich dazu führen wird, dass die Nullen auf der Platte landen.
Deshalb würde ich eigentlich für den pragmatischen Weg sein.Die Daten erst beim Schneiden wegzulassen find ich doof.
Dadurch würde der Hardlinkcutter nicht mehr effizient sein und zudem schneiden viele nie.Gruß,
Hendrik -
Sorry, übersehen.
Zu "Seite 4": Das ist bei mir wahrscheinlich eine andere, da ich die Thread Ansicht nutze.
Gruß,
Hendrik -
Zur dauerhaften Integration hat sich KLS ja schon geäußert, und seine Argumente sind durchaus nachvollziehbar. Die Komplexität erinnert schon wieder unangenehm an an alte Remux-Zeiten. Außerdem halte ich das nalu fill Problem für ein vorübergehendes, langfristig wird sicher kein Sender die HD-Bandbreite so massiv verschwenden wollen.
Zur weiteren Existenz als Patch sehe ich höchstens noch die Alternative einer Plugin-Schnittstelle, die generell zwischen Empfänger-Device und Recorder sitzt, und Plugins den Eingriff in den Datenstrom erlaubt. Wie sowas im Detail aussehen könnte, hab ich aber auch noch keine Vorstellung.
Zurück zum Stripper:
Ich bastele gerade an einer eigenen Neu-Implementierung, und mir sind dabei im bisherigen Stripper zumindest zwei Schwachstellen aufgefallen:Erstes Problem ist, dass TS-Pakete ohne Payload frühzeitig unmodifiziert durchgelassen werden (cTSPaddingStrippers::ProcessTSPacket mit 's'). Das Problem: Dadurch findet keine Korrektur des Continuity-Counter statt, die erst eine Ebene tiefer statt findet (cTSPaddingStripper::ProcessTSPacket ohne 's').
Zweites Problem: Pakete ohne nützliche Payload werden ja verworfen. Dabei wird aber auch ein eventuell vorhandenes Adaption Field mit verworfen. Das könnte u.U. Nebenwirkungen haben. Tatsächlich habe ich Aufnahmen beobachtet, bei denen das letzte Nalu-Fill Paket vor dem neuen I-Frame ein Adaption Field hatte.
Von meiner Implementierung wird es demnächst eine Testversion geben, ganz zufrieden bin ich aber selbst noch nicht damit.
Gruß,
Udo
-
Zitat
Original von henfri
Der pragmatische ist es, die Nullen wegzulassen.Wie man allein dem vorigen Post, oder diesem: Link oder dem ganzen Thread entnehmen kann, ist die Sache offenbar deutlich komplizierter, als einfach einige Nullen wegzulassen.
Ich freue mich daher, dass kluge Köpfe hier weiterbasteln und es bald wieder was zum Testen geben kann - da gibt es wenigstens eine kleine Chance für mich, sich nützlich zu machen -
Zitat
Original von Urig
Von meiner Implementierung wird es demnächst eine Testversion geben, ganz zufrieden bin ich aber selbst noch nicht damit.Hört sich gut an.
Stellst Du es (auch) wieder als separates Programm zur Verfügung? Das wäre im Moment meine bevorzugte Variante. Kann man dann bei Filmen, die man aufheben will mit ein bisschen batch schön aus dem Record-Menü aufrufen und es gibt keine potentiellen Problemstellen im VDR-Core.
Grüße, Peter
-
-
Zitat
Original von iNOB
Das geht mit der 0.5 jetzt schon standalone.Ich weiss, ich mach's ja zur Zeit auch so. Deswegen hatte ich ja "auch _wieder_" geschrieben.
Bezüglich des Implementierungsansatzes gibts hier ja unterschiedliche Wünsche, deswegen meine Stimme für (auch) ein externes Programm.
Grüße, Peter
-
Zitat
Erstes Problem ist, dass TS-Pakete ohne Payload frühzeitig unmodifiziert durchgelassen werden (cTSPaddingStrippers::ProcessTSPacket mit 's'). Das Problem: Dadurch findet keine Korrektur des Continuity-Counter statt, die erst eine Ebene tiefer statt findet (cTSPaddingStripper::ProcessTSPacket ohne 's').
Das entspricht der Spezifikation, wenn kein payload da ist wird auch nicht weitergezählt, ist also absicht. Oder meinst du dass die veränderung des Conty Counter durch andere Packete nicht berücksichtigt wird? Das könnte wirklich ein Problem sein.ZitatZweites Problem: Pakete ohne nützliche Payload werden ja verworfen. Dabei wird aber auch ein eventuell vorhandenes Adaption Field mit verworfen. Das könnte u.U. Nebenwirkungen haben. Tatsächlich habe ich Aufnahmen beobachtet, bei denen das letzte Nalu-Fill Paket vor dem neuen I-Frame ein Adaption Field hatte.
Zitat aus ProcessPacket:
Zitatif (!(input[3] &0x10)) return input; //without payload it must be important adaption field information
Dies sorgt dafür, dass Pakete nur mit Adaptionfield nicht gefiltert werden. Die werden also nicht verworfen.Marten
-
Zitat
Original von Urig
Zur weiteren Existenz als Patch sehe ich höchstens noch die Alternative einer Plugin-Schnittstelle, die generell zwischen Empfänger-Device und Recorder sitzt, und Plugins den Eingriff in den Datenstrom erlaubt. Wie sowas im Detail aussehen könnte, hab ich aber auch noch keine Vorstellung.
Das ist auch meine Vorstellung der idealen Lösung, da so Beiträge der Community sauber getrennt vom VDR-Kern, den KLS pflegt, bleiben. -
Zitat
Originally posted by berndb
Wie man allein dem vorigen Post, oder diesem: Link oder dem ganzen Thread entnehmen kann, ist die Sache offenbar deutlich komplizierter, als einfach einige Nullen wegzulassen.
Irritierenderweise sind es 255en, und nicht Nullen, die weggelassen werden...ZitatOriginally posted by MartenR
Das entspricht der Spezifikation, wenn kein payload da ist wird auch nicht weitergezählt, ist also absicht.
Tatsache, hab ich glatt übersehen. Danke für den Hinweis.ZitatZitat aus ProcessPacket:
Dies sorgt dafür, dass Pakete nur mit Adaptionfield nicht gefiltert werden. Die werden also nicht verworfen.
Das ist klar, bezieht sich aber nur auf Pakete ohne Payload. Was in meinen Tests bisher aber auch nicht vorzukommen scheint.Was ich meine sind Pakete, die Payload UND Adaption Field haben, bei denen der Stripper aber entscheidet, den Payload-Teil wegzuwerfen. In dem Fall fliegt das Adaption Field ungefragt mit weg.
ZitatOriginally posted by lostinspc
Stellst Du es (auch) wieder als separates Programm zur Verfügung?Erst mal ist es ein standalone-Programm, weil's die Entwicklung erleichtert. Danach kommt die Integration bei der Aufnahme, und eventuell als VDR-Kommandozeilenversion ähnlich --edit.
Gruß,
Udo
-
Wie Urig schon schrieb, glaube ich auch nicht an ein längerfristiges Problem mit den Nalus. Es sind IMHO momentan in Europa auch nur ARD/ZDF die ihren Stream auffüllen um eine konstante Bitrate zu bekommen.
Ich gehe davon aus, dass sie 2011 auch auf variable Bitrate wechseln.
Eventuell lohnt sich dann nicht unbedingt der Aufwand. Aus technischer Sicht fände ich eine Open Source Implementation natürlich interessant.
Grüße
Oliver -
und ORF HD
-
Zitat
Original von linowsat
Wie Urig schon schrieb, glaube ich auch nicht an ein längerfristiges Problem mit den Nalus. ...Ich gehe davon aus, dass sie 2011 auch auf variable Bitrate wechseln.
Habe ich da was falsch verstanden? Alle senden doch auch HDTV in variabler Bitrate. Es ist doch der Transponder, der am Ende einen Datenstrom konstanter Größe braucht. Daher werden doch auch für die nicht benötigte Kapazität die Nalu Filler eingesetzt.
Es könnten dann am Ende nur mehr Sender auf einen Transponder geschaltet werden, die dann derart um die Bitrate streiten, dass keine Nalu Filler mehr zum Einsatz kommen. Dann würde aber jeder Sender im Grunde weniger Bitrate bekommen als im Moment ARDHD, arteHD & Co, ergo Bildqualität schlechter? Das passiert hoffentlich nicht ....
-
Zitat
Habe ich da was falsch verstanden? Alle senden doch auch HDTV in variabler Bitrate. Es ist doch der Transponder, der am Ende einen Datenstrom konstanter Größe braucht. Daher werden doch auch für die nicht benötigte Kapazität die Nalu Filler eingesetzt.
Ja, hast du. Es gibt zwei Möglichkeiten bei variabler Bitrate den Transponder aufzufüllen:
1. Es werden im TS Strom Pakete mit der pid 0x1ff eingefügt. Diese werden von vdr auch immer schon verworfen.
2. Im Videostrom eine Ebene höher werden Nalus eingesetzt um die Videobitrate innerhalb des TS konstant zu halten.Dies ist bei ARD und ZDF und arte wohl der Fall da die einzelnen Ströme aus verschiedenen Playoutcentern kommen (dort auch kodiert werden), unter dann irgendwo zusammengeführt werden. So dass für jeden einzelnen Videoelementarystream eine konstante Bitrate verwendet wird.
Wenn z.B. auch dritte Programme in HD kommen würden, würde die ARD wohl einen eigenen Transponder bekommen und könnte dann global dynamisch auf dem Transponder die Bitrate verteilen.Marten
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!