Haenlein-Software Forum

Hallo!

Jetzt, wo ich die Investition schon getätigt habe, fällt mir auf, dass das im Vorschau-Fenster angezeigte und durch Klick auf "Cut-In" ausgewählte Frame, die abgespielte Schnittvorschau und der tatsächliche Schnitt nicht übereinstimmen. Am ehesten stimmen noch das Cut-In-Frame im Vorschau-Fenster und der tatsächlich ausgeführte Schnitt überein, was ja schon mal nicht schlecht ist. Die Schnittvorschau startet aber immer bei einem deutlich späteren Frame, als der in der Vorschau angezeigte und ausgewählte Cut-In-Frame. Das würde die Schnittvorschau zunächst einmal überflüssig machen. Das ganze tritt bei mindestens drei HD-Aufnahmen von ARD und ZDF auf. Es gefällt mir nicht, dass ich scheinbar keine Kontrolle über den Schnitt habe. Auch wenn ich verstehe, dass DVR-Studio (hier Version 2.22.2) nur an GOP-Grenzen schneiden kann, so müssten doch alle drei Anzeigen (Vorschau, Schnittvorschau und tatsächlicher Schnitt) am gleichen Frame beginnen.

Wo ich gerade bei GOPs bin: Wie genau ist eigentlich ein GOP definiert? Startet an jedem I-Frame ein neuer GOP? Wie ist ein GOP in h.264 definiert, wo es nicht nur I-, sondern auch IDR-Frames gibt? Die öffentlichen rechtlichen HD-Streams enthalten gar keine IDR-Frames (was manche Leute übrigends als Argument dafür nehmen, dass DVB-HD-Streams nicht Bluray-compatibel sind). Was ist denn dort eine GOP? Ich habe bei den meisten Cut-In-Frames in der geschnittenen ts-Datei später Bildstörungen, was mich nicht sonderlich stört, solange der Stream wenigstens mit dem Frame beginnt, den ich zum Schnitt ausgewählt habe. Bedeutet das aber, dass DVR-Studio dann an I-Frames schneidet, wodurch nachfolgende Frames Referenzen verlieren? Wozu dann die Beschränkung auf GOP-Grenzen? Was ist mit "Nächstes Key-Frame anzeigen" bei HD-Aufnahmen gemeint? I-Frames oder IDR-Frames? (Ich vermute beides)

Ich weiß, dass das viele Fragen sind, aber vielleicht können ja ein paar davon beantwortet werden...

Gruß,
Indy

Hallo Indy,

eigentlich sollten die Schnittpunkte auch so umgesetzt werden, wie du sie gesetzt hast.
Bedenke aber das du im Programm selber nur die I-Frames angezeigt bekommst und zwischen zwei Bildern, die du siehst noch die restlichen Bilder der GOP liegen.

Unsere Programm schneiden an den I-Frames (bei MPEG2 und H.264), wenn davor ein SPS liegt.
Das du beim H.264 ab und an noch Bildstörungen an den Schnittbereichen hast, liegt daran dass noch nach dem I-Frame ein paar Frames liegen (können), welche vom davor liegendem GOP sind.
Diese lassen sich aber nicht sauber entfernen. Einige Programm machen das mit der Brechstange aber das hat nach unseren Tests auf diversen Playern und Receivern eher eine negative statt positive Auswirkung. Deshalb lassen wir diese drin.

Tobias hat geschrieben:Hallo Indy,

eigentlich sollten die Schnittpunkte auch so umgesetzt werden, wie du sie gesetzt hast.

Ja, das stimmt. Soweit ich sehen kann wird der Stream tatsächlich dort geschnitten, wo man im Vorschaufenster auf den Button "Cut-In" geklickt hat. Aber die Schnittvorschau stimmt damit überhaupt nicht überein. Sie fängt - zumindest bei mir - bei einem deutlich späteren Frame an. Will sagen, die Ansicht im Vorschaufenster ist viel akkurater, als die Schnittvorschau.

Bedenke aber das du im Programm selber nur die I-Frames angezeigt bekommst und zwischen zwei Bildern, die du siehst noch die restlichen Bilder der GOP liegen.

Ja, das ist klar. Und würden bei einem h.264-Stream, der IDR-Frames enthält, auch die angezeigt werden?

Unsere Programm schneiden an den I-Frames (bei MPEG2 und H.264), wenn davor ein SPS liegt.

Was ist ein SPS? Und was ist mit IDR-Frames?

