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

[Michael Niedermayer]

On Tue, Feb 09, 2010 at 11:29:53AM +0000, M?ns Rullg?rd wrote:
> 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.

we can just store the options that fell through all avcodec & avformat
in a per codec place and apply them later.

Also independant of the architecture of ffmpeg.c some options must be parsed
before the codecs can be known, i mean the ones related to format and codec
probing.


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

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100210/8cbb26bc/attachment.pgp>