MPEG2 TS Preamble Solutions on the table: mpeg2ts-preamble-04.txt mpeg2ts-preamble-02.txt

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.

MPEG2 TS preamble RAMS environment 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 RAP + Preamble  Transport Stream RAP (TSRAP)

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

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?