Flac encoder and MPEG4 ALS

Hi,

I started some basic work on the MPEG4 ALS encoder and I get
the feeling that 
I could reuse a lot of code from the flac encoder. So
(hypothetically ) if 
I were to submit a patch, is it okay if I move some code out
of flacenc.c to 
a shared source file? 
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

On Sat, Mar 29, 2008 at 06:49:30PM +0000, Jai Menon wrote:
> Hi,
> 
> I started some basic work on the MPEG4 ALS encoder and
I get the feeling that 
> I could reuse a lot of code from the flac encoder. So
(hypothetically ) if 
> I were to submit a patch, is it okay if I move some
code out of flacenc.c to 
> a shared source file? 

Of course! Code duplication is always bad ...
Note though that moving code must be in seperate patches,
never in a patch
which does functional changes to any code.
Also note svn cp for spliting files while preserving history
with svn.

[...]
-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the
established authorities
are wrong. -- Voltaire

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Jai Menon wrote:
> Hi,
> 
> I started some basic work on the MPEG4 ALS encoder and
I get the feeling that 
> I could reuse a lot of code from the flac encoder. So
(hypothetically ) if 
> I were to submit a patch, is it okay if I move some
code out of flacenc.c to 
> a shared source file? 

Absolutely.

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

Jai Menon a écrit :
> Hi,
> 
> I started some basic work on the MPEG4 ALS encoder and
I get the feeling that 
> I could reuse a lot of code from the flac encoder. So
(hypothetically ) if 
> I were to submit a patch, is it okay if I move some
code out of flacenc.c to 
> a shared source file? 

IIRC we don't even have a decoder for that atm.
Do you have a working ffmpeg decoder for that or are you
using the 
closed mp4alsRM19 binary ?

Ben
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

On Sunday 30 March 2008 08:48:52 Benjamin Zores wrote:
> Jai Menon a écrit :
> > Hi,
> >
> > I started some basic work on the MPEG4 ALS encoder
and I get the feeling
> > that I could reuse a lot of code from the flac
encoder. So
> > (hypothetically ) if I
were to submit a patch, is it okay if I move
> > some code out of flacenc.c to a shared source
file?
>
> IIRC we don't even have a decoder for that atm.
> Do you have a working ffmpeg decoder for that or are
you using the
> closed mp4alsRM19 binary ?

Very correct. It would be more sensible to write a decoder
for  libavcodec 
before pursuing this. But this "work" on the
encoder is with reference to the 
GSoC task. I'm using the RM20 reference decoder and it suits
my current 
purpose. Also i think that the encoder would be
tested/verified against the 
reference.
I have submitted what i hope will be the final patch for my
qual task. Once 
that is done i'll have time to maybe get a basic als decoder
and some code 
refactoring done. Also there is that TAK reversing
thing.......... 

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

On Sun, Mar 30, 2008 at 03:35:22PM +0000, Jai Menon wrote:
> On Sunday 30 March 2008 08:48:52 Benjamin Zores wrote:
> > Jai Menon a écrit :
> > > Hi,
> > >
> > > I started some basic work on the MPEG4 ALS
encoder and I get the feeling
> > > that I could reuse a lot of code from the
flac encoder. So
> > > (hypothetically ) if I
were to submit a patch, is it okay if I move
> > > some code out of flacenc.c to a shared source
file?
> >
> > IIRC we don't even have a decoder for that atm.
> > Do you have a working ffmpeg decoder for that or
are you using the
> > closed mp4alsRM19 binary ?
> 
> Very correct. It would be more sensible to write a
decoder for  libavcodec 
> before pursuing this. But this "work" on the
encoder is with reference to the 
> GSoC task. I'm using the RM20 reference decoder and it
suits my current 
> purpose. Also i think that the encoder would be
tested/verified against the 
> reference.

Just curious - is it possible now to distinguish ALS from
ordinary AAC in mp4
container without extra hack (i.e. looking into extradata)? 


> I have submitted what i hope will be the final patch
for my qual task. Once 
> that is done i'll have time to maybe get a basic als
decoder and some code 
> refactoring done. Also there is that TAK reversing
thing.......... 

There's a bunch of closed-source, NIH-suffering lossless
audio codecs
that are not worth looking at and TAK is one of them IMO
(well, IIRC the author
promised to release specs somewhere in the distant future).

At least your (ALS) encoder quality should be better than
mine (AAC).
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

On Sun, Mar 30, 2008 at 08:34:18AM -0400, Justin Ruggles
wrote:
> Jai Menon wrote:
> > On Sunday 30 March 2008 08:48:52 Benjamin Zores
wrote:
> >> Jai Menon a écrit :
> >>> Hi,
> >>>
> >>> I started some basic work on the MPEG4 ALS
encoder and I get the feeling
> >>> that I could reuse a lot of code from the
flac encoder. So
> >>> (hypothetically ) if I
were to submit a patch, is it okay if I move
> >>> some code out of flacenc.c to a shared
source file?
> >> IIRC we don't even have a decoder for that
atm.
> >> Do you have a working ffmpeg decoder for that
or are you using the
> >> closed mp4alsRM19 binary ?
> > 
> > Very correct. It would be more sensible to write a
decoder for  libavcodec 
> > before pursuing this. But this "work" on
the encoder is with reference to the 
> > GSoC task. I'm using the RM20 reference decoder
and it suits my current 
> > purpose. Also i think that the encoder would be
tested/verified against the 
> > reference.
> 
> A decoder, in this case, is a much larger task since
ALS has several
> different optional extensions that would have to be
supported.  If you
> feel that you are up to the task, by all means submit a
proposal.  I
> chose to suggest an encoder because it is more flexible
as far as the
> timeframe, and therefore much more likely to make it to
SVN by the end
> of the summer.

