Subject: [AVT] Status of MPEG2-TS preamble

From: Roni Even <[email-masked]>
Date: Thu, 29 Jul 2010 10:37:44 +0300

I noticed some typos so I apologies for the resend. 

Hi guys,

I would like to express my view of the situation as individual.

1.       After the previous IETF meeting. Huawei provided examples that
demonstrate that  there is no need for post processing. These examples were
based on MPEG2-TS streams used by their customers.

2.       There were no example streams given by Cisco that show the need for
post  processing.

3.       The whole issue of post processing in my view is not relevant since
the discussion is how to send the preamble over the wire.

4.       If we want to have two options in the solution the way to do it is
to have the RS support both and add to the RAMS-R message a parameter that
will indicate the preamble mode supported by the RTP_Rx. If we go this way,
it is important to decide now before we publish RAMS so that we will not
have later backward interoperability problems

Thanks

Roni Even - as individual

---

From: Colin Perkins <[email-masked]>
Date: Thu, 29 Jul 2010 10:20:37 +0200

On 29 Jul 2010, at 09:37, Roni Even wrote:
> 1.       After the previous IETF meeting. Huawei provided examples  
> that demonstrate that  there is no need for post processing. These  
> examples were based on MPEG2-TS streams used by their customers.
> 2.       There were no example streams given by Cisco that show the  
> need for post  processing.
> 3.       The whole issue of post processing in my view is not  
> relevant since the discussion is how to send the preamble over the  
> wire.

Arguing whether particular streams need post-processing or not, in any  
particular implementation, seems less useful than arguing whether the  
protocol messages have clearly defined semantics, and provide the data  
needed to prime the decoder. This group can't legislate for quality of  
implementation.

> 4.       If we want to have two options in the solution the way to  
> do it is to have the RS support both and add to the RAMS-R message a  
> parameter that will indicate the preamble mode supported by the  
> RTP_Rx. If we go this way,  it is important to decide now before we  
> publish RAMS so that we will not have later backward  
> interoperability problems

The preamble is an RTP payload format, so surely should be negotiated  
in the same way as any other payload format, no?

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

---

From: Roni Even <[email-masked]>
Date: Thu, 29 Jul 2010 11:25:58 +0300

Colin,
Thanks,
Inline
Roni

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Thursday, July 29, 2010 11:21 AM
> To: Roni Even
> Cc: 'IETF AVT WG'
> Subject: Re: [AVT] Status of MPEG2-TS preamble
> 

You are right and it should be specified in the SDP announcement, The
announcement should offer both options. Since this application uses
declarative SDP and not offer answer it requires the client to select using
the RAMS-R message and not answer SDP.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 29 Jul 2010 10:39:36 +0200

On 29 Jul 2010, at 10:25, Roni Even wrote:
...
>>> do it is to have the RS support both and add to the RAMS-R message  
>>> a parameter that will indicate the preamble mode supported by the  
>>> RTP_Rx. If we go this way,  it is important to decide now before  
>>> we publish RAMS so that we will not have later backward  
>> The preamble is an RTP payload format, so surely should be  
>> negotiated in the same way as any other payload format, no?
>
> You are right and it should be specified in the SDP announcement,  
> The announcement should offer both options. Since this application  
> uses declarative SDP and not offer answer it requires the client to  
> select using the RAMS-R message and not answer SDP.

Yes, good point, for use cases that use declarative signalling.

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 29 Jul 2010 01:40:11 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Thursday, July 29, 2010 9:38 AM
> To: 'IETF AVT WG'
> Subject: [AVT] Status of MPEG2-TS preamble
> 
> 1.       After the previous IETF meeting. Huawei provided examples that demonstrate that  there is no need for post
> processing. These examples were based on MPEG2-TS streams used by their customers.

Where in production? I believe everybody agrees that it is always possible to find some stream that just works without any post-processing. But, that is not the point.
 
> 2.       There were no example streams given by Cisco that show the need for post  processing.

Hmm, we provided an example with all the TS header stuff as well. We also provided open source code how to encode and decode that stream structure. Our example only lacked video content in it, which is not relevant to the discussion AFAICT.
 
