Subject: [AVT] RTP splicing

From: Colin Perkins <[email-masked]>
Date: Tue, 9 Nov 2010 16:25:33 +0800

Hi,

Thinking about this further, we have agreed that the splicer should be implemented as an RTP translator for the original media stream. Such a translator will rewrite forward RTP sequence numbers, and forward and reverse RTCP, to match the changes made to the media stream by the content insertion process. We note that the splicing process is not dependent on whether the content to be inserted arrives over RTP or otherwise.

We observe that the inserted stream might have somewhat different characteristics to the original media stream it replaces (e.g., the adverts may be more dynamic, and hence higher bandwidth, than the TV programme). As a result, the translated RTCP RRs received by the sender might be somewhat misleading for adaptation purposes, since they relate to a stream that the sender cannot control during the insertion period. To address this, we recommend that the splicer should have its own SSRC, and generate RTCP reports towards the original media sender, giving the sender some visibility into the performance of the different segments of the path. (The splicer may also optionally send RTCP towards the source of the content to be inserted, if that content is delivered over RTP). 

We think implementation of an RTP splicer is non-obvious and a draft explaining the actual implementation in detail would be valuable. We therefore recommend taking this on as WG item with the goal of an informational or BCP RFC. We don't anticipate any changes to RTP at this time.

Colin Perkins and Magnus Westerlund

---

From: Jinwei Xia <[email-masked]>
Date: Tue, 09 Nov 2010 16:56:31 +0800

Hi Colin and Magnus,

Your analysis are very valuable, especially on the signalling plane. IPTV operators have the intention to deploy middlebox device to insert their own ad. I guess they have strong intention to get the real characteristics from the receiver and confirm their ad is present on user. 

Translator can initiate its own RRs to media source, so it is not feasible for operator to learn the splicing situation on user.  We can work on this together.

Jinwei

----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "IETF AVT WG" <[email-masked]>
Cc: "Magnus Westerlund" <[email-masked]>
Sent: Tuesday, November 09, 2010 4:25 PM
Subject: [AVT] RTP splicing

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 9 Nov 2010 01:13:25 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jinwei Xia
> Sent: Tuesday, November 09, 2010 4:57 PM
> To: Colin Perkins; IETF AVT WG
> Cc: Magnus Westerlund
> Subject: Re: [AVT] RTP splicing
> 
> Hi Colin and Magnus,
> 
> Your analysis are very valuable, especially on the signalling plane. IPTV operators have the intention to deploy middlebox
> device to insert their own ad. I guess they have strong intention to get the real characteristics from the receiver and confirm
> their ad is present on user.

RTCP reports would not confirm that the ads were actually shown to the viewers. So, these reports are not often relied upon.

-acbegen
 
> > Thinking about this further, we have agreed that the splicer should be implemented as an RTP translator for the original
> media stream. Such a translator will rewrite forward RTP sequence numbers, and forward and reverse RTCP, to match the
> changes made to the media stream by the content insertion process. We note that the splicing process is not dependent on
> whether the content to be inserted arrives over RTP or otherwise.
> >
> > We observe that the inserted stream might have somewhat different characteristics to the original media stream it
> replaces (e.g., the adverts may be more dynamic, and hence higher bandwidth, than the TV programme). As a result, the
> translated RTCP RRs received by the sender might be somewhat misleading for adaptation purposes, since they relate to a
> stream that the sender cannot control during the insertion period. To address this, we recommend that the splicer should
> have its own SSRC, and generate RTCP reports towards the original media sender, giving the sender some visibility into the
> performance of the different segments of the path. (The splicer may also optionally send RTCP towards the source of the
> content to be inserted, if that content is delivered over RTP).
> >
> > We think implementation of an RTP splicer is non-obvious and a draft explaining the actual implementation in detail would
> be valuable. We therefore recommend taking this on as WG item with the goal of an informational or BCP RFC. We don't
> anticipate any changes to RTP at this time.
> >

---

From: Colin Perkins <[email-masked]>
Date: Tue, 9 Nov 2010 17:18:10 +0800

> RTCP reports would not confirm that the ads were actually shown to the viewers. So, these reports are not often relied upon.

RTCP reports tell you the data got to the receiver with high confidence. I'm not convinced you can ever tell if the viewer actually saw them :-)

-- 
Colin Perkins
http://csperkins.org/

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Tue, 9 Nov 2010 14:06:04 +0100

Magnus, Colin, Xia,

One of the requirements formulated in the Xia draft is 

REQ 3:

 To prevent the RTP receiver from easily identifying the inserted
      stream, the Splicer should merge the inserted stream into the
      primary RTP stream so that it will not be identified based on RTP
      header information like payload type number, sequence number and
      SSRC.  This requires the Splicer to modify the RTP header of the
      inserted RTP stream.  The Splicer may need to do media transcoding
      in most cases. 

I believe this REQ will determine to a large extent the proposed implementation.

While I agree there are possible benefits that a video client can not distinguish between linear ad content and non-ad (or premium) content in a stream, a concern I have is that the transparency requirement  -from the RTP receiver point of view- imposed on the RTP layer puts a significant burden on the middlebox (depending on the use case), and IMO this is only justified if a video client is not able to make the distinction in any OSI layer -up till the video codec layer- between ad and non-ad content. 

So, my question is : is the group only interested in this 100% transparency case, or is there also interest in environments/implementations where REQ 3 (on all layers!) is not -always- met.

Reasons I can think of why client transparency is not deemed necessary, are:
-with recorded streams, one can FFW anyhow through ad blocks
-some programs are by a large majority of the viewers watched real-time (live, sporting events, news shows), so there is few opportunity to skip the ads

If such interest exists, we can think about whether there are lighter weight solutions leveraging RTP/RTCP protocol extensions that provide better scalability and/or more flexibility but still address real-time merging or mixing of "replacement" content in an existing RTP flow, but with an "active" role for the RTP receiver.  I think of traditional IPTV where live RTP streams are transported over multicast. If an operator wants to implement in the network linear personalised advertisements, the REQ 3 will be a hard nut to crack.  

Regards,
Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jinwei Xia
Sent: dinsdag 9 november 2010 9:57
To: Colin Perkins; IETF AVT WG
Cc: Magnus Westerlund
Subject: Re: [AVT] RTP splicing

Hi Colin and Magnus,

Jinwei

---

From: Jinwei Xia <[email-masked]>
Date: Tue, 09 Nov 2010 21:33:38 +0800

Hi Ali,

>RTCP reports would not confirm that the ads were actually shown to the viewers. So, these reports are not often relied upon.

Right, but at least operator can learn what's happened on middlebox. 

BR
Jinwei

> Translator can initiate its own RRs to media source, so it is feasible for operator to learn the splicing situation on user.
> We can work on this together.
> 
> 
> Jinwei
>