[Ffmpeg-devel] [PATCH] access all bitrates for amr nb encoding
Benoit Fouet
benoit.fouet
Mon Feb 19 14:30:14 CET 2007
Hi,
Michael Niedermayer wrote:
> Hi
>
> On Mon, Feb 19, 2007 at 12:15:21PM +0100, Benoit Fouet wrote:
>
>>>>>>> well, i'm coming with the beginning of something...
>>>>>>> the problem is that audio and video bitrate are crushing one another...
>>>>>>>
>>>>>>> for instance launching a ffmpeg with a -b and -ab options, the last of
>>>>>>> the two options will be taken into acount...
>>>>>>> the question is: "is it the right place to add the ab option handling ?"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> hmm avctx_opts in ffmpeg.c should maybe be split
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> one for video, and one for audio ?
>>>>>
>>>>>
>>>>>
>>>> yes, we can add one for subtitles later when it becomes needed, there
>>>> are also many other possible solutions, like writing the options directly
>>>> into the target context with no avctx_opts in between ...
>>>>
>>>>
>>>>
>>>>
>>>>
>>> indeed, i tried to understand how all this option stuff worked, and it
>>> seems a bit obscure to me for the moment...
>>> if we want to split audio and video avctx_opts, for instance, we'll have
>>> to split the "default" handling too, am i right ?
>>> anyway, i think i'm going to go on reading the source and try to find
>>> out how this is done...
>>>
>>>
>>>
>> well, i fear i didn't have much time to look at it...
>> what we have now is:
>> const char **opt_names=NULL;
>> int opt_name_count=0;
>> AVCodecContext *avctx_opts;
>> AVFormatContext *avformat_opts;
>>
>> i don't know exactly what is the best to be done...
>> should we split all those 4 variables ?
>> should we get rid of avctx_opts ?
>> in fact, i cannot see how to do it without big changes in ffmpeg.c (at
>> least)
>>
>> This was in the first time to make -ab work as -b option, but i guess
>> it's more than that now, isn't it ?
>>
>
> yes and no, its more but its required to get -ab to work, i see no other
> solution
>
>
neither do i, for the reasons i explained sooner
> 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.
> 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} ?
> 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.
Ben
More information about the ffmpeg-devel
mailing list