[Mp4-tech] [Audio] Erroneous bit streams...
Ralph Sperschneider
ralph.sperschneider iis.fraunhofer.de
Fri Dec 1 16:31:50 ESTEDT 2006
guhapriya ganapathy wrote:
> Hi Umang,
> That being the case, why aren't there any erroneous bitstreams
> available in the market to validate the robustness of the decoder?
> Only CT provides a set of erroneous bitstreams for SBR part of HEAAC
> as a part of its certification package.
> As such, ISO has no erroneous bitstreams for AAC.
> Regards,
> Guha Priya.
>
> */Umang Garg <ugarg neomagic.com>/* wrote:
>
> Guha, Sris
> While HEAAC for broadcast environments mandates the CRC check in
> ADTS format, it usage appears to be quite redundant with little
> practical advantage. It existence may have more to do with legacy
> reasons.
> The redundancy arises from the fact that the CRC validation of the
> bitstream cannot happen untill the stream has been parsed upto a
> specified number of bits. If the bitstream is corrupted in the
> 'right' places then it is possible that the parsing process can go
> haywire. This implies that you may not interpret the bits
> correctly and the parsing may take a completely different control
> flow path. It is a chicken-and-egg situation.
> Your best bet lies in the ability to handle serious corruption
> issues at network level. Minor bitstream distortions can then be
> handled inside the decoder by having a robust error handling
> mechanism along with CRC check.
> Regards,
> Umang
>
> ------------------------------------------------------------------------
> *From:* mp4-tech-bounces lists.mpegif.org
> [mailto:mp4-tech-bounces lists.mpegif.org] *On Behalf Of
> *%Sriskanthan Nadarajah
> *Sent:* Monday, May 22, 2024 8:20 PM
> *To:* guhapriya ganapathy; mp4-tech lists.mpegif.org
> *Subject:* RE: [Mp4-tech] [Audio] Erroneous bit streams...
>
> Hi Guha Priya.
> The CRC should be checked and error passed before passing the
> stream to the Codec.
> *Sris*
> **
> *WINUX Interfacing Technology Pte. Ltd.*
> Tele: (65) 6794-3069 H/P 92763116
> Com. Reg. No: 200303307W
> www.winux-it.com
>
> ------------------------------------------------------------------------
> *From:* mp4-tech-bounces lists.mpegif.org on behalf of
> guhapriya ganapathy
> *Sent:* Mon 5/22/2006 1:45 PM
> *To:* mp4-tech lists.mpegif.org
> *Subject:* RE: [Mp4-tech] [Audio] Erroneous bit streams...
>
> Hi Umang,
> In case of a packet loss, it is fine. We may have to make our
> own decisions.
> Coming to bitstream corruption, what is the probability of the
> corrupted bitstream reaching the codec? When a corruption is
> detected at the network layer by the CRC, is it being dropped?
> If so, what is the need for CRC in the codec?
> Regards,
> Guha Priya.
>
>
> */Umang Garg <ugarg neomagic.com>/* wrote:
>
> Hello Guha,
> In broadcast environment you may encounter packet loss and
> stream corruption as two primary errors.
> For HEAAC:
> Stream corruption may be checked via CRC. ADTS format has
> a CRC check along with a separate CRC check for SBR decoding.
> Similarly, packet loss may also have to be handled
> gracefully within the decoder. In case of a loss of
> frame(s) the simplest technique is insertion of a silence
> frame (to maintain synchronization) but a more appropriate
> technique would be gradual muting. As far as I know, the
> HEAAC standard does not say much about packet loss in
> general or the muting technique in particular. You may
> have to make your own decisions on that.
> Regards,
> Umang
>
> ------------------------------------------------------------------------
> *From:* mp4-tech-bounces lists.mpegif.org
> [mailto:mp4-tech-bounces lists.mpegif.org] *On Behalf
> Of *guhapriya ganapathy
> *Sent:* Thursday, May 18, 2024 5:19 PM
> *To:* mp4-tech lists.mpegif.org
> *Subject:* [Mp4-tech] [Audio] Erroneous bit streams...
>
> Dear all,
> Suppose you have an audio codec which is a part of a
> broadcast system (any system for that matter). What
> are the possible errors that might creep in the
> bitstream when it reaches the decoder? (There will be
> CRC check for each packet in the network layer, but I
> am concerned about the bitstream when it reaches the
> decoder.. what are the chances that the bit stream is
> corrupted?)
> Taking AAC HE as an example, Coding Technologies
> provides erroneous bitstreams for SBR (although SBR
> has CRC check) as a part of its certification package
> (wherein for example one bit in every third frame is
> corrupted - a random corruption!), whereas ISO does
> not(?) provide erroneous bitstreams. Of what value are
> erroneous bitstreams to the decoder? Is there a value
> add in generating *erroneous* bitstreams for decoders?
> If so, what is the approach so that it matches what
> happens in the real time?
> Regards,
> Guha Priya.
>
> __________________________________________________
>
Dear all,
with regard to MPEG: MPEG just cares about the correct decoding of error
free (i.e. conform) compressed data (in that case: audio data). The
handling of corrupt data is for MPEG out of scope.
Background: The availability of errors depends on the application -
there might be applications that do not have to deal with errors in the
bitstream payload, while others have to.
However: MPEG provides means to detect and even correct errors, and to
exploit the derived data as much as possible. The tools of choise are
the error resilient bitstream syntax (that subdivides the bitstream
payload in several error sensitivity categories), the usage of the EP
tool (that provides flexible error detection and correction means) and
the application of the error resilience tools available for distinct
codecs (particularly for AAC).
Possible errors depend on the application scenario. In general, any bit
might be corrupt. In practice, one might not want to conceal any frame
just if a single bit error occurred. Assume that each frame would have a
single bit error (random BER 10^-3 at a frame length of 1000 bit): When
applying only frame concealment this would lead to silence. Having a
closer look into the bitsteam you will find that bit errors on certain
places might cause severe audio artifacts, while bit errors on other
places might be negligible. An advanced system hence might want to
render the content of erroneous bitsteams ... A first step towards this
effort is of course that the decoder can handle any possible corrupt
bitstream payload.
Hope this helps,
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