[FFmpeg-soc] AAC Encoding - Where we stand, what's left

[Michael Niedermayer]

On Wed, Jul 08, 2009 at 02:55:54PM -0700, Baptiste Coudurier wrote:
> On 07/08/2009 02:06 PM, Michael Niedermayer wrote:
>> On Wed, Jul 08, 2009 at 01:41:52PM -0700, Baptiste Coudurier wrote:
>>> Hi Michael,
>>>
>>> On 07/08/2009 12:28 PM, Michael Niedermayer wrote:
>>>> On Wed, Jul 08, 2009 at 01:12:20AM -0400, Alex Converse wrote:
>>>>
>>>> [...]
>>>>
>>>> Also if you need (per codec) options as you said, tell me which, ill add
>>>> them
>>> Do you have a per codec option system ready ? :)
>>
>> no, i need a list of requirements/goals/use cases first
>> once i know what the system should do that AVCodecContext fields cannot,
>> iam sure it shouldnt be that hard ...
>
> What's needed:
>
> is custom options for encoders/decoders/muxers/demuxers which are only 
> needed for one element.
>
> The idea of using AVCodecContext/AVFormatContext doesn't please some devs 
> it seems (including Justin, Alex, and me).
>
> Of course global values used by all must be put in the global context.
>
> I think _devs_ would like to be able to have custom options not fitting 
> everywhere else without poluting global context. This would also permit to 
> have x264 and lame mapped commandlines options.
>
> Can this request be considered ?

yes, i just need to understand what people really want and why.
Heres a try, thats different from what we do now and also is similar to it

give each codec/(de)muxer a foobar_opts.h file that lists its custom options
and then put

#include "foobar_opts.h" inside AVCodecContext from avcodec.h

At a binary level its exactly the same, it also makes moving between custom
and global options very easy, and it adds more seperation to the astronomic
AVCodecContext.

Does that look better to (Justin, Alex, and you) ?
If not please all 3 of you be as elaborate as possible about what is good
and bad on it


Also note, for above idea to work while maintaining ABI all custom options
must come after all non custom always and custom options could only be
accessed through AVOptions from outside lavc (that also means lavf would
need AVOptions to access them). I think that should not be a big issue as
few things would access these fields ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire
-------------- 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-soc/attachments/20090709/7c2a3f17/attachment.pgp>