[HDe] Fehlersuche MKV Wiedergabe

Anscheinend läuft bei der MKV-Wiedergabe die Übergabe des Bilds und des Tons an die HDe auseinander, wird diese Differenz zu groß, kommt es zu den bekannten Standbildern bzw. Framedrops.

Ich habe dazu folgenden Log-Auszug angefertigt, wo dies recht gut zu sehen ist.

Audio PTS 315946
Audio PTS 318826
Video PTS 287146
Audio PTS 321706
Video PTS 279946
Audio PTS 324586
Video PTS 272746




Video PTS 5377546
Audio PTS 5425066
Video PTS 5388346
Audio PTS 5427946
Audio PTS 5430826
Video PTS 5384746
Audio PTS 5433706
Video PTS 5399146
Audio PTS 5436586




Video PTS 8520346
Audio PTS 8961706
Audio PTS 8964586
Video PTS 8523946
Audio PTS 8967466
Audio PTS 8970346
Video PTS 8527546




Sprung 1 Minute nach vorne


Audio PTS 4721089
Video PTS 4670689
Audio PTS 4723969
Video PTS 4692289
Audio PTS 4726849
Video PTS 4685089
Audio PTS 4729729
Video PTS 4677889
Audio PTS 4732609
Audio PTS 4735489
Video PTS 4681489
Audio PTS 4738369
Video PTS 4688689
Audio PTS 4741249

Die Differenzen zwischen Audio und Video PTS:
erster Block 31680
zweiter Block 47520
dritter Block 442800
vierter Block 50400

Wie man sieht laufen Audio und Video PTS immer weiter auseinander, nachdem man 1 Minute nach vorne springt ist die Differenz wieder geringer.

Ich habe gerade noch etwas sehr interessantes gefunden.

Zitat

Wenn du im mkv bei der Audiospur stretch und delay benutzt, dann bleibt die Audiospur unverändert. Es wird nur beim muxen die Info über stretch und delay für die Abspielprogramme gespeichert.
Sprich: der Videoplayer führt es dann in Echtzeit bei der Wiedergabe aus.

Wenn jetzt mkv2vob den mkv demuxt, dann erhält er natürlich auch nur die unveränderte Audiospur und sie bleibt asynchron.

Du musst also mit einem Audiotool (z.B. Belight oder AC3machine) stretch und delay bei der Audiospur selber ändern BEVOR du es mit dem Video zum mkv muxt (wo du dann ja nichts mehr eingeben musst bei stretch und delay).

Das könnte auch erklären, warum manche MKV einwandfrei laufen und einige Störungen haben.

Kennt jemand etwas womit man prüfen kann, ob ein MKV einen Audio Delay oder Stretch hat?

Auszug xine Matroska Demuxer:

#define MATROSKA_ID_TR_TIMECODESCALE              0x23314F

case MATROSKA_ID_TR_UID:
      case MATROSKA_ID_TR_FLAGENABLED:
      case MATROSKA_ID_TR_FLAGLACING:
      case MATROSKA_ID_TR_MINCACHE:
      case MATROSKA_ID_TR_MAXCACHE:
      case MATROSKA_ID_TR_TIMECODESCALE:
      case MATROSKA_ID_TR_NAME:
      case MATROSKA_ID_TR_CODECNAME:
      case MATROSKA_ID_TR_CODECSETTINGS:
      case MATROSKA_ID_TR_CODECINFOURL:
      case MATROSKA_ID_TR_CODECDOWNLOADURL:
      case MATROSKA_ID_TR_CODECDECODEALL:
      case MATROSKA_ID_TR_OVERLAY:
      default:
        lprintf("Unhandled ID: 0x%x\n", elem.id);
        if (!ebml_skip(ebml, &elem)) {
          return 0;
        }

