VDR-Testreihe zum Frame-Detector - Bitte um Mithilfe!

Was ich auf die Schnelle getestet habe, hat 5 oder 6, einzige Ausnahme ist WDR-HD mit 9.

CU
Oliver

Würde mich aber doch interessieren, wie ich den Schnittpunkt über den Offset bestimmen kann ?

Ein Ausschnitt mit 13 ist unterwegs. (Es handelt sich definitiv nicht um einen Fehler in der Aufnahme!)

CU
Oliver

Ich hab mal gerade ne Testaufnahme gemacht und bin auf 9 gekommen, der Sender scheint wirklich kritisch ..

Nach Beendigung der Aufnahme:

Maximum TS package frame size needed for this video recording: 17

Vielleicht wäre es noch interessant, das Test-Tool so zu erweitern, daß es ausgibt wieviele Frames insgesamt getestet wurden und wieviele davon den maximalen Wert hatten.
Eventuell sind das ja auch nur "Ausreißer".

Klaus

Zitat von kls

Vielleicht wäre es noch interessant, das Test-Tool so zu erweitern, daß es ausgibt wieviele Frames insgesamt getestet wurden und wieviele davon den maximalen Wert hatten.
Eventuell sind das ja auch nur "Ausreißer".

Es sind bei WDR HD nur Ausreißer - aber reproduzierbar. Einfach mal ~15min aufnehmen. Auch hier ist der Wert meist 5 oder 6, aber ab und zu werden da wohl irgendwelche zusätzlichen Daten mitgesendet. Die Standards erlauben ja eine Menge optionale Daten...

CU
Oliver

Hab gerade zwei WDR HD Köln Aufnahmen von August 2012 getestet, die laut checkts und naludump fehlerfrei sind.
Der framedetectortest zeigt 14 und 18.

Edit: zum bequemen WDR HD Aufnahmen finden:

#!/bin/bash
VIDEODIR=/video
cd $VIDEODIR
for i in `find -name info`; do
WDR=`grep -e ^C $i | grep -e "WDR HD"`;
if [ ! -z "$WDR" ]; then readlink -f $i;
fi
done
exit

WDR HD scheint wirklich anders zu sein. Fast alle Sender 5 oder 6, WDR HD fast alle > 12, negativer Ausreißer mit 18.

Getestet mit DVB-S2

Andy

Zitat von Ein Eike

Ich hab stattdessen mal reindebugt. Das Problem ist wohl, dass ein I-Frame in einem TS-Paket anfängt,
bei dem der Payload Unit Start Indicator nicht gesetzt ist. Ich vermute mal, dass das nicht ok ist, aber so
wird's halt versendet.

OK ist das durchaus. Nur halt ungünstig ;-).

Zitat

Ich würde folgendes vorschlagen (unter der Voraussetzung, dass ich den Code da richtig verstanden habe):
Wenn in cFrameDetector::Analyze(const uchar *Data, int Length) der Parser einen neuen Frame gefunden hat,
sollte unabhängig vom "PUSI" geprüft werden, ob genügend Daten für den Sync-Zustand vorhanden sind.

