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

[Alex Converse]

On Fri, Feb 26, 2010 at 9:38 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Feb 26, 2010 at 03:29:41PM +0100, Michael Niedermayer wrote:
>> On Fri, Feb 26, 2010 at 12:36:53AM -0500, Alex Converse wrote:
>> > 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
>>
>> i of course meant at the top of av_find_stream_info() not in the loop
>
> Thinking of this a little more, i think the sanest solution is to put the
> check in all affected demuxers. Anything else is a mess in terms of
> maintaince.
>

Putting special logic in each demuxer for AAC seems liek a recipie for
disaster. We wind up with dozens of different test cases instead of
just a few.

> which demuxers are affected by this at all?

mp4, mov, mkv, raw (adts), wav
maybe caf, maybe flv

I wouldn't even know which demuxers to check

> mp4 obviously, avi/nut (mov?) in theory not (violates their spec)
> mpeg* has no headers to begin with that could be wrong ...
> what do the others use ?
>
>
> --
> Michael ? ? GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Democracy is the form of government in which you can choose your dictator
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFLh9zLYR7HhwQLD6sRAmJpAJ9czedrbf6rRMq4HfnD9HYRnDkfhwCfco3n
> jqANC79ZEzD/uPu6tr/7cGo=
> =g3sa
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>