[FFmpeg-devel] [RFC] SBR implicit signaling

Michael Niedermayer michaelni
Fri Dec 18 02:38:18 CET 2009

On Thu, Dec 17, 2009 at 05:16:50PM -0500, Alex Converse wrote:
> Hi everyone,
> I'm looking for some input on SBR signaling. First, a quick primer on
> SBR signaling:
> AAC+SBR supports 3 different ways to signal the presence of SBR to the decoder.
> 2. Backward Compatible Explicit Signaling: The exensionAudioObjectType
> is set to SBR in the AudioSpecificConfig (the mp4a global header).
> This is obviously not compatible with ADTS.
> 1. Hierarchical Explicit Signaling: The first AOT signaled in the
> AudioSpecificConfig is SBR. This also is obviously not compatible with
> 0. Implicit Signaling: No notification of SBR is present in the
> headers. The AudioSpecificConfig/ADTS sample rate is the core AAC
> sample rate. Detection of implicitly signaled SBR is required for all
> HE AAC profile decoders.
> Handling the two explicitly signaled cases are trivial. Implicit
> signaling presents more of a problem. There is no way to detect the
> presence of SBR without examining and possibly decoding the first
> audio frame. Furthermore the bulk of the conformance streams are
> implicitly signaled.
> FAAD2 appears to extend the HE-AAC Level 3/4 caveat[1] and decode all
> stream of AAC sample rate <= 24 kHz at twice their AAC sample rate (by
> using SBR's pure upsampling mode if no SBR data is present) and all
> streams of AAC sample rate > 24 kHz at their AAC sample rate (By using
> downsampled SBR if SBR is present).
> Increasing the sample rate in AVCodec.decode() (aac_decode_frame())
> appears to be too late.
> Any input on how to handle implicitly signaled SBR would be welcome.
> [1] "NOTE 1: For level 3 and level 4 decoders, it is mandatory to
> operate SBR in a downsampled mode if the sampling rate of the AAC core
> is higher than 24 kHz. Hence, if SBR operates on a 48 kHz AAC signal,
> the internal sampling rate of SBR will be 96 kHz, however, the output
> signal will be downsampled by SBR to 48 kHz."

I would suggest the following solution:
Add a sbr field to AVCodecContext, some description like
0 -> (encoding) leave decission to encoder
     (decoding) not yet known
1 -> enabled
-1-> disabled
(could have more values if theres are multiple modes, especially when
 the user might want to select them for a future SBR encoder)

then set it appropriately in decoder or parser at whatever point it can be
make sure has_codec_parameters() returns 0 when AAC && sbr==0

The alternative i could see is to make sure samplerate=0 until sbr
can be decided but this may (or may not) be tricky because demuxers would
have to be prevented from setting it one way or another.
That said iam not sure which approuch is better, the first seems clearer
and i think i slightly prefer it
but having samplerate wrong for a brief period could cause problems as
well if some code uses it ...

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20091218/33671cc9/attachment.pgp>

More information about the ffmpeg-devel mailing list