[FFmpeg-devel] Handling of mono data in WMA lossless

[Michael Niedermayer]

On Wed, May 02, 2012 at 06:48:40PM +0200, Jakub Stachowski wrote:
> W dniu 2012-05-02 10:28, Mashiat Sarker Shakkhar pisze:
> >On 5/2/2012 2:11 PM, Jakub Stachowski wrote:
> >>W dniu 2012-05-02 09:55, Mashiat Sarker Shakkhar pisze:
> >>>On 5/2/2012 4:53 AM, Jakub Stachowski wrote:
> >>>[...]
> >>>>This is exactly what I have been missing. I guess it really pays to
> >>>>actually have some idea how audio coding works. All my weird
> >>>>attempts to
> >>>>copy data were unnecessary, for some reason reverse decorrelation was
> >>>>restricted to case when both channels are coded. Removing that check
> >>>>fixes my synthetic test files, real world test case and does not
> >>>>break 3
> >>>>other random WMA files I tested. Patch is attached.
> >>>[...]
> >>>
> >>>It's unfortunate that we are duplicating work. At libav-devel, we
> >>>already have a patch for this -
> >>>http://patches.libav.org/patch/21031/
> >>
> >>I do check libav for anything new in WMA, but it was unfortunate timing
> >>- Kostya's patch was applied the same day I was working on mine.
> >[...]
> >
> >I'd recommend cherry-picking that part of Kostya's patch. (Which of
> >course will be done anyway, when Michael merges changes.)
> 
> I tested libav with Kostya's patch, but that change in mclms_predict
> actually makes things worse in some files. In one of them small
> difference (0xFEFE in one place that should be 0xFFFF) changes into
> several frames being completely different.

merged kostyas changes except the mclms_predict()

thanks
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120503/98e23fca/attachment.asc>