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

["Ben Campbell" <[e-mail]>]

On 21 Jun 2016, at 22:13, Huangyihong (Rachel) wrote:

> Please see below.
>
> BR,
> Rachel
>
>
>> -----Original Message-----
>> From: Ben Campbell [mailto:[e-mail]]
>> Sent: Wednesday, June 22, 2016 6:41 AM
>> To: Colin Perkins
>> 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 16:57, Colin Perkins wrote:
>>
>>>> On 21 Jun 2016, at 22:53, Ben Campbell <[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.
>>
>> That may be the best motivation for not forwarding the input SSRCs 
>> offered so
>> far.
>
>
> [Rachel]: I'm think if it's okay to not specify "undetectable 
> splicing" in this document: This draft is to extend a RTP header 
> extension and RTCP extension message for splicing interval, which is 
> actually a message communicated between the sender and the splicer. So 
> maybe we just need to specify that the splicer MUST NOT forward these 
> extensions to the receivers, cause these messages are useless to them. 
> For undetectable splicing, it has already been written in RFC6828, 
> where splicer works as a mixer. If the splicer works as a translator, 
> it's impossible for receivers not to detect the splicing happens in 
> RTP layer. So I guess there's no need to specify any undetectable 
> splicing activities in this document. What do you think?

I'm generally okay with that, but I want to see what others think,

I do, though, wonder if the MUST NOT is still justified at this point. 
If the motivation is just that forwarding the messages are useless, or 
even a nuisance, MUST seems a bit strong. That is, it doesn't seem to 
impact interoperability, or otherwise create a real problem. This seems 
better stated without 2119 keywords.

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