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

Michael Niedermayer michael at niedermayer.cc
Thu Jul 16 20:40:25 CEST 2015


On Thu, Jul 16, 2015 at 07:19:40PM +0200, wm4 wrote:
> 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.

ffprobe, yes but also anything that chooses a stream out of several
may be interrested if a stream is likely lossless or not.
and that potentially could be interresting for most tools using
the libs.
That choosing also can be automatic or manual both need some knowledge
over a stream to choose which to use if there are several

and yes all these tools could decode the first frame (and 2nd if the
first isnt a keyframe, and 3rd, ... until width/height/... is known
but i think its better if libavformat is able to do that and it
doesnt need to be duplicated in each tool which is interrested in
such information.


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

i dont mind if side data or meta data is used if it is possible and
people prefer it

ATM i think its not possible as theres no side data in the structs
needed. also the reason why iam not a big fan of side data is that
its a quite heavy system, needing malloc(), needing to deal with
malloc failures, needing to iterate over lists of structs to find out
if a specific "key" is set.
It feels to me like total overkill to use all this for basically
setting a single bit flag for a stream/codec. But like i said, i
dont mind it if thats what people want to use for this and the people
who want it also do the work

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150716/378b3364/attachment.sig>


More information about the ffmpeg-devel mailing list