Nouvelle version stable de Jitsi

Posté par  . Modéré par patrick_g.
Étiquettes :
25
5
sept.
2011
Java

Jitsi (anciennement « SIP Communicator ») est un logiciel de VoIP et de messagerie instantanée sous licence LGPL, développé en Java. Il supporte les appels audio‐vidéo via les protocoles SIP et XMPP et la plupart des messageries instantanées comme Windows Live (MSN), XMPP (et donc Google Talk et Facebook), AIM/ICQ, Yahoo! Messenger… Jitsi dispose aussi de fonctionnalités comme le partage de bureau, le chiffrement des appels, l’enregistrement des appels audio et beaucoup d’autres.

Après de nombreux mois de travail intensif, la nouvelle version stable de Jitsi est disponible.

Parmi les changements on retrouve notamment :

  • les appels audio‐vidéo vers les contacts Google Talk (Gmail et Android) ;
  • les appels téléphoniques via Google Voice ;
  • le support du codec audio SILK (utilisé également par Skype) ;
  • vérificateur orthographique ;
  • corrections et améliorations diverses.

Aller plus loin

  • # Et avec Free ?

    Posté par  . Évalué à 2.

    Quelqu'un a-t-il un retour concernant le fonctionnement de Jitsi avec le FAI Free ?

    Je testerai la prochaine fois que j'appelle ma mère.

    • [^] # Re: Et avec Free ?

      Posté par  (site web personnel) . Évalué à 2.

      J'ai soulevé cette question lors d'un post précédent :
      http://linuxfr.org/news/sip-communicator-compatible-xmppjingle

      Depuis ce jour, je n'ai aucun problème avec Jitsi+FreePhonie sur Ubuntu 11.04.

      • [^] # Re: Et avec Free ?

        Posté par  . Évalué à 1.

        Cool, merci. Je testerai ça alors. Car justement depuis que je suis passé à Ubuntu 11.04 je n'arrive plus à passer d'appels via Empathy. Tsss, alors que ça fonctionnait avec quand j'était sue Ubuntu 10.10. Bon, en même temps j'ai pas trop chercher à comprendre… Faut dire que j'appelle rarement ma mère… :-p

      • [^] # Re: Et avec Free ?

        Posté par  . Évalué à 0.

        Je confirme que cela fonctionne bien chez moi avec Ubuntu 11.04 64 bits + Java 64 bits (openjdk)

  • # Sponsorisé par les fabricants de RAM?

    Posté par  (site web personnel) . Évalué à 8.

    Après un rapide test (je m'étais intéressé au différent compétiteurs, mais je l'avais zappé celui-la), il a l'air plutôt pas mal, mêmes sur un des OS du mal, l'interface est agréable (du logiciel liber avec une interface agréable, c'est rare!), il ne me parle pas dans une langue inconnue (il évite les termes techniques pour ce concentrer sur la communication "utile" aux gens), il gère bien les entrées/sorties (par exemple il permet de choisir facilement son entrée ou sortie audio sans parler une langue inconnue par défaut, bon il reste quelques termes genre "JavaSound" gni si on pousse un peu trop mais pour le commun des mortels, il touche pas et la config marche)

    Par contre, la où Pidgin me mange 40 Mo de RAM et Skype taquine les 100 Mo ce que je trouvais déjà limite, Jitsi m'avale 200 Mo le bougre! Je sais que j'ai de quoi faire, mais quand même... Un peu abusé. Bon, en tous cas, Java continue de garder sa réputation de mangeur de RAM. A ne pas mettre sur n'importe quelle machine!

    • [^] # Re: Sponsorisé par les fabricants de RAM?

      Posté par  (site web personnel) . Évalué à 4.

      Effectivement, Jitsi est assez gourmand comparé aux utilitaires précités. J'ai fait le test sur ma machine (64 bits) et j'ai des résultats semblables.

      J'ai réussi à réduire la consommation à 150m en rajoutant les options Java suivantes :
      CLIENTARGS="-Xss128k -Xms64m -Xmx64m -XX:MaxPermSize=64m -XX:+UseCompressedOops". D'ailleurs, je suis étonné qu'il n'y ait pas d'options par défaut pour limiter la Heap et la PermGen.

      J'imagine que la consommation mémoire peut s'expliquer par les bibliothèques tierces dont Jitsi dépend.

      • [^] # Re: Sponsorisé par les fabricants de RAM?

        Posté par  . Évalué à 4.

        Si il arrive à tenir avec 64M de heap, il faudrait tester avec moins de PermGen.
        Même avec une architecture à base de composants, et donc un nombre de classe à charger important, il devrait tenir avec moins de 64M de PermGen.
        (Je ne peux pas tester dans l'immédiat)
        Bon après, il ne descendra pas aux 5M de Miranda :P

    • [^] # Re: Sponsorisé par les fabricants de RAM?

      Posté par  (site web personnel) . Évalué à 4.

      Le problème de voracité de Java en ressources de tous ordres (mémoire, mais également autre) est encore plus flagrant sur de petites configurations :
      j’ai essayé Jitsi sur un eeePC, et là où Jabber ou bien Skype n’ont aucun soucis, Jitsi ne parvenait pas à gérer la vidéo correctement du fait de la surcharge du processeur qu’il occasionnait lui-même.

      Certes, l’eeePC n’est pas une foudre de guerre, mais des logiciels équivalents à Jitsi fonctionnent avec ces ressources, alors que Jitsi les saturent.

      • [^] # Re: Sponsorisé par les fabricants de RAM?

        Posté par  . Évalué à 2.

        Je suis d'accord que Java a effectivement tendance à consommer plus de mémoire qu'une appli native.
        Par contre au niveau de l'utilisation CPU, le JIT de la JVM fait tourner le code avec des performances tout à fait comparable à du C compilé.
        Il me semble qu'en moyenne c'était du 2X plus lent.
        http://www.bytonic.de/html/benchmarks.html

        A partir de là, ça me semble un peu simpliste de penser que java est la cause des mauvaises perfs en vidéo de Jitsi, d'autant plus que le décodage se fait via un appel à des librairies natives (ffmpeg il me semble).
        Je pense plutôt que c'est soit Jitsi qui utilise une sortie vidéo non accélérée, soit qu'il est codé comme un goret (ca me fait penser au cas de Minecraft ça).

        • [^] # Re: Sponsorisé par les fabricants de RAM?

          Posté par  (site web personnel) . Évalué à 4.

          Par contre au niveau de l'utilisation CPU, le JIT de la JVM fait tourner le code avec des performances tout à fait comparable à du C compilé.
          Il me semble qu'en moyenne c'était du 2X plus lent.

          Chez moi, "être comparable à", c'est pas "2x plus lent", mais alors pas du tout.

          • [^] # Re: Sponsorisé par les fabricants de RAM?

            Posté par  . Évalué à 2.

            Les avantages apportés par java face au C/C++ ont évidemment un coût.
            Ce que je voulais dire c'est que ça reste du même ordre de grandeur, contrairement à du PHP / javascript / python / ...
            De toutes façons, pour faire tourner une interface graphique, la vitesse d’exécution du programme n'a que peu d'importance.

            • [^] # Re: Sponsorisé par les fabricants de RAM?

              Posté par  . Évalué à 0.

              Euh, deux fois plus lent, ça n'est pas du même ordre de grandeur. C'est tout même 100% de temps en plus.

              Quand j'encode un DVD et qu'en changeant de codec je passe d'une heure à deux, ce n'est plus du tout comparable.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Sponsorisé par les fabricants de RAM?

                Posté par  (site web personnel) . Évalué à 4.

                Le monsieur a dit (l'emphase est de moi) "De toutes façons, pour faire tourner une interface graphique, la vitesse d’exécution du programme n'a que peu d'importance."

                Entre 0.01 secondes et 0.02 secondes, est-ce "pas comparable" avec tes yeux?

              • [^] # Re: Sponsorisé par les fabricants de RAM?

                Posté par  . Évalué à 1.

                La on parle d'une gui aussi
                Meme si ton logiciel d'encodage etait ecrit en java tu aurais les memes perfs vu que de toutes facons les routines qui font du calcul intensif sont codees en C/Assembleur

        • [^] # Re: Sponsorisé par les fabricants de RAM?

          Posté par  . Évalué à 4.

          Ici, on arrive à moins de deux fois plus lent mais avec java 7. Java 6 a disparu du benchmark http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php?gcc=on&gpp=on&javasteady=on&java=on&cint=on&calc=chart

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Sponsorisé par les fabricants de RAM?

          Posté par  (site web personnel) . Évalué à 4.

          A partir de là, ça me semble un peu simpliste de penser que java est la cause des mauvaises perfs en vidéo de Jitsi, d'autant plus que le décodage se fait via un appel à des librairies natives (ffmpeg il me semble).

          Euh... Je ne connais pas du tout l'architecture de Jitsi, mais la, de ce que tu dis, j'en déduis que si la partie vidéo (la partie qui bouffe du CPU en théorie) est faite par du non-Java, alors c'est soit que les développeurs sont très mauvais codeurs, soit que la partie Java qui a pas besoin de beaucoup de CPU est très très lente au point d'être plus lente que le décodage vidéo.

          Faut faire attention à ce qu'on dit, ça peut être pire pour ce qu'on défend ;-).

          • [^] # Re: Sponsorisé par les fabricants de RAM?

            Posté par  . Évalué à 1.

            soit que la partie Java qui a pas besoin de beaucoup de CPU est très très lente au point d'être plus lente que le décodage vidéo.

            Si c'est le cas, ça serait très étonnant que ça soit du au langage.
            Si une réduction de la vitesse d’exécution par 2 se traduisait par un effondrement des perfs de l'interface graphique, ça serait impossible de coder un programme un poil réactif en python par exemple (en moyenne 50x plus lent que du C à ce que je vois sur un lien posté plus haut).

        • [^] # Re: Sponsorisé par les fabricants de RAM?

          Posté par  . Évalué à 2.

          le JIT de la JVM fait tourner le code avec des performances tout à fait comparable à du C compilé. Il me semble qu'en moyenne c'était du 2X plus lent.

          O_o

          En voilà une bonne phrase pour les politiciens: le chômage n'a pas bougé. Il n'y a que deux fois plus de chômeurs.

          • [^] # Re: Sponsorisé par les fabricants de RAM?

            Posté par  . Évalué à 2.

            Comme déjà dit, on parle d'interface graphique ici, or il y a des gui qui tourne très bien avec python qui est 50 fois plus lent que le C. Donc 2x plus lent pour java, on reste dans le même ordre de grandeur.

            « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Sponsorisé par les fabricants de RAM?

              Posté par  . Évalué à -1.

              Il y a une différence entre une interface Qt en Python et une interface Swing en Java, celle en Python sera plus rapide que celle en Java.

              • [^] # Re: Sponsorisé par les fabricants de RAM?

                Posté par  . Évalué à 1.

                Et il y a beaucoup de chance pour que l'utilisateur ne voit pas la différence (si c'est coder correctement des deux côtés).

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Sponsorisé par les fabricants de RAM?

        Posté par  (site web personnel) . Évalué à 3.

        Certes, l’eeePC n’est pas une foudre de guerre,

        Pour plus de moitié de la population mondiale, l'eeePC est un foudre de guerre (inaccessible vu le prix) qu'il ne peuvent s'offrir.
        Et la ça fait mal : à fonctionnalités identiques, l'un bouffe plus de ressources que l'autre, et pas qu'un peu. Ca confirme donc mon préjugé (qui devient moins préjugé dès que je touche un peu à Java...) sur ce langage. On remplace l'humain par des machines, mais est-ce moins cher de remplacer un humain par plein de machines chères? (au taf, j'ai une fois été choqué qu'il fallait une machine de guerre pour construire 3 stats et afficher 3 camemberts)

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 10.

          Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Sponsorisé par les fabricants de RAM?

          Posté par  (site web personnel) . Évalué à 4.

          Je crois que c'est surtout la compétence qu'on remplace. Je dois encore pouvoir "construire 3 stats et afficher 3 camemberts" sur mes vieilles bécanes avec GnuPlot. Voire en exagérant, sur mon vieux TI99-4A (16 bits à 3,3 MHz, 16 Ko de RAM, stockage sur cassette audio). Mais une personne "normale" ne peut pas. Donc on remplace la compétence, qui vaut cher, par un ordi monstrueux qui vaut cher aussi, mais à qui on ne verse pas de salaire et permet à une personne "normale" de se débrouiller.

          "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

        • [^] # Re: Sponsorisé par les fabricants de RAM?

          Posté par  . Évalué à 3.

          Ce troll est trop velu pour en venir à bout ici : linuxfr étant codé en Ruby, nous allons effondrer le site en court de débat (bing 2ème troll, mince on est pas vendredi).

    • [^] # Re: Sponsorisé par les fabricants de RAM?

      Posté par  . Évalué à 3.

      En parlant des fonctionnalites comparables il est utile de rappeler que Jitsi est a ce jour parmis les seules applications libres a offrir de la video en 640x480. Difficile donc a comparer. L'encodage, et dans une moindre mesure le decodage, H.264 en cette resolution est relativement couteux et effectivement pas forcement dans les capacites d'un eeePC. Dans ces cas la, avant de supposer que le logiciel et la victime d'une equipe incompetente :), l'utilisateur peut facilement baisser la resolution a qqchose de plus abordable pour sa config.

      N'oublions pas non plus que tout le code de Jitsi bien disponible a tous. Tout ceux qui qui croivent pouvoir apporter des optimisations des performances (et les possibilites sont effectivement multiples) sont tout a fait les bienvenus de les proposer sur les mailing listes du projet.

  • # XMPP & Fb

    Posté par  . Évalué à 1. 

    XMPP (et donc Google Talk et Facebook)

    C'est moi qui ne sait pas y faire ou rien n'est compatible avec Fb ?

    Parce que je n'ai jamais réussi à faire communiquer un compte XMPP quelconque (hors Fb) avec un contact Fb. Le mieux que j'ai pu faire c'est utiliser Gajim pour me connecter à mon compte Fb et parler avec mes contacts Fb.

    • [^] # Re: XMPP & Fb

      Posté par  . Évalué à 2.

      Utiliser le protocole XMPP ne signifie pas qu'on peut communiquer avec d'autres serveurs XMPP.

      Parce que je n'ai jamais réussi à faire communiquer un compte XMPP quelconque (hors Fb) avec un contact Fb. Le mieux que j'ai pu faire c'est utiliser Gajim pour me connecter à mon compte Fb et parler avec mes contacts Fb.

      C'est exactement comme ça que c'est conçu, Facebook en a décidé ainsi.

    • [^] # Re: XMPP & Fb

      Posté par  . Évalué à -1.

      XMPP est un protocole et non un fournisseur de service.
      Si tu as un compte FB (facebouc, c'est bien ça ?), tu ne peux communiquer qu'avec tes contacts FB. Même chose pour Gtalk.
      Il y a très peux de services de messagerie instantanée qui reconnaissent les comptes des autres bien que la technologie le permette.
      Il y a MSN et OrangeMessenger mais ce n'est pas du XMPP.
      Il me semble qu'il y avait skyrock et je ne sais plus qui mais ce n'est pas du XMPP.
      Et je crois que Jabber.org permet cela mais je ne sais plus avec qui.

      • [^] # Re: XMPP & Fb

        Posté par  . Évalué à 8.

        Si tu as un compte FB (facebouc, c'est bien ça ?), tu ne peux communiquer qu'avec tes contacts FB. Même chose pour Gtalk.

        Là, je ne suis pas d'accord, avec GTalk (adresse @gmail.com, ou bien utilisant son propre domaine, mais utilisant le service GMail/GTalk), on peut tout à fait parler à des personnes ayant un compte sur jabber.fr par exemple.

    • [^] # Re: XMPP & Fb

      Posté par  (site web personnel) . Évalué à 5.

      ou rien n'est compatible avec Fb ?

      N'inverse pas, correction : Fb est compatible avec rien.
      Plaint-toi auprès de Fb pour qu'ils mettent les passerelles qui vont bien sur leur serveur (ce n'est pas compliqué, juste une question de volonté... Qu'il n'ont pas, et ne sont pas près d'avoir, leurs utilisateurs acceptant assez bien l'enfermement) et alors tu pourras voir le "reste du monde".

  • # Android ?

    Posté par  (site web personnel) . Évalué à 2.

    Y a-t-il une version pour android ?
    Ça serait pas mal, pour remplacer la foison de logiciels nécessaires quand on a plusieurs comptes de messagerie.
    Aah que je regrette mon N900 pour son intégration de la messagerie à l'OS.

    • [^] # Re: Android ?

      Posté par  . Évalué à 4.

      Il y en a une en cours de dev oui (audio + video en SIP et XMPP). On devrait voir les premieres versions vers la fin de l'annee.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.