Subject: Re: [AVT] Discuss Mpeg2TS preamble

From: Franceschini Guido <[email-masked]>
Date: Wed, 20 Jan 2010 09:07:24 +0100

Dear Colin, all,

I have read the drafts on the mpeg2ts preamble, and tried also to follow the various discussion threads, so now I'd like to post some comment.
As you state, the two drafts are very similar except for the mechanism by which the preamble data is formatted and packetized.
IMHO, from the sender' point of view the difference between the two solutions is negligible, but from the Receiver' point of view it is not.

Indeed, the Begen approach requires the implementation (at the Receiver) of a module to interpret the new payload format and transform the data being carried in the TLV elements into something comprehensible to the local M2TS decoder (e.g. Transport Packets, or commands towards a local / private API). Such a translation module is not required in case of the Xia proposal, since the preamble data already enters the terminal formatted in Transport Packets in a RFC2250 Payload Format.
I have understood from the mail threads that the promoters of the Begen draft have defined this new payload format because they assert that at the Receiver there are cases in which a preamble in the form of a stream of Transport Packets cannot be used to simply feed the M2TS decoder, and some trick needs to be implemented. However, if the above statement is true (tricks needed at certain Receivers to cope with decoder peculiar issues), nothing prevents the same ad-hoc logic to be implemented on a preamble made of TS packets instead of a preamble made of TLV elements, and thus I do not see this argument as a distinguishing advantage of the Begen solution. On the other hand, if the M2TS decoder does not require specific tricks, injecting the TS packets directly would be a lot easier.

To sum up, I have failed to understand why (Begen draft) the formatting of the preamble data in a brand new payload format brings advantages with respect to the re-use of an already available format.
Have I missed / misinterpreted anything?

In particular, in relation to your summary:
> 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).

In which sense the Begen draft adds extensibility and flexibility? I would have thought the contrary, since potential future additions in Mpeg2TS will likely require an update of the payload format used in Begen draft, and not on the payload format adopted by the Xia draft.

Thanks in advance
Guido Franceschini

------------------------------------------------------------------
Telecom Italia
Guido FRANCESCHINI
Broadband Solutions and Multimedia Innovation
Via Guglielmo Reiss Romoli, 274 10148 Torino
office   +39 011 2286137
mobile +39 335 7669748
fax      +39 011 2287003

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin Perkins
Sent: martedì 10 novembre 2009 14.23
To: IETF AVT WG
Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room

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]> [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Tuesday, November 10, 2009 7:36 AM
To: [email-masked]<mailto:[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/

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Jan 2010 03:42:35 -0800

Thanks for reading the drafts.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Franceschini Guido
> Sent: Wednesday, January 20, 2010 3:07 AM
> To: Colin Perkins; IETF AVT WG
> Subject: Re: [AVT] Discuss Mpeg2TS preamble
> 
> Dear Colin, all,
> 
> 
> 
> I have read the drafts on the mpeg2ts preamble, and tried also to follow the various
> discussion threads, so now I’d like to post some comment.
> 
> As you state, the two drafts are very similar except for the mechanism by which the
> preamble data is formatted and packetized.
> 
> IMHO, from the sender’ point of view the difference between the two solutions is
> negligible, but from the Receiver’ point of view it is not.
> 
> 
> 
> Indeed, the Begen approach requires the implementation (at the Receiver) of a module to
> interpret the new payload format and transform the data being carried in the TLV elements
> into something comprehensible to the local M2TS decoder (e.g. Transport Packets, or
> commands towards a local / private API). Such a translation module is not required in case
> of the Xia proposal, since the preamble data already enters the terminal formatted in
> Transport Packets in a RFC2250 Payload Format.
> 
> I have understood from the mail threads that the promoters of the Begen draft have defined
> this new payload format because they assert that at the Receiver there are cases in which
> a preamble in the form of a stream of Transport Packets cannot be used to simply feed the
> M2TS decoder, and some trick needs to be implemented. However, if the above statement is

You are missing a large part of our motivation for using TLV format. We use the info in the TLV elements to initialize the decoder and program it so that it can actually start decoding *sooner* compared to simply feeding TS packets to the decoder. This step differs from decoder to decoder, hence, we do post-processing.

> true (tricks needed at certain Receivers to cope with decoder peculiar issues), nothing
> prevents the same ad-hoc logic to be implemented on a preamble made of TS packets instead
> of a preamble made of TLV elements, and thus I do not see this argument as a

You mean one could do the same with the TS packets on the server side? That would be a bad idea. Not only it won't scale due to the variation among decoders (so the server needs to deal with individual requirements), but also it will increase the preamble data size that would make it more vulnerable to packet loss, thus, failures.

> distinguishing advantage of the Begen solution. On the other hand, if the M2TS decoder
> does not require specific tricks, injecting the TS packets directly would be a lot easier.
> 
> 
> 
> To sum up, I have failed to understand why (Begen draft) the formatting of the preamble
> data in a brand new payload format brings advantages with respect to the re-use of an
> already available format.
> 

Without doing an implementation, it may be difficult for one to see why we do the things this way. We are not trying to entertain ourselves here by creating new formats. We are doing it because we believe it offers more advantages and serves our goals better.

> > 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).
> 
> 
> 
> In which sense the Begen draft adds extensibility and flexibility? I would have thought
> the contrary, since potential future additions in Mpeg2TS will likely require an update of
> the payload format used in Begen draft, and not on the payload format adopted by the Xia
> draft.

We offer extensibility and flexibility because we can transmit the preamble info in a very concrete fashion but the post-processing on the client side allows us to tailor that information in an optimized fashion for that particular decoder model/chipset/etc. If the server simply sends TS packets, it needs to go with the preamble TS packets that work for all of the decoders in its receiver pool. It can deal with the specifics of the individual receivers. That would not scale at all.

Regarding the future additions to the MPEG2-TS spec, as much as it is unlikely, if that happens, the decoders need to be updated first before we worry about the preamble format. That is a much bigger problem compared to registering a few new TLVs for the preamble registry.

Cheers, acbegen. 

> 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
> 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
> 	To: [email-masked]
> 	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.
> 
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate.
> La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste
> informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per
> errore siete cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged information
> intended for the addressee(s) only. Dissemination, copying, printing or use by anybody
> else is unauthorised. If you are not the intended recipient, please delete this message
> and any attachments and advise the sender by return e-mail, Thanks.
> 
> rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Jan 2010 12:10:50 +0000

[inline]

On 20 Jan 2010, at 11:42, Ali C. Begen (abegen) wrote:
>> I have read the drafts on the mpeg2ts preamble, and tried also to  
>> follow the various discussion threads, so now I’d like to post some  
>> comment.
>>
>> As you state, the two drafts are very similar except for the  
>> mechanism by which the preamble data is formatted and packetized.
>>
>> IMHO, from the sender’ point of view the difference between the two  
>> solutions is negligible, but from the Receiver’ point of view it is  
>> not.
>>
>>
>>
>> Indeed, the Begen approach requires the implementation (at the  
>> Receiver) of a module to interpret the new payload format and  
>> transform the data being carried in the TLV elements into something  
>> comprehensible to the local M2TS decoder (e.g. Transport Packets,  
>> or commands towards a local / private API). Such a translation  
>> module is not required in case of the Xia proposal, since the  
>> preamble data already enters the terminal formatted in Transport  
>> Packets in a RFC2250 Payload Format.
>>
>> I have understood from the mail threads that the promoters of the  
>> Begen draft have defined this new payload format because they  
>> assert that at the Receiver there are cases in which a preamble in  
>> the form of a stream of Transport Packets cannot be used to simply  
>> feed the M2TS decoder, and some trick needs to be implemented.  
>> However, if the above statement is
>
> You are missing a large part of our motivation for using TLV format.  
> We use the info in the TLV elements to initialize the decoder and  
> program it so that it can actually start decoding *sooner* compared  
> to simply feeding TS packets to the decoder. This step differs from  
> decoder to decoder, hence, we do post-processing.
>
>> true (tricks needed at certain Receivers to cope with decoder  
>> peculiar issues), nothing prevents the same ad-hoc logic to be  
>> implemented on a preamble made of TS packets instead of a preamble  
>> made of TLV elements, and thus I do not see this argument as a
>
> You mean one could do the same with the TS packets on the server  
> side? That would be a bad idea. Not only it won't scale due to the  
> variation among decoders (so the server needs to deal with  
> individual requirements), but also it will increase the preamble  
> data size that would make it more vulnerable to packet loss, thus,  
> failures.

As I understand it, the point Guido is making, and the point made in  
the breakout discussion at the meeting, is that both solutions allow  
you to do exactly the same thing in terms of priming the decoder.  
Ali's draft splits the processing of the TS packets required to do  
that between the client and the server, with an intermediate TLV- 
encoded format; Xia's draft does all the processing of the TS packets  
in the client. They differ in where the complexity of the pre- 
processing is, and in the format of the packets containing the  
preamble information, but they do not differ in the functionality they  
provide, except that Ali's draft is potentially easier to extend to  
non-MPEG transports.

>> distinguishing advantage of the Begen solution. On the other hand,  
>> if the M2TS decoder does not require specific tricks, injecting the  
>> TS packets directly would be a lot easier.
>>
>>
>>
>> To sum up, I have failed to understand why (Begen draft) the  
>> formatting of the preamble data in a brand new payload format  
>> brings advantages with respect to the re-use of an already  
>> available format.
>>
> Without doing an implementation, it may be difficult for one to see  
> why we do the things this way. We are not trying to entertain  
> ourselves here by creating new formats. We are doing it because we  
> believe it offers more advantages and serves our goals better.
>
>
>>
>>
>>> 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).
>>
>>
>> In which sense the Begen draft adds extensibility and flexibility?  
>> I would have thought the contrary, since potential future additions  
>> in Mpeg2TS will likely require an update of the payload format used  
>> in Begen draft, and not on the payload format adopted by the Xia  
>> draft.
>
> We offer extensibility and flexibility because we can transmit the  
> preamble info in a very concrete fashion but the post-processing on  
> the client side allows us to tailor that information in an optimized  
> fashion for that particular decoder model/chipset/etc. If the server  
> simply sends TS packets, it needs to go with the preamble TS packets  
> that work for all of the decoders in its receiver pool. It can deal  
> with the specifics of the individual receivers. That would not scale  
> at all.
>
> Regarding the future additions to the MPEG2-TS spec, as much as it  
> is unlikely, if that happens, the decoders need to be updated first  
> before we worry about the preamble format. That is a much bigger  
> problem compared to registering a few new TLVs for the preamble  
> registry.
>
> Cheers, acbegen.
>
>
>>
>>
>> Thanks in advance
>>
>> Guido Franceschini
>>
>>
>>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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

