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

[wm4]

On Thu, 10 Mar 2016 20:34:57 +0100 (CET)
Marton Balint <cus at passwd.hu> wrote:

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

OK.

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

Yes. Unfortunately, delay is sometimes set by the decoder without
direct information from the demuxer (opus).