Journal Dear Google,

Posté par (page perso) .
Tags : aucun
31
21
fév.
2010
C'est par ces mots que commence une lettre ouverte adressée par la FSF au géant de l'Internet.

La fondation du logiciel libre espère que la firme à qui appartient la plus grande plateforme de vidéos du Web, j'ai nommé YouTube, puisse faire l'effort de libérer les utilisateurs de deux fléaux qui leur portent atteinte : Adobe Flash et le codec H.264.

Comment ? Google a récemment fait l'acquisition de On2 Technologies, les auteurs entre autres du codec VP3 utilisé dans le format libre Ogg Theora. Le codec VP3 étant plutôt dépassé, Google met la main sur des technologies beaucoup plus intéressantes, et notamment le dernier VP8, qui est un sérieux concurrent de H.264. C'est donc tout naturellement que la FSF propose à Google de libérer VP8 et d'en faire un standard en l'utilisant pour les vidéos de son site YouTube.

Cela signifierait la naissance d'une nouvelle norme, et avec HTML5, plus besoin ni du codec breveté, ni du lourd logiciel propriétaire qui fait tourner la majorité des vidéos du Web.

We all want you to do the right thing. Free VP8, and use it on YouTube!

http://www.fsf.org/blogs/community/google-free-on2-vp8-for-y(...)
  • # ...

    Posté par . Évalué à 6.

    We all want you to do the right thing. Free VP8, and use it on YouTube!
    And make all android phone not able to play youtube video anymore.


    Et oui, il faut pas oublier qu'une partie des utilisateurs de youtube n'ont pas le choix du codec (support hardware)...
    • [^] # Re: ...

      Posté par . Évalué à 10.

      Avec HTML5, les vidéos sur internet sont appelées à évoluer de toute façon.
      Les vidéos flash ne sont pas prêtes de disparaître, par contre il y aura le flash actuel, et la balise "video" HTML5 en parallèle.
      Alors sous Androïd t'auras toujours l'actuel, le flash kipuképalibre.
      Et dans deux ans quand le flash commencera à disparaître pour les vidéos, de toute façon Androïd sera dépassé, aura évolué, ton téléphone sera recyclé, et ta remarque sera oubliée, voilà...

      Yth, non ?
      • [^] # Re: ...

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

        Ce n'est pas une question de flash ici. Les androphones disposent d'une puce d'accélération matérielle pour la lecture vidéo, qui supporte H.264. Et probablement pas VP8. Et les androphones ne sont pas les seuls, c'est le cas de la plupart des matériels mobiles, à ma connaissance.

        Le Ogg a su apparaitre petit à petit sur les balladeurs, et encore ça reste assez timide, alors est-ce que un format libre pour la vidéo va finir par devenir suffisamment standard pour être utilisable en alternative à H.264, pour l'instant cela ne me parait pas certain, même si VP8 est libéré d'ailleurs.

        Pour tout ce qui est appareils mobiles ou l'implémentation matérielle compte beaucoup, c'est pas gagné tout ça.
        • [^] # Re: ...

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

          Les androphones disposent d'une puce d'accélération matérielle pour la lecture vidéo, qui supporte H.264. Et probablement pas VP8.

          Si VP8 arrive à la cheville de H.264 (car la lettre pointe un lien qui dit que Theora est meilleur, mais d'autres ont essayé, et n'arrivent pas à la même conclusion... Très loin de la. Sa démonstration a juste montré que Youtube devrait changer de compresseur H.264 pour avoir une meilleure qualité, car le sien est actuellement pas terrible, sans avoir à changer autre chose.), et que donc ça ne coûte pas plus cher de diffuser en VP8 qu'en H.264 pour une qualité donnée, pourquoi ne pas proposer les deux et après l'utilisateur choisit!

          La principale critique faite à Theora est sa qualité de compression, mauvaise, ce qui fait exploser du coup le prix de diffusion. Ceci enlevé par un VP8, il ne resterai qu'un moindre coût de duplication de la chaine de compression et du stockage, ce qui peut être acceptable en terme de coût (c'est rien par rapport au coût de la bande passante), et la, ça vaudrait le coup de pousser un format vidéo libre (car au final, de bout en bout, moins cher que H.264, contrairement à Theora qui est aujourd'hui plus cher du fait de son besoin de bande passante) pour se débarrasser des royalties de H.264.

          Maintenant, il reste à savoir si cette technologie "VP8" mérite vraiment qu'on s'y attarde, peut-être que c'est juste un "pétard mouillé", des formats vidéos révolutionnaires sur la papier, on en a déjà vu plein... Et personne en pratique. Et il faudrait plus qu'une qualité équivalente, il faut plus de "features" et de la meilleure performance, car on l'a vu avec Vorbis, le fait d'être un peu meilleur que MP3 ne lui a pas suffit pour être diffusé, et se fait maintenant écrasé par AAC (dommage, coup manqué pour l'audio libre). Quand on arrive après la bataille initiale, il faut avoir de sacrés avantages pour détrôner le roi, pas seulement la liberté (Vorbis n'a pas détrôné MP3, DisplayPort n'a pas détrôné HDMI etc...)
          • [^] # Re: ...

            Posté par . Évalué à 8.

            je n'ai pas de liens malheureusement, mais youtube, c'est 15 heures de vidéo ajoutées à la minute...

            j'imagine qu'ils ont creusé la question du "comment on les compresse, nos videos". On peut montrer le tout et son contraire, mais si le VP8 et ses brevets sont libérés, alors déjà, on autorisera les développeurs du libre à travailler légalement sur un "compresseur" avec plus de moyens.

            P.-S. : le codec VP3 était à 2 Db du H.264, avec les dernières évolution du "compresseur". C'était déjà pas mal, même si ça n'était pas reproductible sur tout type de vidéo. Si le VP8 est libéré, le temps jouera en sa faveur.
        • [^] # Re: ...

          Posté par . Évalué à 9.

          Le support hardware est souvent un DSP spécialisé. Si le codec est basé sur la même transformation de base que le H264, il n'y a pas de problème (idct ?)

          "La première sécurité est la liberté"

          • [^] # Re: ...

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

            Saut si ... les bloc d'accélération hardware sont spécifiques aux codecs de type MPEG, très (trop !) différents des VP3 et VP8...
            Quand ont connais le coût du hardware et la part de marché du H264 (c'est pas seulement sur internet, mais en TV numérique, BluRay, ...)
            • [^] # Re: ...

              Posté par . Évalué à 6.

              Comme je viens de l'écrire, les accélérateurs hardware sont des DSP depuis que l'on fait plus compliqué que le mpeg2. Donc, changer de codec, c'est simplement changer de firmeware.

              La seul limite potentiel, c'est le type de transformé utilisé. La transformé peut prendre 90% de temps cpu, pour 5% de la taille du source du codec.

              C'était le soucis du support du ogg sur les dsp mp3.

              Si l'idct du mpeg est cablé, même partiellement, cela parait difficile de la remplacer par une transformé ondelette. Il faut que le reste du dsp soit suffisamment puissant ou que celui-ci soit généraliste. Par exemple, dans les OMAP 34xx et 44xx, c'est un DSP C64, assez généraliste qui est présent (il est dans le Palm Pre).

              "La première sécurité est la liberté"

              • [^] # Re: ...

                Posté par . Évalué à 3.

                oui mais ton fournisseur ne changera pas le code de ton accelerateur apres l'avoir vendu, ou alors il faut lui payer très très cher.

                Oui les puces d'accélération actuelles sont toutes basées sur un DSP, donc c'est tout a fait envisageable d'avoir un support DSP pour le VP8 mais la vrai question est est ce que les fournisseurs vont le faire?

                La réponse tient dans la force marketing et commerciale de google...

                Gaetan
                • [^] # Re: ...

                  Posté par . Évalué à 1.

                  Pas seulement. Free met encore à jour les codecs pour sa freebox V5.

                  "La première sécurité est la liberté"

                  • [^] # Re: ...

                    Posté par . Évalué à 2.

                    Pour info, voici un document (marketing) intéressant:
                    http://docs.google.com/viewer?a=v&q=cache:kF2-rx8AgpYJ:w(...)

                    En gros, VP8 serait plus efficace que H.264. Bien bien bien. Sauf que sans plus d'info, et surtout sans une vrai comparaison a haute résolution (pour le CIF, c'est cool, mais pour le VGA ou le 720p?)
                    • [^] # Re: ...

                      Posté par (page perso) . Évalué à -4.

                      C'est ça qui est rigolo : personne ne peut dire si ce codec est bon, que des suppositions, mais les libristes se jettent dessus pour "oublier" les perfs de Theora qui se font descendre, en imaginant qu'une petite boite aura réussi à faire mieux que les milliers d'entreprises autour de H.264 dans tous les domaines (H.264 ayant le gros avantage d'être très universel...).

                      Mais en pratique, toujours le néant...
                      • [^] # Re: ...

                        Posté par . Évalué à 6.

                        Je suis pas d'accord. On2 a une très bonne histoire derrier eux, VP6 est par défaut sur flash 8 et 9 (et a été remplacé par H.264 sans doute pour cause du déploiment des accélérateurs matériel). C'est loin d'être une boite de neuneu.

                        D'expérience, je peux t'assurer qu'une petite équipe bien taillée peu pondre un codec bien plus optimiser qu'une grande boite de plusieurs dizaines de milliers de développeur. Après, c'est la force commerciale qui entre en jeu.

                        H.264 a de gros avantage, mais on est dans un monde qui évolue, rien n'est perdu.
                      • [^] # Re: ...

                        Posté par . Évalué à 9.

                        en imaginant qu'une petite boite aura réussi à faire mieux que les milliers d'entreprises autour de H.264
                        10 000 claviers feraient mieux que 10 bon claviers ?

                        Il faut arrêter avec ce truc de décideur. Parfois, peu de clavier avec les bonnes personnes derriere feront mieux que plein de clavier avec des équipes en pagaille derrière.
                        Je suis ni pour ni contre (bien au contraire) VP8 mais bon, ce genre d'argument pour h264...
                        • [^] # Re: ...

                          Posté par (page perso) . Évalué à -1.

                          Mmm, mouais, je me suis mal exprimé.
                          Disons que je veux voir. Plein de boites disent qu'ils font mieux, et après on voit que c'est le contraire.

                          Je reste sceptique tant que je n'ai rien vu. On2 était effectivement pas mauvais, avec de bons codecs avant H.264. Ont-ils fait mieux maintenant? Si oui, qu'on le prouve! En attendant, Adobe est passé de VP6 à H.264... Ce qui ne laisse augurer rien de bon.
                        • [^] # Re: ...

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

                          Avec une infinité de clavier et une infinité de singes, on peu produire une infinité de codec, y compris les infiniment meilleurs.
                  • [^] # Re: ...

                    Posté par . Évalué à -1.

                    Dans les freebox, le codec est entierement claque en dur. Il n'y a pas encore moyen de tenir la HD juste avec du firmware...

                    La preuve c'est qu'il a fallu changer toutes les freebox pour pouvoir faire de la HD et qu'il va encore falloir les changer pour qu'elles supportent SVC
                    • [^] # Re: ...

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

                      Les freebox pre V4 géréaient que le MPEG2, là elles étaient peut être en dur, j'en sais rien.
                      Mais pour la freebox HD, comme dit au dessus le H264 est beaucoup trop compliqué pour faire du décodage en dur, tout passe par un DSP.
                      Bon après ça n'empeche pas qu'ils devront en sortir une autre pour le SVC je pense, mais juste parce que ça demande beaucoup plus de puissance, et parce que leur fournisseur ne s'amusera sûrement pas à faire des mises à jours pour le plaisir.
                    • [^] # Re: ...

                      Posté par . Évalué à -5.

                      Quand on n'y connaît rien, on ferme sa gueule ...
                      • [^] # Re: ...

                        Posté par . Évalué à -2.

                        Ben prouve moi que j'ai tort ! Le thread (plus en bas) montre que j'ai raison

                        Alors t'es bien mignon de venir vomir toute ta haine de petit con merdeux en venant me repondre sans aucun argument concret mais en prenant bien soin de me pourrir la gueule a chaque fois mais tu es prie de trouver une autre solution a tes problemes perso.
                  • [^] # Re: ...

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

                    Free ne met pas à jour de codec, seulement le ""décontenenceur"", ie la glue entre le DSP et le disque dur.
                    Le firmware du DSP reste constant, il suffit d'aller voir la doc du dsp de la freebox pour voir la liste des codecs supportés.
                • [^] # Re: ...

                  Posté par . Évalué à 1.

                  Oui les puces d'accélération actuelles sont toutes basées sur un DSP, donc c'est tout a fait envisageable d'avoir un support DSP pour le VP8 mais la vrai question est est ce que les fournisseurs vont le faire?

                  Moi j'ai une autre proposition : qu'on libère les specs des DSP pour pouvoir les programmer avec des outils libres. Un peu comme Intel a libéré les specs du x86. (je parle donc juste de "l'ISA" du DSP, si on peut dire)

                  Comme indiqué plus bas, TI met beaucoup de C64x dans ses SoCs récents, et ce DSP est basé sur une archi qui a largement plus de 20 ans. Mais cette archi a toujours été un secret super bien gardé et méga fermé. Aujourd'hui, les DSP sont de plus en plus répandus dans le grand public, ça me paraîtrait normal de les "libérer" un peu.

                  Ça permettra d'éviter d'avoir toutes ces emmerdes avec les industriels qui utilisent leur matos comme moyen de pression sur des choses qui vont pour moi bien au-delà de leurs prérogatives.
                  • [^] # Re: ...

                    Posté par . Évalué à 1.

                    la plupars du temps les proc AP sont basé sur des architectures MIPS dans les set top box. Les coeurs dsp sont assez spécialisé et différent des TI ou autre Freescale (voir Broadcom, ST, ...).

                    Oui si tout était libre se serait mieux, mais ça ne l'est pas. Néanmoins, programmer pour un DSP c'est une autre pair de manche que de coder sur un processeur s x86 ou arm : pas d'émulateur cycle accurate, il faut une board de développement, des outils de compilations proprio et cher... pas à la porté de tout le monde. Et surtout, ça va trop trop vite...
                    • [^] # Re: ...

                      Posté par . Évalué à 1.

                      Oui si tout était libre se serait mieux, mais ça ne l'est pas.

                      Je ne parle même pas d'être "libre", je parle juste d'avoir l'équivalent de l'ISA x86 pour DSP ! Juste : c'est quoi les opcodes, les opérandes, et basta. C'est la base d'une ouverture ! Et après on se demande pourquoi Intel est toujours hégémonique alors que son archi est pourrie ... Depuis le premier x86, ils ont une archi _ouverte_ ! C'est pas dure à comprendre.

                      Néanmoins, programmer pour un DSP c'est une autre pair de manche que de coder sur un processeur s x86 ou arm : pas d'émulateur cycle accurate, il faut une board de développement, des outils de compilations proprio et cher... pas à la porté de tout le monde. Et surtout, ça va trop trop vite...

                      Bravo, tu viens de sortir tous les clichés et excuses à deux balles qu'on pourrait sortir pour n'importe quel produit avant qu'il soit ouvert.

                      - pas d'émulateur de cycle accurate : ça veut dire quoi ? Que ton compilo va pas sortir du code optimal ? Et alors, on s'en branle, au moins on aura du code qui marche ! Si tu savais tous les codes libres qui ne sont pas optimaux par rapport à du proprio ...

                      - il faut une board de développement : depuis quand ? Les machines actuelles exécutent bien le code qu'on leur donne ... Ha oui, tu pourras pas débugger ; bof, je suis sûr qu'on pourra s'en passer. Et surtout, je ne vois pas en quoi ce serait une excuse "contre" ...

                      - des outils de compilations proprio et cher : bah oui justement, c'est le but de l'ouverture : pourvoir s'en passer ...

                      - Et surtout, ça va trop trop vite... : de quoi tu parles ? Si tu parles de l'évolution de l'archi, comme j'ai dit, celle de TI date de 1983 ...
              • [^] # Re: ...

                Posté par . Évalué à -1.

                C'est completement faux ! Ce que tu dis est vrai seulement pour de la SD, ce qui est qd mm super limitant

                Il n'y a pas moyen de tenir de la HD avec du pur soft. Aujourd'hui il faut au minimum avoir en dur l'idct, l'xpred et le decodage vld si tu veux tenir de la HD 1080p

                Franchement si c'etait possible de faire de la HD en pur soft tu aurais 15 000 acteurs sur le marche, ce qui est loin d'etre le cas aujourd'hui

                http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC_products_and_i(...)
                • [^] # Re: ...

                  Posté par . Évalué à 4.

                  Je ne connais pas les détails mais l'omap 3430 fait au moins du 720p avec un C64 à peine modifié. (pour info, j'ai bossé à coté de l'équipe à l'origine du codec)

                  "La première sécurité est la liberté"

                  • [^] # Re: ...

                    Posté par . Évalué à 3.

                    Effectivement on peut avoir du 720p, au dela il faut passer par un reseau de processeurs... ce qui est aujourd'hui tout juste implementable. C'est relativement nouveau et ce qui n'etait pas le cas a l'epoque de la sortie de h264.

                    D'ailleurs, ce sera pas assez puissant pour du svc et on va revenir vers du hw dedie...

                    Pour info, je bosse a l'implentation de ces fameux codecs ;-)
                    • [^] # Re: ...

                      Posté par . Évalué à 0.

                      Tu bosses pour Ti ? Je croyais que l'équipe avait été "transféré" en Inde ?

                      Si tu bosses pour eux, tu dois avoir les specs du 4430 (que je n'ai plus en tête) et cela m'étonnerait qu'il ne puisse pas gérer le 1080p.

                      "La première sécurité est la liberté"

                      • [^] # Re: ...

                        Posté par . Évalué à 4.

                        Non je ne bosse pas pour TI mais pour ST.

                        Pour le 4430, il supporte effectivement du 1080p mais c'est bien grace a une IP:

                        +Hardwired codecs deliver high performance at low power levels
                        +IVA 3 hardware accelerators enable full HD 1080p, multi-standard video encode/decode

                        Apres ils ont effectivement laisse des DSP pour pouvoir gerer d'autre codecs.. et je suis pret a parier qu'ils ne supporteront que de la SD !

                        + Programmable DSP provides flexibility for future codecs

                        http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp(...)
                        • [^] # Re: ...

                          Posté par . Évalué à 4.

                          Les 3430 c'était deux processeurs genre VLIW, rien de hardcodé du tout. Ça ressemble à des DSP, quoi. Et c'est complètement programmable ! C'est juste que tu n'y a pas accès !

                          Arrête 2s de lire les brochures marketing et regarde vraiment ce qu'il y a dans le hard. C'est ça que je n'aime pas avec les boîtes qui font du proprio à mort, c'est que c'est très dur de discuter dessus vu le peu d'info qui filtre, et après on a les mecs qui "bossent dessus" qui viennent se la péter en disant "moa je sais", tout en ne pouvant rien dire, bien sûr. Et donc il faut les vénérer, toussa. Horrible.
                          • [^] # Re: ...

                            Posté par . Évalué à 4.

                            Bon, dans la précipitation, je parlais du 3430 alors que je voulais parler complètement d'autre chose, comme tu parlais de ST .... je voulais parler du ST7100. Mea culpa.
                          • [^] # Re: ...

                            Posté par . Évalué à 2.

                            Je parlais du 4430 qui lui est hardcorde d'apres le brochure, ce qui n'empeche pas d'embarquer un DSP .

                            La serie 3430-1440 passe bien par un DSP mais ne tient que la SD toujours d'apres le brochure (oui je sais c'est depasse de se fier a une brochure ;-) )

                            Et puis bon, le coup du «je bosse dans le metier» c'etait juste pour repondre a Nicolas qui disait lui aussi avoir bosser dedans... bref rien de pedant ou quoi et lui l'a tres bien percu comme ca
                            • [^] # Re: ...

                              Posté par . Évalué à 0.

                              Le 4430 qui contient l'IVA HD supporte le codage et le décodage 1080p.

                              L'IVA HD, c'est 2 cpus de gestion + un C64.

                              "La première sécurité est la liberté"

                            • [^] # Re: ...

                              Posté par . Évalué à -1.

                              Bon, alors va falloir que t'apprennes ce qu'est une brochure : du marketing à deux balles pour te faire avaler le coup de la puce "super spéciale et géniale de chez nous". Moi je suis un techos, je veux du concret, pas un "ça vient d'une brochure" (surtout pour un mec qui se dit du milieu ... ça me fait doucement marrer).

                              Ensuite, parlant du 3430 (je ne connais pas le 4430 mais je suppose qu'il doit y ressembler) il ne contient _que_ un CPU, un DSP, et une CG. Il n'y a _pas_ de soit disant "accélérateur hard". L'IVA c'est une invention marketing qui représente que que fait le C64x : ça ne correspond à aucune brique matérielle réelle ; ou alors, ça correspond au DSP, si tu veux.

                              C'est ça qui est chiant dans ce domaine, c'est que c'est très dur d'avoir les infos : TI garde à mort celles sur son DSP, et ImgTech celles sur sa CG. Mais n'empêche, _tout_ le processus de décodage SD/HD est _reprogrammable_. Arrête de dire "j'ai raison" sans n'avoir rien apporté d'autre qu'une "brochure".

                              Voilà, je n'aime pas du tout les mecs qui balancent deux infos laconiques, sortent des mots savants, se disent du métier et qui se font plusser, alors qu'ils n'y connaissent rien.
                              • [^] # Re: ...

                                Posté par . Évalué à 2.

                                Voilà, je n'aime pas du tout les mecs qui balancent deux infos laconiques, sortent des mots savants, se disent du métier et qui se font plusser, alors qu'ils n'y connaissent rien.

                                Ca c'est bien vrai, les mecs qui balancent 1 ligne d'insultes sans aucun argument c'est vachement mieux!

                                http://linuxfr.org/comments/1107635.html#1107635
                          • [^] # Re: ...

                            Posté par . Évalué à 1.

                            Pas du tout, le 3430 c'est avant tout un ARM qui pilote les autres cœurs (principalement des dsp). Pas du tout VLIW.
                            • [^] # Re: ...

                              Posté par . Évalué à 2.

                              C'est le C64 à coté du Cortex A8 qui est vliw ! (8 voies de mémoire)

                              "La première sécurité est la liberté"

                            • [^] # Re: ...

                              Posté par . Évalué à 2.

                              Comme je disais en réponse à mon commentaire, je me suis trompé : je parlais du ST7100, qui est un CPU généraliste (ARM ou MIPS, je sais pu) + 2 copro VLIW.

                              Quant au 3430, c'est un ARM qui "contrôle" _un_ DSP : de quoi tu parles en disant les "autres cœurs" ?
                    • [^] # Re: ...

                      Posté par . Évalué à 2.

                      Tiens, en parlant de dire n'importe quoi, ce qu'ajoute le SVC en "complexité", c'est juste au niveau du multi-résolution ; les algos sont _exactement_ les mêmes que H264. Bref, devoir "revenir vers du hw dédié" juste pour ça me paraît encore une grosse connerie.
                      • [^] # Re: ...

                        Posté par . Évalué à 2.

                        Oui ca fait juste 15 ans que tout le monde hesite a introduire la scalabilite spatiale tellement c'est une bonne grosse pelote de laine et toi tu en parles comme d'une petite feature, un petit rien du tout...

                        On se demande bien d'ailleurs pourquoi ils ont pris la peine de ne rajouter «juste» que ca dans SVC puisque c'est si facile
                        • [^] # Re: ...

                          Posté par . Évalué à 2.

                          Je ne dis pas que c'est un problème simple, je dis que c'est un problème qui ne nécessite pas un "hw dédié" à faire. Algorithmiquement ça peut être très compliqué, mais ne pas non plus requérir une puissance de calcul de fou.
                  • [^] # Re: ...

                    Posté par . Évalué à 0.

                    Le 3430 a un coeur de décodage (IVA basé sur un coeur c64) qui s'occupe des traitements lourds des decodeurs. Il est donc capable de décoder du 720p pour l'envoyer au coeur ARM Cotex A8.
                    http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp(...)
                    • [^] # Re: ...

                      Posté par . Évalué à 2.

                      C'est merveilleux ton lien explique la puce ne supporte que de la SD !

                      The increased capabilities of the IVA2+ enables multi-standard (MPEG4, H264, Windows Media Video, RealVideo etc.) encode and decode at DVD resolutions.
                      • [^] # Re: ...

                        Posté par . Évalué à 0.

                        bon, et alors tu t'es jamais planté dans la vie?
                        3440 is better
                        http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp(...)
                        • [^] # Re: ...

                          Posté par . Évalué à 1.

                          Bah si je me suis deja plante, pas de probleme !

                          D'ailleurs le decodage sur le 3440 se fait toujours a 720x480 pixels, il y a juste un display en 720p car la camera permet d'enregistrer en 720p

                          Bref, je vais me radoter mais bon le decodage 1080p se fait via un HW dedie, c'est actuellement la solution la plus utilisee.
                • [^] # Re: ...

                  Posté par . Évalué à 1.

                  Mon Athlon fait presque du 1080p fluide (mais c'est le plus bas de gamme) avec uniquement la conversion YUV->RGB faite par la CG (sortie xv). Bref, tu dis n'importe quoi.
                  • [^] # Re: ...

                    Posté par . Évalué à 4.

                    Et ton Athlon, il tient dans ta poche ou dans le boitier cable/ADSL au dessus de ta tele? Ah ben non, c'est con.

                    Du coup retour a la case depart. L'auteur initial aurait du preciser pour eviter les grincheux et les arguments debiles: sur terminaux mobiles la HD en pur soft est impossible (soit par manque de puissance, soit pour pas griller la batterie beaucoup trop vite)
                    • [^] # Re: ...

                      Posté par . Évalué à 1.

                      Oui enfin bon l'auteur ayant complètement déformé le propos de Nicolas qui parlait de DSP reprogrammable en le transformant en "pur soft", ça commence mal.
                      • [^] # Re: ...

                        Posté par . Évalué à 1.

                        Excuse moi si le sujet du thread etait sur le partitionnement hard/soft des decodeurs embarques.

                        Ya mes mots, et il y a le contexte de la reponse... l'intelligence est censee faire le reste.
                  • [^] # Re: ...

                    Posté par . Évalué à 2.

                    Ah, cool!

                    Donc si on resumes, ton athlon n'arrive pas a decoder du 1080p, meme en laissant la conversion yuv/rgb a la carte video.

                    Tu en conclus tout a fait logiquement que puisque ton ensemble cpu + carte graphique (probablement 100 fois plus puissant que n'importe quel peripherique embarque et qui consomment a eux seul 3 fois plus) n'y arrive pas en soft, alors c'est possible de le faire en soft et que par consequent il dit n'importe quoi ?

                    C'est moi ou la logique m'echappe?
                    • [^] # Re: ...

                      Posté par . Évalué à 3.

                      Nan mais pour recentrer, on parlait donc de chip programmable, genre un DSP, et non de "pur soft" (ce qui peut vouloir dire tout et n'importe quoi). Je te dis qu'un processeur généraliste K8 à 2,5GHz, vendu comme 45W pour un dual-core soit 22W pour un, ce qui reste raisonnable même si c'est toujours un peu au dessus de ce que peut supporter l'embarqué, permet déjà de faire ça. Donc le moindre DSP un tant soit peu capable dans ce monde pourra largement faire du 1080p. Contrairement à ce que dit flagos.
                      • [^] # Re: ...

                        Posté par . Évalué à 1.

                        nan, mais j'avais compris la premiere fois c'est pas en le repetant que ca va changer le fait que ta logique est tordue: ton point, c'est qu'un monstre de puissance avec 2 coeurs couple a une carte graphique n'y arrive pas, et que donc un dsp peut y arriver.
                        • [^] # Re: ...

                          Posté par . Évalué à 3.

                          on point, c'est qu'un monstre de puissance avec 2 coeurs couple a une carte graphique n'y arrive pas, et que donc un dsp peut y arriver.

                          (j'ai dit que ça n'utilisait qu'un cœur) Oui, y arrive presque, et ?
                          • [^] # Re: ...

                            Posté par . Évalué à 1.

                            ben je sais pas, tu debarques, insultes la moitie des participants, fait des assomption a l'emporte piece sur le SVC ou l'archi du 4430 que tu dis toi meme ne pas connaitre) et nous sort comme unique argument que puisqu'un monstre de puissance n'arrive pas a decoder proprement une video meme en etant aide pour la conversion vers rgb, ca prouve qu'un dsp completement different et avec moins de puissance de calcul brute peut y arriver.

                            Que ton cpu qui est plus grand que l'ecran d'un ipod video et a lui seul consomme deja plus qu'un ipod touch n'arrive pas a decoder du full hd, ca nous fait un peu une belle jambe...

                            Bref, entre ca et le ton de tes reponses j'ai envie de te repondre:
                            Moi je suis un techos, je veux du concret, pas un "puisqu'un cpu plus puissant y arrive pas, ca prouve qu'un dsp y arrive" (surtout pour un mec qui ouvre sa gueule grand comme une bouche d'egout ... ça me fait doucement marrer).
                            • [^] # Re: ...

                              Posté par . Évalué à 0.

                              Bon, j'en ai marre des gens à côté de la plaque ; ce genre de discussion mène toujours à ça car les gens parlent sur du vent, à propos de technologies tellement fermées que c'est impossible d'y arriver sans qu'un mec sorte un "je sais parfaitement que ...". C'est pour ça que je demande du concret. Ce que personne ne me donne jamais (je viens de retrouver une discussion sur le même sujet il y a 6 mois ici avec le même flagos qui sort les mêmes propos non vérifiés).

                              Pour revenir au point de départ (relire le journal) : le décodage soit-disant "hard" du H264, même dans l'embarqué, peut parfaitement être reprogrammé pour décoder du Théora, ou du VP8, ou quoi que ce soit de puissance équivalente (cette remarques est pour éviter qu'on me sorte du SVC ou du 1080p, qui sont des arguments inutiles ici balancés pour pourrir le débat). Il "suffit" de changer la partie soft (le firmware). C'est dur dans le sens où il n'y a pas de volonté industrielle vers ça pour l'instant, mais il n'y a aucune barrière technique.

                              Et d'ailleurs, comme je disais plus haut, ce serait vachement plus simple si les DSP étaient ouvert : on n'aurait pas ce problème.
                              • [^] # Re: ...

                                Posté par . Évalué à 1.

                                Bon, j'en ai marre des gens à côté de la plaque
                                Heu, attends, tu gueules comme un putois, insultes tout ce qui passe a portee de postillons, tu te la joues briaeros a demander des sources sans bien evidemment sourcer une seule de tes affirmations, et quand on te fait remarquer que ton seul et unique argument qui n'est pas une insulte est totalement illogique, tu bottes en touche?
                                Tu te fous de la gueule de qui la?

                                C'est pour ça que je demande du concret. Ce que personne ne me donne jamais (je viens de retrouver une discussion sur le même sujet il y a 6 mois ici avec le même flagos qui sort les mêmes propos non vérifiés).
                                Pour quelqu'un qui demande du concret, t'es quand meme tres affirmatif dans tes suppositions...
                                • [^] # Re: ...

                                  Posté par . Évalué à 1.

                                  Bon alors je ne sais pas comment te répondre, vu que ton commentaire n'apporte strictement rien ... Bah, je sais pas, mes "preuves" c'est qu'un DSP c'est fait pour être programmable (c'est son but) et que donc on peut le reprogrammer ... Et c'est à peu près ce qui est contenu dans les smartphone modernes (le sujet dont on parlait), donc ... je ne vois pas quoi ajouter.

                                  En fait, c'est très fort votre technique de demander à justifier des trucs "normaux" face à des arguments bidons qui ne veulent rien dire.
                                  • [^] # Re: ...

                                    Posté par . Évalué à 1.

                                    Super ton argument ultime... Il y a toujours un DSP ca c'est vrai, mais ce n'est pas pour autant qu'il est utilise pour faire tout le decodage !

                                    Dans le cas du HD, le DSP est entoure de blocs hard qui realisent les accelerations necessaires a tenir du 1080p. Le DSP controle ces blocs et realise les fonctions de decodage quand il peut tenir le debit. En plus, c'est toujours pratique car ca peut permettre de bricoler des patchs au cas ou il y ait un bug ds une partie hard.

                                    Pour les codecs qui ne supportent que le SD, c'est le DSP qui fait tout le decodage.

                                    Bref, presumer qu'il y a pas de blocs hard sous pretexte qu'il y a un DSP c'est completement bidon. Si tu compares ca a un PC, c'est un peu comme si tu disais: «j'ai un processeur => je n'ai pas de carte graphique»
                                    • [^] # Re: ...

                                      Posté par . Évalué à 1.

                                      Ta dernière comparaison est pas mal, mais encore une fois, d'où te viennent tes infos ? quelles sont tes sources ?

                                      Et pour revenir au sujet, quel périphérique embarqué se targue de faire de la HD ? Où est-il écrit qu'il utilise du hard dédié ?

                                      Enfin, je ne vois pas l'intérêt de mettre du hard différent en plus pour "simplement" traiter plus de donner (bon, je sens qu'on va me dire que c'est pas le même profile, blahblah, mais pour l'instant on parlait simplement de différence de résolution il me semble) : si ton DSP n'est pas assez rapide, t'en prends un autre plus rapide, ou t'en mets deux.
                                      • [^] # Re: ...

                                        Posté par . Évalué à 2.

                                        C'est ce que l'on appelle des "IP", ce sont des puces qui sont fondu a coté de ton dsp (parfois les IP sont purement logiciel). On développe ça d'abord sur FPGA puis on synthetise tout ça et on le vend aux fondeurs de silicium qui s'occupe de l'intégration
                                        Ce qui se fait beaucoup c'est sur System On Chip tout le bordel est sur la meme puce physique (mais y a plein de coeur différent, d'accélérateurs hardware pour tel traitement. Ca se fait énormement dans la téléphonie.

                                        Et les processeurs minables sur STP (genre freeboxtv) ont a coté de leur coeur principal un coeur composé d'une puce controleur (typiquement un ARM7), un petit dsp et plein d'accélérateur hardware (les fameux IP). Sur les téléphones portables ça change on passe de plus en plus vers des dsp généralistes avec quelques IP spécialisés (les fameux 34xx, SnapDragon, ...)
                                        • [^] # Re: ...

                                          Posté par . Évalué à 2.

                                          sur Freebox, c'est un mips qui est secondé par un DSP sigma design pour faire la HD. A priori, il n'y a pas d'IP. Ou alors, juste pour la conversion yuv->rgb.

                                          "La première sécurité est la liberté"

                                        • [^] # Re: ...

                                          Posté par . Évalué à 1.

                                          Encore une fois, je ne te demande pas de me faire des leçons (merci, je connais "en gros") mais de me dire quelles sont tes sources qui te parlent de ces IPs : pour moi c'est faux, comme dit Nicolas, c'est souvent juste un CPU + DSP. J'ai également bossé sur des STB (Phillips, Sagem, Scientific Atlanta) et des téléphones (Motorola) et je connais un peu leurs architectures. Par exemple, sur les téls motos sur lesquels j'ai bossé, le baseband c'est un ARM7 + DSP (le fameux Calypso dont on parlait dans une news récente) et processeur d'application est un ARM9. Fondre des IPs revient _beaucoup_ trop cher dans tous ces domaines, et c'est donc pourquoi je te demande d'où tu tiens ces infos.
                                          • [^] # Re: ...

                                            Posté par . Évalué à 2.

                                            Après discussion, il semble que l'IVA HD contient bien le C64 mais aussi pas mal d'accélérateur à coté. Reste à savoir si ils sont ou pas très spécialisé.

                                            "La première sécurité est la liberté"

                                          • [^] # Re: ...

                                            Posté par . Évalué à 4.

                                            ah, on est des anciens collegues alors :)

                                            J'ai bosser chez freescale (puis motorola). Et déjà, ton ARM c'est un magnifique IP, fourni par ARM. C'est justement le boulot d'un Freescale ou d'un TI que de prendre un assemblage d'IP et de les fondre. Après les autres IP... bah y en a des tonnes, beaucoup viennent de la maison, d'autres vienne de l'extérieur. Ca dépend du marché. On prend l'IP d'un controleur UART qui vient d'une boite externe parce qu'elle coute pas cher et que ca couterait plus cher à développer, on prend le controleur DMA maison,... Et on concoit un nouveau processeur. En gros, c'est comme ça que ça marche (le plus long c'est l'étape de placement).

                                            Les boites qui viendent de l'IP, eux, sont chargés de concevoir la boite de A à Z, regarde les IO, optimiser le path en nombre de transistor, gérer l'autonomie.

                                            C'est schématique, mais en gros, il faut savoir qu'un fondeur comme TI ou Freescale reçoi un IP de la part de ARM, par exemple, et se débrouille pour le placer sur son Soc. IP qui peut etre sous forme de code source, ou de chip synthétisé (selon le contrat). Faire causer tout ce petit monde est un énorme boulot, évidement. Et gérer le power consumption de tout le monde est encore plus ENORME.

                                            Concernant les routines d'accélérations dont l'on discute, je n'ai pas le "source" des processeurs en questions, et savoir s'il y en a ou pas pour une DCT par exemple, excusez moi, mais on s'en contre fous. Ce qui importe c'est ce que nous fourni le toolkit du DSP.

                                            Car IP ou pas, la plupart du temps le fondeur (TI, Freescale,...) fourni un ensemble de librairie optimisées pour certains traitements. Dont tu n'as pas les sources, évidement. En ce moment, ne pas mettre de routines d'accélération H.264 est suicidaire sur le marché. Routine qui tourne principalement sur le DSP et qui peut, en interne, utiliser un IP d'accélération de DCT par exemple (c'est tout a fait envisageable, même si peu probable).
                                            Si tu n'utilises leur lib optimisé, tu dois redévelopper en code DSP, ce qui n'est pas une mince à faire. C'est ça qui est important. Qu'il y ait un IP dédié H.264 ou potentiellement réutilisable pour un autre codec, s'il n'est pas accessible car caché derriere des miriades de registres non documenté, bah je n'en vois pas l'intéret.

                                            Quant à motorola (de bons souvenirs d'ailleurs), effectivement on cause à un DSP ou à un ARM sans voir ce qu'il y a derriere. Et ce n'est pas à eux de fondre des IP.
                                            • [^] # Re: ...

                                              Posté par . Évalué à 2.

                                              Bon, effectivement, c'est abusé de ma part de dire qu'on achète que des puces "toutes prêtes" et qu'on ne fond rien : TI ou Freescale fondent effectivement des IPs. Et fournissent un gros travail d'intégration.

                                              Ce que je souhaitais préciser, c'est que ces IPs sont des trucs relativement "standards", comme le ARM ou le C64. Et aussi que moi je ne me fous pas de ce que ne fournit pas le toolkit : je suis un bidouilleur libriste qui veut savoir ce qu'il y a "derrière" (bon, là je m'écarte du sujet pour relancer mon idée, déjà citée plus haut, d'ouvrir un peu plus ces trucs).

                                              Parce que le problème d'accélération dont on parle ici est exactement ça : quelle est la limite entre ce qu'"on" peut reprogrammer ou non (sachant qui si tu as un gros porte-feuille, je pense que tu peux "tout" reprogrammer, car tu peux par exemple fondre tes propres IPs ... oui, j'ai dit un très gros porte-feuille).

                                              Mon argument était que, les DSP étant reprogrammable (d'ailleurs j'ai du mal à voir ton IP de DCT en interne du DSP : que veux tu dire exactement par là ? genre un peu comme on intègre du MMX dans un CPU ?), pour moi, l'argument du "on ne peut pas faire autre chose que du H264 car c'est câblé en dur" est caduc. Car n'importe qui avec des compétence sur un C64 pourrait te refaire la même chose pour VP8 ou Theora (des compétences et "un peu" de temps, certes, mais comme dans n'importe quel domaine ou le libre avance).

                                              Toi, tu pars du principe que comme le toolkit ne présente qu'un accès "haut niveau" au décodage H264, en gros, c'est câblé "en dur" et on ne peut rien faire d'autre. J'ai bien reformulé ton idée ?

                                              Alors, d'un point de vue pragmatique, je suis d'accord avec toi. Mais d'un point vue même pas théorique, mais simplement pratique, c'est débile car un DSP est reprogrammable par définition : c'est toi-même avec ton linux qui va même charger le programme du DSP en mémoire !

                                              Bref, pour moi, la barrière de la fermeture du DSP est complètement artificielle, et pourrait facilement sauter si les DSP retrouvaient leur vrai nature.

                                              Je remarque aussi qu'on a le même problème avec les FPGA. Je ne sais pas si les constructeurs se rendent compte que s'ils ouvraient un peu plus leur produits, ils auraient un public énorme en plus (ok, ce n'est qu'un avis de libriste ...).
                                              • [^] # Re: ...

                                                Posté par . Évalué à 2.

                                                "genre un peu comme on intègre du MMX dans un CPU ?"

                                                Cela serait le plus cool pour la consommation mémoire, mais en général, c'est plutôt une sorte de DMA. Le défaut majeur étant que le "paquet" doit être assez gros, sinon tu perds trop de temps à configurer l'accélérateur.

                                                Je remarque aussi qu'on a le même problème avec les FPGA. Je ne sais pas si les constructeurs se rendent compte que s'ils ouvraient un peu plus leur produits, ils auraient un public énorme en plus (ok, ce n'est qu'un avis de libriste ...).

                                                Je suis assez d'accord. J'ai d'ailleurs découvert un tel projet chez ST au moment ou ils sont décidé d'arrêter.

                                                Pourtant, c'est facile d'imaginer le potentiel d'une puce avec un gros ARM + une interface DDRAM + IO + un FPGA avec des multiplieurs. Pour 50€ on pourrait avoir une cinquantaine de multiplier 16 bits avec les portes. Aujourd'hui, il faut une très chère suite logiciel pour utiliser par exemple le produit d'Altera qui utilise jusqu'à 4 coeurs PPC.

                                                "La première sécurité est la liberté"

                                                • [^] # Re: ...

                                                  Posté par . Évalué à 3.

                                                  eux tu connais bcp de FPGA à 50€? Peut etre est ce lié aux volumes de prod, mais j'en connais très peu en dessous de 500€ la puce
                                              • [^] # Re: ...

                                                Posté par . Évalué à 2.

                                                non, mon point de vue est légèrement nuancé: oui on peut dans l'absolu mettre n'importe quel codec sur ton dsp, aujourd'hui ils sont assez puissant pour faire tout ce que l'on veut. Mais si ton fournisseur ne te vent pas les bonnes primitive, tu vas devoir le redévelopper. C'est possible. Mais personne ne le fera.

                                                Ce qui compte, in finé, c'est ce qui abouti dans un produit. Les hypothèses, les possibilités, sont bien joli, mais ce qui compte c'est le monde réel. Et dans le monde réel, les fondeurs n'ont pas du tout une approche "libre". C'est leur coeur de métier, et "ouvrir" le code d'un DSP n'est pas dans les moeurs des constructeurs, c'est ce que je dit.

                                                Et, pour reprendre mon argumentaire, au final, on s'en contre ficher. Il te faut quoi pour développer sur ton pc? gcc. dans l'absolu. Sur ton mobile? le simulateur android par exemple (google à eu la bonne approche sur ce coup là). Ou un petit gcc-arm par exemple. Pour ton dsp... arg. Il te faut une board (bah oui, les simu cycle accurate existent, mais qu'en interne des boites, et coute méga cher et son méga lent), les connecteurs, un os debug dessus.... Très peu de monde pourraient le faire sur leur temps libre (j'en connais qui en feraient des merveilles).

                                                Mon avis, est que, plus on s'éloigne du monde du pc, plus l'argent qu'il faut sortir pour avoir un env de dev est important, donc moins il y a de gens, moins de support. In fine, tu auras UN gars qui va te pondre un super codec sur ton DSP A, et personne pour le maintenir au bout de 2 ans.

                                                Donc bon, coder sur DSP, merci, j'ai déjà fait, c'est inchiable, et quand ça marche on n'y touche plus!

                                                A moins, évidement, qu'une norme genre openmax DL ne fournisse les primitives IDCT and co directement dans une belle API, et qu'en dessous ça passe de manière transparente dans les accélérateurs hardware ou dsp. Ca oui, j'y crois. Mais ne travaillant plus dans le mobile, je ne sais pas où ça en est (il y a 2 ans tout le monde en parlait).
                                                • [^] # Re: ...

                                                  Posté par . Évalué à 3.

                                                  "ouvrir" le code d'un DSP n'est pas dans les moeurs des constructeurs, c'est ce que je dit.

                                                  Juste pour préciser, quand je dis "ouvrir", c'est avoir la doc des opcodes, c'est tout. C'est la base, quand même ...

                                                  Sur ton mobile? le simulateur android par exemple

                                                  Non, je n'en ai pas besoin.

                                                  Ou un petit gcc-arm par exemple.

                                                  Oui, ça ça me suffit, et en plus, ça existe déjà (et ça a été fait par des libristes !).

                                                  Pour ton dsp... arg. Il te faut une board (bah oui, les simu cycle accurate existent, mais qu'en interne des boites, et coute méga cher et son méga lent)

                                                  Mais c'est quoi une "board" pour toi ? Moi, j'ai déjà mon matos (un téléphone, une beagleboard, un N900, etc) et ça me suffit pour faire marcher mon DSP !

                                                  les connecteurs

                                                  Quels connecteurs ?!!

                                                  un os debug dessus...

                                                  Pourquoi ?

                                                  J'ai l'impression que tu as une vision complètement formatée par les constructeurs ... "Il faut forcément le kit complet". Je suis d'accord que mon espoir d'avoir de la doc est un peu vain pour l'instant, mais aujourd'hui si j'arrive à reverse-engineerer ces specs, je peux compiler mon propre blob et le faire tourner par le DSP, sans aucun matos ou soft supplémentaire ! Par besoin de connecteur spécial, de debugger spécial ... ! Je ne vois pas ce dont tu veux parler.

                                                  Très peu de monde pourraient le faire sur leur temps libre (j'en connais qui en feraient des merveilles).

                                                  Là je vais redevenir vulgaire : j'ai _horreur_ des mecs qui me disent ce dont je suis capable ou pas. Franchement, avec tout ce qui existe en libre dans tous les domaines aujourd'hui, je ne vois pas comment on peut continuer à sortir ce genre d'argument débile. (dans le genre de programmation "pointue", j'ai codé des routines de manipulation d'image (blending, ...) pour Enlightenment en Altivec sur PPC, avec prefetch, alignement correct, maximisation de la BP ; je veux bien que coder un DSP soit compliqué, mais quand même).

                                                  Mon avis, est que, plus on s'éloigne du monde du pc, plus l'argent qu'il faut sortir pour avoir un env de dev est important, donc moins il y a de gens, moins de support. In fine, tu auras UN gars qui va te pondre un super codec sur ton DSP A, et personne pour le maintenir au bout de 2 ans.

                                                  Et alors ? Tu fais dans l'obscurantisme ! "vous en serez pas capables", "vous n'avez pas l'argent", "c'est trop dur pour vous" : aucun de ces pseudo-arguments ne peut être utilisé de manière valable : c'est juste de la dissuasion. C'est tout ce dont j'ai horreur dans le monde proprio, et qui disparaît complètement dès qu'on ouvre le truc.

                                                  Donc bon, coder sur DSP, merci, j'ai déjà fait, c'est inchiable, et quand ça marche on n'y touche plus!

                                                  Aurais-tu des exemples de programmes sur DSP ? Ça m'intéresse beaucoup, car je vois beaucoup de personnes dire que c'est inchiable, mais personne n'en montre.

                                                  A moins, évidement, qu'une norme genre openmax DL ne fournisse les primitives IDCT and co directement dans une belle API, et qu'en dessous ça passe de manière transparente dans les accélérateurs hardware ou dsp. Ca oui, j'y crois. Mais ne travaillant plus dans le mobile, je ne sais pas où ça en est (il y a 2 ans tout le monde en parlait).

                                                  Je viens d'aller voir, je ne connaissais pas, mais ça a l'air de s'approcher d'OpenCL. C'est vrai que ça pourrait être une solution qui aiderait à résoudre le problème des codecs. Mais si j'aurais mon côté râleur qui dirait que ça ne change rien à la situation fermée des DSP. Mais bon, au moins, ce sera plus souple.
                                                  • [^] # Re: ...

                                                    Posté par . Évalué à 1.

                                                    Il existe une gamme de DSP (blackfin) qui ont été rendu cpu-like pour faire tourner linux dessus.

                                                    De mémoire, l'intérêt est que c'était le processeur le moins chère avec une fpu. Maintenant, ce n'est plus vrai avec les arm Cortex A8/A9.

                                                    "La première sécurité est la liberté"

                                                  • [^] # Re: ...

                                                    Posté par . Évalué à 3.

                                                    mais je te dis pas que tu dois pas le faire, l'intéret du libre est donc que tu peux le faire! Il y a des compilo pour certains DSP. Mais il te faut plus que de la bonne volont.

                                                    Par contre, j'adopte effectivement une position particulière, celle que j'avais à l'époque, je ne connais pas trop le "hack" d'un dsp qui marche bien sur une plateforme ouverte, désolé. Ma position est celle du "bring up". J'ai une brique, avec plein de connecteur autour. Et je dois coder tout ce qu'il faut pour commencer à faire en sorte qu'il me parle, puis me dise ce qui ne va pas, puis faire le traitement, ... Et pour ça il faut plein de truc:
                                                    - le compilo : bah, les compilo libres sont vraiment limité au niveau perf et support des DSP, tout simplement parce que les constructeurs cachent beaucoup d'info, les registres sont pas tous documenté,... les compilo interne sont rarement ouvert et sont très cher. TI en a libéré qque un je pense. Aussi parce que les cibles sont limités et changes trop souvent
                                                    - la connectique. Si, si, je t'assure, un DSP n'est pas un CPU généraliste où tu es assez "proche". J'ai une vision formatée parce que j'ai bosser avec et sans la board de développement. Et ton connecteur JTAG, mon ami, tu l'aimes. Car quand tu code en assembleur sans OS qui gère tes jolis exceptions et t'affiche des printf quand ça ne va pas, bref tu es tout seul devant la bete et qu'elle est dans un état indéterminé parce quelque chose à planté... bah tu fais quoi?? Les constructeurs te vendent (cher) des solutions de debug in place (RVDS par exemple http://www.bluewatersys.com/development/doc/realview/rvds/) qui sont sous forme de suite logiciel sur PC (avec un compilo, un similateur cycle accurate, un gros boitier (qui coute très cher) à connecter à ton PC et à ta board ou ton open phone (forme facteur presque final mais avec les connecteurs de debug)).
                                                    - simulateur : si si si tu en as besoin, ton algo tu te test pas sur la board directement. Tu tests s'il fonctionne sur ton simulation instruction accurate (simul les instructions), puis sur le cycle accurate (voir si ça fout pas la merde en dessous). Evidement, c'est hyper lent, donc dès que ton algo est un minimum validé et que le mec qui est chargé de faire l'injecteur de code sur le DSP l'a fait, tu le fais tourner sur le dsp. Et tu pries.

                                                    Sur un close phone (ou ton forme facteur final), tu n'as aucun des pins de debug qui sorte, ou très rarement. C'est pour ça par exemple que le téléphone OpenMoko est d'abord sorti sous une forme non terminée, pour permettre d'y connecter son PC. Sans ses pin de debug, tu te repose sur le coeur ARM (avec un linux dessus) par exemple pour récupérer l'état des registres et resetter le coeur DSP. Mais si là aussi il y a un soucis, tu es mort. Le pire? C'est qu'electropniquement c'est pas trop complexe (un microcontrolleur pour router les info). Mais tout est obfusqué donc c'est difficile.

                                                    J'ai beaucoup de repect pour des projets comme openMoko, je trouve que c'est vraiment une très bonne idée et parfaitement louable. Enfin une plateforme ouverte. Mais est ce que ça marchera....

                                                    Le probleme d'un DSP, c'est la "distance" avec le CPU. Le DSP est loin. Sans outil pour aller lui ouvrir la tete, tu as une boite noir qui a planté, et souvent ça plante sur des traitement lourds et temps réel qui ne se reproduise pas quand tu fais du pas à pas.

                                                    Attention, OpenMax IL te fourni les primitive de décodage/encodage (idct, ...) alors que OpenCL te fourni un acces direct au "kernel" de calcul (pour coder une primitive ou un traitement particulier). C'est complémentaire. Je ne sais pas si les puces actuelles permettent de faire les 2 en même temps.

                                                    Pour moi le DSP est un faux probleme. Qu'il reste fermé si on peut en changer quand bon nous semble. Et des interfaces standards sont nécessaires. Après, si un TI libère les compilo de ses DSP, ils n'en sera que gagnant (c'est fou ce que les mecs sur internet peuvent être bon, meilleurs que des tonnes d'ingé, jvous jure) ! Mais ça fait très très peur aux fondeurs (c'est comme donner les clés de son coffre fort pour eux...
                                                    • [^] # Re: ...

                                                      Posté par . Évalué à 1.

                                                      Après, si un TI libère les compilo de ses DSP, ils n'en sera que gagnant (c'est fou ce que les mecs sur internet peuvent être bon, meilleurs que des tonnes d'ingé, jvous jure) ! Mais ça fait très très peur aux fondeurs (c'est comme donner les clés de son coffre fort pour eux...

                                                      Ils sont vendeur de hardware. Mais il est très rare qu'une boite investisse dans un produit pour le donner en espérant vendre + de produit d'origine. En général, il vende le compilo pour payer le développement. A un nouvelle investissement correspond un calcul de rentabilité. Et en général, il ne s'agit pas des mêmes départements. Il est donc hors de question que son département SW fasse gagner de l'argent à celui HW tout en en perdant soi-même.

                                                      "La première sécurité est la liberté"

                                                    • [^] # Re: ...

                                                      Posté par . Évalué à 1.

                                                      OK, merci pour ces infos. Je comprend mieux maintenant ton besoin d'un kit complet. Par contre, je continue de penser que c'est une fausse excuse, si tu l'utilises comme argument contre l'ouverture des DSP.

                                                      Pour la standarisation des interfaces, oui, c'est toujours une bonne chose. Mais je dirais que ce n'est pas assez souple pour les besoins actuels, et qu'un accès direct au DSP serait quand même vachement plus cool.
                                                      • [^] # Re: ...

                                                        Posté par . Évalué à 3.

                                                        j'argumente pas contre l'ouverture, évidement je suis pour sinon je viendrais pas sur linuxfr. Mais je tente de définir la position d'un fondeur qui ne voit pas l'intéret d'ouvrir son compilo interne qu'il vend à prix d'or...
                                                        • [^] # Re: ...

                                                          Posté par . Évalué à 1.

                                                          Encore une fois, je ne demande pas à ce qu'ils filent leur sources ! C'est exactement la fausse conclusion qui tombe à chaque fois qu'on parle des drivers Nvidia ... Non, je ne veux pas les obliger à "libérer" un travail qu'ils ont le droit de mettre sous la licence qu'ils veulent !

                                                          Ce que je veux, c'est qu'ils ouvrent l'ISA, bref, une documentation qui explique comment _s'interfacer_ avec le bouzin. Ce qui serait pour moi tout à fait normal. Point de vue utilisateur, ce qui est fait actuellement serait exactement comme te filer une boîte noire sans bouton, c'est complètement inutile.
      • [^] # Re: ...

        Posté par . Évalué à 4.

        Avec HTML5, les vidéos sur internet sont appelées à évoluer de toute façon.
        Vers h264 pour google (pour le moment avec chrome).

        Alors sous Androïd t'auras toujours l'actuel, le flash kipuképalibre.
        Ben non sous android y a pas de flash. Il utilise directement les flux h264.

        C'est un pb de codec accéléré, pas de conteneur (html5 vs flash vs appli spécifique sur le terminal).

        Et dans deux ans quand le flash commencera à disparaître pour les vidéos, de toute façon Androïd sera dépassé, aura évolué, ton téléphone sera recyclé, et ta remarque sera oubliée, voilà...
        Sais tu combien de temps se passe entre qu'une puce soit conçu et qu'elle se retrouve dans un terminal grand publique.

        On dirais pas. Et aujourd'hui je connais pas de puce qui accélère les codec vpx. L'ironie c'est que on2 font des codec h264 hardware.
        • [^] # Re: ...

          Posté par . Évalué à 1.

          c'est toujours la question de l'oeuf et la poule. Un industriel ne veut pas engager de grosses dépenses s'il n'est pas sur que tout le monde va foncer dessus.

          Si on a un google qui dicte une direction, il est grandement probable que dans les prochaines 3-5 années, on ai des puces qui accélèrent la décompression du vpx (la encore, c'est qu'une question de moyen en ingé, les puces peuvent le faire techniquement).
  • # Lettre traduite

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

    Je signale que la lettre a été traduite sur le Framablog (sous une longue introduction) :
    - "Si Google is not evil alors qu'il le prouve en libérant le format vidéo du Web !"
    http://www.framablog.org/index.php/post/2010/02/21/google-vi(...)
  • # VP3 et MPEG-4 AVC,

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

    Le codec VP3 étant plutôt dépassé

    Ou pas. Pas plus dépassé que MPEG-4 AVC (alias H.264, mais je préfère utilisé son nom d'informaticiens que son nom de téléphonistes), vu qu'il est un peu plus efficace, cf. la comparaison référencée par cette lettre à Google.
    • [^] # Re: VP3 et MPEG-4 AVC,

      Posté par . Évalué à 7.

      1. Cette comparaison concerne le codec VP3 et pas VP8.
      2. Il faut plus qu'une comparaison pour appuyer un argument, il en faut des dizaines, indépendantes l'une de l'autres. Celon la mienne de comparaison, on est loin des même performances. La raison est simple : l'encodage de youtube n'est pas optimisé pour la performance. Comparaison a refaire avec un encodeur professionel; on aura des résultats bien meilleurs avec H.264 que theora
      3. pour reprendre la comparaison dont on parle, l'auteur commet deux erreurs:
      - 1) il converti son format d'entrée en un format compressé avec perte (mjpeg) avant de l'envoyer sur son encodeur. C'est mal.
      - 2) il utilise des keyframe séparé de 250, ce qui baisse le bitrate (super!!) mais augmente la difficulté pour seeker. Pour aller à la frame 249 (~9,9s), on dout TOUT décoder depuis la frame 0. C'est de la triche pour baisser le bitrate.
      4. Le codec H.264 a de bonnes qualité et a l'avantage d'être implémenté en hardware sur bon nombre de plateforme (ou des routines partielle). Implémenter un autre codec n'est pas si compliqué, il faut juste convaincre les fournisseurs de supporter d'autre codec (juste une histoire de sous sous, pourquoi vorbis n'est il pas supporté par ses plateformes??? parce que personne ne les utilisent (entendre : aucun fournisseur de contenu (youtube,...) ne pousse pour les fournir). Et supporter un codec, ça coute cher en ingénieur (100 000€/an dans nos pays, ~3 fois moins pour le offshore)).

      Si google arrive et dit "youtube ne founira que du VP8 dans ses contenus html 5", là oui il y a de grande chance que beaucoup se mette à supporter ce codec. Sans un google ou un "supporter providentiel" équivalent, aucune chance. Ce n'est pas la faisabilité technique qui rentre en jeu, mais l'argument commercial (est ce que ça a un intéret marketing/commercial/politique).

      C'est la MPEG-LA qui va faire la gueule. Mais un peu de concurrence (libéralisme, quand tu tiens) ne fait pas de mal dans ce domaine là!
      • [^] # Re: VP3 et MPEG-4 AVC,

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

        - 2) il utilise des keyframe séparé de 250,

        Ah ben voila qui explique son résultat... J'aurai dû regarder de plus près plus tôt pour voir ce "problème". Il met un scénario que Youtube ne peut pas utiliser (10s en seek! Mais c'est du n'importe quoi pour du streaming... C'est acceptable à la limite pour des films qu'on encode à la maison et qu'on ne seek pas, mais c'est tout. Les keyframe sont plutôt normalement de 12 ou 24, et ça a un gros impact sur la qualité à débit donné), et en déduit que Theora est meilleur avec ce scénario inutilisable.

        Bref, le seul test qui mettait Theora en avant part à la poubelle en montrant que ceux qui font des comparaisons ne comprennent pas du tout les contraintes de ceux qu'ils veulent convaincre (c'est gênant), il ne reste définitivement rien à Theora à part le fait d'être libre (ce qui n'est absolument pas suffisant, très loin de là, le prix de cette liberté étant exorbitant...)

        Il reste à espérer que VP8 soit vraiment meilleur, bien meilleur...
        • [^] # Re: VP3 et MPEG-4 AVC,

          Posté par . Évalué à 2.

          Je pense que VP6 est déjà comparable à H.264. Le hic c'est qu'on ne peut pas le tester. VP8 sera sans doute meilleurs.
          Voir un autre de mes commentaires sur cette page pour le lien vers le doc.

Suivre le flux des commentaires

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