How to compute time stamp from frame number using .idx2

[gamez]

Hi eumagga0x2a

I am working on an app to "drive" avidemux using its .py language interface.

In order to make use of adm.addSegment(), timestamps (and segment lengths as the difference between timestamps) must be computed absolutely precisely, or otherwise avidemux will fail later on with a seek error when processing the script. There is no tolerance to seek to the "nearest" frame if a provided timestamp does not actually exist in the source video file.

Since I can find a list of all video (key-)frames together with their respective timestamps in the .idx2 index file (lines with Video and pts values), together with information about the "dependant" frames right before and after the key frame, I was hoping there might be a formula or algorithm to compute the exact timestamp for a given frame number N?

I would very much appreciate to understand how this could be accomplished.

Best regards

g.

[eumagga0x2a]

Don't rely on anything in idx2. All timestamps and pretty much everything else can be modified if plausibility checks in editor suggest so. Always load the video first (a new segment is created automatically), then examine what you've got.

[gamez]

It would already help a lot to understand the meaning of one row of Video information in idx2.

I figure
at: physical hex offset in file
Pts: "span" of time covered by this key frame, and reference point for the following dependant frames
nn:aaaaa:bbbbb:ccccc
- nn: type of dependant frame (IS/BS/PS)
- other fields not clear, probably a mix of byte offsets in the file and/or timing offsets with respect to the key frame

A better understanding of the fields would help to at least make a test, enumerate the key frames in idx2 and compute time stamps for all the frames

Thank you!

g.

[eumagga0x2a]

at: physical hex offset in file

Yes, the physical offset of the start of the corresponding PES packet. For example, the following line represents a GOP:

Code Select Expand

Video at:0007d70c:0019 Pts:905647831:905638831  DF:03fc17:0:0 BF:001a55:-3600:1800 BF:00098a:-5400:-1 BF:0006d5:-1800:5400 PF:005129:7200:7200 BF:00171d:3600:9000 BF:00020e:1800:-1 BF:000675:5400:12600 PF:003c5d:14400:14400 BF:000df9:10800:16200 BF:000102:9000:-1 BF:000585:12600:19800 PF:004f15:21600:21600 BF:000f85:18000:23400 BF:000132:16200:-1 BF:000485:19800:27000 PF:0034dd:28800:28800 BF:001075:25200:30600 BF:00015e:23400:-1 BF:00048d:27000:34200 PF:0043ad:36000:36000 BF:001389:32400:37800 BF:00015e:30600:-1 BF:000725:34200:41400 PF:004171:43200:43200 BF:000d65:39600:45000 BF:000136:37800:-1 BF:000699:41400:48600 PF:005825:50400:50400 BF:000c01:46800:52200 BF:000172:45000:-1 BF:00067d:48600:55800
The PES packet starts at position 0x7d70c, the startcode of the first keyframe begins at offset 19 (i.e. 0x7d70c + 0x13 = 0x7d71f). All timing info is expressed in MPEG ticks (90kHz timescale): PTS associated with this PES packet is 905647831, DTS: 905638831 (I call these fields PTS start and DTS start respectively).

This is followed by entries to individual frames (which can be fields if the video is field-encoded).

Two letters represent frame type and field structure. "D" means we can directly seek to this frame. Avidemux conflates IDR and recovery frames here, both are marked as "D" (the comment in ADM_tsIndexH264.cpp:540 is misleading). "F" means it is a (progressive) frame.

Later you see "P", which marks a P-frame, and "B" which marks a B-frame. "I" means an intra-coded frame, but not necessarily a keyframe. Avidemux usually remaps "I" to P-frame. Please see ADM_tsIndex.h for info regarding field structure.

Frame type and field structure info is followed by frame or field size as hex, PTS offset to the PTS start and DTS offset to the DTS start. "-1" means timestamp is unset.

I can only repeat the warning: don't use idx2 directly.