Re: [avtext] Proposed text for Alia and other AD's DISCUSS

[Colin Perkins <[e-mail]>]

Hi Rachel,

One quick response inline.
Colin



> On 22 Jun 2016, at 03:59, Huangyihong (Rachel) <[e-mail]> wrote:
> 
> Hi Colin and Ben,
> 
> Please see inline.
> 
> BR,
> Rachel
> 
> 
>> -----Original Message-----
>> From: Colin Perkins [mailto:[e-mail]]
>> Sent: Wednesday, June 22, 2016 5:49 AM
>> To: Ben Campbell
>> Cc: Huangyihong (Rachel); [e-mail]; Mirja
>> Kuehlewind; Alia Atlas; Alissa Cooper; [e-mail];
>> [e-mail]; [e-mail]; The IESG;
>> [e-mail]
>> Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS
>> 
>>> On 21 Jun 2016, at 20:32, Ben Campbell <[e-mail]> wrote:
>>> 
>>> Hi, some comments inline:
>>> 
>>> On 21 Jun 2016, at 7:58, Huangyihong (Rachel) wrote:
>>> 
>>>> Hi All,
>>>> 
>>>> Here's my proposal for addressing Alia's and other AD's similar DISCUSS.
>> The main idea is to add a new subsection in Section 2, which is showed as
>> following:
>>>> 
>>>> "
>>>> 2.1 Overview of RTP Splicing
>>>> 
>>>>  RTP Splicing is to replace some multimedia content with certain
>>>>  substitutive multimedia content, and then forward it to the receivers
>>>>  for a period of time. This process is authorized by the service
>>>>  provider who sends the multimedia content to these receivers. A
>>>>  typical usage is that IPTV service providers use their own regional
>>>>  advertising content to replace national advertising content provided
>>>>  by the content providers.
>>> 
>>> I think this could be strengthened a bit. IIUC, this mechanism assumes the
>> splicing interval is sent _by_ the main content provider. That is, this mechanism
>> only works with the permission of the content provider. If they don't consent,
>> they simply won't send the splicing interval.
>>> 
>>> This relationship might be more clear if the example talked about the main
>> content provider offering a time window for the regional advertising insert,
>> rather than about replacing national advertising. While that might in fact
>> replace national content, it should be clear that the main provider _intends_ for
>> the insert to happen.
>> 
>> Right.
> 
> 
> [Rachel]: According to your suggestions, how about changing the above text to below
> 
> "
>   RTP Splicing is to replace some multimedia content with certain
>   substitutive multimedia content, and then forward it to the receivers
>   for a period of time. This process is authorized by the main RTP
>   sender that offers a specific time window for inserting the
>   substitutive multimedia content in the main content. A typical usage
>   is that a IPTV service provider uses its own regional advertising
>   content to replace national advertising content, the time window of
>   which is explicitly indicated by the IPTV service provider.
> "
> 
>> 
>> The other point that’s probably worth noting is that the receiver knows the
>> traffic is being routed via the middlebox, and explicitly communicates with that
>> middlebox via the RTCP reception reports it returns, and possibly also via some
>> non-RTP signalling channel (the sender likely offers it no choice but to use the
>> middlebox if it wants access to the media stream, but that’s a different
>> issue…).
> 
> [Rachel]: Based on this suggestion, I propose to add a sentences in the end of the 2nd paragraph:
> 
> "
>   The splicer is a middlebox handling RTP splicing. It receives main
>   content and substitutive content simultaneously but only chooses to
>   send one of them to the receiver at any point of time. When RTP
>   splicing begins, the splicer sends the substitutive content to the
>   receivers instead of the main content. When RTP splicing ends, the
>   splicer switches back to sending the main content to the receivers.
>   This implies that the traffic is routed via the splicer to the
>   receivers. And the splicer is explicitly communicated with the
>   receivers via RTCP packets and possibly via non-RTP signaling
>   channel.
> “

Yes, but the last sentence might be clearer if written something like “The receiver is explicitly configured to receive the traffic via the splicer, and will return any RTCP feedback to the splicer”.

>>>>  The splicer is a middlebox handling RTP splicing. It receives main
>>>>  content and substitutive content simultaneously but only chooses to
>>>>  send one of them to the receiver at any point of time. When RTP
>>>>  splicing begins, the splicer sends the substitutive content to the
>>>>  receivers instead of the main content. When RTP splicing ends, the
>>>>  splicer switches back to sending the main content to the receivers.
>>>> 
>>>>  The middle box working as the splicer is either a translator or a
>>>>  mixer. [RFC6828] specifies a splicer implemented as a mixer that uses
>>>>  its own SSRC, sequence number space, and timing model when
>> generating
>>>>  the output stream to receivers. The mixer must not insert the SSRC of
>>>>  the main RTP stream or the SSRC of the substitutive RTP stream into
>>>>  the contributing source (CSRC) list in the output media stream when
>>>>  implementing undetectable splicing.
>>> 
>>> I suggest promoting that last sentence a bit, and removing any hint of 2119
>> language. For example:
>>> 
>>> "The splicer, operating on behalf of the content provider, may not wish to
>> reveal that splicing has occurred. In this case, the splicer does not insert the
>> SSRCs from either the main or substitutive RTP streams into the CSRC list in the
>> resulting output media stream.."
> 
> [Rachel]: Thanks for the suggestion.
> 
>>> 
>>>> Since it works as the mixer, it
>>>>  splits the RTCP flow between the sender and receiver into two
>>>>  separate RTCP loops. This implies additional considerations should be
>>>>  taken into account when handling congestion control, see Section 4.4
>>>>  of [RFC6828].
>>>> 
>>>>  A translator [RFC3550] can also be a splicer by forwarding the RTP
>> packets with
>>>>  their SSRCs intact, where the congestion control runs between
>>>>  original sender and receiver, or between substitutive sender and
>>>>  receiver. In such a case, the RTCP feedback message must be passed to
>>>>  the right sender to let the congestion control work. And undetectable
>>>>  splicing will not be fulfilled when the translator works as the
>>>>  splicer.
>>>> "
>>>> 
>>>> Besides that, a new terminology is defined in section 1.1 to define
>> "Undetectable Splicing", see below:
>>>> 
>>>> "
>>>> Undetectable Splicing:
>>>> 
>>>> The RTP receivers are not able to detect any splicing points in the RTP layer.
>> Sometimes, service providers may require an undetectable splicing to avoid the
>> RTP receivers from filtering out the advertisement content.
>>> 
>>> That particular motivation gives me a bit of heartburn. But I think the reality
>> is that the content provider wants to provide an apparently continuous stream,
>> and they don't think the the splicing details are the business of the recipient
>> (any more than the splices that occur in the original media stream incident to
>> the normal editing of the content.)
>> 
>> It’s implied, but perhaps easy to miss in Rachel’s suggested text, that this is
>> only talking about whether the splicing is detectable *at the RTP layer*. A
>> receiver that’s willing to analyse the metadata in the payload can almost
>> certainly tell that the content changed for the duration of the splicing, even
>> without decoding the video.
>> 
>> --
>> Colin Perkins
>> https://csperkins.org/
>> 
>> 
>> 
> 



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