Traitement informatique d'un flux MPEG2 pour analyse

Traitement informatique d'un flux MPEG2 pour analyse - Traitement Audio - Video & Son

Marsh Posté le 03-02-2009 à 16:42:46    

Bonjour,
 
Apres lecture de la norme ISO IEC 13818-1, mon projet est de faire un analyseur de buffer audio pour flux MPEG2. Mais voici le probleme que je rencontre (desole c'est en anglais... je l'ai redige pour des forum anglais car il y a plus de documentation dans cette langue :)
 
Hello,
 
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.
 

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


According to the norm:
- 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?
- 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…
 
Leo
 
 
 
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.lotr?ct=PS&lc=EN&ci=13266&cs=psu)
- Rohde and Schwarz Video and TV Generators and Analysers DVM Family (http://www2.rohde-schwarz.com/en/products/test_and_measurement/product_categories/video_tv/digital_baseband_analysis/?pcat=rsproduct&pid=2340&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/)
      -     VLC and its Developers Wiki (http://wiki.videolan.org/Developers_Corner)
      -     Java Media Framework (http://java.sun.com/javase/technologies/desktop/media/jmf/)
 
 
 

Reply

Marsh Posté le 03-02-2009 à 16:42:46   

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed