On Thu, 10 Mar 2016 20:34:57 +0100 (CET) Marton Balint <c...@passwd.hu> wrote:
> On Thu, 10 Mar 2016, wm4 wrote: > > > On Wed, 9 Mar 2016 23:02:14 +0100 (CET) > > Marton Balint <c...@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). _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
