Guillaume POIRIER a écrit 243 commentaires

Tu peux faire toi-même tes paquets, c'est probablement la meilleure solution pour que ton build soit le mieux intégré à ton système: http://mplayerhq.hu/DOCS/HTML/en/linux.html#debian(...)

je me demandais si mplayer supporte maintenant ODML

Il me semble que oui, mais je sais que le support de l'ODML a été discuté il y a quelques mois.
En tous cas, je n'ai pas eu le genre de problème dont tu parles.
Peut-tu donner plus de détails, lignes de commandes, etc, pour que je puisse reproduire ici ton éventuel problème.

j'ai la flemme de changer parce qu'il est patché de partout pour s'intégrer à Freevo

Tu devrais envoyer des patch à MPlayer pour que tes modifs soient intégrée upstream, si tant est qu'il te soit possible d'en élaborer un pour le CVS courant.

La plupart des projects dérivés de MPlayer sont la cette page: http://mplayerhq.hu/homepage/design7/projects.html(...)
Tu devrais pouvoir y trouver ton bonheur.

Youpi, y'a encore des bugs qui ont étés corrigé cet AM, voici le nouveau tarball: http://www.mplayerhq.hu/~rtognimp/MPlayer-1.0pre7-test2.tar.bz2(...)

Ca dépend de quel côté de la barrière tu te trouve tu sais.
Si tu es du côté développeur, c'est quand même pas marrant de devoir retoucher du code qui marchait très bien pour qu'il fonctionne à nouveau avec GCC-4.0.
Par exemple, dans FFmpeg/MPlayer, il y a tout un tas de fonctions écrites en assembleur inline pour gérer des transformations d'images en SIMD (MMX, SSE, tout ça).
GCC-4.0 oblige à retoucher à ce code là en « l'obfuscant », et pour des raisons qui m'échappent autant qu'aux devs de ce magnifique projet. Les gens de GCC ont beau dire qu'il n'y aurait pas eu de problèmes si le code avait été codé avec des « intrisincs », ce qui est largement plus propre, le problème c'est que les vieilles versions de GCC ne le gèrent pas ou peu, ce qui n'est pas très cool pour les gens qui utilisent encore GCC-2.95.
Tu avoueras que quand tu as un bout de code qui fonctionne bien tu as pas envie d'y toucher.

Par contre, du côté utilisateur, c'est tout bénèf' puisque apparemment les perfs sont là... sauf qu'on s'en fout des perfs quand on ne peut plus compiler ses applications favorites!

En même temps, c'est bien d'avoir une distrib qui ose mettre des logiciels comme gcc 4.0 par défaut ! Ça ça va faire bouger les choses

Ca dépend de quel côté de la barrière tu te trouve tu sais.
Si tu es du côté développeur, c'est quand même pas marrant de devoir retoucher du code qui marchait très bien pour qu'il fonctionne à nouveau avec GCC-4.0.
Par exemple, dans FFmpeg et MPlayer, il y a tout un tas de fonctions écrites en assembleur inline pour gérer des transformations d'images en SIMD (MMX, SSE, tout ça).
GCC-4.0 oblige à retoucher à ce code là en « l'obfuscant », et pour des raisons qui m'échappent autant qu'aux devs de ce magnifique projet. Les gens de GCC ont beau dire qu'il n'y aurait pas eu de problèmes si le code avait été codé avec des « intrisincs », ce qui est largement plus propre, le problème c'est que les vieilles versions de GCC ne le gèrent pas ou peu, ce qui n'est pas très cool pour les gens qui utilisent encore GCC-2.95.
Tu avoueras que quand tu as un bout de code qui fonctionne bien tu as pas envie d'y toucher.

C'est sûr que tu côté utilisateur, on est moins sensible à ce genre d'argument.... sauf quand tes applications favorites ne compilent plus!

Ca fait toujours mal d'apprendre une telle nouvelle...
Kadreg, où que tu sois, puisse ton âme reposer en paix.