Das du beim H.264 ab und an noch Bildstörungen an den Schnittbereichen hast, liegt daran dass noch nach dem I-Frame ein paar Frames liegen (können), welche vom davor liegendem GOP sind.
Diese lassen sich aber nicht sauber entfernen. Einige Programm machen das mit der Brechstange aber das hat nach unseren Tests auf diversen Playern und Receivern eher eine negative statt positive Auswirkung. Deshalb lassen wir diese drin.

Also irgendwie bin ich verwirrt. Ich dachte immer, dass ein GOP die kleinste *unabhängig* dekodierbare Einheit eines MPEG-Streams darstellt. Also ein Frame aus einem GOP kann nicht ein Frame aus einem anderen GOP referenzieren und selbst auch nicht als Referenz für ein Frame aus einem anderen GOP dienen. Wenn das halbwegs richtig wäre, dann kann man an einer GOP-Grenze schneiden, ohne das dabei Bildstörungen auftreten. Für einen h.264-Sream gilt das aber nur an einem IDR-Frame (Instantaneous Decoding Refresh). Ein I-Frame reicht nicht mehr, weil bei h.264 auf dieses I-Frame Frames folgen können, deren Referenzen noch vor dem I-Frame liegen. Schneidet man trotzdem an einem I-Frame, dann fehlen einem Teil der folgenden Frames die Referenzen und man bekommt Bildstörungen - so wie es bei mir häufig der Fall ist.

Ich möchte es wirklich gern verstehen. Deshalb: Wenn ein DVB-HD-Stream keine IDR-Frames enthält, wie ist dann ein GOP definiert und wo schneidet DVR-Studio dann?

Gruß,
Indy

Die Vorschau startet leider technisch bedingt am Anfang etwas träge, deshalb sieht man die ersten Sekunden nicht.
Das stört nur beim ersten Schnittpunkt. Bei einem Schnitt innerhalb der Aufnahme stört das nicht weiter, da man ja die Stelle in der Mitte der Vorschau beurteilt.

Ein I-Frame oder IDR-Frame braucht auch ein SPS (Sequence Parameter Set).
Diese liegt meist direkt vor dem I(DR)-Frame.
Wenn unser Programm sowohl SPS als auch I(DR)-Frame findet, dann wird die dieses Bild als Key-Frame angeboten.

Bei den GOPs in H.264 kann das (leider) etwas mehr verzahnt sein,als bei MPEG 2.
Die Sache mit den "unnutzen Frames" (aus der vorherrigen GOP) hat man aber auch bei MPEG2, dort lässt es sich aber beheben.
Wenn dich das interessiert, dann such im Internet mal nach dem Unterschied zwischen Anzeige und Stream Reihenfolge von Frames in MPEG2, so ähnlich ist es dann auch bei H.264.

Hallo!

Tobias hat geschrieben:Die Vorschau startet leider technisch bedingt am Anfang etwas träge, deshalb sieht man die ersten Sekunden nicht.
Das stört nur beim ersten Schnittpunkt. Bei einem Schnitt innerhalb der Aufnahme stört das nicht weiter, da man ja die Stelle in der Mitte der Vorschau beurteilt.

Ok, nicht schön, aber damit komme ich klar!

Ein I-Frame oder IDR-Frame braucht auch ein SPS (Sequence Parameter Set).
Diese liegt meist direkt vor dem I(DR)-Frame.
Wenn unser Programm sowohl SPS als auch I(DR)-Frame findet, dann wird die dieses Bild als Key-Frame angeboten.

Hmh, noch nie gehört. Ist dann ein I(DR)-Frame mit vorhergehendem SPS automatisch auch der Beginn eines neuen GOPs? Könnt Ihr denn bestätigen, dass die DVB-HD-Streams von ARD, ZDF und arte keine IDR-Frames enthalten? Wie verhält es sich dann streng genommen mit der Kompatibilität zu Bluray?

Bei den GOPs in H.264 kann das (leider) etwas mehr verzahnt sein,als bei MPEG 2.
Die Sache mit den "unnutzen Frames" (aus der vorherrigen GOP) hat man aber auch bei MPEG2, dort lässt es sich aber beheben.
Wenn dich das interessiert, dann such im Internet mal nach dem Unterschied zwischen Anzeige und Stream Reihenfolge von Frames in MPEG2, so ähnlich ist es dann auch bei H.264.

