TSDoctor für VDR? - Filler Data Entfernen

  • 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...


    :lovevdr


    Munter bleiben, Rossi

  • Quote

    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...

    Quote


    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


    Quote

    VDR 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

  • 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

  • Quote

    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 :applaus 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 :doof :lachen2 :streichel

  • Quote

    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

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

  • Quote

    Stellst Du es (auch) wieder als separates Programm zur Verfügung?


    Das geht mit der 0.5 jetzt schon standalone.


    Gruß
    iNOB

  • Quote

    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

    KODI, tvh, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S

    Linux is the best OS I have ever seen -- Albert Einstein

  • Quote

    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.


    Quote

    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.


    Zitat aus ProcessPacket:

    Quote

    if (!(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

    vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

    Edited once, last by MartenR ().

  • Quote

    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.

  • Quote

    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... ;)



    Quote

    Originally 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.



    Quote

    Zitat 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.



    Quote

    Originally 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

  • Quote

    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 ....

  • Quote

    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

    vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!