[FFmpeg-devel] [PATCH] MLP Encoder

Michael Niedermayer michaelni
Fri Aug 15 18:18:07 CEST 2008


On Fri, Aug 15, 2008 at 12:57:39PM -0300, Ramiro Polla wrote:
> Hi,
> 
> On Thu, Aug 14, 2008 at 5:16 AM, Ian Caulfield <ian.caulfield at gmail.com> wrote:
> > 2008/8/14 Ramiro Polla <ramiro.polla at gmail.com>:
> >> 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:
> >
> >> - 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.
> >
> > You shouldn't need to supply coefficients very often - once every
> > major sync ought to be enough...
> 
> I imagine for best compression I could buffer up frames and run the
> filter in the first frame, then first + second, on and on, until the
> filter no longer provides a good approximation, then encode the
> packets up to that point and return them. Is this a good idea, and if
> it is, what's the best way to buffer the frames in a way that doesn't
> mess up sync?

sync should be no problem and if it is then whatever causes the problem
needs to be fixed.

now to the "best compression", read my mail to kostya from yesterday or the
day before about how to encode the band_type RLE thingy optimally.
The very same thing applies here as well. And dont hesitate to ask questions
if anything is unclear.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- 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/20080815/2e2e647d/attachment.pgp>



More information about the ffmpeg-devel mailing list