Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80

From: Magnus Westerlund <[email-masked]>
Date: Fri, 6 May 2011 16:18:08 +0200

On 2011-04-13 16:49, Jinwei Xia wrote:

>> Can we conclude that:
>>
>> Translator:
>>     pros:  allow primary source know the situation of full path.
>>     cons: more considertaion for media adaptation; changing RTP SN and/or
>> TS, and that RTCP.
>>
>> Mixer:
>>     pros: straight forward approach for media adaptation.
>>     cons: primary source only know the situation between itself and mixer;
>> changing RTP SN, TS, SSRC and CSRC, and that RTCP.
>>
>> Is there any missing pros & cons of translator and mixer on splicing?

Sorry for dropping out of the discussion.

I think that the document needs to have a little bit of discussion of
the two main approaches and the pro and con list wit a little more
detail than the above. That as I think it is important it is clear under
what premises and reasoning the path was selected.

Then I think we should form a consensus on which approach we think is
the more suitable to describe in all its gory details.

But if minimal detectability is gone, then it might be that translator
becomes more palatable for me.

I am still not certain how one can avoid continues offset rewriting of
rtp sequence number, timestamp etc unless one uses multiple SSRC in
either a mixer or a translator usage.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Xiajinwei <[email-masked]>
Date: Mon, 09 May 2011 16:21:05 +0800

Magnus, 

Thank you for picking up the discussion.  Let's categorize RTP splicing to
detectability and non-detectability. 

In non-detectable case, The RTP header parameters must remain consistent
regardless of the media content the RTP conveys.  We can analyse the
pron&cons of two approaches as following four aspects:

RTP: translator should rewrite the SN and TS when the amount of
substitutived packets is not equal to amount of main packets replaced.
Translator must execute transcoding if the media type are different between
the two streams; Mixer should initiate its own SN and TS for the new media
stream, or transcoding, additionally mixer should change the CSRC for loop
detection. But the CSRC difference can allow downstream client to be able to
detect the switch.

RTCP: translator should rewrite RTCP traffic passing through it to reflect
the real characteristics of each other; Mixer divides RTCP flow between
source and user into two separate RTCP loops, hence media source has no idea
about the situation on user. Compared to translator, mixer is a more
straight forward approach on RTCP. 

Security:  If encryption is employed, the media translator and mixer need to
be able to decrypt and re-encrypt the media stream. The difference is
translator use one cryptographic key per user, mixer use key per domain.
There is not strong requirement to hide translator or mixer from receiver,
but just there is one potential security issue: mixer exposes its address to
receivers and may get attacks from vicious receivers.

Overhead: neither translaotr nor mixer can avoid the overhead while no
splicing occur. When security mechanisms are used, there is more overhead on
translator since it needs to prepare multiple different keying material for
different receiver.

In non-detectable case, I personally incline to translator since translator
can totally eliminate the difference between the two stream and erase the
potential security issue.

In detectable case, the thing becomes simpler. translator is suitable to
handle detectable splicing. When splicing ends, translator resumes main
stream and rewrites the sequence number one higher than the last packet sent
to receiver in the main stream. There is a little overhead on translator to
rewrite RTP SN. If media sender support SSRC multiplexing, the thing becomes
simplest, the splicer can be a normal "switch node" which swith between
multiple streams with different SSRCs to realize zero overhead. The
appropriate solution is decided on whether the headend uses SSRC
multiplexing mechanism. 

BR
Jinwei

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]] 
> Sent: Friday, May 06, 2011 10:18 PM
> To: Jinwei Xia
> Cc: DRAGE, Keith (Keith); [email-masked]
> Subject: Re: [avtext] Splicing: Confirmation of decisions at IETF#80
> 
> >>     cons: more considertaion for media adaptation; changing RTP SN 
> >> and/or TS, and that RTCP.
> >>
> >> Mixer:
> >>     cons: primary source only know the situation between 
> itself and 
> >> mixer; changing RTP SN, TS, SSRC and CSRC, and that RTCP.
> >>
> I think that the document needs to have a little bit of 
> discussion of the two main approaches and the pro and con 
> list wit a little more detail than the above. That as I think 
> it is important it is clear under what premises and reasoning 
> the path was selected.
> 
> Then I think we should form a consensus on which approach we 
> think is the more suitable to describe in all its gory details.
> 
> But if minimal detectability is gone, then it might be that 
> translator becomes more palatable for me.
> 
> I am still not certain how one can avoid continues offset 
> rewriting of rtp sequence number, timestamp etc unless one 
> uses multiple SSRC in either a mixer or a translator usage.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 12 May 2011 11:18:55 +0200

