andoma | 7 Dec 16:10 2007
Picon

[soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

Author: andoma
Date: Fri Dec  7 16:10:55 2007
New Revision: 1538

Log:
Rebirth of the SoC AAC decoder.
This time we should focus on getting a fully working LC decoder and
then get it merged into lavc.

See 'TODO' on whats left to acomplish.




Added:
   aaclc/
   aaclc/TODO
   aaclc/aac.h
   aaclc/aacdec.c
   aaclc/aactab.c
   aaclc/aactab.h
   aaclc/ffmpeg.patch

Added: aaclc/TODO
==============================================================================
--- (empty file)
+++ aaclc/TODO	Fri Dec  7 16:10:55 2007
 <at>  <at>  -0,0 +1,16  <at>  <at> 
+Stuff that needs to be fixed (in order)
+
(Continue reading)

Diego Biurrun | 7 Dec 16:46 2007
Picon

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

On Fri, Dec 07, 2007 at 04:10:59PM +0100, andoma wrote:
> 
> Log:
> Rebirth of the SoC AAC decoder.
> This time we should focus on getting a fully working LC decoder and
> then get it merged into lavc.
> 
> See 'TODO' on whats left to acomplish.

Excellent :)

> --- (empty file)
> +++ aaclc/aac.h	Fri Dec  7 16:10:55 2007
>  <at>  <at>  -0,0 +1,99  <at>  <at> 
> +
> +/**
> + * Audio object types

Lowercasing such incomplete sentences would be a plus.

> --- (empty file)
> +++ aaclc/aactab.h	Fri Dec  7 16:10:55 2007
>  <at>  <at>  -0,0 +1,47  <at>  <at> 
> +
> +#ifndef FFMPEG_AACTAB_H
> +#define FFMPEG_AACTAB_H
> +
> +#include "common.h"
> +
> +extern const uint16_t    *aac_swb_offset_1024[12];
(Continue reading)

Benoit Fouet | 7 Dec 16:51 2007

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

andoma wrote:
> Author: andoma
> Date: Fri Dec  7 16:10:55 2007
> New Revision: 1538
>
> Log:
> Rebirth of the SoC AAC decoder.
> This time we should focus on getting a fully working LC decoder and
> then get it merged into lavc.
>
> See 'TODO' on whats left to acomplish.
>
>
>
>
> Added:
>    aaclc/
>    aaclc/TODO
>    aaclc/aac.h
>    aaclc/aacdec.c
>    aaclc/aactab.c
>    aaclc/aactab.h
>    aaclc/ffmpeg.patch
>
>   

wasn't that a modified copy of the aac/ directory ?

--

-- 
Ben
(Continue reading)

Robert Swain | 7 Dec 17:05 2007
Picon

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

On Fri, 2007-12-07 at 16:51 +0100, Benoit Fouet wrote:
> andoma wrote:
> > Author: andoma
> > Date: Fri Dec  7 16:10:55 2007
> > New Revision: 1538
> >
> > Log:
> > Rebirth of the SoC AAC decoder.
> > This time we should focus on getting a fully working LC decoder and
> > then get it merged into lavc.
> >
> > See 'TODO' on whats left to acomplish.
> >
> >
> >
> >
> > Added:
> >    aaclc/
> >    aaclc/TODO
> >    aaclc/aac.h
> >    aaclc/aacdec.c
> >    aaclc/aactab.c
> >    aaclc/aactab.h
> >    aaclc/ffmpeg.patch
> >
> >   
> 
> wasn't that a modified copy of the aac/ directory ?

Yes, that's the intention as the code has been stripped to LC AAC and
(Continue reading)

Andreas Öman | 7 Dec 17:07 2007
Picon

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

Benoit Fouet wrote:

> wasn't that a modified copy of the aac/ directory ?
> 

We had a discussion on #ffmpeg-devel regarding this matter.
The general opinion was that it could just as well be created
from "scratch". The diffs back to the "original" aac.c file
would probably be very messy anyway.
Benoit Fouet | 7 Dec 17:10 2007

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

Andreas Öman wrote:
> Benoit Fouet wrote:
>
>   
>> wasn't that a modified copy of the aac/ directory ?
>>
>>     
>
> We had a discussion on #ffmpeg-devel regarding this matter.
> The general opinion was that it could just as well be created
> from "scratch". The diffs back to the "original" aac.c file
> would probably be very messy anyway.
>
>   

ok, thanks :)

--

-- 
Ben
Purple Labs S.A.
www.purplelabs.com
_______________________________________________
FFmpeg-soc mailing list
FFmpeg-soc <at> mplayerhq.hu
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-soc
Michael Niedermayer | 7 Dec 21:36 2007
Picon
Picon

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

On Fri, Dec 07, 2007 at 05:07:01PM +0100, Andreas Öman wrote:
> Benoit Fouet wrote:
> 
> > wasn't that a modified copy of the aac/ directory ?
> > 
> 
> We had a discussion on #ffmpeg-devel regarding this matter.
> The general opinion was that it could just as well be created
> >from "scratch". The diffs back to the "original" aac.c file
> would probably be very messy anyway.

yes combining many unrelated changes leads to messy diffs thats
why each individual change should be commited seperately

let me just say that if it were ffmpeg-svn i would consider to
revoke your svn write permissions for such a commit like that here
and obviously revert the commit at the spot

now its just soc-svn and the average quality of commts here is lower
but i think this commit beats everything which was commited in 2007
in terms of low quality

somehow i feel that theres a "aac is important, lets fogrget all sanity
and get it done as quick as possible even if the result will be trash"
mentality here
i can only say we do have faad already we should do it properly or
not at all

diff -ubwiB |diffstat
ffmpeg.patch->ffmpeg.patch |    8     4     4     0 ++++----
(Continue reading)

Benjamin Larsson | 7 Dec 22:23 2007
Picon

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

Michael Niedermayer wrote:

> i dont know who on #ffmpeg-dev "approved" that but i do know they need their
> head examined and suspect they never looked at the actual code before
> approving it

I'll go to a shrink on monday then. The way we (I?) reasoned was that
because the soc code was in quite bad shape (it has several bugs and
buggy code for features other then just pure aac-lc) just leave it there
and start a new repo with only the aac-lc code in. I see no reason to do
this kind of transition in small incremental steps just to keep the
diffs to a minimum when creating a new repo. The old history wont be
that relevant anyway.

MvH
Benjamin Larsson
Michael Niedermayer | 7 Dec 23:03 2007
Picon
Picon

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

On Fri, Dec 07, 2007 at 10:23:33PM +0100, Benjamin Larsson wrote:
> Michael Niedermayer wrote:
> 
> > i dont know who on #ffmpeg-dev "approved" that but i do know they need their
> > head examined and suspect they never looked at the actual code before
> > approving it
> 
> I'll go to a shrink on monday then.

thank you

> The way we (I?) reasoned was that
> because the soc code was in quite bad shape (it has several bugs and
> buggy code for features other then just pure aac-lc) just leave it there
> and start a new repo with only the aac-lc code in. I see no reason to do
> this kind of transition in small incremental steps just to keep the
> diffs to a minimum when creating a new repo. The old history wont be
> that relevant anyway.

the problem is that some bad changes made it through also, it obscures
what has been written by andreas and what by previous authors

[...]

--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
(Continue reading)

Andreas Öman | 7 Dec 22:51 2007
Picon

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

Michael Niedermayer wrote:
> On Fri, Dec 07, 2007 at 05:07:01PM +0100, Andreas Öman wrote:
>> Benoit Fouet wrote:
>>
>>> wasn't that a modified copy of the aac/ directory ?
>>>
>> We had a discussion on #ffmpeg-devel regarding this matter.
>> The general opinion was that it could just as well be created
>> >from "scratch". The diffs back to the "original" aac.c file
>> would probably be very messy anyway.
> 
> yes combining many unrelated changes leads to messy diffs thats
> why each individual change should be commited seperately

Well, what can I say?
This procedure was was proposed in a mail to this list at November 12th.
I assumed that the absence of answer was equal to "green light".

> let me just say that if it were ffmpeg-svn i would consider to
> revoke your svn write permissions for such a commit like that here
> and obviously revert the commit at the spot

I'm very well aware of those rules and would of course not do such a
thing.

> now its just soc-svn and the average quality of commts here is lower
> but i think this commit beats everything which was commited in 2007
> in terms of low quality

Encouraging...
(Continue reading)

Michael Niedermayer | 7 Dec 23:09 2007
Picon
Picon

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

On Fri, Dec 07, 2007 at 10:51:57PM +0100, Andreas Öman wrote:
[...]
> > now its just soc-svn and the average quality of commts here is lower
> > but i think this commit beats everything which was commited in 2007
> > in terms of low quality
> 
> Encouraging...

iam glad you see it that way

> 
> Do you suggest that the development work should continue in the aac/
> directory or just be done entirely out-of-tree?

i dont care which directory but not some non public private "ill post it
to ffmpeg-dev when finished" thing
just hit svn commit after each change instead of waiting until you
accumulated several unrelated ones

commiting something bad to soc-svn and then reverting is not such a big
problem as is commiting unreviewable changes IMO

[...]

--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
(Continue reading)

Diego Biurrun | 8 Dec 10:40 2007
Picon

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

On Fri, Dec 07, 2007 at 11:09:04PM +0100, Michael Niedermayer wrote:
> On Fri, Dec 07, 2007 at 10:51:57PM +0100, Andreas Öman wrote:
> [...]
> > > now its just soc-svn and the average quality of commts here is lower
> > > but i think this commit beats everything which was commited in 2007
> > > in terms of low quality
> > 
> > Encouraging...
> 
> iam glad you see it that way

Irony fighting irony...

Anyway...  I think the problem here was that Andreas was hitting
somewhat of a brick wall.  His suggestions about the audio API did not
generate much feedback, neither did his inquiry about how to proceed...

Diego
Michael Niedermayer | 8 Dec 14:48 2007
Picon
Picon

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

On Sat, Dec 08, 2007 at 10:40:06AM +0100, Diego Biurrun wrote:
> On Fri, Dec 07, 2007 at 11:09:04PM +0100, Michael Niedermayer wrote:
> > On Fri, Dec 07, 2007 at 10:51:57PM +0100, Andreas Öman wrote:
> > [...]
> > > > now its just soc-svn and the average quality of commts here is lower
> > > > but i think this commit beats everything which was commited in 2007
> > > > in terms of low quality
> > > 
> > > Encouraging...
> > 
> > iam glad you see it that way
> 
> Irony fighting irony...
> 
> Anyway...  I think the problem here was that Andreas was hitting
> somewhat of a brick wall.  His suggestions about the audio API did not
> generate much feedback, neither did his inquiry about how to proceed...

but the commit did :)

about the audio API, i dunno but i dont think it makes sense to delay (all)
audio decoders until some audio mixing API has been finished ...

[...]

--

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
(Continue reading)

Andreas Öman | 8 Dec 15:14 2007
Picon

Re: [soc]: r1538 - in aaclc: . TODO aac.h aacdec.c aactab.c aactab.h ffmpeg.patch

Michael Niedermayer wrote:
> 
> about the audio API, i dunno but i dont think it makes sense to delay (all)
> audio decoders until some audio mixing API has been finished ...

I agree on that. I'll continue to work with the aac-decoder in the
current repo. First thing is to fix the current known bug.

Secondly, the small annoying bugs that's I initially imagined
would be "fixed" by an audio API could be fixed quite easy anyway.

Gmane