Subject: [AVT] New Version Notification for draft-xia-avt-mpeg2ts-preamble-01

From: Peilin YANG <[email-masked]>
Date: Fri, 11 Dec 2009 10:42:02 +0800

Hi Ali,

A new version of the draft “Preamble Acquisition of MPEG2-TS Multicast Sessions”is available: http://www.ietf.org/id/draft-xia-avt-mpeg2ts-preamble-01.txt.

Based on "Discuss Mpeg2TS preamble - meeting room"in Japan, I made some revision and supplemented some new PSI informaiton. 

Comments and guidance on how to proceed are welcome.

Regards,

Peilin

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
 immediately and delete it!
 *****************************************************************************************

Subject: New Version Notification for draft-xia-avt-mpeg2ts-preamble-01
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Thu, 10 Dec 2009 18:22:19 -0800 (PST)

A new version of I-D, draft-xia-avt-mpeg2ts-preamble-01.txt has been successfuly submitted by Peilin Yang and posted to the IETF repository.

Filename:	 draft-xia-avt-mpeg2ts-preamble
Revision:	 01
Title:		 Preamble Acquisition of MPEG2-TS Multicast Sessions
Creation_date:	 2009-12-10
WG ID:		 Independent Submission
Number_of_pages: 19

Abstract:
The ITU-T Rec. H.222.0 | ISO/IEC 13818-1 Transport Stream (MPEG2-TS)
addresses the combining of one or more elementary streams of video
and audio, as well as other data, into single or multiple streams
which are suitable for storage or transmission.  The necessary and
sufficient information contained in the Program Specific
Information(PSI) tables to demultiplex and present programs must be
acquired before a RTP receiver can process any data received in
MPEG2-TS.  In this document, a Retransmission Server is specified to
deliver MPEG2-TS preamble prior to unicast burst RTP packets.  The
Retransmission Server caches raw RTP packets with MPEG2-TS preamble
information, and sends them to the RTP receiver which initiates rapid
acquisition of MPEG2-TS multicast sessions.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on June 13, 2010.Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

The IETF Secretariat.

---

From: Peilin YANG <[email-masked]>
Date: Wed, 16 Dec 2009 15:45:34 +0800

Hi Ali,

I estimate that you have been busy dealing with the comments of RAMS a few days ago and no enough time to review my draft.

I have some comments to your draft.

Except the types of PSI(PAT/PMT/PCR/ECM/EMM/CAT/PTS) described in your draft, ISO13818-1(2000) still defines other PSIs which are not in common use, such as NIT, OPCR, 256 transport stream description elements(in Transport Stream Description Table), User Private(unknowable type and numbers)... Are you going to define types for them?

In addition, ISO13818-1(2007) defines PSI for IPMP again. ETSI EN 300 468 also defines some PSIs(SDT, EIT...). other orgornazation's definition(unknown). What's your suggestion?

Regards,

Peilin

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期三, 十二月 16日, 2009 下午2:50
主题: RE: [AVT]New Version Notification for draft-xia-avt-mpeg2ts-preamble-01
收件人: Peilin YANG <[email-masked]>
抄送: Colin Perkins <[email-masked]>, Stephan Wenger <[email-masked]>, Roni Even <[email-masked]>

> Thanks for the draft. I suppose the chairs need to ping the WG 
> again to review both proposals and make a decision so that we can 
> move this work forward.
> 
> -acbegen
> 
> > -----Original Message-----
> > From: Peilin YANG [mailto:[email-masked]]
> > Sent: Thursday, December 10, 2009 9:42 PM
> > To: Ali C. Begen (abegen)
> > Cc: Colin Perkins; 'Stephan Wenger'; Roni Even; IETF AVT WG
> > Subject: [AVT]New Version Notification for draft-xia-avt-mpeg2ts-
> preamble-01
> > 
> > Hi Ali,
> > 
> > A new version of the draft “Preamble Acquisition of MPEG2-TS 
> Multicast Sessions”is
> > available: http://www.ietf.org/id/draft-xia-avt-mpeg2ts-preamble-
> 01.txt.> 
> > Based on "Discuss Mpeg2TS preamble - meeting room"in Japan, I 
> made some revision and
> > supplemented some new PSI informaiton.
> > 
> ******************************************************************************************>  This email and its attachments contain confidential information from HUAWEI, which is
> > intended only for the person or entity whose address is listed 
> above. Any use of the
> > information contained here in any way (including, but not 
> limited to, total or partial
> > disclosure, reproduction, or dissemination) by persons other 
> than the intended
> > recipient(s) is prohibited. If you receive this email in error, 
> please notify the sender
> > by phone or email

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 16 Dec 2009 06:50:49 -0800

