Neue Schnittfunktion in VDR 1.7.32

  • Da das im Ankündigungsthread wohl eher untergegangen ist, mache ich für dieses spezielle Thema hier mal einen eigenen Thread auf (und bitte nur Dinge hier posten, die wirklich zum Thema gehören).


    Es wurde ja immer wieder (freilich zu Recht) bemängelt, daß es an Schnittstellen zu Artefakten in Bild und Ton kommen kann. Ich habe daher in VDR 1.7.32 einiges an Code eingebaut, damit


    - TS-Pakete, die einen PTS haben, der vor dem Beginn der aktuellen Sequenz liegen, entfernt (bzw. "versteckt") werden
    - TS-Pakete, die erst nach dem letzten Frame der aktuellen Sequenz kommen (aber zeitlich noch zu dieser gehören), mit in die Sequenz "reingezogen" werden
    - Timestamps und Continuity-Counter so korrigiert werden, daß sie wieder in sich stimmig sind


    Wenn ich so geschnittene Aufnahmen (getestet mit je einer Aufnahme von Sat.1 (SD) und "Das Erste HD") z.B. mit Kaffeine abspiele, dann bekomme ich an den Schnittstellen praktisch keine Artefakte mehr. Spiele ich sie mit der TT S2-6400 ab, dann gibt es ein kurzes Flimmern im Bild beim Übergang, der Ton ist OK. Der Mac Video-Player dagegen kommt vollkommen außer tritt und kriegt sich gar nicht mehr ein (was jetzt nicht unbedingt für diesen Player spricht, denn selbst bei einer lokalen Störung in den Daten sollte sich ein Player irgendwann mal wieder synchronisieren und den Rest abspielen können). Ich verwende den Mac-Player hauptsächlich deshalb, weil er anscheinend am empfindlichsten auf Fehler reagiert und daher für diese Tests durchaus gut geeignet ist.


    Meine Bitte an euch wäre nun, den neuen Cutter ausgiebig zu testen, den Code zu reviewen und vielleicht Hinweise zu liefern, woher die noch auftretenden Artefakte kommen könnten.


    Klaus

  • Kann/sollte man mit der neuen Cutter Engine Naludump weglassen?


    Gruß
    iNOB

  • hi
    aendert sich was in der index , marks whatever datei ?


    holger

    VDR1 : core2duo 3.2 Ghz , 1GB Ram , 2x TT 1501 DVB-C 1 GB HD , Asus EN 210 Silent , Debian Squeeze 64bit + e-tobi Pakete
    VDR2 : 1.2 Ghz P3 , Digitainer 768 MB Ram , yavdr 0.3a 32 bit


  • aendert sich was in der index , marks whatever datei ?


    Es kann natürlich sein, daß die verbesserte Frame-Erkennung bei HD-Aufzeichnungen andere Ergebnisse bringt.
    Am Besten mit einer frischen, mit Version 1.7.32 erzeugten Aufnahme testen, oder im Zweifelsfall bei einer älteren Aufnahme die Index-Datei löschen und neu erstellen lassen.


    Klaus

  • In Verbindung mit softhddevice 0.5.2 habe ich mal folgendes getestet:


    Wiedergabe von älteren geschnittenen Filmen (ts) getestet, mein subjektiver Eindruck: Klötzchenbildung an Schnittgrenzen stark reduziert, kaum wahrnehmbar.


    Schnitt eines frisch aufgezeichneten Films von kabel1 HD, Markierungen lassen sich besser verschieben und das Ergebnis ist klötzchenfrei.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Jetzt bin ich dabei einige Filme aus dem HD+ Paket zu Schneiden, die hatte ich mir aufgehoben, bis diese Version kommt.


    Die Schnitte sind wunderbar, meist bei der Wiedergabe nicht mehr zu bemerken. Verbesserungswürdig ist noch der Sprung an eine beliebige Stelle, wie man es beim Überprüfen der Schnitte macht, hier tritt noch Klötzchenbildung auf. Das ist aber für die normale Widergabe nicht relevant und daher vernachlässigbar.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Also ich habe bei einer Aufnahme von ProSieben HD noch Klötzchenbildung an der Schnittstelle.


    Ich möchte es aber morgen/später noch mit einem frischen Index probieren.


    Stimmt, leider klappt es nicht bei allen Aufnahmen.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Was mir dazu noch aufgefallen ist, manche Aufzeichnungen von HD+ haben in der info-Datei F 50 statt F 25, wenn ich hier den index neu erstelle ist er nur noch halb so groß und die Aufzeichnung hat auch nur noch die halbe Länge, marks passen natürlich auch nicht mehr.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github


  • Wie viel willst du? Soll ein Schnittpunkt drin sein, oder ein blankes Stück? Mehr am Anfang (Vorspann) oder besser mitten im Film?


    Am Besten etwa eine Minute aus der Mitte, mit 3 Schnittmarken (2 Sequenzen), die so gesetzt sind, daß du den Fehler in der geschnittenen Fassung gut sehen kannst (die geschnittene Fassung brauch ich natürlich nicht).


    Kann allerdings etwas dauern, bis ich dazu komme, da ich momentan an was anderem arbeite...


    Klaus

  • Moin!


    Du nimmst eine kurze Aufnahme, setzt da drei Schnittmarken rein, so dass der Anfang und etwas aus der Mitte rausgeschnitten werden.
    Wenn du im Schnittergebnis die Klötzchen hast, dann ist es das passende Muster für Klaus.
    :)


    Lars.

  • Wenn ich so geschnittene Aufnahmen (getestet mit je einer Aufnahme von Sat.1 (SD) und "Das Erste HD") z.B. mit Kaffeine abspiele, dann bekomme ich an den Schnittstellen praktisch keine Artefakte mehr. Spiele ich sie mit der TT S2-6400 ab, dann gibt es ein kurzes Flimmern im Bild beim Übergang, der Ton ist OK.

    Ich habe auch mal etwas getestet und kurz in den Code reingeschaut. Mit der S2-6400 und MPEG2-TS-Material habe ich meist kurze Tonstoerungen an der Schnittstelle, eigentlich kein Bildflackern. Ich vermute, dass die Problemchen an nicht genau der richtigen Anzahl von Audiosamples fuer die vorhandenen Videobilder liegen.


    Bei H.264-Material gibt es Kloetzchen im Bild an den Schnittstellen. Das liegt vermutlich daran, dass an beliebigen I-Frames und nicht nur an IDR-Frames geschnitten wird, was bei H.264 nicht stoerungsfrei klappen kann, da hier fuer die Bilder nach dem I-Frame auch Bilder vor dem I-Frame bis zum letzten IDR-Frame als Referenzbilder benutzt werden duerfen. Diese Referenzen sind dann natuerlich kaputt.


    Insgesamt ist die neue Schnittfunktion aber ein grosser Fortschritt, denke ich. Nicht perfekt, aber gut benutzbar.


    Gibt es mit dem Mac-Player auch Probleme mit MPEG2-Material, oder nur bei H.264?


    Gruss,
    S:oren


    Edit: Ach ja, in TsHidePayload() wird der Continuity counter nicht angepasst. Der darf doch aber nur in Paketen mit payload erhoeht werden, oder?

  • Ich habe auch mal etwas getestet und kurz in den Code reingeschaut. Mit der S2-6400 und MPEG2-TS-Material habe ich meist kurze Tonstoerungen an der Schnittstelle, eigentlich kein Bildflackern. Ich vermute, dass die Problemchen an nicht genau der richtigen Anzahl von Audiosamples fuer die vorhandenen Videobilder liegen.


    Bei H.264-Material gibt es Kloetzchen im Bild an den Schnittstellen. Das liegt vermutlich daran, dass an beliebigen I-Frames und nicht nur an IDR-Frames geschnitten wird, was bei H.264 nicht stoerungsfrei klappen kann, da hier fuer die Bilder nach dem I-Frame auch Bilder vor dem I-Frame bis zum letzten IDR-Frame als Referenzbilder benutzt werden duerfen. Diese Referenzen sind dann natuerlich kaputt.


    Wenn ich das richtig sehe, dann dürfte man also nur I-Frames als solche nutzen, die in einer NAL-Unit vom Typ '5' kommen.
    Ich habe das mal testweise mit abgefragt, aber dann liegen die I-Frames schon verdammt weil auseinander. Solche IDR-Frames kommen anscheinend eher selten.


    Zitat


    Gibt es mit dem Mac-Player auch Probleme mit MPEG2-Material, oder nur bei H.264?


    Auch bei MPEG-2.


    Zitat


    Ach ja, in TsHidePayload() wird der Continuity counter nicht angepasst. Der darf doch aber nur in Paketen mit payload erhoeht werden, oder?


    Hatte ich ursprünglich so gemacht, daß der CC nur bei Paketen mit Payload hochgezählt wird, aber da hat mir dann (wenn ich mich recht erinnere) dvbsnoop einen continuity error gemeldet.
    Muß ich mir nochmal anschauen.


    Klaus

  • Moin!


    Hatte ich ursprünglich so gemacht, daß der CC nur bei Paketen mit Payload hochgezählt wird, aber da hat mir dann (wenn ich mich recht erinnere) dvbsnoop einen continuity error gemeldet.
    Muß ich mir nochmal anschauen.


    Wikipedia sagt: "Incremented only when a payload is present (i.e., adaptation field exist is 01 or 11)"
    http://en.wikipedia.org/wiki/MPEG_transport_stream


    Das mit den IDR-Frames ist leider so, dass dann nur ein sehr grober Schnitt möglich ist. Vielleicht erbarmt sich ja mal irgendwann jemand, und schreibt einen framegenauen Cutter mit Neukodierung der betroffenen GOP. :)
    Hier mal ein Ausschnitt aus der c't 2010/03, Seite 164 zu dem Thema.

    Zitat


    H.264-Schnitt: Anders und doch irgendwie bekannt
    Wer schon mit MPEG-2-Schneidern wie Cuttermaran oder Mpeg2Schnitt Erfahrungen gesammelt hat, wird sich schnell an die H.264-Welt gewöhnen – und sich darüber freuen, dass man die Dateien nicht zunächst demultiplexen muss, sondern die Aufnahmen in der Regel ohne Umweg bearbeiten kann. Anders als viele MPEG-2-Schnittprogramme können die in diesem Artikel genannten H.264-Cutter momentan nicht Frame-genau schneiden, sondern nur an bestimmten Stellen. Je nach Senderaster der Programme kann man alle 0,1 bis 1 Sekunden Schnittmarken setzen. Der Grund dafür liegt in Aufbau eines H.264-Videostroms. Grundsätzlich setzt er sich wie alle MPEG-Videoformate aus Gruppen verschiedener Frame-Typen zusammen: von anderen Frames unabhängig kodierte Bilder (Intra-Frame, I-Frame) und davon abgeleitete Bilder (Inter-Frames, zum Beispiel P-Frames und B-Frames). Während sich Letztere bei MPEG-2 nur auf ein vorangegangenes abgeleitetes oder Intra-kodiertes Bild beziehen, dürfen es bei H.264 mehrere sein („bewegungskompensierte Langzeitprädiktion“).
    In diesem Zusammenhang führte man einen speziellen Keyframe-Typ namens „Instantaneous Decoder Refresh“ (IDR) ein, der bei H.264 die Rolle des klassischen I-Frame einnimmt und die Länge einer Group of Pictures (GOP, von einem IDR-Frame zum nächsten) bestimmt. Nur der IDR-Frame kommt als Referenzbild für die Langzeitprädiktion infrage, andere I-Frames („Partial Sync Key Frames“) haben einen niedrigeren Stellenwert und eignen sich nicht als Schnittstartpunkt (Cut-in). Für den Cut-out kann man solche „normalen“ I-Frames aber ebenso nutzen wie die sich nur auf vorangegangene Bilder beziehende P-Frames. Leider geht die Bezeichnung der Frame-Typen bei den Programmen durcheinander: Wird nur von I-Frames gesprochen, sind meist IDR-Frames gemeint.


    Lars.

Jetzt mitmachen!

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