[FFmpeg-devel] [PATCH] HE-AAC v1 decoder try 4

[Alex Converse]

On Wed, Feb 24, 2010 at 11:06 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>
> On Wed, Feb 24, 2010 at 10:31:43PM -0500, Alex Converse wrote:
> > On Wed, Feb 24, 2010 at 9:20 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > On Wed, Feb 24, 2010 at 07:36:53PM -0500, Alex Converse wrote:
> > >> On Tue, Feb 16, 2010 at 6:19 PM, Alex Converse <alex.converse at gmail.com> 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 :)
> > >>
> > >> Since the last patch I beat on the decoder with the zzuf hammer and
> > >> fixed a few minor things as well as addressing the feeback I've seen
> > >> in this thread.
> > >>
> > >> So I'm trying to figure out where we stand on this:
> > >> *Does the ffplay issue block this?
> > >
> > > what ffplay issue?
> > >
> >
> > The sample rate gets set late and ffplay winds up playing back at its
> > default sample rate, as discovered by Vlad earlier in this thread.
>
> id say move the sample_rate=0 from the codec init to av_find_stream_info()
> that is
> if(aac) sample_rate=0; //elaborate comment
>
That still passes a zero to ffplay, unless you mean to do that before
the has_codec_parameters() check in which case I think B below is
cleaner.

>
> just an idea, maybe theres something cleaner ...



There seem to be three tolerable ways to fix this:
A) set frame_size to zero in aac_decode_init()
for other libav* users this may have similar repercussions as setting
sample_rate to zero for ffplay
B) make has_codec_parameters() always return false for AAC
creates a hidden behavioral dependency between lavc and lavf version matching
old lavf old lavc ok
old lavf new lavc bug: half the sample rate is advertised, ffplay will
play back at half speed
new lavf old lavc ok
new lavf new lavf ok
C) have ffplay set sample_rate and channels before opening the decoder
other libav* users may have used ffplay as a model

Some intolerable ways:
D) decide to use implicit SBR or not based?solely?on the input sample
rate (libfaad)
F) abort(); and suggest the user use vorbis

>
> strictly speaking, all demuxers that set a wrong sample_rate are broken
> (sample_rate is defined by math since a very long time. specs cannot
> ?redefine it for their shitty hacks, but then the whole .mp4 spec is a
> ?huge hack with all its intentionally wrongly set fields and layer of
> ?hacks one for each codec on top to get the true value again,
> ?sbr is another "set it wrong ?and add yet another layer of hacks")
>

Regardless of whether or not it was a smart move, it was made; it
lives in the wild, and we need to find a way to live with it.

--Alex