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

["Einat Yellin (Lachover)" <Einat at radvision.com>]

Hi,
Backward compatibility is a major requirement for FEC framework, no
doubt. I believe that the discussion here is around whether a separate
flow for FEC mapping information is required.

While following the discussion, I can relate to the reasons why not
having a separate flow as claimed by Ali:
a. This is a redundant flow since this information can be conveyed in
the FEC repair flow and in SDP even when protecting multiple RTP flows
(specifically you can see an example in
draft-galanos-fecframe-rtp-reedsolomon-mf-00).
b. This separate flow for mapping is also useful only for receivers that
support this draft, so the backward compatibility issue remains the same
as for the case where mapping is specified in the repair flow.
c. A separate flow increases the chance of losing packets.

I must say that I don't understand the reasons for using a separate
flow.
Mr. Zou ZiXuan, is this meant for systems that do not use SDP?

Best,
Einat
-----Original Message-----
From: fecframe-bounces at ietf.org [mailto:fecframe-bounces at ietf.org] On
Behalf Of zouzixuan
Sent: Thursday, September 24, 2009 6:24 AM
To: 'Ali C. Begen (abegen)'; fecframe at ietf.org
Cc: tme at multicasttech.com
Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ??

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.

_______________________________________________
Fecframe mailing list
Fecframe at ietf.org
https://www.ietf.org/mailman/listinfo/fecframe