Journal ekiga et le futur support h263/h264

Posté par .
Tags :
0
25
mai
2007
Suite a la news sur openwengo, j'ai appris que la version svn d'ekiga supporterais le h263/h264.

Etant intéressé, j'ai regardé d'un peu plus près et la c'est la grosse deception.

Le support h263 est assuré par un truc qui date de 3 ans [1] et qui s'appuie sur une vielle version de ffmpeg (celle de l'époque) avec un patch immonde [2] qui n'a jamais été remonté en upstream. Donc ce code ne bénéficiera jamais des amélioration des nouvelles versions de ffmpeg [3] et on devra ce taper plusieurs versions de ffmpeg (la patché et la standard).
Pour le support du h263+ (qui aurait améliorer l'interropabilité avec certains soft), j'ai comme quelque doute...


Le support du h264 n'est pas standard [4] et donc semble utilisable seulement entre 2 softs utilisant opal (donc on peut oublier pour l'utiliser avec d'autres soft pour le moment).

Bref j'ai l'impression que c'est encore loin du truc génial que j'esperais.


[1]
http://www.voxgratia.org/docs/h263_codec.html
[2]
avec plein de retour chariot windows qui pollue le patch, puis si on les retire des modifs commetiques (correction orthographique de commentaires, code qui a bougé, ...) et du code mort.
[3] par exemple un bug h263+ à été corrigé aujourd'hui
[4]
The plugin does not use a standardized framing for MPEG4 in RTP, so
it is not interoperable.
http://sourceforge.net/tracker/download.php?group_id=80674&a(...)
  • # support g729 et g723.1

    Posté par (page perso) . Évalué à 5.

    De même Ekiga ne supporte pas les codecs g729 et g723.1. Je ne parle pas d'un support natif ( car ces codecs sont proprio ), mais de al disponibilité d'un système de plugins pour les codecs permettant d'ajouter facilement le support d'un codec tiers. J'aurai eu ce support du g729/g723.1, j'aurais alors utilisé ekiga pour mon centre d'appel plutôt que de me rabattre sur des téléphones matériel.

    La situation actuelle chez la plupart des fournisseurs de VoIP est qu'ils ne supportent en général que g711/g729 ( voire g723.1 ).
    G711 n'est pas envisageable lorsqu'il faut gérer 60 appel car la bande passant requises pour la ligne serait vraiment trop énorme ( 87.2*60 = 5232 kps, soit une SDSL de 6M, or il vaut mieux avoir la connexion en double pour avoir de la redondance, donc 2 SDSL 6M ).
    Speex est supporté par peu d'opérateur, et il est risqué à mon avis de faire du transcodage d'un codecs à un autre ( g711/speex -> g729/g723.1 ) car cela bouffe du CPU, augmente les risques d'écho ou de lags, ou de dégradation de la voix.

    http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tec(...)
    • [^] # Re: support g729 et g723.1

      Posté par (page perso) . Évalué à 3.

      Je me permet de me corriger moi même. Après lecture de la roadmap de Gnome, il semblerait que la version 3.0 d'Ekiga supportera ce système de plugins. Espérons qu'ensuite il y aura une disponibilité sous une forme ou autre ( implémentation de la version OpenSource d'Intel de ces codecs à but éducatifs, ou version commerciale payante comme le fait Digium ) de ces codecs pour ekiga.
      http://live.gnome.org/RoadMap
    • [^] # Re: support g729 et g723.1

      Posté par . Évalué à 2.

      De même Ekiga ne supporte pas les codecs g729 et g723.1. Je ne parle pas d'un support natif ( car ces codecs sont proprio ),
      Ben se sont des normes tout comme h263 ou h264, donc il est possible d'implémenter des codecs libre dessus.

      En plus il y a moyen de récupérer des draft gratuitement : http://www.itu.int/rec/T-REC-G.723.1-199603-S/fr et http://www.itu.int/rec/T-REC-G.729/fr
      • [^] # Re: support g729 et g723.1

        Posté par . Évalué à 3.

        meme mieux, lTU-T propose les versions pdf gratuitement
      • [^] # Re: support g729 et g723.1

        Posté par . Évalué à 2.

        Ben ya des normes qui sont pleines de brevets. C'est même le but du jeu pour les industriels: faire passer une norme avec des brevets à eux sans que personne ne s'en rende compte. Et ça leur rapporte après car les autres doivent passer à la caisse. Genre G.729. Et c'est un ADPCM qui ne casse pas des briques, donc c'est pas difficile à implémenter. Par contre, tu n'a pas le droit de distribuer n'importe comment. Un autre exemple: le 3GPP fournit le code source des codeurs et décodeurs AMR, mais c'est pas pour autant que t'as le droit de l'utiliser comme bon te semble.
        • [^] # Re: support g729 et g723.1

          Posté par . Évalué à 4.

          Par contre, tu n'a pas le droit de distribuer n'importe comment.
          Oui c'est des histoires de brevet tout comme pour des codec video et on a bien des codecs video h26x libres.

          Un autre exemple: le 3GPP fournit le code source des codeurs et décodeurs AMR, mais c'est pas pour autant que t'as le droit de l'utiliser comme bon te semble.
          La c'est une histoire de copyright tout comme du ne peut pas utiliser comme tu veux ffmpeg (tu dois respecter la LGPL ou la GPL).
  • # Compatibilité

    Posté par . Évalué à 4.

    Bonjour,

    Le support d'H263 dans Ekiga est ce qu'il est, mais cela est quand même une grande avancée pour l'interopérabilité :
    http://wiki.ekiga.org/index.php/Which_programs_work_with_Eki(...)

    Pour tester ce support :
    1- Installer la version SVN d'Ekiga
    Paquets : http://buildserver.net/
    Compilation : http://wiki.ekiga.org/index.php/Additional_Information
    2- Installer le plugin H263:
    http://wiki.ekiga.org/index.php/Additional_Information#H.263(...)

    Toute aide est bien sûr la bienvenue...

    Cordialement,
    Yannick
    • [^] # Re: Compatibilité

      Posté par . Évalué à 4.

      Sur h264,

      Pour le moment il y a MPEG 4 part 2 ; ce n'est pas la même chose qu'h264. H264, c'est MPEG 4 part 10.

      cf. http://fr.wikipedia.org/wiki/MPEG-4

      MPEG 4 part 2 (asp) c'est comme DIVX
      MPEG 4 part 10 c'est comme x264/h264

      Il y quand même une grosse différence (compression double avec h264 et bien plus consommateur de CPU).

      Mais j'espère une bonne surprise pour h264... :)

      Cordialement,
      Yannick
      • [^] # Re: Compatibilité

        Posté par . Évalué à 3.

        Pour le moment il y a MPEG 4 part 2 ; ce n'est pas la même chose qu'h264. H264, c'est MPEG 4 part 10.
        Opps j'ai mal lu, mais dans ce cas quel est l'interet du mpeg4 part 2 sachant que c'est assez similaire au h263. Surtout que ca ma pas l'air tres "standard" (ie les codecs UIT-T sont les plus utilisée).

        http://fr.wikipedia.org/wiki/H.263 :
        l est à noter que la partie baseline de ce codec a aussi servi de fondement au codec video MPEG-4.
        • [^] # Re: Compatibilité

          Posté par . Évalué à 3.

          L'intéret ? Je ne sais pas trop, si ce n'est évidemment que ça doit faire plaisir à ceux qui le programment. Il faudra que je me renseigne plus avant.

          Sur la question du standard, les codecs se négocient dans SIP avant l'établissement de la communication proprement dite ; donc si le client à qui tu souhaites te connecter ne supporte pas MPEG4part2, Ekiga cherchera dans sa liste un autre codec vidéo compatible (comme h263). Il y a déjà quelques clients qui font usage de MPEG4part2 comme linphone (linux et beta pour windows) ou kapanga (propriétaire et payant pour avoir ce codec sous windows) et peut-être d'autres...

          Cordialement,
          Yannick
      • [^] # Re: Compatibilité

        Posté par . Évalué à 2.

        Au passage sur que x264 est GPL et qu'opal est pas compatible avec la GPL, on peut se gratter pour le h264 sur ekiga...
        • [^] # Re: Compatibilité

          Posté par . Évalué à 2.

          Au passage sur que x264 est GPL et qu'opal est pas compatible avec la GPL, on peut se gratter pour le h264 sur ekiga...


          Et pourtant :

          Roadmap for 3.00

          Video Features

          * Support for H.264 (Matthias)


          http://wiki.ekiga.org/index.php/Roadmap_to_3.00

          Et je l'ai testé, ça marche avec x264 (SVN) ;)

          Parfois on peut contourner...

          Cordialement,
          Yannick

Suivre le flux des commentaires

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