[FFmpeg-devel] [FFmpeg-devel-irc] IRC log for 2010-02-07

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> hi
>
> i had to try to reply to a irclog :)
> reply-to seems set to ffmpeg-dev, interresting
>
> [...]
>> [11:04:59] <superdump> Dark_Shikari: fyi, siretart is also interested in updating the libx264 shipped with ffmpeg 0.5 to work with curretn x264 iirc
>> [11:05:09] <superdump> maybe it was he that made the suggestion
>> [11:05:15] <superdump> i would think that it isn't difficult
>> [11:05:23] <superdump> and we could update the preset files too
>> [11:05:33] <superdump> then maybe it could land in lucid
>> [11:10:31] <twnqx> uh
>> [11:10:42] <twnqx> why not just release 0.6 or even 1.0?
>> [11:13:01] * twnqx never really understood that idea of backporting things to obsolete versions
>> [11:18:29] <superdump> twnqx: because we could push out a 0.5.1 almost immediately but there are a number of things we would like to land in 0.6
>
> how many known sec holes does 0.5 have?
> do you guys want to backport all security fixes or just release a 0.5.1
> with 12 months of unfixed secholes?
>
> [...]
>> [20:25:57] <Dark_Shikari> We almost never break backwards compatibility though
>> [20:26:02] <Dark_Shikari> once in 2-3 years at most
>> [20:26:39] <Dark_Shikari> the main issue is that because ffmpeg uses the variables directly instead of the recommended param_parse API, it forces an x264 upgrade every single time ffmpeg is updated
>> [20:26:55] <Dark_Shikari> key/value pairs would avoid this problem
>> [20:27:14] <DonDiego> implement it
>> [20:27:27] <Dark_Shikari> it won't give any benefit until we have codec-specific options ;)
>
> it would fix the compatibility issues
>
> besides codec specific options are just an AVOption array for the
> private context of your AVCodec, 5 lines in ffmpeg.c to set options
> in it.

It's slightly more complicated than that.  Currently the options are
applied to the AVCodecContext in command line order before the codec
is even known.  To have codec-specific options we'd need to figure out
the codec before processing the rest of the options.

> not too hard but it still would need a 1-2 line addition inside
> libavcodec/libx264.c for each new option. Its possible to avoid that
> trivially even without codec specific options, just pass a string that
> contains all the key value pairs and parse that.

That adds complexity to every codec.

> Its what mplayer/mencoder do more or less. I do prefer the AVOption
> based solution though

+1

Using AVOption would also trivially allow -h to display codec-specific
options, which would otherwise be impossible without even more
complexity in each codec.

-- 
M?ns Rullg?rd
mans at mansr.com