Lundi 21 septembre 2009

J’ai continué à chercher des codecs qui pourrait être utilisables sous Windows. J’ai donc effectué plusieurs tests et voici les conclusions pour le moment :

X264 : n’est pas stable sous Windows
WMV1 : OK sous Windows et Linux => 300 kbps en moyenne. Le caps est déterminé par la taille de la vidéo et son framerate, sinon le reste est fixe
WMV2 : De même que ci-dessus. LE caps est à peine plus compliqué. Il y a un élément codec_data=(buffer)XXXX qui semble ne pas changer, mais je ne sais pas à quoi cela correspond.

Nicolas H. m’a demandé de tester d’encoder avec x264enc et de décoder avec ffdec_mpeg4 pour éviter d’utiliser ffdec_h264 qui plante sous Windows. Malheureusement cela ne fonctionne pas.

J’ai voulu contacter Andoni Morale pour discuter du codec Speex. Malheureusement le forum où nous avons l’habitude de discuter ne fonctionnait pas. Je tenterai demain…

Publicités

Jeudi 17 septembre 2009 et Vendredi 18 septembre 2009

J’ai pu terminé la gestion de fichiers properties : maintenant on gère la taille de la fenêtre, le thème graphique, ainsi que la position du splitPane.

J’ai intégré et testé plusieurs codecs que l’on aimerait mettre à l’épreuve sous Windows. Malheureusement, je n’arrive à faire fonctionner que X264. Et encore, après un certain laps de temps l’application plante à cause de ce codec.
J’aimerais payloader certains codecs, mais parfois on a pas de payloader adéquats. Donc on se trouve dans une certaine impasse.

Je discuterai avec l’équipe pour voir ce que nous allons donc faire .

Mercredi 16 septembre

Avec Nicolas R. nous avons décidé d’abandonner l’adaptation de sa bibliothèque pour le moment. Nous ferons ceci plus tard.

J’ai continué à gérer les propriétés. On gère la taille de la frame, bientot le lookAndFeel. Mais je rencontre un petit souci pour le SplitPane. J’en parlerai avec l’équipe.

Mardi 15 septembre 2009

J’ai continué à chercher toute la journée pour quelle raison le flux est si pixelisé, si mauvais. Mais je ne vois pas pourquoi puisuqe je force le format qui est censé être de bonne qualité.

Si possible, j’aimerais discuter avec Nicolas R. pour voir s’il a une idée du pourquoi de ce problème.

Lundi 14 septembre 2009

Les derniers jours, je me suis entrainé et j’ai préparé ma soutenance qui s’est déroulée vendredi après midi.

Aujourd’hui, j’ai continué à adapter la bibliothèque de Nicolas R. à mon code. Je reçois bien les flux, mais ils sont de très mauvais qualité. J’essaye donc de réparer ce souci.

J’ai aussi continué quelque peu la gestion des properties.

Mercredi 9 septembre 2009

Ce matin, après avoir réglé un problème sur ma machine qui m’empêchait de travailler et qui m’a bloqué, j’ai pu changer plusieurs choses au niveau graphique : les onglets sont maintenant renommés, certains éléments sont masqués, les boutons sont plus grand pour créer une certaine harmonie dans la taille des cadres de l’application.

Cet après midi, je me suis surtout préparé pour les soutenances de jeudi et vendredi qui se dérouleront respectivement devant le service où j’ai effectué le stage et devant les professeurs de l’école. La préparation a consisté en l’installation du matériel, entraînement à l’oral, et test de l’application.

Mardi 8 septembre 2009

J’ai pu régler plusieurs problèmes de comportement au niveau des panels quand on clique sur les boutons « send », « receive », « forward » : certains éléments ne sont plus visibles, un d’entre eux est sélectionné au démarrage de l’application.

J’ai corrigé le fameux bug en émission qui empêchait de recevoir un flux vidéo si une webcam n’était pas branchée sur l’ordinateur.

Le panneau de gestion du son a été revisité : notamment les boutons « mute » qui ont été ajoutés.

Je suis aussi allé au showroom, faire plusieurs tests en prévision des soutenances orales de jeudi et vendredi. L’application fonctionne correctement !

Lundi 7 septembre 2009

J’ai pu corriger un bug qui survenait lorsqu’on décidait de couper le streaming et puis de le relancer.

Puis j’ai arrangé l’interface graphique qui ne doit plus qu’être validée par Nicolas. J’ai pu ajouter des icônes, modifier la taille des champs, par exemple.

J’ai commencé à gérer un fichier properties qui stockera plusieurs informations utiles.

Vendredi 4 septembre 2009

J’ai continué l’intégration de la librairie de Nicolas R. dans mon code. Nous nous sommes rendus compte d’un problème lors du streaming en RTP avec une interface Swing. Alors nous nous concentrons pour le moment sur le streaming en UDP.

Nous avons déjà réussi à streamer un fichier vidéo, avec gestion des paramètres. Néanmoins, la réception n’est pas fluide nous travaillons donc sur ce point avant de se lancer dans le streaming de flux issus de la  webcam et du micro.

Jeudi 3 septembre 2009

Ce matin, j’ai pu résoudre le problème concernant le streaming UDP. Le problème venait des paramètres « sync=false async=false » qui n’étaient pas spécifiés pour les éléments Udpsink. Et puis j’ai rajouté les payloaders/depayloaders.

Puis, nous voulions testers plusieurs codecs sous Windows. Le problème est que notre application ne gère que les caps « classiques ». Nous avons donc choisi d’utiliser pour le moment la bibliothèque de Nicolas R. pour faire ces tests.

C’est ce que nous avons fait cet après midi, poru cela nous avons remanié le code et j’ai du comprendre comment fonctionne cette blbliothèque.

Mercredi 2 septembre 2009

Nous avons établi une liste d’encodeurs et décodeurs disponible dans la version 0.10.4 de windows. Nous allons tester par la suite ces codecs pour établir un comparatif.

J’ai pu mettre en place la sauvegarde des flux en réception (quand on streame avec la webcam, ou un fichier vidéo). Cette fonctionnalité marche plutôt bien si on ne streame pas sur le même PC, sinon on observe un décalage entre la vidéo et le son qui se creuse.

Le panel de cette fonctionnalité a été un peu arrangé. On peut maintenant passer un chemin et un nom de fichier sans spécifier l’extension qui auquel cas se rajoute automatiquement.

J’ai remarqué un problème dans le streaming UDP de la webcam : cela ne fonctionne plus. J’essaye donc de résoudre ce problème.

Mardi 1er septembre 2009

J’ai aidé Nicolas R. a trouver un codec audio et vidéo qui fonctionnaient ensemble sous Windows. Finalement nous avons opté pour le choix FLV/MP2 ou FLV/ALAW. Le streaming plante parfois sous windows : il faut spécifier le buffer-size dans ces cas là.

J’ai aussi laissé faire des tests à Marlène sur ma machine concernant son projet.

De mon coté, j’ai implémenté le Panel qui va permettre à l’utilisateur de choisir d’enregistrer le flux ou non. Le panel s’affiche mal pour le moment. Mais, j’ai plutôt travaillé sur les pipelines pour faire cela.

Quand on enregistre le flux webcam/micro cela fonctionne plutot bien. Quand on enregistre le flux d’un fichier vidéo, la vidéo résultante est plutot saccadée. J’essaye donc de corriger ce souci.

Lundi 31 août 2009

Il est maintenant possible de choisir si l’on veut streamer la partie audio et ou la partie vidéo d’un fichier. Et de même dans le cas de la réception.

De plus, j’ai pu corriger un bug dans la gestion des paramètres relatifs aux devices (Webcam et micro). Ce bug est survenu quand j’ai rajouté le panneau d’envoie de fichier.

J’ai aussi aidé Nicolas R. dans ses tests pour l’application de travail collaboratif. Et nous avons cherché un codec audio et un codec vidéo qui fonctionnait suffisament sous Windows.

Vendredi 28 août 2009

Le problème du décalage de son a été réglé ! C’était un problème d’audio rate mal géré.

Les paramètres du panel de streaming vidéo se grisent quand on streame. Quand on charge un profil, le panel est aussi reloadé.

La fonctionnalité streaming de fichier vidéo permet de spécifier l’audio rate et le framerate. Il est à noter qu’avec ma version (la 0.10.22 un warning apparait, alors qu’avec la 0.10.24 non).

Ainsi on a un streaming qui fonctionne plutôt bien.

Ce qu’il reste à faire sur cette application :

– Permettre de choisir si on veut streamer l’audio et/ou la vidéo d’un fichier

– Effectuer quelques petites modifications sur l’interface

– Permettre de sauvegarder dans un fichier le flux que l’on reçoit

-Refaire un tour des fonctionnalités et TESTER LES CODECS !

Jeudi 27 août 2009

L’implémentation du streaming de fichier UDP et RTP est quasiment terminée.

Il reste néanmoins un petit problème de son, mais j’ai décidé de ne pas perdre de temps là dessus (ça fait déjà plusieurs jours que je travaille sur ça). On peut donc streamer le fichier ogg de notre choix à plusieurs destinataires.

J’ai remarqué quelques bugs qui étaient apparu quand j’ai rajouté le bouton radio pour choisir la source à streamer et je les ai corrigés.

J’ai rajouté les paramètres pour indiquer la taille de la vidéo que l’on veut envoyer, ainsi que l’audio rate et les ai pris en compte dans la pipeline.

Il me reste donc à griser les éléments quand on commence à streamer, et permettre de reloader correctement le panel si on charge un nouveau profil.

Puis je pourrai passer à l’amélioration de tous les petits problèmes graphiques qu’on a pu constater avec Nicolas R.

Mercredi 26 août 2009

J’ai commencé la fonctionnalité de streaming de fichier en UDP.

Je reçois correctement la vidéo et l’audio. Malheureusement le son est très mauvais.

J’essaye de résoudre ce problème en testant plusieurs pipelines.

Mardi 25 août 2009

Le son est maintenant récupéré avec une bonne qualité (pas avec le profil qui est chargé au départ, qui est un profil optimisé pour la voix). Malheureusement la vidéo et le son sont décalés entre eux. J’ai cherché plusieurs moyens pour résoudre ce problème.

Le meilleur semble être de muxer la vidéo et le son. Mais si on essaye de faire ceci on se heurte à un problème. Par exemple il n’y a aucun muxer qui accepte du H264 et du Speex en entrée. L’application est censée recevoir n’importe quel codec. Et pourtant il n’y a pas toujours de muxer adéquat. Alors avec Nicolas R., nous avons décidé de laisser le streaming de telle façon en RTP.

J’ai pris le temps de bien découper le code, ajouter la gestion du volume, et bien sûr prendre en compte l’envoi à de multiples destinataires.

Cela semble fonctionner : difficile d’écouter le son sur plusieurs récepteurs sur la même machine. Niveau vidéo, tout est correct.

Demain je m’attaquerai à l’envoi via UDP qui semble plus optimisé.

Lundi 24 août 2009

J’ai finalement trouvé le problème dans le récepteur de vidéo. En fait, le caps doit être encadré par des double-cotes plutôt que par des simple-cotes. Sinon cela fonctionne très bien en ligne de commande mais pas avec Java GStreamer. Petite subtilité à connaître…

J’ai donc réussi à recevoir l’audio et la vidéo. Cependant, on ressent de fort problème de synchronisation audio. Avec Alaw notamment. Vorbis lui demande un long caps pour pouvoir être vraiment décodé. Avec Speex, on rencontre beaucoup moins de problème, mais à un certain moment il y a une telle désynchronisation que on ne reçoit plus de son. J’essaye donc de résoudre ce problème. Bien sûr j’ai testé ceci avec une vidéo relativement grande.

La vidéo en question :

Poids : 19,2 Mo

Temps : 4 minutes 28 secondes

Dimensions 480 x 360

Débit Vidéo : 450 kbps

Débit Audio : 64 kbps

Vendredi 21 août 2009

Le bug UDP a été corrigé. En fait, si on décidait de changer de façon de streamer en ayant déjà rajouté des destinataires, il y avait un mélange.

J’ai commencé à remanier dans mon code la partie streaming de fichier vidéo.

Puis, j’ai commencé à chercher la pipeline qui permet la réception. Etrangement, (encore une fois) elle fonctionne en ligne de commande mais pas avec Java GStreamer. J’essaye donc de résoudre ce problème. Une fois résolu, le streaming de fichier vidéo sera presque terminé : les modifications seront principalement à faire au niveau de la qualité du code.

Jeudi 20 août 2009

