Subject: [avtext] Splicing: Confirmation of decisions at IETF#80

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 28 Mar 2011 18:01:22 +0200

(As WG chair)

There was significant interest in the face-to-face meeting to creating a milestone in the WG. The essence of the milestone will be to address the use case of splicing using existing tools provided in RTP. It will therefore be an informational document.

Unless the chairs hear contrary positions on the mailing list, the chairs will discussing such a milestone with the AD and adding it to our list of milestones in AVTEXT.

Please respond by the end of this week (Friday).

This does not adopt the current text as a working group item. The author will provide another revision of this document based on comments made, and other comments that people may wish to contribute now, and we will make a call to adopt text at that point. Please take this as an invitation to contribution other material either via the mailing list or via separate internet-drafts.

Regards

Keith

---

From: David R Oran <[email-masked]>
Date: Mon, 28 Mar 2011 15:58:08 -0400

Sorry I wasn't there folks (still can't travel for another month or so).
I have one question about the discussion and conclusion.

Was there consensus on the (I believe explicit) statement in the requirements that the splicing action be completely undetectable by the receiver?

The reason I ask is that from my perspective, the entire technical approach (including whether to model as a translator or mixer) is driven by this one requirement. In fact, I can see a number of MUCH simpler approaches if this requirement is dropped.

I just want to be clear when we adopt the milestone if we are a priori confining the solution space to solutions that satisfy this requirement.

I'm somewhat ambivalent about this, since the only use case I can think of where undetectability comes into play is advertisement insertion. We should be clear that everybody understands that this is the case.

Cheers, DaveO.

On Mar 28, 2011, at 12:01 PM, DRAGE, Keith (Keith) wrote:

> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 28 Mar 2011 22:04:25 +0200

(As WG chair)

That would be too much detail for the setting of a milestone, which is all we are asking the working group to perform at the moment (and no we did not discuss this in the working group - at least to my recollection).

However it sounds like a perfectly reasonable question to ask in terms of what the draft (when we get round to the adoption question for text) should cover, either as discussion or as a stated requirement.

Essentially as regards the text we are in the phase of identifying to the author issues he should cover to make his draft text more acceptable to the WG than any other text (not that there is any at the moment).

Feel free to have that discussion.

Regards

Keith

P.S. We are missing you.

> -----Original Message-----
> From: David R Oran [mailto:[email-masked]]
> Sent: 28 March 2011 20:58
> To: DRAGE, Keith (Keith)
> Cc: [email-masked]
> Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80
> 
> Was there consensus on the (I believe explicit) statement in the
> requirements that the splicing action be completely undetectable by the
> receiver?
> 
> The reason I ask is that from my perspective, the entire technical
> approach (including whether to model as a translator or mixer) is driven
> by this one requirement. In fact, I can see a number of MUCH simpler
> approaches if this requirement is dropped.
> 
> I just want to be clear when we adopt the milestone if we are a priori
> confining the solution space to solutions that satisfy this requirement.
> 
> I'm somewhat ambivalent about this, since the only use case I can think of
> where undetectability comes into play is advertisement insertion. We
> should be clear that everybody understands that this is the case.
> 
> Cheers, DaveO.
> 
> 
> > There was significant interest in the face-to-face meeting to creating a
> milestone in the WG. The essence of the milestone will be to address the
> use case of splicing using existing tools provided in RTP. It will
> therefore be an informational document.
> >
> > Unless the chairs hear contrary positions on the mailing list, the
> chairs will discussing such a milestone with the AD and adding it to our
> list of milestones in AVTEXT.
> >
> > This does not adopt the current text as a working group item. The author
> will provide another revision of this document based on comments made, and
> other comments that people may wish to contribute now, and we will make a
> call to adopt text at that point. Please take this as an invitation to
> contribution other material either via the mailing list or via separate
> internet-drafts.
> >
> > Regards
> >
> > Keith

---

From: David R Oran <[email-masked]>
Date: Mon, 28 Mar 2011 16:32:54 -0400

