TSDoctor für VDR? - Filler Data Entfernen

  • hy Marten,


    hier mal was gdb ausspuckt, hoffe das hilft dir weiter:


  • vielen Dank Marten ... bis jetzt läufts alles wie es soll.


    hab mal spasseshalber ein vergleich von vdr ohne und vdr mit patch gemacht was die systemlast angeht:



    werd das mal weiter testen und ein paar aufnahmen machen, sag dann wieder bescheid.


    P.S.: achja jeweils ca. 1min aufgenommen,

    Code
    normal: 
    1min ~ 106mb 
    mit patch : 
    1min ~ 61mb
  • nabend,


    HD aufnahme über mehrere stunden ok, schneiden ok .... tonspuren ok ... keine Bildfehler soweit alles bestens.


    was nicht geht ist komischerweise pro7 und dmax, das bild bleibt schwarz, ton ist aber da.
    Hab mal per femon geguckt, dmax und pro7 haben beide die gleiche vpid 511. KA ob das irgend eine rolle spielt, viel mir nur gleich ins auge. alle anderen Sender(zumindest soweit ich getestet hab) sind iO.


    Mit Vdr ohne patch gehen die beiden sender .... also mit bild ..... müsste daher am patch liegen.


    @ marten


    wenn du noch irgend etwas an infos brauchst sag bescheid.

  • bexbier
    das mit der pid stimmt!
    Ich hatte für die padding pid 0x1ff=511 statt 0x1fff verwendet, daher dachte der patch das Programm von ProSieben sei nur Füllmaterial und hat es verworfen.
    Korrigierter Patch anbei.


    Das erklärt auch das Problem bei der Futurama Aufnahme...


    Marten

  • WOW ! ... das nenn ich mal support ....


    pro7 und dmax laufen nun wieder .... vielen Dank. Werd weiter testen .... soweit super Arbeit ! Hut ab.


    werd berichten wenn mir noch was auffällt.

  • Darf ich kurz einwerfen?
    Also wenn das dann zuverlässig funktioniert, spart man sich um die 50% Speicherplatz, ohne Qualitätsverlust?
    Das wäre natürlich gigantisch, freu mich schon wenn das ausgereift ist :)
    DANKE! :lovevdr


    Lieben Gruß,
    Sandy

    Derzeit: YaVDR 0.4
    Hardware: Asus M2NPV-VM, AMD Athlon 64 X2 4600+, 2x512 DDR2, Nvidia G210, 2x Satelco Easywatch Budget, CI, HDD Samsung SJ501, DVD Plextor PX800, Gehäuse/Display Silverstone LC16M

  • Zitat

    Original von HH_Maus
    Also wenn das dann zuverlässig funktioniert, spart man sich um die 50% Speicherplatz, ohne Qualitätsverlust?


    Naja, vielleicht nicht 50%, aber z.B. 30% - je nach Sender. Und ja, OHNE Qualitätsverlust, denn es werden nur die Füllbytes herausgefiltert, die eh nichts zu Bild oder Ton beitragen und nur dazu dienen, dass der Satellit mit einer konstanten Bitrate senden kann.


    Das gibt wieder so ein Patch, ohne den man den VDR nicht laufen lassen will :D

  • So ganz wasserdicht ist das alles noch nicht. Deswegen gleich nochmal die Warnung: NOCH NICHT AUF PRODUKTVSYSTEMEN EINSETZEN!


    Zunächst mal: Es kommt definitiv vor, dass der Startcode 00 00 01 0c durch eine TS Paketgrenze zerschnitten wird. Springt man danach 3 Bytes rückwärts, ist man so eventuell aus dem Paket raus...


    Dafür scheint das Ende eines fill block immer mit dem Ende eines TS-Pakets zusammen zu fallen, wobei danach eine payload start beginnt. Allerdings garantiert einem das natürlich keiner.


    Die nalu fill data hat leider auch ein vorgeschriebenes Format: Die Fülldaten sind 0xff Bytes, abgeschlossen durch ein einsames 0x80 Byte am Ende, bevor das neue 00 00 01 kommt.


    Die Testbedingung ((*pos) &0x1f)==0x0c kann noch verbessert werden, da der Standard vorschreibt, dass Bit 7 eine 0 ist, d.H. ((*pos) &0x9f)==0x0c. So kommt es auch nicht zu Verwechselungen, falls ein PES-Startcode mit 0x1c kommt. Tatsächlich scheint das Bit 7 zur Unterscheidung von PES-Paketen und NAL Paketen zu dienen.


    Das etwas rüde Umschreiben der PES-Pakete auf unbound packet length macht mir auch Bauchschmerzen. Schließlich werden so alle Videopakete behandelt, auch nicht-HD.


    Ich habe mal in die Tasten gegriffen, und einen alternatives ProcessPayload geschrieben, das etwas konservativer an die Sache ran geht:
    - Unbekannte PES-Pakete oder PES-Pakete mit packet length werden nicht angerührt
    - Das Format der nalu filler wird überprüft
    - nalu filler werden am Ende des ersten Pakets pauschal schon mal mit 0x80 terminiert
    - Endet der nalu filler nicht an einer Paketgrenze, wird gewarnt


    Ich stelle die Version hier mal zur Verfügung, als Ideengeber. Ganz glücklich bin ich damit auch noch nicht, insbesondere der Fall, dass die nalu filler unerwartet mitten in einem Paket enden, bedürfen noch einer Sonderbehandlung. Die dürfte aber nicht so einfach sein.


    Gruß,


    Udo

  • Zitat

    Zunächst mal: Es kommt definitiv vor, dass der Startcode 00 00 01 0c durch eine TS Paketgrenze zerschnitten wird. Springt man danach 3 Bytes rückwärts, ist man so eventuell aus dem Paket raus...


    Das macht keine Probleme da auf den Zeiger new_pos nicht mehr zugegriffen wird (seit zweiter Version), der zeigt nur an ob alles weggeschmissen wurde. Ist eigentlich mehr ein Zähler geworden...


    Zitat

    Dafür scheint das Ende eines fill block immer mit dem Ende eines TS-Pakets zusammen zu fallen, wobei danach eine payload start beginnt. Allerdings garantiert einem das natürlich keiner.


    Garantiert ist allerdings das neue Nalu Nutzdaten wieder mit dem 00 00 01 beginnen, daher reicht das als Signal durchaus aus.


    Zitat

    Die Testbedingung ((*pos) &0x1f)==0x0c kann noch verbessert werden, da der Standard vorschreibt, dass Bit 7 eine 0 ist, d.H. ((*pos) &0x9f)==0x0c. So kommt es auch nicht zu Verwechselungen, falls ein PES-Startcode mit 0x1c kommt. Tatsächlich scheint das Bit 7 zur Unterscheidung von PES-Paketen und NAL Paketen zu dienen.


    Das klingt sinnvoll, 0x1c wird zwar nicht verwendet für PES packete im Moment aber man weis ja nie.


    Zitat

    Das etwas rüde Umschreiben der PES-Pakete auf unbound packet length macht mir auch Bauchschmerzen. Schließlich werden so alle Videopakete behandelt, auch nicht-HD.


    Es werden nur Pakete umgeschrieben die für den Filter registiert werden, wenn in den Informationen wie PAT PMT nicht h264 angezeigt wird, wird nicht gefiltert. Ansonsten ist unbound paket length vollkommen Standardkonform für in TS Stream eingebetteten pes Paketen, siehe Seite 31 http://neuron2.net/library/mpeg2/iso13818-1.pdf .
    pes pakete starten immer wenn das payload start Flag gesetzt ist, jedenfalls macht der live tv code in vomp diese Annahme und wir hatten bislang keine berichte über Probleme, so dass die Paketlänge vom Decoder immer rekonstruiert werden können.

    Zitat

    nalu filler werden am Ende des ersten Pakets pauschal schon mal mit 0x80 terminiert


    Das ist in der Tat schwerig insbesondere der Fall wenn der Füller im Paket endet kann zu Problemen führen (und wir haben ja nur das eine Paket), andererseits auch wieder nicht da ja der Beginn der nächsten Nalu erst kommen muß....


    Marten

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

  • Ist vielleicht etwas off-topic in diesem Forum, aber da jsffm an dieser Stelle schon mal gefragt hatte: Habe mal versucht mit einer GNU-basierten IDE unter WinXP zu kompilieren. Lief ohne Probleme durch, nur scheint das Programm nicht das zu tun, was ich erwarten würde: Die Arte HD ts-streams von meiner Dreambox sind jedenfalls genauso groß geblieben, wie sie vorher waren. Vielleicht läuft mit der FILE-IO doch etwas anders unter Windows als unter Linux, oder die dreambox ts unterscheiden sich irgendwie von den in der Linux VDR gespeicherten. Bin hier aber letztlich zu unbedarft um die Nuss zu knacken.


    Viele Grüße,
    fgniki

  • Das Program geht nur mit vdr ts, es macht bei der PAT PMT ein paar Annahmen, die nur beim vdr zutreffen.


    Marten

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

  • :mahlzeit


    hab das ganze jetzt mit etlichen Aufnahmen auf allen FTA HD Sender getestet. Konnte nichts negatives feststellen, alle Aufnahmen sind ok, ohne Bildfehler oder ähnliches und lassen sich wie gewohnt schneiden.


    Hab den Patch (0.3) nun auf dem Wohnzimmer VDR eingebaut. Falls wieder erwarten doch noch was sein sollte meld ich mich wieder.


    @ Marten, wenn ich Urigs und deinen post richtig verstanden hab sollte in der Zeile :

    Code
    ((*pos) &0x1f)==0x0c


    die "1" gegen eine "9" getauscht werden um auf nummer sicher zugehen falls doch mal ein Paket mit 0x1c anfängt. richtig ?


    Auf jedenfall ein riesen Dank an dich für den genialen Patch !

  • Zitat

    die "1" gegen eine "9" getauscht werden um auf nummer sicher zugehen falls doch mal ein Paket mit 0x1c anfängt. richtig ?


    Ja genau, wo bei laut spec alle Video pakete eigentlich nur pes packete von 0xe0-0xef enthalten sollten..


    Marten

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

  • Zitat

    Originally posted by MartenR


    Garantiert ist allerdings das neue Nalu Nutzdaten wieder mit dem 00 00 01 beginnen, daher reicht das als Signal durchaus aus.


    Im einfachen Fall gehe ich davon aus, dass ein NALU fill block mit einem 0x80 im letzten Byte des TS endet, und das nächste TS mit 00 00 01 beginnt. Beim Kürzen lässt man dann halt schon im ersten NALU Paket das TS mit 80 enden.


    Theoretisch kann aber ein TS-Paket mit 00 oder 00 00 enden, und man weiß nicht, ob diese zwei Bytes nun das Ende der Filler sind, oder nur Datenmüll. Beginnt dann das nächte Paket mit 01, hätte man das vorherige TS nicht verwerfen dürfen, da man dessen 00 00 benötigt.


    Wenn ich dazu komme (sieht schlecht aus dieses Wochenende), versuch ich folgendes:
    - Das erste fill paket wird am Ende des TS mit 80 terminiert.
    - Gedroppt werden nur TS, die ganz aus ff bestehen, oder höchstens ein 80 im letzten Byte haben
    - Startet das nächste 00 00 01 nicht ab dem ersten Byte wird der ungenutzte Bereich nochmal mit 00 00 01 1c ((n-5)*ff) 80 aufgefüllt.
    - Ist die zu füllende Lücke kleiner als 5 Byte, wird nur mit n*00 aufgefüllt.



    Zitat

    Das klingt sinnvoll, 0x1c wird zwar nicht verwendet für PES packete im Moment aber man weis ja nie.


    So wie ich den Standard lese, sind für PES-Pakete nur die Startcodes 0x80 - 0xff vorgesehen. Und 0x9c könnte ja vorkommen.


    Gruß,


    Udo

  • Zitat

    Theoretisch kann aber ein TS-Paket mit 00 oder 00 00 enden, und man weiß nicht, ob diese zwei Bytes nun das Ende der Filler sind, oder nur Datenmüll. Beginnt dann das nächte Paket mit 01, hätte man das vorherige TS nicht verwerfen dürfen, da man dessen 00 00 benötigt.


    Nein kann es nicht, da in den Nalunutzdaten sogenannte Emulationpreventionbytes eingefügt werden, wenn etwas derartiges auftritt, so dass sichergestellt ist, dass die 00 00 01 immer nalu oder pes packete starten lassen. Im Falle eines Empfangsfehler werden die TS Pakete ja verworfen, was man am continuity counter merken könnte.

    Zitat

    So wie ich den Standard lese, sind für PES-Pakete nur die Startcodes 0x80 - 0xff vorgesehen. Und 0x9c könnte ja vorkommen.


    Ja sind es im Prinzip, da wir aber nur Video pids filtern, mit entsprechenden Informationen aus PAT PMT, sind eigentlich nur Pakete mit 0xe0- 0xef vorgesehen...


    Zitat

    Startet das nächste 00 00 01 nicht ab dem ersten Byte wird der ungenutzte Bereich nochmal mit 00 00 01 1c ((n-5)*ff) 80 aufgefüllt.


    Das geht nicht, wenn wir im Device filtern, da bekommen wir nämlich nur ein Paket zu sehen, dass wir bearbeiten können. Und da die Reihenfolge der Pakete im Verhältnis zur PAT PMT eine Rolle spielt, können wir auch kein Paket speichern und später ausgeben.


    Und im Device filtern hat den Vorteil, dass es passiert bevor das Paket aufversicheidene Receiver verteilt wird.



    Marten

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

  • Nur ein kurzer Kommentar von mir, weil mich "bbott" per Email auf diesen Thread aufmerksam gemacht hat.


    Wie "FireFly" schon richtig bemerkt hat, halte ich wenig davon, den hereinkommenden TS-Datenstrom in irgend einer Weise zu verändern. Pakete wegzulassen, die auf TS-Ebene als unnötig erkannt werden, ist völlig ok. Aber tiefer in den Inhalt der Pakete einzudringen möchte ich soweit es geht vermeiden. Es ist schon schlimm genug, daß cFrameDetector zum Erkennen der Framegrenzen sich die Daten genauer anschauen muß (meiner Meinug nach hätte man diese Information viel sinnvoller auf TS-Ebene im DVB-Standard unterbringen sollen). 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.


    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.


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


    Klaus

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


    Ich stimme komplett zu, dass es totaler Unsinn ist den eigenlichen stream mit Fülldaten aufzufüllen, TS Pakete mit 0x1ff sind die sinnvollere Methode. Ich war ja auch ziemlich überrascht das jemand das macht.
    Mich nervt vorallem, dass so auch beim streaming z.B. mit vomp oder streamdev, die Bandbreite z.B. im WLAN vollmüllt....


    Das mit dem Beschweren ist sicherlich ein sinnvoller Weg, die Frage ist es nur wie man es schafft, dass die Beschwerde auch die Technikabteilung der ÖR Sender erreicht....


    Urig: Habe noch eine Idee, man könnte auch Anfang und Ende testen und nur wegwerfen wenn alle Bytes 0xff. Das hat zwar zur Folge, dass ein Paket mehr erhalten bleibt, das sollte aber kaum ins Gewicht fallen, dafür gibt es keine Probleme mit dem Endcode.


    Marten

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

  • Die Technikabteilung der ÖR ist sich des Problems wohl auch bewusst. Normalerweise werden mehrere Programme wohl gemeinsam zu einem Strom codiert und der Encoder hat dann die Möglichkeit, die vorhandene Bandbreite unter den Kanälen dynamisch aufzuteilen.


    Das "Problem" hier ist wohl nur, dass die Daten an drei Standorten getrennt voneinander encodiert und erst dann später beim Play-Out-Center zu einem Strom zusammengefügt werden. Zum Erreichen der Gesamtbandbreite werden die drei Streams deshalb schon beim Encodieren mit Nulldaten aufgefüllt. Meine Rückfrage, warum sie das nicht ändern wollen / können, so dass die Nullbits erst auf TS-Ebene eingefügt werden, wurde aber leider noch nicht beantwortet.


    Wer sich selbst auch "beschweren" will, Kontaktadresse findet Ihr hier.


    Bitte höflich bleiben, dort sitzen auch vdr-Nutzer und -Fans, die teilweise auch schon zu vdr beigetragen haben. Wenn Ihr vernünftige Beschwerden schreibt, können die das ggf. als Argumentationsmaterial verwenden, um die Technik zu ändern.

Jetzt mitmachen!

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