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

From: Bo Burman <[email-masked]>
Date: Wed, 5 Nov 2014 15:27:57 +0000

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?

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 delta 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.

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?

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.

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?

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

Cheers,
Bo

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: den 29 juli 2014 15:15
> To: [email-masked]
> Cc: [email-masked]
> 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-notification/
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: Xiajinwei <[email-masked]>
Date: Sat, 8 Nov 2014 01:50:19 +0000

Hi Bo,

Sorry for my latency, please see my answers inline.

> -----邮件原件-----
> 发件人: avtext [mailto:[email-masked]] 代表 Bo Burman
> 发送时间: 2014年11月5日 23:28
> 收件人: [email-masked]
> 主题: Re: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-00.txt
> 
> 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 "

Accept!

Thank your comments!

Jinwei

> > Subject: [avtext] I-D Action:
> > draft-ietf-avtext-splicing-notification-00.txt
> >
> >
> > 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.
> >

---

From: Bo Burman <[email-masked]>
Date: Thu, 27 Nov 2014 08:36:54 +0000

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

> From: Xiajinwei [mailto:[email-masked]]
> Sent: den 8 november 2014 02:50
> To: Bo Burman; [email-masked]
> Subject: 答复: [avtext] I-D Action: draft-ietf-avtext-splicing-notification-00.txt
> 
> Hi Bo,
> 
> > 主题: Re: [avtext] I-D Action:
> > 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?
> >
> 
[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)
> > >  This draft is a work item of the Audio/Video Transport Extensions
> > > Working
> > Group of the IETF.
> > >
> > > https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notifica
> > > ti
> > > on/
> > >