[FFmpeg-devel] [PATCH] flv set pts

Baptiste Coudurier baptiste.coudurier
Tue Sep 30 22:02:53 CEST 2008


Michael Niedermayer wrote:
> On Tue, Sep 30, 2008 at 12:00:59PM -0700, Baptiste Coudurier wrote:
>> Michael Niedermayer wrote:
>>> On Tue, Sep 30, 2008 at 11:28:45AM -0700, Baptiste Coudurier wrote:
>>>> Hi,
>>>>
>>>> Michael Niedermayer wrote:
>>>>> On Mon, Sep 29, 2008 at 07:56:17PM -0700, Baptiste Coudurier wrote:
>>>>>> Baptiste Coudurier wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> $subject.
>>>>>>>
>>>>>> Scratch old patch, this one should be correct.
>>>>> can you post some example input&output pts & dts values for some file
>>>>> with b frames.
>>>>> I suspicion would be that the patch is not completely correct but this
>>>>> should be more obvious from a list of timestamps and frame types.
>>>>>
>>>> Well, I didn't find any having < 0 cts yet, however it has been said
>>>> that cts is signed like in .mov, so code is assuming that.
>>>>
>>>> Files generated by FFmpeg does not have < 0 cts.
>>>>
>>>> Patch is doing the same as the .mov demuxer excepts that we cannot know
>>>> in advance while we can in .mov, though it misses has_b_frames = 1, I
>>>> can see, not harmful though.
>>>>
>>>> What do you think could be wrong ? I'll try to find a file in the mean time.
>>> Well
>>> if we take as example normal mpeg2 style IPB then
>>>         IPBBPBB
>>> dts:    0123456
>>> pts:    1423756
>>> would be correct
>>>
>>> now if dts where increased by one:
>>>
>>>         IPBBPBB
>>> dts:    1234567
>>> pts:    1423756
>>>
>>> then this would be wrong, and not only the ones for the B frames
>>> would be wrong but all would be. That is for example if the I frame
>>> is feeded at time 1 into the decoder then it will be output at time 2 not 1.
>>>
>> Humm of course yes, and in your situation, cts will be -1 for the third
>> frame to achieve dts 3 and pts 2, I don't see what you mean, the check
>> is indeed for cts < 0.
> 
> well, i think the demuxer would output:
> 
> dts:    12-----
> pts:    1423756
> 
> but this is wrong for the first 2 frames
> 

Yes, that is true, what can we do about that ?
It's sad not to set pts for correct files, what do you suggest ?

We can always unset dts also, I generated a faulty file manually:

[flv @ 0x8ec1220]cts 0 dts 0
[flv @ 0x8ec1220]av_read_packet stream=0, pts=0,
dts=-9223372036854775808, size=8918,  flags=1
IN delayed:0 pts:0, dts:-9223372036854775808 cur_dts:0 st:0 pc:(nil)
[flv @ 0x8ec1220]av_read_frame_internal stream=0, pts=0, dts=0,
size=8918, flags=1

Here we get dts wrongly as 0 though.

[h264 @ 0x8eca440]no picture
[flv @ 0x8ec1220]cts 80 dts 40
[flv @ 0x8ec1220]av_read_packet stream=0, pts=120,
dts=-9223372036854775808, size=6223,  flags=0
IN delayed:0 pts:120, dts:-9223372036854775808 cur_dts:0 st:0 pc:(nil)
[flv @ 0x8ec1220]av_read_frame_internal stream=0, pts=120,
dts=-9223372036854775808, size=6223, flags=0

Here we get no value which is ok.

[flv @ 0x8ec1220]cts -40 dts 80
[flv @ 0x8ec1220]av_read_packet stream=0, pts=40,
dts=-9223372036854775808, size=3685,  flags=0
IN delayed:0 pts:40, dts:-9223372036854775808 cur_dts:0 st:0 pc:(nil)
[flv @ 0x8ec1220]av_read_frame_internal stream=0, pts=40, dts=40,
size=3685, flags=0

This frame has correct timestamps.

We cannot know that there are b frames before encoutering the first
negative cts :/

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.                                http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA




More information about the ffmpeg-devel mailing list