-----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