![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
|
> > First question, are you suggesting
to apply FEC to the combination of a video > and audio RTP stream? > Second question, assuming the above
case is true, I am still not sure why you > need an additional flow carrying
the source payload ids. Is it because there are > two streams? Could you explain? It's not this case that just result in
the need of carrying source play id in additional flow. It is this case to
prove the need of source payload id for RTP flow. Because you need a source
payload id, you gotta transfer it to the client, either in source packet as
current FEC framework specified, or in an additional flow described in our
draft. The latter choice for transferring the source payload is for making
source packet accessible to non-fecframework clients. This table shows an example of multiple flows.
The table depicts the structure of a source block, which is filled up with the
packets (of length 16, 17 19 15 and 8 bytes) from two sequenced flows. The
packets from two flows are identified by flow id 0 and 1, respectively. For FEC
decoding, the receiver needs to know the position of each packet in the source
block. The sequence number can only tell the order of a packet in the flow it
belongs to in the source block. There is no way to tell where a packet exactly
is in the source block. Source Payload ID is thus in this case needed. Would
you please give a solution which is free of source payload id?
Hope this is clear. Zou ZiXuan, Senior Research Staff Media & Communication Lab HUAWEI TECHNOLOGIES CO.,LTD. Address: Huawei Industrial Base Bantian Longgang Shenzhen 518129, P.R.China Tel: +86 0755 28789364 Fax: +86 0755 28788317 E-mail: tendyntu at huawei.com www.huawei.com ------------------------------------------------------------------------------------------------------------------------------------- This e-mail and its attachments contain
confidential information from HUAWEI, which is intended only for the person or
entity whose address is listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient(s) is prohibited. If you
receive this e-mail in error, please notify the sender by phone or email immediately and delete
it! > -----Original Message----- > From: Ali C. Begen (abegen)
[mailto:abegen at cisco.com] > Sent: Wednesday, September 23, 2009
11:29 AM > To: zouzixuan; fecframe at ietf.org > Subject: RE: [Fecframe]
draft-zixuan-fecframe-source-mi ?? > > First question, are you suggesting
to apply FEC to the combination of a video > and audio RTP stream? > > Second question, assuming the above
case is true, I am still not sure why you > need an additional flow carrying
the source payload ids. Is it because there are > two streams? Could you explain? > > Cheers, acbegen. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||