> 3.       The whole issue of post processing in my view is not relevant since the discussion is how to send the preamble over the
> wire.

Are you saying that the scope is only the bits on the wire? Whether that is the case or not, your approach requires a new payload format definition as much as ours. And we think that if we will define one, let it be the one that is easier for post processing when there is a need (which is always in the streams we work with).
 
> 4.       If we want to have two options in the solution the way to do it is to have the RS support both and add to the RAMS-R
> message a parameter that will indicate the preamble mode supported by the RTP_Rx. If we go this way,  it is important to
> decide now before we publish RAMS so that we will not have later backward interoperability problems

RAMS-R extensions are always possible and just need an IANA registration. So need at all to stop RAMS at this stage. 

-acbegen

> 
> 
> 
> Thanks
> 
> Roni Even – as individual

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 29 Jul 2010 01:42:34 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: Thursday, July 29, 2010 10:21 AM
> To: Roni Even
> Cc: 'IETF AVT WG'

I tend to agree. What I am all saying is that we have a clear motivation for it and it needs to be done one way or another if an implementation wants to be interoperable.

-acbegen
 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Roni Even <[email-masked]>
Date: Thu, 29 Jul 2010 12:09:07 +0300

Hi Ali,
My last point was saying that you can have interoperable applications by
having just the RS support both modes
Roni

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Thursday, July 29, 2010 11:43 AM
> To: Colin Perkins; Roni Even
> Cc: IETF AVT WG
> I tend to agree. What I am all saying is that we have a clear
> motivation for it and it needs to be done one way or another if an
> implementation wants to be interoperable.
> 
> -acbegen
> 
> a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Jul 2010 11:12:17 +0200

Speaking as the WG co-chair.

1)	Having talked to authors of both solutions, I think both sides could have done more work for evaluation of each others solution. No significant technical evaluation of either solution has taken place on list.

2)	My interpretation of the working group at the last meeting is that we will not be able to build working group concensus round specifying both solutions. I will check at lunchtime whether any working group members consider they have moved on that point. More to the point, this MUST NOT be an admission of defeat. We will need to justify to the IESG and to the IETF why we believe it is right that there are two documented solutions.

3)	Previous decisions of the working group have been that they do want an RFC in this area. Time has moved on. I will also confirm at lunchtime that we do still want to work on this issue.

4)	If the WG wants a single solution, it is not just the responsibility of both sets of authors to find a common solution. It is the responsibility of the WG (i.e. ALL MEMBERS OF THE WG) to find a solution. Therefore I would appreciate other members of the WG getting to the point where they say that on technical considerations they want solution A or B (or indeed C if they have another proposal). At the moment I am seeing no input on list from outside the author lists, and very little in offline communications (both face-to-face and by email).

5)	I would like people at the ad-hoc (lunchtime today Thursday) to identify what impact the different solutions have on the client and the server. Which solutions require more processing at the client / server? Does that provide appropriate flexibility or is that just cost impact? Hopefully this will help identify the technical flexibility of each solution and help other people may a decision on which they want to go.

6)	Note that the ad-hoc meeting is officially sanctioned, the note well will apply, and we will include the notes of the meeting in the proceedings of the IETF. However I do not intend to take any hums in the meeting - if there are actually any hums needed these will occur on Friday's session.

regards

Keith

________________________________

	From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
	Sent: Thursday, July 29, 2010 8:38 AM
	To: 'IETF AVT WG'
	Subject: [AVT] Status of MPEG2-TS preamble

	Hi guys,

	1.       After the previous IETF meeting. Huawei provided examples that demonstrate that  there is no need for post processing. These examples were based on MPEG2-TS streams used by their customers.

	3.       The whole issue of post processing in my view is not relevant since the discussion is how to send the preamble over the wire.

	4.       If we want to have two options in the solution the way to do it is to have the RS support both and add to the RAMS-R message a parameter that will indicate the preamble mode supported by the RTP_Rx. If we go this way,  it is important to decide now before we publish RAMS so that we will not have later backward interoperability problems

	Thanks

