Frameratenerkennung ab Version 2.0.6

zimuland · 29. März 2014

Hallo,

ich habe den Eindruck, dass seit dem Update von 2.0.5 auf 2.0.6 bei einigen Aufnahmen die Framerate nicht korrekt erkannt wird.
In der Info-Datei steht dann anstelle von "F 25" dann "F 50". Die angzeigte Aufnahmelänge entspricht daher nur der Hälfte der tatsächlichen Länge der Aufnahme.
Kann dieses Verhalten jemand nachvollziehen oder tritt das Problem nur bei mir auf?

Gruß zimuland

UFO · 29. März 2014

Welcher Sender?

zimuland · 29. März 2014

Es tritt bei unterschiedlichen Sendern auf, bisher habe ich es bei ARD, ZDF, SAT.1 und Pro7 gesehen. Alles in SD über DVB-C von KDG.

zimuland · 30. März 2014

Zur weiteren Eingrenzung des Fehlers habe ich jetzt sämtliche Plugins und Patches entfernt und mehrere Probeaufnahmen gemacht.
Bei den 17 Aufnahmen, immer 5 min Aufnahme und 5 min Pause auf demselben Kanal (ARD), war die Framerate bei der ersten Aufnahme falsch. Sie hatte einen Wert von 29.97002997, bei allen anderen Aufnahmen war der Wert mit 25 korrekt.

zimuland · 5. April 2014

Als nächstes habe ich in remux.c einmal

Code

static bool DebugFrames = true;

gesetzt und wieder ein paar Testaufnahmen gestartet.

Code

1:C-1-1101-28106:2014-04-05:1030:1034:50:99:Das Erste:
1:C-1-1079-28006:2014-04-05:1035:1039:50:99:ZDF:
1:C-1-1101-28106:2014-04-05:1040:1044:50:99:Das Erste:
1:C-1-1079-28006:2014-04-05:1045:1049:50:99:ZDF:
1:C-1-1101-28106:2014-04-05:1050:1054:50:99:Das Erste:
1:C-1-1079-28006:2014-04-05:1055:1059:50:99:ZDF:

Folgende Ausgabe habe ich dann erhalten:

Code

I/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/I
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 27 TRO = 0
I/B/P/B/P/B/P/B/P/P/P/P/P/P/P/P/P/P/P/P/P/P/P/P/P/IFloating point exception
Sa 5. Apr 10:35:02 CEST 2014 restarting VDR
I/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/I
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 27 TRO = 0
I/P/P/P/P/B/P/B/P/B/P/B/P/B/P/B/P/B/P/B/P/B/P/B/I
Delta = 1800  FPS = 50.00  FPPU = 1 NF = 24 TRO = 1
I/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/I
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0
I/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/I
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0
I/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/B/P/B/P/B/P/B/P/B/IFloating point exception
Sa 5. Apr 10:55:02 CEST 2014 restarting VDR
I/B/P/B/P/B/P/B/P/B/P/B/P/B/P/B/B/P/B/B/P/B/B/I
Delta = 1800  FPS = 50.00  FPPU = 1 NF = 23 TRO = 1

Alles anzeigen

Wie man sieht gibt es neben den falsch berechneten Frameraten sogar zweimal einen Absturz des VDR.

kls · 5. April 2014

Ich kann da leider nicht beim Debuggen helfen, weil ich hier kein solches Signal habe.

Klaus

Yuri666 · 5. April 2014

I had the same problem.
A some investigation revealed that operaton
iFrameTemporalReferenceOffset = TemporalReference - lastIFrameTemporalReference;
in remux.c sometimes takes negative values
and then in
uint32_t Delta = ptsValues[0] / (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset());
we have divide by zero.

zimuland · 6. April 2014

Für den Absturz hatte ich diese auch diese Division im Verdacht.
Ich habe mal bei der Ausgabe der Frametypen den Wert für die "Temporal Reference" in der Ausgabe hinzugefügt:

Code

I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0
I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 15 TRO = 0
I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0


I 2/B 0/B 1/P 5/B 3/B 4/P 7/B 6/I 1Floating point exception
So 6. Apr 09:59:37 CEST 2014 restarting VDR


I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0
I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/P 26/B 24/B 25/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 27 TRO = 0
I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0
I 1/B 0/P 3/B 2/P 5/B 4/P 7/B 6/P 9/B 8/P 11/B 10/P 13/B 12/P 15/B 14/P 17/B 16/P 19/B 18/P 21/B 20/P 23/B 22/I 1
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0
I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0
I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/P 26/B 24/B 25/P 29/B 27/B 28/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 30 TRO = 0
I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0
I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0
I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0


I 1/B 0/P 3/B 2/P 5/B 4/P 7/B 6/P 9/B 8/P 11/B 10/P 13/B 12/P 15/B 14/P 17/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 1800  FPS = 50.00  FPPU = 1 NF = 24 TRO = 1


I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0
I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 15 TRO = 0


I 1/B 0/P 3/B 2/P 5/B 4/P 7/B 6/P 9/B 8/P 11/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 1800  FPS = 50.00  FPPU = 1 NF = 24 TRO = 1


I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0
I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0
I 2/B 0/B 1/P 5/B 3/B 4/P 8/B 6/B 7/P 11/B 9/B 10/P 14/B 12/B 13/P 17/B 15/B 16/P 20/B 18/B 19/P 23/B 21/B 22/I 2
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 24 TRO = 0

Alles anzeigen

Scheinbar ist die Ausgabe immer dann falsch, wenn die Werte für die beiden I-Frames unterschiedlich sind.

Soweit ich das verstanden habe, stellt die Temporal Reference die Position des Frames innerhalb der GOP. Diese kann auch für I-Frames variieren, da die GOP immer mit einem I-Frame beginnt und B-Frames immer erst nach dem zugehörigen I-Frame gesendet werden. Somit sollte die Position des I-Frames innerhalb der GOP eigentlich keinen Einfluss auf die Framerate haben.

zimuland · 12. April 2014

Nachdem ich jetzt auch noch die Ausgabe der PTS-Werte ergänzt habe ergibt sich folgendes Bild:

Code

I 2 FEDDC331/B 0 FEDDA711/B 1 FEDDB521/P 5 FEDDED61/B 3 FEDDD141/B 4 FEDDDF51/P 8 FEDE1791/B 6 FEDDFB71/B 7 FEDE0981/P 10 FEDE33B1/B 9 FEDE25A1/P 12 FEDE4FD1/B 11 FEDE41C1/P 14 FEDE6BF1/B 13 FEDE5DE1/P 16 FEDE8811/B 15 FEDE7A01/P 18 FEDEA431/B 17 FEDE9621/P 20 FEDEC051/B 19 FEDEB241/P 22 FEDEDC71/B 21 FEDECE61/P 24 FEDEF891/B 23 FEDEEA81/P 26 FEDF14B1/B 25 FEDF06A1/P 28 FEDF30D1/B 27 FEDF22C1/P 30 FEDF4CF1/B 29 FEDF3EE1/I 1
   -19021007    -19028207    -19024607    -19010207    -19017407    -19013807    -18999407    -19006607    -19003007     -18992207    -18995807     -18985007     -18988607     -18977807     -18981407     -18970607     -18974207     -18963407     -18967007     -18956207     -18959807     -18949007     -18952607     -18941807     -18945407     -18934607     -18938207     -18927407     -18931007     -18920207     -18923807

Liste der sortierten PES-Werte und Zuordnung der entsprechenden Frames:

Code

-19028207 -19024607 -19021007 -19017407 -19013807 -19010207 -19006607 -19003007 -18999407 -18995807 -18992207 -18988607 -18985007 -18981407 -18977807 -18974207 -18970607 -18967007 -18963407 -18959807 -18956207 -18952607 -18949007 -18945407 -18941807 -18938207 -18934607 -18931007 -18927407 -18923807 -18920207
B 0       B 1       I 2       B 2       B 4       P 5       B 6       B 7       P 8       B 9       P 10      B 11      P 12      B 13      P 14      B 15      P 16      B 17      P 18      B 19      P 20      B 21      P 22      B 23      P 24      B 25      P 26      B 27      P 28      B 29      P 30

Daraus errechnen sich folgende PTS-Differenzwerte:

Code

3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600 3600

Somit ergeben sich vor der Berechnung des Delta folgende Werte:

Code

ptsValues[0] = 3600
framesPerPayloadUnit = 1
parser->IFrameTemporalReferenceOffset() = -1

Dies führt dann natürlich zu einer Floating point exception.

Ohne die Division ergeben sich dann folgende (korrekten) Werte.

Code

Delta = 3600  FPS = 25.00  FPPU = 1 NF = 31 TRO = -1

Da zur Berechnung des Delta nur die minimale Differenz zwischen zwei Frames (egal ob I, B der P) herangezogen wird, verstehe ich die Division (und dabei insbesondere die Verwendung der Differenz der "Temporal Reference" der I-Frames) bei der Berechnung nicht.
Leider steht mir kein Signal aus einer anderern Quelle als KDG zum Vergleich zur Verfügung. Vielleicht verwendet ja KDG eine ganz spezielle Kodierung des Streams.

kls · 13. April 2014

Kannst du bitte mal folgenden Patch probieren?

Diff

