[FFmpeg-devel] [PATCH] MLP/TrueHD decoder
Sun Dec 2 00:49:17 CET 2007
It appears I attached an older version of the patch in my last email,
sorry. I've attached an up-to-date patch (hopefully) addressing
On Dec 1, 2007 10:08 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Thu, Nov 29, 2007 at 10:55:56AM +0000, Ian Caulfield wrote:
> > On Nov 12, 2007 1:25 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > As well as an error being returned, the "have parameters" flag in the
> > context is cleared, causing all packets to be rejected until we get a
> > (valid) sync packet.
> there is no variable, constant or otherwise called "have parameters" or have*
The variable "has_params" is used (previously called in_sync).
> > >
> > > do the parameters change between syncs in practice? or would using the
> > > parameters of the last undamaged sync work as well?
> > Unfortunately so - the sync packets contain not just things like "6
> > channels, 48KHz", but also encoding parameters which change throughout
> > the stream to improve compression - an earlier version of the decoder
> > had a bug where one of the parameters wasn't reset properly and it
> > sounded awful. I think trying to fudge by on the last set of
> > parameters is likely to produce nasty output...
> well, but some sound will have to be placed where decoding fails ...
> from the outside of the decoder we are limited to things like putting
> silence there or repeating the last valid output
> does this sound better?
I don't know offhand, but data like the state for the prediction
filters is conveyed each sync frame - if this goes badly wrong, I
suspect the output will be little better than random data. The MLP
scheme is designed for lossless media, so the error resilience isn't
great. I'm not an expert on audio error recovery/concealment though.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the ffmpeg-devel