---

From: "Allison, Art" <[email-masked]>
Date: Thu, 29 Jul 2010 08:43:33 -0400

I have seen nothing that alters my firm conviction that one solution,  http://tools.ietf.org/id/draft-begen-avt-rtp-mpeg2ts-preamble-0n.txt should be selected.
Previous posts provide my reasons.

Art

Art Allison
Senior Director Advanced Engineering, Science and Technology
National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418 
Fax  202 775 4981
www.nab.org
Advocacy  Education  Innovation

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: Thursday, July 29, 2010 5:12 AM
To: 'IETF AVT WG'
Subject: Re: [AVT] Status of MPEG2-TS preamble

regards

Keith

	Hi guys,

	Thanks

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 29 Jul 2010 10:48:06 -0500

In today's break out session, we mentioned a few documents that were
relevant in evaluating the strengths and weaknesses of the two RAMS
MPEG2TS preamble proposals. We were asked to provide references to those
documents.

The most relevant specification is the MPEG2TS specification itself,
which I am assuming that the folks involved in the technical evaluation
have read. The next set of important documents includes ATSC A/65
(PSIP), ETSI DVB EN 300 468 (DVB/SI), ETSI TS 103 397 (DVB simulcrypt),
ETSI ETR 289 (DVB Scrambling and CA), NIST SP800-38A and NIST FIPS PUB
197 (AES based encryption) and to a lesser extent ETSI TS 102 034 (DVB /
IPI). If you need copies of these documents, please email me privately
and I will try to make copies available. 

These documents specify/recommend some timing constraints for the
various tables, including PAT, PMT and ECM. In addition to these timing
constraints, care must be taken in driving the multiple
demux/decrypt/decode chipsets found in the wild. The transport demux
needs time to setup at various places in the process, as do the
decryptor and the decoder. The combination of these various timing
constraints, the various deployed systems that expect to receive
compliant streams, and the desire to accelerate the process using RAMS
presents a difficult set of problems. These problems are particularly
onerous in a multi-CAS/simulcrypt system with a heterogeneous receiver
environment. In other words, many of these issues become apparent when
you try to deploy in a real-world environment with multiple CAS vendors
and multiple decoder chipsets.

We are fortunate to have received unambiguous feedback from the primary
authors of some of these documents (including Art and Sandy).  If there
are additional technical issues that need to be evaluated, I suggest
that we reach out to additional subject matter experts in the MPEG
community. 

Let's find the best solution and move forward.

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
DRAGE, Keith (Keith)
Sent: Thursday, July 29, 2010 11:12 AM
To: 'IETF AVT WG'
Subject: Re: [AVT] Status of MPEG2-TS preamble

1)	Having talked to authors of both solutions, I think both sides
could have done more work for evaluation of each others solution. No
significant technical evaluation of either solution has taken place on
list.

2)	My interpretation of the working group at the last meeting is
that we will not be able to build working group concensus round
specifying both solutions. I will check at lunchtime whether any working
group members consider they have moved on that point. More to the point,
this MUST NOT be an admission of defeat. We will need to justify to the
IESG and to the IETF why we believe it is right that there are two
documented solutions.

3)	Previous decisions of the working group have been that they do
want an RFC in this area. Time has moved on. I will also confirm at
lunchtime that we do still want to work on this issue.

4)	If the WG wants a single solution, it is not just the
responsibility of both sets of authors to find a common solution. It is
the responsibility of the WG (i.e. ALL MEMBERS OF THE WG) to find a
solution. Therefore I would appreciate other members of the WG getting
to the point where they say that on technical considerations they want
solution A or B (or indeed C if they have another proposal). At the
moment I am seeing no input on list from outside the author lists, and
very little in offline communications (both face-to-face and by email).

5)	I would like people at the ad-hoc (lunchtime today Thursday) to
identify what impact the different solutions have on the client and the
server. Which solutions require more processing at the client / server?
Does that provide appropriate flexibility or is that just cost impact?
Hopefully this will help identify the technical flexibility of each
solution and help other people may a decision on which they want to go.