> pron&cons of two approaches as following four aspects:

First of all non-detectable is still detectable just by looking at the
media stream. For example a non-detectable splicing operation with a
video stream using H.264 will still be detectable just because that
streams encoded by different encoders will have different parameter
sets. Only if you do full media transcoding in the splicer can you avoid
this. This is both complex and reduces quality thus I hope this is not
expected.

> detection. But the CSRC difference can allow downstream client to be able to

Hmmm, I am not certain I agree with this description or usage of the
models.

Lets start with the picture

Source1 ---> Splicer ----> receiver
source2 -------^

In a translator case source1 view of the session is that it sees RTCP
feedback from the receiver, at least when its content is forwarded. When
it splices in source 2, then it creates a consistent continuation of
source1 stream by setting SN and TS, while the splicer provide feedback
on delivery to source 1 while it splices instead of the receiver. When
it goes back to source1 it still will need to change SN and TS to
maintain previous consistency.

In a mixer case the splicer will use its own SSRC always and just select
which of the source it uses for the media in the stream. Which means
that the mixer owns the SN and TS space it forwards the media using.
Also feedback will always be separated for the leg to the mixer and the
leg between the mixer and the receiver. If the sources needs to react to
downstream events additional RTCP extensions are needed.
In the mixer case the mixer can select to use CSRC and forward the
corresponding SDES items or not.

> straight forward approach on RTCP. 

Yes, except that if response to other leg is needed, then codec control
messages or similar are needed.

> receivers and may get attacks from vicious receivers.

I don't understand why you come to the conclusion about why translators
and mixers uses different keys. That is up to the implementation.

And if we are talking about IPTV we are anyway talking about payload
internal encryption which neither the boxes will touch unless one has
decided to to media transcoding which seems expensive for this.

> translator since it needs to prepare multiple different keying material for

I don't see the need for having different security overhead between
translator and mixer.

> potential security issue.

I think both can realize the non-detectable case.

> rewrite RTP SN. 

What about the TS? I think that may become inconsistent and thus needs
rewriting also.

If media sender support SSRC multiplexing, the thing becomes
> appropriate solution is decided on whether the headend uses SSRC

I think the question is not if the sender supports SSRC multiplexing,
but if the receivers do. Sending two different RTP streams and hoping
that they are nicely inserted in the gap is possible but not necessarily
trivial.

Cheers

Magnus Westerlund

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 12 May 2011 16:54:17 -0700

Hi Magnus,

Inline...

>this. This is both complex and reduces quality thus I hope this is not

I don't think your example is a good one.  In H.264 (as well as in most
other video compression standards) there are certain points in the
bitstream which break bitstream prediction.  The data (after decoding)
between those points is called a sequence.  A decoder cannot, without
relying on heuristic means, determine whether a bitstream composed of more
than one sequence was produced by one or more than one encoder.

It's equally possible that two decoders use the same parameter sets.  It's
not even unlikely that they do, especially if you are using a "standard"
set of tools and image formats, probably mandated by a profiling
organization such as 3GPP.

At the risk of being proven wrong in an exotic use case, I would even
argue that, with most media codecs, it is very hard or even impossible, to
identify properly implemented splicing without side information of some
kind.

I believe I agree with the rest of Magnus' comments below (without having
thought about them in much detail).

Stephan

>_______________________________________________
>avtext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/avtext

---

From: Xiajinwei <[email-masked]>
Date: Fri, 13 May 2011 11:54:21 +0800

Magnus,

> Sent: Thursday, May 12, 2011 5:19 PM
> To: Xiajinwei
> Cc: 'DRAGE, Keith (Keith)'; [email-masked]
> > Thank you for picking up the discussion.  Let's categorize RTP 
> > splicing to detectability and non-detectability.
> > 
> > In non-detectable case, The RTP header parameters must remain 
> > consistent regardless of the media content the RTP conveys.  We can 
> > analyse the pron&cons of two approaches as following four aspects:
> 
> First of all non-detectable is still detectable just by 
> looking at the media stream. For example a non-detectable 
> splicing operation with a video stream using H.264 will still 
> be detectable just because that streams encoded by different 
> encoders will have different parameter sets. Only if you do 
> full media transcoding in the splicer can you avoid this. 
> This is both complex and reduces quality thus I hope this is 
> not expected.
> 

I agree minimum-detectable is more appropriate. In
draft-xia-avtext-splicing-for-rtp-00, I mentioned the RTP header parameters
MUST remain consistent except that meida type SHOULD be same since
transcoding is prohibitively expensive and complex, so it  is RECOMMENDED to
use same media type in insertion stream as that in main stream. If an
operator want to realize complete non-detectable on client, he must take the
tranacoding cost in account. 

Moreover, Splicer SHOULD also realize minimum-detectable in application
layer, for example, reusing existing PIDs after a splicing described in
[SMPTE-321M]. How this is done is an implementation detail and not discussed
in this draft.

So how about above change? 

> > Translator must execute transcoding if the media type are different 
> > between the two streams; Mixer should initiate its own SN 
> and TS for 
> > the new media stream, or transcoding, additionally mixer 
> should change 
> > the CSRC for loop detection. But the CSRC difference can allow 
> > downstream client to be able to detect the switch.
> 
> Hmmm, I am not certain I agree with this description or usage 
> of the models.
> 
> In a translator case source1 view of the session is that it 
> sees RTCP feedback from the receiver, at least when its 
> content is forwarded. When it splices in source 2, then it 
> creates a consistent continuation of
> source1 stream by setting SN and TS, while the splicer 
> provide feedback on delivery to source 1 while it splices 
> instead of the receiver. When it goes back to source1 it 
> still will need to change SN and TS to maintain previous consistency.
> 
> In a mixer case the splicer will use its own SSRC always and 
> just select which of the source it uses for the media in the 
> stream. Which means that the mixer owns the SN and TS space 
> it forwards the media using.
> Also feedback will always be separated for the leg to the 
> mixer and the leg between the mixer and the receiver. If the 
> sources needs to react to downstream events additional RTCP 
> extensions are needed.
> In the mixer case the mixer can select to use CSRC and 
> forward the corresponding SDES items or not.
> 
> 

Your description is more detailed, also including RTCP processing. Compared
to translator, mixer change the CSRC field in RTP header during splicing.

> 
> > 
> > RTCP: translator should rewrite RTCP traffic passing through it to 
> > reflect the real characteristics of each other; Mixer divides RTCP 
> > flow between source and user into two separate RTCP loops, 
> hence media 
> > source has no idea about the situation on user. Compared to 
> > translator, mixer is a more straight forward approach on RTCP.
> 
> Yes, except that if response to other leg is needed, then 
> codec control messages or similar are needed.
> 

True. RFC5104 can repair it.

> > 
> > Security:  If encryption is employed, the media translator 
> and mixer 
> > need to be able to decrypt and re-encrypt the media stream. The 
> > difference is translator use one cryptographic key per 
> user, mixer use key per domain.
> > There is not strong requirement to hide translator or mixer from 
> > receiver, but just there is one potential security issue: mixer 
> > exposes its address to receivers and may get attacks from 
> vicious receivers.
> 
> I don't understand why you come to the conclusion about why 
> translators and mixers uses different keys. That is up to the 
> implementation.
> 
> And if we are talking about IPTV we are anyway talking about 
> payload internal encryption which neither the boxes will 
> touch unless one has decided to to media transcoding which 
> seems expensive for this.

an translator change the payload of RTP during splicing with SSRC intact,
should it use different keys for different segments? 

> > splicing occur. When security mechanisms are used, there is more 
> > overhead on translator since it needs to prepare multiple different 
> > keying material for different receiver.
> 
> I don't see the need for having different security overhead 
> between translator and mixer.
> 
> > 
> > 
> > In non-detectable case, I personally incline to translator since 
> > translator can totally eliminate the difference between the 
> two stream 
> > and erase the potential security issue.
> 

Yes, both can do that. The problem is which one is better. What's your
prefer in the two candidates or otherwise?