---

From: Roni Even <[email-masked]>
Date: Wed, 20 Jan 2010 14:58:34 +0200

Ali,
Inline
Roni Even 
As individual

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Wednesday, January 20, 2010 1:43 PM
> To: Franceschini Guido; Colin Perkins; IETF AVT WG
> follow the various
> mechanism by which the
> solutions is
> Receiver) of a module to
> Begen draft have defined
> You are missing a large part of our motivation for using TLV format. We
> use the info in the TLV elements to initialize the decoder and program
> it so that it can actually start decoding *sooner* compared to simply
> feeding TS packets to the decoder. This step differs from decoder to
> decoder, hence, we do post-processing.

You assume that the decoder is not a black box that accept MPEG2-TS stream.
This may not be the case always and there is no standard definition of such
interface. The general solution may need to convert the TLV elements to
MPEG2-TS stream to be fed to the decoder.

> peculiar issues), nothing
> You mean one could do the same with the TS packets on the server side?
> That would be a bad idea. Not only it won't scale due to the variation
> among decoders (so the server needs to deal with individual
> requirements), but also it will increase the preamble data size that
> would make it more vulnerable to packet loss, thus, failures.

It was agreed that the solution need to satisfy only the System Target
Decoder (STD) that behaves according to the definition of H.222.0 / ISO
13818 see the following text

"Encoders shall produce bit streams that meet the appropriate STD's
constraints. Physical decoders may assume that a stream plays properly on
its STD. The physical decoder must compensate for ways in which its design
differs from that of the STD."

> formatting of the preamble
> Without doing an implementation, it may be difficult for one to see why
> we do the things this way. We are not trying to entertain ourselves
> here by creating new formats. We are doing it because we believe it
> offers more advantages and serves our goals better.
> 
> 
> >
> >
> preamble info in a very concrete fashion but the post-processing on the
> client side allows us to tailor that information in an optimized
> with the specifics of the individual receivers. That would not scale at
> all.
> 
> Regarding the future additions to the MPEG2-TS spec, as much as it is
> unlikely, if that happens, the decoders need to be updated first before
> we worry about the preamble format. That is a much bigger problem
> compared to registering a few new TLVs for the preamble registry.
> 
> Cheers, acbegen.
> 
> 
> >
> >
> > Thanks in advance
> >
> > Guido Franceschini
> >
> >
> >

---

From: Franceschini Guido <[email-masked]>
Date: Wed, 20 Jan 2010 14:25:33 +0100

Ali, Colin, Roni,

thanks for the feedback, really. Indeed, it was hard for me, by just reading docs & mail, to understand all details and motivations.

I learn now that Ali's motivation is that post-processing at a Receiver allows to speed-up the process. I have no intention at all to challenge this statement, although maybe in some implementation things could have worked well also in the simple way.

The only point where I do not understand / share Ali's position is why a different packing is required, instead of just TS packets in RFC2250.
Indeed, if I put an ad-hoc module on a Receiver to manage the preamble, the fact that this module gathers PAT, PMT etc in TLV elements or in Transport Packets ... well, it doesn't really change anything. This actually means that IMHO the two proposals (in terms of RTP packet formatting) have the same value for this case; however I would prefer the RFC2250 solution for two reasons:
- I do not see a need for something different, thus why not re-using something that already exists? It would benefit implementations in terms of development time, debugging, footprint maybe. I don't think that there is a significant difference in payload format overhead.
- Maybe it is true that 100% of Receivers require a preamble specific logic to support a fast start-up, in which case both solutions are comparable; or maybe this does not apply to 100% of Receivers, but just to N%, in which case the usage of RFC2250 would simplify implementation in the remaining (100-N)% of terminals.

