VDR markiert durchgehend jeden Frame als fehlerhaft mit insgesamt 153.485 Fehlern

Quote from FireFly

Aber der Indexer des VDR hat ein anderes Problem: Die fehlerhafte Aufnahme (mit starken Artefakten in den ersten vier Minuten) hat 153.485 Fehler nach dem Re-indexieren. Schneide ich die ersten vier Minuten weg, dann hat die resultierende Aufnahme noch 144.524 Fehler (der Schnittbalken im OSD ist weiterhin komplett schwarz von den Fehlermarkierungen).

Lasse ich dann vdr --genindex darüber laufen, dann hat die Aufnahme Null Fehler und es gibt auch keine Ausgaben von DebugChecks = true.

Momentan fehlt mir die Zeit das genauer zu untersuchen und ich bin mir nicht sicher, ob man das weiter verfolgen soll weil es ein ziemlicher Spezialfall ist ...

FireFly , könnstest Du dazu einen neuenThread aufmachen? 153.485 Fehler ... das hat doch mit diesem Thread "Genau ein TS Fehler am Anfang der HD Aufnahme" nichts zu tun.

Quote from FireFly

kls: Kannst Du Dir mal oben meinen Beitrag #29 ansehen?

Bei der ursprünglichen (re-indexierten) und geschnittenen Aufnahme werden alle Frames als fehlerhaft markiert, nach erneutem --genindex ist die geschnittene Aufnahme fehlerfrei, was auch dem subjektiven Bildeindruck entspricht.

Kann es sein, das die Aufnahme mit einer Version vor 2.7.3 gemacht wurde?

Evtl. ist das hiermit gefixt.

Quote from FireFly

Die Index-Generierung (für die Originalaufnahme und die geschnittene) und das Schneiden wurden mit VDR 2.7.3 (inkl. dem von Dir verlinkten Patch) gemacht.

Das heißt also, mit Version 2.7.3 ist alles OK, oder?

Beim Schneiden wird keine Fehlererkennung gemacht.

Quote from kls

Beim Schneiden wird keine Fehlererkennung gemacht.

Ich war (und bin) fest der Auffassung, dass wir das mit v2.7.3 eingeführt hatten, den Fehler im Vor- bzw. Nachlauf sowie in Werbepausen lassen sich seitdem durch Schneiden "entsorgen".

Oder willst du damit sagen, dass beim Schneiden nur bereits vorher erkannte Fehlerindikatoren kopiert bzw. eben weggelassen werden?

Quote from shofmann

Oder willst du damit sagen, dass beim Schneiden nur bereits vorher erkannte Fehlerindikatoren kopiert bzw. eben weggelassen werden?

Ja, genau das.

Wenn der PTS-Abstand einmal zu groß war, hatte sich das nicht mehr "gefangen". Daher die Änderung

@@ -2073,8 +2073,10 @@ void cFrameChecker::CheckFrame(const uchar *Data, int Length, bool IndependentFr
                  Report("duplicate backref");
               backRefs |= b;
               }
-           else
+           else {
               Report("rev diff too big");
+              lastPts = Pts;
+              }
            }
         else
            Report("zero diff");

Kannst du mir die Aufnahme mal zur Verfügung stellen?

fnu, kannst Du bitte #29 sowie #36-#50 in einen neuen Thread

"VDR markiert durchgehend jeden Frame als fehlerhaft mit insgesamt 153.485 Fehlern"

auslagern?

Ich habe jetzt die Testaufnahme von FireFly (danke dafür!) analysiert und folgendes gefunden:

1. Die Aufnahme hat am Anfang so viele fehlerhafte TS-Pakete, dass es nicht gelingt, den FPS-Wert zu ermitteln. Daher nimmt VDR defaultmäßig an, es wären 25fps, was dann dazu führt, dass nachfolgend alle Frames als fehlerhaft gemeldet werden, weil die Referenzen nicht stimmen. Wenn ich manuell den richtigen Wert vorgebe (50fps), dann sind diese Fehler weg. Da werde ich mir noch was überlegen.

2. In der Aufnahme gibt es eine Fehlerstelle, bei der ein viel zu großer Wert für num_ref_frames_in_pic_order_cnt_cycle gelesen wird. Dadurch dauert das Regenerieren des Index sehr lange, da die nachfolgende for-Schleife mehrere Milliarden mal durchlaufen wird. Ich habe das jetzt mal so geändert:

--- remux.c     2024/10/13 13:34:32     5.15
+++ remux.c     2024/12/04 14:04:39
@@ -1554,8 +1554,13 @@
      GetBit(); // delta_pic_order_always_zero_flag
      GetGolombSe(); // offset_for_non_ref_pic
      GetGolombSe(); // offset_for_top_to_bottom_field
-     for (int i = GetGolombUe(); i--; ) // num_ref_frames_in_pic_order_cnt_cycle
-         GetGolombSe(); // offset_for_ref_frame
+     uint32_t num_ref_frames_in_pic_order_cnt_cycle = GetGolombUe();
+     if (num_ref_frames_in_pic_order_cnt_cycle <= 32) {
+        for (uint i = 0; i < num_ref_frames_in_pic_order_cnt_cycle; i++)
+            GetGolombSe(); // offset_for_ref_frame
+        }
+     else
+        esyslog("ERROR: num_ref_frames_in_pic_order_cnt_cycle too big (%u)", num_ref_frames_in_pic_order_cnt_cycle);
      }
   GetGolombUe(); // max_num_ref_frames
   GetBit(); // gaps_in_frame_num_value_allowed_flag

Das Problem wird z.B. auch hier beschrieben.

Was ich allerdings nicht rausfinden konnte ist, wie groß gültige Wert für num_ref_frames_in_pic_order_cnt_cycle sein können (hab jetzt mal 32 genommen, damit scheint es zu gehen).

Weiß das vielleicht jemand?

Möglicherweise wäre es auch sinnvoll, beim Auftreten dieses Fehlers cH264Parser::ParseSequenceParameterSet() gleich ganz zu verlassen, da alles Nachfolgende ja keinen Sinn mehr machen dürfte.

Gerade ist mir noch aufgefallen, dass das wahrscheinlich eh der falsche Zweig für dieses Video ist.

pic_order_cnt_type ist nämlich in den allermeisten Fällen 0, hat an Fehlerstellen gerne mal "krumme" Werte, und ist auch zufällig ein paarmal 1 (und triggert dann den o.g. Fehler).

Das ist jetzt mein momantaner Stand für diesen Fix:

--- remux.c     2024/12/04 14:33:10     5.16
+++ remux.c     2024/12/04 21:53:07
@@ -287,6 +287,8 @@
                if (TsPid(p) == pid) { // only handle TS packets for the initial PID
                   if (++numPacketsPid > MAX_TS_PACKETS_FOR_VIDEO_FRAME_DETECTION)
                      return SetEof();
+                  if (TsError(p))
+                     return SetEof(); // don't parse TS packets with errors
                   if (TsHasPayload(p)) {
                      if (index > 0 && TsPayloadStart(p)) // checking index to not skip the very first TS packet
                         return SetEof();
@@ -1554,8 +1556,13 @@
      GetBit(); // delta_pic_order_always_zero_flag
      GetGolombSe(); // offset_for_non_ref_pic
      GetGolombSe(); // offset_for_top_to_bottom_field
-     for (int i = GetGolombUe(); i--; ) // num_ref_frames_in_pic_order_cnt_cycle
-         GetGolombSe(); // offset_for_ref_frame
+     uint32_t num_ref_frames_in_pic_order_cnt_cycle = GetGolombUe();
+     if (num_ref_frames_in_pic_order_cnt_cycle <= 32) {
+        for (uint i = 0; i < num_ref_frames_in_pic_order_cnt_cycle; i++)
+            GetGolombSe(); // offset_for_ref_frame
+        }
+     else
+        esyslog("ERROR: num_ref_frames_in_pic_order_cnt_cycle too big (%u)", num_ref_frames_in_pic_order_cnt_cycle);
      }
   GetGolombUe(); // max_num_ref_frames
   GetBit(); // gaps_in_frame_num_value_allowed_flag

Die Abfrage von TsError(p) in cTsPayload::GetByte() bewirkt, dass nur fehlerfreie TS-Pakete geparst werden. Damit tritt der im zweiten Hunk korrigierte Fall gar nicht mehr auf und der FPS-Wert wird richtig erkannt.

Da würde mich jetzt Input von euch interessieren. Ist die Änderung im ersten Hunk ausreichend? Soll ich den zweiten Hunk (der ja eh nur ein Symptom kuriert) weglassen?