> > 
> > 
> > In detectable case, the thing becomes simpler. translator 
> is suitable 
> > to handle detectable splicing. When splicing ends, 
> translator resumes 
> > main stream and rewrites the sequence number one higher 
> than the last 
> > packet sent to receiver in the main stream. There is a 
> little overhead 
> > on translator to rewrite RTP SN.
> 
> What about the TS? I think that may become inconsistent and 
> thus needs rewriting also.

Sorry for missing it again, the TS is higher than the last inserted packet
to maintain consistency.

> > simplest, the splicer can be a normal "switch node" which swith 
> > between multiple streams with different SSRCs to realize zero 
> > overhead. The appropriate solution is decided on whether 
> the headend 
> > uses SSRC multiplexing mechanism.
> 
> I think the question is not if the sender supports SSRC 
> multiplexing, but if the receivers do. Sending two different 
> RTP streams and hoping that they are nicely inserted in the 
> gap is possible but not necessarily trivial.

Yes, this is inner implementation to fill up the gap. Using SSRC
multiplexing may be the most straight forward approach for detectable case.

Thank you

Jinwei

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 13 May 2011 09:56:40 +0200

> identify properly implemented splicing without side information of some

I agree that it is not certain that you can detect, but in certain case
you will be able to detect, at least using heuristics.

Yes, if you ensure a certain level of harmonization between the encoding
I agree you can make it difficult to detect.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Mon, 16 May 2011 11:47:18 +0100

> What about the TS? I think that may become inconsistent and thus needs

I'd think it reasonable to require that the inserted content MUST be the same duration as the original content. Otherwise, not only will you need to rewrite the timestamps after the splicing has ended, you'll either have a gap or extra data to be buffered somewhere. You'll only have to rewrite timestamps during the splicing, to normalise the random offset.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 May 2011 09:14:32 +0200

> So how about above change? 

I guess PIDs are protocol IDs. I think one needs to have a more detailed
discussion on what IDs can be reused and when they can't.

> to translator, mixer change the CSRC field in RTP header during splicing.

It may do that, it is not a strict requirement to use CSRC in mixers.
And in a splicer there appears to be benefits of not including the CRSC.

> should it use different keys for different segments? 

For the payload internal stuff people are using, it can likely handle
such key changes using security payload internal mechanism. The whole
point with these payload internal mechanisms is that no entity between
the content source and the decoder actually needs to have the key.

If one uses regular transport security like SRTP or DTLS, IPsec, etc.
then you need to re-process all the packets if you change something in
them. Thus different key-context for the different legs makes sense.

> prefer in the two candidates or otherwise?

I think it comes down to how one wants to organize the splicer and the
upstream content sources. To which degree they should aware of the
splicer and if requiring changes to them are acceptable, specifically
the original content source.

If modifying the original content source is out of the picture then I
think a translator is the right way to go, although I believe it will
require a bit more text to describe all the aspects one needs to think
about.

If one can modify the original content source, then I think a mixer is
more straight forward and thus easier to describe.

What the answer is to the modifying question I don't know. Input is
desirable.

> multiplexing may be the most straight forward approach for detectable case.

Yes, but also least likely to ensure glitch free media processing, at
least before you have updated your receivers to include a few mechanisms
to ensure that they can quickly and correctly create a common timeline.

Thus I think SSRC multiplexing is to quite a large degree a red herring
in this case. It will not work well in legacy case, and even with
updates it is still creating potential issues. Thus I think using a
single SSRC and inserting the content into the stream is the most likely
to work well.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 May 2011 09:18:36 +0200

On 2011-05-16 12:47, Colin Perkins wrote:

> I'd think it reasonable to require that the inserted content MUST be
> the same duration as the original content. Otherwise, not only will
> you need to rewrite the timestamps after the splicing has ended,
> you'll either have a gap or extra data to be buffered somewhere.
> You'll only have to rewrite timestamps during the splicing, to
> normalise the random offset.
> 

I agree that you need to have content to insert that is very close to
the space you are replacing. The question is what happens when things
are off with a video frame or less, or an audio frame or less.

One thing to worry about here is what happens if the frame rate varies
between the content, then you may have a small diff to take care of.
Yes, letting that be a bit extra delay between content in the point of
switching is back is likely fine, but it needs to be discussed in the
document.

I might have made the impression that this issue is bigger than it
really is.

Cheers

Magnus Westerlund

