Pierre Tramo a écrit 675 commentaires

Leur solution est basée sur VLC et un plugin GPL qu'ils ont développé à leur frais.

Par curiosité, c'est quoi comme plugin ? Les sources sont dispo (je n'ai rien vu sur leur site web) ?

Qu'est ce que mplayer ne lit pas comme flux/fichier ?

En ce qui concerne les fichiers, je n'ai pas d'exemple récent en tête.
Et pour les flux, il ne me semble pas que mplayer sache recevoir du MPEG2-TS over UDP/RTP, en unicast ou multicast (cela dit, il existe des utilitaires qui savent réceptionner ces flux et les rebalancer sur la sortie standard, donc techniquement c'est faisable).
De plus, le décodeur MPEG2 de VLC semble être plus tolérant aux erreurs que ceux de mplayer et xine : j'en ai fait l'expérience en réceptionnant des flux DVB avec une carte DVB-T dont le frontend (partie tuner + démodulateur) était de piètre qualité, la vidéo n'était pas regardable en balançant le flux sur l'entrée standard de mplayer et xine (genre, sans arrêts, l'image se blo), alors que VLC parvenait à afficher la vidéo sans broncher, avec juste quelques erreurs sur l'image de temps à autres (avec donc la même qualité d'image (voire même meilleure) que quand j'utilisais le décodage hard de la carte).

Ils ont tous leurs points forts et leurs points faibles en termes de fonctionnalités : tel ou tel player refuse parfois de lire certains fichiers/flux (même s'il possède les bons codecs), alors que ça passera sur un autre, donc c'est toujours utile d'en avoir plusieurs sous la main, même si on en choisit un principal.
D'ailleurs si tu tournes aussi sous Windows, tu devrais apprécier d'avoir le même player avec la même interface dans les deux environnements.
Et VLC c'est beaucoup plus qu'un simple player : il sait notamment transcoder et diffuser des flux, et est pilotable entre autres par Telnet (j'apprécie beaucoup cette fonctionnalité de la version 0.7.2), bref, un magnifique joujou ;)

Kewl... le support du H264 :)
Enfin faut pas s'emballer non plus, tout ça c'est encore très jeune, et c'est un peu normal : MPEG4-AVC/H264 est une norme encore trop récente pour être utilisée en production (pas seulement en ce qui concerne VLC, mais aussi pour le matériel pro).

A propos, il supporte les codecs AAC et amr pour l'audio ?
Dans ce cas il serais relativement facile de lire le 3GP.
Il lit les deux, cf http://www.videolan.org/vlc/features.html(...) pour la liste des formats supportés en entrée (et http://www.videolan.org/streaming/features.html(...) pour les formats supportés en sortie).

Les processeurs de motorola et d'IBM, les powerPC particulièrement, pourtant reconnus plus performants se sont inclinés devant l'absence de marché..

Euh non, pas vraiment. Les PowerPC sont minoritaires sur le marché des micro ordinateurs, mais c'est loin d'être leur seul débouché, même si c'est le plus visible. Dans les serveurs, les consoles de jeux et autres set top boxes, dans l'embarqué, ... bref tous les secteurs où les gens font plus attention au rapport puissance/prix, à la consommation et à la fiabilité qu'à la présence du logo rassurant qu'ils ont remarqué lors d'une campagne de pub.
Certes IBM voit probablement Linux (tout comme Java) comme une occasion de porter un coup à l'égémonie wintel, ce qui serait favorable à la plateforme PowerPC (mais ça ne serait probablement pas aussi lucratif que les services qu'ils pourraient vendre au dessus), mais de là à dire que le PowerPC est condamné à attendre le déclin des x86 pour exister...

vous remarquerais que l'Alpha, lui, avait une version de NT

Il y avait aussi une version PowerPC de NT, mais bon, un mauvais OS sur un bon proc, ça ne fait pas une bonne archi...

Bref, toujours est-il que le rapport des forces des systèmes d'exploitation change considérablement depuis qu'IBM a mis ses billes dans Linux & Opensource, ne serait-ce que sur le marché des serveurs.
Or, Opensource == [re]compilation facile. Compilation facile dit portage facile sur une autre architecture. dans ma tête ça me dit, "ouverture de marché pour des processeurs 'différents', du matériel 'différent'".

Justement, sur le marché des serveurs, IBM n'avait pas vraiment besoin de Linux pour exister, et les parts de marché que Linux a grignoté, ce sont celles des Unix proprio.
C'est juste qu'ils se sont dit qu'ils feraient de meilleures affaires en vendant des services qu'en vendant des OS (AIX ou autres), et partant de se constat il est logique de chercher à mutualiser les coûts de développement des OS avec leurs concurrents.

s/noter/noter négativement/ bien sûr ;)
Scuzez du dérangement.

D'ailleur, OlivierL, je ne vois pas pourquoi me moinsser si ce n'est le fait
que tu n'es pas d'accord avec moi.
Tu as des preuves de ce que tu avances ? Il se trouve que j'ai posté pas mal de commentaires qui ont obtenu des scores négatifs (voire même abbyssaux), et que je viens tout juste de retrouver mon droit de vote. Je ne vois pas trop comment j'aurais pu te moinsser dans ces conditions... Et quand bien même, je m'abstiens par principe de noter les commentaires auxquels je réponds ou qui me répondent (sauf cas de force majeur :o ). Alors tu es gentil mais je te prierais d'éviter ces accusations gratuites.
Les Pierre Tramo sont vraiment des cibles faciles, ces temps ci...
\_o<

Ce que j'apprécie partiiculièrement dans le Perl Cookbook, c'est la discussion sur les différentes approches/solutions possibles, leurs avantages, leurs inconvénients, ... Ça aide a mieux comprendre et c'est toujours très instructif. J'ai parcouru un peu PLEAC et j'ai l'impression qu'il n'y a qu'une suite de morceaux de code. À mon avis, ça passe à côté du plus important et c'est bien dommage.

Oui, il faut prendre les analyses de ces cabinets avec beaucoup de pincettes. Celà dit, leurs analyses, reprises par les Grands Reporters de 01 et leurs équivalents dans le monde, ont une audience assez large chez les décideurs pressés et peuvent ainsi impacter la stratégie de Sun. C'est pourquoi je trouve que cette citation (somme toute assez évidente) n'est pas si anodine que ça.

open-source (sans majuscules) est un terme utilisé depuis bien avant la création de l'OSI, et désigne tout logiciel livré avec ses sources, mais si on n'a le droit de rien faire avec ces sources.

Il me semblait que Solaris désignait juste les dernières versions de SunOS, que les premières versions de SunOS utilisaient BSD et les suivantes System V.

Beh as tu vu les classes Java qui permettent de découvrir une base de données ?
connaitre les stored proc, les classes, si le sgbd est transactionnel ?
Euh je vois pas trop le rapport, là. J'ai pas parlé de base de données là... (Dans ce cas j'aurais bien évidemment fait du Java, je ne suis pas J2EE Lead Architect depuis 1987 pour rien ;)

