Je viens de lire un truc intéressant à propos du futur de la balise <video/> de HTML5. Cette balise permet d'insérer une vidéo dans une page web aussi simplement qu'on insère une image. L'un des participant à cette niouse est pessimiste quand au remplacement de flash par h264/theora pour la bonne raison qu'une vidéo dans du flash est plus difficile à récupérer par le client, de la même façon qu'une image :
L'autre truc pour lesquelles les grosses boites freinent sur les codecs audio-vidéo a mon avis: c'est qu'il serais excessivement simple de récupérer les médias (Comme aujourd'hui pour récupérer les images). Le flash leur permet de rendre un petit poil plus difficile cette récupération (du moins c'est ce qu'ils pensent).
En plus le flash permet d'associer des URL, de renvoyer des choses au serveur à certain moment de la vidéo…
Le rêve pour des sociétés imbibées de rêves de contrôle des usages drmisés.
Et c'est exactement l'objectif opposé que cherche a atteindre le W3C !
Il a tout à fait raison… mais il se trompe sur un point. C'est sur la finalité de cette balise <video />. Cette balise n'est absolument pas destinée aux grosses boites, mais surtout aux internautes. Actuellement, quand l'internaute veut insérer une vidéo sur son blog, c'est une galère monstrueuse. Il doit d'abord encoder sa vidéo au(x) bon(s) format(s), l'uploader sur son serveur, puis, la tâche la plus difficile : trouver le bon code <object <embed />/> qui permettra d'afficher sa vidéo sur tous les navigateurs.
C'est en réponse à ça que youtube et consort ont opté pour Flash. Je me souviens encore il y a 6 ans, aux débuts de l'ADSL, voir fleurir des pages web remplies de vidéos… en wmv insérées à coup de balise object/embed. Ce n'est que plus tard que Youtube a popularisé la lecture de vidéos à l'aide de flash. Grâce à Flash et aux plate-formes vidéos, l'internaute n'a plus à se poser de question : il uploade sa vidéo et récupère immédiatement le code source à insérer dans son blog pour afficher sa vidéo. C'est bien là le but de la vidéo dans Flash.
<video/> apportera donc ce confort à l'utilisateur. De la même façon que pour insérer une image, je tape : <img src="monimage.png" /> pour insérer une vidéo, je taperais <video src="mavideo.mp4" />.
Les grosses boites pourront toujours continuer à utiliser Flash pour "protéger" leur contenu ou passer à <video /> en utilisant des codecs protégés par DRM. Ce n'est pas parce que les navigateurs connaissent maintenant <video /> qu'ils oublient Flash. Tout ce qu'elles devront retenir (ces grosses boites), c'est que plus leur fichiers seront difficiles d'accès moins nous y aurons accès.
Le web ouvert utilisera <video /> sans restriction, le web commercial utilisera Flash. Tout va pour le mieux 
PS : C'est sûrement aussi dans cette optique de simplicité que Apple a préféré inclure le codec h264 plutôt que le theora dans Safari. Ainsi les utilisateurs d'iPhone 3GS n'auront même pas à se poser la question de réencoder leurs vidéos et pourront les poster directement sur leur blog.
Commentaires
Pour Apple, je crois plutôt qu'ils ont pas envie de le proposer (alors qu'une simple màj du firmware l'offrirait sans problèmes).
Ils parlent des risques de brevet logiciel caché (comme RamBus, ou autre patent-troll), qui est un risque réel aux USA. Rappelons que Microsoft a raqué sévère pour la gestion des plugins cf http://dascritch.net/blog.php/post/... et le problème du règlement de cette balise a probablement motivé l'absence de Flash dans l'iPhone (en plus de sa consommation indécente des ressources)
C'est plutôt une solution amère et violente pour contrôler leur écosystème, un extand&embrance, si tu préfères. «Chez nous c'est plus facile parce que ça marche parce qu'on vend des solutions de montage vidéo et que QuickTime c'est meilleur. Na.»
Un peu comme la balise Applet de Sun, les commentaires conditionnels de Microsoft, et les Layers de Netscape.
Alle, hop ! autopromo : http://dascritch.net/blog.php/post/...
Ben étant donné qu'ils se défendent en disant que l'iPhone a une puce qui décode le h264 mais pas le theora, ton idée de la mise à jour firmware tombe à l'eau :/
Qu'est-ce qui les empêchent de supporter Ogg Vorbis en faisant de la décompression logicielle, comme le fait mon fidèle baladeur iRiver iHP-140 qui a déjà 6 ans ?
Oh mais attends... Ne serait-ce pas parce que cela risque de créer une trop grande masse critique de baladeurs soudainement compatibles, et donc rendre viable une concurrence ou une offre gratuite de haute qualité face à l'iTMS ?
Car si on découvre qu'il existe un codec de génération actuelle autre que l'AAC ou LAAC et qui plus est, à l'immense avantage de ne pas demander de royalties, tu ne crois pas que Apple va manquer de motivation pour l'implémenter ?
Allons allons, soyons sérieux, Apple n'est pas une entreprise philanthropique, et un petit monopole façon AT&T, IBM ou Microsoft ferait leur plus grand bien aux actionnaires....
Mais sinon, le sujet principal de l'article, t'en penses quoi ?
sur pcinpact apparrement ils disent que la balise est enlevé je n'ai pas tout compris .Pour ton article il y a quand même un point noir assez immense je te cite "Grâce à Flash et aux plate-formes vidéos, l'internaute n'a plus à se poser de question : il uploade sa vidéo et récupère immédiatement le code source à insérer dans son blog pour afficher sa vidéo. C'est bien là le but de la vidéo dans Flash." ok à 100% pour un user clickodromeur comme moi c'est ce qu'il faut!
Mais par contre "<video/> apportera donc ce confort à l'utilisateur. De la même façon que pour insérer une image, je tape : <img src="monimage.png" /> pour insérer une vidéo, je taperais <video src="mavideo.mp4" />."
Quel confort?Il faut savoir ce qu'est un ftp,avoir le logiciel connaître les balises et le html.
La balise vidéo permet à un dev même débutant de s'affranchir (à condition d'avoir un serveur qui ne lag pas) des solutions externes youtube etc... bon article sinon
ps pour le monsieur au dessus"Qu'est-ce qui les empêchent de supporter Ogg Vorbis en faisant de la décompression logicielle"
Tout et rien..Tout il n'y a pas de puce matérielle pour le faire,rien le code est ouvert donc ils peuvent.L'avenir de l'encodage et décodage est l'intégration à l'architecture matérielle afin d'affranchir le logiciel..et pour la mobilité de gagner en autonomie en libérant le proc principal
Ajouter un commentaire
Abonnement aux commentaires
S'abonner pour recevoir les commentaires suivants par email
URL de rétrolien : http://alt-i.fr/trackback/667
Fil des commentaires de ce billet