---

From: Jinwei Xia <[email-masked]>
Date: Tue, 17 May 2011 17:55:05 +0800

Magnus,

Inline~~

> Sent: Tuesday, May 17, 2011 3:19 PM
> To: Colin Perkins
> Cc: Xiajinwei; [email-masked]
> >>> In detectable case, the thing becomes simpler. translator is 
> >>> suitable to handle detectable splicing. When splicing ends, 
> >>> translator resumes main stream and rewrites the sequence 
> number one 
> >>> higher than the last packet sent to receiver in the main stream. 
> >>> There is a little overhead on translator to rewrite RTP SN.
> >>
> >> What about the TS? I think that may become inconsistent and thus 
> >> needs rewriting also.
> > 
> I agree that you need to have content to insert that is very 
> close to the space you are replacing. The question is what 
> happens when things are off with a video frame or less, or an 
> audio frame or less.
> 

Your concern make senses, one of splicing requirements is Splicer SHOULD NOT
cause perceptible media clipping at the splicing joint.  Media source must
schedule the splicing point which usually is the boundary of two
independently decodable frames. When audio and video are not interleaved,
each audio frame is usually decodable for common audio codecs. For video,
some predicted frames need to depent on other frames, so the splicing point
is usually at the Group of Pictures (GoP) boundary instead.

> One thing to worry about here is what happens if the frame 
> rate varies between the content, then you may have a small 
> diff to take care of.
> Yes, letting that be a bit extra delay between content in the 
> point of switching is back is likely fine, but it needs to be 
> discussed in the document.

Media encoding bitrates of the two contents may be different but the
difference should be minor, since both of them should match the user's media
comsuption rate to ensure that the user's buffer remains at a stable level
over time. If the encoding bitrate of insertion content is drastically
higher or lower than that of main content when splicing begins, user might
rapidly flood or drain its buffer, and eventually result in a buffer
overflow or underflow. So the insertion content is recommended to be encoded
at an appropriate bitrate to match main content's. If the insertion content
comes from another media source, the source may have knowledge about the
media encoding bitrate of main content in advance. How does it know that is
out of scope in this draft.

I will add above content in next version.

Thank you again!

Jinwei

> 
> I might have made the impression that this issue is bigger 
> than it really is.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Jinwei Xia <[email-masked]>
Date: Mon, 23 May 2011 15:02:05 +0800

Hi Magnus，

Sorry for my late response.

> > draft-xia-avtext-splicing-for-rtp-00, I mentioned the RTP header 
> > parameters MUST remain consistent except that meida type SHOULD be 
> > same since transcoding is prohibitively expensive and 
> complex, so it  
> > is RECOMMENDED to use same media type in insertion stream 
> as that in 
> > main stream. If an operator want to realize complete 
> non-detectable on 
> > client, he must take the tranacoding cost in account.
> > 
> > Moreover, Splicer SHOULD also realize minimum-detectable in 
> > application layer, for example, reusing existing PIDs after 
> a splicing 
> > described in [SMPTE-321M]. How this is done is an implementation 
> > detail and not discussed in this draft.
> > 
> I guess PIDs are protocol IDs. I think one needs to have a 
> more detailed discussion on what IDs can be reused and when 
> they can't.
> 

No, PID is packet identifier, a 13-bit ID to to identify elementary stream of a program in MPEG2 transport stream.For each program, there is one unique Program Map Table (PMT), each program includes multiple streams (video, audio and metadata), each stream has its unique packet identifier (PID). 

Since splicing changes the contents of a transport stream, and the PIDs (i.e., new PIDs in insertion stream), then the changes must be reflected in valid PMT packets. Splicer are responsible for
sending any changes to the PMT required to accommodate changes in the number of PIDs after a splicing.

However, in order to prevent commercial killing devices from taking advantage of changes in PMT, systems with splicing are encouraged to avoid changes to the PMT by reusing existing video and audio PIDs (i.e., PIDs in original stream) after a splicing.

> > an translator change the payload of RTP during splicing with SSRC 
> > intact, should it use different keys for different segments?
> 
> For the payload internal stuff people are using, it can 
> likely handle such key changes using security payload 
> internal mechanism. The whole point with these payload 
> internal mechanisms is that no entity between the content 
> source and the decoder actually needs to have the key.
> 
> then you need to re-process all the packets if you change 
> something in them. Thus different key-context for the 
> different legs makes sense.

