VideoHelp Forum
+ Reply to Thread
Results 1 to 10 of 10
Thread
  1. Member
    Join Date
    Jan 2012
    Location
    Germany, Bavaria
    Search Comp PM
    Hi,

    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.

    Thank you
    Last edited by CryGuy; 24th Jan 2019 at 11:25.
    Quote Quote  
  2. > The AVStream.start_time member is not what I'm looking for

    Why? Normally it is exactly what you want. Depends on file and stream format (afaik for example AVI never stores time offsets).
    Quote Quote  
  3. Member
    Join Date
    Jan 2012
    Location
    Germany, Bavaria
    Search Comp PM
    Originally Posted by shekh View Post
    > The AVStream.start_time member is not what I'm looking for

    Why? Normally it is exactly what you want. Depends on file and stream format (afaik for example AVI never stores time offsets).
    I'm using AviDemux. It shows time stamps that are not clear to me. I was asking, and I was told that the offset is taken into account. Hence I was looking for it. The start_time member does not contain the value.

    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 18:02.
    Quote Quote  
  4. Member
    Join Date
    Jan 2012
    Location
    Germany, Bavaria
    Search Comp PM
    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.
    Quote Quote  
  5. 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).
    Quote Quote  
  6. Member
    Join Date
    Jan 2012
    Location
    Germany, Bavaria
    Search Comp PM
    Ok, thanks für your contribution. Appreciate it.

    Here is one example:
    https://mega.nz/#!W4RhSITR!BM07L8Cgt9qXzFOLyt40slTLdI4NF_FZ3T9exMevebk

    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 19:55. Reason: typo
    Quote Quote  
  7. 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).
    Quote Quote  
  8. Member
    Join Date
    Jan 2012
    Location
    Germany, Bavaria
    Search Comp PM
    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.

    https://avidemux.org/smif/index.php/topic,18476.0.html#msg85002

    (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.
    Quote Quote  
  9. 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").
    https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html
    Hope this helps to push a fix.
    Quote Quote  
  10. Member
    Join Date
    Jan 2012
    Location
    Germany, Bavaria
    Search Comp PM
    Agreeing. Thanks shekh for the support!
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!