Nicolas R. m’a aidé à trouver le problème. En fait, il faut absolument rajouter un sync=false async=false à l’élément udpsink pour pouvoir recevoir le flux vidéo.

A partir de là, on voit très bien la vidéo que l’on streame. J’ai commencé à modifier la GUI pour faciliter à l’utilisateur le choix de la source vidéo.

Mais je me suis rendu compte d’un bug lors du streaming en UDP que j’ai commencé à corriger.

Mercredi 19 août 2009

J’ai continué de chercher d’où venait le problème quand on ajoute la commande pour envoyer la vidéo. Je ne trouve pas pourquoi cela ne fonctionne pas avec Java contrairement en ligne de commande.

Après avoir discuté avec Nicolas R., je pense utiliser sa méthode pour gérer ce type de tâche. J’ai donc cherché dans son code comment il réalisait ceci.

Demain, j’en discuterai avec lui de visu pour pouvoir terminer cette fonctionnalité avant la fin de la semaine.

Mardi 18 août 2009

J’ai continué de travailler sur la pipeline qui me pose problème. En ligne de commande elle fonctionne puisque j’arrive à afficher la vidéo et à entendre le son.

En modifiant la pipeline et en commentant la partie gestion des paquets RTP/RTCP, j’ai réussi à jouer la vidéo dans mon application.

Si je rajoute la première ligne censée envoyer le flux vidéo à mon destinataire, plus rien ne fonctionne.

Il y a donc eu un progrès dans cette fonctionnalité mais tout n’est pas au point. J’essaye donc de comprendre pourquoi.

Lundi 17 août 2009

Après une bonne remise dans le bain, j’ai essayé de comprendre pourquoi la pipeline ne fonctionne pas avec Java GStreamer. J’ai essayé plusieurs méthodes, mais je n’obtiens ni l’image ni le son.

J’ai essayé de récupérer l’élément ffmpegcolorspace, le videoTee avec aucun des deux je n’y arrive. Même en liant un queue créé à la main ou non. J’ai essayé de modifier la pipeline mais rien n’y fait.

Vendredi 24 juillet 2009

Avec l’aide Nicolas R., j’ai pu trouver une pipeline qui fonctionne en ligne de commande et qui permet de traiter la vidéo et le son. Puis j’ai rajouté tous les bouts de pipeline qui concernent le protcole RTP et RTCP. Et cela fonctionne.

Puis, j’ai commencé à l’adapter dans Java GStreamer mais ni l’image ni le son ne fonctionnent. J’ai donc cherché à comprendre pourquoi cela ne marchait pas.

Aujourd’hui commencent les vacances. Je serai donc de retour le 17 août 2009.

Bonnes vacances à tous !

Jeudi 23 juillet 2009

J’ai travaillé toute la journée sur cette pipeline qui me pose toujours problème… et que je n’arrive pas à résoudre pour le moment. C’est assez contraignant pour continuer cette fonctionnalité.

Mercredi 22 juillet 2009

J’ai continué à chercher d’où vient le problème de la pipeline. Je n’arrive pas à connecter le tee au videosink et au audiosink en meme temps. Alors qu’avec le decodebin cela fonctionne très bien. Pour le moment je sèche sur ce problème…

J’ai par ailleurs aidé les deux Nicolas à faire des tests avec le logiciel de travail collaboratif.

Mardi 21 juillet 2009

J’ai continué à chercher d’où venait ce problème de non affichage de la vidéo. Après avoir ajouté un élément tee, j’ai pu isoler le bout de la pipeline qui fait planter l’affichage, mais je n’ai pas réussi à résoudre le problème. L’affichage ne devrait pas être lié à ce bout qui fait en fait de l’envoie de paquets RTP. Je vais donc continuer à chercher une solution.

En toute fin de journée j’ai aidé Nicolas H. dans ses tests de streaming. Et j’ai commencé à chercher dans les fichiers sources où été généré le caps, pour que l’on puisse enfin utiliser n’importe quel codec.

Lundi 20 juillet 2009

J’ai remarqué que plusieurs éléments graphiques ne sont pas bien en place. J’ai commencé à les modifier sans résultat. Mais j’ai préféré remettre ceci à plus tard pour fignoler l’interface une fois que les fonctionnalités sont terminées.

J’ai donc continué le streaming de vidéo. J’ai écrit une pipeline qui permettrait de lire et de streamer le flux, mais je rencontre quelques problèmes d’affichage de cette vidéo coté émetteur. J’ai donc cherché à trouver et à résoudre ce problème.

D’une autre part j’ai commencé à mettre en place le coté récepteur pour décoder la vidéo.

Vendredi 17 juillet 2009

J’ai résolu le problème de sauvegarde des paramètres RTP et UDP dans les fichiers XML.

J’ai fait un tour de toutes les fonctionnalités implémentées, il ne semble y avoir aucun problème pour le moment.

J’ai commencé l’implémentation du streaming d’une vidéo comme source. Je comptais faire en sorte d’afficher une vignette une fois la vidéo sélectionnée, mais après avoir recherché comment faire, j’ai appris qu’il faut utiliser l’API JMF. Je discuterai donc de ceci avec Nicolas R. car ce n’est pas notre priorité.

Andoni Morales m’a répondu, et m’a dit que les codecs de FFMPEG se trouvent dans la version LGPL Je la testerai donc lundi.

Jeudi 16 juillet 2009

J’ai centralisé dans une classe toute la gestion du XML. Toute sauvegarde ou chargement se fait via cette classe.

J’ai ainsi pu résoudre de nombreux problèmes. Quasiment toutes les fonctionnalités concernant les fichiers XML fonctionnent : j’ai remarqué que la sauvegarde des paramètres RTP et UDP ne se fait plus. Je corrigerai rapidement ceci demain.

Comme le souhaitais Nicolas R., lorsqu’on charge un nouveau profil, la fenêtre n’est pas détruite puis réouverte, mais elle est rechargée. Je viens de terminer ceci à l’instant, demain je vérifierai que tout fonctionne bien. A priori oui.

J’ai aussi modifié le comportement de l’application lors de l’ajout d’un destinataire dans le cas ou l’option « manual » n’est pas cochée.

J’ai essayé de contacter Andoni Morales ce matin, mais il ne m’a pas répondu. Dès que j’aurai des nouvelles je tiendrai l’équipe informée.

Mercredi 15 juillet 2009

Nicolas R. m’a demandé d’installer la prerelease de GStreamer Winbuilds pour faire des tests de stabilité. Après installation, nous nous sommes rendus compte que malheureusement le décodeur X264 n’est pas dans cette version. Donc nous n’avons pas pu faire de tests. J’ai voulu contacter Andoni Morales à ce propos, mais le forum sur lequel il est joignable ne fonctionnait pas. Je réessayerai demain.

Par ailleurs, j’ai commencé à modifier la gestion du serializer XML pour faire en sorte de tout avoir dans une seule et même classe qui sera en mesure de sauvegarder ou de charger un fichier. Je rencontre quelques problèmes que je suis en train de résoudre au fur et à mesure.

Vendredi 10 juillet 2009

Après avoir discuté avec Nicolas R., il semble que l’on pourrait factoriser quelque peu le code permettant de parser le fichier XML. J’ai réfléchis à cela et continuerai donc ceci lundi.

Par ailleurs j’ai trouvé et corrigé un bug majeur dans la gestion des paramètres !

J’ai aussi modifié le panneau qui permet de régler le volume, en ajoutant des icones au bouton, des labels, en centrant les sliders et aussi en changeant un peu le comportement des components.

Jeudi 9 juillet 2009

J’ai essayé de résoudre le problème dans la sauvegarde. Le problème n’est toujours pas résolu, je bloque sur un petit quelque chose mais je ne sais pas comment y remédier pour le moment. J’ai essayé de demander de l’aide à Nicolas R. mais il était très occupé. Sinon j’ai refait un tour de l’application pour vérifier les fonctionnalités implémentées, je n’ai pas trouvé de bug à corriger.

Mercredi 8 juillet 2009

J’ai terminé la sauvegarde qui réalise le fichier XML « final ». Ce fichier contient donc : codec audio en cours, codec vidéo en cours et leurs paramètres. Les paramètres UDP et RTP. Les paramètres vidéo et audio des devices. La liste des destinataires UDP et RTP.

Je me suis attelé au chargement de ce fichier, mais je rencontre quelques petits problèmes. Une fois ceci résolu, je résoudrai quelques problèmes graphiques de l’interface.

Mardi 7 juillet 2009

La sauvegarde des codecs audio video, ainsi que tous les paramètres (des codecs, devices, etc.) fonctionne très bien. Et le chargement du fichier issu de la sauvegarde marche aussi. Cette nouvelle fonctionnalité sera donc très utile lorsque nous passerons à la phase de tests.

J’ai commencé à réaliser la sauvegarde d’un fichier XML final qui contiendra les informations décrites dessus, et les destinataires. Puis je passerai au chargement de ce fichier. Et nous devrions être au point au niveau des fichiers XML.

Ensuite je règlerai quelques problèmes au niveau de l’interface graphique.

Lundi 6 juillet 2009

Aujourd’hui j’ai fait mis au point la fonctionnalité qui permet de sauvegarder le codec audio et vidéo courant, ainsi que tous les paramètres.

La structure se sauvegarde correctement. En revanche, les paramètres actuels, ceux qui se trouvent dans les spinners, sliders, ou text field sont mal sauvegardés.

Demain je résoudrai ce problème et je passerai à la sauvegarde/chargement d’un XML qui contiendra toute cette structure et tous les destinataires.

Ensuite, comme convenu avec Nicolas H. je passerai à une autre fonctionnalité : pouvoir spécifier une fichier comme source vidéo et/ou audio.

Vendredi 3 juillet 2009

J’ai corrigé un bug au niveau de la gestion manuelle des ports en UDP/RTP.

De plus, nous avons décidé de ne pas ajouter à la liste des destinataires ceux dont les ports n’étaient pas spécifiés dans le fichier XML. Ceci a donc été réalisé.

De plus, j’ai avancé la sauvegarde des codecs audio et vidéos en cours dans un fichier XML. Néanmoins j’ai rencontré quelques soucis à ce niveau. En effet : le fichier de sortie XML doit pouvoir être rechargeable dans cette application. Mais cette fonctionnalité est en bonne voie.

Jeudi 2 juillet 2009

J’ai pu développer la fonctionnalité qui consiste à sauvegarder dans un fichier XML la liste des destinataires UDP et RTP. Cette liste est maintenant chargeable puis sauvegardable. Cela va permettre d’éviter de taper plusieurs fois tous les destinataires à chaque session de test.

J’ai aussi commencé la sauvegarde de tous les codecs et de leurs paramètres dans un fichier XML. Je pense que cette fonctionnalité sera terminée demain.

Mercredi 1er juillet 2009

Il est maintenant impossible de ne pas envoyer la video ET l’audio. il faut au moins un des deux.

Dorénavant, il sera possible de spécifier tous les ports UDP/RTP (RTCP) pour chaque host dans le fichier XML (ce qui a pris pas mal de temps).

De plus, un mode automatique/manuel a été ajouté, pour gérer comme on le désire tous les ports à la main. Et le streaming fonctionne très bien !

Demain je réaliserai la sauvegarde dans un fichier XML de tous les hosts présents dans la liste.

Mardi 30 juin 2009

Tous les paramètres sont maintenant capables d’être changés dynamiquement.

L’audio rate est aussi géré dans le manager pour pouvoir gérer le caps correctement.

J’ai aussi corrigé un autre bug que l’on avait trouvé lors du « refresh device ».

Il est maintenant possible de décider ce que l’on souhaite envoyer : soit la vidéo, soit l’audio, soit les 2.

Il faudra gérer le cas qui empêche de streamer si l’on n’envoit rien du tout.

J’allais commencer à permettre de gérer TOUS les ports des hosts dans le fichier XML. Je ferai ceci demain.

Lundi 29 juin 2009

L’application prend maintenant en compte le changement dynamique de paramètre : codec vidéo et audio , volume micro et son, du protocole RTP. Tout fonctionne très bien : cela a pu se vérifier notamment avec le son.

Après discussion avec Nicolas R., il faut aussi implémenter la modification de paramètre pour les devices. Je ferai ceci demain, cela devrait aller vite.

J’ai commencé à faire prendre en compte l’audio rate dans le caps. Ceci sera aussi terminé demain.

Vendredi 26 juin 2009

J’ai réfléchis à quel serait le meilleur moyen pour prendre en compte la modification dynamique des paramètres dans la pipeline en cours de streaming. Pour cela il faut que le manager qui contient tous les paramètres notifie à la classe qui l’observe qu’il faut modifier la pipeline. Puisque, on ne veut pas que le Manager sache qu’on utilise le framework GStreamer (pour pouvoir en interfacer un autre par la suite).

