[FFmpeg-devel] [PATCH] MLP/TrueHD Decoder - 2nd try

[Michael Niedermayer]

On Fri, Jul 04, 2008 at 03:46:51PM +0100, Ramiro Polla wrote:
> Michael Niedermayer wrote:
>> On Fri, Jul 04, 2008 at 01:15:20AM +0100, Ramiro Polla wrote:
>>> Michael Niedermayer wrote:
>>>> On Thu, Jul 03, 2008 at 01:47:11AM +0100, Ramiro Polla wrote:
>>>>> Michael Niedermayer wrote:
>>>>>> On Tue, Jul 01, 2008 at 06:24:55PM +0100, Ramiro Polla wrote:
>>>>>>> Michael Niedermayer wrote:
>>>>>>>> On Tue, Jul 01, 2008 at 01:55:39AM +0100, Ramiro Polla wrote:
[...]
>> [...]
>>> /** Read parameters for one of the prediction filters. */
>>>
>>> static int read_filter_params(MLPDecodeContext *m, GetBitContext *gbp,
>>>                               unsigned int channel, unsigned int filter)
>>> {
>>>     const char fchar = filter ? 'I' : 'F';
>>>     int i, order;
>>>
>>>     // filter is 0 for FIR, 1 for IIR
>>>     assert(filter < 2);
>>>
>>>     order = get_bits(gbp, 4);
>>>     if (order > MAX_FILTER_ORDER) {
>>>         av_log(m->avctx, AV_LOG_ERROR,
>>>                "%cIR filter order %d is greater than maximum %d\n",
>>>                fchar, order, MAX_FILTER_ORDER);
>>>         return -1;
>>>     }
>>>     m->filter_order[channel][filter] = order;
>>>
>>>     if (order > 0) {
>> is a filter order == 0 even valid ?
>
> As Ian already answered: yes. It happens when data is too random and 
> writing the residuals to the filters would be as big as writing the full 
> data. The data doesn't even have to be random. The 440hz.mlp sample (which 
> is just a pure 440 hz sine wave) uses this from time to time. I'm really 
> impressed that the encoder can't code a pure sine wave efficiently. 
> Shouldn't it be fairly predictable?

yes, trashy encoder for a trashy codec ...
But soon we will have your optimal lossless encoder and RD optimal viterbi
lossy encoder :)


>
> Can you just confirm again if these changes were ok and the decoder is good 
> to apply?

yes

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- 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/20080704/4bf5a94d/attachment.pgp>