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 ??
-----Original Message-----
From: fecframe-bounces at ietf.org [mailto:fecframe-bounces at ietf.org] On
Behalf Of zouzixuan
Sent: Monday, September 28, 2009 10:57 AM
To: 'Ali C. Begen (abegen)'; Einat Yellin (Lachover);
tme at multicasttech.com; gjshep at gmail.com; fecframe at ietf.org
Subject: Re: [Fecframe] draft-zixuan-fecframe-source-mi ??
Hi, Ali
> I am not questioning backward compatibility, I am questioning the cost
for
it
> and the scenarios where we want backward compatibility. Einat did a
good
> summary, so now the WG needs to provide input.
You mean there should be some input on backward compatibility to the
framework.
> Regarding your example, putting the audio and video packets into the
source
> blocks as they are available does not seem to be a good design choice
to
me.
> When I say "systematic," I mean you can create your source blocks in a
> deterministic way (such as 4 packets from stream 1, one packet from
stream
2).
> Variable-packet size can be handled.
In this "systematic" case, how could we know the position of a packet in
the
source block?
[Einat] There are different ways to signal the source block structure.
In our draft we followed rfc 5109 and used the 'base' (first) RTP
sequence number along with a bitmap. This works for the cases where what
matters is which RTP packets belong to this FEC source block and the
order of the packets in the FEC source block is deterministic (from
lower SN to higher SN and from lower flow ID to higher flow ID). If a
more detailed structure of source block is needed then I agree that the
bitmap is not enough. Still, this information can be sent as part of the
repair packet header which IMO makes more sense.
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: Monday, September 28, 2009 1:40 AM
> To: zouzixuan; Einat Yellin (Lachover); tme at multicasttech.com;
> gjshep at gmail.com; fecframe at ietf.org
> Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
>
> I am not questioning backward compatibility, I am questioning the cost
for
it
> and the scenarios where we want backward compatibility. Einat did a
good
> summary, so now the WG needs to provide input.
>
> Regarding your example, putting the audio and video packets into the
source
> blocks as they are available does not seem to be a good design choice
to
me.
> When I say "systematic," I mean you can create your source blocks in a
> deterministic way (such as 4 packets from stream 1, one packet from
stream
2).
> Variable-packet size can be handled.
>
> Cheers, acbegen.
>
> > -----Original Message-----
> > From: zouzixuan [mailto:tendyntu at huawei.com]
> > Sent: Sunday, September 27, 2009 5:59 AM
> > To: 'Einat Yellin (Lachover)'; Ali C. Begen (abegen);
tme at multicasttech.com;
> > gjshep at gmail.com; fecframe at ietf.org
> > Subject: RE: [Fecframe] draft-zixuan-fecframe-source-mi ??
> >
> > 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
_______________________________________________
Fecframe mailing list
Fecframe at ietf.org
https://www.ietf.org/mailman/listinfo/fecframe
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
