aac adts input

[Justin Ruggles]

Hello,

I have a question regarding aac audio input that is in ADTS format
rather than MP4 container. FAAC can create it either way, but FFmpeg
only seems to support the mp4 container from what I can determine.
MPlayer, mp4creator (mpeg4ip), and faad all support the ADTS variety.
Am I missing something? If not, would it be a simple patch to add support?

As an odd side note, I have an aac audio clip with samplerate 22050 Hz,
and FFplay is playing it at half-speed. FFplay reports the correct
samplerate...it just sounds funny. When muxed into mp4 with video, it
plays both the audio & video at half-speed. It plays correctly in
MPlayer and with faad.

-Justin

[Måns Rullgård]

Post by Justin Ruggles
Hello,
I have a question regarding aac audio input that is in ADTS format
rather than MP4 container. FAAC can create it either way, but FFmpeg
only seems to support the mp4 container from what I can determine.
MPlayer, mp4creator (mpeg4ip), and faad all support the ADTS variety.
Am I missing something? If not, would it be a simple patch to add support?

The ADTS format is similar to MPEG1 audio, so supporting it should be fairly
easy. Patches are always welcome.

Post by Justin Ruggles
As an odd side note, I have an aac audio clip with samplerate 22050 Hz,
and FFplay is playing it at half-speed. FFplay reports the correct
samplerate...it just sounds funny. When muxed into mp4 with video, it
plays both the audio & video at half-speed. It plays correctly in
MPlayer and with faad.

Upload it to mplayerhq.hu.

[Attila Kinali]

On Tue, 9 Aug 2005 07:46:00 +0100 (BST)

Post by Måns Rullgård
Upload it to mplayerhq.hu.

mphq is currently not fully functional.
Especialy http and ftp are down for the time being.

Attila Kinali

[Justin Ruggles]

Post by Attila Kinali
On Tue, 9 Aug 2005 07:46:00 +0100 (BST)

Post by Måns Rullgård
Upload it to mplayerhq.hu.

mphq is currently not fully functional.
Especialy http and ftp are down for the time being.

In that case.
http://home.earthlink.net/~jruggle/clip.m4a

There's nothing special about the clip that I can tell other than the
fact that it has a samplerate of 22050Hz. I encoded it from a wav file
using faac.

-Justin

[Justin Ruggles]

Post by Justin Ruggles
As an odd side note, I have an aac audio clip with samplerate 22050 Hz,
and FFplay is playing it at half-speed. FFplay reports the correct
samplerate...it just sounds funny. When muxed into mp4 with video, it
plays both the audio & video at half-speed. It plays correctly in
MPlayer and with faad.

I think I've solved this. It seems that faad automatically upsamples
the 22050 Hz to 44100 Hz. The avctx->sample_rate is changed to 44100 by
the faad configuration. The problem lies in that SDL is initialized
before the codec, so it plays at 22050 while faad outputs at 44100.

Patch coming soon.
-Justin

[Justin Ruggles]

Post by Justin Ruggles
Patch coming soon.

And here it is. This patch moves all the SDL audio initialization to
after the codec initialization. I debated just detecting if the codec
init changes the samplerate or number of channels, and if so,
reinitializing SDL with new params. But it seems that moving the entire
SDL portion doesn't do any harm. If anyone disagrees, I can resubmit a
patch doing it the other way.

-Justin

[Michael Niedermayer]

Hi

Post by Justin Ruggles

Post by Justin Ruggles
Patch coming soon.

And here it is. This patch moves all the SDL audio initialization to
after the codec initialization. I debated just detecting if the codec
init changes the samplerate or number of channels, and if so,
reinitializing SDL with new params. But it seems that moving the entire
SDL portion doesn't do any harm. If anyone disagrees, I can resubmit a
patch doing it the other way.

well, if the file stores 22050hz and FAAD resamples it during decoding then
the bug is in FAAD and should be fixed there
if OTOH the file contains 44100hz and the mov headers say its 22050 then
maybe the mov demuxer should avoid using this header value for AAC or
some other solution
but "fixing" ffplay wont help, as ffplay isnt the only application which
uses libav*

[...]

[Benjamin Larsson]

Post by Michael Niedermayer
Hi

Post by Justin Ruggles

Post by Justin Ruggles
Patch coming soon.

And here it is. This patch moves all the SDL audio initialization to
after the codec initialization. I debated just detecting if the codec
init changes the samplerate or number of channels, and if so,
reinitializing SDL with new params. But it seems that moving the entire
SDL portion doesn't do any harm. If anyone disagrees, I can resubmit a
patch doing it the other way.

well, if the file stores 22050hz and FAAD resamples it during decoding then
the bug is in FAAD and should be fixed there
if OTOH the file contains 44100hz and the mov headers say its 22050 then
maybe the mov demuxer should avoid using this header value for AAC or
some other solution
but "fixing" ffplay wont help, as ffplay isnt the only application which
uses libav*
[...]

Also to be taken into consideration is if the file is using SBR, eg
doubbling the frequency. I would guess this is the case here.

MvH
Benjamin Larsson

[Justin Ruggles]

Post by Benjamin Larsson
Also to be taken into consideration is if the file is using SBR, eg
doubbling the frequency. I would guess this is the case here.

some insightful comments from libfaad2/mp4.c:
/* no SBR signalled, this could mean either implicit signalling or no
SBR in this file */
/* MPEG specification states: assume SBR on files with samplerate <=
24000 Hz */

Now it all makes more sense. Here is a much simpler patch.

Just for interest's sake though, should an application be able to assume
that initializing a codec should not modify the AVCodecContext parameters?

-Justin

[Michael Niedermayer]

Hi

Post by Justin Ruggles

Post by Benjamin Larsson
Also to be taken into consideration is if the file is using SBR, eg
doubbling the frequency. I would guess this is the case here.

