[FFmpeg-devel] [PATCH] lavf/mov: Add support for edit list parsing.

[wm4]

On Fri, 21 Oct 2016 16:59:14 +0100
Derek Buitenhuis <derek.buitenhuis at gmail.com> wrote:

> On 10/21/2016 4:32 PM, Derek Buitenhuis wrote:
> >     * Audio packets. Especially audio packets with a large number of samples.
> >       It's extremely likely that edits will not fall on packet boundaries, and
> >       depending on the number of samples per packet, audio sync issues can and
> >       will occur, even with smaller packets of e.g. 1024 samples, if there are
> >       a large number of entries in the edit list. Gradual loss of sync will
> >       occur.  
> 
> Apologies, I do see skip_samples is used, but it's unclear if it is correct
> or how to use it.
> 
> i.e. skip_samples is documented as:
> 
>     "Number of samples to skip at the start of the frame decoded from the next packet."
> 
> It's extremely vague, doesn't really say *when* to discard samples. After
> start? After a seek? Every packet? Does skip_samples get updated mid-demux?
> 
> I've been told it's after every reset (i.e. call to av_codec_flush), but the docs
> sure don't seem to say this...

In practice, it seems skip_samples is a counter that can affect all
decoded frames after it has been set. This can be by the user along
with a av_codec_flush call, or by a packet due to packet side data like
AV_PKT_DATA_SKIP_SAMPLES (or with the new edit list code, the discard
flag). I think logically, the side data sets skip_samples _before_ the
output of the corresponding packet is decoded, but _after_ the previous
packet is decoded.

Once skip_samples has reached 0, it has no effect on any decoded data
anymore.

(What annoys me here is that not all decoders do 1:1 packet in/out, but
may do arbitrary things like variable buffering of packets. All this
means that avctx->internal->pkt can be set to a random packet, while
this edit list logic requires that it's the "current" packet.)

> Also a friendly reminder that users may not be using libavcodec, but their own
> decoder.

Indeed, this would mean all those users have to replicate the hacks in
libavcodec/utils.c to get not garbage with libavformat-demuxed mp4s
containing edit lists.