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)
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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