J’ai donc pensé à une méthode qui me semblait répondre à notre problème. Mais Nicolas R. m’a dit que cela ne convenait pas.

Mais je discuterais avec lui lundi matin car il y a certains points que j’aimerais éclaircir pour pouvoir résoudre au mieux la problématique posée.

Jeudi 25 juin

Aujourd’hui, j’ai pu terminer la sauvegarde du profil en cours (du codec audio et du codec vidéo) dans un fichier XML. Cette fonctionnalité importante va permettre de tester les paramètres des codecs et ensuite les sauvegarder pour pouvoir les charger directement dans l’application de travail collaboratif.

De plus, le volume est maintenant pris en compte au niveau du micro et au niveau du son reçu par le « destinataire ».

Sinon, j’ai à peine commencé le changement dynamique de paramètres via le manager. Une fois cette modification prise en compte, l’application sera déjà largement exploitable pour être en mesure de trouver de bons paramètres pour une vidéoconférence, selon les codecs choisis.

Mercredi 24 juin 2009

Ce matin j’ai continué à tenter de résoudre le problème d’ajout dynamique de destinataires mais cela ne fonctionne toujours pas.

Les deux boutons permettent de régler le volume au niveau du manager : pour le moment les changements dynamiques ne sont pas encore pris en compte

Par ailleurs, j’ai commencé une fonctionnalité qui va permettre de sauvegarder les paramètres en cours dans un fichier XML pour pouvoir ensuite le charger dans l’application de travail collaboration pour créer une romm avec ces paramètres.

Pour le moment, la fonctionnalité est ajoutée dans la barre des menus (Ctrl + S comme raccourci). On peut enregistrer le XML, l’écraser, ou non, et les premières balises sont inscrites dans le fichier.

Lundi 22 juin 2009

J’essaye de résoudre le problème de l’ajout dynamique de récepteurs quand le streaming a déjà commencé.Pour le moment ce streaming se coupe, dès lors qu’on ajoute un nouveau récepteur, et les anciens récepteurs cessent de recevoir le flux, alors que Java Gstreamer ne génère aucune erreur, et que la caméra fonctionne toujours.

Il est maintenant possible de rajouter un port dans le fichier XML qui gère les hosts. Ce numéro de port doit être supérieur au numéro de port minimal en cours. Sinon, si le numéro est inférieur, le nouveau récepteur prend alors comme numéro de port le numéro minimal.

J’ai par ailleurs commencé à coder un panel qui va permettre de gérer le son du micro et du son provenant du récepteur.

Jeudi 18 juin 2009

J’ai continué l’ajout dynamique de récepteur dans la pipeline. Bien que je n’ai pas d’erreur de Java Gstreamer le streaming se coupe et ne se fait plus sur aucun port. Malheureusement Nicolas R. n’était pas là pour m’aider aujourd’hui.

2 autres fonctionnalités ont été rajoutées à l’application.

La première, est le chargement de profils pour pouvoir charger de nouveaux codecs ou des paramètres particuliers.

La seconde est l’ajout de récepteur via fichier XML. Ceci permet si on teste différentes configurations de ne pas avoir à taper chaque fois les adresses IP. En quelques clicks les hosts sont rajoutés (en UDP ou RTP) à la liste déjà existante.

Par ailleurs, j’ai voulu rajouter un bouton pour régler le volume du son et du micro en reprenant le code de Nicolas R. Malheureusement, son code utilise SWT, et cette application utilise SWING. Je voulais donc lui demander s’il avait déjà cette fonctionnalité avec SWING ou s’il fallait que je la fasse.

Mercredi 17 juin 2009

J’ai continué la prise en compte de l’ajout d’un récepteur au niveau de la pipeline. Malheureusement je rencontre différentes erreurs que j’ai essayé de corriger. Je m’aide pourtant du code de Nicolas R. pour faire ceci.

A ce propos, j’ai contacté Nicolas R. pour qu’il essaye de me débloquer de la situation malheureusement il n’était pas très disponible aujourd’hui.

Je cherche donc toujours la piste qui va me permettre de résoudre ce problème.

Mardi 16 juin 2009

L’application est maintenant en mesure d’émettre à plusieurs récepteurs, qui eux reçoivent correctement les flux audio et vidéo.

J’ai par la suite, commencé à mettre en place le pattern Observer/observable. Je détecte bien l’ajout d’un nouveau récepteur. Il ne me reste plus qu’à lui envoyer le flux alors que le streaming a déjà commencé. Et ensuite, je pourrai permettre le changement dynamique des paramètres.

Lundi 15 juin 2009

Les panels pour ajouter et supprimer des émetteurs en RTP et UDP sont terminés. Ainsi que le panel pour spécifier de quel IP provient le flux UDP ou RTP que l’on veut lire  (ou plus tard « forwarder »).

L’envoi des données multiclient est normalement bien implémenté avec une boîte noire qui permet donc à mon Panel de ne pas connaître la bibliothèque avec laquelle il s’interface de manière à pouvoir la changer plus tard si on le désire. Demain je passerai à la réception de ces données pour tester la réception.

Vendredi 12 juin 2009

L’application est maintenant capable d’ajouter plusieurs destinataires en UDP et RTP, avec une bonne gestion, pour chacun des ports audio et vidéo (RTCP dans le cas RTP).

L’ergonomie a été pensée de façon à ajouter très vite plusieurs destinataires rapidement.

J’ai commencé à réfléchir à la création de la « boite noire » qui s’interfacera avec GStreamer puisque dans la dernière version le streaming n’est plus possible (à cause des multiples destinataires l’architecture a été revue concernant ce point). Lundi quand je réaliserai la classe qui gèrera les opérations de streaming, elle prendra en compte les multiples destinataires.

Jeudi 11 juin 2009

Le bug sur le bouton refresh a été corrigé

Il n’est plus nécessaire d’appuyer sur entrée quand on entre une IP

L’animation a été remplacée par un écran noir

Quand on clique sur le bouton send, les paramètres des codecs se grisent

Les caps sont mieux gérés maintenant

Mercredi 10 juin 2009

Le problème du son est maintenant résolu. Le streaming RTP fonctionne bien.

Il est maintenant possible d’utiliser le protocole UDP (sur 2 ports pour le moment)  : ce protocole ne fonctionne pas avec tous les codecs. Pour cette raison j’ai encore modifié le fichier XML qui permet de spécifier si le codec est utilisable en UDP ou pas. S’il ne l’est pas, il ne sera pas sélectionnable dans le comboBox.

Par ailleurs, j’ai ajouté un type float param. J’ai aussi fait quelques modifications mineures dans l’application.

J’ai aussi ajouté, et testé très rapidement des codecs : GSM, VORBIS, THEORA. Ainsi que leurs paramètres.

Mardi 9 juin 2009

J’ai corrigé un bug dans le rafraichissement des devices qui ne se faisait pas correctement.

J’ai par ailleurs travaillé sur le problème de son. Et je sais maintenant d’où viens le problème :

– d’une part l’application était trop gourmande en resources (maintenant je stream avec une taille et un framerate bien plus petits)

– d’autre part, c’est le fait de (re)définir chaque paramètre, même avec les valeurs par défaut qui donne un mauvais son

J’en parlerai à Nicolas R. demain pour qu’il me donne son avis.

Lundi 8 juin 2009

Ces derniers jours j’ai continué de travailler sur l’application..

A ce jour, la communication vidéo se fait plutôt bien, on peut maintenant entendre le son, mais il est incompréhensible. J’ai repris les « meilleurs paramètres » sur le blog de  Nicolas H. mais le son est toujours mauvais. Mais j’ai remarqué que mon CPU tourne aux environs de 120% quand je lance mon applications (…) peut être cela vient de ce problème. J’ai voulu essayer de mon poste Linux à mon poste Windows mais le son est très mauvais que ce soit en Speex ou en ALAW (qui lui n’a pas de paramètre, donc le problème ne devrait pas venir du codec).

Il est maintenant possible de rafraichir les périphériques, ceci fonctionne très bien.

Mardi 2 juin 2009

J’ai encore modifié la classe Manager pour qu’on puisse connaître à tout instant les devices audio et video sélectionné, ainsi que les codecs audio et vidéo.

J’ai commencé la classe ManagedPipeline qui selon les informations que contient le Manager est en mesure de créer la pipeline.
J’ai par ailleurs effectué quelques modifications au niveau de l’affichage de l’application qui s’affiche différemment sous Linux.

Vendredi 29 mai 2009

Aujourd’hui j’ai modifié le comportement des boutons qui maintenant est correct.

Si on « commence » le streaming, les paramètres non modifiables se grisent

Le panneau de droite se trouve dans un JSplitPane qui permet donc de le décaler

Il est maintenant possible de changer le Look And Feel avec une partie de ceux proposés par Substance. En revanche, si on change le LAF avec un de ceux du système, l’application plante…

J’ai commencé à jeter un oeil à la création d’une Pipeline, mais j’avoue ne pas avoir saisi le fonctionnement.

Mardi j’appelerai Nicolas R. qui sera en mesure de me guider pour cette étape.

Jeudi 28 mai 2009

Voilà les nouvelles modifications dans l’application de test des codecs :

– Modification du fichier XML pour prendre en charge les paramètres des devices audio et vidéo

– Manager capable de récupérer tous les paramètres dans chaque panel (ainsi que le protocole choisi)

– Modification du comportement des boutons pour streamer, recevoir, etc.

Mercredi 27 mai 2009

Voici ce que j’ai pu rajouter à l’application :

– Un scrollPane sur le Panel de droite dans la frame

– Sur le panel de droite, des onglets pour chaque rubrique

– Une marge de chaque côté de la frame pour que les panels ne soient pas collés

– Changement de LookAndFell

– Un cardLaout pour le panneau IP/port en udp/rtp

– L’affichage de 2 ou 4 TextField pour le port que l’on soit en UDP ou RTP

– Des JSliders à la place de JSpinners si le paramètre le permet(int ou long) avec un JTextField à coté pour être précis

– Le commencement du manager de Pipeline qui devra chercher les paramètres de chaque panel

Mardi 26 mai 2009

J’ai rajouté plusieurs éléments à l’UI :

– des onglets pour les paramètres des codecs audio et vidéo

– des bordures pour chaque panel

– ajout de boutons pour l’état de la pipeline, et l’action à réaliser (réception, envoi, froward)

– modification des alignements des comboBox, etc.

– ajout des autres numéros de port (RTCP, audio) : mais ceci reste à modifier, je ne prends pas en compte si on est en UDP ou RTP

Lundi 25 mai 2009

J’ai encore modifié l’UI de l’application. J’ai notamment rajouté un panel pour les quelques paramètres de l’audio et de la vidéo, ainsi que pour la gestion des protocoles.

J’ai aussi ajouté des champs pour l’Ip et le port qui sont placés dans la partie sud de l’application.J’ai aussi défini des tailles pour les panels et ajouté des ScrollPane à certains endroits du module dans le cas où l’on aurait trop de paramètres.

Dans le fichier XML on peut maintenant passer le nom du decoder, payloader, depayloader associé à chaque codec.

On peut aussi spécifier si l’élément est modifiable pendant que l’on stream. Exemple : un nom d’élément ne sera pas modifiable, un bitrate si.

Je me suis informé quant à l’utilisation de Observer/Observable en Java pour être notifié dynamiquement dans les changements des paramètres pour prendre en compte la modification de la pipeline.

Mercredi 20 mai 2009

Le développement de l’application progresse.

Voici ce qu’il reste à faire :

– Gérer correctement une JScrollPane

– Récupérer les paramètres dans la HashMap pour les injecter dans la pipeline

– Ajouter deux JTextField pour le numéro de port et l’adresse IP, ainsi que deux boutons pour  lancer et couper le streaming

– Créer la pipeline et streamer !

Mardi 19 mai 2009

J’ai modifié l’organisation de mes classes et j’ai découpé mon code dans différents packages.

J’ai continué le panel qui permet d’afficher les paramètres selon les codecs choisit. Normalement le code devrait fonctionner, en fait, je n’arrive pas à afficher les bonnes informations dynamiquement.

Lundi 18 mai 2009

J’ai continué le développement du module qui permettra de faire des tests à partir des différents codecs que nous souhaiterons utiliser dans l’application finale.

Le module est capable de parser un fichier XML qui contiendra les différents éléments à tester, ainsi que leurs paramètres, les paramètres concernant le protocole, etc.

