[Ffmpeg-devel] Possible bug in reading PTS/DTS
Tue Apr 24 03:47:21 CEST 2007
Michel Bardiaux wrote:
> M?ns Rullg?rd wrote:
>> Michel Bardiaux wrote:
>>> Luca Abeni wrote:
>>>> Hi Michel,
>>>> Michel Bardiaux wrote:
and the B-frames will have
>> DTS = PTS, like this:
> This is one of the clearest explanations I have seen so far. Top is PTS,
> right? Bottom is DTS, line 2 is sequence in stream order (input to
I think the top is DTS, where we should have the P frame to decode
following B frame.
> codec), line 3 is sequence in presentation order (output from codec).
> Correct? One sees clearly the codec delay, and why a 'fake' DTS is
> needed on the first packet, and how things work whatever the GOP
> structure (if one decodes the whole GOP sequentially, that is; grokking
> the minimal sequence of decoding to reach a particular frame is still
> completely nonobvious to me)
> But I have just tried to adapt that graph to encoding, and no cigar
> there. Could you...?
>>> I'm afraid there is something
>>> very wrong in the MPEG muxer. But we have 3 different issues here: what
>>> an 'idal' MPEG should contain as timestamps; how the demuxer should
>>> react when encoutering the one unavoidable timestamp discontinity in an
>>> otherwise 'ideal' MPEG; and how to react to all other anomalies.
>> There is the additional question of what to do when the application passes
>> invalid timestamps to the muxer. Complain and/or simply output them to the
>> file anyway?
More information about the ffmpeg-devel