Subject: Re: [AVT] Discuss Mpeg2TS preamble

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

I will just repeat myself. 

Everything we need for rams purposes is already defined. If there will be changes or additions in the mpeg2-ts spec, the preamble is the least important thing to worry about on a settop box. Even then defining new elements is as simple as registering with iana. 

If one is not planning to get the full potential of using the preamble, then it is of course his own choice. I cannot argue with that. 

-acbegen

----- Original Message -----
From: Hui Deng <[email-masked]>
To: Franceschini Guido <[email-masked]>
Cc: Roni Even <[email-masked]>; Ali C. Begen (abegen); Colin Perkins <[email-masked]>; IETF AVT WG <[email-masked]>
Sent: Thu Jan 21 06:52:40 2010
Subject: Re: [AVT] Discuss Mpeg2TS preamble

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

2010/1/20 Franceschini Guido <[email-masked]>:
> 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:
>> 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'
> Subject: RE: [AVT] Discuss Mpeg2TS preamble
>
> Ali,
> Inline
> Roni Even
> As individual
>
>> -----Original Message-----
>> 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
>> Subject: Re: [AVT] Discuss Mpeg2TS preamble
>>
>> 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.
>
> 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.
>
>>
>> > 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.
>
> 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."
>
>
>>
>> > 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?
>>
>> 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.
>>
>>
>> >
>> >
>> > 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.
>>
>> 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
>> >
>> >
>> >
>> > ------------------------------------------------------------------
>> > 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]] 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/
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > 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.
>>
>> _______________________________________________
>> Audio/Video Transport Working Group
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/avt
>
>
> 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.
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

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

In the rams context, it should be sent in the ret session with payload-type multiplexing. I don't see any better approach for either draft. But since xia draft is not defining a new payload format, the preamble has to be fully acceptable by any receiver that understands 2250 language. This requires strict conformance to rfc 2250. So I guess one won't need signaling for this. 

We define a new format and the client needs to understand it. Ow it will discard it. 

As for the content of the premable, we have guidelines in our draft. Any further detail IMO is implementation specific. In the xia draft, the main mpeg2ts spec rules apply so I don't think there is a need for any guidelines. That's why I earlier asked why one would need the xia draft for an implementation. We wrote a draft because we defined a new payload format. Cheers.       

-acbegen

----- Original Message -----
From: Roni Even <[email-masked]>
To: Ali C. Begen (abegen); 'Franceschini Guido' <[email-masked]>; 'Colin Perkins' <[email-masked]>; 'IETF AVT WG' <[email-masked]>
Sent: Wed Jan 20 14:43:24 2010
Subject: RE: [AVT] Discuss Mpeg2TS preamble

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
> To: Roni Even; Franceschini Guido; Colin Perkins; IETF AVT WG
> > Sent: Wednesday, January 20, 2010 11:24 AM
> > To: Ali C. Begen (abegen); 'Franceschini Guido'; 'Colin Perkins';
> 'IETF AVT WG'
> > 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.
> 
> 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
> >
> > > Sent: Wednesday, January 20, 2010 5:09 PM
> > > To: Roni Even; Franceschini Guido; Colin Perkins; IETF AVT WG
> > > > > 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
> > > 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
> > > > 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