/* no SBR signalled, this could mean either implicit signalling or no
SBR in this file */
/* MPEG specification states: assume SBR on files with samplerate <=
24000 Hz */
Now it all makes more sense. Here is a much simpler patch.

if i understand this correctly the patch practically discards the high
frequency information for some SBR files? if thats true then the patch
is rejected

[...]

[Justin Ruggles]

Post by Michael Niedermayer
if i understand this correctly the patch practically discards the high
frequency information for some SBR files? if thats true then the patch
is rejected

Yes. For files that intend SBR to be used implicitly due to the fact
that they're 24000Hz or lower. Unfortunately for me, this also results
in the decoder using SBR where it is not intended. That's a limitation
of the aac encoder though... oh well.

So back to my other point, if a file uses SBR, the header will report
the base encoded samplerate, but the decoder will detect SBR and report
the SBR-extended samplerate. Shouldn't ffplay be aware that the decoder
might change the samplerate due to SBR and adjust the SDL output
accordingly? To me that's not working around a bug, but allowing for an
intended feature.

-Justin

[Michael Niedermayer]

Hi

Post by Justin Ruggles

Post by Michael Niedermayer
if i understand this correctly the patch practically discards the high
frequency information for some SBR files? if thats true then the patch
is rejected

Yes. For files that intend SBR to be used implicitly due to the fact
that they're 24000Hz or lower. Unfortunately for me, this also results
in the decoder using SBR where it is not intended. That's a limitation
of the aac encoder though... oh well.
So back to my other point, if a file uses SBR, the header will report
the base encoded samplerate, but the decoder will detect SBR and report
the SBR-extended samplerate. Shouldn't ffplay be aware that the decoder
might change the samplerate due to SBR and adjust the SDL output
accordingly? To me that's not working around a bug, but allowing for an
intended feature.

NO! there is a difference between changing the sampling rate during decoding
and the demuxer setting a wrong sampling rate even though the sampling rate
never changes
the file stores information for 48khz so that is the correct sampling rate
if we add support for audio "low res" then there would bee 2 sampling rates
one at which the file is coded and one which comes out of the decoder

[...]

[Justin Ruggles]

Post by Michael Niedermayer
the file stores information for 48khz so that is the correct sampling rate
if we add support for audio "low res" then there would bee 2 sampling rates
one at which the file is coded and one which comes out of the decoder

So, from what I understand, you're saying that your preferred way of
adding support would be to enhance the demuxer to detect SBR and have
the "correct" samplerate reported there rather than relying on an
external codec?

-Justin

[Rich Felker]

Post by Justin Ruggles

Post by Michael Niedermayer
the file stores information for 48khz so that is the correct sampling rate
if we add support for audio "low res" then there would bee 2 sampling rates
one at which the file is coded and one which comes out of the decoder

So, from what I understand, you're saying that your preferred way of
adding support would be to enhance the demuxer to detect SBR and have
the "correct" samplerate reported there rather than relying on an
external codec?

Correct files with sbr store the full samplerate in the container
headers... Nothing special has to be done at the demuxer level unless
there are broken containers or broken files that store the half-rate
samplerate there..

Rich

[Justin Ruggles]

Post by Rich Felker
Correct files with sbr store the full samplerate in the container
headers... Nothing special has to be done at the demuxer level unless
there are broken containers or broken files that store the half-rate
samplerate there..

ok. So my file is considered broken because it is below 24000Hz,
doesn't specify *not* to use SBR, and reports the half-rate in the
header. So faac needs to be updated, not ffmpeg.
Thanks for the clarification.
-Justin

[Michael Niedermayer]

Hi

Post by Justin Ruggles

Post by Rich Felker
Correct files with sbr store the full samplerate in the container
headers... Nothing special has to be done at the demuxer level unless
there are broken containers or broken files that store the half-rate
samplerate there..

ok. So my file is considered broken because it is below 24000Hz,
doesn't specify *not* to use SBR, and reports the half-rate in the
header. So faac needs to be updated, not ffmpeg.

no, libav* always tries to support as much as possible, no matter
how broken the encoder implementation or in this case probably rather
the mov/mp4 spec is
the mov demuxer must not set the sampling rate for AAC or it must set it
correctly

[...]

[Måns Rullgård]

Post by Justin Ruggles
Just for interest's sake though, should an application be able to assume
that initializing a codec should not modify the AVCodecContext parameters?

No, IMHO. For starters, there are cases where certain information is only
available from the codec layer (think MPEG). I also think it's good if the
application has a chance to detect a discrepancy between parameters from the
container and those from the codec. Which set, if any, is correct is still
not trivial to deduce, of course.

[Rich Felker]

Post by Michael Niedermayer
Hi

Post by Justin Ruggles

Post by Justin Ruggles
Patch coming soon.

And here it is. This patch moves all the SDL audio initialization to
after the codec initialization. I debated just detecting if the codec
init changes the samplerate or number of channels, and if so,
reinitializing SDL with new params. But it seems that moving the entire
SDL portion doesn't do any harm. If anyone disagrees, I can resubmit a
patch doing it the other way.

well, if the file stores 22050hz and FAAD resamples it during decoding then
the bug is in FAAD and should be fixed there
if OTOH the file contains 44100hz and the mov headers say its 22050 then
maybe the mov demuxer should avoid using this header value for AAC or
some other solution
but "fixing" ffplay wont help, as ffplay isnt the only application which
uses libav*

the stuff faad does seems broken, but actually it's comparable to
lavc's "lowres" decoding option. i have the opposite problem with
faad: files with 44100 stored in the header, but faad outputs 22050
because sbr doesn't work with the speed-optimized mode i have to
compile faad with in order to make it use less than 90% cpu.

rich