Bad video DTS value

[Nikola Vranic]

Summary of the bug:
First video packet DTS has wrong value, value which is lower then 0. This can be problem when seeking to 0.

How to reproduce:

% ffprobe -show_packets mpeg2.mov

[PACKET]
codec_type=video
stream_index=0
pts=-1
pts_time=-0.041667
dts=-1
dts_time=-0.041667
duration=1
duration_time=0.041667
convergence_duration=N/A
convergence_duration_time=N/A
size=32992
pos=36
flags=K
[/PACKET]
...
ffmpeg version: latest git master source
built on: Ubuntu 10.04

[Carl Eugen Hoyos]

The output of ffprobe -show_packets mpeg2.mov looks different here, are you sure your version of FFmpeg is unpatched? Consider adding the output of ffmpeg -i mpeg2.mov

Could you explain what kind of problem you experience? Seeking works fine here for the attached sample.

[Nikola Vranic]

Ohh sorry, I forget to remove some patch.

Well when I use ffmpeg library in my application and when I want to seek to position 0 I don't got first frame of the stream because it's DST is -1. Instead I got some other frame. I suggest patch which you can find in attachment. I will also put how looks packets with and without patch. With this patch I can seek to position 0 and because of that I think that this is a bug in ffmpeg library.

[DonMoir]

It's not unusual for first packet dts to be non-zero in a variety of formats.

you can use AVStream.first_dts as an offset which in the case of the mpeg2.mov is also -1.

So in this case if your desired seekTime is zero (not accounting for time_base here) it would be seekTime + AVStream.first_dts and result is -1.

As long as the first_dts is consistent with the packet dts then all is good. The first_dts of the stream must always represent the first packet dts.

It would be a mistake to make some modification to packet dts without taking into account the first_dts.

I have no problem with seeking to zero (dead on) on above file and DO take into account the first_dts.

[Elon Musk]

I see nowhere proof that DTS -1 is against specification of format.