Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: SBR decoding (Read 2227 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

SBR decoding

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?