Right, we should narrow the security scope into transport security since the we are discussing splicing in media transport area.  The security considerations will give the SRTP based security contexts in future version.

> I think it comes down to how one wants to organize the 
> splicer and the upstream content sources. To which degree 
> they should aware of the splicer and if requiring changes to 
> them are acceptable, specifically the original content source.
> 
> If modifying the original content source is out of the 
> picture then I think a translator is the right way to go, 
> although I believe it will require a bit more text to 
> describe all the aspects one needs to think about.
> 
> If one can modify the original content source, then I think a 
> mixer is more straight forward and thus easier to describe.
> 
> What the answer is to the modifying question I don't know. 
> Input is desirable.
> 

I think this is a key point, but feeling a little confusion about above analysis. Based on our previous discussion, whether translator or mixer can act as splicer needs to take two aspects into account when minimum-detectable requirement is supported. One aspect is bitrate adaption to handle varying network condition, another is overhead on splicer while splicing is not active. But neither seems to be related to original content source changing requirement, do you mean the original content source should reserve some gap in the content using some sort of RTP empty packets during the gap time, or otherwise?

Another confusing point is the mixer definition in RFC3550: "An intermediate system that receives RTP packets from one or more sources, possibly changes the data format, combines the packets in some manner and then forwards a new RTP packet." I am not sure whether combine implies a full mix, but a splicer does not combine packets in some manner, it merely decides which of two streams to forward.

> Yes, but also least likely to ensure glitch free media 
> processing, at least before you have updated your receivers 
> to include a few mechanisms to ensure that they can quickly 
> and correctly create a common timeline.
> 
> Thus I think SSRC multiplexing is to quite a large degree a 
> red herring in this case. It will not work well in legacy 
> case, and even with updates it is still creating potential 
> issues. Thus I think using a single SSRC and inserting the 
> content into the stream is the most likely to work well.

Agree, let's simplify the case and focus on a single SSRC.

Thank you

Jinwei

---

From: Colin Perkins <[email-masked]>
Date: Mon, 23 May 2011 11:54:01 +0100

On 17 May 2011, at 08:18, Magnus Westerlund wrote:
>>>> In detectable case, the thing becomes simpler. translator is suitable to handle detectable splicing. When splicing ends, translator resumes main stream and rewrites the sequence number one higher than the last packet sent to receiver in the main stream. There is a little overhead on translator to rewrite RTP SN. 
>>> 
>>> What about the TS? I think that may become inconsistent and thus needs rewriting also.
>> 
> I agree that you need to have content to insert that is very close to the space you are replacing. The question is what happens when things are off with a video frame or less, or an audio frame or less.
> 
> One thing to worry about here is what happens if the frame rate varies between the content, then you may have a small diff to take care of. Yes, letting that be a bit extra delay between content in the point of switching is back is likely fine, but it needs to be discussed in the document.

Okay, this makes sense. I guess providing the inserted content is not longer than the gap, there's no real problem, and the draft just needs to mention the issue. If the inserted content might be longer, then things get a little more complex.

> I might have made the impression that this issue is bigger than it really is.
> 
> Cheers
> 
> Magnus Westerlund
> 

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 23 May 2011 12:03:40 +0100

On 23 May 2011, at 08:02, Jinwei Xia wrote:
>>> I agree minimum-detectable is more appropriate. In draft-xia-avtext-splicing-for-rtp-00, I mentioned the RTP header parameters MUST remain consistent except that meida type SHOULD be same since transcoding is prohibitively expensive and complex, so it  is RECOMMENDED to use same media type in insertion stream as that in main stream. If an operator want to realize complete non-detectable on client, he must take the tranacoding cost in account.
>>> 
>>> Moreover, Splicer SHOULD also realize minimum-detectable in application layer, for example, reusing existing PIDs after a splicing described in [SMPTE-321M]. How this is done is an implementation detail and not discussed in this draft.
>>> 
>> I guess PIDs are protocol IDs. I think one needs to have a more detailed discussion on what IDs can be reused and when they can't.
> 
> Since splicing changes the contents of a transport stream, and the PIDs (i.e., new PIDs in insertion stream), then the changes must be reflected in valid PMT packets. Splicer are responsible for sending any changes to the PMT required to accommodate changes in the number of PIDs after a splicing.
> 

