Re: [Fecframe] draft-zixuan-fecframe-source-mi ??
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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?

 

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?

 

0

16

B0,0

B0,1

B0,2

B0,3

B0,4

B0,5

B0,6

B0,7

B0,8

B0,9

B0,10

B0,11

B0,12

B0,13

B0,14

B0,15

0

0

0

0

17

B1,0

B1,1

B1,2

B1,3

B1,4

B1,5

B1,6

B1,7

B1,8

B1,9

B1,10

B1,11

B1,12

B1,13

B1,14

B1,15

B1,16

0

0

1

19

B2,0

B2,1

B2,2

B2,3

B2,4

B2,5

B2,6

B2,7

B2,8

B2,9

B2,10

B2,11

B2,12

B2,13

B2,14

B2,15

B2,16

B2,17

B2,18

0

15

B3,0

B3,1

B3,2

B3,3

B3,4

B3,5

B3,6

B3,7

B3,8

B3,9

B3,10

B3,11

B3,12

B3,13

B3,14

0

0

0

0

1

8

B4,0

B4,1

B4,2

B4,3

B4,4

B4,5

B4,6

B4,7

 

 

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.


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.