Ja, also ich muss wohl tatsächlich noch mehr lesen. Mir war bewusst, dass die (De-)Kodier- und Anzeige-Reihenfolge bei MPEG nicht immer gleich sein muss. Allerdings dachte ich, dass sich das trotzdem NUR auf die Reihenfolge innerhalb eines GOPs bezieht. Auch dieser Text (http://de.wikipedia.org/wiki/Bildergruppe) diskutiert das ganze nur auf Ebene eines GOPs. Was die unabhängige Dekodierung eines GOPs angeht, gibt es allerdings noch die Begriffe "open GOP" und "closed GOP", vielleicht hat das ja etwas damit zu tun.

Gibt es denn eigentlich keine öffentlich zugängliche Dokumentation der HD-Streams, zumindest der öffentlich-rechtlichen Sender? Das wäre ja auch für Euch interessant, oder nicht?

Gruß,
Indy

Hallo Indy,

das Thema HD Bearbeitung ist sehr komplex und um einiges schwieriger als das alte MPEG2.
Bitte habe aber Verständnis dafür, dass wir nicht die Zeit haben das hier im Forum zu erklären. Tobias und Sascha sind keine "normalen" Supporter. Deren Aufgabe ist die Entwicklung der Produkte, denn es soll ja weiter gehen.

Was die Infoquellen angeht, gebe ich Dir Recht, das könnte offener sein. Gerade was die Blu-Ray Spezifikation angeht, sitzt man bei den Patentinhabern wie die Glucke auf den Eiern…

Vieles muss man über zig Quellen sich zusammensuchen. Wie kompliziert es ist, zeigt auch die Tasche, dass sich nicht viele Firmen wirklich mit dem Thema befassen.

Ich sehen es als Vorteil… Weniger Konkurrenz.

Hallo Indy,
versuche mal ein bisschen Licht ins Dunkle der H.264 Materie zu bringen. Das Problem beim Schneiden des Filmes ist das die Schnittstelle neu codiert werden müsste.

Dieses kommt daher weil der H.264 Codec eine Referenzierung über die eigene GOP zulässt. Im Klartext ein P-Frame darf auf beliebig viele Referenzframes verweisen. x264
beschränkt das Maximum auf sechzehn. Außerdem entsteht durch die Mehrfachreferenzen ein weiteres Phänomen. Es existieren in H.264 zwei verschiedene Arten von I-Frames: normale I-Frames und IDR-Frames. Beide I-Frame-Typen sind vollständige Einzelbilder, d. h. sie selbst enthalten keine Referenzen auf andere Frames. Referenzen über einfache I-Frames hinweg sind aber möglich. Es wäre also einwandfrei erlaubt, dass das Frame P4 über das I-Frame hinweg auf P2 referenziert. Die Konsequenz
daraus ist die, dass ein einfaches I-Frame nicht als Punkt taugt, an dem wir den Film schneiden können, denn damit würden wir P4 zumindest einen Teil seiner Referenzen wegnehmen. Bildfehler am Anfang der zweiten Datei wären die Folge. Keyframes in dem Sinn, wie wir sie kennen, sind nur IDR-Frames, denn eine Referenz über ein IDR-Frame hinweg ist nicht erlaubt. Das heißt auch, dass fürs Springen und Schneiden nur IDR-Frames relevant sind und wir einfache I-Frames genauso wie P- und B-Frames
behandeln müssen.Jetzt kannst du dir sicherlich auch erklären warum in den ÖR Aufnahmen diese Pixelfehler bei den Schnittpunkten sind. Die Streams von ARTE_HD, ARD_HD, ZDF_HD, ORF_HD und ServusTV_HD haben keine IDR Frames, nur I-Frames.

Die Referenzierung über I-Frames hinweg ist schon vorhanden nur verwerfen die gängigen Schnittprogramme .....die ins Leere gehenden Frames.Schneidet man mit einem einfachen Dateisplitter oder HEX Editor würden die B-Frames nicht entfernt werden und man hätte Block-Störungen bzw gar kein Bild.

Ein IDR Frame wäre immer auch das erste Frame (Frame 0) in der Display Order.
Hoffe es wird hiermit ein bisschen durchsichtiger für dich. Wenn du weitere Infos zum H.264 Codec suchst solltest du wie Ralf schon anmerkte Google bemühen. Manches ist dem Encodingwissen von Brother John entnommen, und andere Quellen. Habe sie für dich einfach mal zusammen getragen.
Gruss skaterkarlo...