tu as une api qui mappe celle de swing (meme classes, meme interfaces... ) mais qui t'affiche le tout en mode texte.. je recherchrais le nom.
J'attends avec impatience :o

Sinan, rien à voir, mais quelqu'un connait-il un bon client Telnet en Java (pour piloter un soft à distance depuis un prog Java) ? Google m'en propose plusieurs, et je ne sais lequel choisir...

En gardant java clot, Sun maintient une certainne avance sur les fork eventuel; puisque java tend à prendre encore plus d'importance, sun espere sans doute garder ses client captifs, ce qu'il ne peut plus faire avec solaris.
Mouais, Sun ne gagne pas d'argent avec Java. En tous cas pas avec le J2SE, et il en gagne (un peu ?) avec son serveur J2EE, alors qu'il en existe plusieurs libres.

On n'investit pas de l'argent dans un produit en fin de vie ... si je puis me permetre .
Tu vas quand même un peu vite en besogne : Sun investit beaucoup pour ses prochains processeurs Sparc multicore (Niagara et Rock), ce qui implique d'importants investissement également dans Solaris. Je pense que l'effort d'ouverture que leurs client doivent réclamer et la considération de Solaris comme un poste de développement (pour vendre du service et bâtir des solutions plus rentables dessus) plus que comme un poste un poste de revenus constituent des hypothèses plus crédibles.
Après, bien sûr, ça leur permettrait aussi de repiquer du code à droite à gauche pour des portions de l'OS qu'ils ne jugeraient pas stratégiques.