I've looked at it once. Seems the most features are for
floating-point
mode, baseline decoder should be comparatively easy.
Especially if you
are the person who writes encoder to it ;)

Too bad the spec costs money and available drafts allow you
to write
some hybrid between LPAC and ALS. At least we have the
reference
decoder and encoder sources.
 
> > I have submitted what i hope will be the final
patch for my qual task. Once 
> > that is done i'll have time to maybe get a basic
als decoder and some code 
> > refactoring done. Also there is that TAK reversing
thing.......... 
> 
> I agree with Kostya that we should not try to
reverse-engineer TAK.
> 
> -Justin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

On Sun, Mar 30, 2008 at 09:44:51AM -0400, Justin Ruggles
wrote:
> Kostya wrote:
[...]
> > 
> > I've looked at it once. Seems the most features
are for floating-point
> > mode, baseline decoder should be comparatively
easy. Especially if you
> > are the person who writes encoder to it ;)
> 
> It has 2 entropy coders, plus another for
floating-point.  It has 2 ways
> of doing multi-channel.  There are also several
prediction methods.  The
> spec does not specifically say what is
"baseline" vs. extended, but it
> would be simple enough to break down the task.

IIRC, both entropy coders are VLC - classical Shannon-Fano
scheme and
classical Golomb codes. Prediction is also standard LPC and
RLS, the latter
is quite rare in codecs though (MLP, APE, TTA ?).

And yes, they overlooked the possibility to define
baseline.

Also it leads me to the thought LPAC author just included an
alternative
to each encoding step to (dis)satisfy all 
 
> > Too bad the spec costs money and available drafts
allow you to write
> > some hybrid between LPAC and ALS. At least we have
the reference
> > decoder and encoder sources.
> 
> I have paid for the spec.  If this becomes an SoC
project, I will share
> it only with the student.  I won't make it publicly
available though.
> 
> -Justin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

On Sunday 30 March 2008 13:55:49 Kostya wrote:
> On Sun, Mar 30, 2008 at 09:44:51AM -0400, Justin
Ruggles wrote:
> > Kostya wrote:
>
> [...]
>
> > > I've looked at it once. Seems the most
features are for floating-point
> > > mode, baseline decoder should be
comparatively easy. Especially if you
> > > are the person who writes encoder to it ;)
> >
> > It has 2 entropy coders, plus another for
floating-point.  It has 2 ways
> > of doing multi-channel.  There are also several
prediction methods.  The
> > spec does not specifically say what is
"baseline" vs. extended, but it
> > would be simple enough to break down the task.
>
> IIRC, both entropy coders are VLC - classical
Shannon-Fano scheme and
> classical Golomb codes. Prediction is also standard LPC
and RLS, the latter
> is quite rare in codecs though (MLP, APE, TTA ?).
 and iirc golomb rice codes are used only for the tail end
residuals, those in 
center are encoded using block gilbert-moore
codes........but i may be wrong

Regards
Jai Menon
<realitymangmx.net>

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

On Sun, Mar 30, 2008 at 08:53:12PM +0000, Jai Menon wrote:
> On Sunday 30 March 2008 13:55:49 Kostya wrote:
> > On Sun, Mar 30, 2008 at 09:44:51AM -0400, Justin
Ruggles wrote:
> > > Kostya wrote:
> >
> > [...]
> >
> > > > I've looked at it once. Seems the most
features are for floating-point
> > > > mode, baseline decoder should be
comparatively easy. Especially if you
> > > > are the person who writes encoder to it
;)
> > >
> > > It has 2 entropy coders, plus another for
floating-point.  It has 2 ways
> > > of doing multi-channel.  There are also
several prediction methods.  The
> > > spec does not specifically say what is
"baseline" vs. extended, but it
> > > would be simple enough to break down the
task.
> >
> > IIRC, both entropy coders are VLC - classical
Shannon-Fano scheme and
> > classical Golomb codes. Prediction is also
standard LPC and RLS, the latter
> > is quite rare in codecs though (MLP, APE, TTA ?).
>  and iirc golomb rice codes are used only for the tail
end residuals, those in 
> center are encoded using block gilbert-moore
codes........but i may be wrong

Just to clarify - Rice codes are one case of Golomb codes
and yes, they are
used for large values in ALS.

Block Gilbert-Moore codes are another name for Shannon-Fano
codes and
respect Shannon more than that RealNetworks engineer who
suggested that
coding scheme and name for ALS.
 
> Regards
> Jai Menon
> <realitymangmx.net>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel