[FFmpeg-devel] [PATCH]Save properties of the decoded stream

[wm4]

On Thu, 16 Jul 2015 15:33:31 +0200
Michael Niedermayer <michael at niedermayer.cc> wrote:

> On Thu, Jul 16, 2015 at 12:54:24PM +0200, wm4 wrote:
> [...]
> > > diff --git a/libavcodec/webp.c b/libavcodec/webp.c
> > > index 723a847..8caa6a2 100644
> > > --- a/libavcodec/webp.c
> > > +++ b/libavcodec/webp.c
> > > @@ -1417,6 +1417,7 @@ static int webp_decode_frame(AVCodecContext *avctx, void *data, int *got_frame,
> > >                                                  chunk_size, 0);
> > >                  if (ret < 0)
> > >                      return ret;
> > > +                avctx->properties |= FF_CODEC_PROPERTY_LOSSLESS;
> > >              }
> > >              bytestream2_skip(&gb, chunk_size);
> > >              break;
> > 
> > The lossless mode can apparently change mid-stream, so it should NOT be
> > an AVCodecContext field. Use per-frame side-data instead.
> 
> "everything" can change mid stream, this field is not about if a frame

Which is why the current bloated AVCodecContext approach is wrong.

> is lossless or even if the whole file is guranteed to be lossless
> (for such gurantee the whole file would need to be parsed which is
>  not practical for gathering some secondary bit of information about a
>  stream)
> 
> This field is simply to indicate if a stream appears to be lossless
> based on parsing headers or the first keyframe.
> So it is a property of the stream or decoder instance, similar to
> the width, height, format, sample rate, bit rate, ... fields in
> AVCodecContext are properties of a stream or codec instance even
> though they too could and do change per frame.

So it exists for ffprobe? If ffprobe (or similar things) want to gather
information based on the first frame, they should just decode the first
frame, instead of requiring tons of fragile magic in libavformat.

In any case, adding even more rarely set fields to an already big
struct doesn't sound like a very good idea to me. With side-data at
least there's a certain discoverability and orderliness. It gets
obscure stuff out of the way.

> 
> What could be done, and maybe thats what you meant is to use side data
> or IMHO better a flag or specific quality value of the existing
> quality field from AVFrame, to communicate the lossless nature
> of a frame. That per frame information could then be used by the core
> to set the per stream information aka  avctx->properties
> this is more complex but would make the per frame lossless-ness
> information available to user applications
> 
> [...]