Ça n'est pas vraiment une question de faire ou ne pas faire, les deux doivent être capables de tout faire (éventuellement en leur ajoutant des biblio programmées en C ou en Assembleur pour les parties bouffeuses de CPU). C'est plus un problème d'utilisation naturelle ou pas : par exemple, pour faire un aspirateur de site web, qui modifie les pages, les tare, les envoie et les détare sur un serveur par ssh, le premier langage auquel je pense pour le faire, ça n'est pas Java ;)

Ah si tiens, une chose que Java ne sait pas faire : de vraies interfaces textes (pas seulement par l'utilisation de stdin/stdout/stderr). Un binding de curses, ça permettrait de faire des trucs sympatoches (mais bon, pour la portabilité, spa trop :/ ).

IBM was the major mover that led to the creation of the Swing API to replace the AWT api.
Sa création a été promue par IBM, quoi.

la syntaxe de Perl est tellement peu naturelle pour faire un tableau de tableau que la plupart du temps on se simplifie la vie en faisant un tableau de chaine puis un split, beurk..
J'ai déjà utilisé des structures de données assez violentes en Perl, avec plusieurs niveaux de tableux (indexés et associatifs) imbriqués, je ne vois pas le problème.

http://cpan.org/modules/01modules.index.html(...) y en a quand même un paquet !
L'API Java est très vaste également, mais elle ne recouvre pas tout. Les deux ont des domaines d'excellence distincts, c'est tout (il n'y a qu'à regarder les protocoles réseau : Java fait beaucoup de choses que Perl ne fait pas, et inversement).

3) avec des niveaux de puissance/souplesse/stabilité assez divers (l'usage des fonctions preg* de PHP est beaucoup moins pratique que la syntaxe de Perl, et niveau memory leak c'est pas mal non plus : en faisant un appel de fonction (ou l'évaluation d'une expression, je ne sais plus) dans la partie remplacement d'un preg_replace, j'avais tout bouffé en trois appels, alors que je n'aurais jamais eu ce problème en Perl).

Et un point important aussi, c'est la disponibilité d'un important volume de documentation de qualité sur Perl (Perl Cookbook roxor).

- Parce que le langage a toutes les propriétés dont j'ai besoin quand je veux faire un script : tables de hash, regex, ...
- Parce que je suis à peu près sûr que quoi que je veuille faire, il y aura un module pour.
- Parce que c'est portable.
- Parce que je maîtrise ce langage plutôt pas trop mal et que malgré tout il m'arrive encore d'apprendre de nouvelles choses.
- Parce que malgré son extrème flexibilité, ce langage a une conception très logique et carrée, et une fois qu'on connait bien le langage, c'est un pur bonheur (contrairement à PHP par exemple, qui se veut très simple, mais qui nous fait découvrir d'immondes gruickitudes au fur et à mesure qu'on apprend à le maîtriser).
- Et parce que Perl rulez :o

plonk!

Ah nan, j'ai pris ce pseudo en hommage au Pierre Tramo originel après qu'il s'est suicidé la première fois, de deux balles dans la nuque après s'être tranché les deux bras et les deux jambes à la tronçonneuse.
Et malheureusement, ce nom a depuis été sailli par des hordes de chomistes qui font rien qu'à semer la terreur sur leur passage.
Et maintenant tu te repetitsuicides...
Mais moi, je m'y suis habitué à ce nom, et je n'ai pas trop envie d'en changer. Ah moins qu'on m'en trouve un au moins aussi bien.

Encore une fois les amalgames... tu ne sais faire que ça ?
Je peux savoir pourquoi tu me reproches à moi d'avoir émis cette hypothèse, au lieu de le reprocher à ceux qui l'ont exécutée ?

sur wikipédia ?
-->[]

T'es gentil mais quand j'ai opté pour ce pseudo, il y en avait un nombre assez... nul.
Je ne vois pas en quoi je devrais assumer les actes de ceux qui ont également choisi ce pseudo par la suite.
Si demain tout le monde s'appelle Beurt et va foutre la zone un peu partout, tu trouverais normal qu'on te demande de changer de pseudo ?

J'espère bien que non ! Il n'y a rien de plus inergonomique...