Subject: Re: Question on RFC2733, packet-based FEC

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 01 Jun 2000 01:51:23 -0400

Stephan Wenger wrote:
> 
> Hi all,
> 
> I don't understand the reason for an (artificial?) limitation of
> RFC2733.  RFC2733 says that, when calculating FEC over
> several packets of different sizes, the FEC packet has to
> protect all bytes of the biggest packet (and padding is to be
> used for the other packets to bring them up to the size of
> the biggest packet).  Is there some hidden secret about this
> requirement?

The aim is to provide complete recovery of a missing packet, which
results in this requirement.

> 
> The rest of the EMail describes scenarios where this limitation
> is counter-productive.
> 
> In a recent ITU meeting, Adam Li of UCLA brought to our
> attention an idea to implement unequal error protection using
> packet based FEC.  What they want to do is to use data
> partitioning to put important video data (such as headers and
> motion vectors) to the front of a packet, and put the less
> important coefficients to the end.  Then apply packet based
> FEC only on the first (more important) part of the packets.
> Resulting FEC packets are smaller -- lower bandwidth requirements.

This has actually been discussed within IETF. In fact, I think one of
the MPEG-4 over RTP drafts may actually be doing this. We rejected this
from the rfc2733 mechanism, as I recall, because you needed a whole
bunch of additional stuff to indicate what is covered by the FEC, if its
not the whole packet. In the worst case, you'd actually need a bitmap
which is the size of the largest packet, where the bitmap indicates
which bits are protected by FEC. As a result, any general purpose
mechanism for unequal protection would likely require as many bits to
signal as the savings obtained from the unequal protection. Note that
the advantages of this unequal proection is solely reducing packet
sizes.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 01 Jun 2000 10:44:50 +0200

Jonathan,

>the advantages of this unequal proection is solely reducing packet

Well, I believe that, in the future, all video coding schemes will include
data partitioning (DP).  DP allows you to separate the different data
types of video (e.g. motion vectors and coefficients) from each other.
Similarly, a few audio coding schemes such as G.723.1 already identify
bits that are more important for the perceptual quality of reconstructed
audio, and allow to separate those from the other bits.  To arrange
the more important bits at the begin, and the less important bits at
the end of a packet is (or will be in the future) a functionality of the
media coding.  STandards that already allow for this include H.263++
(to be ratified in fall), MPEG-4 visual, and G.723.1.  There might be
more.

If we assume such input data, then there is no need for any additional
signalling of the importance of bits.  The size of the FEC packet would
be the indication of the number of protected bits.

I agree that this is not a 'general purpose' mechanism.  But it is powerful
enough for all practical forms of use I'm currently thinking about.  And
the change would be rather minor -- a mere change of a requirement,
no change in the packet format.  The change would be completely upward
compatible.

I wish I would have thought about this earlier, and payd more attention
to IETF discussions on that.  Now, it's a bit late.  But I feel that we should
consider introducing such a change at the time when RFC2733 is moving
forward from proposed to draft standard status.

Regarding your remark that one of the MPEG-4 drafts is currently addressing
this issue: you're right.  But one reason why this draft does not have
that much support is precisely that it mixes QoS/transport functionality
with simple packetization issues (where architectural cleanness would
suggest separating the problem).

Stephan

---

From: "Adam Li" <[email-masked]>
Date: Thu, 1 Jun 2000 12:57:56 -0700

Hi, there,

Thanks for the discussion on this issue. I should have come to ask for
suggestions from you all earlier. But I just came back from a long
trip oversea, and am quite occupied by my other works recently.

The scheme I proposed is actually very generic and quite simple to
implement. It doesn't make much assumption on the payload it protects,
and probably won't take much overhead to communicate the protection
range and levels. The only thing I am not sure is that if it can be
easily fit in the structure of draft-ietf-avt-fec and
draft-ietf-avt-reedsolomon. Also, it might make sense to have seperate
mechanics for complete and partial recovery of lost packet, since not
all codecs have the capability of benefiting from partial recovered
data packets.

Later today, I will post a document that discribe the proposed scheme,
so you can take a look at the details. I really would appreciate your
suggestions and feedback on if we should incooperate it into
draft-ietf-avt-fec or to start a seperate internet draft on this.

Regards,

Adam Li

----------
Adam H. Li
Image Communication Lab                          (310) 825-5178 (Lab)
University of California, Los Angeles            (310) 825-7928 (Fax)

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, May 31, 2000 10:51 PM
> To: Stephan Wenger
> Cc: [email-masked]
> Subject: Re: Question on RFC2733, packet-based FEC
>
>
>
>
> Stephan Wenger wrote:
> >
> > Hi all,
> >

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 02 Jun 2000 00:55:51 -0400

> all codecs have the capability of benefiting from partial recovered

Well, there is the practical problem that draft-ietv-avt-fec has already
issued as rfc2733, and cannot be changed. 

-Jonathan R.

---

---

From: "Adam Li" <[email-masked]>
Date: Thu, 1 Jun 2000 23:17:11 -0700

Hi, there,

The enclosed is a file which described a proposed scheme for doing
Uneven Level Protection. Please take a look if you have time, and give
me your suggestions and thoughts, and also your advices on whether we
should incooperate it in to the draft-ietf-avt-fec or start a seperate
internet draft with it.

Your help is really appreciated.

Adam Li

----------
Adam H. Li