To clarify:
> side?
No, I meant one could do the same with the TS packets on the client side, for all clients where this provides benefit.

And of course, the server would just generate a single preamble of TS packets with just the STD model in mind.

Best regards
Guido

-----Original Message-----
From: Roni Even [mailto:[email-masked]]
Sent: mercoledì 20 gennaio 2010 13.59
To: 'Ali C. Begen (abegen)'; Franceschini Guido; 'Colin Perkins'; 'IETF AVT WG'
Subject: RE: [AVT] Discuss Mpeg2TS preamble

Ali,
Inline
Roni Even
As individual

> Franceschini Guido
> > discussion threads, so now I'd like to post some comment.
> >
> > IMHO, from the sender' point of view the difference between the two
> solutions is
> > negligible, but from the Receiver' point of view it is not.
> >
> >
> >

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Jan 2010 07:08:42 -0800

> MPEG2-TS stream to be fed to the decoder.

Right. We can always do the safest thing that all decoders will support. But, hardly that will be the optimal way of doing this. Either solution will work OK for standard decoders. But, for many decoders out there, there is room for improvement. 

Our goal is not to define which algorithm should be used as it will be a difficult task given the variety of things we need to deal with. Rather, we wanna standardize the transport aspects (bits on the wire) but in a way that it provides flexibility to do some customization based on the individual client features.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Jan 2010 07:17:21 -0800

> From: Franceschini Guido [mailto:[email-masked]]
> Sent: Wednesday, January 20, 2010 8:26 AM
> To: Roni Even; Ali C. Begen (abegen); 'Colin Perkins'; 'IETF AVT WG'
> thanks for the feedback, really. Indeed, it was hard for me, by just reading docs & mail,
> to understand all details and motivations.
> 
> I learn now that Ali's motivation is that post-processing at a Receiver allows to speed-up
> the process. I have no intention at all to challenge this statement, although maybe in
> some implementation things could have worked well also in the simple way.
> 
> The only point where I do not understand / share Ali's position is why a different packing
> is required, instead of just TS packets in RFC2250.
> Indeed, if I put an ad-hoc module on a Receiver to manage the preamble, the fact that this
> module gathers PAT, PMT etc in TLV elements or in Transport Packets ... well, it doesn't
> really change anything. This actually means that IMHO the two proposals (in terms of RTP
> packet formatting) have the same value for this case; however I would prefer the RFC2250
> solution for two reasons:
> - I do not see a need for something different, thus why not re-using something that
> already exists? It would benefit implementations in terms of development time, debugging,
> footprint maybe. I don't think that there is a significant difference in payload format
> overhead.

We pack our stuff into a single RTP packet for most cases. If it is received, we are all set. I'd like to see how many RTP packets the other approach produces in general. Most TS packets carry a lot of stuffing bytes.

> - Maybe it is true that 100% of Receivers require a preamble specific logic to support a
> fast start-up, in which case both solutions are comparable; or maybe this does not apply
> to 100% of Receivers, but just to N%, in which case the usage of RFC2250 would simplify
> implementation in the remaining (100-N)% of terminals.

I will say it in more simpler terms:

If additional speed-up is the goal, there has to be some logic on the client that processes the preamble data and generates the appropriate and compliant transport stream for the particular decoder. This is what we claim in our draft and what we do. The other draft stays away from doing such customizations and post-processing because they don't want the clients to deal with this. 

Can't you get the same stuff from the TS packets and do post-processing to speed up the process? You probably can (although authors of the other draft have not said this explicitly yet). But, processing the TS packets will not be easier. We do the common extraction once on the server for all clients and we do customization at each client, which scales pretty well.

Cheers,
-acbegen

---

From: Roni Even <[email-masked]>
Date: Wed, 20 Jan 2010 18:23:42 +0200

Ali,
If I am not wrong this can be done in both solutions since the preamble is
easily identified and the difference is in packetization. 
Still for the non optimization case feeding mpeg2-ts is simpler on the
decoder.
Roni Even as Individual

> Sent: Wednesday, January 20, 2010 5:09 PM
> To: Roni Even; Franceschini Guido; Colin Perkins; IETF AVT WG
> Right. We can always do the safest thing that all decoders will
> support. But, hardly that will be the optimal way of doing this. Either
> solution will work OK for standard decoders. But, for many decoders out
> there, there is room for improvement.
> 
> Our goal is not to define which algorithm should be used as it will be
> a difficult task given the variety of things we need to deal with.
> Rather, we wanna standardize the transport aspects (bits on the wire)
> but in a way that it provides flexibility to do some customization
> based on the individual client features.
> 
> -acbegen
> 
> > >
> > > > prevents the same ad-hoc logic to be implemented on a preamble
> made
> > > of TS packets instead

---

