An M2TS multiplexor with separate independent time sources support.
Links
→ M2TS@wikipedia
Project is now suspended.
Q: Why is it two sections for descriptors in the same single transport packet?
A: First section characterizes program and second one (for each elementary stream) characterizes elementary stream. And these descriptors are not necessarily applicable for both. For instance, the following descriptors can not be found in program info descriptors section: Maximum_bitrate_descriptor, STD_descriptor, SL_descriptor, MultiplexerBuffer_descriptor.
How to get information about programs in MPEG transport stream.
(1) Read new transport packet
(2) If PID!=0 then goto (1), else goto (3)
(3) If adaptation_field_control equals b'10' or b'00' then goto (1), else goto (4)
(4) Payload of the packet is PAT data, so there must be
N == (section_length - 9)/4 of programs described by 16 bit program_number field and
13 bit program_map_PID (or network_PID if program_number equals 0) and 3 bit stuffing in between.
After I gathered all the {program_number, program_map_PID} pairs, I can
look for PMT packets with corresponding PIDs.
(1) Filter transport packet with PID equal to one of the listed at PAT
(2) Read PCR_PID (13)
(3) In ES loop look for stream_type (8) and elementary_PID (13) of each
From ISO13818-1 (Generic coding of moving pictures and associated audio information):
2.1.2 bitrate: The rate at which the compressed bit stream is delivered from the channel to the input of a decoder.
2.1.10 data element: An item of data as represented before encoding and after decoding.
2.1.13 decoding (process): The process defined in ITU-T Rec. H.222.0 | ISO/IEC 13818-1 that reads an input coded bit stream and outputs decoded pictures or audio samples.
2.1.20 elementary stream; ES (system): A generic term for one of the coded video, coded audio or other coded bit streams in PES packets. One elementary stream is carried in a sequence of PES packets with one and only one stream_id.
2.1.31 packet data (system): Contiguous bytes of data from an elementary stream present in a packet.
2.1.32 packet identifier; PID (system): A unique integer value used to identify elementary streams of a program in a single or multi-program Transport Stream as described in 2.4.3 of ITU-T Rec. H.222.0 | ISO/IEC 13818-1.
2.1.33 padding (audio): A method to adjust the average length of an audio frame in time to the duration of the corresponding PCM samples, by conditionally adding a slot to the audio frame.
2.1.34 payload: Payload refers to the bytes which follow the header bytes in a packet. For example, the payload of some Transport Stream packets includes a PES_packet_header and its PES_packet_data_bytes, or pointer_field and PSI sections, or private data; but a PES_packet_payload consists of only PES_packet_data_bytes. The Transport Stream packet header and adaptation fields are not payload.
2.1.35 PES (system): An abbreviation for Packetized Elementary Stream.
2.1.36 PES packet (system): The data structure used to carry elementary stream data. A PES packet consists of a PES packet header followed by a number of contiguous bytes from an elementary data stream. It is a layer in the system coding syntax described in 2.4.3.6 of ITU-T Rec. H.222.0 | ISO/IEC 13818-1.
2.1.37 PES packet header (system): The leading fields in a PES packet up to and not including the PES_packet_data_byte fields, where the stream is not a padding stream. In the case of a padding stream the PES packet header is similarly defined as the leading fields in a PES packet up to and not including padding_byte fields.
2.1.38 PES Stream (system): A PES Stream consists of PES packets, all of whose payloads consist of data from a single elementary stream, and all of which have the same stream_id. Specific semantic constraints apply. Refer to Intro. 4 of ITU-T Rec. H.222.0 | ISO/IEC 13818-1.
2.1.39 presentation time-stamp; PTS (system): A field that may be present in a PES packet header that indicates the time that a presentation unit is presented in the system target decoder.
2.1.40 presentation unit; PU (system): A decoded Audio Access Unit or a decoded picture.
2.1.41 program (system): A program is a collection of program elements. Program elements may be elementary streams. Program elements need not have any defined time base; those that do, have a common time base and are intended for synchronized presentation.
2.1.42 Program Clock Reference; PCR (system): A time stamp in the Transport Stream from which decoder timing is derived.
2.1.43 program element (system): A generic term for one of the elementary streams or other data streams that may be included in a program.
2.1.44 Program Specific Information; PSI (system): PSI consists of normative data which is necessary for the demultiplexing of Transport Streams and the successful regeneration of programs and is described in 2.4.4 of ITU-T Rec. H.222.0 | ISO/IEC 13818-1. An example of privately defined PSI data is the non-mandatory network information table.
2.1.45 random access: The process of beginning to read and decode the coded bit stream at an arbitrary point.
2.1.46 reserved: The term "reserved", when used in the clauses defining the coded bit stream, indicates that the value may be used in the future for ISO defined extensions. Unless otherwise specified within ITU-T Rec. H.222.0 | ISO/IEC 13818-1, all reserved bits shall be set to '1'.
bslbf Bit string, left bit first, where "left" is the order in which bit strings are written in this Recommendation | International Standard. Bit strings are written as a string of 1s and 0s within single quote marks, e.g. '1000 0001'. Blanks within a bit string are for ease of reading and have no significance.
ch Channel
gr Granule of 3 * 32 sub-band samples in audio Layer II, 18 * 32 sub-band samples in audio Layer III.
main_data The main_data portion of the bit stream contains the scale factors, Huffman encoded data, and ancillary information.
main_data_beg This gives the location in the bit stream of the beginning of the main_data for the frame. The location is equal to the ending location of the previous frame's main_data plus 1 bit. It is calculated from the main_data_end value of the previous frame.
part2_length This value contains the number of main_data bits used for scale factors
rpchof Remainder polynomial coefficients, highest order first
sb Sub-band
scfsi Scalefactor selector information
switch_point_l Number of scalefactor band (long block scalefactor band) from which point on window switching is used
switch_point_s Number of scalefactor band (short block scalefactor band) from which point on window switching is used
tcimsbf Two's complement integer, msb (sign) bit first
uimsbf Unsigned integer, most significant bit first
vlclbf Variable length code, left bit first, where "left" refers to the order in which the variable length codes are written
window Number of actual time slot in case of block_type = = 2, 0 <= window <= 2.
The bit streams retrieved by the decoder are described in 2.4.1 and 2.5.1. Each data item in the bit stream is in bold type. It is described by its name, its length in bits, and a mnemonic for its type and order of transmission.
The action caused by a decoded data element in a bit stream depends on the value of that data element and on data elements previously decoded. The decoding of the data elements and definition of the state variables used in their decoding are described in the clauses containing the semantic description of the syntax. The following constructs are used to express the conditions when data elements are present, and are in normal type.
Note this syntax uses the "C"-code convention that a variable or expression evaluating to a non-zero value is equivalent to a condition that is true:
|
while ( condition ) {
data_element . . . } |
If the condition is true, then the group of data elements occurs next in the data stream. This repeats until the condition is not true. |
|
do { data_element . . . } while ( condition ) |
The data element always occurs at least once. The data element is repeated until the condition is not true. |
|
if ( condition ) { data_element . . . } |
If the condition is true, then the first group of data elements occurs next in the data stream. |
|
else { data_element . . . } |
If the condition is not true, then the second group of data elements occurs next in the data stream. |
|
for (i = 0; i < n; i+ +) { data_element . . . } |
The group of data elements occurs n times. Conditional constructs within the group of data elements may depend on the value of the loop control variable i, which is set to zero for the first occurrence, incremented to 1 for the second occurrence, and so forth. |
| As noted, the group of data elements may contain nested conditional constructs. For compactness, the {} are omitted when only one data element follows: | |
|---|---|
| data_element[] | data_element [] is an array of data. The number of data elements is indicated by the context. |
| data_element [n] | data_element [n] is the n+1th element of an array of data. |
| data_element [m][n] | data_element [m][n] is the m+1,n+1th element of a two-dimensional array of data. |
| data_element [l][m][n] | data_element [l][m][n] is the l+1,m+1,n+1th element of a three-dimensional array of data. |
| data_element [m..n] | is the inclusive range of bits between bit m and bit n in the data_element. |
We had a talk with couple of people, involved in the project, on how a demultiplexer-multiplixer library is going to be organized.
Demultiplexer is to parse MPTS down to tables (PAT, PMT, SDT, TOT, etc) and elementary streams. It will have an interface to provide all the information about the stream and also able to accept callback procedure hooks which are to be called whenever a new PES arrives.
As for now, we're implementing readers/writers of standard tables, that is, reader gets bitstream and forms a structurized data of a table, and a writer, vice versa, takes that structurized table data and forms a bitstream to put into new MPTS as the multiplexer's output.
→ Presented the topic of my work.
→ To be honest, I'm not hugely comptetent in it, so I got many questions I couldn't answer. But I believe an advantage of such an approach (when I get new topic almost every two months) is that I never get time to be bored because I got nothing to do :)
→ I also videotaped my performance.
Prepared slides for tomorrow's presentation.
Ivan Yurlagin, 