My project is to develop a software which allows to check the functioning of MPEG2 audio buffers while decoding process, in accordance to ISO IEC 13818-1 standard. So the main purpose is to check how works the data flow into audio buffers, and to detect underflow and overflow. The software has to work only with TS (Transport Stream) streams, with MPEG2 Audio coding (ISO 13818-3) only.
This software is not a live analyser, it has to make only off line analyses on a recorded stream (so on a file). So the time of process is not a constraint, although it must simulate a decoding time management, in order to detect any problems. The final information produced by software is trends and errors reports (not decoding).
I read the ISO IEC 13818-1 norm (MPEG2 System). But that raised many questions and I have to find answers before starting to code.
ISO norm give a theoretical method to implement time management while decoding. It’s the T-STD method (Transport Stream System Target Decoder). T-STD is designed to give an overview of the functioning and to help manufacturers and developers: it’s not a mandatory implementation way.
Here is what I understood about ISO norm and T-STD.
Code: Select all
What is transferred:
What is Full TS packets (from TS stream) Audio Elementary Stream Audio Access Unit
transferred: which contains PID which so PES packets extracted so ES stream extracted
refer to audio stream from TS packets payload from PES packets payload
(after PSI analyse) | |
| | |
----------------- -------------------------------- --------------------------
| | | | |
V | v | v
--------- --------- |\_
| | | | | \_
| TB | 512 bytes | B | 3584 bytes | D _>
| | | | | _ /
--------- --------- |/
^ | ^ | ^
| | | | |
---------------- -------------------------------- --------------------------
| | |
How it’s Bit rare extracted from Rxn = 2 Mb/s Decoding instant extracted
transferred: PCR value extracted from from DTS timestamps which are
TS packets which contain PID contained in PES packets
which refer to audio stream
-or-
Bit rate extracted from PSI information
TB: Transport Buffer
B: Elementary Buffer
D: Decoding Buffer- the decoder works properly if TB is never on overflow and B is never on overflow or underflow (it’s what the software must detect)
- the reference system clock of coder and decoder is based on 27 MHz
- PCR values are parts of this clock (so based on 27 MHz)
- PTS/DTS timestamps values are based on the same clock, but are just parts of 90 kHz
With this diagram and theses information, here is how the software might run (from my conclusions):
- two queues (for example InputStream class in Java code) simulate TB and B. No need to simulate D.
- a wide loop (“while” code) simulate each clock cycles (so 27 000 000 iterations for a whole second)
- for each loop iteration, a set of tests (“if” code) decide what must happen. For example:
o The bit rate between TB and B is 2 Mb/s. Therefore, each 13 iterations, one byte must be dropped from TB queue and put into B queue.
o B contains PES packets with DTS timestamps. For each iteration, if the cycle value of the iteration is equal to DTS timestamp contained into PES packets, concerned PES packets are dropped from B and put into D (D is no represented in the software, so PES packets are discarded)
o For each iteration, a control of busy size in TB and B is made, to detect overflow and underflow.
Also, it’s seems to be possible to simulate a no-live time management for audio decoding (the process maybe the same for video and system information decoding but that is beyond the scope of the software).
Although, many questions are still without replies:
- Because of the TS stream is a file and the software is not a live application, what is the bit rate for filling TB buffer?
o Must that be find out through PCR values, with transport_rate equation (see 2-5 equation into norm)?
o Must that be find out through PSI information (for example from audio_stream_descriptor, see 2-48 table into norm)?
- Because of the PTS/DTS timestamps are some 90 kHz unities, the main loop of the software has to simulate a 27 MHz clock or a 90 kHz clock?
- The norm specifies that Elementary Buffer B must not be in underflow. But the drain of the B buffer is guided by DTS values contained into B. If B is empty, how it can become in underflow (nothing to extract because no PES and associated DTS)? Is Decoder Buffer D applying a bit rate constraint?
- Here is a screenshot of an existing application which analyse audio buffers:
In this case, B buffer start to be on underflow at about 10 ms. How is it possible, if only DTS values contained in PES packets controls the drain of B?
In this case, how is it possible to start process with an already underflow B buffer?
- In PES packets, there is some ESCR values (Elementary Stream System Clock Reference). Is it usefull for TS stream decoding? What is its sense for the time management?
I’ve got other questions, but maybe they will find answers after replies on above problems.
Thanks a lot to correct me on my conclusions about ISO norm, and also to reply to my questions…
Dazdh
For information, several applications make already this process, as:
- Interra Systems Vega Analyser (http://www.interrasystems.com/dms/dms_vega.php)
- Tektronix MTS400 Series MPEG Analysis (http://www2.tek.com/cmswpt/psdetails.lo ... 266&cs=psu)
- Rohde and Schwarz Video and TV Generators and Analysers DVM Family (http://www2.rohde-schwarz.com/en/produc ... pnodeid=71)
I didn’t find out in open source world any issue or software about T-STD and time management. There are only one-block encoders/decoders, like:
- libmpeg2 (http://libmpeg2.sourceforge.net/)
- Java Media Framework (http://java.sun.com/javase/technologies ... media/jmf/)
