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(...)
Journal Dear Google,
21
fév.
2010
# ...
Posté par M . Évalué à 6.
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 Yth (Mastodon) . Évalué à 10.
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 shinobufan (site web personnel) . Évalué à 7.
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 Zenitram (site web personnel) . Évalué à 4.
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 thedidouille . Évalué à 8.
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 Nicolas Boulay (site web personnel) . Évalué à 9.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par superna (site web personnel) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 6.
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 Stibb . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Stibb . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à -4.
Mais en pratique, toujours le néant...
[^] # Re: ...
Posté par Stibb . Évalué à 6.
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 kowalsky . Évalué à 9.
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 Zenitram (site web personnel) . Évalué à -1.
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 psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: ...
Posté par Zarmakuizz (site web personnel) . Évalué à 2.
http://desencyclopedie.wikia.com/wiki/L%27auteur_de_cet_arti(...)
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: ...
Posté par thedude . Évalué à 2.
[^] # Re: ...
Posté par Moogle . Évalué à 2.
[^] # Re: ...
Posté par Thomas Douillard . Évalué à 2.
[^] # Re: ...
Posté par flagos . Évalué à -1.
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 Ph Husson (site web personnel) . Évalué à 3.
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 benoar . Évalué à -5.
[^] # Re: ...
Posté par flagos . Évalué à -2.
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 Ph Husson (site web personnel) . Évalué à 2.
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 benoar . Évalué à 1.
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 Stibb . Évalué à 1.
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 benoar . Évalué à 1.
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 flagos . Évalué à -1.
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 Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par flagos . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 0.
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 flagos . Évalué à 4.
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 benoar . Évalué à 4.
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 benoar . Évalué à 4.
[^] # Re: ...
Posté par flagos . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 0.
L'IVA HD, c'est 2 cpus de gestion + un C64.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par benoar . Évalué à -1.
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 Littleboy . Évalué à 2.
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 Stibb . Évalué à 1.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par benoar . Évalué à 2.
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 benoar . Évalué à 2.
[^] # Re: ...
Posté par flagos . Évalué à 2.
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 benoar . Évalué à 2.
[^] # Re: ...
Posté par Stibb . Évalué à 0.
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp(...)
[^] # Re: ...
Posté par flagos . Évalué à 2.
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 Stibb . Évalué à 0.
3440 is better
http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp(...)
[^] # Re: ...
Posté par flagos . Évalué à 1.
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 benoar . Évalué à 1.
[^] # Re: ...
Posté par Littleboy . Évalué à 4.
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 benoar . Évalué à 1.
[^] # Re: ...
Posté par flagos . Évalué à 1.
Ya mes mots, et il y a le contexte de la reponse... l'intelligence est censee faire le reste.
[^] # Re: ...
Posté par thedude . Évalué à 2.
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 benoar . Évalué à 3.
[^] # Re: ...
Posté par thedude . Évalué à 1.
[^] # Re: ...
Posté par benoar . Évalué à 3.
(j'ai dit que ça n'utilisait qu'un cœur) Oui, y arrive presque, et ?
[^] # Re: ...
Posté par thedude . Évalué à 1.
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 benoar . Évalué à 0.
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 thedude . Évalué à 1.
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 benoar . Évalué à 1.
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 flagos . Évalué à 1.
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 benoar . Évalué à 1.
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 Stibb . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par benoar . Évalué à 1.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Stibb . Évalué à 4.
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 benoar . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 2.
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 Stibb . Évalué à 3.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&(...)
Les gammes style virtex peuvent monter plus cher. Le spartan 1500 de open graphics avec 100 multipliers 18 bits coutaient ~300$
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Stibb . Évalué à 2.
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par benoar . Évalué à 3.
http://www.armadeus.com/francais/produits-cartes_microproces(...)
Des kits à 100/200€ quoi. Par contre, je ne sais pas trop à quelle puissance ça correspond.
[^] # Re: ...
Posté par Stibb . Évalué à 2.
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 benoar . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 1.
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 Stibb . Évalué à 3.
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 Nicolas Boulay (site web personnel) . Évalué à 1.
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 benoar . Évalué à 1.
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 Stibb . Évalué à 3.
[^] # Re: ...
Posté par benoar . Évalué à 1.
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 M . Évalué à 4.
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 Stibb . Évalué à 1.
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 Alexis Kauffmann (site web personnel, Mastodon) . Évalué à 10.
- "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(...)
[^] # Re: Lettre traduite
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 2.
http://ciberderechos.barrapunto.com/article.pl?sid=10/02/20/(...)
Je devrais me réabonner au flux atom du Framablog, je ne sais pas pourquoi je ne le suis plus...
GNU's Not Unix / LINUX Is Not Unix Xernel
# VP3 et MPEG-4 AVC,
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
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 Stibb . Évalué à 7.
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 Zenitram (site web personnel) . Évalué à 1.
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 Stibb . Évalué à 2.
Voir un autre de mes commentaires sur cette page pour le lien vers le doc.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.