Timestamp issues

[CryGuy]

Hi,

still fighting with timestamps. There are several issues, but I'm focusing on one case for now. Here are two short video files (5 seconds length each):

https://mega.nz/#!ilIDxS4Q!1zFHuqRuclacGSgfYyRT13hQ0II4y965nSnT9t-_tJs
https://mega.nz/#!W4RhSITR!BM07L8Cgt9qXzFOLyt40slTLdI4NF_FZ3T9exMevebk

The video tracks are identical, but one file also includes an audio track. The PTS of the first video frame is 2000. With a timebase of 1/25000, this is 0.080 s.
Question: When loading them in ADM, why does it correctly show 0.080 s for the file with a video track only, whereas it shows strange 0.146 s for the file that additionally includes an audio track?

BTW, the PTS of the first audio frame is 672. With a timebase of 1/48000, this is exactly 0.014 s. Even taking this into account, I can't reproduce the 0.146 s being displayed.

Thanks for clarification.

EDIT: ADM latest build (538 from 9/29/2018)

[eumagga0x2a]

For the file with an audio track, we calculate video delay as "video delay + (video delay - audio delay)" resulting exactly in the first frame PTS = 0.146 s, i.e. we advance audio by delaying video relative to the original video delay which can't be reduced because we have B-frames.

[CryGuy]

Thanks for your reply.

Probably we have a different understanding of which timestamp we expect to be displayed. I expect the video timestamp to be displayed because the user works based on video frames. Not more or less. If it's 0.08, I expect 0.08 to be displayed. It is the video frame time stamp and independent from any audio track and independent from the frame type (I, B, etc.)

So, I don't understand it, I can only accept it.

EDIT: I don't know which meaning 0.146 s has for the user. I don't see the sense of this computation. It's neither the timestamp from the opened file, nor it's the timestamp as it will be written to the output file when copying/encoding. It's an arbitrary value. But maybe I'm missing something, I don't know.

[CryGuy]

I have another video (40 mins and too long to upload). Smallest video PTS (an I-frame) is zero. Smallest audio PTS is zero. So I expect "0.0" to displayed when I open the video in ADM. However, it shows 2.081 s. Why??

I'm utilizing the libav library and dumping the values read from AVPacket->pts, but maybe it's returning wrong values.

[eumagga0x2a]

If the video is stored in a mp4 container and the A/V sync is clearly wrong, than you see probably the issue fixed by [demuxers/Mp4] Fix track delay calculation, media time is in track timescale units, not in movie timescale, no official nightlies have been built since then yet.

The timing displayed by Avidemux differs from the one shown by FFmpeg because Avidemux uses uint64_t for timestamps while ffmpeg uses int64_t (rounding errors from ticks to microseconds conversion nonwithstanding). This requires all timestamps to be shifted to avoid some timestamps going negative.

[CryGuy]

A/V sync is not wrong. I've once subscribed the RSS feed for Avidemux at Github and saw the change lately, but didn't closer to the date. So I'm gonna wait for the next build.

I understand that shifting is necessary to avoid negative values due to the unsinged data type, but in the sample files, there is no negative PTS (and no negative DTS), hence nothing needs to be shifted IMO. And I can't follow the way it's done.. but anyway I'll wait for the next build.
Thanks.

[eumagga0x2a]

I understand that shifting is necessary to avoid negative values due to the unsinged data type, but in the sample files, there is no negative PTS (and no negative DTS), hence nothing needs to be shifted IMO.

It would be necessary to have access to this sample then (the biggest sample video has been 7 GiB in size so far). At the very least, you could post the portion of admlog.txt related to parsing the container.

[CryGuy]

Samples already linked in my first post. See "Video and audio.mp4".

Dumped values see attachment.
There is no reason to show 0.146 for the first video frame. It is 0.08.

[CryGuy]

Another Sample:
https://mega.nz/#!T5YxRY7T!HhA15FX4mesntqiH4wN6uMd4dgoOufYqdA3X7Xxy4js

There are negative DTS values this time, but even if you shift all time stamps to fit into the uint64 range, I don't understand the value 2.081 s being displayed for the first frame. But as I said, if this might change in the next build, I'm gonna wait for it.

[eumagga0x2a]

With a build from the current git master, I get 160 ms as PTS of the first frame, with DTS = 80 ms as specified in the elst atom for the video track for "Another sample.mp4".

There is no reason to show 0.146 for the first video frame. It is 0.08.

The elst says to advance audio by 66 ms relative to video beginning at 80 ms = 80+66 = 146 ms video delay.

[CryGuy]

Thanks for looking into it.

The elst says to advance audio by 66 ms relative to video beginning at 80 ms = 80+66 = 146 ms video delay.

As the PTS of the first video frame is 0, the video beginning at 80 ms is due to shifting all values by +80 ms because of compensating the negative -80 ms DTS value, right?
I don't find the 66 ms for the audio stream. AVStream.start_time is 0. Probably I'm looking at the wrong place. However, I'm assuming it's correct what you say, so the 146 ms make sense now.
Thanks.

[eumagga0x2a]

Video begins at 80 ms because the elst says so, Avidemux doesn't mess with it.

In general, a transition to FFmpeg-like storage of timing info as a fraction is deemed highly desireable. It would require a lot of work however. Patches as always welcome.

[CryGuy]

Video begins at 80 ms because the elst says so, Avidemux doesn't mess with it.

Oh, ok. Would you mind letting me know where the value is read from?

In general, a transition to FFmpeg-like storage of timing info as a fraction is deemed highly desireable. It would require a lot of work however. Patches as always welcome.

OT: In VB, I could support you... (yes, obviously kidding). I could do C(++), but.... that's a different topic.


EDIT: I'm asking such questions because I need transparency. When there are issues, things need to be reproducable for me, but as I'm always confused about the values displayed, it's hard for me to pointpoint the cause of a behavior.

[CryGuy]

There is no reason to show 0.146 for the first video frame. It is 0.08.

The elst says to advance audio by 66 ms relative to video beginning at 80 ms = 80+66 = 146 ms video delay.

Hi, and sorry for bothering you again with this topic, but it's still not clear to me. (actually I think it's not correct)
I'm referring to "Video and audio.mp4" as already linked before:
https://mega.nz/#!W4RhSITR!BM07L8Cgt9qXzFOLyt40slTLdI4NF_FZ3T9exMevebk
(first video PTS=80, first audio PTS=14; there are no negative timestamps)

A while ago, I've asked where that 66 ms are stored. Now I see that it seems to be just the difference of the first PTSs of the two tracks, while there is no additional offset for the audio tack. If so, it does not make sense to me to compute 80+66 because 80 is already the result of 14+66. So I'm wondering why 66 are added to 80. It's not necessary IMO.