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

Re: [AVT] Discuss Mpeg2TS preamble - meeting room

To: "IETF AVT WG" <avt at ietf.org>
Subject: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
From: "Allison, Art" <AAllison at nab.org>
Date: Wed, 11 Nov 2009 17:10:12 -0500
Delivered-to: avt at core3.amsl.com
In-reply-to: <04CAD96D4C5A3D48B1919248A8FE0D540A9A5DD4 at xmb-sjc-215.amer.cisco.com>
List-archive: <http://www.ietf.org/mail-archive/web/avt>
List-help: <mailto:avt-request@ietf.org?subject=help>
List-id: Audio/Video Transport Working Group <avt.ietf.org>
List-post: <mailto:avt@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
References: <009201ca618d$0dcca980$2965fc80$%roni at huawei.com> <002801ca619e$fdd80440$f9880cc0$%roni at huawei.com> <83BC92A1-5634-4655-8A39-B320158631E7 at csperkins.org> <C90F9745-FC16-4529-8269-6EB8D39FEFB7 at cisco.com> <001901ca625c$a50f0a20$3e0c7c0a at china.huawei.com> <71C9EC0544D1F64D8B7D91EDCC6220200320EF65 at NABSREX027324.NAB.ORG> <04CAD96D4C5A3D48B1919248A8FE0D540A9A5D9D at xmb-sjc-215.amer.cisco.com> <000801ca631a$8a4a8700$3e0c7c0a at china.huawei.com> <04CAD96D4C5A3D48B1919248A8FE0D540A9A5DD4 at xmb-sjc-215.amer.cisco.com>
Thread-index: AcpjGphHH3cn7A3LR02IU+wQiRnfMQAACJ+gAAApjxA=
Thread-topic: [AVT] Discuss Mpeg2TS preamble - meeting room

To avoid defining clients; what has worked in other standards has been
to place constraints on the transmission, including a buffer model that
must be followed; and then any complaint receiver should work.
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: Ali C. Begen (abegen) [mailto:abegen at cisco.com] 
|Sent: Wednesday, November 11, 2009 5:05 PM
|To: Frank Xia; Allison, Art; IETF AVT WG
|Subject: RE: [AVT] Discuss Mpeg2TS preamble - meeting room
|
|I know what "any" is, but we were asked not to specify such 
|things in the list or the draft. This was in the breakout 
|session, and you may consult with your colleagues who attended 
|the meeting.
|
|-acbegen
|
|> -----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
|
|

References:
- [AVT] Discuss Mpeg2TS preamble
  - From: Roni Even
- [AVT] Discuss Mpeg2TS preamble - meeting room
  - From: Roni Even
- Re: [AVT] Discuss Mpeg2TS preamble - meeting room
  - From: Colin Perkins
- Re: [AVT] Discuss Mpeg2TS preamble - meeting room
  - From: David R Oran
- Re: [AVT] Discuss Mpeg2TS preamble - meeting room
  - From: Frank Xia
- Re: [AVT] Discuss Mpeg2TS preamble - meeting room
  - From: Allison, Art
- Re: [AVT] Discuss Mpeg2TS preamble - meeting room
  - From: Ali C. Begen (abegen)
- Re: [AVT] Discuss Mpeg2TS preamble - meeting room
  - From: Frank Xia
- Re: [AVT] Discuss Mpeg2TS preamble - meeting room
  - From: Ali C. Begen (abegen)

Prev by Date: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
Next by Date: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
Previous by thread: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
Next by thread: Re: [AVT] Discuss Mpeg2TS preamble - meeting room
Index(es):
- Date
- Thread