From: Eric Friedrich <[email-masked]>
Date: Wed, 20 Jan 2010 11:45:55 -0500

Roni-
   You are correct that this can be done in both solutions, however  
identifying particular packets in the preamble is much simpler when  
they are marked with TLV types. Without a TLV Type value, the receiver  
would need to implement MPEG2-TS parsing algorithms for the TS packet  
header and for the Program Specific Information (PAT,PMT). The TLV  
proposal does not require any knowledge of PSI semantics at the  
receiver.

Thanks,
Eric

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 20 Jan 2010 11:27:55 -0800

> Sent: Wednesday, January 20, 2010 11:24 AM
> To: Ali C. Begen (abegen); 'Franceschini Guido'; 'Colin Perkins'; 'IETF AVT WG'

For non-optimized case, yeah, pure TS packets are easier to use. But, why should we limit ourselves? In fact, there is not much to define as a draft if the server is guaranteed to produce compliant TS packets for the preamble. By compliant here, I mean, the decoder will not break when it is fed the preamble TS packets and then the TS packets coming out of the unicast burst or the multicast stream. If the implementation can make sure of this and does not see the need for the optimization, it could do so w/o needing a spec for it.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Thu, 21 Jan 2010 00:43:24 +0200

Ali,
I think that what need to be specified is how to convey to the RTP_Rx that
it will receive the preamble as an RFC 2250 stream multiplexed with the
burst. If the stream was sent as a retransmission stream as part of the
burst it would not need any signaling.
There is also a need to provide guidelines about how to compose the preamble
stream.

Roni Even as Individual

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Wednesday, January 20, 2010 9:28 PM
> For non-optimized case, yeah, pure TS packets are easier to use. But,
> why should we limit ourselves? In fact, there is not much to define as
> a draft if the server is guaranteed to produce compliant TS packets for
> the preamble. By compliant here, I mean, the decoder will not break
> when it is fed the preamble TS packets and then the TS packets coming
> out of the unicast burst or the multicast stream. If the implementation
> can make sure of this and does not see the need for the optimization,
> it could do so w/o needing a spec for it.
> 
> -acbegen
> 
> > Roni Even as Individual
> >
> > > > > feeding TS packets to the decoder. This step differs from
> decoder
> > > to
> > > > You assume that the decoder is not a black box that accept MPEG2-
> TS
> > > stream.
> > > > This may not be the case always and there is no standard
> definition
> > > of such
> > > > interface. The general solution may need to convert the TLV
> elements
> > > to
> > > > > > of a preamble made of TLV elements, and thus I do not see
> this
> > > > > argument as a
> > > > >
> > > > Decoder (STD) that behaves according to the definition of H.222.0
> /
> > > ISO
> > > > its STD. The physical decoder must compensate for ways in which
> its
> > > design

---

From: Peilin Yang <[email-masked]>
Date: Thu, 21 Jan 2010 17:21:47 +0800

Hi Guido, Colin, Roni and Ali,

I think Guido makes a positive evaluation of two preamble drafts that
re-using the RFC2250 solution that already exists would benefit
implementations in terms of development time, debugging, footprint.... I
support him.

About "sooner".  
I am not clear how "it can actually start decoding *sooner* compared to
simply feeding TS packets to the decoder. " The following is extracted from
Ali's email.
"You are missing a large part of our motivation for using TLV format. We use
the info in the TLV elements to initialize the decoder and program it so
that it can actually start decoding *sooner* compared to simply feeding TS
packets to the decoder. This step differs from decoder to decoder, hence, we
do post-processing."
I read carefully the  Post-pprocessing in Section 7 Ali's draft.  "7.
Post-Processing of the MPEG2-TS Preamble"  "...the Preamble information
must be first processed and a demux/decoder-friendly stream must be  formed.
The demux/decoder-friendly stream must conform to [MPEG2TS].   In this
section, we briefly explain this process."
>From these sentences, IMHO, there shall be an extra step to convert TOLV to
TS packet after receiving preamble, and then feed to demultiplex and decode.
Yet in Xia's draft, directly feed to  demultiplex and decode after receiving
preamble. Which is it "sooner"? IMHO, No extra step shall be sooner. Except
"sooner", the key important is that RTP session in Xia's draft doesn't need
to understand MPEG2-TS . It is transparant for RTP session.

About TOLV format. 
Leave aside the length of IPMP is three bytes which is bigger than two bytes
of the length of TOLV.  The length of ECM and EMM is variable, it is
possbile that their length is bigger than the length which two bytes
describe. This is a question for present TOLV format. In addition, in this
case, ECM and EMM have several TS packets.  I have no idea how TOLV do.
Does It need to copy all ECM/EMM TS packet into Section data of TOLV?

About the discontinuity.
How to deal with the discontinuity from 'Sandy (Alexander) MacInnis'.