J’ai fait le premier panel qui permettra de sélectionner les devices audio et video que l’on souhaite utiliser. J’ai à peine commencé le panel qui permettra de choisir les codecs et de spécifier les paramètres que l’on veut.

Jeudi 14 mai 2009

J’ai modifié le serveur RTSP de manière à ce qu’il prenne des paramètres en ligne de commande : le port, la pipeline, l’ip.

Mais après discussion avec Nicolas H. et Nicolas R., nous nous sommes rendus compte que ce serveur n’était pas forcément la meilleure solution.

Pour le moment, nous avons donc décidé de ne travailler pour le moment qu’avec des codecs qui ne nécessitent pas vraiment de caps et qui sont stables à la fois sous  windows et sous Linux.

Après avoir cherché un codec vidéo (principalement); il se trouve que H263 semble être stable.

Mais peut être qu’avec la prochaine version de GStreamer sous Windows X264 fonctionnera bien.

Mercredi 13 mai 2009

J’ai réussi à créer un fichier de configuration dans lequel il faudra spécifier la pipeline, le numéro de port, et le nom du flux streamé. Il suffira ensuite de compiler et exécuter pour lire le flux.

Par ailleurs, le temps de latence de 3s était du au playbin2 qui est configuré comme ceci. Pour supprimer ce temps de latence, il faut utiliser une pipeline un peu plus compliquée (celle ci gère simplement la vidéo) :

gst-launch-0.10 rtspsrc latency=200 location= »rtsp://__ip__:8559/test » ! decodebin2 ! ffmpegcolorspace ! directdrawsink

En revanche, et c’est étrange, je n’arrive pas à faire en sorte que 2 clients puissent lire en même temps le flux. Ceci provoque une erreur interne du flux de données… Je vais donc m’attarder sur ce point.

Mardi 12 mai 2009

En discutant avec certaines personnes sur le canal IRC à propos des fichiers SDP, il m’a clairement été confirmé que contruire le fichier à la main nous mènerait au même problème pour récupérer le caps puisque la configuration n’est pas statique.

Il m’a alors été vivement conseillé d’utiliser le serveur RTSP de GStreamer qui semble être maintenu depuis sa sortie en 2008.

Il a fallu mettre à jour GStreamer pour ce faire, ainsi que tous les plugins. Je résume la manoeuvre à suivre :

– Lancer cette commande : sudo apt-get build-dep gstreamer0.10-plugins-base gstreamer0.10-plugins-good  gstreamer0.10-plugins-ugly gstreamer0.10-plugins-bad

– Télécharger les dernières sources sur le site de GStreamer : ici
– Dézipper les sources, lancer le fichier configure (à la fin de l’affichage il devrait indiquer que la plupart des éléments seront installés)
– Lancer le fichier autogen.sh, puis faire make, et sudo make install

A partir de là le serveur peut aussi être compilé (autogen.sh, puis faire make, et sudo make install).
J’ai exécuté les fichiers de test en lançant test-video, puis il m’a suffit coté client de lancer la commande gst-launch-0.10 playbin2 uri=rtsp://__ip__:8554/test

J’essaye maintenant de comprendre le fonctionnement de ce serveur pour qu’il puisse être intégré à notre logiciel.

Lundi 11 mai 2009

Nous avons laissé tourner tout le week end la réception d’un flux sous Windows en utilisant le codec Theora, et là tout fonctionne parfaitement. C’est donc le fait d’utiliser RTP et X264 qui n’est pas stable sous Windows, c’est pour cette raison qu’il faut résoudre ce problème de caps pour pouvoir utiliser n’importe quel codec.

J’ai donc continué à chercher des informations concernant les fichiers SDP.
En début d’après midi, j’ai pu lire un document qui explique à quoi correspondent les différentes spécifications (voir la page dans la blogroll) et quels sont les informations à fournir.

A partir de là j’ai essayé de créer le fichier SDP minimal, c’est à dire avec le minimum de spécifications, mais j’obtiens le message d’erreur suivant : GstTypeFindElement:typefind: Could not determine type of stream
J’essaye donc de résoudre cette erreur afin de voir s’il est possible de décoder un flux en contournant ce problème de caps.

Quoi qu’il en soit, en discutant avec Marlène, j’ai appris que même en utilisant le protocole RTSP il faut absolument passer le caps pour décoder le flux..

Jeudi 7 mai 2009

J’ai essayé de trouver des exemples d’utilisation de fichiers SDP, avec GStreamer ou bien VLC. Malheureusement, je n’en trouve pas.

J’ai essayé d’avoir de l’aide via, la mailing list, le canal IRC, et 2 autres forums. Mais mes messages restent sans réponse. Il m’est alors difficile de progresser.

En ce qui concerne la stabilité, avec Theora, tout semble fonctionner correctement. Le problème serait vraisemblablement du à l’utilisation combinée de RTP et de X264.

Il faudrait donc pouvoir régler ce problème de caps, on pourrait ainsi utiliser n’importe quel codec qui fonctionne correctement.

Mercredi 6 mai 2005

Ce matin j’ai continué à chercher une solution au problème d’interruption des flux, le problème semble venir de l’utilisation de X264 et du protocole RTP.
J’ai joint Nicolas R. au téléphone pour lui expliquer le problème.
Il m’a conseillé de faire plusieurs choses :
– Faire la liste des codecs qui utilisent/n’utilisent pas de caps sous Windows et sous Linux
– Trouver comment est généré ce caps pour pouvoir le reconstruire au niveau de l’émetteur
– Voir comment fonctionne SDP

J’ai donc cherché des informations concernant SIP/SDP, mais on en trouve très peu. Parallèment, j’ai demandé sur la mailing list de Java Gstreamer s’il était possible de simuler le passage de l’option -v.

Mardi 5 mai 2009

J’ai continué à chercher d’où pouvait provenir ce problème d’interruption des flux. Malheureusement, je n’ai pas avancé d’un poil.
Je me suis aussi concentré sur la caméra branchée sur la carte Osprey. Et ça ne fonctionne pas non plus.
J’appelerai Nicolas R. pour lui faire part des soucis qui me freinent.

Lundi 4 mai 2009

Nicolas R. m’a téléphoné ce matin. Il me conseille de résoudre les problèmes auxquels je suis confronté avant de commencer l’intégration dans le logiciel.
J’ai donc cherché à récupérer le flux provenant de la caméra branchée sur la carte Osprey. Le problème semble provenir de l’élément dshowvideosrc : j’ai changé les éléments dans ma pipeline pour vérifier d’où pouvait provenir le problème.
Plusieurs personnes sur IRC ont aussi tenté de m’aider. Malheureusement aucun de nous n’arrive à comprendre pourquoi cela ne fonctionne pas.

Pour ce qui est du problème d’interruption des flux, j’ai aussi cherché de l’aide. Une autre personne rencontre exactement le même problème que moi ici. Et comme on peut le lire à cette adresse, Andoni Morales travaille pour modifier l’architecture de ce projet. Ceci résoudra peut être de nombreux problèmes auxquels nous sommes confrontés.

Jeudi 30 avril 2009

Je cherche toujours d’où peut venir l’interruption. Il semblerait que la pipeline ne plante plus si je retire le depay/décodeur et que j’envoie le tout dans un fakesink. Mais je n’ai pas pu corriger ce problème.

Avec Marlène, nous nous sommes rendus compte d’un problème lorsqu’on utilise Gstreamer avec un device qui a un nom avec accent. En fait, on ne peut pas utiliser ce device directement en ligne de commande (nous n’avons pas perdu de temps pour le faire marcher en ligne de commande). Mais maintenant tout fonctionne très bien avec java Gstreamer.

J’ai installé la carte osprey. J’arrive à lire le flux via VLC mais j’ai toujours des difficultés à lire le flux via Gstreamer. Comme la caméra de Nicolas R. je pensais qu’il fallait spécifier un certain framerate, la hauteur et la largeur. Mais même en faisant ceci ça ne marche pas. J’ai un message qui me dit : Check your filtered caps if any

Mercredi 29 avril

J’essaye de déterminer d’où peut provenir ce problème d’interruption du flux sous Windows. Personne n’est en mesure de m’aider pour résoudre ce problème. Utiliser le –gst-debug-level n’apporte aucune information quant au problème.
En revanche le flux sous Linux fonctionne parfaitement.

J’ai par ailleurs continué la compréhension du logiciel collaboratif.

Mardi 28 avril 2009

J’ai contacté Nicolas R. pour avoir des explications quant à l’intégration de mon travail dans le logiciel. Il m’a dit qu’il était préférable d’attendre lundi pour qu’il puisse me fournir un certain nombre d’explications et me mettre dans de bonnes conditions de travail.
Il m’a conseillé de comprendre le code du logiciel et c’est ce que j’ai fait.

D’autre part, je me suis donc rendu compte que la réception des flux plantait parfois sous Windows, mais apparemment pas sous Linux. Il se trouve que ce plantage n’est pas du à Java Gstreamer mais bien à Gstreamer lui même. J’essaye donc de comprendre d’où cela peut venir pour faire en sorte de corriger ceci et de rendre le streaming plus stable.

Lundi 27 avril 2009

La récupération des périphériques vidéo sous Linux fonctionne très bien. Celle des périphériques audio aussi, mais lorsqu’on spécifie le device dans la pipeline on obtient une erreur du type « can’t open audio device for recording ».

J’ai testé ce que m’a dit Nicolas R. pour récupérer le caps. Cela ne fonctionne pas. En fait, cela permet de récupérer les caps en entrées et sorties seulement : dans quel intervalle doit être la hauteur de la vidéo, son framerate, etc.

J’ai constaté que parfois j’obtenais une exception lors de la réception de la vidéo sous Windows seulement. Le problème se produit « aléatoirement ». Il semblerait que l’erreur soit due a ffmpeg. Mais je n’ai pas réussi à la corriger.

Vendredi 24 avril 2009

La compilation de Gstreamer fonctionne. J’ai modifié par ailleurs la procédure que j’avais écrite puisque Andoni Morales a modifié certaines choses dans son projet. Si jamais il y a des erreurs à la compilation, je vous conseille de le contacter, il se peut qu’il ait fait des modifications qui ne fonctionnent pas.

En récupérant les dll issues de la compilation j’ai pu faire tourner le .jar dont je parlais dans mon billet d’hier ! Donc, c’est une bonne chose, si par la suite on voudra compiler soit même la version de WinBuilds Gstreamer.

J’ai porté les 2 modules sous Linux et j’ai pu faire du streaming croisé. Il m’est arrivé que le streaming plante au bout de quelques secondes mais je n’ai pas réussi à reproduire l’erreur. Quoiqu’il en soit, ceci fonctionne.

En revanche, je n’arrive pas à récupérer la liste des devices audio et vidéo sous Linux. En effet, le runtime.exec(« ls /dev/video* ») retourne toujours null. J’ai tenté de me faire aider sur un forum mais je n’ai pas eu de réponse. Donc, pour le moment, je force l’utilisation du device.

Comme je le disais hier, il est possible d’utiliser mes deux modules à l’aide d’un jar exécutable. Sous windows, il faut absolument spécifier les deux variables. En revanche sous Linux non : normalement Gstreamer est déjà installé.

Jeudi 23 avril 2009

J’ai réussi à faire fonctionner Java Gstreamer sans avoir Gstreamer installé sur la machine, simplement en mettant les dll dans un répertoire. En fait, c’est plutôt simple, il suffit d’ajouter comme variable d’environnement : dans Run Configurations, onglet Environment, il faut ajouter la variable GST-PLUGIN_PATH qui doit pointer sur lib\gstreamer-0.10\ et la variable PATH qui doit pointer sur bin\.

Ainsi tout marche parfaitement : j’ai réussi à streamer à partir de mes 2 modules.

J’ai voulu essayer de tester l’application à partir des dll compilées soit même.  J’ai repris donc ma procédure de compilation (j’ai du tout télécharger et réinstaller, puisque entre temps j’ai changé de machine) mais la compilation a échoué. Je vais donc reprendre la compilation, et si je n’y arrive pas, je contacter Andoni pour savoir s’il a modifié sa version de Gstreamer.

D’autre part, j’ai essayé de porter mes 2 modules (via un jar exécutable qui fonctionne sous Windows) sous Linux et je me suis rendu compte que je n’avais pas pris en compte la détection des périphériques sous ce système d’exploitation. Théoriquement, une fois ceci fait, le module devrait marcher.

Mercredi 22 avril 2009

Ce matin j’ai continué dans la recherche pour le passage de caps. En fait, il semblerait qu’il faille connecter à la pipeline le deep-notify signal. J’ai donc commencé des recherches àce sujet, et testé plusieurs méthodes.

