[FFmpeg-devel] [PATCH] MLP Encoder

Michael Niedermayer michaelni
Thu Aug 14 14:07:26 CEST 2008

On Thu, Aug 14, 2008 at 02:08:45AM -0300, Ramiro Polla wrote:
> Hello,
> Attached is the MLP encoder written as part of the Google Summer of
> Code project and mentored by Justin Ruggles.
> Things that are not quite complete:
> - 24-bit support. I'm waiting to see what will become of
> SAMPLE_FMT_S24, and the code might need a few changes. But mostly it
> works;

> - The filters... The filtering code is there and it works, but finding
> good coefficients is not. The FIR code from flacenc.c can be plugged
> in there quite easily, but it takes more bits to encode the
> coefficients than the raw data. It might be because of the small frame
> size (40 samples @ 44100kHz). If the frame size was raised to
> something like 256 samples, the compression would be much better, but
> the RE work shows that the bitstream doesn't allow this. Also my
> attempts with IIR filters weren't successful.

i dont know the bitstream yet very well ...
but ian said they can be coded less often, also
no harm should be done (except the speed loss) by trying them and then not
using them when they turned out overall worse for a frame.

> Things that are awfully suboptimal:
> - The search for the best offset for the codebooks. If just one offset
> (the average) is taken into account and no search is done, encoding is
> 30% faster and the resulting filesize is 0.5% bigger. At one point I
> thought taking the median (instead of the average) of all the samples
> would compress better (more values close to 0), but it took longer to
> calculate and would have highly inaccurate offsets, having to search
> even more.

there are fast algorithms that can calculate the median of n samples in O(n)
time and space. If you think a median is better i can explain how to do it.

> Things that have not been implemented:
> - The lossless matrix. I don't know what to do of it. So there is no
> channel decorrelation.

if this is a generic matrix with arbitrary coefficient(i assume so but
didnt RTFS yet) then the attached code can be used to calculate a optimal
one, i can cleanup&commit that if its usefull for mlp

> - More than 2 channels. This shouldn't be too hard, I just didn't put
> it high on my priorities.
> Things that can be reused from existing code:
> - More structs can be reused from mlpdec.c. I would prefer to split
> Substr into DecodingParams and RestartHeader (like the encoder does),
> and move that to mlp.h. I'll send a patch about this depending on the
> review.
> - The noise code can be reused if the noise generation functions are
> cleaned up to use shared structs or more generic parameters. This code
> is still not being needed by the encoder though, since it does no
> rematrixing.
> There's also another patch pending to simplify quant_step_size in mlpdec.c.

> Example of file sizes and compression using sample "luckynight.mlp":
> decoded wav: 10668844
> original mlp: 7899056  25.9%
> encoded  mlp: 8563354  19.7%

this needs more work ...

> Besides this, the bitstream is very robust. You can trash it at will
> and the decoder will play as much as possible, resuming lossless
> playback usually in less than 70ms (for 44100kHz, with 40 samples per
> frame and 16 frames per major sync).
> Please review.

I will ASAP, just wanted to reply first with a few generic comments.

also you could add a rate distortion optimal lossy mode using viterbi :)
or even a lame throw away the LSB lossy mode.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pca.c
Type: text/x-csrc
Size: 6286 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080814/91546d8a/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pca.h
Type: text/x-chdr
Size: 992 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080814/91546d8a/attachment.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080814/91546d8a/attachment.pgp>

More information about the ffmpeg-devel mailing list