Trolloscope Who is the best ? - Page 21

ouais enfin les besoins ne sont pas les mêmes... un codec "matériel" va mettre l'accent sur la qualité "HD" alors qu'un codec "web" va préférer la possibilité de lire en "streaming" avec une compression efficace...

Sans gros changement, H264 reste impossible pour des années, voir http://article.gmane.org/gmane.org.w3c.whatwg.discuss/19991 :

Apple refuses to implement Ogg Theora in Quicktime by default (as used by Safari), citing lack of hardware support and an uncertain patent landscape.
Google has implemented H.264 and Ogg Theora in Chrome, but cannot provide the H.264 codec license to third-party distributors of Chromium, and have indicated a belief that Ogg Theora's quality-per-bit is not yet suitable for the volume handled by YouTube.
Opera refuses to implement H.264, citing the obscene cost of the relevant patent licenses.
Mozilla refuses to implement H.264, as they would not be able to obtain a license that covers their downstream distributors.
Microsoft has not commented on their intent to support <video> at all. (ce qui a changé depuis)

WMV doit lui aussi être couvert par des brevets...

vince (./601) :
ouais enfin les besoins ne sont pas les mêmes... un codec "matériel" va mettre l'accent sur la qualité "HD" alors qu'un codec "web" va préférer la possibilité de lire en "streaming" avec une compression efficace...

Le h264 est également orienté streaming, et a une compression bien plus efficace que le Theora, justement

Et on s'oriente quand même vers du streaming de bonne qualité sur pas mal de sites (journaux, ou films à la demande).

