Subject: [AVT] Status of MPEG2-TS preamble

From: Roni Even <[email-masked]>
Date: Thu, 29 Jul 2010 10:33:12 +0300

Hi guys,

I would like to express my view of the situation as individual.

1.       After the previous IETF meeting. Huawei provided example that
demonstrate that  there is no need for post processing. These examples were
based onMPEG2-TS steams used by their customers.

2.       There were no streams given by Cisco that show the need for post
processing.

3.       The whole issue of post processing in my view is not relevant since
the discussion is how to send the preamble over the wire

4.       If we want to have two options in the solution the way to do it is
to have the RS support both and add to the RAMS-R message a parameter that
will indicate the preamble mode supported by the RTP_Rx. If we go this wa it
is important to decide now before we publish RAMS so that we will not have
later backward interoperability problems

Thanks

Roni Even - as individual

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 29 Jul 2010 11:42:19 -0500

Roni-

Regarding your first 3 points - As noted in the on-list discussions at
the time, we recommended that a stream that has encryption enabled is
more instructive in analyzing the relative merits of the two proposals.
A stream that has more than one set of encryption keys (aka DVB
simulcrypt, or similar protocol) is even more useful. We referenced a
code set in the open-source community that shows how to handle such
stream using the TLV method. 

I am not aware of any guidance on how to generate an MPEG2TS compliant
preamble burst that can be passed to a generic MPEG
demux/decrypt/decoder. Based on extensive experience in the wild, one
can't simply pass a burst of MPEG2TS data to a demux/decrypt/decode
chain and expect it to work in an accelerated manner. This is
particularly true if you have multiple Conditional Access Systems (CAS)
in use. In fact, if you do not let the various client sub-systems
configure themselves with one data element before jamming the next
element into them, the AV display will be delayed rather than
accelerated. In other words, you need to setup the demux with the
content of the PAT, then setup the demux with the contents of the PMT.
You then have to figure out which CAS is in use on this stream and setup
the decrytpor. You then feed the appropriate ECM into the decryptor and
get the control word. You then feed the control word into the stream
decryptor and let it setup. You are then (and only then) able to send
the I-frame and subsequent B-P frames into the decoder. We tried this
both ways, using MPEG2TS and TLV. The TLV method turned out to be more
efficient, on both the server and the client. This is true for a given
client implementation, and it becomes increasingly apparent as
additional chipsets/clients are implemented. The TLV method allows the
RTP/RAMS software modules to do the processing. If you try to do this
processing in the MPEG2TS domain, modules that are not normally
available to the client implementor (CAS kernels, transport demux
microcode, and maybe even decryptor and decoder microcode) may be
impacted. Also remember that the RS does not have control over the
originator of the MPEG stream  (aka the encoder/encryptor/mux)- it has
to work with any compliant stream.

These are subtle points, and I encourage the reader to consider today's
prior email on this subject as well as the code we have released.

Regarding your last point - If we burden the RS with both methods, there
is a realtime performance penalty as well as a coding/testing burden. I
would strongly prefer to find the best technical solution. If there is a
better way to do this than the scheme we have proposed (and contributed
to the open source community), I would be very happy to see it.

Bill VerSteeg

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roni Even
Sent: Thursday, July 29, 2010 9:33 AM
To: 'IETF AVT WG'
Subject: [AVT] Status of MPEG2-TS preamble

Hi guys,

1.       After the previous IETF meeting. Huawei provided example that
demonstrate that  there is no need for post processing. These examples
were based onMPEG2-TS steams used by their customers.

2.       There were no streams given by Cisco that show the need for
post  processing.

3.       The whole issue of post processing in my view is not relevant
since the discussion is how to send the preamble over the wire

4.       If we want to have two options in the solution the way to do it
is to have the RS support both and add to the RAMS-R message a parameter
that will indicate the preamble mode supported by the RTP_Rx. If we go
this wa it is important to decide now before we publish RAMS so that we
will not have later backward interoperability problems

Thanks