[VDR 2.6.9] markad Schnitt von Aufnahmen

Ja, die Macht der Mathematik.

kls:

Ich hätte nochmals eine Frage in dem Zusammenhang:

Woher kommt das Flag, dass ein Packet ein Key Packet ist und du das dann in deinen Index als "independent" kennzeichnet ?

Kommt das so aus dem DVB Stream oder entscheidest du das im VDR (wenn ja, wo) ?

Mit ist bei H.264 aufgefallen, dass im Index alle i-Frames als "independent" gekennzeichnet sind und nicht nur die IDR Frames.

Und da die inneren i-Frames eines GOPs nicht unabhängig decodiert werden können, kommt es zu Bildfehler kurz nach dem Sprung auf so eine Marke.

Quote from kls

innere I-Frames eines GOP

Das gibt es bei H.264 leider. Bei MPEG2 gibt es das nicht, da gibt es auch keine Bildfehler am Schnittpunkt.

Quote from kls

I-Frames sind die, die ohne Zuhilfenahme anderer Frames sofort darstellbar sind.

Das ist zwar auch bei H.264 richtig, aber danach können Frames kommen, deren PTS vor dem I-Frame liegt, oder Referenzen haben, die über das I Frame hinweg gehen. Und das gibt dann die Bildfehler. Erst bei einem IDR Frame das nicht mehr der Fall.

Ich fasse mal zusammen, was da steht, das Bild lässt sich leider nicht kopieren.

Frame in Stream Order:

P1 IDR P2 P3 I P4 P4

Frame P4 kann eine Referenz zu P2 haben, also über das I Frame hinweg. Wenn man bei I schneidet, fehlt P4 die Referenz.

Hier ein paar Auszüge von PTS DTS Debugs einer H.264 Aufnahme (flags = 1 entspricht dem VDR Index Flag independent, ich lese ja das ein, was du raus schreibst)

packet (59682), stream 0: flags 1, PTS 3382427181 DTS 3382409181, diff: PTS to Key      70200, DTS 1800
packet (59683), stream 0: flags 0, PTS 3382419981 DTS 3382410981, diff: PTS to Key      -7200, DTS 1800
packet (59684), stream 0: flags 0, PTS 3382416381 DTS 3382412781, diff: PTS to Key     -10800, DTS 1800
packet (59685), stream 0: flags 0, PTS 3382414581 DTS 3382414581, diff: PTS to Key     -12600, DTS 1800
packet (59686), stream 0: flags 0, PTS 3382418181 DTS 3382416381, diff: PTS to Key      -9000, DTS 1800
packet (59687), stream 0: flags 0, PTS 3382423581 DTS 3382418181, diff: PTS to Key      -3600, DTS 1800
packet (59688), stream 0: flags 0, PTS 3382421781 DTS 3382419981, diff: PTS to Key      -5400, DTS 1800
packet (59689), stream 0: flags 0, PTS 3382425381 DTS 3382421781, diff: PTS to Key      -1800, DTS 1800
packet (59690), stream 0: flags 0, PTS 3382441581 DTS 3382423581, diff: PTS to Key      14400, DTS 1800

Die ersten Pakete nach 59682 werden vor diesem dargestellt, gibt Bildfehler beim Schnitt an dieser Stelle. Einfach weglassen geht auch nicht, weil dann nachfolgenden Frames Referenzen fehlen.

Hier im Stream die nächste Möglichkeit, wo Schneiden ohne Bildfehler möglich wäre:

packet (59884), stream 0: flags 1, PTS 3382778181 DTS 3382772781, diff: PTS to Key      19800, DTS 1800
packet (59885), stream 0: flags 0, PTS 3382792581 DTS 3382774581, diff: PTS to Key      14400, DTS 1800
packet (59886), stream 0: flags 0, PTS 3382785381 DTS 3382776381, diff: PTS to Key       7200, DTS 1800
packet (59887), stream 0: flags 0, PTS 3382781781 DTS 3382778181, diff: PTS to Key       3600, DTS 1800
packet (59888), stream 0: flags 0, PTS 3382779981 DTS 3382779981, diff: PTS to Key       1800, DTS 1800
packet (59889), stream 0: flags 0, PTS 3382783581 DTS 3382781781, diff: PTS to Key       5400, DTS 1800
packet (59890), stream 0: flags 0, PTS 3382788981 DTS 3382783581, diff: PTS to Key      10800, DTS 1800
packet (59891), stream 0: flags 0, PTS 3382787181 DTS 3382785381, diff: PTS to Key       9000, DTS 1800

Quote from kls

würde ich mich über einen entsprechenden Patch, der das fixt, freuen.

Der Fix war nicht das Ziel meines Posts. Ich wollte nur wissen, wo das Flag herkommt.

Ich bin sogar der Meinung, das sollte man so lassen. Obiges Beispiel zeigt die Auswirkung, wenn man das fixen würde: Der Abstand IDR zu IDR an der Stelle (ist vermutlich nicht konstant) in meiner H.264 Aufnahme ist 4,7s. Das wäre doch sehr grob für eine Sprungmarke, dann wohl lieber Bildfehler am Schnitt, oder ?

Wenn ich den Code richtig verstanden habe, dann wird es keinen Patch geben, da der DVB Stream die Info in der NAL Unit nicht sendet:

diff --git a/remux.c b/remux.c
index 6c046ab4..8a9e7801 100644
--- a/remux.c
+++ b/remux.c
@@ -1489,8 +1489,8 @@ int cH264Parser::Parse(const uchar *Data, int Length, int Pid)
                                             gotSequenceParameterSet = true;
                                             }
                                          break;
-           case nutCodedSliceNonIdr:
-           case nutCodedSliceIdr:        if (gotAccessUnitDelimiter && gotSequenceParameterSet) {
+           case nutCodedSliceIdr:        dsyslog("IDR found");
+           case nutCodedSliceNonIdr:     if (gotAccessUnitDelimiter && gotSequenceParameterSet) {
                                             ParseSliceHeader();
                                             gotAccessUnitDelimiter = false;
                                             if (newFrame)

Mit diesem Patch müsste ich bei jedem IDR Frame eine Syslog Meldung "IDR found" kommen.

Da kommt aber nichts.

Die Aufnahme ist von ARD HD.

Quote from kls

Das würde ja bedeuten, dass das Umschalten zwischen zwei solchen Kanälen bis zu 4.7s dauern kann, denn eine (fehlerfreie) Darstellung ist ja erst nach einem IDF möglich, wenn ich das richtig verstehe.

Nein, weil nicht alle Frames auf das letzte IDR verweisen, sondern nur ein paar Frames nach dem nicht IDR I-Frame eine Referenz vor das i-Frame haben. Es scheint meistens 7 zu sein, also 7*1/50 = 0,14s bis das Bild fehlerfrei ist.

Sehe ich auch so.