[Mp4-tech] Re: [Audio] a few questions with regard to MPEG-2 AAC
Ralph Sperschneider
ralph.sperschneider iis.fraunhofer.de
Fri Dec 1 17:35:15 ESTEDT 2006
Dear Yueshi,
Yueshi Shen wrote:
> 1) crc_check
>
> In page 42, the spec says "CRC error detection data generated as
> described in ISO/IEC 11172-3, subclause 2.4.3.1 <http://2.4.3.1>".
> However, in the corresponding section of the MPEG-1 Audio, apart from
> the CRC-check calculation algorithm, the protected fields are also
> defined (and they differ for Layer I, II, and III). So I am wondering
> what is the CRC-check protected range for MPEG-2 AAC?
>
You might have overlooked the information provided for the
adts_error_check():
adts_error_check() The following bits are protected and fed into the CRC
algorithm in order of their appearance:
• all bits of adts_fixed_header()
• all bits of adts_variable_header()
• first 192 bits of any
o single_channel_element()
o channel_pair_element()
o coupling_channel_element()
o lfe_channel_element()
• First 128 bits of the second individual_channel_stream() in the
channel_pair_element() must be protected.
• All information in any program_config_element() or
data_stream_element() must be protected.
For any element where the specified protection length of 128 or 192 bits
exceeds its actual length, the element is zero padded to the specified
protection length for CRC calculation. The id_syn_ele bits shall be
excluded from CRC protection. If the length of a CPE is shorter than 192
bits, zero data are appended to achieve the length of 192 bits.
Furthermore, if the first ICS of the CPE ends at the Nth bit (N<192),
the first (192 - N) bits of the second ICS are protected twice, each
time in order of their appearance. For example, if the second ICS starts
at the 190th bit
of CPE, the first 3 bits of the second ICS are protected twice. Finally,
if the length of the second ICS is shorter than 128 bits, zero data are
appended to achieve the length of 128 bits.
> 2) adts_buffer_fullness
>
> In page 45, the mechanism of generating adts_buffer_fullness is
> described. I guess it's a similar idea as VBV buffer in MPEG video, so
> it's a control mechanism for output's timing.
>
The buffer fullness is rather for decoder input buffer control on a
constant rate channel than for output's timing. The output timing is
however affected indirectly, since the decoder has to start the audio
output such that in no circumstances an underrun or overrun of the
decoder input buffer will occurs.
>
> 3) padding audio frames
>
> One of the fill_element()'s usages is to keep every audio frame same
> length.
>
No, this is not true. There is no reason to keep every audio frame at
the same length. Padding using fill_element()'s is usually only
performed on the encoder site when otherwise an underrun of the decoder
input buffer would occur.
Best regards,
Ralph
--
Dipl.-Ing. Ralph Sperschneider | Phone: +49 9131 776 344
Fraunhofer IIS | Fax: +49 9131 776 398
Am Wolfsmantel 33 | mailto:ralph.sperschneider iis.fraunhofer.de
D 91058 Erlangen | http://www.iis.fraunhofer.de/amm/
More information about the Mp4-tech
mailing list