[Mp4-tech] [Audio] Re: SBR decoding

Yueshi Shen shenyueshi gmail.com
Thu Jan 18 10:49:02 ESTEDT 2007


Dear Andreas and Devial,
May I add one comment to Andreas' reply: in 14496-3:2005, subpart 4,
4.5.2.8.2.1, page 105, it says:"Prior to SBR decoding, a SBR header part
must be present. As long as no SBR header part is present, the SBR decoder
performs upsampling and delay adjustment only. In continuous broadcast
applications, SBR extension data elements with an SBR header part are
typically sent twice per second."
Moreover, I wish to ask another question: If there's a situation that an
AAC+ decoder has already seen SBR headers, a new SBR comes along and such a
SBR makes the decoder perform upsampling only, as if no header has ever been
seen.  This will be useful when we insert blank audio frames into the middle
of an AAC+ bitstream, as we know a blank AAC+ frame without SBR will be
decoded at a lower sampling frequency.  How can I construct such a
"upsampling-only" SBR?
Thanks a lot.
Sincerely
Yueshi
mp4-tech-bounces lists.mpegif.org wrote on 16.01.2024 18:12:11 :
> Devilal,
>
> the MPEG-4 audio standard has the answer to 1 and 2:
> an extension_type of 0 means that this is simply fill data. Such elments
> may be inserted by the encoder to prevent overflows of its bit-buffer.
> They do not contain data that is relevant to decoding.
> regarding 3: This is outlined in more detail in the SBR conformance
> standard (ISO/IEC 14496-4:2004/Amd.8:2005). The conformance testing
> procedure needs this layout of the data.
>
> Regards,
>
> Andreas

mp4-tech-bounces lists.mpegif.org wrote on 16.01.2024 11:54:40:
> Hi,
> I am doing SBR decoding with some streams downloaded from ISO
> website. Some of the streams are: al_sbr_cm_48_1.mp4,
> al_sbr_cm_48_2.mp4, al_sbr_e_44_2.mp4, al_sbr_i_44_1.mp4,
> al_sbr_ps_02.mp4(this steams has Parametric Stereo also),
> al_sbr_sig_48_2_sig1.mp4 and al_sbr_sr_24_2_fsaac12.mp4.
>
> I have a couple of questions related to SBR decoding:
>
> 1. In one frame the following syntactic elements are coming -
> ID_CPE/ID_SCE i.e Channel Pair Element(for Stereo) or Single Channel
> Element(for Mono)
> ID_FIL - Fill Element
> ID_FIL - Fill Element
> ID_END - to end the syntactic elements
>
> My question is why do u need fill elemets two times?
>
>
> 2. The fillExtType being decoded is 13 for fist call of fill element
> and is 0 for second time.
> I understand that 13 is corresponding to EXT_SBR_DATA and 14 for
> EXT_SBR_DATA_CRC i.e. SBR with CRC which has 10 extra bits in the
> SBR Extension data element. I assume that we have streams without
> CRC check, so, the number 13 is corresponding to EXT_SBR_DATA and is
correct.
>
> But what is the significance of second fill elements in the
> syntactic elements? Moreover, it does not do anything in the
> decoding as it always decodes 0 as fillExtType.
>
>
> 3. In case of fillExtType == 13 (the first time decoding of fill
> element) it does decode SBR header_flag bit and it is always 0 .
> After knowing that header_flag is 0 (i.e. header_flag NOT SET), the
> decoder does not decode SBR header and it just does up-sampling and
> not SBR decoding(i.e. HF Generation, HF Adjustments and other steps).
>
> This is happening with all the streams I mentioned above. The
> reference software from ISO i.e. mp4mcDec is also doing the same
> thing. Is this correct decoding for these streams or something wrong
> with my decoding? Are there other streams for SBR decoding which
> follow the missing decoding in the current case?
>
> --
> Regards,
> Devilal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/mp4-tech/attachments/20070118/04a97fa8/attachment.html


More information about the Mp4-tech mailing list