Après une réunion avec Nicolas H., nous avons convenu qu’il serait préférable de travailler seulement avec des codecs qui ne nécessitent pas de caps.

X264 et Alaw n’utilisent pas vraiment de caps : il faut en passer un, mais celui-ci peut se contenter d’être toujours le même donc cela ne semble poser aucun problème.

J’ai donc commencé à créer mon « package » pour utiliser mon module sans avoir Gstreamer installé sur sa machine.

Tel quel cela ne fonctionne pas. Je passe donc comme arguments, les paths qu’utilisait Gstreamer lorsqu’il était installé et qui mènent donc aux mêmes fichiers. Et on aboutit à cette erreur que je cherche à corriger :

Exception in thread « main » java.lang.IllegalArgumentException: No such Gstreamer factory: fakesink

Mardi 21 avril 2009

J’ai tenté de joindre Nicolas R. pour pouvoir avancer, malheureusement il est malade.

J’ai donc continué à chercher comment passer ce caps en cherchant sur Internet, ou en demandant sur IRC mais personne n’était capable de me répondre.

Marlène a essayé de m’aider dans cette tâche qui est très importante. Malheureusement, elle non plus n’a pas trouvé de solution.

Lundi 20 avril 2009

J’ai continué mes recherches sur la gestion dynamique des caps. En fait, il n’est pas possible de le faire avec appsrc, ni avec aucun élément de Gstreamer. Il faut obligatoirement développer une solution externe au framework.

J’ai donc essayé de récupérer dans Java Gstreamer le flux qui serait produit par le passage de l’option -v. Si je passe cette option grâce à Eclipse, cela ne fait rien. J’ai donc essayé d’autres méthodes mais je n’ai pas réussi. Je n’ai pas trouvé de méthode dans la documentation permettant de récupérer ce qui m’intéresse soit via la pipeline, ou autrement.

J’ai essayé de joindre Nicolas R. pour savoir s’il pouvait m’aider pour résoudre ce problème, en vain. J’espère pouvoir lui demander s’il sait comment récupérer l’affichage produit par cette option, pour ensuite le découper et l’envoyer grâce au serveur du logiciel sur lequel il travaille, aux autres clients.

Vendredi 17 avril 2009

J’ai effectué plusieurs tests en choisissant les devices audio et vidéos possibles. Par ailleurs, j’ai pu corriger plusieurs choses dans mon code pour prendre notamment en compte si l’on utilise l’application sous Windows ou Linux pour que cela fonctionne avec les deux sytèmes d’exploitation.

Sempiternel problème : les caps audio/vidéo qui changent assez souvent selon la configuration choisie et le matériel. J’ai donc commencé à chercher une solution pour pouvoir envoyer et récupérer les caps dynamiquement. Pourquoi pas avec l’élément appsrc. Je n’ai pas trouvé d’informations très utiles quant à cette utilisation. Mais dès lundi, je me renseignerai sur le forum adéquat.

Jeudi 16 avril 2009

On a enfin réussi a récupérer les devices audio et vidéo présents sur la machine.

Pour les récupérer, il faut lancer un exécutable via Java. Ce fichier .exe produit du code JSON ( format de données textuel que nous ne connaissions pas et que nous avons donc pu découvrir, rapidement), qui une fois parsé correctement permet de récupérer la liste des devices.

Cette liste est maintenant proposée dans le petit module, et on peut donc choisir la source que l’on désire streamer !

En laissant choisir la webcam, dont on veut streamer le flux, je me suis rendu compte qu’il faut parfois spécifier la hauteur et la largeur de l’image, car celle provenant de la webcam est trop grande, et n’est pas accepté par les éléments suivants de la pipeline. Je vais donc travailler sur cet aspect et ensuite, passer à des tests pour faire fonctionner l’application aussi bien sur Windows que sur Linux.

Mercredi 15 avril

J’ai pu résoudre le problème que j’avais rencontré hier. Donc le streaming en passant les caps dans le module fonctionne bien (je n’ai testé que de Windows à Windows pour le moment).

Ensuite, j’ai essayé avec Marlène de faire fonctionner un exécutable générant un fichier XML contenant touts les devices audio et vidéo. Ce fichier fonctionnait sur sa machine mais pas sur la mienne. Après plusieurs tests, Marlène a réussi à faire fonctionner cet .exe.

J’ai tenté d’appeler cet executable via Java avec le code suivant :

Runtime.getRuntime().exec(« C:\\DShowDevices.exe »);

Visiblement, cela ne génére aucune erreur, ni aucune exception. Mais le fichier XML n’est pas créé. Pourtant, en regardant sur les forums, le code semble bon.

Peut-être est il impossible à l’exe de générer un fichier ?

J’ai par ailleurs jeté un oeil au code de Videolan qui récupère aussi les devices. Il semble que Videolan utilise DirectShow. Il devrait donc être possible de faire fonctionner cette DLL. Marlène travaille donc sur ceci, et moi de mon côté sur l’exécutable.

Mardi 14 avril 2009

Je me suis largement inspiré du module d’émission pour réaliser le module de réception. Ce module est simple, on choisit quel type de codec on doit utiliser pour décoder. Puis on a deux champs pour spécifier le caps audio et le caps vidéo.

J’ai essayé de comprendre pourquoi j’obtiens cette erreur lorsque j’essaye de recevoir le flux :

