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

Andreas Schneider Andreas.Schneider codingtechnologies.com
Thu Jan 18 12:03:30 ESTEDT 2007


Hello Yueshi,
please see below.
"Yueshi Shen" <shenyueshi gmail.com> wrote on 18.01.2024 00:49:02:
> 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? 

Such a situation can not really occur, at least not in a bitstream that is 
fully standard compliant.
If an SBR header was present once, then this very SBR header conveyed the 
settings that must be used to decode the SBR bitstream. These settings 
will stay in effect upto the point in time when a new - potentially 
different header arrives.
If the new header is valid, then the decoder will not switch to upsampling 
but uses this header instead.
If the new header is not valid, the decoder may do anything, as there is 
no normative behaviour for such a case.
Regards,
Andreas
> 
> 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
> 
--
Andreas Schneider
Senior Research Engineer
mailto:snd CodingTechnologies.com
+49 911 92891 -26 (phone)
+49 911 92891 -99 (fax)
Coding Technologies GmbH
Deutschherrnstr. 15-19
D-90429 Nuernberg, Germany
http://www.codingtechnologies.com


More information about the Mp4-tech mailing list