[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Discuss Mpeg2TS preamble - meeting room
Many thanks, Colin - this really clarifies!
BR, YK
> -----Original Message-----
> From: Colin Perkins [mailto:csp at csperkins.org]
> Sent: Wednesday, November 11, 2009 1:19 AM
> To: Ye-Kui Wang
> Cc: 'Stephan Wenger'; 'David R Oran'; 'IETF AVT WG'
> Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
>
>
> On 11 Nov 2009, at 15:05, Ye-Kui Wang wrote:
> > 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),
>
> 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
>
>
>
> > 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: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org]
> On Behalf Of
> >> Stephan Wenger
> >> Sent: Tuesday, November 10, 2009 6:31 PM
> >> To: David R Oran; Colin Perkins
> >> Cc: IETF AVT WG
> >> Subject: 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
> >>
> >>
> >> _______________________________________________
> >> 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
>
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>
>