Subject: RE: [AVT] WGLC: draft-ietf.avt-ulp-19.txt

From: "Allison, Art" <[email-masked]>
Date: Thu, 30 Nov 2006 09:19:34 -0500

>From work in other fora, I have seen some indications that AVC has a
lower tolerance for errors than MPEG-2. Has anyone made a determination
of the difference over these phy? It seem to me that RS may be 'needed'
more when there are fewer information bits representing each frame of
video.
I find the post asserting that RS is the appropriate FEC persuasive.
Art

_____________
Art Allison
Director, Advanced Engineering
Science & Technology
National Association of Broadcasters
1771 N Street, NW
Washington, D.C. 20036
Phone: 202.429.5418
Fax: 202.777.4981
[email-masked]

The National Association of Broadcasters is a trade association that
advocates on behalf of more than 8,300 free, local radio and television
stations and also broadcast networks before Congress, the Federal
Communications Commission and the Courts.

-----Original Message-----
From: Stephan Wenger [mailto:[email-masked]] 
Sent: Thursday, November 30, 2006 7:39 AM
To: Colin Perkins
Cc: Even, Roni; Botzko,Stephen; [email-masked]
Subject: Re: [AVT] WGLC: draft-ietf.avt-ulp-19.txt

Hi Colin, all,

On Nov 28, 2006, at 6:08 PM, Colin Perkins wrote:

> [...]
> No - given the advances since RFC 2733 was published, I think it 
> worthwhile to include further justification and explanation of where 
> this fits in with other FEC schemes.

Some fairly advanced media formats offer tricks that in our view allow
to employ simple XOR FEC (only) without significant delay increase.  We
(Nokia) have proposed such tricks in 3GPP SA4. There, we protect two
important media packets (whatever that means for the  
specific media codec) with one FEC packet.   I don't want to re- 
create ongoing discussions in SA4 here, where the usefulness of our
trick is challenged, but I can provide pointers to documents for those
interested.  (Please contact me in private.  We also have academic work
in preparation, which should be available in the foreseeable future).

IMHO, there is little point in evaluating Reed-Solomon or any other
"higher" FEC code for an RTP payload format.  If your delay tolerance is
such high that you can afford multiple repair packets per FEC block, go
use fecframe WG's technology, or use feedback based repair (whatever
fits your application better).  When using only a single repair packet
per FEC block, there is no difference between XOR FEC and the other FEC
schemes.

With respect to the uneven protection feature, and in response to
Stephen: yes, there are media formats that could employ uneven
protection.  Examples include G.723.1 with Annex C enabled, H.263 with
Annex V enabled, H.264 in extended profile or in baseline when
RFC3984 aggregation packets are used, and these packets are populated in
a smart way.  Yes, no one is using any of these in the way they could be
used, but are we all sure that's not a chicken-and-egg problem?

In consequence, let me speak in favor of moving the ULP draft finally
forward.  Yes, there is value in adding some discussion why Reed-
Solomon (or any higher FEC code) does not make much sense, perhaps along
the lines of point 1 above.  But then, PLEASE, let's call it a day.  18
revisions are enough.

Regards,
Stephan

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Thu, 30 Nov 2006 18:04:20 +0200

>lower tolerance for errors than MPEG-2.

This sounds incorrect - AVC has many more error resilient coding tools
than MPEG-2. 

BR, YK

--------------------------------------------------------------------- 
  Ye-Kui Wang 
  Senior Research Engineer, Ph.D 
  Multimedia Technologies Laboratory
  Nokia Research Center 
  P.O. Box 100, FIN-33721 Tampere, Finland 
  Visiokatu 1, 33720 Tampere, Finland 
  Mobile: +358-50-486-7004 
  Fax: +358-7180-35935 
---------------------------------------------------------------------

---

From: Mark Watson <[email-masked]>
Date: Thu, 30 Nov 2006 10:46:31 -0800

Art,

The properties of RS that make it appear appealing compared to  
RFC2733/ULP are essentially:
(1) you can support larger block sizes
(2) it is MDS - that is for an (N ,K) code receipt of any K packets  
from the N packets sent allows recovery of the original K packets

However, RS has some other properties which are not so appealing,  
specifically a practical limit in these applications on the total  
source + repair symbols than 255 symbols and, most significantly,  
computational complexity.

Noone will be surprised that I might mention that there exist codes  
which are more flexibility in terms of block size, lower  
computational complexity and "close-to-MDS" error correction. Other  
standards bodies which have looked at FEC for streaming (specifically  
3GPP and DVB) have chosen those, rather than just simple parity codes  
(such as RFC2733) or Reed-Solomon codes.

Also, although AVC provides many tools that could provide for  
enhanced error concealment, mainly people are interested in its  
improved compression capabilities, which means each bit of  
transmitted data contains more actual information and thus causes  
more problems when lost. So, AVC does not have lower error tolerance  
per se, but simple the better compression you have the worse the  
effect of each lost bit.

...Mark

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 30 Nov 2006 12:39:40 -0800

>standards bodies which have looked at FEC for streaming 
>(specifically 3GPP and DVB) have chosen those, rather than just 
>simple parity codes (such as RFC2733) or Reed-Solomon codes.

Of course, for completeness, one should also mention that these other 
codes do have at least one potential drawback - namely, that they are 
encumbered :-)

	Ross.

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 1 Dec 2006 06:29:31 +0200

On Nov 30, 2006, at 10:39 PM, Ross Finlayson wrote:

>> Noone will be surprised that I might mention that there exist  
>> codes which are more flexibility in terms of block size, lower  
>> computational complexity and "close-to-MDS" error correction.  
>> Other standards bodies which have looked at FEC for streaming  
> Of course, for completeness, one should also mention that these  
> other codes do have at least one potential drawback - namely, that  
> they are encumbered :-)

Indeed.  To make the picture even more complete: RFC 2733 and the ULP  
draft are also encumbered, see declaration #339.

Regards,
Stephan