id	summary	reporter	owner	description	type	status	priority	component	version	resolution	keywords	cc	blockedby	blocking	reproduced	analyzed
500	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.
"	enhancement	open	normal	avformat	git-master						0	0