Also statt

}
if (TsPayloadStart(Data) {
// Determine the frame rate from the PTS values in the PES headers:

... jetzt das hier:

}
if (TsPayloadStart(Data) newFrame) {
// Determine the frame rate from the PTS values in the PES headers:

Was hältst du davon?

Alles anzeigen

Ich glaube nicht, daß das was bringt, denn wir brauchen ja den Anfang des ersten PES-Pakets einer Payload, um den PTS zu ermitteln. Und dazu muß PUSI gesetzt sein.

Ich werde mir das auch nochmal genauer anschauen, was da bei "WDR HD" anders ist als bei den anderen.

Klaus

Ich habe jetzt mal folgende Debug-Ausgaben eingebaut und MIN_TS_PACKETS_FOR_FRAME_DETECTOR auf 100 gesetzt, um garantiert nichts zu verpassen:

--- remux.c     2014/01/18 11:27:30     3.1
+++ remux.c     2014/01/27 10:19:25
@@ -18,7 +18,7 @@
 
 // Set these to 'true' for debug output:
 static bool DebugPatPmt = false;
-static bool DebugFrames = false;
+static bool DebugFrames = true;//XXX false;
 
 #define dbgpatpmt(a...) if (DebugPatPmt) fprintf(stderr, a)
 #define dbgframes(a...) if (DebugFrames) fprintf(stderr, a)
@@ -247,11 +247,16 @@
   index = 0;
 }
 
+int TSIndex = 0;//XXX
+int TSOther = 0;//XXX 
+
 uchar cTsPayload::GetByte(void)
 {
   if (!Eof()) {
      if (index % TS_SIZE == 0) { // encountered the next TS header
+        if (index == 0) TSOther = 0;//XXX
         for (;; index += TS_SIZE) {
+            TSIndex = index / TS_SIZE;//XXX
             if (data[index] == TS_SYNC_BYTE && index + TS_SIZE <= length) { // to make sure we are at a TS header start and drop incomplete TS packets at the end
                uchar *p = data + index;
                if (TsPid(p) == pid) { // only handle TS packets for the initial PID
@@ -264,6 +269,7 @@
                      break;
                      }
                   }
+               else TSOther++;//XXX
                }
             else {
                length = index; // triggers EOF
@@ -1349,6 +1355,8 @@
      static const char SliceTypes[] = "PBIpi";
      dbgframes("%c", SliceTypes[slice_type % 5]);
      }
+  static const char SliceTypes[] = "PBIpi";//XXX
+  if (debug || TSIndex > 1) fprintf(stderr, " %d(%d)%c", TSIndex, TSOther, SliceTypes[slice_type % 5]);//XXX
   if (frame_mbs_only_flag)
      return; // don't need the rest - a frame is complete
   GetGolombUe(); // pic_parameter_set_id

Damit erhalte ich bei einer Aufnahme auf "WDR HD" von S19.2E:

ASI 1(0)I/AB 0(0)B/AB 0(0)B/AB 0(0)B/AB 0(0)B/AB 0(0)B/AB 0(0)B/AB 0(0)B/AP 0(0)P/AB 0(0)B/AB 0(0)B/AB 0(0)B/AB 0(0)B/AB 0(0)B/AP 0(0)P/AB 0(0)B/AB 0(0)B/AB 0(0)B/AB 0(0)B/AB 0(0)B/AP 0(0)P/AB 0(0)B/AB 0(0)B/AB 0(0)B/AB 0(0)B/AB 0(0)B/AP 0(0)P/AB 0(0)B/AB 0(0)B/AB 0(0)B/AB 0(0)B/AB 0(0)B/ASI 1(0)I
Delta = 1800 FPS = 50,00 FPPU = 1 NF = 32 TRO = 0
2(1)I 4(3)I 2(1)I 2(1)I 2(1)I 4(3)I 4(3)I 4(3)I 4(3)I 5(4)I 2(1)I 3(2)I 2(1)I 2(1)I 4(3)I 2(1)I 2(1)I 4(3)I 3(2)I 2(1)I 2(1)I 4(3)I 4(3)I 3(2)I 2(1)I 4(3)I 2(1)I 2(1)I 2(1)I 5(4)I 4(3)I 3(2)I 3(2)I 5(4)I 2(1)I 5(4)I 2(1)I 3(2)I 2(1)I 7(6)I 8(7)I 3(2)I 2(1)I 4(3)I 4(3)I 2(1)I 4(3)I 2(1)I 4(3)I 6(5)I 4(3)I 3(2)I 3(2)I 3(2)I 5(4)I 6(5)I 2(1)I 12(11)I 2(1)I 2(1)I 7(6)I 2(1)I 3(2)I 3(2)I 2(1)I 3(2)I 3(2)I 3(2)I 2(1)I 2(1)I 2(1)I 2(1)I 4(3)I 4(3)I 4(3)I 4(3)I 2(1)I 4(3)I 6(5)I 2(1)I 4(3)I 3(2)I 4(3)I 2(1)I 4(3)I 3(2)I 2(1)I 2(1)I 4(3)I 2(1)I 2(1)I 5(4)I 2(1)I 2(1)I 2(1)I 2(1)I 2(1)I 2(1)I 5(4)I 2(1)I 3(2)I 4(3)I 8(7)I 8(7)I 7(6)I 5(4)I 2(1)I 3(2)I 4(3)I 4(3)I 2(1)I 4(3)I 2(1)I 4(3)I 4(3)I 4(3)I 2(1)I 3(2)I 2(1)I 2(1)I 4(3)I 3(2)I 4(3)I 2(1)I 2(1)I 4(3)I 11(10)I 4(3)I 2(1)I 10(9)I 3(2)I 2(1)I 2(1)I 4(3)I 4(3)I 2(1)I 4(3)I 2(1)I 2(1)I 3(2)I 2(1)I 3(2)I 3(2)I 3(2)I 2(1)I 4(3)I 3(2)I 4(3)I 3(2)I 3(2)I 2(1)I 4(3)I 2(1)I 3(2)I 4(3)I 2(1)I 4(3)I 4(3)I 4(3)I 2(1)I 3(2)I 4(3)I 4(3)I 6(5)I 4(3)I 4(3)I 4(3)I 2(1)I 2(1)I 3(2)I 4(3)I 2(1)I 4(3)I 4(3)I 3(2)I 2(1)I 4(3)I 4(3)I 5(4)I 2(1)I 6(5)I 4(3)I 4(3)I 2(1)I 2(1)I 2(1)I 4(3)I 4(3)I 2(1)I 3(2)I 12(11)I 3(2)I 2(1)I 2(1)I 2(1)I 3(2)I 4(3)I 2(1)I 3(2)I 4(3)I 4(3)I 4(3)I 2(1)I 2(1)I 3(2)I 4(3)I 2(1)I 3(2)I 2(1)I 4(3)I 4(3)I 4(3)I 3(2)I 3(2)I 2(1)I 3(2)I 2(1)I 3(2)I 2(1)I 3(2)I 3(2)I 3(2)I 2(1)I 2(1)I 3(2)I 4(3)I 2(1)I 3(2)I 5(4)I 3(2)I 3(2)I 4(3)I 2(1)I 3(2)I 8(7)I 3(2)I 2(1)I 5(4)I 3(2)I 4(3)I 2(1)I 3(2)I 3(2)I 2(1)I 5(4)I 4(3)I 2(1)I 2(1)I 2(1)I 2(1)I 2(1)I 4(3)I 3(2)I 4(3)I 3(2)I 4(3)I 2(1)I 3(2)I 4(3)I 2(1)I 12(11)I 4(3)I 7(6)I 4(3)I 2(1)I 2(1)I 4(3)I 8(7)I 2(1)I 2(1)I 3(2)I 2(1)I 4(3)I 2(1)I 2(1)I 2(1)I 4(3)I

Die Aufnahme lief ca. 35 Minuten und es gab 5 Fälle wo 10 oder mehr TS-Pakete nötig waren, um den Frame zu erkennen. Wobei dies nur bei I-Frames auftrat. Interessant ist auch, daß der Frametyp zwar immer im jeweils zweiten TS-Paket des Video-Streams erkannt wurde, zwischen dem ersten und zweiten Video-TS-Paket einer Payload aber bis zu 11 Pakete anderer PIDs (Audio) kamen.

Es könnte alles so einfach sein, wenn der Encoder nicht erstmal ein einzelnes Video-TS-Paket schicken würde und dann ewig viele Audio-Pakete, bevor die restlichen Video-Pakete kommen. Er könnte genausogut erstmal die Audio-Pakete schicken und dann die Video-Pakete "am Stück" (zumindest so viele, daß der Frame-Type erkannt werden kann). Dieses eine Paket vorzuziehen kann ja wohl keinen Unterschied machen. Aber dummerweise erlaubt der DVB-Standard solch ungeschicktes Verhalten...

Was also tun?
Fest steht, daß der Datenstrom nicht unnötig im Speicher umhergeschoben werden soll. Ein "Auseinanderdröseln" von Audio-, Subtitle- und Video-Daten kommt daher nicht in Frage. Bevor das erste Byte eines Video-Frames in die Aufnahmedatei geschrieben wird muß in cRecorder::Action() der Frame-Type bekannt sein, denn hier wird vor jedem I-Frame eine PAT/PMT eingefügt. Daher ist es wohl auch nicht möglich, daß der cFrameDetector erstmal bei jeder neuen Video-Payload (unabhängig davon, ob darin ein neuer Frame beginnt) ein "merk dir mal die Position" zurückgibt und cRecorder::Action() später, wenn tatsächlich ein Frame erkannt wird, diese Position anstatt der dann aktuellen nimmt, um den Index zu schreiben. Dann wäre die PAT/PMT ja nicht mehr vor dem I-Frame, und wenn sowas gleich am Anfang einer Aufnahme passieren würde, dann würde die ganze erste GOP nicht richtig wiedergegeben werden können, da zu diesem Zeitpunkt noch nicht bekannt wäre, welche PID was enthält.

Hmm, es wäre aber ohne weiteres möglich, die PAT/PMT auf jeden Fall am Beginn der Aufnahme zu schreiben. Das wäre also schonmal lösbar. Aber was, wenn die Wiedergabe irgendwo mitten in der Aufnahme starten soll? Wenn dann eine solche Stelle erwischt wird, wo keine PAT/PMT vor dem I-Frame kommt, dann haben wir wieder das gleiche Problem. Gut, das ließe sich dadurch lösen, daß bei der Wiedergabe am Einsprungpunkt der Frame nach einer PAT/PMT durchsucht wird. Das ist aber schon nicht mehr so schön, weil es halt einfach nicht mehr dir richtige Reihenfolge ist (Ursache vs. Wirkung). Und außerdem wäre das eine inkompatible Änderung des Aufzeichnungsformats. Ältere VDR-Versionen könnten eine solche Aufnahme zwar komplett abspielen, beim Einspringen irgendwo mittendrin würde aber eine GOP nicht richtig wiedergegeben. Könnte man vielleicht aber auch verschmerzen.
Gefallen tut es mir aber trotzdem nicht...

Bleibt fast nur, MIN_TS_PACKETS_FOR_FRAME_DETECTOR noch weiter hochzuschrauben. Fragt sich nur, wie hoch?
In der "guten alten Zeit" reichte mal ein einziges TS-Paket, denn da war der Frame-Type bereits im ersten TS-Paket einer Video-Payload bekannt. Irgendwann wurden es dann mal zwei TS-Pakete, da das ganze h.264-Gedöns erstmal so viel Vorgeplänkel benötigte bevor es zum Wesentlichen kam. Dann wurden es 5, weil sich einzelne Audio-TS-Pakete zwischen erstem und zweitem Video-TS-Paket eingeschlichen hatten. Und jetzt reichen in Extremfällen selbst 10 schon nicht mehr!

MIN_TS_PACKETS_FOR_FRAME_DETECTOR bestimmt, wieviele TS-Pakete auf jeden Fall "am Stück" im Puffer sein müssen, damit der cFrameDetector seine Aufgabe erfüllen kann. Der Puffer in cRecorder ist 20MB groß, 10 TS-Pakete am Stück sind 1880 Byte, also im Vergleich zum gesamten Puffer sehr wenig. Von daher gesehen sollte es kein großes Problem sein, diesen Wert deutlich zu erhöhen, also vielleicht tatsächlich auf 100, das wären dann ca. 18KB, immer noch wenig im Vergleich zum gesamten Puffer.
Das "Kleinhalten" dieser Zahl dient aber auch dem Zweck, in cFrameDetector nicht unnötig weit in die P- und B-Frames "hineinzuschauen", denn das kostet ja alles Rechenaufwand. Da aber, so wie es aussieht, der Frame-Type durchaus in den ersten beiden Video-TS-Paketen gefunden wird, wäre es vielleicht eine Überlegung wert, hierfür einfach eine zweite Konstante zu benutzen, die entsprechend klein ist (z.B. 5, um auf der sicheren Seite zu sein). Es würden dann auf jeden Fall immer 100 TS-Pakete am Stück zur Verfügung stehen (was den Aufwand nur minimal erhöhen sollte, wenn überhaupt), davon würden aber nur maximal 5 Video-TS-Pakete untersucht werden. Im einfachsten Fall würden damit dann wie bisher einfach nur 5 TS-Pakete angeschaut. Es könnten aber bis zu 95 andere Pakete dazwischen eingestreut liegen, die einfach übersprungen werden.
Das wäre meiner Meinung nach ein brauchbarer Kompromiss.
Ich werde das mal so einbauen, inclusive einer Log-Meldung, wenn eines der Limits jemals erreicht werden sollte.

Oder hat jemand einen besseren Vorschlag?

Klaus

Was man tun soll?

Ein Hinweis an den WDR, das ihre Encoder - sagen wir besser nicht falsch, das kommt nicht so gut an sondern - suboptimal konfiguriert sind würde wahrscheinlich nichts bringen, selbst wenn das fachlich korrekt dargelegt wäre?

Klingt sinnig - zumindest wesentlich besser, als das Aufnahmeformat zu ändern.

Lars.

Zitat von urknall

Was man tun soll?

Ein Hinweis an den WDR, das ihre Encoder - sagen wir besser nicht falsch, das kommt nicht so gut an sondern - suboptimal konfiguriert sind würde wahrscheinlich nichts bringen, selbst wenn das fachlich korrekt dargelegt wäre?

Es sind ja auch noch andere Sender betroffen - leider...

Klaus

Ok, ich dachte das wäre quasi das schwarze Schaf, wenn andere den Standard auch verbiegen, muss natürlich eine Lösung auf Empfängerseite her.