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

["Huangyihong (Rachel)" <[e-mail]>]

Hi Alia,

Please see below.

BR,
Rachel

From: Alia Atlas [mailto:[e-mail]]
Sent: Wednesday, June 22, 2016 6:07 AM
To: Colin Perkins
Cc: Ben Campbell; Huangyihong (Rachel); [e-mail]; Mirja Kuehlewind; Alissa Cooper; [e-mail]; [e-mail]; [e-mail]; The IESG; [e-mail]
Subject: Re: [avtext] Proposed text for Alia and other AD's DISCUSS

Colin,

These are really useful points for me.
So, indicating that the receiver has agreed to receive the stream via the splicer would help.
As written, it sounds like there is a requirement to hide the splicing from the receiver - and all
the motivations I've been hearing are to "force" the receiver to get the included advertisements
and not be able to tell where they are.

[Rachel]: I guess undetectable splicing does cause some unhappiness. I suggest to remove it and related words from this document.
However, even not mentioning undetectable splicing, it still makes sense for the splicer to remove the header extension when forwarding the media content to the receivers, since the RTP sender intends to send the splicing interval messages to the splicer, not the receivers, and the splicer is on behalf of the RTP sender to forward the content. So in that case I don’t think it’s “hiding” or “force” the receive to get the advertisements. The time window is there, even there’s not substitutive advertisement spliced in, it still contains original advertisements.

Regards,
Alia

On Tue, Jun 21, 2016 at 5:57 PM, Colin Perkins <[e-mail]<mailto:[e-mail]>> wrote:
> On 21 Jun 2016, at 22:53, Ben Campbell <[e-mail]<mailto:[e-mail]>> wrote:
>
> On 21 Jun 2016, at 16:48, Colin Perkins wrote:
>
>>> 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.
>
> Okay, that's a good point. But one wonders why bother with the guidance for "undetectable splices" at all? In the example, if an implementation that wants to do commercial skipping can still do it anyway, then why even talk about it? (Other than to say that undetectable splices aren't real?)

It (slightly) simplifies the receiver if it can not care about seeing multiple sources (either SSRC or CSRC, depending on how the splicer was implemented) in the RTP stream.

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