APC-1952 liaison from BICC/11
ggf at AVAYA.COM
Fri Oct 6 12:10:19 EDT 2000
Dear Mr. Gero,
Thank you very much for your email. However, under the situation you
discribed, the statement does hold.
In the example illustrated by Figure 1 of APC-1905, the second part of the
Packet #3 is not protected by ULP #2. Indeed, it is not protected by any
ULP. In this example, if Packet #3 is lost, the second part will not be
recoverable no matter the first part is recoverable or not. The statement
does hold in the situation you described.
The statement about the grouping rules in the document is describing one
mportant general principles for any efficient forward error correction
scheme. It is nice to know that Mr. Gero agrees on the same principle. We
are not intending to claim that the grouping rules in APC-1905 absolutely
guarantees the property, however, the scheme described in APC-1905 is much
more efficient in this aspect than most interleaving schemes. For example,
in a interleaving scheme proposed in APC-1841, even correctly transmitted
data will have to be discarded because of the holes in rearranged packets.
Hope this helps. If you have any more difficulties, I would be happy to
Adam H. Li, Ph.D.
Image Communication Lab (310) 825-5178 (Lab)
University of California, Los Angeles (310) 825-7928 (Fax)
----- Original Message -----
From: "Baese Gero" <Gero.X.Baese at mchp.siemens.de>
To: <adamli at icsl.ucla.edu>
Cc: <ITU-SG16 at mailbag.cps.intel.com>; "'Guenther Liebl'"
<liebl at lnt.e-technik.tu-muenchen.de>
Sent: Friday, October 06, 2000 8:33 AM
Subject: difficulty within the UCLA proposal "Generic Uneven Level
> Dear authors,
> While studying your last ITU-proposal APC-1905, "Generic Uneven Level
> Protection (ULP)"
> for Annex I of H.323, which had been submitted for the Portland meeting in
> August, we
> discovered a mismatch between one of the major features stated and the
> simple example given in Figure 1.
> On page 3, you state in section "Protection procedure" that
> "In order to achieve more efficient usage of the channel bandwidth, the
> levels need to be grouped in such a way that when data in one packet
> by level p are recoverable, all the data of the same packet protected by
> level below p
> are recoverable."
> We definitely agree on this feature, since we are both interested in
> protecting any type
> of progressive or prioritized media stream most efficiently!
> However, when considering your example in Figure 1 on the next page, we
> a simple loss situation, for which the above statement does not seem to
> Let us assume that out of the seven given packets, exactly (information)
> packets #2 and #3
> are lost, but all the others have been received correctly. Since packets
> #1-#3 are only
> protected with one single FEC packet, ULP #1, at level L_0, the leftmost
> part of the
> lost packets #2 and #3 can definitely not be recovered anymore.
> If we now consider the protection strategy for level L_1, we see that the
> second part of
> packets #1, #2, #4, and #5 are protected via the respective part of FEC
> packet, ULP #2. But
> only the part belonging to packet #2 has been lost (packet #3 is not
> to ULP #2),
> which should definitely be recoverable then.
> Thus, we would be able to overcome the loss in packet #2 at protection
> L_1, but
> not at level L_0, which is a contradiction to the above statement.
> Can you please tell us (and possibly all other interested participants),
> this conclusion
> is correct, or if we have misunderstood something?
> Although Figure 1 only contains a simple example, we think that obeying
> above statement
> at each step while constructing a suitable and effective protection
> can be
> quite difficult. If you think that this is not the case at all for your
> proposal, it
> would be probably best to specify your coding principle in more detail,
> that all participants of the group can evaluate how complex the choice of
> protection scheme can be.
> Thanks a lot in advance,
> Gero Baese
> Guenther Liebl
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd