-----Original Message-----
From: Frank Xia [mailto:xiayangsong at huawei.com]
Sent: Thursday, November 12, 2009 7:02 AM
To: Ali C. Begen (abegen); Allison, Art; IETF AVT WG
Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
Hi Ali
It is reasonable to assert " ...and additional
particular requirements of that client, if any"
when you even don't what "any" is?
BR
Frank
----- Original Message -----
From: "Ali C. Begen (abegen)" <abegen at cisco.com>
To: "Allison, Art" <AAllison at nab.org>; "IETF AVT WG" <avt at ietf.org>
Sent: Wednesday, November 11, 2009 3:38 PM
Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
> Indeed. In our scheme, we achieve it in the post processing stage while
> creating the TS packets out of the TLOV elements and considering the
> arriving burst packets that carry the original TS packets. The outcome
> of
> the post processing strictly obeys the rules of the MPEG2-TS spec and
> additional particular requirements of that client, if any.
>
> -acbegen
>
>> -----Original Message-----
>> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of
>> Allison, Art
>> Sent: Wednesday, November 11, 2009 11:58 PM
>> To: IETF AVT WG
>> Subject: 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
>> |
>> _______________________________________________
>> 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