Best regards
Peilin

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Franceschini
Guido
发送时间: 2010年1月20日 21:26
收件人: Roni Even; 'Ali C. Begen (abegen)'; 'Colin Perkins'; 'IETF AVT WG'
主题: Re: [AVT] Discuss Mpeg2TS preamble

Ali, Colin, Roni,

thanks for the feedback, really. Indeed, it was hard for me, by just reading
docs & mail, to understand all details and motivations.

I learn now that Ali's motivation is that post-processing at a Receiver
allows to speed-up the process. I have no intention at all to challenge this
statement, although maybe in some implementation things could have worked
well also in the simple way.

The only point where I do not understand / share Ali's position is why a
different packing is required, instead of just TS packets in RFC2250.
Indeed, if I put an ad-hoc module on a Receiver to manage the preamble, the
fact that this module gathers PAT, PMT etc in TLV elements or in Transport
Packets ... well, it doesn't really change anything. This actually means
that IMHO the two proposals (in terms of RTP packet formatting) have the
same value for this case; however I would prefer the RFC2250 solution for
two reasons:
- I do not see a need for something different, thus why not re-using
something that already exists? It would benefit implementations in terms of
development time, debugging, footprint maybe. I don't think that there is a
significant difference in payload format overhead.
- Maybe it is true that 100% of Receivers require a preamble specific logic
to support a fast start-up, in which case both solutions are comparable; or
maybe this does not apply to 100% of Receivers, but just to N%, in which
case the usage of RFC2250 would simplify implementation in the remaining
(100-N)% of terminals.

> You mean one could do the same with the TS packets on the server side?
No, I meant one could do the same with the TS packets on the client side,
for all clients where this provides benefit.

And of course, the server would just generate a single preamble of TS
packets with just the STD model in mind.

Best regards
Guido

-----Original Message-----
From: Roni Even [mailto:[email-masked]]
Sent: mercoledì 20 gennaio 2010 13.59
To: 'Ali C. Begen (abegen)'; Franceschini Guido; 'Colin Perkins'; 'IETF AVT
WG'

Ali,
Inline
Roni Even
As individual

> > interpret the new payload format and transform the data being 
> > carried
> in the TLV elements
> > commands towards a local / private API). Such a translation module 
> > is
> not required in case
> > M2TS decoder, and some trick needs to be implemented. However, if 
> > the
> above statement is
>
> program it so that it can actually start decoding *sooner* compared to 
> simply feeding TS packets to the decoder. This step differs from 

> > if
> the M2TS decoder
> > > authors
> have any changes
> > the contrary, since potential future additions in Mpeg2TS will 
> > likely
> require an update of
> > the payload format used in Begen draft, and not on the payload 
> > format
> adopted by the Xia
> > draft.
>
> unlikely, if that happens, the decoders need to be updated first 
> problem compared to registering a few new TLVs for the preamble registry.
>
> Cheers, acbegen.
>
>
> >
> >
> > Thanks in advance
> >
> > Guido Franceschini
> >
> >
> >
> > Broadband Solutions and Multimedia Innovation Via Guglielmo Reiss 
> > Romoli, 274 10148 Torino
> > office   +39 011 2286137
> > mobile +39 335 7669748
> > fax      +39 011 2287003
> >
> >
> >
> > Thanks to the authors and all those who attended, we had a 
> > productive
> meeting to discuss
> > the media stream, cache it on the server, and send it to the 
> > receiver
> on request in the
> > The idea expressed in the Xia draft is to extract the MPEG2-TS 
> > frames
> needed for the
> >     We will have an offline meeting to talk about MPEG2TS preamble 
> > at
> 16:00 today. We can
> > errore siete cortesemente pregati di darne immediata comunicazione 
> > al
> mittente e di

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone indicate. La diffusione, copia o qualsiasi altra azione derivante
dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
abbiate ricevuto questo documento per errore siete cortesemente pregati di
darne immediata comunicazione al mittente e di provvedere alla sua
distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the
sender by return e-mail, Thanks.

---

From: Peilin Yang <[email-masked]>
Date: Thu, 21 Jan 2010 17:33:26 +0800

Hi Eric,

I don't think that the receiver does not know the knowledge of PSI semantics
in Ali's draft.  

"PAT_TLOV_Type,PMT_TLOV_Type, ECM_TLOV_Type, ECM_TLOV_Type, etc" are all the
PSI semantics. If there is a new PSI emerging,the receiver must know
it.otherwise, the result is bad. 

Peilin

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Eric
Friedrich
发送时间: 2010年1月21日 0:46
收件人: Roni Even
抄送: 'Colin Perkins'; 'Franceschini Guido'; 'IETF AVT WG'
主题: Re: [AVT] Discuss Mpeg2TS preamble

Roni-
   You are correct that this can be done in both solutions, however
