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