On Tue, Jun 10, 2008 at 7:03 PM, Rov Juvano <<a href="mailto:rovjuvano@users.sourceforge.net">rovjuvano@users.sourceforge.net</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Mon, Jun 09, 2008 at 11:07:53AM +0200, Remi Denis-Courmont wrote:<br>
> AFAIK, the normal format within VLC is fl32, so you should at least handle<br>
> this one. Unless there is a reason to handle another format directly, let<br>
> the core do the conversion to fl32 (and then from fl32 to whatever the<br>
> audio output wants).<br>
<br>
</div>Can someone verify this?  If so, I can remove the s16 version.<br>
<font color="#888888"><br>
--<br>
rovjuvano<br>
</font><div></div></blockquote><div><br>I've been tinkering with the audio filters code as of late, and
converted the volume normalizing filter into a filter2 module. I found
it necessary to modify transcode.c in order to get fl32 into the volume
normalization module. I noticed some decoders and some encoders (FAAC,
for one) use s16l, but it seems that most encoders/decoders I've seen
working use either s16l or fl32. I actually wrote patches about two
weeks ago (never released due to hacky things I did :-/ ) but those
patches should be largely obsolete since the overhaul to the filter
code which dionoea committed recently. I am currently working on
revamping my code to adapt to the new API, and will let you all know
when its done.<br><br>Basically, as I discussed with dionoea on IRC friday, (I think) the plan was to recommend fl32 for new filter2's to be written in, but allow for some logic in setting up the transcoding chain to allow for funky filters that want something other that fl32. <br>
<br>For instance if we have a  decoder that spits out fl32, a filter2 (filter A) that does (s16l->s16l), another  filter2 (filter B) that does(fl32->fl32) and an  encoder that wants s16l, the logic I'm working on would set up the chain:<br>
 decoder,    a converter (fl32->s16l),     filter A,      a conversion filter(s16l->fl32),     filter B,   conversion filter(fl32->s16l),     encoder.<br>As you can see, this logic introduces 3 new filters into the chain that werent there before, but every filter and the encoder gets what it wants.<br>
<br>A final drawback to this logic is that specifying filterB before filterA requires less filters, as you can get by with the chain:<br>decoder,    filterB,    converter (fl32->s16l),     filterA,    encoder<br> </div>
</div>So the solution to this drawback would be to set some option 'CPU optimized filter chain' that could find the way to introduce the least possible amount of PCM conversions, at the expense of the order specified by the user. There are definitely cases I can imagine that the user would want the exact order they specify the filters set up,  and would then disable that option.<br>
<br>Those are just my thoughts on the matter. Talk is cheap, I'll show you all the code soon enough to see what you think :D. <br><br>Also, Rov, if you need help writing the filter2 module, just ping me (kdubois) on irc, I've already spent a day or two banging my head against the wall trying to figure this all out :P<br clear="all">
<br>-- <br>Kevin DuBois<br><a href="mailto:kdub432@gmail.com">kdub432@gmail.com</a><br>PGP Key fingerprint = 80CF 7C1D 0A1C BE03 2203 95B6 1515 C3DC B6BE 7E88<br>