identifying particular packets in the preamble is much simpler when they are
marked with TLV types. Without a TLV Type value, the receiver would need to
implement MPEG2-TS parsing algorithms for the TS packet header and for the
Program Specific Information (PAT,PMT). The TLV proposal does not require
any knowledge of PSI semantics at the receiver.

Thanks,
Eric

On Jan 20, 2010, at 11:23 AM, Roni Even wrote:

> Ali,
> If I am not wrong this can be done in both solutions since the 
> preamble is easily identified and the difference is in packetization.
>> solution will work OK for standard decoders. But, for many decoders 
>> out there, there is room for improvement.
>>
>> Our goal is not to define which algorithm should be used as it will 
>> be a difficult task given the variety of things we need to deal with.

---

From: Eric Friedrich <[email-masked]>
Date: Thu, 21 Jan 2010 07:33:53 -0500

Hi Peilin-
   Comment Inline
On Jan 21, 2010, at 4:21 AM, Peilin Yang wrote:

> <snipped...>

Depending on the layout of ECM/EMM in the Transport Stream, the  
preamble will contain 1 TOLV per section. The section length is  
limited to 4096 according to MPEG2-TS standards, which can be  
expressed in 16 bytes. Multiple ECM or EMM sections are represented in  
the preamble by multiple TOLV elements.

Thanks,
Eric

---

From: Eric Friedrich <[email-masked]>
Date: Thu, 21 Jan 2010 07:42:19 -0500

Hi Peilin-
   I will clarify my earlier remarks.

For whichever preamble proposal you choose, you may wish to do some  
post processing on the receiver. In order to do this post-processing,  
you must be able to identify the difference between the PAT, PMT and  
ECM packets for example. They are present on different PIDs, but you  
must discover what PID each of them uses.

In the Xia draft, the only way to discover the PMT and ECM PIDs is to  
parse the PAT and PMT. This parsing requires knowledge of PSI  
semantics (size, location and meaning of every bitfield specified by  
the MPEG-2TS program_association and program_map tables).

In the TOLV preamble case, the receiver does not need the ability to  
parse the PAT and PMT of the stream. Instead, the PAT, PMT, and ECM  
packets are marked as such using TOLV Type values defined in the Begen  
draft. I do not regard these TOLV values as part of the PSI semantics  
as they are outside the scope of the MPEG2-TS standard.

Thanks,
Eric Friedrich

On Jan 21, 2010, at 4:33 AM, Peilin Yang wrote:

> they are

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 21 Jan 2010 05:25:07 -0800

> preamble. Which is it "sooner"? IMHO, No extra step shall be sooner. Except

You are comparing mice to elephants. The time needed for post-processing is almost nothing compared to the savings it provides.

> Does It need to copy all ECM/EMM TS packet into Section data of TOLV?

Eric has already responded.
 
> How to deal with the discontinuity from 'Sandy (Alexander) MacInnis'.

We deal with it in the post processing. So, it is not a concern for us. 

-acbegen

---

From: Hui Deng <[email-masked]>
Date: Thu, 21 Jan 2010 22:52:40 +0800

Hi All,

I also support Guido's opinion. From the viewpoint of operator, I also
would prefer the RFC2250 solution because potential future additions
in MPEG2-TS will not require an update of the Receivers in the Xia
draft.

Best regards,
Hui

---

From: Martin Ellis <[email-masked]>
Date: Thu, 21 Jan 2010 15:23:13 +0000

Hi,

I've been following this thread, but I'm slightly confused by this argument.

If there are future additions to MPEG2-TS, doesn't that mean that the
receivers definitely *will* need to be updated (to handle the new
MPEG2-TS format)?
At that point, any necessary changes to handle the preamble could also
be addressed, right?

Martin

---

From: Franceschini Guido <[email-masked]>
Date: Thu, 21 Jan 2010 16:48:00 +0100

Hi all,

Since I was maybe the first one to mention this, let me agree with the most of you on the fact that the potential future upgrade of MPEG2 specs is not an issue worth discussion.
Definitely, decision on one or the other technology should not be based on such a weak argument.

Let me also add that I am very happy that my comments promoted so much reaction, which -at least for myself- has much better clarified the motivation of the Begen draft.
The fact that, at the end of the day, I am not convinced of Begen's choices and maintain my preference for the Xia draft is then my own individual opinion; what is more valuable, I think, is that everybody has now a chance to make his own better-informed opinion, since much "noise" and misunderstanding has been cleared.

Cheers
Guido

-----Original Message-----
From: Martin Ellis [mailto:[email-masked]]
Sent: giovedì 21 gennaio 2010 16.23
To: Hui Deng
Cc: Franceschini Guido; Colin Perkins; Roni Even; IETF AVT WG
Subject: Re: [AVT] Discuss Mpeg2TS preamble

Hi,

Martin

---

From: Roni Even <[email-masked]>
Date: Thu, 21 Jan 2010 18:03:17 +0200

