Opened 8 years ago

Closed 4 years ago

#500 closed enhancement (fixed)

Seemingly inconsistent AVIndexEntry timestamps for movs starting with B-Frames

Reported by: rmk Owned by:
Priority: normal Component: avformat
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

A while ago I asked on the ml regarding the semantics of the undocumented fields of AVIndexEntry defined in avformat.h (http://www.mail-archive.com/libav-user@ffmpeg.org/msg00535.html). I didn't get an answer so I still do not know what the correct behaviour is but I have observed things that at least appear inconsistent. I have two examples of MPEG-2 files in a mov container which both start with the sequence BBI (presentation order). One is the file that is attached to issue #479 that has the following properties:

Mesht0456_01_cut.MP4

AVStream.time_base = 1/30000
AVStream.start_time = 3003 (0.1001s)
start frame order = BBI
PTS of first I-Frame = 3003
PTS of first frame (B) = 0
first I-frame AVIndexEntry.timestamp = 0

Then another one (uploaded to http://www.datafilehost.com/download-27d635cc.html since I do not have a smaller sample):

xdcam_hd422_1080p24.mov

AVStream.time_base = 1/2400
AVStream.start_time = 200 (0.08333333333333334s)
start frame order = BBI
PTS of first I-Frame = 200
PTS of first frame (B) = 0
first I-frame AVIndexEntry.timestamp = -100 (-0.416666666666667s)

The first sample looks like AVIndexEntry.timestamp is set with the stream's start_time subtracted from the respective frame's PTS. This also works for all following index entries. However, this does not work for the second example. I have no idea if this is related to issue #479. All I'm trying to do is use the index (if it is there) to find out the PTSs of keyframes and I thought that was OK to do via AVIndexEntry. So either I am abusing the API and it would help to document this so others don't run into this or one of the files is broken or it is indeed a bug. In any case, just a short, unambiguous sentence of documentation for each AVIndexEntry field by someone who knows the semantics would help libav API users a great deal to use this and to help improve the seeking functionality of ffmpeg be it only by providing bug reports with samples.

One more observation is that in both cases the timestamp of the index entry corresponding to the first I frame matches the DTS of the packet containing the I-Frame. Is that the semantics of AVIndexEntry.timestamp? In that case how would one derive the PTS of the I-frame from the index entry? Any insight/help would be greatly appreciated.

Change History (4)

comment:1 Changed 7 years ago by michael

  • Component changed from undetermined to avformat
  • Status changed from new to open
  • Type changed from defect to enhancement
  • Version changed from unspecified to git-master

Well strictly speaking AVIndexEntry.timestamp is a demuxer internal variable and its meaning can differ between demuxers somewhat. Patches to make it more similar and usefull are of course welcome.
Ive also added some documentation for the field that ill push to git master in a moment.

I guess this makes this issue a feature request

comment:2 Changed 7 years ago by rmk

Thanks a lot for the clarification! Yes, that probably makes it a feature request.

Just to make sure I understand: Then, depending on the demuxer, the timestamp I pass to av_index_search_timestamp could also be whatever the demuxer implementor thought was most convenient, so I have to know that as an API user to use it/interprete the results correctly, right?

comment:3 Changed 6 years ago by rmk

It probably makes sense to close this. The original question was answered by Michael and on the list, i.e. depending on muxer the index entry can refer to DTS rather than PTS, which seems to be the case here and an enhancement request should probably be called something like "introduce API to seek by PTS" and be described differently.

comment:4 Changed 4 years ago by michael

  • Resolution set to fixed
  • Status changed from open to closed

Closing at the patch creators request

Note: See TracTickets for help on using tickets.