Subject: Re: [AVT] New Version Notification for draft-xia-avt-splicing-for-mpeg2ts-ps-00

From: Jinwei Xia <[email-masked]>
Date: Wed, 10 Mar 2010 11:53:58 +0800

Hi all,

We just submit a new draft "draft-xia-avt-splicing-for-mpeg2ts-ps-00" to
analyse the problem existed on transport layer when performing splicing in
MPEG2-TS.

Here is the initial version:
http://tools.ietf.org/html/draft-xia-avt-splicing-for-mpeg2ts-ps-00

Any comments are very welcome~ Thank you!

BR
Jinwei

> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]] 
> Sent: Monday, March 01, 2010 6:03 PM
> To: [email-masked]
> Subject: New Version Notification for 
> draft-xia-avt-splicing-for-mpeg2ts-ps-00
> 
> 
> A new version of I-D, 
> draft-xia-avt-splicing-for-mpeg2ts-ps-00.txt has been 
> successfuly submitted by Jinwei Xia and posted to the IETF repository.
> 
> Filename:	 draft-xia-avt-splicing-for-mpeg2ts-ps
> Revision:	 00
> Title:		 Splicing for MPEG2-TS Problem 
> Statement in RTP Sessions
> Creation_date:	 2010-02-28
> WG ID:		 Independent Submission
> Number_of_pages: 9
> 
> Abstract:
> The base splicing related protocols, i.e., Digital Program 
> Insertion Splicing API [SCTE30] and Digital Program Insertion 
> Cueing Message for Cable [SCTE35], only take into account how 
> to insert the content (e.g. spot advertisements of various 
> lengths, program substitution, public service announcements 
> etc.) into any MPEG-2 Output Multiplex in the Splicer and how 
> to carry notification of upcoming Splicing and other timing 
> information in the transport stream, but not give enough 
> mechanisms to direct underlying transport protocol such as 
> RTP how to work compatibly with the spliced MPEG2-TS.  This 
> memo highlights the issues of what's the impact on RTP layer 
> when performing splicing between the primary channel and the 
> insertion channel.
>                                                               
>                     
> 
> 
> The IETF Secretariat.
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Sun, 14 Mar 2010 10:53:16 +0000

Jinwei,

The Splicer described in this draft is an RTP Translator, in the sense  
of RFC 3550 section 7, and must perform all the processing specified  
there. The analysis doesn't seem to recognise this.

Colin

On 10 Mar 2010, at 03:53, Jinwei Xia wrote:
> Hi all,
>
> We just submit a new draft "draft-xia-avt-splicing-for-mpeg2ts- 
> ps-00" to analyse the problem existed on transport layer when  
> performing splicing in MPEG2-TS.
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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

---

From: Jinwei Xia <[email-masked]>
Date: Mon, 15 Mar 2010 13:51:34 +0800

Hi Colin,

Thank your review and comments!

> 
> The Splicer described in this draft is an RTP Translator, in 
> the sense of RFC 3550 section 7, and must perform all the 
> processing specified there. 

Indeed, the splicer is a specified translator in advertisement insertion
scenario.  splicer needs to re-encode ads data packets into primary program,
and assigns new sequence numbers to the outgoing data packets.  The problem
is splicer can not switch to data-untouched mode to mitigate the overhead on
it for a long period of time when splicing no more occurs again.

>The analysis doesn't seem to 
> recognise this.

Right, I will refer RFC3550 and highlight Translator in updated version. 

Thank you~

BR
Jinwei

> >> draft-xia-avt-splicing-for-mpeg2ts-ps-00.txt has been successfuly 
> >> submitted by Jinwei Xia and posted to the IETF repository.
> >>
> Insertion 
> >> Splicing API [SCTE30] and Digital Program Insertion Cueing Message 
> >> for Cable [SCTE35], only take into account how to insert 
> the content 
> >> (e.g. spot advertisements of various lengths, program 
> substitution, 
> >> public service announcements
> >> etc.) into any MPEG-2 Output Multiplex in the Splicer and how to 
> >> carry notification of upcoming Splicing and other timing 
> information 
> >> in the transport stream, but not give enough mechanisms to direct 
> >> underlying transport protocol such as RTP how to work 
> compatibly with 
> >> the spliced MPEG2-TS.  This memo highlights the issues of 
> what's the 
> >> impact on RTP layer when performing splicing between the primary 
> >> channel and the insertion channel.
> >>
> >>
> >>
> >>
> >> The IETF Secretariat.
> >>
> >>
> >

---

From: Colin Perkins <[email-masked]>
Date: Mon, 15 Mar 2010 09:23:12 +0000

On 15 Mar 2010, at 05:51, Jinwei Xia wrote:

> Indeed, the splicer is a specified translator in advertisement  
> insertion scenario.  splicer needs to re-encode ads data packets  
> into primary program, and assigns new sequence numbers to the  
> outgoing data packets.

...which implies that it must also rewrite RTCP packets to match.

Colin

> The problem is splicer can not switch to data-untouched mode to  
> mitigate the overhead on it for a long period of time when splicing  
> no more occurs again.
>

---

From: Jinwei Xia <[email-masked]>
Date: Mon, 15 Mar 2010 19:43:21 +0800

Hi Colin,

> >
> >>
> >> The Splicer described in this draft is an RTP Translator, in the 
> >> sense of RFC 3550 section 7, and must perform all the processing 
> >> specified there.
> >
> > insertion scenario.  splicer needs to re-encode ads data 
> packets into 
> > primary program, and assigns new sequence numbers to the 
> outgoing data 
> > packets.
> 

That is right, the corresponding RTCP packets should be modified based on
RFC3550 section 7.2 too. The related content will be added in the next
version.

Thank you

Jinwei

> > mitigate the overhead on it for a long period of time when 
> splicing no 
> > more occurs again.
> >
> successfuly