Hi,
There is a different between the codec and the pre-processing part. The
codec may be a black box that the manufacturer buys and updates while the
pre-processing is updated separately
Roni Even

> Sent: Thursday, January 21, 2010 5:23 PM
> To: Hui Deng
> >> thanks for the feedback, really. Indeed, it was hard for me, by just
> reading docs & mail, to understand all details and motivations.
> >>
> >> I learn now that Ali's motivation is that post-processing at a
> Receiver allows to speed-up the process. I have no intention at all to
> challenge this statement, although maybe in some implementation things
> could have worked well also in the simple way.
> >>
> >> The only point where I do not understand / share Ali's position is
> why a different packing is required, instead of just TS packets in
> RFC2250.
> >> Indeed, if I put an ad-hoc module on a Receiver to manage the
> preamble, the fact that this module gathers PAT, PMT etc in TLV
> elements or in Transport Packets ... well, it doesn't really change
> anything. This actually means that IMHO the two proposals (in terms of
> RTP packet formatting) have the same value for this case; however I
> would prefer the RFC2250 solution for two reasons:
> something that already exists? It would benefit implementations in
> terms of development time, debugging, footprint maybe. I don't think
> that there is a significant difference in payload format overhead.
> >> - Maybe it is true that 100% of Receivers require a preamble
> specific logic to support a fast start-up, in which case both solutions
> are comparable; or maybe this does not apply to 100% of Receivers, but
> just to N%, in which case the usage of RFC2250 would simplify
> >> No, I meant one could do the same with the TS packets on the client
> side, for all clients where this provides benefit.
> >>
> >> And of course, the server would just generate a single preamble of
> TS packets with just the STD model in mind.
> >>
> >> Best regards
> >> Guido
> >>
> >>> > commands towards a local / private API). Such a translation
> module is
> >>> not required in case
> >>> > distinguishing advantage of the Begen solution. On the other
> hand, if
> >>> the M2TS decoder
> >>> > does not require specific tricks, injecting the TS packets
> directly
> >>> would be a lot easier.
> >>> >
> >>> >
> >>> >
> >>> > data in a brand new payload format brings advantages with respect
> to
> >>> the re-use of an
> why
> >>> > they wish to make, is available, we expect the working group will
> be
> >>> able to review both
> >>> > draft) or a slightly lower overhead with less flexibility (the
> Xia
> >>> draft).
> >>> >
> >>> >
> >>> >
> >>> > In which sense the Begen draft adds extensibility and
> flexibility? I
> >>> would have thought
> before
> >>> > 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
> >>> > The idea expressed in the Begen draft is to extract the data
> needed
> >>> for the preamble from
> >>> > 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
> >>> > 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
> >>> > data as the preamble. The key difference between them is the way
> in
> >>> which that data is
> >>> > into a TLV-encoded form for transmission; the Xia draft extracts
> the
> >>> preamble data from
> >>> > 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
> >>> > packets as RFC 2250 packets, rather than the current approach
> that
> >>> uses an RFC 4588
> >>> > 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.
> >>> > The meeting concluded with an understanding that the two
> proposals
> >>> have essentially
> >>> > identical overheads and behaviour. The key difference between
> then,
> >>> assuming the Xia
> >>> > 2250 packets to conform to the RTP specifications, is that the
> Begen
> >>> draft includes
> >>> > proposal when dealing with encrypted streams. This will need to
> be
> >>> clarified.
> >>> >
> >>> >
> >>> >
> >>> > Actions:
> >>> >
> >>> >
> >>> >
> >>> > the discussion, especially with respect to the exact amount of
> data
> >>> that has to be sent in
> >>> > *   Authors of the Xia draft to clarify its behaviour when using
> an
> >>> encrypted MPEG2-TS.
> >>> >
> >>> >
> >>> >
> >>> have any changes they
> >>> > wish to make, is available, we expect the working group will be
> able
> >>> to review both
> >>> > draft) or a slightly lower overhead with less flexibility (the
> Xia
> >>> draft).
> >>> >
> >>> >
> >>> >
> >>> > Colin
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >     We will have an offline meeting to talk about MPEG2TS
> preamble at
> >>> 16:00 today. We can
> >>> > Questo messaggio e i suoi allegati sono indirizzati
> esclusivamente
> >>> alle persone indicate.
> >>> > errore siete cortesemente pregati di darne immediata
> comunicazione al
> >>> mittente e di
> >>> > intended for the addressee(s) only. Dissemination, copying,
> printing
> >>> or use by anybody
> >>> > else is unauthorised. If you are not the intended recipient,
> please
> >>> delete this message
> >>> > rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail
> se
> >>> non è necessario.
> >>>
> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> >> This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is
> unauthorised. If you are not the intended recipient, please delete this
> message and any attachments and advise the sender by return e-mail,
> Thanks.
> >>