Opened 12 years ago

Closed 3 years ago

#1759 closed defect (needs_more_info)

Bad video DTS value

Reported by: Nikola Vranic Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: DTS
Cc: donmoir@comcast.net Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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

Attachments (4)

mpeg2.mov (1.1 MB ) - added by Nikola Vranic 12 years ago.
without patch.txt (78.2 KB ) - added by Nikola Vranic 12 years ago.
with patch.txt (78.2 KB ) - added by Nikola Vranic 12 years ago.
patch.diff (1.1 KB ) - added by Nikola Vranic 12 years ago.

Download all attachments as: .zip

Change History (8)

by Nikola Vranic, 12 years ago

Attachment: mpeg2.mov added

comment:1 by Carl Eugen Hoyos, 12 years ago

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.

comment:2 by Nikola Vranic, 12 years ago

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.

by Nikola Vranic, 12 years ago

Attachment: without patch.txt added

by Nikola Vranic, 12 years ago

Attachment: with patch.txt added

by Nikola Vranic, 12 years ago

Attachment: patch.diff added

comment:3 by DonMoir, 12 years ago

Cc: donmoir@comcast.net added

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.

Last edited 12 years ago by DonMoir (previous) (diff)

comment:4 by Elon Musk, 3 years ago

Resolution: needs_more_info
Status: newclosed

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

Note: See TracTickets for help on using tickets.