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

[Michael Niedermayer]

On Wed, Nov 12, 2014 at 06:31:52PM +0100, Lukasz Marek wrote:
> 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.

iam not sure i understand what you have in mind or if i misunderstand
but
What i was thinking of is that the options from a configuration file
or command line would be provided to the ffm muxer in the form of a
string or AVDictionary by the user application (ffserver for example)
and the connecting ffmpeg would receive this string or AVDictionary
from the ffm demuxer and use it to configure the encoder by
passing it into avcodec_open(), defaults would be from the side
that actually runs the encoder, the other side would have no
impact on the defaults it would just transfer the user parameters

i dont see any need for a callback but its quite possible i
misundertood something


> 
> 
> 
> > 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 :)

yes i definitly think its better this is pushed and we improve on top
of that if theres sense in doing so instead of endless redesigns

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20141112/533c4bd5/attachment.asc>