Hi Peilin,

> Sent: Wednesday, December 16, 2009 2:46 AM
> Cc: Colin Perkins; Stephan Wenger; Roni Even; [email-masked]
> Subject: Comments to draft-begen-avt-rtp-mpeg2ts-preamble//RE: [AVT]New Version
> Notification for draft-xia-avt-mpeg2ts-preamble-01
> 
> Hi Ali,
> 

I reviewed it but I will wait for the WG to review and comment on both proposals. The WG should have enough material to evaluate the options.
 
> Except the types of PSI(PAT/PMT/PCR/ECM/EMM/CAT/PTS) described in your draft, ISO13818-
> 1(2000) still defines other PSIs which are not in common use, such as NIT, OPCR, 256
> transport stream description elements(in Transport Stream Description Table), User
> Private(unknowable type and numbers)... Are you going to define types for them?

Is anybody using them in the context of RAMS? If so, we can define them.
 
> In addition, ISO13818-1(2007) defines PSI for IPMP again. ETSI EN 300 468 also defines
> some PSIs(SDT, EIT...). other orgornazation's definition(unknown). What's your suggestion?

We have an extension mechanism that can be used by anybody by registering the type values for new TOLV elements. If there is a need for a new type in the future, the registry can be extended with a simple specification.

-acbegen
 
>  This email and its attachments contain confidential information from HUAWEI, which is
> intended only for the person or entity whose address is listed above. Any use of the
> information contained here in any way (including, but not limited to, total or partial
> disclosure, reproduction, or dissemination) by persons other than the intended
> recipient(s) is prohibited. If you receive this email in error, please notify the sender
> by phone or email
> >  This email and its attachments contain confidential information from HUAWEI, which is

---

From: Peilin YANG <[email-masked]>
Date: Thu, 17 Dec 2009 16:22:55 +0800

Hi Ali,

I got some IPTV streams from different Telecommunication Companies which have different PSIs. I illustrated some MPEGs-TS with some PSIs 
1. The first has PAT, PMT, ECM(ECM included in PMT), PCR(PCR included in Video adaption field). 
2. The second has PAT, PMT, ECM(ECM included in CAT), PCR(PCR with an independent PID)
3. The third has PAT,PMT, PCR, Serveral transport stream description elements(Maximum bitrate descriptor,System clock descriptor,Smoothing buffer descriptor)
4. The fourth has PAT,PMT,CAT,ECM,SDT,EIT.
5. The fifth has PAT,PMT,NIT.
...

In therory you can register and extend all these type values for new TOLV elements. However, RTP receivers need to update their software to support if only there is a new TOLV element. It is unconvenient and not flexible for RTP receivers. In fact, a RTP session doesn't need to concern this.

For my method, MPEG2-TS PSIs is transparent for RTP sessions which forward it to the demux/decoder. It don't need to update any software if a new PSI happens only if demux/decoder can support it. It is very flexible to RTP receivers.

In addition I found another question to your method, the length of the IPMP is three bytes.
 
Peilin  

----- 原邮件 -----
发件人: "Ali C. Begen (abegen)" <[email-masked]>
日期: 星期三, 十二月 16日, 2009 下午10:51
主题: RE: Comments to draft-begen-avt-rtp-mpeg2ts-preamble//RE: [AVT]New Version Notification for draft-xia-avt-mpeg2ts-preamble-01
收件人: Peilin YANG <[email-masked]>
抄送: Colin Perkins <[email-masked]>, Stephan Wenger <[email-masked]>, Roni Even <[email-masked]>, [email-masked]

> > I estimate that you have been busy dealing with the comments of 
> RAMS a few days ago and no
> > enough time to review my draft.
> 
> I reviewed it but I will wait for the WG to review and comment on 
> both proposals. The WG should have enough material to evaluate the 
> options. 
> > some PSIs(SDT, EIT...). other orgornazation's 
> definition(unknown). What's your suggestion?
> 
> We have an extension mechanism that can be used by anybody by 
> registering the type values for new TOLV elements. If there is a 
> need for a new type in the future, the registry can be extended 
> with a simple specification.
> 
> -acbegen
> 
> > Regards,
> > 
> > Peilin
> > 
> > 
> *****************************************************************************************> 
> > ----- 原邮件 -----
> > 抄送: Colin Perkins <[email-masked]>, Stephan Wenger 
> <[email-masked]>, Roni Even
> > <[email-masked]>
> > 
> ******************************************************************************************> >  This email and its attachments contain confidential information from HUAWEI, which is

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 17 Dec 2009 07:19:01 -0800

