Neue Schnittfunktion in VDR 1.7.32

    Nachdem ich nun einige Zeit damit verbracht habe, zu versuchen, die PCR richtig hinzubekommen, und egal was ich angestellt habe, das Ergebnis beim Abspielen immer das Gleiche war, habe ich die Werte mal durch zufällige Werte ersetzt bzw. konstant auf 0 gesetzt - und siehe da: es macht überhaupt keinen Unterschied! Die PCR wird von den Playern anscheinend vollkommen ignoriert.


    Da aber die PTS- und DTS-Werte inzwischen wohl stimmen, habe ich momentan keine weitere Idee, woran es liegen könnte, daß es an den Schnittstellen einer 720p HD-Aufzeichnung bei der TT S2-6400 noch immer Artefakte gibt, und der Mac-Player total außer Tritt kommt, während Kaffeine sie problemlos abspielt, ohne jede Störung.


    Ich werde daher dieses Thema erstmal wieder zurückstellen, bis jemand eventuell eine neue Idee hat...


    Abei die jüngsten Änderungen (nach vdr-1.7.32-cutterfix-1.diff anzuwenden), die aber wohl keinen Einfluß auf die Problematik haben dürften (insbesondere die Änderung bei NewPcr, da der PCR-Wert ja offensichtlich egal ist).


    Klaus

    Moin!


    Ich werde die nächsten Tage mal versuchen, die passende Stelle im Quelltext von Cuttermaran zu finden. Vielleicht ergeben sich daraus ja noch einige Erkenntnisse...
    Wäre aber nur für MPEG2 gültig, aber vielleicht reicht das dann ja schon.


    Ich kann mich noch erinnern, dass vlc Streams von pvrinput erst dann richtig wiedergegeben hat, nachdem ich die PCR-Pakete eingebaut hab. So ganz unwichtig wird das schon nicht sein. :)
    Aber mein Wissen ist da auch begrenzt.


    Lars.

    Zitat von kls

    Da aber die PTS- und DTS-Werte inzwischen wohl stimmen, habe ich momentan keine weitere Idee, woran es liegen könnte, daß es an den Schnittstellen einer 720p HD-Aufzeichnung bei der TT S2-6400 noch immer Artefakte gibt, und der Mac-Player total außer Tritt kommt, während Kaffeine sie problemlos abspielt, ohne jede Störung.

    Wenns nur bei H.264 auftritt, tippe ich ja auf die IDR-Frames. Durch Verschieben der Schnittmarke (vermutlich eben auf einen IDR-Frame) habe ich bei einem Test die Artefakte weg bekommen. Koenntest Du das nochmal testen, auch wenns dann nicht in die Schnittfunktion reinkommt? Vielleicht ist es bei H.264 (nicht bei MPEG-2!) auch besser, keine Frames wegzulassen, weil dann die internen PictureOrderCounts nicht mehr stimmen. Ist aber nur eine Idee...


    Gruss,
    S:oren

    Zitat von S:oren

    Wenns nur bei H.264 auftritt, tippe ich ja auf die IDR-Frames. Durch Verschieben der Schnittmarke (vermutlich eben auf einen IDR-Frame) habe ich bei einem Test die Artefakte weg bekommen. Koenntest Du das nochmal testen, auch wenns dann nicht in die Schnittfunktion reinkommt? Vielleicht ist es bei H.264 (nicht bei MPEG-2!) auch besser, keine Frames wegzulassen, weil dann die internen PictureOrderCounts nicht mehr stimmen. Ist aber nur eine Idee...


    Ich hatte mal testweise die Split-Funktion aktiviert, so daß jede Sequenz in eine eigene Datei geschrieben wurde. Die einzelnen Dateien hat der Mac-Player von vorne bis hinten problemlos abgespielt. Sobald ich aber zwei solche Dateien mit 'cat' aneinandergehängt und abgespielt habe, kam der Mac kurz vor der Schnittstelle total außer Tritt. Ich schätze mal, das spricht eher gegen die IDR-Frame-Theorie.


    Klaus

    Zitat von kls

    Ich hatte mal testweise die Split-Funktion aktiviert, so daß jede Sequenz in eine eigene Datei geschrieben wurde. Die einzelnen Dateien hat der Mac-Player von vorne bis hinten problemlos abgespielt. Sobald ich aber zwei solche Dateien mit 'cat' aneinandergehängt und abgespielt habe, kam der Mac kurz vor der Schnittstelle total außer Tritt. Ich schätze mal, das spricht eher gegen die IDR-Frame-Theorie.

    Vielleicht gibts da verschiedene Mac-Player, wir hatten jedenfalls die Erfahrung gemacht, dass der Mac immer erst an einem IDR-Frame mit der Wiedergabe beginnt und alles vorher ignoriert. Das kann er natuerlich nur am Anfang nach dem Start einer Sequenz, nicht bei einem Schnitt. Jede Sequenz einzeln ist nach dem ersten IDR-Frame ja komplett standardkonform, zwei aneinandergehaengte Sequenzen dann auf jeden Fall nicht, wenn die zweite nicht mit einem IDR-Frame beginnt. Fehlertoleranz ist auch nicht die Staerke des Mac (man soll ja iTunes verwenden).


    Gruss,
    S:oren

    Moin!


    Der Source von Cuttermaran ist leider nicht so ergiebig, die interessanten Stellen gibt's nur als Dll... :(


    Ich hab mir einfach mal alle Video-PTS- und -DTS-Werte ausgegeben, die Originalen vor dem Schnitt und die gefixten nach dem Schnitt.
    Dann habe ich die geschnittene Aufnahme mal durch ProjectX gejagt.


    Die erste GOP nach dem Schnitt gefällt ihm nicht, weshalb sie verworfen wird (ist in der demuxten Ausgabe nicht enthalten).


    Hier die Werte um den Schnitt herum:


    Dann habe ich den Cut-out einen Schritt nach hinten und den Cut-in einen Schritt nach vorne verschoben und noch mal geschnitten, damit ich sehe, wie die Originalwerte der weggeschnittenen GOPs aussehen:


    Ich versuche jetzt schon eine Weile, meinen Kopf um diese Werte zu wickeln, finde aber irgendwie noch keinen Zugang. :)
    Interessant finde ich die Meldung von ProjectX, dass der Start der ersten GOP nach der Schnittmarke früher als das Ende der GOP davor ist. Da muss also noch irgendwo ein Haken sein. Ich weiß allerdings nicht genau, durch welchen Wert der Start der GOP angezeigt wird.


    Hier sind die Stellen, an denen ich die Werte ausgebe:


    Falls ich noch irgendwelche Erkenntnisse bekomme, sag ich Bescheid.
    Das ganze ist eine SD-MPEG2-Aufnahme von Pro7 (KabelD).


    Lars.

    Zitat von mini73

    Moin!
    Interessant finde ich die Meldung von ProjectX, dass der Start der ersten GOP nach der Schnittmarke früher als das Ende der GOP davor ist. Da muss also noch irgendwo ein Haken sein. Ich weiß allerdings nicht genau, durch welchen Wert der Start der GOP angezeigt wird.
    Das ganze ist eine SD-MPEG2-Aufnahme von Pro7 (KabelD).
    Lars.


    Hi, hängt das evtl. mit dem geänderten Sendeformat von der Pro7/Sat.1-Gruppe zusammen?
    Quelle: Senderumstellung bei der ProSiebenSat1 Gruppe

    Zitat

    seit dem 24.10.2010 hat die ProSiebenSat.1-Gruppe das Sendeformat umgestellt. Betroffen sind aber nur die SD Sender.
    Der Sender packt nun in eine MPEG2 GOP (Group of Pictures) neben dem Vollbild nun ca. 38 Änderungsbilder. Somit verlängert sich die GOP von 0,4 auf bis zu 1,4 Sekunden.
    ...Eine Norm GOP geht bis zu 25 Bilder also 1 Sekunde.


    Das ist zwar schon in 2010 passiert und scheinbar wurde es in 2011 wieder zurückgenommen. Aber es gibt seit dieser Zeit trotzdem immer mal wieder Aufnahmen von diesen Sendern, die derart verunstaltet wurden. Das merkt man dann schon beim Springen in den Aufnahmen, wenn man darin mit Skip ( >| ) navigiert, dann ist sofort der Ton wieder da und nach ca. 2-3 Sekunden läuft das Bild erst wieder. Wenn man dann beim Schneiden von einer fixen, normgerechten GOP-Länge ausgeht.. Beim Abspielen der geschnittenen Aufnahme bleibt dann das Bild ständig hängen und der Ton ist extrem asynchron (so war es zumindest unter der originalen Activy Software). Andere Schnittprogramme hatten auch ihre Probleme damit siehe Quelle.
    Sollte der VDR damit keine Probleme haben?


    Mario

    Zitat von mini73

    Interessant finde ich die Meldung von ProjectX, dass der Start der ersten GOP nach der Schnittmarke früher als das Ende der GOP davor ist. Da muss also noch irgendwo ein Haken sein. Ich weiß allerdings nicht genau, durch welchen Wert der Start der GOP angezeigt wird.


    Ich koennte mir vorstellen, dass man das Open-GOP-Flag loeschen sollte, wenn man bei MPEG-2 beim Cut-In die B-Frames nach dem ersten I-Frame loescht und die GOP somit schliesst. Ist aber nur so eine Idee, hab es selber nicht ausprobiert (hab gerade kein Zugriff auf meinen vdr). Ob ProjectX das nun exakt checkt, weiss ich nicht...


    Gruss,
    S:oren

    Ich würde die Timestamps mit

    Code
    printf"%2d:%02d:%02d.%03d",
        (int)(ts / (90 * 3600000)), (int)((ts / (90 * 60000)) % 60),
        (int)((ts / (90 * 1000)) % 60), (int)((ts / 90) % 1000));


    ausgeben, finde dann die Logs viel lesbarer, als die langen Integerzahlen.


    Johns

    Sag mir, wo die Developer sind. Wo sind sie geblieben? . . . . . . . . . . . . . . . . . . . . SoftHdDevice - A software and GPU emulated HD output device plugin.
    Sag mir, wo die Developer sind. Was ist geschehn?


    Client0: Crown CW02 MSI_C847MS-E33 Zotac_GT640_passiv Cine-S2 iMon-MCE / streamdev softhddevice
    Client1: Lian_Li_PC-Q09FB ASRock_H67M-ITX/HT I3-2100 ASUS_ENGT520_passiv / streamdev softhddevice
    Test: Lian_Li_PC-Q09R Asus C60M1-I / streamdev
    Server0: Dockstar TT-S2-3600-USB / streamdev
    Server2: Lian_Li_PC-Q07R Intel_DH61DL G620 WD20EARX 90W PicoPSU Cine-S2+DuoFlex-S2+DuoFlex-CT / streamdev / 22 Watt Verbrauch

    Moin!


    Die GOP-Länge ist meistens 24: IBBPBBPBBPBBPBBPBBPBBPBB.


    So sieht die Ausgabe mit den umgewandelten Timestamps aus:



    Wenn mir jemand sagt, wie ich das Open-GOP-Flag lösche (bzw. das Setzen verhindere), probiere ich das gerne aus... Finde auf die Schnelle nicht die richtige Stelle. Da es eine TS-Aufnahme ist, ist es wohl nicht "SetBrokenLink".


    Lars.

    Moin!


    Wird aber anscheinend nur für PES-Aufnahmen aufgerufen:

    Code
    if (!SeamlessBegin) {
            if (isPesRecording) {
               if (Index == BeginIndex)
                  cRemux::SetBrokenLink(Buffer, Length);
               }
            else if (NumIndependentFrames < 2) {
               if (DanglingPacketStripper.Process(Buffer, Length, FirstPts))
                  NumIndependentFrames = 0; // we search until we find two consecutive I-frames without any more dangling packets
               }
            }


    Lars.

    Zitat von mini73


    Wird aber anscheinend nur für PES-Aufnahmen aufgerufen:
    ...


    Das BrokenLink Flag besagt ja nur, daß B-Frames, die eine PTS *vor* dem I-Frame haben, nicht dargestellt werden sollen.
    Da diese aber mit DanglingPacketStripper.Process() entfernt (bzw. "leer" gemacht) werden, sollte dieses Flag keinerlei Unterschied mehr machen.


    Klaus

    Zitat von kls

    Das BrokenLink Flag besagt ja nur, daß B-Frames, die eine PTS *vor* dem I-Frame haben, nicht dargestellt werden sollen.
    Da diese aber mit DanglingPacketStripper.Process() entfernt (bzw. "leer" gemacht) werden, sollte dieses Flag keinerlei Unterschied mehr machen.


    So hatte ich das auch verstanden. Merkwürdig nur, dass ProjectX da noch ein Problem sieht.
    Hab noch keinen Blick in dessen Source geworfen, warum es eine Fehlermeldung schmeißt. Das würde sicherlich helfen, damit man weiß, welcher Timestamp da getestet wird.
    Hab heute leider anderes zu tun.


    Lars.

    Langsam, langsam, das geht hier gerade durcheinander.
    Wenn ich den Code richtig verstehe, wird bei alten PES-Aufnahmen das BrokenLink-Flag gesetzt und keine B-Frames geloescht. Das macht dann ja so Sinn.
    Bei TS-MPEG2-Aufnahmen werden die ersten B-Frames nach dem CutIn (mit dem kleineren PTS als beim I-Frame und eben der Referenz auf die rausgeschnittene GOP) geloescht, dann gibts natuerlich keinen Link auf die vorangegangene GOP mehr, der broken sein koennte. Das BrokenLInk-Flag zu setzen macht hier natuerlich keinen Sinn. Mein Vorschlag war daher auch, in der GOP mit den geloeschten B-Frames das OpenGOP-Flag zu loeschen, da die GOP ja nun (ohne die B-Frames nach dem I-Frame) geschlossen ist. Das OpenGop-Flag ist direkt neben dem BrokenLink-Flag, wenn ich mich recht erinnere...


    Gruss,
    S:oren

    Ich habe mal schnell aus dem SetBrokenLink ein SetClosedGOP gemacht und hoffe, das stimmt so...

    Weiß nicht, ob das zur Erhellung was beiträgt, aber ich habe mir den vdr-1.7.33 gebastelt und mit dem mal eine 10min Tagesschauaufnahme geschnitten (stammt allerdings von einem vdr-1.7.31 - macht das einen Unterschied?).
    Die Schnittmarken habe ich so gesetzt, dass nach dem Schneiden nur noch der Sprecher zu sehen war. So kann man einfach feststellen, ob Bild und Ton synchron sind. Aus 10min Tagesschau ist so ein tsfile mit 1:25min Länge entstanden.


    Zunächst:
    Das Setzen der Schnittstellen klappt erstaunlich gut. Ich habe jeweils die erste Schnittmarke auf das Bild gesetzt, dass ich im geschnittenen Video dabei haben wollte, die Endmarke (cut out) jeweils auf das erste Bild, dass im Resultat nicht dabei sein sollte. Und tatsächlich sehe ich im Video keine Frames von den Einspielern und bei keinem Satz des Tagesschausprechers fehlt am Anfang ein Wort oder eine Silbe. Wenn das immer so gut läuft, ist das zum Werbung raus schneiden mehr als genug.


    Xine:
    Xine spielt das geschnittene TS-File klaglos durch. Allerdings gibt es an den Schnittstellen die Bildfehler, die hier schon beim Testen mit Mac-Playern beschrieben wurden: Es pixelt und blitzt für eine Sekunde kurz, dann ist wieder alles im Tritt und synchron.


    VLC:
    VLC macht leider mehr Probleme. Zum Start meldet das Programm:

    - sieht aber alles fein aus. An der ersten Schnittstelle fällt dann aber schon für wenigstens einige Sekunden der Ton aus, an den weiteren Schnittstellen beginnt das Bild übelst zu zittern. Springt man mit Hilfe der Maus innerhalb der Schitteile auf eine andere Stelle, kommt das ganze wieder in Fahrt und Bild und Ton sind perfekt. Leider meldet die Konsole nur noch

    Code
    [h264 @ 0x7f67dcca5410] Increasing reorder buffer to 11
[h264 @ 0x7f67dcca5410] Increasing reorder buffer to 12
[h264 @ 0x7f67dcca5410] Increasing reorder buffer to 16

    je Übergang von einer Schnittstelle zur nächsten.


    Inzwischen kann ProjectX auch h264 streams aus ts Files holen - also hoffnungsvoll mal das ganze durchgejagt und das Video und den ac3 Ton mit mkvmerge (mkvtoolnix) wieder zusammengesetzt. Das Resultat ist erstaunlicherweise eine Sekunde kürzer, die beiden Player verhalten sich jedoch exakt gleich!. Das Springen auf eine andere Stelle ist beim VLC mit der mkv-Datei etwas leichter, um so das Zittern beim Abspielen wieder abzustellen, aber das rechne ich mit meinem bescheidenem Wissen mal dem Container zu.
    Komischerweise stürzt ProjectX beim Verarbeiten der Untertitelspur ab. Genau das hat aber bereits bei vier anderen mit vdr-1.7.33 geschnittenen Aufnahmen von Channel4HD geklappt: die Untertitel ließen sich aus dem geschnittenen TS-File holen und weiterverarbeiten. Daher im Anhang noch das log-File von ProjectX ohne Untertitelextraktion.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden