FW: [Mp4-tech] [Audio] CRC check in MPEG-4 ADTS stream

[MPEGIF List Admins]

Forwarding non-member reply that was auto-discarded.
Thanks for the replay, and please remember to subscribe with your sending
address (or to send from your subscribed account).
the admins.
-----Original Message-----
From: Alexander Groeschel
[mailto:Alexander.Groeschel codingtechnologies.com] 
Sent: Monday, 17 April 2024 23:06
To: klaus.raffold gmail.com
Cc: mp4-tech lists.mpegif.org
Subject: Re: [Mp4-tech] [Audio] CRC check in MPEG-4 ADTS stream
Hi Klaus,
mp4-tech-bounces lists.mpegif.org wrote on 04/17/2006 03:35:02 PM:
> Hi Experts,
> 
> This is about implementing CRC check in MPEG-4 ADTS bitstream. 
> 
> The ISO/IEC 13818-7 (MPEG-2 AAC) standard, where the ISO/IEC 14496-3, 
subpart-1(MPEG-4 Audio) cross refers to for details on MPEG-4 ADTS, states 
that ... 
> 
> "
> ...
> 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 
appearence. 
> ...
> "
> 
> What i understand from this is that, i have to parse the received 
bitstream to find out which of the bits in the stream are CRC protected 
and in what way. This means, that I have to start 
> interpreting the bits in the stream even before I get to know whether 
they are corrupted or not. 
Yes, unfortunately that's the case.
> My parsing can go completely heywire if i start interpreting corrupted 
bits. 
Right.
> In that case what error protection does CRC offer in MPEG-4 ADTS stream 
?? 
If the frame is corrupted, you still (with a certain security) will know 
at the end that it's corrupted. But you're right, you waste time on 
useless parsing attempts.
> OR is my understanding incomplete, or am I 
> missing something ?? 

There was an attempt inside MPEG to change this definition, which didn't 
get approved - mainly because at that time chips already existed that 
implemented this weired CRC calculation. Instead, the clarificaton cited 
by you was added to the text.
> 
> Thanks and regards,
> klaus

Hope this helps,
regards,
alex.
----------------------------
Alexander Gröschel
Senior Research Engineer 
Coding Technologies GmbH
+49 911 928 91 21 (phone)
+49 911 928 91 99 (fax)
Deutschherrnstraße 15 - 19, 
D-90429 Nürnberg, Germany
mailto:gel codingtechnologies.com 
http://www.codingtechnologies.com
------------------------------------------------------------------------