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

[zouzixuan <tendyntu at huawei.com>]

Hi, Einat, Ali
	 Similar to Einat's explanation on "backward compatible" as stated
your draft , our intention is to keep source packet unmodified without
adding source payload id to it. And therefore the non-framework client can
interpret the source packet. But I'm still not sure if the "backward
compatibility" we are referring to here is considered a valuable requirement
in FEC framework. 

	 I'd like to again use the example we gave in the previous thread we
replied to Ali's doubts to explain the need of source payload id for RTP
flow. Ali, sorry, I was supposed to gave more detailed information on this.
.
    Here are several assumptions on this example:
	 1) We assume a FEC-protected audiovisual stream which is
combination of a video and a audio RTP flow. ID 0 identify video source
data, and ID 1 identify audio source data. The definition of ID can be
conveyed through SDP
	 2) RTP packets length is non-equal, e.g. in 16, 17, 19, 15, 8
bytes, as is shown.
	 3) A video or audio source packet is fed into a source block in an
First-come-First-serve order in which the video and audio packets are
generated.

   In which case we think the source-pay-load ID is needed. For
backward-compatibility, the source payload id can be conveyed in an separate
flow, which could be either an additional flow or the repair flow. 

   Ali, would you please give a more details on "systematic approach"? I'm
not following this.

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

So here I think if we want to have answer on the necessity of the things in
our draft, we need to at first have conclusions on the following: 1) whether
the "back compatibility" Elinat and me are referring to is a real issue to
be considered in FEC framework, And 2) if some cases like this one, which
demands source payload id, stands and is representative.

Cheers
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: Einat Yellin (Lachover) [mailto:Einat at radvision.com]
> Sent: Thursday, September 24, 2009 1:24 PM
> To: zouzixuan; Ali C. Begen (abegen); fecframe at ietf.org
> Cc: tme at multicasttech.com
> Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
> 
> 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