Merci Edouard pour tout le travail que tu as pu faire au long de ces 3 années. Mon Dieu comme le temps passe vite.
Je te souhaite bon vent et bonne chance pour la suite, et j'espère que tu restera quand même pas trop loin du projet pour continuer de partager ton savoir.
J'espère de mon côté pouvoir continuer "d'améliorer" la symbiose avec MEncoder... y a-t-il une personne qui compte prendre la relève dans l'équipe?

Une grand Merci!

Guillaume

L'architecture de bus InfiniBand est prise en charge dans ce nouveau noyau : c'est apparemment une alternative au bus PCI où les données sont transmises en série et en multiplexage, au lieu d'être transmises en parallèle, ceci ne concernant pour l'instant que les serveurs « high-end » et certains PC.

Il me semble que cette définition est inexacte (cf http://www.oreillynet.com/pub/a/network/2002/02/04/windows.html(...) )
L'infiniband, c'est plutôt une technologie d'interconnection caractérisée par une faible latence et un gros débit, et est plutôt présenté comme un remplaçant d'ethernet ou mirinet pour les calculs sur grid.

Bon, si on regarde sur le wikipedia: http://en.wikipedia.org/wiki/InfiniBand(...) il semble bien qu'Infiniband se veut comme un remplaçant d'autant ethernet que le bus PCI...
Tout ça pour dire que jusqu'à présent, on pouvait difficilement avoir des gros débits de noeuds à noeuds en réseau local avec des technologies courantes, mais que heureusement est arrivé Infiniband!

tout simplement parce que le wav est échantillonné salement pour avoir une qualité "téléphone". Le Flac lui est échantillonné en qualité CD.

essaye, l'enregistreur gnome, tu verras

En effet, je viens de tester, et je vois même pas comment changer les préférences d'enregistrement... c'est franchement très crétin. Il me semble que l'ancien enregistreur de son de Gnome ne souffrait pas de cette limitation.
Ça réussit pas trop au libre de copier Windows si c'est pour se retrouver avec des outils aussi limités...

l'enregistreur de gnome enregistre en meilleure qualité en flac que direct en wav.

Désolé de pas être sympa sur ce coup, mais il me semble que tu racontes n'importe quoi.
À part si FLAC gère un quelconque gain lors de la rediffusion, il n'y a aucune raison objective pour que tu ais une meilleure qualité en FLAC.
Tout ça, c'est subjectif.
... ou alors, c'est que je suis plus du tout au fait de la théorie du traitement du signal, auquel cas je serais ravi d'en apprendre un peu plus.
Sans rancune?

Comment ça peut être possible d'avoir un coeur SSE quand tu sais pas si le CPU cible a :

1) pas de SSE
2) MMX
3) SSE
4) SSE2
5) SSE3 ?

J'imagine que de toutes façons, dans ce cas, ou bien tu oublies tout de suite parceque si des parties du programme ont été optimisées, c'est que globalement les traitements sont assez lourds (ex: compression MPEG-4), soit tu compiles toi-même le programme en C pur.

Dans tous les cas, c'est un faux problème.

Oui, il y a en effet pas mal de problèmes avec cette lib, que j'ai, en ce qui me concerne, rencontré lors des différentes phase de dev de x264 et MPlayer.
Fais bien attention à avoir compilé MPlayer et x264 avec le même compilateur, et assures-toi que la version de x264 est bien supportée par MPlayer.Si jamais tu as des problèmes pour décoder, essayes avec le patch de Loren Meritt: http://article.gmane.org/gmane.comp.video.ffmpeg.devel/18067/match=(...)
A part ça, il ne faut pas perdre de vue que x.264 est en plein dev, et qu'il y a encore moults réglages qui restent à faire pour être vraiment utilisable.

il s'agit d'un banal #include manquant.

Sachant la source du problème, c'est d'autant plus dommage alors que tu n'ais pas fourni le patch qui-va-bien! ;-)

très peu de personne (développeurs) ont compilé leur kernel.

