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

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

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?

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