Subject: [AVT] Question about RFC 2733 and Reed Solomon code

From: Weiyu Wang <[email-masked]>
Date: Mon, 8 Aug 2005 13:45:19 -0700 (PDT)

Hi,

I am currently reading the RFC 2733, An RTP Payload
Format for Generic Forward Error Correction. 

And we did some test using the Reed Solomon algorithm
and it did pretty well.

We are considering using this RFC along with this Reed
Solomon algorithm.

However, we noticed a limitation.
In order to generate FEC packet, RTP data packets must
be put into a buffer according to section 7, on 
page 9. However, the first several fields (Padding
Bit, Extension bit, CC bits, Marker bit, Payload type)
are 14 bits long, not on byte boundary. But our Reed
Solomon algorithm is based on byte-aligned buffers.
This requires shifting all following fields to fill
the 2-bit space. 

Moreover, since the first 14 bits are not on word 
boundary, how can I specify the "most significant bit"
for the Padding Bit?

Thank you!

____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 Aug 2005 11:16:59 +0100

Weiyu,

The RFC 2733 format does not support Reed-Solomon codes; you need to  
use a different payload format. There was a proposal for such a  
format, although it has now expired: http://www1.ietf.org/ 
proceedings_new/04nov/IDs/draft-ietf-avt-uxp-07.txt

Alternatively, a mechanism such as that described in draft-watson- 
tsvwg-fec-sf-00.txt might be appropriate.

Colin