6)	Note that the ad-hoc meeting is officially sanctioned, the note
well will apply, and we will include the notes of the meeting in the
proceedings of the IETF. However I do not intend to take any hums in the
meeting - if there are actually any hums needed these will occur on
Friday's session.

regards

Keith

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Roni Even
	Sent: Thursday, July 29, 2010 8:38 AM
	To: 'IETF AVT WG'
	Subject: [AVT] Status of MPEG2-TS preamble

	Hi guys,

	1.       After the previous IETF meeting. Huawei provided
examples that demonstrate that  there is no need for post processing.
These examples were based on MPEG2-TS streams used by their customers.

	2.       There were no example streams given by Cisco that show
the need for post  processing.

	3.       The whole issue of post processing in my view is not
relevant since the discussion is how to send the preamble over the wire.

	4.       If we want to have two options in the solution the way
to do it is to have the RS support both and add to the RAMS-R message a
parameter that will indicate the preamble mode supported by the RTP_Rx.
If we go this way,  it is important to decide now before we publish RAMS
so that we will not have later backward interoperability problems

	Thanks

---

From: Roni Even <[email-masked]>
Date: Thu, 29 Jul 2010 19:23:20 +0300

Bill,
Thanks, it looks to me that some of the documents are not about MPEG2-TS
like FIPS 197 and nist sp800-38a since I am familiar with those. So why did
you mention them
Roni

> Bill Ver Steeg (versteb)
> Sent: Thursday, July 29, 2010 6:48 PM
> To: DRAGE, Keith (Keith); IETF AVT WG

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 29 Jul 2010 11:34:32 -0500

Roni-

The first few documents that describe the format of the System
Information are where one would start. These documents describe 95% of
the flow.

When you start getting into the encrypted use cases (and then into the
simulcrypt use cases), the actual encryption algorithm comes into play
when you try to accelerate the flow. Turning the ECM into a control word
and then using the control word to decrypt the video has a significant
impact on the overall timing of the system. These two documents describe
the commonly-used IPTV AES-128 variants. 

Bvs

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Thursday, July 29, 2010 6:23 PM
To: Bill Ver Steeg (versteb); 'DRAGE, Keith (Keith)'; 'IETF AVT WG'
Subject: RE: [AVT] Status of MPEG2-TS preamble

Bill,
Thanks, it looks to me that some of the documents are not about MPEG2-TS
like FIPS 197 and nist sp800-38a since I am familiar with those. So why
did
you mention them
Roni

> meeting - if there are actually any hums needed these will occur on
RTP_Rx.

---

From: "Allison, Art" <[email-masked]>
Date: Thu, 29 Jul 2010 13:16:11 -0400

