erzeugter MPEG2 Transport Stream fängt nicht bei I-Frame an

[Breaker27]

Hallo,

ich habe einen Transport Stream mit MPEG2 Video aufgenommen (RTL DVB-S) mit DVBViewer und diesen durch ts doctor gejagt (ohne Schnitt, einfach ein "sauberes" ts File erzeugt).

1.) Das resultierende File erzeugte aber bei mkvmerge (MKVToolnix) folgende Warnmeldung:

Warnung: Einer oder mehrere B-Frames ohne zweites Referenzbild innerhalb der ersten Bildgruppe gefunden. Bitte diesen Fehler im MPEG2-Videostrom beheben und danach erneut versuchen, ihn zu muxen.


Sollte nicht ein von ts doctor erzeugtes ts File mit einem I-Frame beginnen? Meine Vorstellung wäre, dass ts Doctor so saubere, kompatible Files wie möglich erzeugt. D.h. es beginnt mit einem I-Frame (GOP-Anfang) und die Audiostöme werden bzgl. MPEG / AC3 Frames so geschnitten, dass sie (im Rahmen der Audioframe-Spielzeiten von 24 / 32ms) auch synchron starten.

Offenbar ist das nicht so. - Ist das so gewollt? Problem: Je nach Tool könnte das erste GOP übersprungen werden (weil nicht abspielbar) und dann im Folgenden zu nicht synchronem  Audio/Video führen.

2.) Außerdem meldet das log:
Start writing PID $006A at PTS: 20:15:53.814 aligned to video PID $00A3, remaining delay 8 ms
Start writing PID $0068 at PTS: 20:15:53.951 aligned to video PID $00A3, remaining delay 145 ms

Warum wird nicht der Audiostrom bzw. Videostrom entsprechend gekürzt, dass das Audiodelay +- maximal 32 ms (AC3) bzw. 24ms (MPEG1L2) ist? Es müssten die Audioströme mit Audioframes befüllt bzw. abgeschnitten werden. Das wäre doch möglich? Das Verhalten ist zwar nicht schlimm, da das Delay offenbar korrekt ist und man es in der Bearbeitungskette entsprechend berücksichtigen kann. Trotzdem nicht optimal...

Falls nötig bzw. nicht nachvollziehbar, kann ich entsprechendes ts File zur Verfügung stellen (ist aber reproduzierbar).

Ich verwende ts doctor 1.2.14 unter Win7x64.

[Cypheros]

Hi,

bei MPEG2 schneidet der TS-Doctor am I-Frame aber innerhalb Gop kommen nach dem I-Frame in der Regel zwei B-Frames, die zeitlich vor dem I-Frame liegen. Die beiden B-Frames werden angemäkelt, da diese B-Frames sich auf die vorherige Gop beziehen. Würde man versuchen die B-Frames zu löschen, stimmt die Gop nicht mehr und enthält zwei Frames zu wenig. Auch nicht perfekt.
Ist ein Kompromiß, wenn man den Stream nicht komplett remuxt, sondern den Stream möglichst unverändert lässt.

Du sprichst hier nicht von der normalen TS-Verarbeitung sondern vom TS-Demuxer/Remuxer. Hier ist dieser genauer Schnitt und Füllen von Audiolücken ist zur Zeit nur bei AC3 und E-AC3 verfügbar (Lipsync-Feature). Mpeg2-Audio ist aber in Vorbereitung.

[ErichV]

Sollte nicht ein von ts doctor erzeugtes ts File mit einem I-Frame beginnen? Meine Vorstellung wäre, dass ts Doctor so saubere, kompatible Files wie möglich erzeugt. D.h. es beginnt mit einem I-Frame (GOP-Anfang) und die Audiostöme werden bzgl. MPEG / AC3 Frames so geschnitten, dass sie (im Rahmen der Audioframe-Spielzeiten von 24 / 32ms) auch synchron starten.

Du könntest den Stream auch dahingehend Recodieren, dass er mit einem IDR-Frame (quasi mit einem speziellen I-Frame) beginnt. Alle Frames, die in der Kette hinter dem IDR-Frame liegen, aber zeitlich dem IDR-Frame vorauseilen, würden dann einfach ignorriert werden. Ich habe so etwas zwar noch nicht probiert, denke aber schon, dass dies möglich wäre.