--- remux.c     2014/04/13 11:49:40     3.6
+++ remux.c     2014/04/13 11:57:20
@@ -1511,7 +1511,13 @@
                        for (int i = 0; i < numPtsValues; i++)
                            ptsValues[i] = ptsValues[i + 1] - ptsValues[i];
                        qsort(ptsValues, numPtsValues, sizeof(uint32_t), CmpUint32);
-                       uint32_t Delta = ptsValues[0] / (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset());
+                       int Div = framesPerPayloadUnit;
+                       if (framesPerPayloadUnit > 1) {
+                          Div += parser->IFrameTemporalReferenceOffset();
+                          if (Div <= 0)
+                             Div = 1;
+                          }
+                       uint32_t Delta = ptsValues[0] / Div;
                        // determine frame info:
                        if (isVideo) {
                           if (abs(Delta - 3600) <= 1)

Alles anzeigen

Klaus

UFO · 13. April 2014

Hm - wäre es so nicht besser?

Code

-                       uint32_t Delta = ptsValues[0] / (framesPerPayloadUnit + parser->IFrameTemporalReferenceOffset());
+                       int Div = framesPerPayloadUnit;
+                       if (framesPerPayloadUnit > 1)
+                          Div += parser->IFrameTemporalReferenceOffset();
+                       if (Div <= 0)
+                          Div = 1;
+                       uint32_t Delta = ptsValues[0] / Div;

Damit ist eine Division durch 0 in jedem Fall ausgeschlossen.

CU
Oliver

kls · 13. April 2014

Zitat von UFO

Hm - wäre es so nicht besser?
...

Damit ist es sicher noch sicherer - obwohl framesPerPayloadUnit noch nie Probleme gemacht hat.
Ich werde es so ändern.

Das Ermitteln der Framerate ist ja mit der Zeit leider immer komplexer geworden, und eigentlich müsste das ja auch in den Daten drinstehen. Für MPEG2 scheint das ja im "Sequence Start" zu stehen, aber für H.264 finde ich irgendwie nicht den richtigen Ansatzpunkt. Laut "ITU-T H.264" gibt es zwar eine "Sub-sequence characteristics SEI message" (SEI payload type 12), aber wenn ich mir mal die SEI payload types einiger HD-Kanäle anschaue, dann kommen da nur SEI messages mit payload type 1 oder 6.
Hat jemand einen Tipp, wie man bei H.264 die Framerate auslesen kann?

Klaus

zimuland · 13. April 2014

Hallo Klaus,

ein erster kurzer Test ist positiv verlaufen. Damit sind alle drei bisher beobachteten Fälle abgedeckt. Ich werde es heute Abend aber noch etwas ausführlicher testen.

Code

Delta = 3600  FPS = 25.00  FPPU = 1 NF = 16 TRO = 1
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 25 TRO = 0
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 26 TRO = -1

Gruß
Zimuland

zimuland · 13. April 2014

Bei mehr als 50 Aufnahmen gab es keine Probleme.

Die einzige Auffälligkeit war die folgende Sequenz:

Code

I 2 7AEDF553/B 0 7AEDD933/B 1 7AEDE743/P 5 7AEE1F83/B 3 7AEE0363/B 4 7AEE1173/P 8 7AEE49B3/B 6 7AEE2D93/B 7 7AEE3BA3/P 11 7AEE73E3/B 9 7AEE57C3/B 10 7AEE65D3/P 14 7AEE9E13/B 12 7AEE81F3/B 13 7AEE9003/P 17 7AEEC843/B 15 7AEEAC23/B 16 7AEEBA33/P 20 7AEEF273/B 18 7AEED653I 321/B 19
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 20 TRO = 319

kls · 14. April 2014

Zitat von zimuland

Bei mehr als 50 Aufnahmen gab es keine Probleme.

Die einzige Auffälligkeit war die folgende Sequenz:

Code

I 2 7AEDF553/B 0 7AEDD933/B 1 7AEDE743/P 5 7AEE1F83/B 3 7AEE0363/B 4 7AEE1173/P 8 7AEE49B3/B 6 7AEE2D93/B 7 7AEE3BA3/P 11 7AEE73E3/B 9 7AEE57C3/B 10 7AEE65D3/P 14 7AEE9E13/B 12 7AEE81F3/B 13 7AEE9003/P 17 7AEEC843/B 15 7AEEAC23/B 16 7AEEBA33/P 20 7AEEF273/B 18 7AEED653I 321/B 19
Delta = 3600  FPS = 25.00  FPPU = 1 NF = 20 TRO = 319

Das ist allerdings sehr merkwürdig. Kann ich mir eigentlich nicht erklären, woher das kommen könnte...

Klaus

Frameratenerkennung ab Version 2.0.6

Jetzt mitmachen!

Teilen