[FFmpeg-devel] [PATCH 3/9] lavf/ffm: store/restore private codec context

[Lukasz Marek]

On 12 November 2014 17:53, Michael Niedermayer <michaelni at gmx.at> wrote:

> On Wed, Nov 12, 2014 at 05:47:01PM +0100, Stefano Sabatini wrote:
> > On date Wednesday 2014-11-12 09:09:43 +0100, Nicolas George encoded:
> > > Le primidi 21 brumaire, an CCXXIII, Lukasz Marek a écrit :
> > > > +static int ffm_write_header_codec_private_ctx(AVIOContext *pb, void
> *priv_data, int type)
> > > > +{
> > > > +    AVIOContext *tmp;
> > > > +    char *buf = NULL;
> > > > +
> > > > +    if (priv_data) {
> > > > +        if (avio_open_dyn_buf(&tmp) < 0)
> > > > +            return AVERROR(ENOMEM);
> > >
> > > > +        av_opt_serialize(priv_data, AV_OPT_FLAG_ENCODING_PARAM |
> type, 1, &buf, '=', ',');
> > >
>    ^
> >
> > > Unless I am mistaken, this is skip_default. What happens if the
> instance
> > > that reads the file does not have the same defaults as the instance
> that has
> > > written it? For example, what happens if ffmpeg feeding ffserver is
> not the
> > > same version as ffserver?
> >
> > We should specify an FFM version, and abort in case it's not
> > compatible.
>

I'm not sure how it should help. Stupid example:
codec has on option to encode picture upside down
In early version  0 - disable 1 - enable feature
In later version it has been changed 1 - disable, 0 - enable.

version of ffm has nothing to do with it.

The problem is that the codec context is used to transport the
> values into the muxer instead of some form of key/value list, string
> or AVDictionary.
>

Yes. A solution would be to provide a callback implemented by codec.
So codec gets a dictionary of properties and version of libav libraries
that produced it and codec applies them itself.
If not implemented then current approach is a fallback without worrying
about compatibility.
This would allow just to fix some incompatibilities in case they occur.
Of course to make it working all options should be sent, not only
non-defaults.



> now, iam not sure changing this as part of this patchset is a good
> idea, its maybe better to try to get this in and not entangle it to
> more changes ...
>

Yes. This can take very long to do all wishes :)