Tiens, c'est quand même étrange que le port PPC soit pas plus testé... Il me semblait pourtant que la bécane de dev de Linus est une grosse PPC multipro....
Il recompile pas son kernel tous les jours le Linus? ;-) (bien sûr, c'est une remarque stupide: il ne suffit pas qu'il recompile son kernel, il faut encore qu'il utilise les mêmes bouts de code qur toi.)

Certes, c'est bien beau de leur reproché de ne pas avoir corrigé ce warning, mais as-tu:
1- vérifié que ce warning est vraiment si inquiétant que ça (certaines écritures tout à fait valides provoquent des warning). Bon, c 'est vrai que dans ton cas, il y a un nombre conséquent de warnings.
2- proposé un patch (manifestement, non :-( )?

Je suis d'accord que c'est dommage que ta remarque n'a pas été prise en compte, mais comme on dit: on n'est jamais mieux servit que par soit-même! ;-)

Tout à fait d'accord. Mais je pensais, en rédigeant cette dépèche, aux personnes qui ne connaissent rien à la compression de données (ce qui doit représenter une portion majoritaire des lecteurs). Il me semblait qu'un peu de vulagaristation ne pouvait pas faire de mal, sans tomber dans des raccourcis abusifs (par ex. si j'avais dit que c'était le successeur de du MPEG-4).
M'enfin, si vous avez envie d'en savoir plus sur h 264, allez donc faire un tour sur http://atlas2.tgv.net/~media-video/forum2/viewtopic.php?t=4345(...)
...En encore désolé d'avoir choqué certains... ;-)

J'aimerais d'ailleurs profiter de cette tribune qu'est LinuxFR pour indiquer que toute aide pour relire ou tenir la doc (autant le version HTML que la page de manuel) à jour serait la bienvenue. On est pas trop de deux pour le moment à cette tâche. À tout niveau de connaissance, vous pouvez nous apporter votre aide (en rapportant les erreurs de français si vous ne vous y connaissez pas trop, ou en rapportant les erreurs plus techniques si vous avec plus de bouteille).
Chaque contribution compte, aussi petite soit-elle (à partir du moment où vous travaillez bien sûr sur une version à jour du CVS, pour éviter le travail inutile, bien sûr).

Si cette activité vous plaît(ou plaîrait), vous pouvez me joindre par la re-direction dlfp (crex chez dlfp point org il me semble) ou avec le nouvel outil de message privé.

En vous remerciant! ;-)

En effet depuis le depart des developpeurs principaux, mplayer n'a que des modifs de maintenaces...

