Subject: [AVT] Discuss Mpeg2TS preamble

From: Roni Even <[email-masked]>
Date: Tue, 10 Nov 2009 07:36:17 +0900

Hi,

We will have an offline meeting to talk about MPEG2TS preamble at 16:00
today. We can meet at the registration desk on 3rd floor.

I will try to get us a room.

Regards

Roni Even

AVT co-chair

---

From: Roni Even <[email-masked]>
Date: Tue, 10 Nov 2009 09:44:41 +0900

Hi,

We have a room for the meeting thanks to David Oran,

It is the IAB room which is the Sirius room on the 7th floor

So we will meet there from 16:00

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: Tuesday, November 10, 2009 7:36 AM
To: [email-masked]
Subject: [AVT] Discuss Mpeg2TS preamble

Hi,

Regards

Roni Even

AVT co-chair

---

From: Colin Perkins <[email-masked]>
Date: Tue, 10 Nov 2009 22:23:20 +0900

Roni, all,

Thanks to the authors and all those who attended, we had a productive  
meeting to discuss the differences, advantages, and disadvantages of  
these two proposals. This is my attempt to summarise the discussion,  
based on notes taken by myself and Stephan Wenger. Roni will circulate  
the attendee list.

The meeting began by reviewing the structure of an MPEG2-TS and the  
data that needs to be conveyed as part of the preamble in order for  
the rapid acquisition work to operate. We then reviewed the details of  
operation for the two drafts (draft-begen-avt-rtp-mpeg2ts- 
preamble-03.txt and draft-xia-avt-mpeg2ts-preamble-00.txt).

The idea expressed in the Begen draft is to extract the data needed  
for the preamble from the media stream, cache it on the server, and  
send it to the receiver on request in the form of one (or occasionally  
a small number of) RTP packets using a new RTP payload format. That  
RTP payload format is organised as a set of TLV-encoded blocks, where  
each block represents a particular piece of preamble data, extracted  
from the MPEG2-TS. The use of TLV-encoded blocks provides extensibility.

The idea expressed in the Xia draft is to extract the MPEG2-TS frames  
needed for the preamble from the media stream, cache them on the  
server, and send them to the receiver on request in the form of MPEG2- 
TS frames encapsulated in an RTP packet representing an RFC 4588  
retransmission of a synthetic RFC 2250 RTP packet encapsulating those  
MPEG2-TS frames (note that only the frames required for the preamble  
are sent, not the complete RTP packets that contain them).

After much discussion, it was understood that both proposals send  
essentially the same data as the preamble. The key difference between  
them is the way in which that data is encapsulated: the Began draft  
extracts the preamble data from the MPEG2-TS and wraps it into a TLV- 
encoded form for transmission; the Xia draft extracts the preamble  
data from the MPEG2-TS and sends it as a sequence of new MPEG2-TS  
frames wrapped in an RTP retransmission packet.

We discussed compatibility of the two approaches with the RTP  
standards. The Began draft is clearly compatible. The Xia draft is not  
compatible as it stands, since the preamble is sent as an RTP  
retransmission packet but contains a synthetic packet that is not a  
retransmission. This issue with the Xia draft can be solved by  
formatting the preamble packets as RFC 2250 packets, rather than the  
current approach that uses an RFC 4588 retransmission of an RFC 2250  
packet.

We discussed overheads, in terms of the number of packets sent, and  
vulnerability to packet loss. The two drafts generally send the same  
information in the same number of RTP packets in the preamble, and so  
have essentially the same overhead and resilience to loss. Acquisition  
delays are also the same, since both send the same information.

The Began draft includes TLV headers which may provide extra  
flexibility, but will slightly increase the packet size compared to  
the Xia draft which sends raw MPEG2-TS frames.

The meeting concluded with an understanding that the two proposals  
have essentially identical overheads and behaviour. The key difference  
between then, assuming the Xia proposal is updated to use RFC 2250  
packets rather than RFC 4588 retransmissions of RFC 2250 packets to  
conform to the RTP specifications, is that the Begen draft includes  
additional TLV-headers to provide additional flexibility and  
extensibility, at the expense of a slightly larger packet.

One issue that was discussed, and remains unclear, is the exact  
behaviour of the Xia proposal when dealing with encrypted streams.  
This will need to be clarified.

Actions:

Authors of the Xia draft to update their draft for clarity of English  
and to reflect the discussion, especially with respect to the exact  
amount of data that has to be sent in the preamble, and to change to  
using the RFC 2250 format
Authors of the Xia draft to clarify its behaviour when using an  
encrypted MPEG2-TS.

Once an update to the Xia draft, and the Begen draft if the authors  
have any changes they wish to make, is available, we expect the  
working group will be able to review both proposals to make a decision  
whether it prefers extensibility and flexibility (the Begen draft) or  
a slightly lower overhead with less flexibility (the Xia draft).

Colin

On 10 Nov 2009, at 09:44, Roni Even wrote:
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Roni Even
> We will have an offline meeting to talk about MPEG2TS preamble at  
> 16:00 today. We can meet at the registration desk on 3rd floor.

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

---

From: David R Oran <[email-masked]>
Date: Wed, 11 Nov 2009 06:36:32 +0900

Thanks for the summary. I have two additional questions about sending  
the preamble as synthesized RFC2250 packets.

1. Isn't there additional processing needed on the RS to synthesize  
the correct MPEG-level timing (continuity counters, etc.) so that the  
preamble is a legal stream of MPEGTS packets? It isn't at all clear to  
me how this would be done and the draft is silent on this matter.

2. My recollection from our testing (I'm not 100% clear on the details  
- this was a while ago) was that some decoders are not happy to get  
certain MPEG packets back-to-back or spaced too closely in time. One  
of the things we do in our implementation using TLVs is to allow the  
decoder API to the RAMS code to run a custom local clock for feeding  
the preamble into the decoder. One phenomenon we've definitely seen is  
that if you cram two ECMs back to back into the decoder some CAS  
schemes will simply drop one of them on the floor and you lose  
critical decryption keying information.