javaw.exe:2176): CRITICAL **: file ..\..\gst\gstutils.c: line 1765: assertion `GST_IS_ELEMENT (element_1)’ failed

Il serait préférable que je résolve cette erreur pour passer à la suite.

Vendredi 10 avril 2009

Les différents codecs audio/vidéo fonctionnent entre eux. J’avais quelques fois des problèmes de gros décalage entre la vidéo et le son qui normalement sont semble-t-il résolus. Il est conseillé de spécifier le caps vidéo et audio à chaque fois, même si dans certains cas on peut s’en passer.

Il faudrait maintenant réaliser des tests de discussion, puisqu’il m’est assez difficile de parler, voir si l’image et le son concordent, et qu’il n’y pas de trop grand décalage.

J’ai aussi fait des tests concernant les dimensions de la vidéo. Il est normalement possible de choisir une valeur entre 1 et 2147483647. Mais en fait, on ne peut pas entrer n’importe quelles valeurs sinon le streaming ne fonctionne plus (cela paraît logique). Il serait donc préférable de proposer à l’utilisateur un choix de résolutions plutot que lui faire rentrer des chiffres au hasard.

J’ai cherché une manière de récupérer les dimensions possibles et utilisables, mais apparemment cela n’existe pas.

J’ai du écarter comme je le disais dans mon billet d’hier le protocole UDP. En utilisant le protocole RTP, on peut choisir, pour le moment, soit le codec Theora ou X264 pour la vidéo, soit le codec Alaw ou Vorbis pour l’audio. Tous ces codecs fonctionnent plutôt bien.

Il serait donc intéressant à partir de lundi de faire des mini tests de discussion pour tester les probables décalages audio/vidéo.

Jeudi 9 avril 2009

Nous avons continué, Marlène et moi, à tenter de faire fonctionner la dll pour pouvoir récupérer les périphériques audio et vidéo. Cela ne fonctionne toujours pas. C’est Marlène qui s’occupe maintenant de cette tâche.

De mon côté, j’ai continué le petit module de tests. J’ai du traiter que je n’avais pas encore traité :  l’envoi de différents types de données via UDP. Après bien des tests, on peut conclure que cela fonctionne très mal. On a de mauvaises synchronisations. J’ai donc eu la confirmation qu’envoyer des « raw data » via UDP n’est pas adapté. Il sera donc préférable d’envoyer des paquets RTP via UDP, car ceci fonctione bien mieux.

J’ai cherché une solution pour pouvoir récupérer dynamiquement les caps audio et vidéo pour ne pas avoir à copier cette longue chaîne de caractères. Et il semblerait que cela soit impossible à moins d’utiliser le protocole RTSP.

Chose fastidieuse, du moment que l’on change la taille de la vidéo, en spécifiant la hauteur et/ou la largeur, le caps change complètement.

Mercredi 8 mars

Ce matin, j’ai essayé avec Marlène de faire fonctionner sa dll qui permet de détecter les périphériques.
Après avoir ajouté le .jar et la dll au projet cela ne fonctionnait pas. Nous avons essayé d’installer directshow, en vain.
Nous avons alors essayé d’installer Visual Studio Express et cela fonctionne. Nous pensons donc que cela fonctionne parce que VSE installe les frameworks .NET. Marlène va donc voir s’il est possible d’utiliser la dll sans installer quoi que ce soit.

L’après midi, j’ai continué le module en Java. Je reprends donc les pipelines que j’avais écrites et selon ce que choisit l’utilisateur, je construit les pipelines.
Je suis tombé sur un cas que je n’avais pas essayé : envoyer via UDP un ogg contenant de la vidéo encodée avec Theora
et de l’audio encodée avec Vorbis. J’ai donc écrit la pipeline, mais la transmission est très mauvaise et le son est saccadé. Je me suis donc renseigné, et en fait, ogg ne supporte pas le streaming, d’où ces problèmes de  synchronisation.

Mardi 7 avril

J’ai pu terminer grosso modo l’interface de mon petit module de test en Java. Grosso modo parce qu’il serait possible d’améliorer plusieurs choses, notamment la vérification des paramètres rentrés : est-ce qu’ils sont contenus dans la plage qu’indique gst-inspect,  par exemple.

J’ai fait un tout premier test, streamer à partir du module, en Theora et en UDP le flux vidéo. Et j’ai testé la réception en ligne de commande sur mon autre ordinateur. Après quelques problèmes résolus cela fonctionne très bien.

J’ai ensuite essayé de faire la même chose mais cette fois-ci, en affichant la vidéo streamée dans le petit module. Et là je rencontre d’autres problèmes. Les problèmes sont sûrement dus à ma façon d’utiliser Java Gstreamer.

Une fois ceci réalisé, je devrai prendre en compte les autres codecs, les autres protocoles, etc. Puis faire un autre module en Java permettant la réception et la lecture des flux vidéo et audio.

Lundi 6 avril

En début de matinée, j’ai continué à chercher d’où venait ce problème de débit beaucoup trop grand bien que l’on spécifiait le bitrate. La solution a été trouvée par Nicolas H. et est très simple : il faut aussi forcer le framerate ! Il était à 100 images par secondes, au lieu des 25 habituelles. Voilà pourquoi le débit était quasiment quadruplé.

Ensuite, j’ai commencé le développement d’une mini application Java pour effectuer des tests avec Gstreamer. Pour le moment, l’interface graphique est en grande partie réalisée. Il reste au niveau du code, plusieurs vérifications à faire (ne pas permettre de choisir 2 codecs vidéo par exemple pour éviter d’autres problèmes par la suite par exemple).

Une fois ces vérifications faites,  je m’attacherai à streamer les flux audio et vidéo selon les codecs choisis et les informations fournies par l’utilisateur vers la machine cible.

Vendredi 3 avril 2009

J’ai continué de faire des tests avec Java Gstreamer. J’ai essayé notamment de passer des paramètres aux différents éléments de la pipeline.En fait, cela se fait simplement en appelant la méthode set() à partir de l’élément créé.

J’ai aussi regardé plus en détail le code Java écrit par Nicolas R. concernant Gstreamer afin d’essayer de mieux comprendre le fonctionnement des différentes classes.

Dans la dernière heure de la journée, j’ai essayé de résoudre un problème qu’à rencontré Nicolas H. concernant le taux du bitrate avec theoraenc. En effet, peu importe le bitrate défini, le bitrate du côté récepteur reste toujours à 2M/s. Pour cette raison, je vais continuer à voir d’où peut venir ce problème et comment le résoudre.

Jeudi 2 avril 2009

J’ai réussi à faire fonctionner le streaming en utilisant vorbis. Il semblerait que ce soit l’envoi de paquets RTCP qui fasse planter le flux vidéo ou audio.
Voici les pipeline :

Emetteur (Windows) :
gst-launch-0.10.exe -v gstrtpbin name=rtpbin dshowvideosrc ! decodebin name=dec dec. ! queue ! x264enc byte-stream=true bitrate=300 ! rtph264pay ! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0 ! udpsink port=5000 host=192.168.29.96 ts-offset=0 udpsrc port=5005 name=vrtpsrc ! rtpbin.recv_rtcp_sink_0 dshowaudiosrc ! queue ! audioresample ! audioconvert ! vorbisenc ! rtpvorbispay ! rtpbin.send_rtp_sink_1 rtpbin.send_rtp_src_1 ! udpsink port=5002 host=192.168.29.96 ts-offset=0


Récepteur(Linux) :

gst-launch gstrtpbin name=rtpbin latency=200 udpsrc caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264" port=5000 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! ffdec_h264 ! xvimagesink udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 rtpbin.send_rtcp_src_0 ! udpsink port=5005 host=192.168.29.83 sync=false async=false udpsrc caps="un long caps" port=5002 ! rtpbin.recv_rtp_sink_1 rtpbin. ! rtpvorbisdepay ! vorbisdec ! audioconvert ! audioresample ! alsasink udpsrc port=5003 ! rtpbin.recv_rtcp_sink_1 rtpbin.send_rtcp_src_1 ! udpsink port=5007 host=192.168.29.83 sync=false async=false


======

J’ai par ailleurs commencé à jeter un oeil à l’interface Java pour le framework Gstreamer en lisant les tutoriaux et effectuant quelques simples tests basés sur les pipelines que j’avais écrites (notamment celles pour la vidéo).
J’ai aussi regardé le code Java fait par Nicolas R. pour comprendre comment cela va fonctionner dans le logiciel sur lequel nous travaillons.

Mercredi 1er avril 2009

J’ai voulu reprendre les pipelines que j’avais écrites le 23 mars qui permettaient de streamer avec X264 et Alaw. Bizarrement, quand j’exécutais la pipeline, une exception se produisait (sans plus d’informations). J’ai donc de suite pensé à une erreur de ma part quand j’ai copié/collé la pipeline.
J’ai donc commencé à la découper pour la simplifier et tester ce qui ne fonctionnait pas. En parallèle, je travaillais avec une personne sur le channel IRC de gstreamer qui s’est mis dans les mêmes conditions que moi et chez qui ma pipeline fonctionnait parfaitement. J’ai donc essayé sur l’ordinateur de Marlène, et cela fonctionnait aussi.

J’ai alors essayé de tester cette pipeline avec la version exe de Winbuilds Gstreamer, et non pas celle que j’avais moi même compilé. Avec la version 0.10.2 ou 0.10.3 cela faisait la même chose. Après plusieurs désinstallation/réinstallation ça ne marchait toujours pas. Et ce n’était pas dû non plus aux variables d’environnement, mais cela semblait quand même lié à mon système.
Quoiqu’il en soit, on m’a fournit un autre ordinateur, et la pipeline fonctionne correctement.

En attendant que Nicolas R. revienne pour m’expliquer comment fonctionne JNA j’ai fait des tests de streaming avec Vorbis. En fait, pour que le streaming fonctionne il faut spécifier le caps au niveau du récepteur. En revanche, j’ai remarqué que la vidéo ou le son se bloquent au bout de quelques secondes. je vais donc tenter de comprendre pourquoi.

Mardi 31 mars 2009

Aujourd’hui j’ai essayé de corriger le problème du plugin Speex.

J’ai pu localiser que l’erreur se situe dans le fichier gstspeexenc.c aux alentours de la ligne 700 :
speex_init_header (&enc->header, enc->rate, 1, enc->speex_mode);

Je pensais dans un premier temps que l’erreur était due au mauvais rate (qui doit être 8000, 16000 ou 32000).
Dans un premier temps j’ai donc forcé ce rate aux trois valeurs mais le problème persiste.

J’ai donc cherché sur le net, et par moi même de quoi pouvait provenir ce problème, mais je n’ai pas trouvé.
Quoi qu’il en soit j’ai informé Andoni que j’avais ce problème et j’ai laissé un message sur la mailing list mais je n’ai eu aucune réponse. De plus, il me semble que personne ne relate ce problème sur le net.

Pour le moment je vais donc laisser ce problème de côté, mais dans le cas où j’aurai une réponse, j’y reviendrai.

Lundi 30 mars 2009

Petite progression…
J’ai réussi à streamer la vidéo de la webcam encodée avec X264 en UDP.
Je vais maintenant essayer d’avoir la vidéo + le son
Il faut malheureusement récupérer le caps de l’émetteur pour pouvoir récupérer le flux vidéo chose que je ne faisais pas auparavant.

Emetteur Windows :
gst-launch-0.10.exe -v dshowvideosrc ! video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! x264enc ! udpsink host=192.168.X.X port=1234

Récepteur Linux :

gst-launch udpsrc port=1234 caps="video/x-h264, ...." ! ffdec_h264 ! autovideosink

========
J’ai continué à travailler sur l’utilisation du codec Speex.
Pour m’aider, j’ai rejoint le channel de discussion IRC Gstreamer afin d’avoir une aide assez rapide (autre que par mail).
Avec une autre personne nous avons abouti aux mêmes conclusions :
Sous Linux Speex fonctionne très bien, en revanche pas sous Windows.

Pour preuve cette simple commande :
gst-launch-0.10.exe dshowaudiosrc ! speexenc ! fakesink
Elle fonctionne sous Linux mais produit une exception sous Windows dès son utilisation.
J’ai cherché de voir si d’autres personnes avaient rencontré le même problème que moi, malheureusement non. Il me semble que la correction de ce bug risque d’être difficile quoi qu’il en soit puisqu’on ne sait pas exactement d’où vient le problème.

Vendredi 27 mars 2009

J’ai continué l’ajout du plugin Speex mais je recontre toujours quelques problèmes. Notamment des problèmes de compilation du plugin récupéré sur le site de Speex, ce qui m’empêche de l’ajouter correctement à ma solution Gstreamer.

En parallèle, j’essaye de comprendre pourquoi je n’arrive pas à utiliser Speex avec Gstreamer WinBuilds. Il se pourrait que je doive récupérer le caps en passant l’option -v pour la commande de l’émetteur.
Mais passer cette option lance une exception.

Je cherche donc des solutions à ces problèmes…

Jeudi 26 mars 2009

J’ai continué l’ajout du plugin qui ne fonctionne toujours pas (pour les mêmes raisons qu’hier : problèmes de compilation).

J’ai essayé de streamer en utilisant Speex mais là alors que Gstreamer s’exécute normalement, il rencontre une exception. J’ai donc cherché à voir d’où provient cette erreur.

Aujourd’hui je n’ai eu aucune réponse à mes problèmes alors j’ai essayé de les résoudre tant bien que mal.

Je dois donc constater qu’aujourd’hui je n’ai pas vraiment avancé puisque je suis bloqué par plusieurs points que j’aimerais faire progresser. J’espère les résoudre au plus tôt pour pouvoir continuer mes tests.

Mercredi 25 mars 2009

Pas vraiment de progrès aujourd’hui, malheureusement.

Rajouter un plugin semble simple mais je rencontre quelques petites difficultés au niveau de la compilation du plugin que j’ai pu récupérer sur le site de Speex. Dont des fichiers qui me manquent pour pouvoir suivre correctement le mini tutoriel.

Andoni Morales m’a dit qu’il avait mis la version de Gstreamer Winbuilds à jour. On a plus de problèmes pour la dll de ffmpeg. Ce qui est une bonne chose. En revanche, il y a un nouveau problème à la compilation ce qui empêche d’utiliser x264enc. J’ai donc cherché à résoudre ceci, pour pouvoir tester le streaming avec H264 + Speex. Je l’ai informé de ce problème. J’attends sa réponse.

J’ai vu aussi que Andoni Morales souhaitait faire une sorte de script pour mettre à jour plus facilement Gstreamer WinBuilds. Une fois que j’aurai résolu ces problèmes de plugins et que j’aurai avancé les tests je lui demanderai comment il est possible de faire une version de Gstreamer pour Windows à partir des sources officielles.

Mardi 24 mars 2009

Jai continué à chercher d’où venait le problème qui m’empêche de streamer le flux vidéo + le flux audio encodé avec le codec Vorbis.

Parallèlement, j’ai demandé de l’aide sur la mailing list qui m’a répondu, mais entre temps j’étais passé à l’ajout du plugin Speex.

En effet, j’ai demandé à Andoni Morales Alastruey s’il était possible d’inclure le plugin Speex dans la prochaine version de Gstreamer WinBuilds. Il m’a répondu que oui (donc la nouvelle version qui devrait sortir dans une semaine devrait contenir le plugin Speex). Je lui ai demandé par la même occasion s’il était possible d’écrire un tutoriel pour comprendre comment ajouter un plugin.

Il a écrit ce tutoriel qui se trouve ici. J’ai donc commencé à intégrer le plugin Speex et je vais essayer de terminer ceci demain.

Lundi 23 mars 2009

Le codec Speex n’est pas du tout pris en charge, pour le moment, dans GStreamer WinBuilds. Mais il se peut, que dans les prochaines versions, il soit rajouté, puisque la personne qui gère GStreamer WinBuilds met assez souvent le framework à jour (une à deux fois par semaine).
Par la force des choses, je vais donc concentrer mes efforts sur le codec Vorbis, mais si Speex est pris en charge, j’effectuerai certains tests avec ce codec.

Autre nouvelle, bonne cette fois-ci, la version courante rencontre des problèmes avec ffmpeg-0.5 : normalement, le bug devrait être fixé au plus tard dans une semaine.

============
STREAMING SON
============

Premier test : Codec Vorbis, Protocole UDP
Récepteur Linux (à lancer en premier) :

gst-launch udpsrc port=1234 ! oggdemux ! vorbisdec ! audioconvert ! audioresample !  alsasink sync=false

Emetteur Windows :
gst-launch-0.10.exe dshowaudiosrc ! audioconvert ! vorbisenc ! oggmux ! udpsink host=192.168.X.X port=1234

————————–
J’ai fait une requête auprès d’Andoni Morales Alastruey pour que le plugin Speex soit pris en compte dans la prochaine version de Gstreamer WinBuilds. Je vais donc suivre cela de près.

J’ai continué des tests de streaming avec le codec H264 pour la vidéo, le codec ALAW pour le son (pour le moment) et le protocole RTP. Streaming d’une vidéo au format ogg :

Emetteur Windows :
gst-launch-0.10.exe gstrtpbin name=rtpbin filesrc location=big_buck_bunny_720p_stereo.ogg ! decodebin name=dec dec. ! queue ! x264enc byte-stream=true bitrate=300 ! rtph264pay ! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0 ! udpsink port=5000 host=192.168.X.X ts-offset=0 name=vrtpsink rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=192.168.X.X sync=false async=false name=vrtcpsink udpsrc port=5005 name=vrtpsrc ! rtpbin.recv_rtcp_sink_0 dec. ! queue ! audioresample ! audioconvert ! alawenc ! rtppcmapay ! rtpbin.send_rtp_sink_1 rtpbin.send_rtp_src_1 ! udpsink port=5002 host=192.168.X.X ts-offset=0 name=artpsink rtpbin.send_rtcp_src_1 ! udpsink port=5003 host=192.168.X.X sync=false async=false name=artcpsink udpsrc port=5007 name=artpsrc ! rtpbin.recv_rtcp_sink_1

Récepteur Linux :
gst-launch gstrtpbin name=rtpbin latency=200 udpsrc caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264" port=5000 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! ffdec_h264 ! xvimagesink udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 rtpbin.send_rtcp_src_0 ! udpsink port=5005 host=192.168.X.X sync=false async=false udpsrc caps="application/x-rtp,media=(string)audio,clock-rate=(int)8000,encoding-name=(string)PCMA" port=5002 ! rtpbin.recv_rtp_sink_1 rtpbin. ! rtppcmadepay ! alawdec ! audioconvert ! audioresample ! alsasink udpsrc port=5003 ! rtpbin.recv_rtcp_sink_1 rtpbin.send_rtcp_src_1 ! udpsink port=5007 host=192.168.X.X sync=false async=false

J’ai ensuite essayé de streamer la vidéo issue de la webcam et le son issu du micro et cela fonctionne plutot bien sans trop de délai :

Emetteur Windows :
gst-launch-0.10.exe gstrtpbin name=rtpbin dshowvideosrc ! decodebin name=dec dec. ! queue ! x264enc byte-stream=true bitrate=300 ! rtph264pay ! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0 ! udpsink port=5000 host=192.168.X.X ts-offset=0 name=vrtpsink rtpbin.send_rtcp_src_0 ! udpsink port=5001 host=192.168.X.X sync=false async=false name=vrtcpsink udpsrc port=5005 name=vrtpsrc ! rtpbin.recv_rtcp_sink_0 dshowaudiosrc ! queue ! audioresample ! audioconvert ! alawenc ! rtppcmapay ! rtpbin.send_rtp_sink_1 rtpbin.send_rtp_src_1 ! udpsink port=5002 host=192.168.X.X ts-offset=0 name=artpsink rtpbin.send_rtcp_src_1 ! udpsink port=5003 host=192.168.X.X sync=false async=false name=artcpsink udpsrc port=5007 name=artpsrc ! rtpbin.recv_rtcp_sink_1

Récepteur Linux :
gst-launch gstrtpbin name=rtpbin latency=200 udpsrc caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264" port=5000 ! rtpbin.recv_rtp_sink_0 rtpbin. ! rtph264depay ! ffdec_h264 ! xvimagesink udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0 rtpbin.send_rtcp_src_0 ! udpsink port=5005 host=192.168.X.X sync=false async=false udpsrc caps="application/x-rtp,media=(string)audio,clock-rate=(int)8000,encoding-name=(string)PCMA" port=5002 ! rtpbin.recv_rtp_sink_1 rtpbin. ! rtppcmadepay ! alawdec ! audioconvert ! audioresample ! alsasink udpsrc port=5003 ! rtpbin.recv_rtcp_sink_1 rtpbin.send_rtcp_src_1 ! udpsink port=5007 host=192.168.X.X sync=false async=false

J’ai ensuité voulu encoder le son avec le codec Vorbis mais j’obtiens l’erreur :

WARNING: from element /GstPipeline:pipeline0/GstRtpVorbisDepay:rtpvorbisdepay0: Could not decode stream.
Additional debug info:
gstrtpvorbisdepay.c(605): gst_rtp_vorbis_depay_process (): /GstPipeline:pipeline0/GstRtpVorbisDepay:rtpvorbisdepay0:
Could not switch codebooks

J’ai pourtant changé :

– dans le caps : PCMA ==> VORBIS

– alawenc / alawdec ==> vorbisenc/vorbisdec

– rtppcmapay/rtppcmadepay ==> rtpvorbispay/rtpvorbisdepay

Je cherche donc d’où viens l’erreur.

Vendredi 20 mars 2009

En discutant sur le forum de WinBuilds, j’ai appris que le warning qui apparaît lorsqu’on exécute gst-launch pourrait être du à la nouvelle version de FFmpeg qui a été intégrée par Andoni Morales. Il devrait corriger le problème d’ici peu.

J’ai pu corriger le bug de dshowaudiosrc avec l’aide d’une personne via la mailing list de Gstreamer. En effet, j’ai appliqué son patch disponible ici (dernier post) qui m’a permis de résoudre le problème.

=================
TEST SOUS WINDOWS
=================

D’après mes premiers tests il est possible de récupérer le son issu d’un micro et de l’enregistrer dans un fichier comme ceci :
gst-launch-0.10.exe dshowaudiosrc ! audioconvert ! vorbisenc ! oggmux ! filesink location=fichier.ogg

Voici comment écouter le son directement issu du micro :
gst-launch-0.10.exe dshowaudiosrc ! directsoundsink

J’ai commencé par regarder comment encoder et décoder avec Speex. Il se trouve que dans la version de base de windows il n’y a pas de codec Speex.
J’ai pu lire aussi que Speex été soumis à un trou de sécurité connu. Je vérifierai si ce trou existe toujours et s’il est possible d’utiliser le codec Speex ou non.

La semaine prochaine je devrais donc faire ceci, puis tester le streaming entre Windows et Linux avec du son, ainsi qu’avec de la vidéo + du son.

Jeudi 19 mars 2009

Aujourd’hui j’ai donc pu terminer la compilation de Gstreamer WinBuilds (voir billet ci-dessous).

En revanche j’ai remaqué qu’en exécutant l’exécutable, il y a certains warning disant que le fichier libgstffmpeg.dll n’a pu être chargé. Il faudra chercher plus d’informations à propos de cette dll. Et donc vérifier si cela empêchera de faire fonctionner des fonctionnalités. J’ai testé rapidement l’écoute audio et l’affichage de la webcam cela fonctionne. Mais je n’ai pas testé l’encodage, ou le streaming par exemple.

Puis j’ai essayé aussi de résoudre le problème rencontré hier, m’empêchant d’enregistrer le son issu du micro. Apparemment, c’est un problème connu sous Windows. J’ai et je vais donc essayer de résoudre ce problème à partir de demain et essayer de permettre d’utiliser correctement le micro.

Mercredi 18 mars 2009

Une manière simple de tester que le son arrive bien au casque ou aux haut-parleurs est :
– Sous Linux : gst-launch audiotestsrc ! alsasink
– Sous Windows : gst-launch-0.10.exe audiotestsrc ! directsoundsink

Il est possible avec Gstreamer d’enregistrer le son émis du micro dans un fichier.
Sous Linux, voici la ligne de commande pour faire ceci :
gst-launch alsasrc ! audioconvert ! vorbisenc ! oggmux ! filesink location=nom_fichier.ogg

Idée de fonctionnalité : ceci pourrait être utile si on désire enregistrer la conversation pour la réécouter par la suite.

Pensez aussi à vérifier que votre micro fonctionne correctement, et que dans les propriétés du système, il n’est pas mis à muet.

Et voici comment écouter directement le son issu du micro :

gst-launch alsasrc ! alsasink sync=false

Quelqu’un a eu le même problème que moi, et il avait été résolu à cette adresse : ici

En fait, il faut spécifier avec sync=false que l’on ne désire pas de synchronisation.

L’utilisation du micro avec Gstreamer sous Windows ne fonctionne pas. Je cherche d’où vient le problème.

La compilation de Gstreamer sous Windows devrait toucher à sa fin. Il ne reste que deux erreurs à la compilation qui normalement sont dues à deux macros qui manquent. La personne qui se charge de WinBuilds va fixer l’erreur ce soir normalement. Avec un peu de chance, tout devrait compiler demain.

Mardi 17 mars 2009

J’ai effectué d’autres tests de streaming avec le codec theora, avec le protocole RTP cette fois. On peut en tirer les mêmes conclusions que pour l’UDP : sur un réseau local, il n’y a pas vraiment de décalage.
Il faudra néanmoins tester ces deux protocoles sur un réseau bruité, parce que RTP est censé être un peu plus robuste qu’UDP pour le transport vidéo.

En théorie, RTP est censé être plus adapté au transport des paquets. En revanche, ce protocole est un peu contraignant, puisqu’il faut récupérer le caps donné par l’émetteur pour être en mesure de récupérer le flux au niveau du récepteur (voir billet du Jeudi 12 mars 2009).

===========
PASSAGE AU SON
===========

Lecture d’un son issu d’un fichier ogg sous Linux :
gst-launch filesrc location=./Bureau/big_buck_bunny_720p_stereo.ogg ! oggdemux ! vorbisdec ! autoaudiosink

Lecture d’un son issu d’un fichier ogg sous Windows :
gst-launch-0.10.exe filesrc location=big_buck_bunny_480p_stereo.ogg ! oggdemux ! vorbisdec ! audioconvert ! audioresample ! directsoundsink

Je voulais directement entendre le son joué au micro mais je n’y suis pas réussi (je n’ai essayé que sous Linux) mais je continuerai demain.
En effet, j’ai continué la compilation de Gstreamer sous Windows. J’ai résolu un problème qui causait pas mal d’erreurs. Encore quelques unes à corriger et tout devrait compiler correctement. Dans ce cas, je ferai un billet détaillé qui explique pas à pas comment compiler.

Lundi 16 mars 2009

Voici comment on peut afficher l’image de sa webcam, et streamer le flux vers une autre machine :

Serveur Windows :
gst-launch-0.10.exe dshowvideosrc ! video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! queue ! tee name=t ! theoraenc ! udpsink host=192.168.29.96 port=1234 t. ! queue ! ffmpegcolorspace ! directdrawsink

Client Linux :
gst-launch -v udpsrc port=1234 ! theoradec ! autovideosink

=============

Serveur Linux :
gst-launch v4l2src device=/dev/video0 ! video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! queue ! tee name=t ! theoraenc ! udpsink host=192.168.29.83 port=1234 t. ! queue ! ffmpegcolorspace ! xvimagesink

Client Windows :
gst-launch-0.10.exe udpsrc port=1234 ! theoradec ! ffmpegcolorspace ! directdrawsink

Il est à noter que le streaming de cette manière ne fonctionne pas bien lorsque le serveur est sous Linux et le client sous Windows. En effet, le flux est interrompu et Gstreamer s’arrête du côté client.

J’ai testé quelques paramètres d’encodage avec le codec Theora. Notamment le bitrate, quality, quick et sharpness. En fait, les paramètres par défaut sont ceux « optimaux ». Il me reste quelques autres paramètres à tester.

Il est à noter que la taille de la fenêtre d’affichage de la caméra influe sur le temps de décalage. Plus la fenêtre est grande, plus l’image se décale. Sûrement parce qu’il doit y avoir une estimation de mouvement des blocs qui composent l’image. Plus l’image est grande, plus il y a de blocs, plus il faut de temps de calcul. De plus, agrandir la fenêtre, vue la pixelisation, doit demander du temps de calcul en plus pour l’interpolation.

Vendredi 13 mars 2009

Aujourd’hui j’ai continué la compilation de Gstreamer.

Des personnes de la mailing list pensaient que les erreurs venaient du fait que je n’avais ni Perl ni Python. Après les avoir installés, nous nous sommes rendus compte que non.

En parallèle, j’ai continué les tests de streaming entre deux systèmes différents, et j’ai regardé comment fonctionne la classe qui permet de capturer la vidéo à partir d’une webcam.

Jeudi 12 mars 2009

Je continue les tests avec gstreamer.

Le streaming udp de windows à windows fonctionne comme suit :

UDP coté client :
gst-launch-0.10.exe udpsrc port=1234 ! theoradec ! ffmpegcolorspace ! directdrawsink

UDP coté serveur :
gst-launch-0.10.exe dshowvideosrc ! video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! theoraenc ! udpsink host=127.0.0.1 port=1234

Remarque : on peut noter, en comparant les lignes de commandes Linux et Windows que le autovideosink n’est pas supporté sous Windows. Il est remplacé par le directdrawsink.

J’ai poursuivi les tests de streaming, cette fois entre deux machines ayant un OS différent.

=========
Premier test (Protocole UDP, Theora) :
=========

Client Linux, streaming UDP :
gst-launch -v udpsrc port=1234 ! theoradec ! autovideosink

Serveur Windows, streaming UDP :
gst-launch-0.10.exe dshowvideosrc ! video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! theoraenc ! udpsink  host=192.168.X.X port=1234

Dans le cas d’un streaming UDP, il faut lancer le client, ensuite le serveur.

=========
Second test (Protocole UDP, Theora) :
=========

Client Windows, streaming UDP :
gst-launch-0.10.exe udpsrc port=1234 ! theoradec ! ffmpegcolorspace ! directdrawsink

Serveur Linux, streaming UDP :
gst-launch v4l2src device=/dev/video0 ! video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! theoraenc ! udpsink host=192.168.X.X port=1234

Il se peut que le flux ne soit pas reçu et provoque une erreur du type :
ERROR: from element /GstPipeline:pipeline0/GstTheoraDec:theoradec0: Could not decode stream.

Dans ce cas, il faut lancer le client (qui s’est fermé suite à l’erreur) et relancer le serveur, normalement tout devrait fonctionner.

=========
Troisième test (Protocole RTP/RTCP, Theora) :
=========

Serveur Linux, streaming RTP/RTCP :
gst-launch -v v4l2src ! videoscale method=1 ! video/x-raw-yuv !
theoraenc ! rtptheorapay ! .send_rtp_sink gstrtpsession name=session
.send_rtp_src ! udpsink port=5000 host=192.168.X.X
session.send_rtcp_src ! udpsink port=5001 host=192.168.X.X

Client Windows, streaming RTP/RTCP :

gst-launch-0.10.exe udpsrc port=5000 caps ="application/x-rtp, ... seqnum-base=(guint)61692" ! .recv_rtp_sink gstrtpsession name=session .recv_rtp_src ! rtptheoradepay !  theoradec ! ffmpegcolorspace ! directdrawsink udpsrc port=5001 caps="application/x-rtcp" ! session.recv_rtcp_sink

Remarques :
– il faut passer l’option -v du côté serveur pour récupérer la dernière occurence du type « application/x-rtp, … seqnum-base=(guint)61692 » pour pouvoir ensuite spécifier le caps au niveau du client.
– il faut bien sûr lancer le serveur PUIS le client, cette fois.

=========
Quatrième test (Protocole RTP/RTCP, Theora) :
=========

Serveur Windows, streaming RTP/RTCP :
gst-launch-0.10.exe -v dshowvideosrc ! videoscale ! video/x-raw-yuv ! theoraenc ! rtptheorapay ! .send_rtp_sink gstrtpsession name=session .send_rtp_src ! udpsink port=5000 host=192.168.29.96 session.send_rtcp_src ! udpsink port=5001 host=192.168.29.96 > info.txt

Client Linux , streaming RTP/RTCP :

gst-launch udpsrc port=5000 caps="application/x-rtp ... seqnum-base=(guint)6699" ! .recv_rtp_sink gstrtpsession name=session .recv_rtp_src ! rtptheoradepay !  theoradec ! xvimagesink udpsrc port=5001 caps="application/x-rtcp" ! session.recv_rtcp_sink

Remarques :

– les mêmes qu’au troisième test

– on peut penser à rediriger les informations produites dans un fichier texte avec  » > info.txt » pour ne pas encombrer la console. Si le fichier n’existe pas, il sera créé automatiquement, sinon il sera écrasé.

=========
Cinquième test (Protocole RTP/RTCP, H.264) :
=========

Serveur Windows, streaming RTP/RTCP :
gst-launch-0.10.exe -v dshowvideosrc ! videoscale method=1 ! video/x-raw-yuv ! x264enc byte-stream=true bitrate=300 vbv-buf-capacity=300 me=0 subme=3 ! rtph264pay ! .send_rtp_sink gstrtpsession name=session .send_rtp_src ! udpsink port=5000 host=192.168.X.X session.send_rtcp_src ! udpsink port=5001 host=192.168.X.X > info.txt

Client Linux, streaming RTP/RTCP :
gst-launch udpsrc port=5000 caps="application/x-rtp ... seqnum-base=(guint)30502" ! .recv_rtp_sink gstrtpsession name=session .recv_rtp_src ! rtph264depay ! ffdec_h264 ! xvimagesink udpsrc port=5001 caps="application/x-rtcp" ! session.recv_rtcp_sink

Remarques :

– les mêmes qu’au test précédent

=========
Sixième test (Protocole RTP/RTCP, H.264) :
=========

Alors là ça ne marche pas. J’y reviendrai plus tard, car je ne comprends pas pourquoi.

Serveur Linux, streaming RTP/RTCP :
gst-launch -v v4l2src ! videoscale method=1 ! video/x-raw-yuv ! x264enc byte-stream=true bitrate=300 vbv-buf-capacity=300 me=0 subme=3 ! rtph264pay ! .send_rtp_sink gstrtpsession name=session .send_rtp_src ! udpsink port=5000 host=192.168.X.X session.send_rtcp_src ! udpsink port=5001 host=192.168.X.X

Client Windows, streaming RTP/RTCP :
gst-launch-0.10.exe udpsrc port=5000 caps="application/x-rtp ... seqnum-base=(guint)899" ! .recv_rtp_sink gstrtpsession name=session .recv_rtp_src ! rtph264depay ! ffdec_h264 ! directdrawsink udpsrc port=5001 caps="application/x-rtcp" ! session.recv_rtcp_sink

J’obtiens l’erreur suivante :

** (gst-launch-0.10:580): CRITICAL **: file ..\..\gst\gstobject.c: line 348: assertion `((GObject *) object)->ref_count > 0′ failed

