[vlc-devel] Starting Scaletempo for VLC

[Kevin DuBois]

On Tue, Jun 10, 2008 at 7:03 PM, Rov Juvano <rovjuvano at users.sourceforge.net>
wrote:

> On Mon, Jun 09, 2008 at 11:07:53AM +0200, Remi Denis-Courmont wrote:
> > AFAIK, the normal format within VLC is fl32, so you should at least
> handle
> > this one. Unless there is a reason to handle another format directly, let
> > the core do the conversion to fl32 (and then from fl32 to whatever the
> > audio output wants).
>
> Can someone verify this?  If so, I can remove the s16 version.
>
> --
> rovjuvano
>

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.

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.

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:
 decoder,    a converter (fl32->s16l),     filter A,      a conversion
filter(s16l->fl32),     filter B,   conversion filter(fl32->s16l),
encoder.
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.

A final drawback to this logic is that specifying filterB before filterA
requires less filters, as you can get by with the chain:
decoder,    filterB,    converter (fl32->s16l),     filterA,    encoder

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.

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.

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

-- 
Kevin DuBois
kdub432 at gmail.com
PGP Key fingerprint = 80CF 7C1D 0A1C BE03 2203 95B6 1515 C3DC B6BE 7E88
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080610/bf678a6d/attachment.html>