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

[Ramiro Polla]

Michael Niedermayer wrote:
> 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

Applied. With minor version bump that I forgot to mention in the 
patches, but is in the development policy in general.texi. BTW I think 
this is not being enforced properly either. I know I always forget...

Thanks everyone that helped in the process with reviewing, samples, 
etc... And of course thanks to Ian Caulfield for the RE...

Ramiro Polla