[FFmpeg-devel] [PATCHv2 2/3] avformat/utils: increase detected start_time with skip_samples

[Marton Balint]

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
> inoffensive.
>
> 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.

Correct.

> 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 
well)

> 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.

Regards,
Marton