Re: [Fecframe] draft-zixuan-fecframe-source-mi ??

[zouzixuan <tendyntu at huawei.com>]

Hi, Ali
	It's a good suggestion that others join the discussion on this. The
point here is that whether we need to take the backward compatibility into
account in FEC Framework or not. We may not ignore a fact that the diversity
of clients exists in practice. We didn't mean to make the idea we proposed
to be something depart from the framework. We just hope to complement the
framework so that it can be practically more adaptable.

Best regards,
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: Thursday, September 24, 2009 12:09 AM
> To: zouzixuan; fecframe at ietf.org
> Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
> 
> There are multiple things here used as an excuse to depart from the
convention
> used in the framework.
> 
> The main goal here seems to provide the non-framework capable RTP
> applications a way of using the nice features of the framework. In this
example,
> "a nice feature" stands for the protection of multiple RTP streams
together. I
> will let others comment on this, too, but personally, I am not sure
whether we
> should be doing this. On one hand, we want the nice features, but at the
same
> time we don't wanna support the framework, and the excuse is the backward
> compatibility in environments with both framework-capable and incapable
RTP
> receivers. In addition, using an additional flow may increase the chances
of
> failure since if source fec payload id's are lost, receiver will be
clueless. This
> deserves a consensus from the WG, probably from AVT, too.
> 
> Furthermore, I believe two RTP streams can be still protected together w/o
any
> additional source fec payload id's (You asked for an example, and I will
try to
> explain in simple words). If certain features of the RTP streams are known
> (which is usually the case), by using a systematic approach (not in the
sense of
> systematic FEC), things can probably be worked out. In your example, I
believe
> in each source block you wanna do a different order of the source packets
and
> flows, so things are quite unpredictable. E.g., packet 16 and 17 are
before
> packet 15 of the same flow, packet 19 is before packet 8 of the other
flow, and
> packets belonging to flows 0 and 1 are dispersed, any particular reason?
> 
> But, if you follow a systematic approach, your CDP can convey the mapping
out
> of band, and decoding will know what to expect and how to decode. Remember
> that there will be constraints on which RTP streams you can combine prior
to
> FEC encoding (this was brought up in the last meeting).
> 
> If all the RTP streams belong to the same RTP session, their SSRC's will
be
> different, so SSRC+seqnum should uniquely identify each source packet.
But,
> this would not work if the RTP streams would be from different sessions.
In
> that case, they could share same SSRC's, and I can see the complications.
> 
> Cheers, acbegen.
> 
> 
> From: zouzixuan [mailto:tendyntu at huawei.com]
> Sent: Wednesday, September 23, 2009 4:28 AM
> To: Ali C. Begen (abegen); 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?
> 
> 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.