On 04/24/2011 04:54 AM, Måns Rullgård wrote: > Justin Ruggles <[email protected]> writes: > >> On 04/23/2011 11:30 AM, Måns Rullgård wrote: >> >>> Diego Biurrun <[email protected]> writes: >>> >>>> On Fri, Apr 22, 2011 at 10:19:44PM -0400, Justin Ruggles wrote: >>>>> >>>>> Based on patches by clsid2 in ffdshow-tryout. >>>>> >>>>> --- a/configure >>>>> +++ b/configure >>>>> @@ -95,6 +95,7 @@ Configuration options: >>>>> --disable-mpegaudio-hp faster (but less accurate) MPEG audio >>>>> decoding [no] >>>>> + --enable-audio-float floating-point output from some audio >>>>> decoders [no] >>>> >>>> The comment is not very descriptive. >>> >>> I really would prefer runtime selection. >> >> One issue is not a big deal, just annoying. av_find_stream_info() >> doesn't get the AVOptions, and it requires the decoder to always be >> opened to get the sample_fmt. So in this case any requested sample_fmt >> will not be known and it will be set to default. Because the encoders >> are opened before the decoders in ffmpeg, the encoder sample_fmt will be >> selected based on that default sample_fmt from the decoder. Then after >> the decoder is opened it sets the input sample_fmt to the requested one >> this time, but the encoder has already been initialized with the >> original default. >> >> If the user doesn't request a sample_fmt explicitly, we have another >> issue. Either we set the decoder sample_fmt based on the encoder or we >> set the encoder sample_fmt based on the decoder. We could choose the >> most accurate supported sample format on one side or the other, then >> choose the best option on the other side... but anyway we solve this, it >> is a lot of mess for a temporary solution... > > Sounds like something needs to be fixed then. Anyway, why this patch at > all if it's temporary? It's quite ugly, and the proper format > conversion API is nowhere in sight.
I'll try today to see if I can get the AVOptions set before av_find_stream_info() in ffmpeg.c. If I can do that, I think the request_sample_fmt behavior would at least be acceptable. why the patch: 1) floating-point output is useful 2) for these decoders, outputting float is the final goal 3) this is a step in the right direction 4) currently int16 output is much faster because of float_to_int16_interleave() -Justin _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