Excuses-moi d'en douter! Tu n'as sans doute pas pris encore connaissance de Chagelog, je pense.
Comprends bien quand même qu'il n'y a aucune honte a travailler sur un logiciel sans tout casser/re-inventer à chaque fois (cf pour ça l'interview de Linus)
... ça ma chiffonne que tu dises ça, mais ça me rassures de voir que tu n'as pas l'air au courant.

Ce n'est pas moi qui décide, mais à priori voilà ce que comporte le TODO du projet:
(tu verras un passage qu'il n'est pas tout à fait à jour étant donné qu'il me semble que le démultiplexeur mpeg-TS est présent dans cette release, et que toute la doc des options d'XviD a été refaite cet été.)

FOR THE NEXT RELEASE:
~~~~~~~~~~~~~~~~~~~~~~
- fix vo_svga vs. -vf scale - DONE?
- Re: [MPlayer-cvslog] CVS: main/libvo vo_vesa.c,1.82,1.83
This patch makes mplayer unusable in console mode, always leaves the
console in graphic mode.
- Dec 19: [BUG] mencoder+mp3lame creates desynced AVI (<=22Khz support missing)
- check files at FTP/incoming/!to_be_fixed/*
- fix partial -dr + ffmpeg + B frames (different stride per frame)
- implementing 8bpp support in vo_x11.c
- cleanup qtaudio/qtvideo (move globals to context)
- cleanup DMO interfaces
- fix AVI index offset base position handling ('no video stream found' bug)
- Update GUI code to support gtk 2.x (any volunteers??? we really need help here
)

FOR THE v1.00 RELEASE:
~~~~~~~~~~~~~~~~~~~~~~

- display OSD and subtitles using DVB card's OSD

mpg demuxer:
- implement mpeg-TS demuxer
- implement common mpeg 1/2/4 es/ps/pes/mp3 demuxer

avi demuxer: (needs rewrite)
- implement hardcore bruteforce avi re-sync for broken files (-forceidx)
- fix for growing avi files (movi_end pos > stream->end_pos)
- implement forward seeking in avi streams with no index

mencoder:
- finish mencoder -ovc vfw (bitrate setting, codec selection etc)
- add ogg/vorbis audio encoder
- stop/resume

DOCS:
- break up 6 level deep sections
- merge tech/encoding-tips.txt into mencoder.xml
- merge iive's XvMC docs into video.xml
- finish reviewing all of the docs
- mplayer.1
- encoding.html
- video.html
- documentation.html
- enhance the FAQ
- document missing XviD options
- add Matroska, NSV and nut to formats.xml
- split man page into mplayer.1 and mencoder.1

Je cherchais il y a quelques jours à faire fonctionner la _réception_ des flux webcam sous Linux...
Il m'a semblé, d'après mes recherches succintes, que aMSN et kopete le gérait...
Je n'ai pas pu encore tester ce deux logiciels dont j'ai entendu le plus grand bien, mais ce qui m'étonne, c'est que sur la malling-list de ffmpeg, un gars est en train de "reverse-engineerer" le codec de webcam de MSN... ce qui pour moi semble vouloir dire que pour le moment, la webcam avec des clients MSN, c'est mort, mais que j'ai toujours possible avec des standards ouverts comme jabber...
J'ai bon?
Quelqu'un de l'expérience là-dessus?

NB: n'ayant pas l'adsl, je n'ai pas poussé plus loin mes recherches.

Il semble que l'excellentissime Alan Cox, [..] a décidé de créer une branche "plus stable" de Linux 2.6

À proprement parler, Alan Cox n'a jamais vraiment prétendu que "'2.6.x' est tellement buggé que bah, il faut que je m'y colle"...
Ce qu'il serait plus correct de dire, c'est que Alan a toujours aimé débugger du Kernel, et qu'il a toujours fait ça sur les versions 'stables' du kernel. (au moins sur toute la série 2.x.y, avant je sais pas, j'étais pas là! ;-)
Il se trouve aussi qu'Alan a pris un an sabbatique pendant lequel il a été bien moins actif du côté du kernel, aussi on peu comprendre pourquoi le 2.6.x a 'dérivé' sans son oeuvre bienfaitrice...
Il faut tout de même bien comprendre qu'un Kernel, tout comme n'importe quel logiciel, comporte forcément pas mal de bugs, certains moins gênant que d'autres, aussi c'est assez normal qu'un gars aux yeux de lynx comme Alan puisse en trouver à la pelle... ça veut pas forcément dire que 2.6.x est à chier, ça veut surtout dire que la branche -ac, c'est bon, mangez-en ! ;-)

J'espère ainsi avoir rétabli [un peu] la réalité

En ce qui me concerne, je donne le préfixe lors ./configure... est-ce que ça au moins ça fonctionne?
Sinon, essaye avec:

PREFIX=/usr/local/stow/MPlayer-cvs-2004-12-01 make install

pas testé, mais comme en général les variables de makefile sont en majuscules...
Si ça marche pas, dis-le, je ferais remonter le rapport de bogue...

Salut Nico!
Tu fais bien de réagir, la doc XML a été marquée "outdated" par Diego la semaine dernière...
Pour committer tout ça, t'en fais, pas, je peux m'en charger...
Sinon, tu peux m'envoyer ce que tu as fait sur ma redirection dlfp.

Bonne chance!

C'est simple... il te suffit de tester pour en avoir le coeur net. Et puis si tu as de vrais problèmes de stabilité, même avec cette nouvelle version, le mieux, encore et toujours, est de faire un joli rapport de bogue...
C'est pas compliqué, non? ;-)

Salut Fabien!
J'espère que tu es bien installé...
Pour les stages à l'étanger, tu pourrais demander comment ça se passe avec Karina Guerrier, bureau des stages, au 1e étage de l'IFSIC, elle est là pour ça, et a l'habitude!
Bonne chance!
A+

Guillaume