> Sent: Thursday, December 17, 2009 3:23 AM
> Subject: RE: Comments to draft-begen-avt-rtp-mpeg2ts-preamble//RE: [AVT]New Version
> I got some IPTV streams from different Telecommunication Companies which have different
> PSIs. I illustrated some MPEGs-TS with some PSIs
> 3. The third has PAT,PMT, PCR, Serveral transport stream description elements(Maximum
> bitrate descriptor,System clock descriptor,Smoothing buffer descriptor)

I am quite sure you can find any type of mpeg2 transport streams that contain any subsets of these elements if you search enough. But, if they are not related to RAMS, we don't need to define them.
 
> In therory you can register and extend all these type values for new TOLV elements.
> However, RTP receivers need to update their software to support if only there is a new
> TOLV element. It is unconvenient and not flexible for RTP receivers. In fact, a RTP
> session doesn't need to concern this.

The stuff needed for RAMS is already defined in the draft. For other elements such as NIT, they will show up in the burst packets and the source packets upon joining the multicast session. So, it is not like we drop them somewhere. They are not needed for RAMS so we don't carry them. Any redundant element will make the preamble data larger and more susceptible to loss.
 
> For my method, MPEG2-TS PSIs is transparent for RTP sessions which forward it to the
> demux/decoder. It don't need to update any software if a new PSI happens only if
> demux/decoder can support it. It is very flexible to RTP receivers.

This is your opinion. In the breakout session, we discussed in detail which proposal offered more extensibility and flexibility.
 
> In addition I found another question to your method, the length of the IPMP is three

Ha? I don’t think IPMP is related to RAMS in anyway. I don't think our draft has it either.

-acbegen
 
> 主题: RE: Comments to draft-begen-avt-rtp-mpeg2ts-preamble//RE: [AVT]New Version

---

From: Roni Even <[email-masked]>
Date: Thu, 17 Dec 2009 17:35:53 +0200

Hi,
I think that Peilin is pointing out that the PSI information includes more
elements than the ones currently specified in
draft-begen-avt-rtp-mpeg2ts-preamble. Your response says that they are not
needed for RAMS. I think that every element that is needed in order to start
decoding the requested program is needed or you will have to wait for it. I
have not seen in the draft-begen-avt-rtp-mpeg2ts-preamble any analysis of
the all the PSI information explaining why you need only a specific subset. 
draft-xia-avt-mpeg2ts-preamble does not require to define TLOV element for
these elements so it is easy for the RS to support the elements the
applications wants to convey in the preamble without requiring any change on
the RTP_Rx

Regards
Roni Even as Individual

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Thursday, December 17, 2009 5:19 PM
> To: Peilin YANG
> Cc: Stephan Wenger; Colin Perkins; Roni Even; [email-masked]
> Subject: Re: [AVT] Comments to draft-begen-avt-rtp-mpeg2ts-
> preamble//RE: New Version Notification for draft-xia-avt-mpeg2ts-
> preamble-01
> 
> 
> 
> > 1. The first has PAT, PMT, ECM(ECM included in PMT), PCR(PCR included
> in Video adaption
> > field).
> I am quite sure you can find any type of mpeg2 transport streams that
> contain any subsets of these elements if you search enough. But, if
> they are not related to RAMS, we don't need to define them.
> 
> The stuff needed for RAMS is already defined in the draft. For other
> elements such as NIT, they will show up in the burst packets and the
> source packets upon joining the multicast session. So, it is not like
> we drop them somewhere. They are not needed for RAMS so we don't carry
> them. Any redundant element will make the preamble data larger and more
> susceptible to loss.
> 
> This is your opinion. In the breakout session, we discussed in detail
> which proposal offered more extensibility and flexibility.
> 
> > In addition I found another question to your method, the length of
> the IPMP is three
> > bytes.
> 
> > <[email-masked]>, [email-masked]
> >
> > > Hi Peilin,
> > >
> > > > 主题: RE: [AVT]New Version Notification for draft-xia-avt-
> mpeg2ts-
> > > preamble-01
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Eric Friedrich <[email-masked]>
Date: Thu, 17 Dec 2009 10:43:02 -0500

Thanks for the comments Peilin.

On Dec 17, 2009, at 3:22 AM, Peilin YANG wrote:

> Hi Ali,
>
> I got some IPTV streams from different Telecommunication Companies  
> which have different PSIs. I illustrated some MPEGs-TS with some PSIs
> 3. The third has PAT,PMT, PCR, Serveral transport stream description  
> elements(Maximum bitrate descriptor,System clock  
> descriptor,Smoothing buffer descriptor)
> In therory you can register and extend all these type values for new  
> TOLV elements. However, RTP receivers need to update their software  
> to support if only there is a new TOLV element. It is unconvenient  
> and not flexible for RTP receivers. In fact, a RTP session doesn't  
> need to concern this.
The various standards bodies all define their own PSI elements.  
However, the only ones that are absolutely required for RAMS are  
defined in MPEG2-TS (13818-1). These are the PAT, PMT, CAT, ECM, EMM.  
The remainder of PSI elements do not provide any benefit in the  
context of RAMS. They are useful to the decoder, yes, but do not aid  
in acquiring and presenting the video any quicker. If an  
implementation would like to include any of these optional TLVs they  
are able to add new TOLVs to the registry or make use of the private  
extension mechanism.

> For my method, MPEG2-TS PSIs is transparent for RTP sessions which  
> forward it to the demux/decoder. It don't need to update any  
> software if a new PSI happens only if demux/decoder can support it.  
> It is very flexible to RTP receivers.
>
> the IPMP is three bytes.
I'm not sure what your question is here? A TOLV element can  
accommodate a value field of any length.

> Peilin

Thanks,
Eric

> This email and its attachments contain confidential information from  
> HUAWEI, which is intended only for the person or entity whose  
> address is listed above. Any use of the information contained here  
> in any way (including, but not limited to, total or partial  
> disclosure, reproduction, or dissemination) by persons other than  
> the intended recipient(s) is prohibited. If you receive this email  
> in error, please notify the sender by phone or email
> 主题: RE: Comments to draft-begen-avt-rtp-mpeg2ts-preamble//RE:  
> [AVT]New Version Notification for draft-xia-avt-mpeg2ts-preamble-01
> <[email-masked]>, Roni Even <[email-masked]>, [email-masked]
>
>> Hi Peilin,
>>
>> ******************************************************************************************> 
>> ******************************************************************************************>

---

From: Frank Xia <[email-masked]>
Date: Thu, 17 Dec 2009 09:48:41 -0600

Hi Eric

Please check my quick response.

BR
Frank
----- Original Message ----- 
From: "Eric Friedrich" <[email-masked]>
To: "Peilin YANG" <[email-masked]>
Cc: "Stephan Wenger" <[email-masked]>; "Colin Perkins" <[email-masked]>; 
"Roni Even" <[email-masked]>; <[email-masked]>
Sent: Thursday, December 17, 2009 9:43 AM
Subject: Re: [AVT] Comments to draft-begen-avt-rtp-mpeg2ts-preamble//RE: 
NewVersion Notification for draft-xia-avt-mpeg2ts-preamble-01

>> I got some IPTV streams from different Telecommunication Companies  which 
>> have different PSIs. I illustrated some MPEGs-TS with some PSIs
>> elements(Maximum bitrate descriptor,System clock  descriptor,Smoothing 
>> buffer descriptor)
>> TOLV elements. However, RTP receivers need to update their software  to 
>> support if only there is a new TOLV element. It is unconvenient  and not 
>> flexible for RTP receivers. In fact, a RTP session doesn't  need to 
>> concern this.
> The various standards bodies all define their own PSI elements.  However, 
> the only ones that are absolutely required for RAMS are  defined in 
> MPEG2-TS (13818-1). These are the PAT, PMT, CAT, ECM, EMM.  The remainder 
> of PSI elements do not provide any benefit in the  context of RAMS. They 
> are useful to the decoder, yes, but do not aid  in acquiring and 
> presenting the video any quicker. If an  implementation would like to 
> include any of these optional TLVs they  are able to add new TOLVs to the 
> registry or make use of the private  extension mechanism.

Frank=>"Add new TOLV" means updating both RS and RR.
 Remember the number of RR could be enormous.

>> forward it to the demux/decoder. It don't need to update any  software if 
>> a new PSI happens only if demux/decoder can support it.  It is very 
>> flexible to RTP receivers.
>>
> I'm not sure what your question is here? A TOLV element can  accommodate a 
> value field of any length.
>
>>
>> Peilin
>>
>
> Thanks,
> Eric
>
>
>> HUAWEI, which is intended only for the person or entity whose  address is 
>> listed above. Any use of the information contained here  in any way 
>> (including, but not limited to, total or partial  disclosure, 
>> reproduction, or dissemination) by persons other than  the intended 
>> recipient(s) is prohibited. If you receive this email  in error, please 
>> notify the sender by phone or email
>> 主题: RE: Comments to draft-begen-avt-rtp-mpeg2ts-preamble//RE:  [AVT]New 
>> Version Notification for draft-xia-avt-mpeg2ts-preamble-01
>>> HUAWEI, which is
>>> HUAWEI, which is

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 17 Dec 2009 07:55:17 -0800

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, December 17, 2009 10:36 AM
> To: Ali C. Begen (abegen); 'Peilin YANG'
> Cc: 'Stephan Wenger'; 'Colin Perkins'; [email-masked]
> Subject: RE: [AVT] Comments to draft-begen-avt-rtp-mpeg2ts-preamble//RE: NewVersion

