MPEG2 TS Preamble

1
MPEG2 TS Preamble

• Solutions on the table
• http//tools.ietf.org/id/draft-begen-avt-rtp-mpeg2
  ts-preamble-04.txt
• http//tools.ietf.org/id/draft-xia-avt-mpeg2ts-pre
  amble-02.txt

2
Problem statement

• Demultiplexing and decoding an MPEG2 Transport
  Stream (MPEG2-TS) requires the knowledge of
  specific information about the transport stream,
  which can be spread over different locations
  throughout the transport stream.
• The time it takes to retrieve all this
  information the MPEG2 TS preamble- for an (RTP)
  receiver may be long.
• Idea is to send the MPEG2 TS preamble
  information to a receiver that will shortly start
  receiving the transport stream, allowing the
  receiver to start processing/decoding the
  MPEG2-TS sooner.

3
MPEG2 TS preamble RAMS environment
RAP Preamble ? Transport Stream RAP (TSRAP)

• RAP data is sent as retransmission packets in a
  burst, when an RTP receiver wants rapid
  acquisition of a SSM RTP (RAMS draft)
• There are two proposals on how to efficiently
  send MPEG2 TS preamble data which is
  periodically repeated but in general scattered
  across the MPEG2 TS RTP SSM - alongside with the
  burst

4
Begen versus Xia Solution

• Begen
• The MPEG2 TS Preamble is wrapped by the RS in
  dedicated Type-Order-Length-Value (TOLV)
  elements, encapsulated in RTP packets e.g. PAT
  TOLV, PCR TOLV,..
• The RTP receiver performs a post-processing in
  order to present this as TS data to the TS
  demuxer/decoding logic
• Xia
• The MPEG2 TS Preamble is sent by the RS as MPEG2
  TS/RTP packets (RFC 2250), with TS packets kept
  unmodified from original Stream

5
Discussions from mailing list

• Begen et. Al. stress that irrespective of the
  preamble transport method, there must be
  post-processing done by any receiver design, as
  existing TS demuxing/decoding logic in most cases
  will not respond in a desired way to a burst of
  condensed MPEG2 TS preamble info
• This was initially contested by Xia et al, but
  the Xia draft does not preclude such post
  processing
• The customised post-processing is not addressed
  in Begen draft
• Both solutions do not result in large differences
  in terms of processing requirements, both at
  server side and receiver side
• Some expressed a single solution is preferred,
  others are OK with both solutions specified by
  IETF
• Little specification is required for Xia
  proposal, but may have slightly more bandwidth
  overhead compared to Begen draft
• Not significant when compared to the RAMS burst
  packet transmissions
• Discussions on how easy/difficult it is for a
  MPEG2 TS preamble post-processing stage at the
  receiver, where starting point is either the Xia
  format or the Begen format
• Should the MPEG2 TS preamble also be addressed in
  a non-RAMS environment?