> That would be too much detail for the setting of a milestone, which is all we are asking the working group to perform at the moment (and no we did not discuss this in the working group - at least t…
Well, I sort of disagree. If some hyperbole would help clarify, this is like establishing a milestone "get astronauts to the moon" while leaving out the pesky requirements detail of "you need to get them back alive".

> However it sounds like a perfectly reasonable question to ask in terms of what the draft (when we get round to the adoption question for text) should cover, either as discussion or as a stated requ…
I just want to make sure people are aware of the implications implicit in the milestone so we don't immediately stall over the consequences of this (to me key overriding) requirement.

> Essentially as regards the text we are in the phase of identifying to the author issues he should cover to make his draft text more acceptable to the WG than any other text (not that there is any a…
I'm not at the point of worrying about text in the drafts, since if we are on the same page as the authors on the undetectability requirement whatever the final thing says it's going to look more or less like what they propose, and if the WG doesn't buy the requirement by contrast I suspect the ultimate solution can look quite different (and possibly quite a bit simpler).

So, for the record, I am in favor of the milestone without an undetectability requirement and not opposed (but abstain) with that requirement.

---

From: xiajinwei 65217 <[email-masked]>
Date: Tue, 29 Mar 2011 22:30:48 +0800

Hi Chair and Dave,

Thank your comments. 

The user in RTP/RTCP protocol is STB device, so user undetectability is exactly STB undetectability. This means that substitutive content and main content should not be discriminated by STB in RTP layer. 
If the substitutive content comes from local file storage, translator can directly replace the main content in a single stream, i.e., main stream. This is irrrelevant to STB undetectability requirement.

If the substitutive content is conveyed via another RTP stream, translator does not merge the two streams into one and outputs them alternately, this will cause a few concerns.  From commercial viewpoint, STB has the capability to detect the substitutive stream, and thus possibly filter substitutive stream, especially in DVR/PVR/Time-shift applications, this is unacceptable for operators and advertisers. SMPTE 321M standard (Splice Points f
or MPEG2-TS) gives corresponding description "However, in order to prevent commercial killing devices from taking advantage of changes in PSI, systems with splicing are encouraged to avoid changes to the PMT by reusing existing video and audio PIDs after a splice. "  IMHO it is STB undetectability on TS layer, we just map the requirement to RTP layer. I also attaches SMPTE 321.

Thank you

Jinwei

----- 原邮件 -----
发件人: "DRAGE, Keith (Keith)" <[email-masked]>
日期: 星期二, 三月 29日, 2011 上午4:04
主题: Re: [avtext] Splicing: Confirmation of decisions at IETF#80
收件人: David R Oran <[email-masked]>
抄送: "[email-masked]" <[email-masked]>

> (As WG chair)
> 
> That would be too much detail for the setting of a milestone, 
> which is all we are asking the working group to perform at the 
> moment (and no we did not discuss this in the working group - at 
> least to my recollection).
> 
> However it sounds like a perfectly reasonable question to ask in 
> terms of what the draft (when we get round to the adoption 
> question for text) should cover, either as discussion or as a 
> stated requirement.
> 
> Essentially as regards the text we are in the phase of identifying 
> to the author issues he should cover to make his draft text more 
> acceptable to the WG than any other text (not that there is any at 
> the moment).
> 
> > I just want to be clear when we adopt the milestone if we are a 
> priori> confining the solution space to solutions that satisfy 
> this requirement.
> > 
> > contribution other material either via the mailing list or via 
> separate> internet-drafts.
> > >
> > > Regards
> > >
> > > Keith

---

From: David R Oran <[email-masked]>
Date: Tue, 29 Mar 2011 11:02:46 -0400

> The user in RTP/RTCP protocol is STB device, so user undetectability is exactly STB undetectability. This means that substitutive content and main content should not be discriminated by STB in RTP…
"should not" or "must not". Note that avoiding detection at the RTP layer doesn't help if the splice is detectable above the RTP layer - more on this below.

> If the substitutive content comes from local file storage, translator can directly replace the main content in a single stream, i.e., main stream. This is irrrelevant to STB undetectability require…
I don't think this follows - see my encryption example below.

> or MPEG2-TS) gives corresponding description "However, in order to prevent commercial killing devices from taking advantage of changes in PSI, systems with splicing are encouraged to avoid changes…
Thanks for supplying the confirming details.

Do you agree with my conclusion that accepting the milestone does in fact imply we are accepting the non-detectability requirement? In other words, you aren't interested in pursuing the work if this requirement is removed?

I ask because nearly all uses of splicing other than advertisement insertion do not bring along a non-detectability requirement. For example, other use cases include splicing a recorded video into a video conferencing session, implementing a playlist server that stitches pieces of video together, inserting alternate audio via a spliced stream, etc.

Just as an interesting factoid, even if you go to great lengths to hide the splicing in the RTP translator, in a large number of cases advertisements are unencrypted while the base content is encrypted. Therefore, even if you do a totally undetectable splice at the RTP layer, the receiver will *still* be able to find the splice points by the switch in encryption state. Providers who are paranoid about this actually go to the extreme of re-encrypting the content at the splicer, which of course cannot be done at the RTP layer since it changes the application data and hence causes re-encapsulation.

(Full disclosure: Cisco has IPR on how to splice unencrypted advertisements or advertisements encrypted under different keys using RTP mixer approaches. These are detectable by a smart receiver so the IPR does not apply to the approach you have in your I.D.)

These and other considerations are why I'm abstaining on (not opposing!) adopting the milestone if the non-detectability requirement is retained. 

If other people share my ambivalence, an alternative is to re-work the milestone to talk only about advertisement insertion via RTP splicing, and consider a separate and different approach for splicing where detectability isn't a problem. I offer this alternative because we may wind up with an overly complex or restrictive or brittle solution to meet the non-detectability requirement, which could be simplified or generalized for the other use cases.

DaveO.

> <SMPTE 312M.pdf>

---

From: xiajinwei 65217 <[email-masked]>
Date: Wed, 30 Mar 2011 05:50:54 +0800

----- 原邮件 -----
发件人: David R Oran <[email-masked]>
日期: 星期二, 三月 29日, 2011 下午11:05
主题: Re: 回复:Re: [avtext] Splicing: Confirmation of decisions at IETF#80
收件人: xiajinwei 65217 <[email-masked]>
抄送: "DRAGE, Keith (Keith)" <[email-masked]>, "[email-masked]" <[email-masked]>

> > The user in RTP/RTCP protocol is STB device, so user 
> undetectability is exactly STB undetectability. This means that 
> substitutive content and main content should not be discriminated 
> by STB in RTP layer. 
> "should not" or "must not". Note that avoiding detection at the 
> RTP layer doesn't help if the splice is detectable above the RTP 
> layer - more on this below.
> 

I think "should not" is better, the requirement from one operator should not force all operators to implement it.

> > If the substitutive content comes from local file storage, 
> translator can directly replace the main content in a single 
> stream, i.e., main stream. This is irrrelevant to STB 
> undetectability requirement.
> > 
> > If the substitutive content is conveyed via another RTP stream, 
> translator does not merge the two streams into one and outputs 
> them alternately, this will cause a few concerns.  From commercial 
> viewpoint, STB has the capability to detect the substitutive 
> stream, and thus possibly filter substitutive stream, especially 
> in DVR/PVR/Time-shift applications, this is unacceptable for 
> operators and advertisers. SMPTE 321M standard (Splice Points f
> > or MPEG2-TS) gives corresponding description "However, in order 
> to prevent commercial killing devices from taking advantage of 
> changes in PSI, systems with splicing are encouraged to avoid 
> changes to the PMT by reusing existing video and audio PIDs after 
> a splice. "  IMHO it is STB undetectability on TS layer, we just 
> map the requirement to RTP layer. I also attaches SMPTE 321.
> > 
> Do you agree with my conclusion that accepting the milestone does 
> in fact imply we are accepting the non-detectability requirement? 
> In other words, you aren't interested in pursuing the work if this 
> requirement is removed?

Actually I prefer to define the requirement as optional, just like above description of SMPTE 321M.

> 
> I ask because nearly all uses of splicing other than advertisement 
> insertion do not bring along a non-detectability requirement. For 
> example, other use cases include splicing a recorded video into a 
> video conferencing session, implementing a playlist server that 
> stitches pieces of video together, inserting alternate audio via a 
> spliced stream, etc.

Yes, these use cases, in addition to emergency broadcast, also use splicing technology. Ad insertion is a special use case.

> 
> Just as an interesting factoid, even if you go to great lengths to 
> hide the splicing in the RTP translator, in a large number of 
> cases advertisements are unencrypted while the base content is 
> encrypted. Therefore, even if you do a totally undetectable splice 
> at the RTP layer, the receiver will *still* be able to find the 
> splice points by the switch in encryption state. Providers who are 
> paranoid about this actually go to the extreme of re-encrypting 
> the content at the splicer, which of course cannot be done at the 
> RTP layer since it changes the application data and hence causes 
> re-encapsulation.

Translator can be used in SRTP environment (section 7.4 of RFC3711), thus the substitutive content can used same encryption material with main content when re-encrypting them.

Thank you 

Jinwei

> 
> (Full disclosure: Cisco has IPR on how to splice unencrypted 
> advertisements or advertisements encrypted under different keys 
> using RTP mixer approaches. These are detectable by a smart 
> receiver so the IPR does not apply to the approach you have in 
> your I.D.)
> 
> These and other considerations are why I'm abstaining on (not 
> opposing!) adopting the milestone if the non-detectability 
> requirement is retained. 
> 
> If other people share my ambivalence, an alternative is to re-work 
> the milestone to talk only about advertisement insertion via RTP 
> splicing, and consider a separate and different approach for 
> splicing where detectability isn't a problem. I offer this 
> alternative because we may wind up with an overly complex or 
> restrictive or brittle solution to meet the non-detectability 
> requirement, which could be simplified or generalized for the 
> other use cases.
> 
> DaveO.
> 
> > 
> > Thank you
> > 
> > Jinwei
> > 
> > 
> > ----- 原邮件 -----
> >>> Subject: Re: [avtext] Splicing: Confirmation of decisions at 
> IETF#80>>> 
> >>> Sorry I wasn't there folks (still can't travel for another 
> month 
> >> or so).
> >>> requirements that the splicing action be completely 
> undetectable 
> >> by the
> >>> receiver?
> >>> 
> >>> by this one requirement. In fact, I can see a number of MUCH 
> simpler>>> approaches if this requirement is dropped.
> >>> 
> >>> will provide another revision of this document based on 
> comments 
> >> made, and

---

From: Roni Even <[email-masked]>
Date: Thu, 31 Mar 2011 10:25:06 +0200

Hi,
I support adding a milestone for splicing and will help review this work
Roni Even

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of DRAGE, Keith (Keith)
> Sent: Monday, March 28, 2011 6:01 PM
> To: [email-masked]
> Subject: [avtext] Splicing: Confirmation of decisions at IETF#80
> 
> (As WG chair)
> 
> There was significant interest in the face-to-face meeting to creating
> a milestone in the WG. The essence of the milestone will be to address
> the use case of splicing using existing tools provided in RTP. It will
> chairs will discussing such a milestone with the AD and adding it to
> our list of milestones in AVTEXT.
> 
> This does not adopt the current text as a working group item. The
> author will provide another revision of this document based on comments
> made, and other comments that people may wish to contribute now, and we
> will make a call to adopt text at that point. Please take this as an
> invitation to contribution other material either via the mailing list
> or via separate internet-drafts.
> 
> Regards
> 
> Keith