** (gst-launch-0.10:580): CRITICAL **: file ..\..\gst\gstobject.c: line 348: assertion `((GObject *) object)->ref_count > 0′ failed

J’avais déjà obtenu cette erreur sur le serveur lorsque la webcam n’était pas branchée. Mais là, c’est différent, c’est sur le client qu’elle apparaît.

=========
Septième et huitième test (ProtocoleUDP, H.264) :
=========

Alors là, dans les deux cas, le streaming ne fonctionne pas :

Client Windows, streaming UDP :
gst-launch-0.10.exe udpsrc port=1234 ! ffdec_h264 ! ffmpegcolorspace ! directdrawsink

Serveur Linux, streaming UDP :
gst-launch v4l2src ! video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! x264enc ! udpsink host=192.168.X.X port=1234

On obtient l’erreur suivante :

GstPipeline:pipeline0/ffdec_h264:ffdec_h2640: ffdec_h264: input format was not set before data start

Mercredi 11 mars 2009

L’installation de gstreamer est très très très longue.
En effet, il faut plusieurs modules pour pouvoir l’installer et l’installation de chaque module prend au minimum 20 minutes voire 30 minutes.

De plus, j’ai rencontré plusieurs problèmes avec mingw qui a des problèmes pour installer plusieurs modules.

Nicolas R. m’a alors conseillé d’utiliser cygwin.
J’ai repris l’installation de gstreamer mais l’installation est toujours aussi longue. Mais, pour le moment je ne rencontre pas les mêmes problèmes de compilation qu’avec minGW.
=============
Edit : fausse joie, le configure marche sans aucun soucis, bien que très long, mais si j’exécute le make file :
Error makefile 993: Colon expected
Error makefile 1019: Colon expected

Je n’arrive donc pas à installer m4 qui va me servir à installer autoconf. Du coup je ne peux pas installer automake puisque autoconf n’est pas installé. Et j’ai besoin de automake et autoconf pour installer gstreamer.
=============
Edit 2 : Finalement, j’ai installé gstreamer via un exe, voici le lien : ici
Je reviendrai plus tard sur la compilation de gstreamer, qui nous sera utile si on veut modifier le code source.
J’ai réalisé deux simples tests :
– l’affichage d’une vidéo provenant d’un fichier :
gst-launch-0.10.exe filesrc location=big_buck_bunny_480p_stereo.ogg ! oggdemux ! theoradec ! ffmpegcolorspace ! directdrawsink
– l’affichage de la vidéo provenant d’une webcam :
gst-launch-0.10.exe dshowvideosrc ! videoscale ! ffmpegcolorspace ! directdrawsink

Comme on peut le constater, les lignes de commandes entre Linux et Windows ne sont pas les mêmes.

Mardi 10 mars 2009

L’installation de gstreamer est plus difficile que prévue.

Après que les problèmes de réseaux aient pu être résolus, j’ai téléchargé et installé minGW qui est une adaptation des logiciels de développement du GNU, à la plate-forme Win32.

J’ai alors procédé à l’installation de gstreamer.
Et c’est là où ont commencé les dominos en cascade…

• Pour installer gstreamer il faut automake.
• Pour installer automake il faut autoconf
• Pour installer autoconf il faut m4
• Pour installer gstreamer il faut ensuite bison

Malheureusement, après installation bison ne fonctionne pas.
Demain, je vais donc voir pourquoi bison ne fonctionne pas et continuer à installer gstreamer.

Lundi 09 mars 2009

Après avoir regardé encore un peu le plugin (notamment la gestion des caps) , j’ai voulu installer gstreamer sous Windows pour effectuer une batterie de tests.

Depuis la version 0.8, la version de gstreamer sous Windows n’est plus supportée. J’ai donc essayé de compiler la version d’origine (la 0.10) pour vérifier si cela fonctionne. Malheureusement non.
C’est en cherchant sur le web que je me suis aperçu que plusieurs autres systèmes avaient été mis en place pour faciliter l’installation : comme OABuild qui n’est plus maintenu et OAH Build.

Mais pour installer OAH Build, il m’a fallu avant tout télécharger et installer Visual Studio Express 2008 ainsi que tous les modules d’OAH Build, ce qui a pris énormément de temps.

Lien pour OABuild : ici
Le lien vers OAH Build se trouve dans la page ci-dessus.

Vendredi 06 mars 2009

Le plugin filtrant en rouge, vert et/ou bleu fonctionne via la pipeline.

Voici comment l’appeler :

gst-launch --gst-plugin-path=$HOME/gst-template/gst-plugin/src/.libs/ v4l2src ! ffmpegcolorspace ! "video/x-raw-rgb,bpp=16,depth=16" ! myvideo ! videoscale ! ffmpegcolorspace ! xvimagesink

En fait, il faut forcer le format, et ne pas oublier d’appeler un ffmpegcolorspace après le v4l2src car la webcam n’est pas capable de produire directement ce genre de format.

Il reste néanmoins un problème : le nombre de couleur est réduit. J’ai donc essayé de forcer avec un autre format (ayant un bpp et depth plus grand), et en changeant le caps dans le code. Mais cela fonctionne mal. J’ai essayé de tatonner et de tester plusieurs caps pour avoir un filtrage qui ne modifie pas le nombre de couleurs, en vain.

La version qui fonctionne utilise un caps : GST_STATIC_CAPS (GST_VIDEO_CAPS_RGB_16). La doc en ligne n’apporte pas d’information quant à son utilisation, elle montre seulement les autres caps RGB possibles.

Jeudi 05 mars 2009

J’ai réussi à tester le plugin d’exemple.

En fait, la procédure est simple. Voici ce qu’il faut faire :

cd src
../tools/make_element testfilter

On obtient 2 fichiers (.c et .h) qu’il faut modifier pour créer son plugin (je vais essayer de détailler ça plus tard quand mon plugin marchera effectivement)

Puis, on modifie le fichier makefile.am pour spécifier le nom de la librairie

Ensuite on excécute le fichier autogen.sh (qui se trouve dans le répertoire parent. Attention, il peut manquer des packages). Si tout est ok, on exécute le makefile.

Normalement, la librairie se placera dans src/.libs

Il faut tester si le plugin fonctionne :

gst-inspect $HOME/gst-template/gst-plugin/src/.libs/libtestfilter.so

Problème qui m’a ralenti : mon plugin ne s’appelait pas « testfilter » mais « plugin » donc il était introuvable…

A partir de ce moment le plugin est utilisable dans la pipeline en utilisant la commande :
gst-launch --gst-plugin-path=$HOME/gst-template/gst-plugin/src/.libs/ fakesrc ! plugin ! fakesink silent=TRUE

La création de mon propre plugin utilisable dans la pipeline se poursuit mais rencontre quelques problèmes.

En effet, mon plugin ne reçoit pas une image RGB. J’ai donc tenté de forcer le format, ou de définir mon propre caps mais lors de l’exécution un message d’erreur annonce : Could not negotiate format.

On peut quand même modifier l’image même si le résultat obtenu n’est pas celui attendu.

Mercredi 04 mars 2009

Lecture du tutoriel pour créer son propre plugin (en anglais)

Création de trois plugins gstreamer qui filtrent le rouge, vert, bleu

Tentative d’utilisation de ces plugins dans la pipeline gstreamer

Mardi 03 mars 2009

Lecture et compréhension du code Java de UBIK
Exploration de gstreamer  (comment fonctionne la pipeline, mixage de vidéos, streaming UDP et TCP)

Exemples qui fonctionnent :

– Mixage des 2 vidéos provenant de 2 webcams :
gst-launch v4l2src device=/dev/video0 ! video/x-raw-yuv ! videobox ! videoscale ! videomixer name=mix ! ffmpegcolorspace ! xvimagesink v4l2src device=/dev/video1 !  video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! mix.

– Streaming UDP simple côté client :
gst-launch -v udpsrc port=1234 ! theoradec ! autovideosink

– Streaming UDP simple côté serveur :
gst-launch v4l2src device=/dev/video0 ! video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! theoraenc ! udpsink host=127.0.0.1 port=1234

Exemples qui ne fonctionnent pas (pourquoi ??) :

– Mixage de 2 vidéos puis envoi en UDP :
gst-launch v4l2src device=/dev/video0 ! video/x-raw-yuv ! videobox ! videoscale ! videomixer name=mix ! ffmpegcolorspace ! xvimagesink v4l2src device=/dev/video1 !  video/x-raw-yuv ! videoscale ! ffmpegcolorspace ! mix. mix.src ! ffenc_h263 ! udpsink host=127.0.0.1 port=1234

On obtient l’erreur : WARNING: erroneous pipeline: could not link mix to ffmpegcsp2

Même en forçant le format vidéo on obtient la même erreur (à noter que videomixer ne gère qu’un seul format)

Le stage va consister en :
– tester gstreamer sur Linux
– tester gstreamer sur Windows
– faire des tests de streaming entre Linux et Windows
-> Voir ce qui ne fonctionne pas
– récupérer les bin qui fonctionnent sous Linux et les recompiler pour qu’ils marchent sur Windows
– développer un plugin qui pourrait être proposé à la communauté gstreamer

Lundi 02 mars 2009

Arrivée dans l’entreprise
Sensibilisation aux risques et aux risques informatiques
Informations sur la vie de l’entreprise, CE, etc.
Découverte des locaux et de l’équipe
Installation de l’OS Ubuntu, des packages, etc.
Découverte de gstreamer
Découverte de UBIK
Tests sur UBIK (maitre de conférence, white board, etc.)