[FFmpeg-devel] [PATCH] HE-AAC v1 decoder try 4
Wed Feb 17 19:29:06 CET 2010
On Wed, Feb 17, 2010 at 01:20:59PM +0000, M?ns Rullg?rd wrote:
> Vladimir Pantelic <pan at nt.tu-darmstadt.de> writes:
> > Alexander Strange wrote:
> >> On Feb 16, 2010, at 6:19 PM, Alex Converse wrote:
> >>> On Tue, Feb 16, 2010 at 6:01 PM, Alex Converse<alex.converse at gmail.com>wrote:
> >>>> Notes:
> >>>> *All the computation time is spent in ff_sbr_apply() and it's
> >>>> children. If it isn't called from ff_sbr_apply() making it 100% faster
> >>>> isn't going to buy us anything.
> >>>> *Right now the synthesis filterbank is written on top on an MDCT. With
> >>>> appropriate SIMD functions it may make sense to move it to an FFT.
> >>>> Right now the MDCT version is much faster.
> >>>> *SIMD placeholder patch not included
> >>> Wrong patch.
> >>> try 4.1 :)
> >>> <sbr.diff>
> >> I tried it with ffplay and it plays 2x too slow. If ffplay needs to be fixed, I wonder if other players will too? Well, it's unavoidable anyway.
> >> ffmpeg to wav sounds fine.
> > guess its the issue that the container signals the smaller (non-sbr)
> > sample rate, e.g. 24khz and the decoder applies SBR and returns
> > 48kHz. I had to fix my player to switch to the decoder returned sample
> > rate too...
> I learned a long time ago not to trust the container values for
> anything. If the decoder says anything at all, that's usually
> correct. Except for dodgy mpeg4 in avi, where it's equally common for
> both to be wrong.
and h263 in mov where the h263 width & height are "correct" but the users
will insist that they are wrong because qt crops and scales the decoder
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some touch of madness. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel