[Ffmpeg-devel] Possible bug in reading PTS/DTS

[Xiaohui Sun]

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:
>>
>> 0123456
>> IPBBPBBP
>>  IBBPBBP
>>  0231564
>>     
>
> 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?
>>
>>     
>
> Greetings,
>