[Ffmpeg-devel] [PATCH] access all bitrates for amr nb encoding

[Benoit Fouet]

Hi,

Michael Niedermayer wrote:
> Hi
>
> On Mon, Feb 19, 2007 at 02:30:14PM +0100, Benoit Fouet wrote:
> [...]
>   
>>> getting rid of *_opts can be done by simply keeping a single 
>>> opt_names, opt_values and opt_name_count and simply going over them every
>>> time a context must be initalized, i dont know if that is a good idea but
>>> its possible,
>>>       
>> i've not yet worked out the correlation between options and context... i
>> mean, for instance, how options for input file(s) are not used for
>> output... but i go on reading :)
>>
>>     
>>>  there are also 2 or so places where you would need to append
>>> a option to override some flags in opt_*
>>>
>>>   
>>>       
>> i don't understand that.
>>     
>
> you dont have to unless you want to get rid of *_opts :)
>
>
>   
ok, so you suggest i should look at having 3 *_opts (video, audio and
subtitles), or a _opts table ?

>>> either way theres one thing which i think has not been disscussed yet and
>>> that is how to route the options in a generic way to the correct context
>>>
>>> if a option matches exactly then it should be set in all contextx (if thats
>>> now done once with split avctx/avformat_opts or every time a context is inited
>>> doesnt matter)
>>>
>>>   
>>>       
>> are there many options that work for two out of {audio; video; subtitle} ?
>>     
>
> 13 are are marked as for audio and video in AVCodecContext but there are 
> likely more which theoretically should be marked for audio+video
>
>
>   
i'll have a look and send a patch, i'd like everything right before
beginning to change option management ;)

>>> if there is no exact match bit it starts with "a"/"v"/"s" and the remainder
>>> has a match then it would be set only for audio/video/subtitles, does that 
>>> work? or do we have some name clashes here?
>>>
>>> [...]
>>>   
>>>       
>> i'm not sure i understand you (once again :) )
>> i've not a clear vision of all this works, actually... so it's quite
>> hard to follow you.
>>     
>
> option parsing works very simply
> first the old parsing is done (this is irrelevant for us)
>
>   
you mean the one using the OptionDef table in ffmpeg.c, right ?

> then what isnt handled is feeded into the AVOption code which puts the
> name into opt_names and the value into avctx_opts/avformat_opts
> that is done in opt_default()
>
>   
that is ok (i mean i understand).

> then at appropriate places in the code the stuff from
> avctx_opts/avformat_opts is copied into the actual contexts
>
>   
this is what i still have problems to see how is done...
and i guess i have to understand if i want to split it correctly (and do
things at their right places too)

> the problem with audio/video is that there is just 1 avctx_opts which can
> not hold 2 different bitrates ...
>
> if its simply split and the options are appropriately put into each then the
> problem is solved
>
>   
i think too this would be the simpliest way to do so, but as i already
said, my view is far from being an expert one !
this would mean to modify the OFFSET macro (for instance) so that it can
handle properly the split, i guess...

> independant of that the avctx_opts/avformat_opts * (audio/video/subtitles)
> could be changed to a single name/value array which are used instead of
> avctx_opts/avformat_opts (i dont know if this is a good idea, i would have
> to see the change first to judge which way is cleaner)
>
> [...]
>   
>   
ok then... i get a view which seems clearer now, cool :)

Thanks,
Ben