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

[Bo Burman <[e-mail]>]

Hi Jinwei,

It is now my turn to apologize for the delay. I have no further concerns. My responses to your answers inline below.

Cheers,
Bo

> -----Original Message-----
> From: Xiajinwei [mailto:[e-mail]]
> Sent: den 8 november 2014 02:50
> To: Bo Burman; [e-mail]
> Subject: 答复: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-00.txt
> 
> 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.
> 
[BoB] OK. That information is actually there in the Introduction. I don't think you have to change anything.

> >
> > 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.
[BoB] OK

> 
> > 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.
[BoB] I think a splicing point denotes a time instant in the stream coming from the source where it is appropriate, considering the source content, to insert other content. I don't have a strong opinion, though, and I'm OK with defining a new packet.

> 
> > 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.
[BoB] OK. It becomes clear when reading RFC 6828.

> 
> > 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.
[BoB] OK

> 
> > 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-notifica
> > > ti
> > > on/
> > >
> > > There's also a htmlized version available at:
> > > http://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-0
> > > 0
> > >
> > >
> > > 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