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 answer.
Adam
---------- 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@mchp.siemens.de To: adamli@icsl.ucla.edu Cc: ITU-SG16@mailbag.cps.intel.com; "'Guenther Liebl'" liebl@lnt.e-technik.tu-muenchen.de Sent: Friday, October 06, 2000 8:33 AM Subject: difficulty within the UCLA proposal "Generic Uneven Level Protection(ULP)"
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 protection levels need to be grouped in such a way that when data in one packet protected 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 found a simple loss situation, for which the above statement does not seem to
hold
anymore: 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
related
to ULP #2), which should definitely be recoverable then. Thus, we would be able to overcome the loss in packet #2 at protection
level
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),
if
this conclusion is correct, or if we have misunderstood something?
Although Figure 1 only contains a simple example, we think that obeying
the
above statement at each step while constructing a suitable and effective protection
strategy
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,
such
that all participants of the group can evaluate how complex the choice of
a
good 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@mailbag.intel.com