I'm a programmer, and I'm using the libraries from FFmpeg (like avcodec*.dll). I'm not very deep into the libraries yet, but I was able to dump stream information (mainly timestamp information from all packets) and to decode and display video frames. Now, after searching the web up and down without succes, I'm asking here.
Within movie files, there can be multiple streams. Streams can have a time offset, for example to delay audio. My problem is that I do not find the location where this time offset is stored. I'm familiar with the AVStream structure. I expected to find time offset information there, but I'm obviously looking at the wrong place. The AVStream.start_time member is not what I'm looking for. So, where is the offset information stored? Or am I completely wrong and there is no such offset value? That would mean, there are only the timestamps (DTS and PTS) stored with each packet.
+ Reply to Thread
Results 1 to 10 of 10
Last edited by CryGuy; 24th Jan 2019 at 10:25.
EDIT: If there's an audio offset of 66 ms, and the start_time value for the audio track is AV_NOPTS_VALUE, it's obviously not the place where the offset is stored.
Last edited by CryGuy; 24th Jan 2019 at 17:02.
The track offset is not the offset of the first frame. For example, even if the PTS of the first audio frame is zero, the whole audio track might be shifted by a certain amount. That's what I'm looking for. The value of AVStream.start_time is just the timestamp of the first frame (and it's not set before the first frame has been read), but it is not the track offset.
From my experience when working with ffmpeg, offsets work like this:
start_time should match first decoded frame pts, or be undefined (in which case it means the file header does not support storing such info). But in some cases there is also start_time which is defined and is not first pts, because some frames are marked as discarded (removed by edit list or whatever). The logic here is unclear.
Audio stream may have decoding delay specific to codec (mp3, aac, have such delay). This delay should be already included in start_time if possible, I'm not sure.
Would be glad to know which software is 100% accurate in this and can be used as reference.
ADM probably shows some converted (aligned) timestamps in the user interface which are not directly present in ffmpeg api (IMO it is normal approach but I can't tell if it does this correctly anyway).
Ok, thanks fŁr your contribution. Appreciate it.
Here is one example:
Opened in ADM, it shows 0.146 for the first frame. As the PTS of the first video frame is 80 ms, and the PTS of the first audio frame is 14 ms, I did not understand why 0.146 is displayed for the first frame. I've asked, and the eplanation given was: "The elst says to advance audio by 66 ms relative to video beginning at 80 ms = 80+66 = 146 ms video delay." Independent from how ADM computes this value, I'd only like to understand where that 66 ms is coming from. I don't find it anywhere.
Last edited by CryGuy; 24th Jan 2019 at 18:55. Reason: typo
In this example I agree with you.
Video starts at 2000/25000 = 80ms
Audio starts at 672/48000 = 14ms
so audio is ahead of video by 66ms
I can imagine 3 ways to represent these numbers:
1) as is: v=80, a=14
2) align to video (vd way): v=0, a=-66
3) align to audio: v=66, a=0
"80+66" makes no sense to me. Do you have a link to post where this was explained? (If it was in forum).
Hi, thanks for looking into it. Now the value is so obvious. Really embarassing for me. Anyway, this is the answer to the question. Why ADM computes it this way, is more something for the ADM forum. As there was already a topic there, I shouldn't bother you here in addition with the same issue.
(ADM does not use negative values for timestamps, hence it has to shift all values to make them >=0. That's ok. In this sample video, there's neither a negative PTS nor DTS, so nothing needs to be shifted, and IMO, the first video frame could be displayed as (+)0.080 s. I do understand that it's not easy to decide which value to be displayed; even more as you can concatenate videos.)
I was asking (here at VideoHelp) not mainly because of ADM but because I needed to know whether there's such an offset per stream in order to make it work correctly in my own application. If there's no such offset but the difference of the first PTS, then I can consider this topic solved.
I learned something about mp4/mov structure from this question. You can view all the values yourself (without touching ffmpeg) with help of tools like mp4explorer.
"elst atom" for video reveals 80ms delay and for audio 14ms delay, everything the same as reported by ffmpeg.
The description quite clear: each of these times are relative to overall (movie) timeline, there is no reason to add them (there is no such thing as "relative to video").
Hope this helps to push a fix.
Agreeing. Thanks shekh for the support!