Opened 4 years ago

Last modified 4 years ago

#1759 new defect

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 4 years ago.
without patch.txt (78.2 KB) - added by nikola.vranic 4 years ago.
with patch.txt (78.2 KB) - added by nikola.vranic 4 years ago.
patch.diff (1.1 KB) - added by nikola.vranic 4 years ago.

Download all attachments as: .zip

Change History (7)

Changed 4 years ago by nikola.vranic

comment:1 Changed 4 years ago by cehoyos

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 Changed 4 years ago by 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.

Changed 4 years ago by nikola.vranic

Changed 4 years ago by nikola.vranic

Changed 4 years ago by nikola.vranic

comment:3 Changed 4 years ago by DonMoir

  • 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 in account the first_dts.

Version 0, edited 4 years ago by DonMoir (next)
Note: See TracTickets for help on using tickets.