Discussion :

[Dazdh]

Bonjour,

Mon projet est de developper un anaylseur de flux DVB. Le DVB est un ensemble de normes dediees a la television et la video numerique (utilise dans les DVD, la TNT, la tele par satellite, etc...). Mon projet est plus exactement une analyse du contenu audio des flux TS (si ca vous dit quelque chose . Jai comme langage impose le C#, mais je suis ouvert a toutes infos dans nimporte quel autre langage et environnement de developpement.

Connaissez vous des API, quel que soit le langage, qui permettent de traiter des flux DVB, MPEG, ... ?
Connaissez vous des sites Web (FR ou EN) specialise dans le developpement oriente vers le DVB?
Connaissez toute autre source dinformations pouvant me guider et maider dans du developpement DVB?

Merci pour avance,

Leo

[moldavi]

Bonjour.

Dans un environnement windows, tu as DirectShow. Je te conseillerai le C++ comme langage de développement, car les exemples que tu trouveras seront majoritairement dans ce langage.

http://moldavi.developpez.com/tutorial/diretcshow1/

Par contre, pour l'acquisition satellite, DirectShow c'est un peu galère (niveau exemple et utilisation), mais il n'y a pas grand chose d'autre...

[shenron666]

je ne sais pas si c'est possible dans ton cas d'utiliser la bibliothèque OpenCV

[Dazdh]

Merci pour vos reponses.

En faisant des recherches dans tous les sens, je pense que ma premiere etapes avant de me lancer dans la programmation va etre une analyse complete des normes ISO 13818-1 -2 -3... Mais je garde vos conseils.

A propos de ces normes (MPEG general, MPEG video, MPEG audio), savait vous ou je pourrais trouver un peu daide, des tutoriels, bref des base de connaissances plus simple que les normes elle memes?

[Mat.M]

Salut Dazdh j'ai bossé dans une start-up sur un projet de récepteur de programmes par satellites je pense que c'est similaire à ton projet.
La carte de réception satellite proposait des filtres DirectShow je conseille aussi et fortement de programmer en C++.
Ce que je devais faire c'était programmer une sorte de "player" de chaines satellites.
Donc je devais programmer les filtres .ax/DirectShow de la carte selon la fréquence ,FEC,polarité et des paramètres dont je ne me souviens plus
Et puis faire le rendu dans une fenêtre Windows.

Mais Direct Show c'est un peu une boite noire tu peux pas controler ce qu'i y a dedans à moins de programmer des filtres .ax
As tu regardé sur www.dvb.org ?
Difficile de trouver de la doc sur ce site il faut peut-être s'enregistrer..
Pour la doc c'est très difficile à trouver si ce n'est quelques bouquins..

Connaissez vous des API, quel que soit le langage, qui permettent de traiter des flux DVB, MPEG, ... ?
Leo

Pour le flux c'est en amont évidemment avant la décompression MPEG..
donc je dirais que cela peut-être en fonction de la carte de réception qui donne le flux.
Avec le SDK de la carte de réception satellite avec laquelle je bossais il y avait un SDK et donc un filtre .ax /des méthodes C++ qui pouvaient donner le flux brut...
Pour la décompression MPEG il suffit de prendre les filtres DirectShow.
Donc tu devras probablement écrire un filtre qui lit et traite le flux reçu par la carte et trouver les bonnes connections vers un filtre de décompression MPEG de DShow.
Cela peut se faire avec GraphEdit..

[Dazdh]

Merci pour ces reponses.

En fait, je nai pas du tout le controle sur la carte de reception, etc...

Le materiel "brut" que l'on me fournit, c'est des fichiers .ts (flux de paquets TS) qui sortent dun encodeur MPEG (ce sont en fait ces donnees brutes qui sont transmises telle quelle sur satellite, cable, etc...).

Mon projet est danalyser ce fichier et d'en sortir clairement tous les elements. Cela semble simple puisque les paquets TS contenus dans le fichier .ts ont une longueur fixe de 188 octets et que jai trouve leur structure sur le net (protocole MPEG). Il suffirait donc de lire chaque groupe de 188 octets du fichier, et pour chacun determiner par exemple l'ID (octet 0 a 2), le PAYLOAD (octet 3 a 10, ...), en faisait une lecture bit a bit ou octet a octet en C#.

Le probleme est que jai tres peu dinfos precises sur la structure de ces paquets, et notemment comment est gere le buffer audio a l'interieur... (surtout que certains paquets peuvent avoir une longueur variable). C'est donc dans ce domaine exactement que je cherche activement de l'info. Jai bien les normes 13818-1 -2 -3 mais c'est particulierement indigeste et mon anglais nest pas tres bon...

Saurais tu ou je peux chercher tout ca ?

Merci

Leo

[Mat.M]

Hello Dazdh je le redis c'est pas facile de trouver de la doc dessus et moi-même je ne pourrais pas trop t'aider là-dessus
Je me souviens que pour lire le flux il y a des tables CAT je crois qui sont les catégories de programmes ainsi que d'autres tables.
Est-ce que tu as regardé le site dvb.org normalement les normes sont dessus ?
Tu m'as parlé d'une norme en principe il n'ya pas d'autres documents.
Peut-être regarde autour du libre et des outils linux je me souviens être tombé sur un code source pour Linux qui décryptait les tables.
Regarde aussi peut-être sur sourceforge.net il y a peut-être des projets sur la DVB.

[Dazdh]

Oui, jai trouve plusieurs projets libre pour le decodage de flux TS, dont certains vraiment tres puissants. Cependant, la pluspart s arrete au decodage du paquet TS, et ne vont pas jusqua lanalyse des buffers.

Lacces aux normes ISO est-il forcement payant?

[moldavi]

Bonjour.

Le format mpeg2 est très complexe et les spécifications sont payantes.

Par contre tu as une implémentation libre de ce format : la libmpeg2 (sourceforge). Elle n'implémente pas toutes les spécifications. Pour la partie audio, virtualdub mpeg2 devrait contenir les sources pour le démultiplexage.

bon courage...

PS: si tu dois implémenter tout cela en temps réel, alors ce sera avec un filtre directshow (gplmpgdec comme exemple, toujours sur sourceforge).

[Dazdh]

Merci pour ces conseils.

En effet, libmpeg2 en C est tres interessante... Je vais creuser de ce cote la. Mais elle est tres mal documentee.

Que pense tu de l'API Java Java Media Framework (JMF)? Pour du MPEG 2 (flux TS) c'est est pas bon non ?(selon cette page: http://java.sun.com/javase/technolog...1/formats.html)

Merci.

[moldavi]

Bonjour.

Dans ton lien, je ne vois aucune référence au MPEG2.

[Dazdh]

Bonjour,

Jai maintenant plus d'information sur ce que je voudrais implementer. Il s'agit du VBV (Video Buffer Verifier), cest un decodeur logique (uniquement pour faire des test) qui permet de detecter les overflow et les underflow lors du decodage des flux TS. Jai aussi vu une autre methode, ou un protocole (je ne sais pas bien ce dont il s'agit) qui s'apelle T-STD (Transport Stream Target Decoder).

Connaissez vous, dans des librairies existantes (VLC, libmpeg2, DirectShow, ...), des concepts se referant a tout ca? Et un endroit ou je peux trouver de la doc sur ces sujets?

A ce propos, j'ai trouve un lien tres interessant, il s'agit d'un tutorial sur le MPEG2 (http://www.bretl.com/mpeghtml/MPEGindex.htm) (Pour ceux que ca interesse).

Merci

[Dazdh]

Bonjour,

Ca y est jai fait quelques recherches plus precices. Il s'agit d'implementer la methode T-STD (Transport Stream System Target Decoder), qui permet de simuler un decodeur et de verifier la presence ou non dunderflow et doverflow dans les buffers. Je n'ai absolument rien trouve sur le net... Avez vous des infos concernant une implementation de cette methode?

Merci

[Dazdh]

Bonjour,

Apres de tres nombreuses recherches et surtout apres lecture de la norme ISO 13818-1 j'ai reussi a modeliser mon probleme de maniere claire. Je vous le livre donc tel que je l'ai redige (en anglais car je l'ai poste aussi sur des forums en anglais).

Merci de me donner votre opinion sur ce probleme, et si vous pouvez de m'aider a le resoudre!

Dazdh

-----------------------------

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
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?
- Here is a screenshot of an existing application which analyse audio buffers:
//see f1.jpg
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?
// see f2.jpg
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...i=13266&cs=psu)
- Rohde and Schwarz Video and TV Generators and Analysers DVM Family (http://www2.rohde-schwarz.com/en/pro...340&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/technolog...top/media/jmf/)