Right.

> the all the PSI information explaining why you need only a specific subset.

Section 4?

We covered the elements one would need for RAMS. If there are ones that we haven't but should be covered as well, we will be glad to add them now or later.

> applications wants to convey in the preamble without requiring any change on

If an implementation is too worried that it may need other elements in the future, it can define all of them at the beginning with public or private extensions. So, I don’t see a problem here.

-acbegen
 
> > which have different
> > elements(Maximum
> > TOLV elements.
> > forward it to the
> > [AVT]New Version

---

From: Roni Even <[email-masked]>
Date: Thu, 17 Dec 2009 18:38:35 +0200

Ali,
It is easier to add support for new functionality on the server side if it
does not require any change on the client side. 
In this case even if you add new TOLV elements than it is not sure that they
will be supported by the clients and the worst part is that the server does
not know if the client supports any new elements.
Roni Even as Individual

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Thursday, December 17, 2009 5:55 PM
> To: Roni Even; Peilin YANG
> Cc: Stephan Wenger; Colin Perkins; [email-masked]
> Subject: RE: [AVT] Comments to draft-begen-avt-rtp-mpeg2ts-
> preamble//RE: NewVersion Notification for draft-xia-avt-mpeg2ts-
> preamble-01
> 
> 
> 
> We covered the elements one would need for RAMS. If there are ones that
> we haven't but should be covered as well, we will be glad to add them
> now or later.
> 
> If an implementation is too worried that it may need other elements in
> the future, it can define all of them at the beginning with public or
> private extensions. So, I don’t see a problem here.
> 
> -acbegen
> 
> > Regards
> > Roni Even as Individual
> >
> > > > Subject: RE: Comments to draft-begen-avt-rtp-mpeg2ts-
> preamble//RE:
> > > [AVT]New Version
> > > > 2. The second has PAT, PMT, ECM(ECM included in CAT), PCR(PCR
> with an
> > > independent PID)
> > > > However, RTP receivers need to update their software to support
> if
> > > only there is a new
> > > > TOLV element. It is unconvenient and not flexible for RTP
> receivers.
> > > In fact, a RTP
> > > Ha? I don’t think IPMP is related to RAMS in anyway. I don't think
> our
> > > draft has it either.
> > >
> > > -acbegen
> > >
> > > > Peilin
> > > >
> > > >
> > >
> above.
> > > Any use of the
> > > > information contained here in any way (including, but not limited
> to,
> > > total or partial
> the
> > > intended
> > > > > > Subject: Comments to draft-begen-avt-rtp-mpeg2ts-
> preamble//RE:
> > > > > [AVT]New Version
> > > > > > Except the types of PSI(PAT/PMT/PCR/ECM/EMM/CAT/PTS)
> described
> > > > > in your draft, ISO13818-
> > > > > > Private(unknowable type and numbers)... Are you going to
> define
> > > > > types for them?
> > > > >
> > > > > Is anybody using them in the context of RAMS? If so, we can
> define
> > > > > them.
> > > > > > In addition, ISO13818-1(2007) defines PSI for IPMP again.
> ETSI
> > > > > EN 300 468 also defines
> > > > >  This email and its attachments contain confidential
> information
> > > from HUAWEI, which is
> > > > > > > again to review both proposals and make a decision so that
> we
> > > can
> > > > > > > move this work forward.
> > > > > > >
> > > > > > > -acbegen
> > > > > > >
> > > > > >  This email and its attachments contain confidential
> information
> > > from HUAWEI, which is

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 17 Dec 2009 08:59:15 -0800

> Sent: Thursday, December 17, 2009 11:39 AM

Sure, but my point is that this is pretty unlikely to happen in the preamble. The receiver code may need to be updated a lot more frequently due to other changes/additions in the other parts of the RAMS signaling protocol.

> not know if the client supports any new elements.

Any unknown TOLV element is discarded by the receiver by default. If this happens, the receiver will not benefit from the potential additional optimization that particular TOLV would provide. However, I am not concerned about this as it would not break RAMS or cause performance loss - the current draft covers all the core and necessary (as far as we know) stuff in the preamble.

-acbegen

> > preamble//RE: NewVersion