[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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