./602 > Ouais, donc en gros ça sera certainement quand même H264 qui sera utilisé vu que Apple et Microsoft ont les moyens de se le payer.
Et après je vois pas trop le problème... Sur les *vrais* OS, il y a un système de codecs accessibles à tous (CoreVideo/DirectShow) donc ça doit pas poser de vrai problème à qui que ce soit d'utiliser ça non ? (A part juste vouloir faire chier le monde bêtement, car c'est ce qui va se passer du côté de Firefox on peut supposer ^^)
(Et qu'en est-il de FFMPEG ?)

GoldenCrystal (./604) :
./602 > Ouais, donc en gros ça sera certainement quand même H264 qui sera utilisé vu que Apple et Microsoft ont les moyens de se le payer.
Et après je vois pas trop le problème... Sur les *vrais* OS, il y a un système de codecs accessibles à tous (CoreVideo/DirectShow) donc ça doit pas poser de vrai problème à qui que ce soit d'utiliser ça non ? (A part juste vouloir faire chier le monde bêtement, car c'est ce qui va se passer du côté de Firefox on peut supposer ^^)
(Et qu'en est-il de FFMPEG ?)

Surtout qu'en pratique, on peut lire du h264 et du vma sur tous les OS (y compris Linux)…
Et je ne vois vraiment pas l'intérêt de ne pas utiliser le système de codec du système (à part se faire chier et ajouter des failles potentielles, naturellement)

Je ne connais pas de format vidéo que mplayer ne sache pas lire, j'en viens à oublier qu'il y en a plusieurs (par contre il a parfois des difficultés avec le streaming, mais c'est pas un problème de codec...)
mais l'intégration dans firefox (avec des trucs genre mplayerplug-in) laisse à désirer malheureusement. Pour l'instant.

Ça reste quand même plus simple d'avoir une implémentation au niveau du système, c'est con que chaque appli doive se farcir tous les codecs ^^

par contre, je ne sais pas si c'est la même chose avec les autres OS, mais mplayer sur OS X est chiant vu que quand on parcourt une vidéo, l'image reste figée quand on bouge le curseur d'avancement, il ne recommence à afficher la vidéo que quand on relâche le curseur

ben il suffit d'utiliser mplayer au niveau du système, c'est ce que je sous-entendais (il faudrait que les trucs genre mplayerplug-in soient un peu plus stables/perfectionnés, il pourrait s'intégrer dans n'importe quelle appli).

Ceci dit, je trouve plus pratique d'avoir les vidéos qui s'ouvrent dans une fenêtre de lecteur séparée que à l'intérieur d'une page web. (D'ailleurs j'ai installé récemment MediaPlayerConnectivity, ça a l'air pas trop mal.)

Je n'ai pas spécialement remarqué ton problème mais moi ce qui me saoule avec mplayer sous linux (mais je sais pas si ça vient vraiment de lui) c'est que si tu reviens en arrière sur un DVD le disque s'arrête de tourner ; rendu au point à partir duquel tu n'as pas encore vu, l'image se fige pendant au moins trois secondes le temps que le lecteur se remette en marche

Enfin, s'il faut un plug-in pour chaque application, c'est pas franchement le plus simple

Oui, l'idée serait d'avoir un API de base (FFMPEG remplit relativement bien ce rôle sous linux, sauf que chacun le compile à sa sauce avant de le lier de manière statique... Ce qui est, il va sans dire, complètement con ^^) que tu peux utiliser comme bon te semble à partir de ton application. Et pas de développer un plugin autour de ton API pour la foutre dans toutes les appli possibles

L'API de ffmpeg change souvent, aussi...

Euh, ça a sûrement été dit plus haut, mais je ne comprends pas le problème du h264 vu qu'il existe x264 qui est une implémentation libre ?

Le problème est que le H264 est soumis a de multiple brevets comme le gif en son temps. Et il me semble qu'il n'y a pas d'encodeur libre.

Lionel Debroux (./611) :
L'API de ffmpeg change souvent, aussi...

#mondedulibre#

Uther (./613) :
Le problème est que le H264 est soumis a de multiple brevets comme le gif en son temps. Et il me semble qu'il n'y a pas d'encodeur libre.

Si, il y a un encodeur x264 qui est libre

GoldenCrystal (./610) :
Oui, l'idée serait d'avoir un API de base (FFMPEG remplit relativement bien ce rôle sous linux, sauf que chacun le compile à sa sauce avant de le lier de manière statique... Ce qui est, il va sans dire, complètement con ^^) que tu peux utiliser comme bon te semble à partir de ton application. Et pas de développer un plugin autour de ton API pour la foutre dans toutes les appli possibles

Il n'y a pas de système centralisé sous Linux ?

Sasume (./612) :
Euh, ça a sûrement été dit plus haut, mais je ne comprends pas le problème du h264 vu qu'il existe x264 qui est une implémentation libre ?

Ce n'est pas pour autant qu'elle est légale (ou que tu as le droit de la distribuer, je ne sais plus…). Un peu comme la libdvdcss : en théorie, tu n'as pas le droit de t'en servir (ça dépend des pays)

Centralisation et standardisation de choses d'aussi haut niveau que des API multimedia et des implémentations de codecs sous Linux ? Tu rêves
Les specs Linux Standards Base essaient d'améliorer la soupe de la compatibilité entre les distros, mais elles sont encore assez basiques - et puis beaucoup de distros ne respectent pas LSB.

Mais il est difficile, voire impossible, de faire une API qui convient à tous les usages. Voir ASIO sous Windows, PulseAudio sur divers, etc.
Même quand il y a une API définie comme standard par le fabricant de l'OS (même si, et c'est un autre débat, il existait déjà, au moment de la définition, d'autres API plus ou moins équivalentes définies depuis des années, plus ou moins bien respectées - cf. Windows et les couches graphiques spécifiques de MacOS X, versus POSIX et X+toolkits), certains font autrement, par exemple pour des raisons de performance, de footprint, etc.

Un système centralisé pour quoi ?

Pour la vidéo

Ben mplayer fait tout même le café, donc pourquoi on aurait besoin d'autre chose ?
Si je comprends bien, ta question est : pourquoi les différents lecteurs vidéo disponibles ne partagent-ils pas un système commun ? mais la réponse est que ces différents lecteurs vidéo sont concurrents (tu as le choix, mais tu vas en choisir un, je ne vois pas l'intérêt d'en installer plusieurs à la fois, enfin à part dans des cas particuliers genre si tu veux les tester). C'est comme si tu demandais pourquoi il n'y a pas un système centralisé pour l'affichage de pages web, qui serait partagé par tous les navigateurs... pareil, je ne vois pas pourquoi on aurait besoin de plusieurs navigateurs à part pour tester des trucs.

Mais si tu parles de l'affichage vidéo/interface avec le matériel, c'est bien sûr centralisé hein (le serveur X a un composant pour ça, Xv)

Sally (./620) :
Ben mplayer fait tout même le café, donc pourquoi on aurait besoin d'autre chose ?Si je comprends bien, ta question est : pourquoi les différents lecteurs vidéo disponibles ne partagent-ils pas un système commun ? mais la réponse est que ces différents lecteurs vidéo sont concurrents (tu as le choix, mais tu vas en choisir un, je ne vois pas l'intérêt d'en installer plusieurs à la fois, enfin à part dans des cas particuliers genre si tu veux les tester). C'est comme si tu demandais pourquoi il n'y a pas un système centralisé pour l'affichage de pages web, qui serait partagé par tous les navigateurs... pareil, je ne vois pas pourquoi on aurait besoin de plusieurs navigateurs à part pour tester des trucs.

Parce qu'il y a plein d'applications autre qu'un lecteur de films qui peuvent vouloir afficher de la vidéo (navigateur web, client msn, visualisation rapide dans l'explorateur de fichiers, mediacenter [truc plus lourd qu'un simple lecteur, quoi ], éditeur graphique de filtres vidéo, transfert d'image ou de vidéo depuis un apn, encodeur de DVD, ...

Et perso, ça me ferait chier qu'un de ces composants ne profite pas d'un codec que j'aurais ajouté)

J'ai édité ./616 pour faire apparaître plus clairement ce que je voulais dire sur la difficulté d'avoir une implémentation universelle pour tous les usages.

Sally > Justement la partie rendu vidéo on s'en tape, que tu veuilles le rendre sur la console avec aalib ou sur une texture c'est pas le problème du codec...
Mais le fait est qu'un API commun pour accéder au codecs est super pratique (et de mon point de vue, indispensable).
Exemple sous Windows, n'importe quelle application peut accéder au système DirectShow et/ou Kernel Streaming (rox \o/) et gagner l'accès naturel à toutes les périphériques vidéos, encodeurs, et décodeurs disponibles.
Ce qui veut dire que tu peux installer un codec (exemple ffdshow, donc ffmpeg quoi ^^) et en faire bénéficier non seulement Windows Media Player, mais aussi n'importe quelle application du système si tant est qu'elle désire jouer le jeu. Windows Media Player utilise Direct Show, Windows Media Player Classic utilise DirectShow, WinAmp utilise (éventuellement) DirectShow... Etc, ce qui te fait préférer l'un à l'autre ce sont leurs différences.

Sous OSX, même chose, avec CoreVideo tu as un accès standard à toutes les fonctionnalités vidéo (mais bon je connais pas toute l'étendue là donc...) et tu peux en faire ce que tu veux.
Donc si tu installes un codec (Perian quoi ) toutes les applications en bénéficient d'office. Ce qui te permet donc de lire de nouveaux formats de vidéo dans QuickTime, donc dans les pages Web (entre autres), mais aussi de bénéficier de ce même support pour les autres applications, comme par exemple NicePlayer (stoujours mieux que l'interface bridée de QuickTime 7).

Les trucs comme VLC (/mplayer) qui se la jouent individuel, c'est très bien si tu as besoin de mettre ton lecteur sur une clef USB ou autre, mais franchement, pour le reste c'est complètement con dans le concept...

http://en.wikipedia.org/wiki/OpenMAX - mais ce n'est pas du tout mainstream.

Ca ne résout pas un problème : les codecs un peu exotiques (et il y en a x_x) d'une part, et les codecs livrés avec de la merde d'une autre (RealPlayer, QuickTime...). Je veux bien qu'on utilise l'API système pour les codecs, mais il faudrait que ça soit fait proprement, et pas avec trois tonnes d'outils parasites.

Mouais je ne suis pas sûr de bien comprendre, c'est un peu technique pour moi, mais quand je veux installer un codec pour mplayer, je le fous dans /usr/lib/codecs et pouf ça marche, ça n'est peut-être pas le cas des vieux lecteurs mais ça devrait l'être de toute autre application linux un peu moderne qui veut lire de la vidéo non ? (je ne compte pas flash player évidemment). Si c'est pas le cas, c'est certes pas malin, mais autrement, je ne comprends pas bien le problème ^^

Nil (./627) :
Ca ne résout pas un problème : les codecs un peu exotiques (et il y en a x_x) d'une part, et les codecs livrés avec de la merde d'une autre (RealPlayer, QuickTime...). Je veux bien qu'on utilise l'API système pour les codecs, mais il faudrait que ça soit fait proprement, et pas avec trois tonnes d'outils parasites.

Les codecs QT et RM peuvent être installés sans rien avec, hein (QTalternative, RealAlternative)

Sally (./628) :
Mouais je ne suis pas sûr de bien comprendre, c'est un peu technique pour moi, mais quand je veux installer un codec pour mplayer, je le fous dans /usr/lib/codecs et pouf ça marche, ça n'est peut-être pas le cas des vieux lecteurs mais ça devrait l'être de toute autre application linux un peu moderne qui veut lire de la vidéo non ? (je ne compte pas flash player évidemment). Si c'est pas le cas, c'est certes pas malin, mais autrement, je ne comprends pas bien le problème ^^

Mais ils seront utilisés seulement par mplayer, non ?

Ben j'en sais rien j'ai pas d'autre lecteur vidéo, j'ai toujours supposé que si j'en avais un il les utiliserait aussi, ça me semble logique (ils vont dans /usr/lib/codecs qui ne semble pas avoir un nom spécifique à mplayer), mais j'ai jamais vérifié. Edit : après une mini recherche google il semble que ces codecs soient utilisés aussi par xine et kaffeine, au moins.