[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] Discuss Mpeg2TS preamble - meeting room

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" <oran at cisco.com> wrote:

> 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 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: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf
>>> Of Roni Even
>>> Sent: Tuesday, November 10, 2009 7:36 AM
>>> To: avt at ietf.org
>>> 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
>> avt at ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt