[FFmpeg-devel] [PATCHv2 2/3] avformat/utils: increase detected start_time with skip_samples
cus at passwd.hu
Thu Mar 10 20:34:57 CET 2016
On Thu, 10 Mar 2016, wm4 wrote:
> On Wed, 9 Mar 2016 23:02:14 +0100 (CET)
> Marton Balint <cus at passwd.hu> wrote:
> Anyway, with just an audio track, adjusting start_time is rather
> If there's a video track, it becomes complicated. The audio packets
> (after applying delay skipping) will not start at 0 (even if you adjust
> AVStream.start_time, obviously). So something else needs to make sure
> that they either start at 0, or the video track needs to be offset by
> the audio delay.
> So I would have thought that the edit list actually changes the audio
> track so that the the audio track starts exactly at time 0 after
> skipping the padding (presumably the video starts at time 0). This
> would mean mov.c actually has to adjust the audio packet timestamps so
> that the first audio packet PTS is negative (-padding). After skipping
> padding, the first sample would have timestamp 0.
> This also means the AVFormatContext.start_time should be 0 or unknown,
> instead of e.g. the raw audio packet's negative PTS.
Yes, and that will be the case after applying the third patch in the
series which will set skipped_samples based on the edit list in MOV. (It
is only enabled for AAC, but it might make sense for other audio codecs as
> The delay field is in samples. Some demuxers are using it for this
> purpose (matroskadec and oggparseopus.c come to mind).
Yes, sorry, I missed that in the docs.
> Yes, the common code and ffmpeg.c oddly ignores this, but API users can
> use it to handle preskip correctly with these formats.
So when somebody does the transition to skipped_samples in those demuxers
he must set the delay to 0, that way the code of the API users should
not break too much. Obviously not perfect, but I don't see a better way.
More information about the ffmpeg-devel