[avtext] 答复: I-D Action: draft-ietf-avtext-splicing-notification-00.txt

[Xiajinwei <[e-mail]>]

Hi Bo,

Sorry for my latency, please see my answers inline.

> -----邮件原件-----
> 发件人: avtext [mailto:[e-mail]] 代表 Bo Burman
> 发送时间: 2014年11月5日 23:28
> 收件人: [e-mail]
> 主题: Re: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-00.txt
> 
> I've reviewed this draft and have the following comments:
> 
> 1) I'm lacking a discussion on why this solution is chosen, with splicing period
> information in RTP Header Extension and RTCP. What are the pro's/con's with it
> compared to other possible signaling solutions, external to RTP?

In MPEG-based cable TV systems, the splicing information usually in carried in some specific MPEG packets. When using RTP to encapsulate MPEG packets, it will be a heavy load for the mixer to detect deeply enough to extract the splicing information. Hence, conveying splicing information in RTP layer is easier for the mixer to learn. In addition, RTP is more general manner to carry splicing information and could be applied to any media encoding, not focus solely on MPEG.

> 
> 2) In section 3.1, I think the current specification of the splicing out NTP
> timestamp, seconds part, is broken, being just 24 bits. Assume that the splicing
> in point has an NTP timestamp seconds of (hex) 0xXXYYYYYY (XX being an
> arbitrary 8-bit number, YYYYYY a 24-bit number). If the difference between
> YYYYYY and 0x1000000 denotes a shorter time than the intended splicing
> interval, it will cause an increment in XX in the splicing out point NTP time. This
> invalidates the assumption that the upper 8 bits for the splicing out point are
> the same as the splicing in point. YYYYYY can in general be arbitrarily close to
> 0xFFFFFF, definitely not allowing a splicing interval of up to 2^25 seconds. For
> example, YYYYYY can be 0xFFFFFA, which causes a wrap in XX after only 6
> seconds. It seems to me that the current text half-way assumes that the
> splicing out point is a delta time, which would in fact allow splicing times of up
> to 2^25 seconds. I suggest splicing out is instead specified !
> as a delt
>  a time to the splicing in point (effectively being the length of the splicing
> period), in which case the above problems can be avoided. However, any carry
> digit from the sum of the splicing in and splicing period fractional parts must of
> course be used to adjust the seconds part of the resulting sum constituting the
> splicing out point. It could also be considered if RTCP splicing notification (in
> section 3.2) should then, for consistency, use the same splicing period instead
> of splicing out timestamp, but I have no specific preference there.
> 

You are correct that the upper 8 bits might not always be the same as the upper 8 bits of those in the splicing in point. I don’t think this is ambiguous, provided the splicing duration is less than 2^25 seconds, but the draft should be corrected. I will clarify it on next version.

> 3) For section 3.2, is the best semantic and functional match a new RTCP report
> packet (see RFC 5968)? Was, for example, a new RTCP source description
> (SDES) type, describing a time period in the source RTP stream that can be
> replaced by a middle-node, considered? If it was considered and rejected, why?
> 

In my mind, an SDES packet seems more appropriate to describe a property of the source, whereas splicing points are a property of the stream. It also doesn’t fit into the other categories from RFC 5968, so a new RTCP packet type seems appropriate.

> 4) In section 5, third and fourth paragraphs: it is somewhat opaque to me how
> RR from downstream receivers can help the main RTP sender and substitutive
> RTP sender learn that splicing did not occur? Downstream receivers will only
> see and report on the mixer's SSRC in either case, right? I think some
> clarification may be beneficial.
> 

The background is described in section 4.2 of RFC6828. The mixer selects one media stream from multiple streams rather than mixing them, so the mixer can leave the SSRC identifier in the RTCP report intact. I will add RFC6828 as reference at there.

> 5) Are there any multicast/broadcast considerations that should be described,
> or will the scenario only work strictly point-to-point between (each of) the main
> RTP sender and the mixer, and the substitutive RTP sender and the mixer?
> 

Splicing is applicable to all scenarios, so I don't mention this. maybe I can add it somewhere.

> Editorial nits:
> I) Section 2, second paragraph: "... more than once to against the possible
> packet loss" --> "... more than once to mitigate the possible packet loss "
> II) Section 3.1, second paragraph: consumption --> assumption (if that text is
> kept after needed changes from 2 above)
> III) Section 3.1, next-to-last paragraph: "could not include" --> "must not
> include"
> IV) Section 4, title: Reduing --> Reducing
> V) Section 6, second video m-line is lacking a=rtpmap
> 

Accept!


Thank your comments!

Jinwei

> Cheers,
> Bo
> 
> 
> > -----Original Message-----
> > From: avtext [mailto:[e-mail]] On Behalf Of
> > [e-mail]
> > Sent: den 29 juli 2014 15:15
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [avtext] I-D Action:
> > draft-ietf-avtext-splicing-notification-00.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >  This draft is a work item of the Audio/Video Transport Extensions Working
> Group of the IETF.
> >
> >         Title           : RTP/RTCP Extension for RTP Splicing
> Notification
> >         Authors         : Jinwei Xia
> >                           Roni Even
> >                           Rachel Huang
> >                           Lingli Deng
> > 	Filename        : draft-ietf-avtext-splicing-notification-00.txt
> > 	Pages           : 12
> > 	Date            : 2014-07-28
> >
> > Abstract:
> >    Content splicing is a process that replaces the content of a main
> >    multimedia stream with other multimedia content, and delivers the
> >    substitutive multimedia content to the receivers for a period of
> >    time. The RTP mixer is designed to handle RTP splicing in [RFC6828],
> >    but how the RTP mixer knows when to start and end the splicing is
> >    still unspecified.
> >
> >    This memo defines two RTP/RTCP extensions to indicate the splicing
> >    related information to the RTP mixer: an RTP header extension that
> >    conveys the information in-band and an RTCP packet that conveys the
> >    information out-of-band.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notificati
> > on/
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-00
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > avtext mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avtext
> 
> _______________________________________________
> avtext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avtext