[FFmpeg-devel] [PATCH] MLP Encoder

[Michael Niedermayer]

On Fri, Aug 15, 2008 at 06:18:07PM +0200, Michael Niedermayer wrote:
> 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.

to elaborate a little
1. buffer lots of stuff (a second or more maybe)
* try to encode all blocks and all sizes that is block 0,1,2,3 each
  individually then, 0+1, 1+2, 2+3, ... then 0+1+2, 1+2+3, 2+3+4, ...
* use the viterbi alorithm to select the best combination within the buffered
  data (that may be for example 0,1+2+3,4+5,6,...)
* output the oldest (0 in the example above)
* goto 1 [and of course dont recalculate what has already been in the
  previous step]

I hope you didnt belive writing the best MLP encoder would be trivial? :)
and even with above it would not be the best because
1. we ignore the IIR
2. the lpc code we have is only optimal in the continuous and linear least
   squares sense, it is not optimal in the least bits sense sadly.

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/a5ceb674/attachment.pgp>