This sounds like something that should be specified by MPEG, not by IETF. Is there an MPEG document that this draft can reference to discuss how MPEG-specific payload data is manipulated?

>>> an translator change the payload of RTP during splicing with SSRC intact, should it use different keys for different segments?
>> 
>> For the payload internal stuff people are using, it can likely handle such key changes using security payload internal mechanism. The whole point with these payload internal mechanisms is that no entity between the content source and the decoder actually needs to have the key.
>> 
>> If one uses regular transport security like SRTP or DTLS, IPsec, etc. then you need to re-process all the packets if you change something in them. Thus different key-context for the different legs makes sense.
> 

People are using payload internal security, so it needs to be mentioned in the draft, but (as this the PID stuff), it should probably be by reference to some other document.

>>>>> In non-detectable case, I personally incline to translator since translator can totally eliminate the difference between the two stream and erase the potential security issue.
>>>> 
>>> Yes, both can do that. The problem is which one is better. What's your prefer in the two candidates or otherwise?
>> 
>>> Yes, this is inner implementation to fill up the gap. Using SSRC multiplexing may be the most straight forward approach for detectable case.
>> 
>> Yes, but also least likely to ensure glitch free media processing, at least before you have updated your receivers to include a few mechanisms to ensure that they can quickly and correctly create a common timeline.
>> 
>> Thus I think SSRC multiplexing is to quite a large degree a red herring in this case. It will not work well in legacy case, and even with updates it is still creating potential issues. Thus I think using a single SSRC and inserting the content into the stream is the most likely to work well.
> 

I think the draft would be much clearer if it focussed on either non-detectable (e.g., using a translator) or detectable splicing, and didn't try to discuss both.

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

---

From: Jinwei Xia <[email-masked]>
Date: Tue, 24 May 2011 11:25:38 +0800

Hi Colin,

> > No, PID is packet identifier, a 13-bit ID to to identify 
> elementary stream of a program in MPEG2 transport stream.For 
> each program, there is one unique Program Map Table (PMT), 
> each program includes multiple streams (video, audio and 
> metadata), each stream has its unique packet identifier (PID). 
> > 
> > Since splicing changes the contents of a transport stream, 
> and the PIDs (i.e., new PIDs in insertion stream), then the 
> changes must be reflected in valid PMT packets. Splicer are 
> responsible for sending any changes to the PMT required to 
> accommodate changes in the number of PIDs after a splicing.
> > 
> > However, in order to prevent commercial killing devices 
> from taking advantage of changes in PMT, systems with 
> splicing are encouraged to avoid changes to the PMT by 
> reusing existing video and audio PIDs (i.e., PIDs in original 
> stream) after a splicing.
> 
> This sounds like something that should be specified by MPEG, 
> not by IETF. Is there an MPEG document that this draft can 
> reference to discuss how MPEG-specific payload data is manipulated?

Right, above description is about MPEG splicing, I just interprets how
non-detectable splicing is done in application layer herein, but would not
include above description in draft. There are several MPEG-splicing
references in SCTE and SMPTE STDs.

> 
> >>> an translator change the payload of RTP during splicing 
> with SSRC intact, should it use different keys for different segments?
> >> 
> >> If one uses regular transport security like SRTP or DTLS, 
> IPsec, etc. then you need to re-process all the packets if 
> you change something in them. Thus different key-context for 
> the different legs makes sense.
> > 
> > Right, we should narrow the security scope into transport 
> security since the we are discussing splicing in media 
> transport area.  The security considerations will give the 
> SRTP based security contexts in future version.
> 
> People are using payload internal security, so it needs to be 
> mentioned in the draft, but (as this the PID stuff), it 
> should probably be by reference to some other document.
> 

Accept

> >> Thus I think SSRC multiplexing is to quite a large degree 
> a red herring in this case. It will not work well in legacy 
> I think the draft would be much clearer if it focussed on 
> either non-detectable (e.g., using a translator) or 
> detectable splicing, and didn't try to discuss both.
> 

Both cases can be discussed in the maillist with wide scope, but if there
should be only one solution in a single draft, I prefer to address
minimum-detectable case. 

Thank you.

Jinwei