Auszug Matroska Spezifikation (komplett unter http://www.matroska.org/techni…tml#simpleblock_structure )

Zitat

TrackTimecodeScale 3 [23][31][4F] * - > 0 1.0 float The scale to apply on this track to work at normal speed in relation with other tracks (mostly used to adjust video speed when the audio length differs).

Also wird der Timecodescale welcher für die Geschwindigkeit des Audio-Tracks zuständig ist vom xine-mkv-demuxer nicht unterstützt/ausgewertet.

Ich hab zu testzwecken auch gerade mal ein MKV bearbeitet indem ich es demuxxt habe, die Tonspur mit eac3to angepasst habe auf die FPS des Bildes und danach wieder zurück in MKV gemuxxt. Damit Bild und Ton zueinanderpassen und definitiv kein TrackTimescale benutzt wird.
Ich gucke das KMV gerade über die HDe ,es läuft bis jetzt 5 Minuten OHNE Hänger oder Artefakte im Bild.
Ich werde es jetzt noch bis zum Ende durchgucken und wieder berichten ob die bekannten Probleme auftreten oder nicht.

Das MKV ist jetzt zuende. Über die komplette Spielzeit gab es keine Störungen der Wiedergabe.

Also Problem gefunden, zur Lösung müsste der TrackTimecodeScale im Matroska-Demuxer ausgewertet und der entsprechende Track dementsprechend angepasst werden.

Ich probiere mich mal daran, versprechen kann ich aber nichts.

Edit: Hmm, Timecodescale ist bei meinem MKV auf 1.0 also wird darüber nicht der Audiotrack angepasst. Über irgendwas muss er aber bei der MKV-Wiedergabe angepasst werden, muxe ich die Streams unverändert von MKV zu TS ist das Audio beim abspielen komplett asynchron. Die Laufzeit der einzelnen Streams ist nachdem demux auch anders. Die zeiten hab ich mit mediainfo ausgelesen.

Ich habe gerade an verschiedenen Stellen im mkv-demuxer versucht das Video dynamisch und auch fest auf die FPS des Audios einzustellen. Irgendwie hat alles nicht so geklappt wie es sollte. Audio FPS auf die Video FPS gesetzt ergab zwar gute Bildwiedergabe (soweit wie ichs laufen gelassen hab). Der Ton war aber kein bischen mehr synchron. Das ist das gleiche Verhalten, welches Auftritt, wenn man die einzelnen Streams des MKV demuxxt und danach zu einem TS muxxt.

Mir ist aufgefallen das der hdplayer immer 23.98 FPS konfiguriert, er sollte bei meinem Testfile aber auf 25FPS setzen (Das Video hat 23.98FPS der Ton 25FPS).
Macht der Demuxer eventuell alles richtig mit dem anpassen der Videogeschwindigkeit, bis auf das dann noch erforderliche abändern der Framerate?

Kann mir jemand sagen an welcher Stelle der Demuxer die Framerate weitergibt?
Oder holt sich die HDe die Framerate selbst aus dem Videostream?

Wenn ich das richtig sehe, scheint es wirklich am hdplayer zu liegen.

Es wird immer die Framerate des Videos gesetz, wo der hdplayer diese genau hernimmt habe ich noch nicht nachgesehen. Dabei setzt er die Framerate immer auf die ursprüngliche des Videostreams (was ja ansich nicht verkehrt ist). Das Problem tritt bei MKV dann nur auf, da es dort erlaubt ist Streams mit verschiedenen Framerates in ein File zu packen. Im MKV selbst wird dies entweder über den schon angesprochenen TimeCodeScale oder alternativ über die Duration realisiert. Das mit der Duration scheint im xine-Demuxer auch zu passen.

Nur wird das vom hdplayer jetzt nicht mit der Duration wiedergegeben die xine aus dem MKV liest, sondern mit der die der Videostream normalerweise hat.

Das endet dann, wie man auch in meinen PTS Logs sehen kann, damit, dass die PTS von Audio und Video immer weiter auseinanderlaufen, bis es zwangsläufig zu einem resync kommen muss. Ist ja auch klar xine liefert den Video-Stream für z.B. 25FPS, der hdplayer gibt aber nur 23,98 FPS aus.

Kann man dem hdplayer zu testzwecken irgendwo eine FPS aufzwingen?

Der Patch ist fertig zum testen.

Erstmal vielen Dank an Wade, der mir einige Hinweise geben konnte, wie dort was läuft.

Das Problem lag letzendlich im xine-hde, dort wird eine selbsterechnete Framerate genutzt, die natürlich nicht passt, wenn das Video gestreckt werden muss.
Es kann sein, dass durch die Änderungen andere Demuxer, sprich Formate, probleme machen können. Nämlich genau dann, wenn die Framerate von diesen nicht korrekt übergeben werden kann.

Wenn ihr den Patch testet und es MKV gibt die nicht vernünftig laufen testet bitte ob der Stream z.B. im TS-Container vernünftig läuft. So können wir sehen obs noch weitere Probleme mit MKV gibt, oder ob schlicht und einfach der Stream ansich Schuld ist.

Wie komet schon festgestellt hat, viele die vorher nicht gingen laufen jetzt perfekt oder mit nur geringen Störungen.
Andere hingegen haben weiterhin Probleme mit Hängern.
Ich hab mir wieder eins der MKVs vorgenommen, welches immer noch Probleme beim abspielen hat.

Wie die Logs zeigen liefert der Matroska-Demuxer, keine gravierenden Unterschiede mehr zwischen Audio und Video PTS.

Edit: Mal ne möglicherweise dumme Vermutung
Mir ist aufgefallen, das es hauptsächlich bei Material mit niedrigerer Bitrate auftritt. Ich habe hier z.B. ein File mit 13,5 Mbps und eins mit 4 296 Kbps.
Ist es möglich das immer weiter der Buffer gefüllt wird, da von xine solange immer mehr Daten angefordert werden bis ein Abspielbuffer voll ist und bei der geringen Bitrate xine dann irgendwann merkt das er viel zuweit vorne ist und dann die Drops verursacht?
Die "video out:" Meldungen werden von xine selbst verursacht, das seeking durch die HDe. Das seeking... kommt auch immer einen guten Moment später wenn man das Log Live verfolgt.
Außerdem läuft es auf dem TV, bei dem File mit geringer Datenrate, noch kurze zeit weiter wenn man den VDR killt.

maniac: track_num 1, pts 4723200, timecode_diff: 0, flags: 0x0 duration: 3600
maniac: track_num 1, pts 4734000, timecode_diff: 120, flags: 0x0 duration: 3600
maniac: track_num 1, pts 4730400, timecode_diff: 80, flags: 0x0 duration: 3600
maniac: track_num 1, pts 4741200, timecode_diff: 200, flags: 0x0 duration: 3600
maniac: track_num 1, pts 4737600, timecode_diff: 160, flags: 0x0 duration: 3600
maniac: track_num 1, pts 4748400, timecode_diff: 280, flags: 0x0 duration: 3600
maniac: track_num 1, pts 4744800, timecode_diff: 240, flags: 0x0 duration: 3600
maniac: track_num 3, pts 4749120, timecode_diff: 288, flags: 0x4 duration: 2880
maniac: track_num 2, pts 4749120, timecode_diff: 288, flags: 0x4 duration: 2880
maniac: track_num 1, pts 4755600, timecode_diff: 360, flags: 0x0 duration: 3600
maniac: track_num 1, pts 4752000, timecode_diff: 320, flags: 0x0 duration: 3600
maniac: track_num 1, pts 4762800, timecode_diff: 440, flags: 0x0 duration: 3600
maniac: track_num 1, pts 4759200, timecode_diff: 400, flags: 0x0 duration: 3600
maniac: track_num 1, pts 4770000, timecode_diff: 520, flags: 0x0 duration: 3600
maniac: track_num 1, pts 4766400, timecode_diff: 480, flags: 0x0 duration: 3600
.
.
.
maniac: track_num 1, pts 5137200, timecode_diff: 560, flags: 0x0 duration: 3600
maniac: track_num 1, pts 5148000, timecode_diff: 680, flags: 0x0 duration: 3600
maniac: track_num 1, pts 5144400, timecode_diff: 640, flags: 0x0 duration: 3600
maniac: track_num 3, pts 5158080, timecode_diff: 792, flags: 0x4 duration: 2880
video_out: Verwerfe Bild mit pts 4735500, weil es zu alt ist (Unterschied: 360520).
video_out: Verwerfe Bild mit pts 4739104, weil es zu alt ist (Unterschied: 356916).
video_out: Verwerfe Bild mit pts 4742708, weil es zu alt ist (Unterschied: 353312).
video_out: Verwerfe Bild mit pts 4746312, weil es zu alt ist (Unterschied: 349708).
video_out: Verwerfe Bild mit pts 4749916, weil es zu alt ist (Unterschied: 346104).
video_out: Verwerfe Bild mit pts 4753520, weil es zu alt ist (Unterschied: 342500).
video_out: Verwerfe Bild mit pts 4757123, weil es zu alt ist (Unterschied: 338897).
video_out: Verwerfe Bild mit pts 4760726, weil es zu alt ist (Unterschied: 335294).
video_out: Verwerfe Bild mit pts 4764329, weil es zu alt ist (Unterschied: 331691).
video_out: Verwerfe Bild mit pts 4767932, weil es zu alt ist (Unterschied: 328088).
video_out: Verwerfe Bild mit pts 4771535, weil es zu alt ist (Unterschied: 324485).
video_out: Verwerfe Bild mit pts 4775138, weil es zu alt ist (Unterschied: 320882).
video_out: Verwerfe Bild mit pts 4778741, weil es zu alt ist (Unterschied: 317279).
seeking to 0x49152e due to last_skip = 176 (145635 0)
hde-vd: (hde_decode_data:377) skip=176 (0/0)
hde-vd: (hde_decode_data:377) skip=0 (1/0)
video_out: Verwerfe Bild mit pts 4782344, weil es zu alt ist (Unterschied: 29488).
video_out: Verwerfe Bild mit pts 4785947, weil es zu alt ist (Unterschied: 25885).
video_out: Verwerfe Bild mit pts 4789550, weil es zu alt ist (Unterschied: 22282).
video_out: Verwerfe Bild mit pts 4796756, weil es zu alt ist (Unterschied: 15076).
video_out: Verwerfe Bild mit pts 4800358, weil es zu alt ist (Unterschied: 11474).
video_out: Verwerfe Bild mit pts 4803960, weil es zu alt ist (Unterschied: 7872).
video_out: Verwerfe Bild mit pts 4807562, weil es zu alt ist (Unterschied: 4270).
maniac: track_num 2, pts 5158080, timecode_diff: 792, flags: 0x4 duration: 2880
maniac: track_num 1, pts 5158800, timecode_diff: 800, flags: 0x0 duration: 3600

Bei Szenen die eine höhrere Datenrate besitzen als der Durchschnitt kommt es auch zu Artefakten. Das kann man mit einem Workaround beheben. Und zwar schaltet man den Framedrop von xine ab. Weiterer Nebeneffekt auch Dateien mit einer Bitrate von 30Mbps laufen nun in einer guckbaren Art und Weise. Dort treten dann zwar öfter kleinere Drops seitens der HDe auf, diese äussern sich dann aber nurnoch durch sehr kleine Microruckler.

In xine muss dafür die Datei src/xine-engine/video_out.c gepatched werden. Bei xine-lib-1.1.16.2 muss dafür in Zeile 834 ein
diff = 0;
eingefügt werden. Bei anderen xine Versionen kann die Zeile abweichen.

Die Stelle sollte danach ungefähr so aussehen

pts = img->vpts;
    diff = cur_vpts - pts;
    diff = 0;

    if (diff > duration || this->discard_frames) {

Mir ist gerade aufgefallen, das wenn die Daten an die HDe übergeben werden (xine-hde/hde_io.c Funktion hde_io_video_frame) öfter ein Byte fehlt. Dieses Byte ist verglichen zum Original-Stream immer 0x00. Wahrscheinlich ist das irgendwo in einem Header.

Ich vermute, das das aber schon in demux_matroska.c der xine-lib selbst passiert, dort hab ich aber noch nicht die Stelle finden können, wo ich die Daten zur Kontrolle abgreifen kann.

Kennt sich jemand gut genug mit dem Code in demux_matroska.c aus der mal gucken könnte wo dieses Byte immer verloren geht und ggf. fixen?

Das fehlende Byte ansich ist nicht kritisch.
Fügt man dort aber mehr 0x00 Bytes ein, schiebt man das auftreten der Ströung immer weiter nach hinten.

Das würde wieder zu der niedrigeren Datenrate als Problem führen.