[Ffmpeg-devel] Question about parameters

[Aaron Williams]

Hi,

VXctor_Paesa wrote:
> Hi,
>   
>> Michael Niedermayer wrote:
>>     
>>> Hi
>>>
>>> On Sat, Dec 23, 2006 at 07:06:39PM -0800, Aaron Williams wrote:
>>>
>>>       
>>>> Robert Swain wrote:
>>>>
>>>>         
>>>>> Hello,
>>>>>
>>>>> On 24 Dec 2006, at 01:57, Aaron Williams wrote:
>>>>>
>>>>>           
>>>>>> Hi,
>>>>>>
>>>>>> I am writing a new audio "codec" which basically computes the peak
>>>>>> RMS
>>>>>> volume for normalizing audio in another pass and am wondering if
>>>>>> there's
>>>>>> a standard way for my codec to introduce a new parameter so I can
>>>>>> specify the RMS window size?  What is the best way for me to add this
>>>>>> parameter to pass to my module?  My goal is to use the output from
>>>>>> this
>>>>>> to adjust the -vol parameter in the transcoding pass.
>>>>>>
>>>>>>             
> [...]
>
>   
>>>> I will repeat my question:  How does one add codec specific parameters
>>>> to the command line of ffmpeg without adding a general purpose option
>>>> and without bloating AVCodecContext with new fields not needed for
>>>> other
>>>> codecs?  There are a number of parameters I wish to add for
>>>> normalization such as RMS window size, target volume, thresholds and an
>>>> output log filename.
>>>>
>>>> Another audio feature I would like to add is the ability to adjust the
>>>> level of individual channels.
>>>>
>>>>         
>>> what you describe are audio filters not audio codecs and while it should
>>> be possible to implement filters as raw-pcm codecs that would cause
>>> alot of problems (think of chains or networks of codecs) -> its not
>>> acceptable for ffmpeg svn and as its not acceptable for svn theres
>>> no point in asking here how to solve the various problems ensuing
>>> due to this missdesign
>>>
>>> [...]
>>>
>>> ------------------------------------------------------------------------
>>>       
>> One drawback of a filter is that the normalizing pass is basically a
>> dead-end.  By definition, two passes are required.  The first pass must
>> process the entire file and find the peak levels.  Also, as was
>> previously stated, there currently is no audio filter support.  If this
>> were present then I might make use of this.  Right now the normalization
>> pass goes very quickly since it only decodes the audio stream to PCM and
>> does no video decoding.
>>
>> If there is a misdesign, it is in the basic ffmpeg itself in that there
>> is no support for audio filters or for dynamic parameters.  Each codec
>> and/or filter should be able to supply additional command-line
>> parameters as needed. This will add greater flexibility and eliminate
>> parameters in core data structures that are only used by one or two
>> modules.
>>
>> Actually, it fits quite nicely as a codec, though it does not output
>> anything. The current design lets it easily specify the window size
>> which works out perfectly.  My only requirement is that I be able to
>> pass enough information to generate a small log file with the results of
>> the analysis.
>>
>> As far as modifying the volume output, this can already be accomplished
>> during the second transcoding pass by using the -vol parameter.  I have
>> made a change so that it can take a value like it currently does (i.e.
>> defaults to 256) or one can specify the output volume in DB.  My goal is
>> to also be able to specify a log file to be read at startup with the
>> volume adjustments, which should be simple to do.
>>     
>
> This reminds me that ffmpeg allows two passes to find the optimal video
> bitrate, it produces a log file in the first step that the second step
> reads.
>
> Wouldn't be natural to add audio normalizing into the current two pass
> processing?
>
> Regards,
> V?ctor
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>
>
>   
I thought about that, though this is a bit different.  In the first
pass, there is no actual encoding but I am looking at this method.

The problem I seem to face is that it looks like the logging is only
active during the encode phase but I need to log the output only after
the entire file has been processed, basically in the close phase. Also,
in the first pass this could mess things up since there is no actual
data output from this to send to the output, which seems to screw it up.

Right now for my processing I use something like this:

ffmpeg -i filename.xyz -acodec normalize -vcodec copy -f null out

which currently just prints the result to the screen after processing

ffmpeg -i filename.xyz -vol [volume] -target ntsc-dvd -sameq -acodec mp2
-ab 192 filename.mpg

which matches my requirements to convert a bunch of videos to MPEG2 for
a Vela hardware decoder box used for playback.  Since I don't care about
bandwidth in my case, I only encode once, though since currently only
video uses two passes I don't see why this couldn't also be combined
with two-pass video encoding.

Right now the normalization is more of a judgment call where I provide
the data and make a decision based on the result. Preferably I could
automate this but will need a number of additional parameters for
thresholds, such as a target audio peak and RMS ranges.

One other thing is right now I have to use -f null because there is no
actual data encoded in the normalization pass, unlike mpeg video or
audio encoding. Trying to use something like avi will screw it up since
there is no actual output audio data.

Audio filters would be a nice addition to ffmpeg, since they could be
used for other things as well like reverb, equalization, pitch
adjustment, Dolby pro-logic encoding/decoding or other things, and in
fact this would fit well in there and could either pass the audio through.

There are other things to take into account as well. For example, if a
number of input files are used to produce an output file, the
normalization would be performed on each of the input files and analyzed
to see what the average output and peak output are and which files need
to be adjusted and by how much, which is not possible with the current
design.

I won't have time to implement a full normalization process since I only
have a couple of days to get this working for a project I'm working on,
though perhaps this could be implemented later with a proper framework.

One thing I think might be useful for filters, though, would be to allow
each filter to be able to specify new command-line options at runtime.
This could help clean up ffmpeg.c and data structures like
AVCodecContext so they don't have to be cluttered up with filter
options. This could also be useful for different codecs and formats.

-Aaron