[FFmpeg-devel] Is there anybody want to merge fix-point wma back to ffmpeg?

[Siarhei Siamashka]

On 8 November 2007, William Xue wrote:
> >> I merged the codes yesterday, and the quality was a little worse.
> >>
> >> But the worst thing is wma_decode_block returned -1 in arm cpu,
> >> because of the following codes:
> >
> > Hi, before you debug the bitstream reader, compare the output from the
> > code running on x86.
>
> Thanks. I fixed the problem.
>
> (*(uint32_t *)a)  when a is "uint8_r *a" are not working as expected in my
> arm cpu.

Did you find this alignment problem in ffmpeg code or in yours? Architectures
which require strict alignment are supported in ffmpeg and bitstream reader
should be fine as far as I know.

> The performance is greatly improved, though not enough for my poor cpu.

That's good. Optimizations are cumulative and after a number of iterations,
you may end up running this code fast enough on your cpu.

> And the quality is also a little worse. I will try to ensure that I did
> not make any mistakes
> when merging the codes in following days.

Even if the quality of this WMA code is not up to ffmpeg standards yet, I
would definitely like to have a look at it and try to use it as an unofficial 
patch (in mplayer package for Nokia 770 that I'm trying to maintain). Current
WMA decoder is hardly usable on ARM cores without FPU, so almost any fixed
point implementation should be a big step forward. That said, I'm not a big
fan of WMA myself and don't have anything encoded in it on my PC except for 
a few test samples, but some users might probably like this improvement.

So I would surely welcome fixed point WMA decoder patches getting posted in
some of your followup posts.