Seemingly inconsistent AVIndexEntry timestamps for movs starting with B-Frames

[rmk]

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.

[Michael Niedermayer]

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

[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?

[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.

[Michael Niedermayer]

Closing at the patch creators request