I would have listed ATSC A/53 Part 3:2009 [http://www.atsc.org/cms/standards/a53/a_53-Part-3-2009.pdf], rather than A/65 as A/65 should not impact the choice.  

EIA679-B Part B: National Renewable Security Standard (March 2000) and ANSI/SCTE 41 2004 POD Copy Protection System may be instructive.
Art 

Art Allison

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill Ver Steeg (versteb)
Sent: Thursday, July 29, 2010 11:48 AM
To: DRAGE, Keith (Keith); IETF AVT WG
Subject: Re: [AVT] Status of MPEG2-TS preamble

Bill VerSteeg

-----Original Message-----

regards

Keith

	Hi guys,

	Thanks

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 29 Jul 2010 19:19:46 +0200

Yup. Brain burp on my part.

Bvs

On Jul 29, 2010, at 7:16 PM, "Allison, Art" <[email-masked]> wrote:

> I would have listed ATSC A/53 Part 3:2009 [http://www.atsc.org/cms/standards/a53/a_53-Part-3-2009.pdf 
> ], rather than A/65 as A/65 should not impact the choice.
>
> EIA679-B Part B: National Renewable Security Standard (March 2000)  
> and ANSI/SCTE 41 2004 POD Copy Protection System may be instructive.
> Art
>
> Art Allison

---

From: Peilin YANG <[email-masked]>
Date: Fri, 30 Jul 2010 01:50:10 +0800

Dear Bill,

If you have a look at previous mailings, you will find that Xia's solution has received operator' support.

I think a better solution can withstand market's choice. If xia's solution is not good, the market will throw it way involuntarily. 

If you don't worry about ali's solution, why you don't want to allow the market to decide. Unless......

Best regards,

Peilin

----- 原邮件 -----
发件人: "Bill Ver Steeg (versteb)" <[email-masked]>
日期: 星期四, 七月 29日, 2010 下午11:48
主题: Re: [AVT] Status of MPEG2-TS preamble
收件人: "DRAGE, Keith (Keith)" <[email-masked]>, IETF AVT WG <[email-masked]>

Bill VerSteeg

---

From: "Roni Even" <[email-masked]>
Date: Thu, 29 Jul 2010 20:56:35 +0300

Art thanks, 
I started looking at A/65 and did not see any relevance. A/53 has timing
information but I am not sure I see anything specific that discuss the
relative timing between PAT, PMT, CAT, ECM and EMM which was mentioned as an
issue.

I also looked at section 7 of
http://tools.ietf.org/html/draft-begen-avt-rtp-mpeg2ts-preamble-05 and saw a
simple construction of the TS stream from the TOLV to be fed to the
demux/decoder.

So I am still not sure what the discussion is about unless section 7 is not
correct

Roni 

> Allison, Art
> Sent: Thursday, July 29, 2010 8:16 PM
> To: IETF AVT WG
> I would have listed ATSC A/53 Part 3:2009
> [http://www.atsc.org/cms/standards/a53/a_53-Part-3-2009.pdf], rather
> than A/65 as A/65 should not impact the choice.
> 
> EIA679-B Part B: National Renewable Security Standard (March 2000) and
> ANSI/SCTE 41 2004 POD Copy Protection System may be instructive.
> Art
> 
> Art Allison

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 29 Jul 2010 19:58:26 +0200

(As WG chair)

Please concentrate on giving the working group members the technical material they need to evaluate the two solutions.

I am not aware that number of customers (apart from in pursuance of demonstrating interoperable implementations) forms any part of the IETF review process. If you believe otherwise then please point me to the relevant guidance, and I will be happy to correct my position.

If you believe two solutions together is the right technical solution, then please identify the technical advantages of doing that. If you believe one solution is technically better than the other, then please provide that material.

regards

Keith 

P.S. The first part of Bill's response below relates to a request in the ad-hoc to provide references to the relevant parts of the MPEG specifications to allow evaluation of the MPEG parts of the solutions.

> From: Peilin YANG [mailto:[email-masked]] 
> Sent: Thursday, July 29, 2010 6:50 PM
> To: Bill Ver Steeg (versteb)
> Cc: DRAGE, Keith (Keith); IETF AVT WG
> If you have a look at previous mailings, you will find that 
> Xia's solution has received operator' support.
> 
> I think a better solution can withstand market's choice. If 
> xia's solution is not good, the market will throw it way 
> involuntarily. 
> 
> If you don't worry about ali's solution, why you don't want 
> to allow the market to decide. Unless......
> 
> Best regards,
> 
> Peilin
> 
> 
> ----- 原邮件 -----
> In today's break out session, we mentioned a few documents 
> that were relevant in evaluating the strengths and weaknesses 
> of the two RAMS MPEG2TS preamble proposals. We were asked to 
> provide references to those documents.
> 
> The most relevant specification is the MPEG2TS specification 
> itself, which I am assuming that the folks involved in the 
> technical evaluation have read. The next set of important 
> documents includes ATSC A/65 (PSIP), ETSI DVB EN 300 468 
> (DVB/SI), ETSI TS 103 397 (DVB simulcrypt), ETSI ETR 289 (DVB 
> Scrambling and CA), NIST SP800-38A and NIST FIPS PUB
> 197 (AES based encryption) and to a lesser extent ETSI TS 102 
> 034 (DVB / IPI). If you need copies of these documents, 
> please email me privately and I will try to make copies available. 
> 
> These documents specify/recommend some timing constraints for 
> the various tables, including PAT, PMT and ECM. In addition 
> to these timing constraints, care must be taken in driving 
> the multiple demux/decrypt/decode chipsets found in the wild. 
> The transport demux needs time to setup at various places in 
> the process, as do the decryptor and the decoder. The 
> combination of these various timing constraints, the various 
> deployed systems that expect to receive compliant streams, 
> and the desire to accelerate the process using RAMS presents 
> a difficult set of problems. These problems are particularly 
> onerous in a multi-CAS/simulcrypt system with a heterogeneous 
> receiver environment. In other words, many of these issues 
> become apparent when you try to deploy in a real-world 
> environment with multiple CAS vendors and multiple decoder chipsets.
> 
> We are fortunate to have received unambiguous feedback from 
> the primary authors of some of these documents (including Art 
> and Sandy).  If there are additional technical issues that 
> need to be evaluated, I suggest that we reach out to 
> additional subject matter experts in the MPEG community. 
>

---

From: "Allison, Art" <[email-masked]>
Date: Thu, 29 Jul 2010 14:32:23 -0400

A/53 does not address the CA stress case. ATSC constrains the buffer sizes of video (Part 3 Section 6.1.1).  I had forgotten that the audio buffer model (which is quite constraining and bears upon starting up with sound even somewhat in synchronization with video) is actually defined in another standard -- A/52B  (http://www.atsc.org/cms/standards/a_52b.pdf) at section 5.5 and A.3.6 and more generally section 6.1.1  independent of transport standard used for AC-3 streams.  

While ATSC does have a simulcrypt standard (A/70A); for ATSC-based MPEG-2 most US systems that source streams with Conditional Access (read all US cable systems), it is not used. One needs to consider the SCTE and CEA (was EIA) standards for such steam construction. 

To capture the stream construction variations for CA controlled streams created by equipment in the US/Canada for delivery over IP, it would seem that input would be helpful from the IP-based system operators such as those offered by telephone companies such as AT&T (apologies if I missed such contributions). 

Art Allison

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Thursday, July 29, 2010 1:57 PM
To: Allison, Art; 'IETF AVT WG'
Subject: RE: [AVT] Status of MPEG2-TS preamble

Art thanks, 

Roni

---

From: Peilin YANG <[email-masked]>
Date: Fri, 30 Jul 2010 03:01:03 +0800

Dear All, 

IMHO, a good method to evaluate the preamble is to compare two solutions. The following is the step comparion of both solutions based on two drafts.
I write "......" at the step 8 which is a potential possible step, because I don't know how it does according to Begen draft, though I read Begen draft for many times. 
In our current deployments, there is no step 8, but I think it is no problem to implement it if it is necessary.

***********************Begen draft****************| *******************   Xia draft  *******************              
The steps of RS************************************|The steps of RS
Step1: RS detects the preamble information***************|  RS detects the preamble information(The same as Begen draft)
Step2: RS extracts this specific data*********************|  None
Step3: RS puts these in the TOLV elements***************|  None
Step4: RS packages them together in RTP packets*********|  RS brings these TS packets together in RTP packets 
Step5: RS transmits these to the receiver*****************|  RS transmits these to the receiver(The same as Begen draft)
***********************************************|*****************************************************
The steps of RR***********************************|The steps of RR
Step6: RR extracts the preamble data from TOLV elements**|  None
Step7: RR generates again a sequence of MPEG2 TS packets*|  None
step8: (......)**************************************|(......)
Step9: RR feeds theses to the demux/decoder*************|  RR feeds to the demux/decoder(The same as Begen draft)

I don't know if I express it clearly. Welcome any comments.

Best regards,

Peilin

----- 原邮件 -----
发件人: "DRAGE, Keith (Keith)" <[email-masked]>
日期: 星期五, 七月 30日, 2010 上午1:58
主题: RE: [AVT] Status of MPEG2-TS preamble
收件人: Peilin YANG <[email-masked]>, "Bill Ver Steeg (versteb)" <[email-masked]>
抄送: IETF AVT WG <[email-masked]>

(As WG chair)

regards

Keith