Debugage de DemuxPSI. Le nouveau code doit etre capable de gerer des cas
foireux qui ne sont pas senses arriver (et qui n'ont jamais ete rencontre
dans les flux qu'on a, vu que ca n'a jamais plante la avant). Son
principal interet est de ne plus produire de warning a la compilation :)
Benny
- Suppression totale de la synchro en dates absolues ;
- Rajout de la re-synchro en dates relatives (il est donc d�sormais
possible de couper un flux et de le relancer, ou de changer de flux,
tout en gardant le m�me input, le m�me d�codeur audio... pratique pour
le pseudo-changement de cha�ne pr�vu � la War :-) ;
--
MaXX
- Correction de deux bugs concernant le calcul de b_has_pts et d'une autre
variable de la structure pes (les masques utilis�s n'�taient pas les bons...
cons�quence imm�diate : la synchro ne voyait jamais de paquet dat�) ;
- Correction d'un bug de la m�thode de calcul de i_pts ;
* audio_decoder/audio_decoder.c :
- Autod�tection des dates en utilisant le champ i_pts fourni par la
synchro... le son � fr�quence variable adapt�e aux pertes de paquets TS et
autres probl�mes est d�sormais une r�alit� :-)
* audio_output/audio_output.c :
+ Rajout de la synchro :
- On attend si on est en avance ;
- On saute des frames si on est en retard ;
+ Ce n'est pas encore tout � fait �a, mais �a commence � prendre forme...
On dirait que le mini-server va trop vite, parce que l'audio est souvent
en retard... Polux ?
* Makefile :
- Modifications cosm�tiques ;
--
MaXX
- Rajout du support permettant de d�tecter la fin du thread input
correspondant au flux de bits pass� en argument � la fonction GetByte ;
* input/input.c :
- Changements cosm�tiques ;
* input/input_psi.c :
- Correction d'un bug de la fonction DestroyPgrmDescr qui faisait
segfaulter le vlc � sa terminaison ;
* audio_decoder/audio_decoder.c :
* generic_decoder/generic_decoder.c :
* video_decoder/video_decoder.c :
- Les fonctions xdec_DestroyThread envoient d�sormais un signal permettant
aux decoder threads de quitter la fonction GetByte meme s'ils sont en
attente dans la fonction pthread_cond_wait ;
--
MaXX
- Rajout de l'option -pg maintenant que le %*!&#@ de bug est corrig�, et en
attendant qu'on trouve le moyen de releaser proprement le lock des
decoder_fifos :-)
* audio_decoder/audio_decoder.c :
- Correction d'un bug qui entrainait une d�rivation du son ;
* include/audio_output.h :
- Passage du nb max de fifos audio de 4 � 2 pour augmenter le niveau sonore ;
* interface/main.c :
- Typo ;
--
MaXX
- Correction d'un bug de la fonction input_PcrReInit : pthread_mutex_lock()
�tait appel�e avec un argument obtenu en d�r�f�ren�ant un pointeur non
initialis� ;
- Le bug ne survenait que lorsque le vlc �tait compil� SANS -Ox, probablement
parce que le code optimis� n'ex�cutait pas les instructions dans le meme
ordre ;
-- MaXX
- mtime_t devient un s64 (et non plus un u64) pour harmoniser gestion de
l'horloge et synchronisation ;
- LAST_MDATE correspond d�sormais � la plus grande valeur que peut
prendre un s64 ;
- MSTRTIME_MAX_SIZE prend en compte le fait que les dates peuvent d�sormais
�tre n�gatives ;
* misc/mtime.c :
- modifications diverses et vari�es prenant en compte le changement de
mtime_t ;
* include/input.h :
- i_pts et les variables s64 de la structure pcr sont d�sormais des mtime_t ;
* input/input.c :
- passage des casts en (mtime_t) et non (s64) ;
* input/input_file.c :
- rajout d'un #include "mtime.h" ;
* input/input_pcr.c :
- passage des s64 en mtime_t ;
* misc/xutils.c :
- correction de deux warnings ;
-- MaXX
- Proprification des commentaires ;
* include/input.h :
- i_pts �tait un u32 mais doit �tre un s64 ;
- Question ouverte au Ptyx : pourquoi mtime_t est un u64 ?
Est-ce que c'est mauvais de passer mtime_t en s64 ?
Est-ce que �a fait modifier beaucoup de code ?
* input/input.c :
- Correction d'un cast ;
-- MaXX
- Int�gration totale et non comment�e du support de la synchro ;
- Le probl�me du 0.1% de CPU -> 9.7% est r�solu en compilant avec un
flag d'optimisation (cf ci-dessous) ;
* Makefile :
- Rajout d'une ligne *comment�e* avec le flag d'optimisation -O2 ;
- En -O2 et en faisant tourner le mini-server et un vlc --novideo sur la
meme machine, la somme des %CPU du vlc et du mini-server est �gale � 0 :-)
C'est pas beau �a ?
-- MaXX "vlc rewlz"
- Tout est pret pour accueillir la synchro :-)
- Les passages modifi�s sont encore en commentaire, parce qu'avec ma
synchro simul�e le %CPU du d�codeur audio passe de 0.1% � 9.7%, alors
que les op�rations sont toutes simples et pas appel�es tant que �a
(il faudra encore essayer en -Oqqch si �a change qqch) ;
- Reste � modifier l'audio output pour la synchro... coming soon ;
-- MaXX
- Correction d'une erreur dans la taille des frames du Layer II (1152
et non 1192) (ne vous en faites pas, l'erreur n'�tait pr�sente que dans
un commentaire :-) ;
* audio_decoder/audio_decoder.c :
- Rajout d'un certain nombre de commentaires utiles pour la suite du
d�veloppement de l'audio_decoder ;
- Modification de la m�thode de calcul du nombre de frames audio libres
dans l'aout_fifo (� tester !) ;
-- MaXX
* Au d�marrage l'interface lance le script contenu dans vlc.init s'il
existe (typiquement spawnage d'input) ;
* Le d�codeur PSI spawne automatiquement les threads video et audio des
qu'il a fini ;
[les deux pr�c�dents comportements peuvent �tre d�sactiv�s en
commentant #define AUTO_SPAWN dans config.h]
* Correction d'un bug de compilation dans input_pcr.c
--Meuuh
Jean-Marc Dressler