Time stamp issue #2

[CryGuy]

Hi,

I've already added this issue to a previous topic, better I'd better start a new one.

Here's the video I'm referring to: ("Video and audio.mp4")
https://mega.nz/#!W4RhSITR!BM07L8Cgt9qXzFOLyt40slTLdI4NF_FZ3T9exMevebk

First video PTS=80 ms, first audio PTS=14 ms; there are no negative timestamps.
My question: Why does ADM show 0.146 for the first frame? In the previous thread I was told, that there is an audio offset of 66 ms, and as 80+66=146, this value is shown. This does not make sense to me. 80 is already the result of 14+66, so I don't know why 66 is added a second time. Am I wrong?

[eumagga0x2a]

You post in the previous topic was not ignored, just too much other stuff to do.

The reasoning is as follows: 80 ms is the difference between PTS and DTS of the first frame with DTS starting at zero. Additionally, a delay of 80 ms is specified in the edit list for the video track. But as the delay for the audio track is not equal zero, the delay reduces from 160 ms to 160 - 14 = 146 ms. So the question is whether the empty edit (mediaTime:-1) at the start of the video track is relative to PTS start or relative to DTS start.

[CryGuy]

I didn't think it was ignored, I only thought it was better to start a new topic as the other thread contains also other examples, which might be too confusing to follow.

I can't follow "80 ms is specified in the edit list for the video track". There is no additional delay. The video track starts at 80 ms, the audio track at 14 ms, and there are no negative PTS (and DTS) value, so nothing needs to be added or shifted or anything.

[eumagga0x2a]

You assume that the ELST delay is relative to already included in PTS, so that the effective additional delay = ELST delay - first frame PTS = 0 in this case. Avidemux assumes that the ELST delay is relative applies also to DTS, so that the effective first frame DTS is 0 + 80 = 80 ms and the first frame PTS is 80 + 80 = 160. Please point to specs which say otherwise, it would be very important to correct this behaviour if the assumption is wrong.

[CryGuy]

From one of your previous posts, I assumed there is an ELST delay. I just did not finding anything that confirms that an (additional) ELST delay exists at all. There are just the PTS/DST values per frame, and that's it. I'm utilizing the FFmpeg/libav libraries, and I was not able to retrieve any delay wherever I looked. So I've asked in a general (not ADM related) forum:

https://forum.videohelp.com/threads/391977-How-to-retrieve-stream-offsets

I don't say I'm right, it's just that I can't see your assumption confirmed.

Thanks.

EDIT: The AVStream.start_time value for each stream is just the value of the first PTS, so if that is the delay you're referring to, you would just double the start_time if you take start_time + PTS of first frame.

[eumagga0x2a]

mediaTime is the key. The ELST delay is 80 ms, but the mediaTime of the second edit is 2000 in track scale = 80 in movie timescale, i.e. both values cancel each other.

At the same time CTTS specifies 2000 offset for the very first entry and as the spec states that DT (confusingly explained as "display time" in the STTS section while it is such only when no CTTS atom is present and otherwise it is "decode time" and also used in this context below in the following section dedicated to the CTTS atom) starts at zero, the final PTS value of the first frame is 80 ticks in movie timescale = 80 ms.

Another potential problem: Avidemux assumes all CTTS entries being non-negative, while the spec explicitely points out that "The delta expressed in the composition offset table can be positive or negative".

Thank you for your persistence.

[CryGuy]

I know too little about the native mp4 format. I've just used mp4box to dump some information. This includes edit list entries, so now I know what you're referring to. I can't evaluate this. I was only relying on the information from ffmpeg.

You'll know best if ADM needs to be modified. In any case, thanks for your time.