To summarize these two: locally constructing an MPEG2TS and wrapping  
it in RFC2250 may not work with all receivers, even if the MPEG2TS has  
the CC adjustments mentioned above and meets the letter of the MPEG  
specification.

Thanks, DaveO.

On Nov 10, 2009, at 10:23 PM, Colin Perkins wrote:

> Roni, all,
>
> Thanks to the authors and all those who attended, we had a  
> productive meeting to discuss the differences, advantages, and  
> disadvantages of these two proposals. This is my attempt to  
> summarise the discussion, based on notes taken by myself and Stephan  
> Wenger. Roni will circulate the attendee list.
>
> the rapid acquisition work to operate. We then reviewed the details  
> of operation for the two drafts (draft-begen-avt-rtp-mpeg2ts- 
> send it to the receiver on request in the form of one (or  
> occasionally a small number of) RTP packets using a new RTP payload  
> format. That RTP payload format is organised as a set of TLV-encoded  
> blocks, where each block represents a particular piece of preamble  
> data, extracted from the MPEG2-TS. The use of TLV-encoded blocks  
> provides extensibility.
>
> The idea expressed in the Xia draft is to extract the MPEG2-TS  
> frames needed for the preamble from the media stream, cache them on  
> the server, and send them to the receiver on request in the form of  
> MPEG2-TS frames encapsulated in an RTP packet representing an RFC  
> 4588 retransmission of a synthetic RFC 2250 RTP packet encapsulating  
> those MPEG2-TS frames (note that only the frames required for the  
> preamble are sent, not the complete RTP packets that contain them).
>
> essentially the same data as the preamble. The key difference  
> between them is the way in which that data is encapsulated: the  
> Began draft extracts the preamble data from the MPEG2-TS and wraps  
> it into a TLV-encoded form for transmission; the Xia draft extracts  
> the preamble data from the MPEG2-TS and sends it as a sequence of  
> new MPEG2-TS frames wrapped in an RTP retransmission packet.
>
> standards. The Began draft is clearly compatible. The Xia draft is  
> not compatible as it stands, since the preamble is sent as an RTP  
> information in the same number of RTP packets in the preamble, and  
> so have essentially the same overhead and resilience to loss.  
> Acquisition delays are also the same, since both send the same  
> information.
>
> have essentially identical overheads and behaviour. The key  
> difference between then, assuming the Xia proposal is updated to use  
> RFC 2250 packets rather than RFC 4588 retransmissions of RFC 2250  
> packets to conform to the RTP specifications, is that the Begen  
> draft includes additional TLV-headers to provide additional  
> flexibility and extensibility, at the expense of a slightly larger  
> packet.
>
> 	• Authors of the Xia draft to update their draft for clarity of  
> English and to reflect the discussion, especially with respect to  
> the exact amount of data that has to be sent in the preamble, and to  
> change to using the RFC 2250 format
> 	• Authors of the Xia draft to clarify its behaviour when using an  
> encrypted MPEG2-TS.
>
> working group will be able to review both proposals to make a  
> decision whether it prefers extensibility and flexibility (the Begen  
> draft) or a slightly lower overhead with less flexibility (the Xia  
> draft).
>
> Colin
>
>
>
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Frank Xia <[email-masked]>
Date: Tue, 10 Nov 2009 17:22:17 -0600

Hi David

Let's say there are two reference points:
one is  RS output in our solution, and the
other is  the output of  post-processing module
of RR in your solution.

If we observe these two points from TS level,
they are complete identical.

Addtionally, please check my other response.

BR
Frank

----- Original Message ----- 
From: "David R Oran" <[email-masked]>
To: "Colin Perkins" <[email-masked]>
Cc: "IETF AVT WG" <[email-masked]>
Sent: Tuesday, November 10, 2009 3:36 PM
Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room

1. Isn't there additional processing needed on the RS to synthesize
the correct MPEG-level timing (continuity counters, etc.) so that the
preamble is a legal stream of MPEGTS packets? It isn't at all clear to
me how this would be done and the draft is silent on this matter.
Frank=> How do you restore MPEG TS from TLV and make these
new created TS legal with respect to CC?

Frank=> how does your solution avoid this implementation specific issue?
Your argument seems that your solution is flexibility enough.
If we break into the details,  flexibility probably is not a panacea.
For example, given a special decoder of  STB tends drop one of two 
consecutive
ECMs.  A local clock  can be used to space these two ECMs after processing 
of
TLV according to  your solution.  The same local clock applies
after the STB receiving of the two ECM TS according to our solution.

Frank=>To summarize:  the only difference between these two solutions
is preamble transport formats  between RS and RR.

Thanks, DaveO.

On Nov 10, 2009, at 10:23 PM, Colin Perkins wrote:

> The meeting began by reviewing the structure of an MPEG2-TS and the  data 
> that needs to be conveyed as part of the preamble in order for  the rapid 
> acquisition work to operate. We then reviewed the details  of operation 
> for the two drafts (draft-begen-avt-rtp-mpeg2ts- preamble-03.txt and 
> draft-xia-avt-mpeg2ts-preamble-00.txt).
>
> The idea expressed in the Begen draft is to extract the data needed  for 
> the preamble from the media stream, cache it on the server, and  send it 
> to the receiver on request in the form of one (or  occasionally a small 
> number of) RTP packets using a new RTP payload  format. That RTP payload 
> format is organised as a set of TLV-encoded  blocks, where each block 
> represents a particular piece of preamble  data, extracted from the 
> MPEG2-TS. The use of TLV-encoded blocks  provides extensibility.
>
> needed for the preamble from the media stream, cache them on  the server, 
> and send them to the receiver on request in the form of  MPEG2-TS frames 
> encapsulated in an RTP packet representing an RFC  4588 retransmission of 
> a synthetic RFC 2250 RTP packet encapsulating  those MPEG2-TS frames (note 
> that only the frames required for the  preamble are sent, not the complete 
> RTP packets that contain them).
>
> extracts the preamble data from the MPEG2-TS and wraps  it into a 
> TLV-encoded form for transmission; the Xia draft extracts  the preamble 
> data from the MPEG2-TS and sends it as a sequence of  new MPEG2-TS frames 
> wrapped in an RTP retransmission packet.
>
> We discussed compatibility of the two approaches with the RTP  standards. 
> The Began draft is clearly compatible. The Xia draft is  not compatible as 
> it stands, since the preamble is sent as an RTP  retransmission packet but 
> contains a synthetic packet that is not a  retransmission. This issue with 
> the Xia draft can be solved by  formatting the preamble packets as RFC 
> 2250 packets, rather than the  current approach that uses an RFC 4588 
> retransmission of an RFC 2250  packet.
>
> The Began draft includes TLV headers which may provide extra  flexibility, 
> but will slightly increase the packet size compared to  the Xia draft 
> which sends raw MPEG2-TS frames.
>
> The meeting concluded with an understanding that the two proposals  have 
> essentially identical overheads and behaviour. The key  difference between 
> then, assuming the Xia proposal is updated to use  RFC 2250 packets rather 
> than RFC 4588 retransmissions of RFC 2250  packets to conform to the RTP 
> specifications, is that the Begen  draft includes additional TLV-headers 
> to provide additional  flexibility and extensibility, at the expense of a 
> slightly larger  packet.
>
> One issue that was discussed, and remains unclear, is the exact  behaviour 
> of the Xia proposal when dealing with encrypted streams.  This will need 
> to be clarified.
>
> Actions:
>
> • Authors of the Xia draft to update their draft for clarity of  English 
> Once an update to the Xia draft, and the Begen draft if the authors  have 
> any changes they wish to make, is available, we expect the  working group 
> will be able to review both proposals to make a  decision whether it 
> prefers extensibility and flexibility (the Begen  draft) or a slightly 
> lower overhead with less flexibility (the Xia  draft).
>
> Colin
>
>
>
>
>
>
>
>
>> From: [email-masked] [mailto:[email-masked]] On Behalf  Of 
>> Roni Even

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 11 Nov 2009 08:30:35 +0900

Hi David,
My suggestion would be to wait for an updated draft, rather than discussing
point 1 on the list.  List discussions of these drafts have clearly led to
confusion before.  Give those guys time to breathe.
With respect to your second point, my personal feeling is that IETF
standardization should not be overly bothered by possibly non-compliant
implementations of MPEG-2 system layers in certain chipset products.
Stephan

On 11/11/09 6:36 AM, "David R Oran" <[email-masked]> wrote:

>> € Authors of the Xia draft to update their draft for clarity of
>> € Authors of the Xia draft to clarify its behaviour when using an
>> encrypted MPEG2-TS.
>>

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 11 Nov 2009 01:05:06 -0500

Hmm, there have been so many interesting discussions in AVT!

Just one quick comment based on Colin's and Stephan's excellent and
informative summary. After the Xia draft has been updated and the behaviour
when using an encrypted MPEG2-TS is clarified (which I don't see an
essential difference between the two herein - but I am a security expert),
then a big difference between the two approaches should be taken into
consideration. The Begen approach needs a new standard, while the Xia
approach can already be done today for any multicast application scenario
based on RTP and MPEG2-TS. What is specified in the Xia draft can be just an
informative RFC documenting something that can already be done today.

BR, YK (from boring Sophia Antipolis)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stephan Wenger
> Sent: Tuesday, November 10, 2009 6:31 PM
> To: David R Oran; Colin Perkins
> Cc: IETF AVT WG
> My suggestion would be to wait for an updated draft, rather 
> than discussing point 1 on the list.  List discussions of 
> these drafts have clearly led to confusion before.  Give 
> those guys time to breathe.
> With respect to your second point, my personal feeling is 
> that IETF standardization should not be overly bothered by 
> possibly non-compliant implementations of MPEG-2 system 
> layers in certain chipset products.
> Stephan
> 
> 
> productive 
> >> based on notes taken by myself and Stephan Wenger. Roni will 
> >> circulate the attendee list.
> >> 
> >> server, and send them to the receiver on request in the form of 
> >> TLV-encoded form for transmission; the Xia draft extracts the 
> >> preamble data from the MPEG2-TS and sends it as a sequence of new 
> >> MPEG2-TS frames wrapped in an RTP retransmission packet.
> >> 
> >> have essentially the same overhead and resilience to loss.
> >> packets to conform to the RTP specifications, is that the 
> Begen draft 
> >> includes additional TLV-headers to provide additional 
> flexibility and 
> >> English and to reflect the discussion, especially with 
> respect to the 
> >> exact amount of data that has to be sent in the preamble, and to 
> >> change to using the RFC 2250 format € Authors of the Xia draft to 
> >> clarify its behaviour when using an encrypted MPEG2-TS.
> >> 
> >>> We have a room for the meeting thanks to David Oran, It 
> is the IAB 
> >>> room which is the Sirius room on the 7th floor So we will 
> meet there 
> >>> from 16:00 Roni Even
> >>>

---

From: Ye-Kui Wang <[email-masked]>
Date: Wed, 11 Nov 2009 01:24:34 -0500

Many thanks, Colin - this really clarifies!

BR, YK 

> From: Colin Perkins [mailto:[email-masked]] 
> Sent: Wednesday, November 11, 2009 1:19 AM
> To: Ye-Kui Wang
> Cc: 'Stephan Wenger'; 'David R Oran'; 'IETF AVT WG'
> On 11 Nov 2009, at 15:05, Ye-Kui Wang wrote:
> > informative summary. After the Xia draft has been updated and the 
> > behaviour when using an encrypted MPEG2-TS is clarified 
> (which I don't 
> > see an essential difference between the two herein - but I am a 
> > security expert),
> 
> The question was not regarding security, but regarding the 
> frequency of "preamble" data in encrypted sessions, and the 
> overhead of the Xia draft in that case.
> 
> Colin
> 
> 
> 
> > approach can already be done today for any multicast application 
> > scenario based on RTP and MPEG2-TS. What is specified in 
> the Xia draft 
> > can be just an informative RFC documenting something that 
> can already 
> > be done today.
> >
> >> Stephan Wenger
> >> My suggestion would be to wait for an updated draft, rather than 
> >> discussing point 1 on the list.  List discussions of these drafts 
> >> have clearly led to confusion before.  Give those guys time to 
> >> breathe.
> that IETF 
> >> standardization should not be overly bothered by possibly 
> >> non-compliant implementations of MPEG-2 system layers in certain 
> >> chipset products.
> >> Stephan
> >>
> >>
> >>>> Audio/Video Transport Working Group [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Wed, 11 Nov 2009 15:18:45 +0900

On 11 Nov 2009, at 15:05, Ye-Kui Wang wrote:
> behaviour when using an encrypted MPEG2-TS is clarified (which I  
> don't see an essential difference between the two herein - but I am  
> a security expert),

The question was not regarding security, but regarding the frequency  
of "preamble" data in encrypted sessions, and the overhead of the Xia  
draft in that case.

Colin

> scenario

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

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 11 Nov 2009 09:58:09 -0500

I have a very small resource budget for IETF work, and am reacting to
on-list comments - that after a few exchanges did not mention a key
point. I have not read the RFC and make no assertions about its
adequacy. That said:

It is important that the IP packetization and later extraction does not
result in a violation of the TS buffer model in use due to the
inevitable jitter that the IP packetization introduces (that is the
packetization process must not change the arrival times of the MPEG2TS
packets <in the MPEG2 TS processor> 'too much') and therefore the RFC
must place a constraint or complaint MPEG2 TS processors can be expected
to fail. 

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 Frank Xia
|Sent: Tuesday, November 10, 2009 6:22 PM
|To: David R Oran; Colin Perkins
|Cc: IETF AVT WG
|Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
|
|Hi David
|
|Let's say there are two reference points:
|one is  RS output in our solution, and the other is  the 
|output of  post-processing module of RR in your solution.
|
|If we observe these two points from TS level, they are 
|complete identical.
|
|Addtionally, please check my other response.
|
|BR
|Frank
|
|----- Original Message -----
|From: "David R Oran" <[email-masked]>
|To: "Colin Perkins" <[email-masked]>
|Cc: "IETF AVT WG" <[email-masked]>
|Sent: Tuesday, November 10, 2009 3:36 PM
|Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
|
|
|Thanks for the summary. I have two additional questions about sending
|the preamble as synthesized RFC2250 packets.
|
|1. Isn't there additional processing needed on the RS to synthesize
|the correct MPEG-level timing (continuity counters, etc.) so that the
|preamble is a legal stream of MPEGTS packets? It isn't at all clear to
|me how this would be done and the draft is silent on this matter.
|Frank=> How do you restore MPEG TS from TLV and make these
|new created TS legal with respect to CC?
|
|2. My recollection from our testing (I'm not 100% clear on the details
|- this was a while ago) was that some decoders are not happy to get
|certain MPEG packets back-to-back or spaced too closely in time. One
|of the things we do in our implementation using TLVs is to allow the
|decoder API to the RAMS code to run a custom local clock for feeding
|the preamble into the decoder. One phenomenon we've definitely seen is
|that if you cram two ECMs back to back into the decoder some CAS
|schemes will simply drop one of them on the floor and you lose
|critical decryption keying information.
|
|Frank=> how does your solution avoid this implementation 
|specific issue?
|Your argument seems that your solution is flexibility enough.
|If we break into the details,  flexibility probably is not a panacea.
|For example, given a special decoder of  STB tends drop one of two 
|consecutive
|ECMs.  A local clock  can be used to space these two ECMs 
|after processing 
|of
|TLV according to  your solution.  The same local clock applies
|after the STB receiving of the two ECM TS according to our solution.
|
|To summarize these two: locally constructing an MPEG2TS and wrapping
|it in RFC2250 may not work with all receivers, even if the MPEG2TS has
|the CC adjustments mentioned above and meets the letter of the MPEG
|specification.
|
|Frank=>To summarize:  the only difference between these two solutions
|is preamble transport formats  between RS and RR.
|
|Thanks, DaveO.
|
|
|On Nov 10, 2009, at 10:23 PM, Colin Perkins wrote:
|
|> Roni, all,
|>
|> Thanks to the authors and all those who attended, we had a  
|productive 
|> meeting to discuss the differences, advantages, and  
|disadvantages of 
|> these two proposals. This is my attempt to  summarise the 
|discussion, 
|> based on notes taken by myself and Stephan  Wenger. Roni 
|will circulate 
|> the attendee list.
|>
|> The meeting began by reviewing the structure of an MPEG2-TS 
|and the  data 
|> that needs to be conveyed as part of the preamble in order 
|for  the rapid 
|> acquisition work to operate. We then reviewed the details  
|of operation 
|> for the two drafts (draft-begen-avt-rtp-mpeg2ts- preamble-03.txt and 
|> draft-xia-avt-mpeg2ts-preamble-00.txt).
|>
|> The idea expressed in the Begen draft is to extract the data 
|needed  for 
|> the preamble from the media stream, cache it on the server, 
|and  send it 
|> to the receiver on request in the form of one (or  
|occasionally a small 
|> number of) RTP packets using a new RTP payload  format. That 
|RTP payload 
|> format is organised as a set of TLV-encoded  blocks, where 
|each block 
|> represents a particular piece of preamble  data, extracted from the 
|> MPEG2-TS. The use of TLV-encoded blocks  provides extensibility.
|>
|> The idea expressed in the Xia draft is to extract the 
|MPEG2-TS  frames 
|> needed for the preamble from the media stream, cache them on 
| the server, 
|> and send them to the receiver on request in the form of  
|MPEG2-TS frames 
|> encapsulated in an RTP packet representing an RFC  4588 
|retransmission of 
|> a synthetic RFC 2250 RTP packet encapsulating  those 
|MPEG2-TS frames (note 
|> that only the frames required for the  preamble are sent, 
|not the complete 
|> RTP packets that contain them).
|>
|> After much discussion, it was understood that both proposals send 
|> essentially the same data as the preamble. The key 
|difference  between 
|> them is the way in which that data is encapsulated: the  Began draft 
|> extracts the preamble data from the MPEG2-TS and wraps  it into a 
|> TLV-encoded form for transmission; the Xia draft extracts  
|the preamble 
|> data from the MPEG2-TS and sends it as a sequence of  new 
|MPEG2-TS frames 
|> wrapped in an RTP retransmission packet.
|>
|> We discussed compatibility of the two approaches with the 
|RTP  standards. 
|> The Began draft is clearly compatible. The Xia draft is  not 
|compatible as 
|> it stands, since the preamble is sent as an RTP  
|retransmission packet but 
|> contains a synthetic packet that is not a  retransmission. 
|This issue with 
|> the Xia draft can be solved by  formatting the preamble 
|packets as RFC 
|> 2250 packets, rather than the  current approach that uses an 
|RFC 4588 
|> retransmission of an RFC 2250  packet.
|>
|> We discussed overheads, in terms of the number of packets sent, and 
|> vulnerability to packet loss. The two drafts generally send the same 
|> information in the same number of RTP packets in the 
|preamble, and  so 
|> have essentially the same overhead and resilience to loss.  
|Acquisition 
|> delays are also the same, since both send the same  information.
|>
|> The Began draft includes TLV headers which may provide extra 
| flexibility, 
|> but will slightly increase the packet size compared to  the 
|Xia draft 
|> which sends raw MPEG2-TS frames.
|>
|> The meeting concluded with an understanding that the two 
|proposals  have 
|> essentially identical overheads and behaviour. The key  
|difference between 
|> then, assuming the Xia proposal is updated to use  RFC 2250 
|packets rather 
|> than RFC 4588 retransmissions of RFC 2250  packets to 
|conform to the RTP 
|> specifications, is that the Begen  draft includes additional 
|TLV-headers 
|> to provide additional  flexibility and extensibility, at the 
|expense of a 
|> slightly larger  packet.
|>
|> One issue that was discussed, and remains unclear, is the 
|exact  behaviour 
|> of the Xia proposal when dealing with encrypted streams.  
|This will need 
|> to be clarified.
|>
|> Actions:
|>
|> * Authors of the Xia draft to update their draft for clarity 
|of  English 
|> and to reflect the discussion, especially with respect to  the exact 
|> amount of data that has to be sent in the preamble, and to  
|change to 
|> using the RFC 2250 format
|> * Authors of the Xia draft to clarify its behaviour when using an 
|> encrypted MPEG2-TS.
|>
|> Once an update to the Xia draft, and the Begen draft if the 
|authors  have 
|> any changes they wish to make, is available, we expect the  
|working group 
|> will be able to review both proposals to make a  decision whether it 
|> prefers extensibility and flexibility (the Begen  draft) or 
|a slightly 
|> lower overhead with less flexibility (the Xia  draft).
|>
|> Colin
|>
|>
|>
|>
|>
|>
|>
|>
|> On 10 Nov 2009, at 09:44, Roni Even wrote:
|>> Hi,
|>> We have a room for the meeting thanks to David Oran,
|>> It is the IAB room which is the Sirius room on the 7th floor
|>> So we will meet there from 16:00
|>> Roni Even
|>>
|>> From: [email-masked] [mailto:[email-masked]] On 
|Behalf  Of 
|>> Roni Even
|>> Sent: Tuesday, November 10, 2009 7:36 AM
|>> To: [email-masked]
|>> Subject: [AVT] Discuss Mpeg2TS preamble
|>>
|>> Hi,
|>> We will have an offline meeting to talk about MPEG2TS 
|preamble at  16:00 
|>> today. We can meet at the registration desk on 3rd floor.
|>> I will try to get us a room.
|>> Regards
|>> Roni Even
|>> AVT co-chair
|>
|>
|> -- 
|> Colin Perkins
|> http://csperkins.org/
|>
|>
|>
|> _______________________________________________
|> Audio/Video Transport Working Group
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/avt
|
|_______________________________________________
|Audio/Video Transport Working Group
[email-masked]
|https://www.ietf.org/mailman/listinfo/avt 
|
|_______________________________________________
|Audio/Video Transport Working Group
[email-masked]
|https://www.ietf.org/mailman/listinfo/avt
|

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 11 Nov 2009 13:38:17 -0800

Indeed. In our scheme, we achieve it in the post processing stage while creating the TS packets out of the TLOV elements and considering the arriving burst packets that carry the original TS packets. The outcome of the post processing strictly obeys the rules of the MPEG2-TS spec and additional particular requirements of that client, if any.

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Allison, Art
> Sent: Wednesday, November 11, 2009 11:58 PM
> To: IETF AVT WG

---

From: Frank Xia <[email-masked]>
Date: Wed, 11 Nov 2009 16:01:36 -0600

Hi Ali

It is reasonable to assert " ...and additional
particular requirements of that client, if any"
when you even don't what "any" is?

BR
Frank

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Allison, Art" <[email-masked]>; "IETF AVT WG" <[email-masked]>
Sent: Wednesday, November 11, 2009 3:38 PM
Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room

> Indeed. In our scheme, we achieve it in the post processing stage while 
> creating the TS packets out of the TLOV elements and considering the 
> arriving burst packets that carry the original TS packets. The outcome of 
> the post processing strictly obeys the rules of the MPEG2-TS spec and 
> additional particular requirements of that client, if any.
>
> -acbegen
>
>> Allison, Art

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 11 Nov 2009 14:04:32 -0800

I know what "any" is, but we were asked not to specify such things in the list or the draft. This was in the breakout session, and you may consult with your colleagues who attended the meeting.

-acbegen

> From: Frank Xia [mailto:[email-masked]]
> Sent: Thursday, November 12, 2009 7:02 AM
> To: Ali C. Begen (abegen); Allison, Art; IETF AVT WG

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 11 Nov 2009 17:10:12 -0500

To avoid defining clients; what has worked in other standards has been
to place constraints on the transmission, including a buffer model that
must be followed; and then any complaint receiver should work.
Art
Art Allison

|-----Original Message-----
|From: Ali C. Begen (abegen) [mailto:[email-masked]] 
|Sent: Wednesday, November 11, 2009 5:05 PM
|To: Frank Xia; Allison, Art; IETF AVT WG
|Subject: RE: [AVT] Discuss Mpeg2TS preamble - meeting room
|
|I know what "any" is, but we were asked not to specify such 
|things in the list or the draft. This was in the breakout 
|session, and you may consult with your colleagues who attended 
|the meeting.
|
|-acbegen
|
|> -----Original Message-----
|> From: Frank Xia [mailto:[email-masked]]
|> Sent: Thursday, November 12, 2009 7:02 AM
|> To: Ali C. Begen (abegen); Allison, Art; IETF AVT WG
|> Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
|> 
|> Hi Ali
|> 
|> It is reasonable to assert " ...and additional particular 
|requirements 
|> of that client, if any"
|> when you even don't what "any" is?
|> 
|> BR
|> Frank
|> 
|> ----- Original Message -----
|> From: "Ali C. Begen (abegen)" <[email-masked]>
|> To: "Allison, Art" <[email-masked]>; "IETF AVT WG" <[email-masked]>
|> Sent: Wednesday, November 11, 2009 3:38 PM
|> Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
|> 
|> 
|> > Indeed. In our scheme, we achieve it in the post processing stage 
|> > while creating the TS packets out of the TLOV elements and 
|> > considering the arriving burst packets that carry the original TS 
|> > packets. The outcome of the post processing strictly obeys 
|the rules 
|> > of the MPEG2-TS spec and additional particular 
|requirements of that client, if any.
|> >
|> > -acbegen
|> >
|> >> -----Original Message-----
|> >> From: [email-masked] [mailto:[email-masked]] 
|On Behalf 
|> >> Of Allison, Art
|> >> Sent: Wednesday, November 11, 2009 11:58 PM
|> >> To: IETF AVT WG
|> >> Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
|> >>
|> >> I have a very small resource budget for IETF work, and am 
|reacting 
|> >> to on-list comments - that after a few exchanges did not 
|mention a 
|> >> key point. I have not read the RFC and make no assertions 
|about its 
|> >> adequacy. That said:
|> >>
|> >> It is important that the IP packetization and later 
|extraction does 
|> >> not result in a violation of the TS buffer model in use 
|due to the 
|> >> inevitable jitter that the IP packetization introduces 
|(that is the 
|> >> packetization process must not change the arrival times of the 
|> >> MPEG2TS packets <in the MPEG2 TS processor> 'too much') and 
|> >> therefore the RFC must place a constraint or complaint MPEG2 TS 
|> >> processors can be expected to fail.
|> >>
|> >> 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 Frank Xia
|> >> |Sent: Tuesday, November 10, 2009 6:22 PM
|> >> |To: David R Oran; Colin Perkins
|> >> |Cc: IETF AVT WG
|> >> |Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
|> >> |
|> >> |Hi David
|> >> |
|> >> |Let's say there are two reference points:
|> >> |one is  RS output in our solution, and the other is  the 
|output of  
|> >> |post-processing module of RR in your solution.
|> >> |
|> >> |If we observe these two points from TS level, they are complete 
|> >> |identical.
|> >> |
|> >> |Addtionally, please check my other response.
|> >> |
|> >> |BR
|> >> |Frank
|> >> |
|> >> |----- Original Message -----
|> >> |From: "David R Oran" <[email-masked]>
|> >> |To: "Colin Perkins" <[email-masked]>
|> >> |Cc: "IETF AVT WG" <[email-masked]>
|> >> |Sent: Tuesday, November 10, 2009 3:36 PM
|> >> |Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
|> >> |
|> >> |
|> >> |Thanks for the summary. I have two additional questions about 
|> >> |sending the preamble as synthesized RFC2250 packets.
|> >> |
|> >> |1. Isn't there additional processing needed on the RS to 
|> >> |synthesize the correct MPEG-level timing (continuity counters, 
|> >> |etc.) so that the preamble is a legal stream of MPEGTS 
|packets? It 
|> >> |isn't at all clear to me how this would be done and the 
|draft is silent on this matter.
|> >> |Frank=> How do you restore MPEG TS from TLV and make these new 
|> >> |created TS legal with respect to CC?
|> >> |
|> >> |2. My recollection from our testing (I'm not 100% clear on the 
|> >> |details
|> >> |- this was a while ago) was that some decoders are not happy to 
|> >> |get certain MPEG packets back-to-back or spaced too closely in 
|> >> |time. One of the things we do in our implementation 
|using TLVs is 
|> >> |to allow the decoder API to the RAMS code to run a custom local 
|> >> |clock for feeding the preamble into the decoder. One phenomenon 
|> >> |we've definitely seen is that if you cram two ECMs back to back 
|> >> |into the decoder some CAS schemes will simply drop one 
|of them on 
|> >> |the floor and you lose critical decryption keying information.
|> >> |
|> >> |Frank=> how does your solution avoid this implementation 
|specific 
|> >> |issue?
|> >> |Your argument seems that your solution is flexibility enough.
|> >> |If we break into the details,  flexibility probably is 
|not a panacea.
|> >> |For example, given a special decoder of  STB tends drop 
|one of two 
|> >> |consecutive ECMs.  A local clock  can be used to space these two 
|> >> |ECMs after processing of TLV according to  your solution.  The 
|> >> |same local clock applies after the STB receiving of the 
|two ECM TS 
|> >> |according to our solution.
|> >> |
|> >> |To summarize these two: locally constructing an MPEG2TS and 
|> >> |wrapping it in RFC2250 may not work with all receivers, even if 
|> >> |the MPEG2TS has the CC adjustments mentioned above and meets the 
|> >> |letter of the MPEG specification.
|> >> |
|> >> |Frank=>To summarize:  the only difference between these two 
|> >> |solutions is preamble transport formats  between RS and RR.
|> >> |
|> >> |Thanks, DaveO.
|> >> |
|> >> |
|> >> |On Nov 10, 2009, at 10:23 PM, Colin Perkins wrote:
|> >> |
|> >> |> Roni, all,
|> >> |>
|> >> |> Thanks to the authors and all those who attended, we had a
|> >> |productive
|> >> |> meeting to discuss the differences, advantages, and
|> >> |disadvantages of
|> >> |> these two proposals. This is my attempt to  summarise the
|> >> |discussion,
|> >> |> based on notes taken by myself and Stephan  Wenger. Roni
|> >> |will circulate
|> >> |> the attendee list.
|> >> |>
|> >> |> The meeting began by reviewing the structure of an MPEG2-TS
|> >> |and the  data
|> >> |> that needs to be conveyed as part of the preamble in order
|> >> |for  the rapid
|> >> |> acquisition work to operate. We then reviewed the details
|> >> |of operation
|> >> |> for the two drafts (draft-begen-avt-rtp-mpeg2ts- 
|preamble-03.txt 
|> >> |> and draft-xia-avt-mpeg2ts-preamble-00.txt).
|> >> |>
|> >> |> The idea expressed in the Begen draft is to extract the data
|> >> |needed  for
|> >> |> the preamble from the media stream, cache it on the server,
|> >> |and  send it
|> >> |> to the receiver on request in the form of one (or
|> >> |occasionally a small
|> >> |> number of) RTP packets using a new RTP payload  format. That
|> >> |RTP payload
|> >> |> format is organised as a set of TLV-encoded  blocks, where
|> >> |each block
|> >> |> represents a particular piece of preamble  data, 
|extracted from 
|> >> |> the MPEG2-TS. The use of TLV-encoded blocks  provides 
|extensibility.
|> >> |>
|> >> |> The idea expressed in the Xia draft is to extract the
|> >> |MPEG2-TS  frames
|> >> |> needed for the preamble from the media stream, cache them on
|> >> | the server,
|> >> |> and send them to the receiver on request in the form of
|> >> |MPEG2-TS frames
|> >> |> encapsulated in an RTP packet representing an RFC  4588
|> >> |retransmission of
|> >> |> a synthetic RFC 2250 RTP packet encapsulating  those
|> >> |MPEG2-TS frames (note
|> >> |> that only the frames required for the  preamble are sent,
|> >> |not the complete
|> >> |> RTP packets that contain them).
|> >> |>
|> >> |> After much discussion, it was understood that both proposals 
|> >> |> send essentially the same data as the preamble. The key
|> >> |difference  between
|> >> |> them is the way in which that data is encapsulated: the  Began 
|> >> |> draft extracts the preamble data from the MPEG2-TS and 
|wraps  it 
|> >> |> into a TLV-encoded form for transmission; the Xia 
|draft extracts
|> >> |the preamble
|> >> |> data from the MPEG2-TS and sends it as a sequence of  new
|> >> |MPEG2-TS frames
|> >> |> wrapped in an RTP retransmission packet.
|> >> |>
|> >> |> We discussed compatibility of the two approaches with the
|> >> |RTP  standards.
|> >> |> The Began draft is clearly compatible. The Xia draft is  not
|> >> |compatible as
|> >> |> it stands, since the preamble is sent as an RTP
|> >> |retransmission packet but
|> >> |> contains a synthetic packet that is not a  retransmission.
|> >> |This issue with
|> >> |> the Xia draft can be solved by  formatting the preamble
|> >> |packets as RFC
|> >> |> 2250 packets, rather than the  current approach that uses an
|> >> |RFC 4588
|> >> |> retransmission of an RFC 2250  packet.
|> >> |>
|> >> |> We discussed overheads, in terms of the number of 
|packets sent, 
|> >> |> and vulnerability to packet loss. The two drafts 
|generally send 
|> >> |> the same information in the same number of RTP packets in the
|> >> |preamble, and  so
|> >> |> have essentially the same overhead and resilience to loss.
|> >> |Acquisition
|> >> |> delays are also the same, since both send the same  
|information.
|> >> |>
|> >> |> The Began draft includes TLV headers which may provide extra
|> >> | flexibility,
|> >> |> but will slightly increase the packet size compared to  the
|> >> |Xia draft
|> >> |> which sends raw MPEG2-TS frames.
|> >> |>
|> >> |> The meeting concluded with an understanding that the two
|> >> |proposals  have
|> >> |> essentially identical overheads and behaviour. The key
|> >> |difference between
|> >> |> then, assuming the Xia proposal is updated to use  RFC 2250
|> >> |packets rather
|> >> |> than RFC 4588 retransmissions of RFC 2250  packets to
|> >> |conform to the RTP
|> >> |> specifications, is that the Begen  draft includes additional
|> >> |TLV-headers
|> >> |> to provide additional  flexibility and extensibility, at the
|> >> |expense of a
|> >> |> slightly larger  packet.
|> >> |>
|> >> |> One issue that was discussed, and remains unclear, is the
|> >> |exact  behaviour
|> >> |> of the Xia proposal when dealing with encrypted streams.
|> >> |This will need
|> >> |> to be clarified.
|> >> |>
|> >> |> Actions:
|> >> |>
|> >> |> * Authors of the Xia draft to update their draft for clarity
|> >> |of  English
|> >> |> and to reflect the discussion, especially with respect to  the 
|> >> |> exact amount of data that has to be sent in the 
|preamble, and to
|> >> |change to
|> >> |> using the RFC 2250 format
|> >> |> * Authors of the Xia draft to clarify its behaviour when using 
|> >> |> an encrypted MPEG2-TS.
|> >> |>
|> >> |> Once an update to the Xia draft, and the Begen draft if the
|> >> |authors  have
|> >> |> any changes they wish to make, is available, we expect the
|> >> |working group
|> >> |> will be able to review both proposals to make a  decision 
|> >> |> whether it prefers extensibility and flexibility (the Begen  
|> >> |> draft) or
|> >> |a slightly
|> >> |> lower overhead with less flexibility (the Xia  draft).
|> >> |>
|> >> |> Colin
|> >> |>
|> >> |>
|> >> |>
|> >> |>
|> >> |>
|> >> |>
|> >> |>
|> >> |>
|> >> |> On 10 Nov 2009, at 09:44, Roni Even wrote:
|> >> |>> Hi,
|> >> |>> We have a room for the meeting thanks to David Oran, 
|It is the 
|> >> |>> IAB room which is the Sirius room on the 7th floor So we will 
|> >> |>> meet there from 16:00 Roni Even
|> >> |>>
|> >> |>> From: [email-masked] [mailto:[email-masked]] On
|> >> |Behalf  Of
|> >> |>> Roni Even
|> >> |>> Sent: Tuesday, November 10, 2009 7:36 AM
|> >> |>> To: [email-masked]
|> >> |>> Subject: [AVT] Discuss Mpeg2TS preamble
|> >> |>>
|> >> |>> Hi,
|> >> |>> We will have an offline meeting to talk about MPEG2TS
|> >> |preamble at  16:00
|> >> |>> today. We can meet at the registration desk on 3rd floor.
|> >> |>> I will try to get us a room.
|> >> |>> Regards
|> >> |>> Roni Even
|> >> |>> AVT co-chair
|> >> |>
|> >> |>
|> >> |> --
|> >> |> Colin Perkins
|> >> |> http://csperkins.org/
|> >> |>
|> >> |>
|> >> |>
|> >> |> _______________________________________________
|> >> |> Audio/Video Transport Working Group [email-masked] 
|> >> |> https://www.ietf.org/mailman/listinfo/avt
|> >> |
|> >> |_______________________________________________
|> >> |Audio/Video Transport Working Group [email-masked] 
|> >> |https://www.ietf.org/mailman/listinfo/avt
|> >> |
|> >> |_______________________________________________
|> >> |Audio/Video Transport Working Group [email-masked] 
|> >> |https://www.ietf.org/mailman/listinfo/avt
|> >> |
|> >> _______________________________________________
|> >> Audio/Video Transport Working Group [email-masked] 
|> >> https://www.ietf.org/mailman/listinfo/avt
|> > _______________________________________________
|> > Audio/Video Transport Working Group
|> > [email-masked]
|> > https://www.ietf.org/mailman/listinfo/avt
|
|

---

From: Frank Xia <[email-masked]>
Date: Wed, 11 Nov 2009 16:23:26 -0600

Hi Ali

Sorry my missing the breakout, but probably
you should comment the summary by Colin.

I believe most of people in the WG did not
attend the meeting, meanwhile, the decision
should be made by the community.
I encourage you to list all the presumable
benefits of solution  if these help to roll
the ball.

To be honest, I don't buy the argument that
your solution can optimize the RR, as seems
to deviate the scope which is preamble
acquisition.   Of course, I may be wrong.

BR
Frank

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Frank Xia" <[email-masked]>; "Allison, Art" <[email-masked]>; 
"IETF AVT WG" <[email-masked]>
Sent: Wednesday, November 11, 2009 4:04 PM
Subject: RE: [AVT] Discuss Mpeg2TS preamble - meeting room

I know what "any" is, but we were asked not to specify such things in the 
list or the draft. This was in the breakout session, and you may consult 
with your colleagues who attended the meeting.

-acbegen

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 11 Nov 2009 17:30:54 -0500

Frank-

In what way to you say that the proposed MPEG2TS solution does not
optimize the RR? This is a bold statement.

The TLV parser on the RR understands the syntax of the received data and
can feed the data elements into the transport demux engine as
appropriate.

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Frank Xia
Sent: Wednesday, November 11, 2009 5:23 PM
To: Ali C. Begen (abegen); Allison, Art; IETF AVT WG
Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room

Hi Ali

BR
Frank

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Frank Xia" <[email-masked]>; "Allison, Art"
<[email-masked]>; 

I know what "any" is, but we were asked not to specify such things in
the 
list or the draft. This was in the breakout session, and you may consult

-acbegen

> > arriving burst packets that carry the original TS packets. The
outcome 
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
Of

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 11 Nov 2009 14:31:40 -0800

> you should comment the summary by Colin.

I believe his words are clean and explicit. The current action items belong to your draft. We are waiting for your revision so that we can ask the WG to review both drafts. 
 
> should be made by the community.

Of course, it will be made by the community.

> benefits of solution  if these help to roll

We can, if there will be a need for it when WG starts reviewing the drafts.
 
> acquisition.   Of course, I may be wrong.

I personally believe it is perfectly within the scope. But, it is WG's decision that counts.

Cheers, acbegen

---

From: Frank Xia <[email-masked]>
Date: Wed, 11 Nov 2009 16:44:27 -0600

Hi Bill

Don't get offended :-)

All what I want to say is we should focus.
preamble acquisition or RR optimization?

You  choose do both,  while we prefer
focusing on the former for simplication
and leaving the latter at  RR's discretion.

There is no any information loss after our
processing, and RR  can still do any
optimization.

BR
Frank

----- Original Message ----- 
From: "Bill Ver Steeg (versteb)" <[email-masked]>
To: "Frank Xia" <[email-masked]>; "Ali C. Begen (abegen)" 
<[email-masked]>; "Allison, Art" <[email-masked]>; "IETF AVT WG" 
<[email-masked]>
Sent: Wednesday, November 11, 2009 4:30 PM
Subject: RE: [AVT] Discuss Mpeg2TS preamble - meeting room

Frank-

Bill VerSteeg

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

Hi Ali

BR
Frank

----- Original Message ----- 
From: "Ali C. Begen (abegen)" <[email-masked]>
To: "Frank Xia" <[email-masked]>; "Allison, Art"
<[email-masked]>;

-acbegen

outcome
Of