Reprise du message précédent :

 
1) avec un grep sur ps -A ? Sinon quand X est lancé, il y a un fichier .X0-lock dans tmp (pour le serveur 0). Bon il doit y avoir des solutions plus élégantes.
2)xvinfo oui
3) ?

merci, ça doit le faire avec le lock... Il est supprimé quand X s'arrete ?

 
Oui... sauf pépin (crash). Mais de toute façon une session X ne peut se lancer s'il n'est pas effacé, alors... Par contre, il peut très bien s'appeler X1-lock pour ceux qui lancent un deuxième serveur X, etc...

ok donc j'ai juste à vérifier la présence d'un X*-lock. Mais bon, je n'en suis pas là.

Gros Problème pour mon script : Savez-vous s'il ya moyen de forcer mplayer à ecrire ses messages en anglais même s'il a été compilé avec l'option --language=fr ???
En effet, je viens de me rendre compte que mon script actuel ne marchera pas si les messages de mplayer sont dans une autre langue (étant donné que je récupère des infos de mplayer grâce à grep/awk...). Donc l'idéal serait de forcer mplayer à parler anglais et de modifier le script en conséquence.
 
Sinon : la normalisation est maintenant automatique ainsi que le crop et le calcul du bitrate (taille son récupérée avec ls -l).  
 
Dans l'état actuel l'utilisateur saisit :  
1/titre, angle, piste son à ripper. ("angle" disparaitra aussi dans le cas où il n'y en a qu'un...)
2/bitrate audio, nombre de CD.
3/critère de qualité visée.
Toutes les autres infos sont récupérées automatiquement ou calculées. (normalisation, ratio, resolution, crop, durée du film...)
 
PS : merci à "philou_a7" pour avoir corriger ma grosse boulette.

jotenakis a écrit a écrit : Gros Problème pour mon script : Savez-vous s'il ya moyen de forcer mplayer à ecrire ses messages en anglais même s'il a été compilé avec l'option --language=fr ??? En effet, je viens de me rendre compte que mon script actuel ne marchera pas si les messages de mplayer sont dans une autre langue (étant donné que je récupère des infos de mplayer grâce à grep/awk...). Donc l'idéal serait de forcer mplayer à parler anglais et de modifier le script en conséquence.   Sinon : la normalisation est maintenant automatique ainsi que le crop et le calcul du bitrate (taille son récupérée avec ls -l).     Dans l'état actuel l'utilisateur saisit :   1/titre, angle, piste son à ripper. ("angle" disparaitra aussi dans le cas où il n'y en a qu'un...) 2/bitrate audio, nombre de CD. 3/critère de qualité visée. Toutes les autres infos sont récupérées automatiquement ou calculées. (normalisation, ratio, resolution, crop, durée du film...)   PS : merci à "philou_a7" pour avoir corriger ma grosse boulette.

 
C'est bien tout ca !
Pour la langue je n'en sais rien, en fait j'ai toujours compile avec l'anglais. Je vais poser la question sur la liste.
A+

Voilà la réponse d'Arpi :
> Is that possible to force mplayer to display its messages in English,  
> even if it has been compiled with the --language=fr option (or whatever  
> language) ?
 
no
 
A'rpi / Astral & ESP-team
 
Donc --> soit tu fais le script en anglais, soit en français, soit un truc très compliqué qui prenne en charge les deux langues. Je pencherais pour la version anglaise, étant donné que ce sera plus facile à distribuer.

MERci
   
Pour le moment c'est fr... Verrais comment améliorer + tard.
 
Mais ça risque de finir par un test vérifiant que mplayer est compilé en anglais et basta...

jotenakis a écrit a écrit : MERci     Pour le moment c'est fr... Verrais comment améliorer + tard.   Mais ça risque de finir par un test vérifiant que mplayer est compilé en anglais et basta...

 
Oui faire un multilangue compliquerait la chose. Il faudrait repérer toutes les chaînes de caractères... phew, du boulot ! Eventuellement ce serait possible d'universaliser avec des variables qui contiendraient toutes les chaînes à rechercher en différentes langues. Mais bon y a plus urgent !

MPlayer pre9 est sorti aujourd'hui. J'ai fait l'update avec le CVS, et ils ont fait une très grosse mise-à-jour de la page man. Notamment, il y a une grosse doc sur les nouvelles options de lavcodec et le support des options xvid.

mencoder vs dvd::rip
 
Hello!
Est-ce que vous obtenez de meilleurs résultats avec mencoder qu'avec dvd::rip? J'ai essayé dvd::rip (il me semble que ce sujet est consacré à l'encodage, pas uniquement à mencoder), et franchement, la qualité est VRAIMENT inférieure à ce que j'obtiens avec rippack sous windaube.
J'essaierai bien mencoder, mais je n'ai pas envie de passer 1 heure à bien paramétrer les lignes de commandes avant de lancer l'encodage. Est-ce qu'il existe une GUI, ou bien un sript qui permettrait de tout configurer (rip, réglages, encodage)?
Mais surtout, j'aimerai savoir s'il vaut le coup que je me penche sur mencoder, sachant que rippack produit d'excellents résultats... Pouvoir encoder sur linux m'éviterai juste d'avoir à rebooter sur windows.
Merci!

JoWiLe a écrit a écrit : franchement, pour trouver mieux que mencoder, accroche toi

 
Bah écoutes, je ne demande pas mieux. As-tu déja utilisé rippack sous Windaube? Parce que c'est pour le moment le meilleur encoder que j'ai jamais vu, toutes plateformes confondues. Je ne parle pas de l'interface, je parle des résultat obtenus. Transcode, utilisé via dvd::rip, me donne des résultats pourris comparés à rippack.
Bon, et bien d'autres avis? De toute façon, j'ai déja mplayer et mencoder d'installés sur mon système, va falloir que j'essaie un jour où l'autre...

 
Attends, tu confonds logiciel et codec. dvdrip, mencoder, rippack ne font pas l'encodage en lui-même : ils envoient des paramètres à un codec et font un fichier mpeg4. Tu ne dis pas quel codec tu a pris sous Windows, ni sous dvdrip, ni les bitrates. Je peux te dire que j'ai essayé libavcodec et xvid sous linux, et que c'est impeccable.

 
Si t'avais lu ce thread, tu saurais que justement ce script est en cours d'élaboration et que j'ai mis il y a quelques temps sur mon site une page d'explication et des scripts. Lis les pages précédentes et tu trouveras les liens.

 
Nan nan, pas d'accusation attive et injuste!!! J'ai lu ce thread, mais j'espérait que qq'un me résume un peu tout ça... Ca fait du bien parfois dans un thread de resituer le contexte, nan (bon, ok, mon excuse est pourrie, désolé...    
 
Mais je suis quand même lu des choses dans ce thread, sérieusement, et ce que j'en ai vu, c'est que le processus menant à l'encodage d'un dvd en utilisant mencoder est quand même long et fatidieux pour obtenir de bon résultats. Ce que je recherche, c'est un logiciel sous linux qui offre des résultats aussi bon, tout en n'ayant pas à faire 36 essais et passer 2 heures à configurer le tout avant de lancer l'encodage...
 
Après avoir essayé dvd::rip sous linux, et étant pas satisfait du résultat, l'encodage de dvd est la seule application qui me fasse encore rebooter sur windows, avec Counter-Strike...
 
Est-ce qu'en tout cas, vous pourriez m'indiquer quels codecs audios comme vidéo choisir pour une meilleure compatibilité avec les lecteurs multimédia de windows? ogg peut etre sympa et donner de bon résultats, m'enfin si c'est pas tip top sous windows (décallage son-image...), je suis pas trop chaud...

conti a écrit a écrit :     Nan nan, pas d'accusation attive et injuste!!! J'ai lu ce thread, mais j'espérait que qq'un me résume un peu tout ça... Ca fait du bien parfois dans un thread de resituer le contexte, nan (bon, ok, mon excuse est pourrie, désolé...       Mais je suis quand même lu des choses dans ce thread, sérieusement, et ce que j'en ai vu, c'est que le processus menant à l'encodage d'un dvd en utilisant mencoder est quand même long et fatidieux pour obtenir de bon résultats. Ce que je recherche, c'est un logiciel sous linux qui offre des résultats aussi bon, tout en n'ayant pas à faire 36 essais et passer 2 heures à configurer le tout avant de lancer l'encodage...   Après avoir essayé dvd::rip sous linux, et étant pas satisfait du résultat, l'encodage de dvd est la seule application qui me fasse encore rebooter sur windows, avec Counter-Strike...   Est-ce qu'en tout cas, vous pourriez m'indiquer quels codecs audios comme vidéo choisir pour une meilleure compatibilité avec les lecteurs multimédia de windows? ogg peut etre sympa et donner de bon résultats, m'enfin si c'est pas tip top sous windows (décallage son-image...), je suis pas trop chaud...

 
Mais oui je suis pas MAICHAN !
Bon, tu as deux codecs très haute qualité sous Linux : libavcodec (du projet ffmpeg) et xvid, que tu dois connaître sous Win.
Si tu lis l'anglais, je t'invite à aller sur mon site : http://www.zeb.uklinux.net/encoding.html
J'ai mis une liste de tout ce qu'il faut pour compiler et encoder avec mencoder avec des scripts. Commence avec l'encodage mp3.
Donne du feedback. Et sinon jotenakis va sortir son script aussi, et je pense que ce sera excellent.

Au fait, si tu télécharge la version pré9 de MPlayer, tu n'as pas besoin de prendre la version CVS de ffmpeg. C'est inclus dedans.

 
Bon, je vais voir ça ce soir. Pour ce qui est du feedback, pas de problème, je serait sans pitié!    
Pour ce qui est de libavcodec, je crois l'avoir déja installé sur mon système. J'espère que ce n'est pas ce que dvd::rip utilisé, vu le résultat navrant que j'ai obtenu comparé à rippack...
Pour le codec xvid, c'est justement ce dont je voulais parler... OK, peut etre qu'il est plus rapide que le divx au niveau de l'encodage, mais bon, tout le monde n'a pas xvid, et qui dit que ce codec sera encore dispo dans 5 ou 10 ans, et s'il ne faudra pas faire des pieds et des mains pour pouvoir encore lire tout ça... C'est pourquoi pour le moment je me cantonne au divx4...
Pour ogg, c'est la même chose que xvid.. Tout ça est peut etre mieux que les codecs "standards", mais je suis pas trop trop confiant...
Bon, je vais regarder ton site...

conti a écrit a écrit :     Bon, je vais voir ça ce soir. Pour ce qui est du feedback, pas de problème, je serait sans pitié!     Pour ce qui est de libavcodec, je crois l'avoir déja installé sur mon système. J'espère que ce n'est pas ce que dvd::rip utilisé, vu le résultat navrant que j'ai obtenu comparé à rippack... Pour le codec xvid, c'est justement ce dont je voulais parler... OK, peut etre qu'il est plus rapide que le divx au niveau de l'encodage, mais bon, tout le monde n'a pas xvid, et qui dit que ce codec sera encore dispo dans 5 ou 10 ans, et s'il ne faudra pas faire des pieds et des mains pour pouvoir encore lire tout ça... C'est pourquoi pour le moment je me cantonne au divx4... Pour ogg, c'est la même chose que xvid.. Tout ça est peut etre mieux que les codecs "standards", mais je suis pas trop trop confiant... Bon, je vais regarder ton site...

 
Bon plein de choses à mettre au point :
1) oui sois sans pitié ! Mais c'est vrai que je n'améliorerai pas beaucoup ces scripts désormais, étant donné que jotenakis va sortir le sien beaucoup mieux.
2) pour libavcodec il s'installe, notamment, avec la compilation de mplayer. Mais tu ne l'as pas forcément installé avec dvdrip/transcode. Tu peux connaître le codec que tu utilises dans un des menus de dvdrip. De toute façon, rien ne vaut mencoder en ligne de commande (ou script). Encode un DVD à 900kbps et tu verras la qualité.  
3) xvid et divx4 sont tous les deux mpeg4 compliants. Ca signifie que xvid n'est pas plus spécifique que divx4, et tellement meilleur. Donc tu peux déjà encoder en xvid, ce sera toujours reconnu par des lecteurs mpeg4 comme mplayer.
4) ogg vorbis est un standard libre : tu es sûr qu'il sera toujours supporté. Si un jour Thomson fait payer les lecteurs mp3, ils auront le droit de le faire, et là tu seras coincé. Pas pour ogg vorbis. De plus, vorbis est déjà supporté sous Windows : winamp3 par ex. Va voir sur doom9.net, il y a les codecs pour WMP. La qualité est tellement meilleure que mp3, surtout à bas débit. Ce problème de support est pareil avec divx4 : ils ne proposent plus que le 5 en téléchargement, avec leur spyware. Le jour où ils trouveront qu'ils ne font pas assez de fric, adieu le support du codec. Avec xvid/libavcodec, pas de risque.

Euh... un peu n'importe quoi la
 
Dans 5 ans tu ne pourras peut etre plus lire tes divx si divx network n'existe plus
Par contre, vu que le *SOURCE* de xvid est dispo, dans 1000 ans tu pourras encore les lire (sous le hurd par exemple).
 
Ensuite, sous linux, le divx est assez bridée
Les options equivalentes au divx pro de windows existent pour une partie dans Xvid et dans ffmpeg/lavcode, PAS dans divx
 
Enfin, les codecs Xvid et FFmpeg-mpeg4 sont hyper proches du standards mpeg4 et sont interchangeables
 
Tu l'encode en xvid et tu changes les fourcc en Divx et hopla c'est un divx

 
Non, pas vraiment n'importe quoi... Quand je parle de pouvoir lire les divx/xvid dans 5-10 ans, il n'est pas question de disponibilité des sources. Il est plus question de standard. Parce que ce n'est pas parce que les sources seront toujours sur tes CD que tu disposeras d'applis pour lire les films.
 
Si tu veux, je peux te fournir des sources d'applis qui ont 10 ans, et dont les fichiers ne peuvent être ouverts par aucun programme...
 
Encoder avec le meilleur codec, qu'il soit audio ou vidéo, permet assurément d'obtenir le meilleur résultat. Mais galérer dans quelques années pour pouvoir les lire serait vraiment dommage... Je ne dis pas qu'il ne faut pas expérimenter, car c'est ce qui fait avancer les choses, mais c'est à faire avec prudence...

 
Dans 10 ans, tu seras sûr de toujours pouvoir les lire avec mplayer sous Linux. Avec Microsoft et Palladium, c'est pas sûr.

vu que t'as les sources, il y a rien qui t"empeche de recompiler dans 10 ans (toi ou un autre)
 
Le fait d'avoir les sources te guarantit la perennite
 
 
Y a qu'a voir les pbs lors du passage a windows XP sur certains periph plus supportés par le constructeur
 
Sous linux et dérivé, le probleme existe pas.
Une fois que c'est dedans ca le reste.
 
Idem pour l'ogg et le Xvid et le lavcodec.

Zeb2,
 
J'ai qq petits pbs avec ta procédure:
-sur les lignes 105 et 106, j'ai dû remplacer vqcomp=0.6 par vqcomp=6/10
-lors du lancement de ffasencoder.sh, j'ai finalement l'erreur suivante dans le shell:
./ffasencoder.sh: line 108: 8534 Relais brisé (pipe) cat ./*vob
Suivi d'une erreur de segmentation...
Une idée d'où peut provenir le problème?

 
Salut
- vqcomp est optionnel, ca permet de favoriser les scenes rapides/lentes dans un sens ou dans l'autre. Tu peux le virer completement, par defaut il est a 0.5. Le fait que ca ne marche avec le point vient peut-etre de locales qui ne prennent pas le point comme le separateur decimal ? Ou peut-etre que ca ne marche plus avec la nouvelle version de mplayer (les options de lavcodec ont change)
- cat ./*vob permet de concatener les fichiers vob decryptes. Il faut l'utiliser dans le repertoire ou tu as tes fichiers vob. Si tu as extrait un seul vob avec la methode de jotenakis, tu n'as pas besoin de concatener plusieurs fichiers. Ajuste le script a tes besoins.

 
Mmmm... Bon, pour vqcomp, c'est réglé.
Mais pour le cat ./*vob, je ne vois pas d'où vient le problème. Certes, il n'y a qu'un seul vob, donc la concaténation est inutile. Cependant, cela devrait toujours marcher avec un seul fichier. Dans ce cas, il n'y a pas de concaténation, mais cat envoie toujours le (seul) fichier vob vers la sortie standard, et dans le cas du script, sur le pipe.
C'est bête, car l'écriture du divx avait commencé (2Mo d'écrit).

 
Je suis d'accord, c'est etrange. Mais bon vaut mieux limiter les processus, je ne sais pas d'ou provient cette instabilite.

Alors, personne n'a de solution concernant ce broken pipe? J'aurai bien aimé pouvoir relancer l'encodage cette nuit...

 
Essaye sans le pipe : retire le cat avec un editeur.
Sinon quelle version de mplayer tu as ?

 
Ouais, depuis j'ai réessayé sans le pipe et relancé le tout. Pour ce qui est de mplayer, j'ai la version 0.90pre8-2.96 sur Linux 2.4.18-6mdk.
On verra bien si cela fonctionne sans le pipe...

 
Essaie avec la pre9 ou même le CVS, compile sur ta machine. J'ai eu aussi parfois des problèmes avec des pipe vers mplayer, mais moins avec les dernières versions.

 
J'utiliserai le CVS si cela ne fonctionne pas sans le pipe, mais bon, il n'y a pas de raison, le problème semblait venir du pipe.
Par contre, une autre chose m'a étonné. J'ai suivi ta procédure pour obtenir les valeurs de crop via mplayer. Valeurs que j'ai reporté comme tu l'indiques dans les paramètres de mplayer pour voir si le crop est bon. Je m'attendais à voir disparaître les bandes noires, ce qui ne fut pas le cas. Cela est-il normal?

En tout cas, ce le fait de pouvoir encoder sans perturber les autres applis est vraiment excellent. Je peux meme mater un divx pendant ce temps!

 
Oui, rectangle fait un simple cadre blanc de la taille indiquée par crop.

 
En effet, nice est nice. OUAHAHAHAHAHA. Pardon, c'est la fin du week-end.

 
??? Ah... Et bien c'est exactement ce que j'attendais à voir!!! Mmmm... Je réessaie (suis bigleux ou quoi?)

 
Ahhh!!! J'ai recommencé, et cette fois-ci, je vois bien le rectangle. Pourtant je portais mes lunettes la première fois que j'ai essayé! Bon, il faut dire qu'entre temps, j'ai remplacé ma vieille version de mplayer par une récente, ça doit expliquer. En tout cas, le cropdetect fonctionne à merveille!

Bon, et bien j'ai relancé le script sans utiliser cat, et j'ai toujours une erreur lors de la deuxième passe:
./ffsaencoder.sh: line 109: 3967 Erreur de segmentation (suivi du contenu de la ligne 109)
 
A noter que j'ai au début du début de la deuxième passe le message suivant:
Cannot generate tables.
 
Ce message apparaît aussi lorsque je lis un film avec mplayer. Je ne suis pas sûr qu'il y ait là un lien avec l'erreur de segmentation que j'obtiens...
 
Avez-vous une idée?

 
Oui. Telecharge le CVS de MPlayer (+CVS libavcodec) ou utilise au moins la derniere pre version (la 9). On ne peut pas diagnostiquer les problemes si tu n'utilises pas les derniers patches.

J'espère vous envoyer ce soir la 1ere version de mon script. C'est (et ça ne sera pas) fini mais c'est quand même pas mal fonctionnel.
 
J'ai testé (avec succés ) avec mplayer0.90pre9 (compilé en anglais) et transcodeCVS.
 
Ce qu'il reste à faire :
1) le mux avec ogmmerge + vérification/correction de la synchro (bouclage...)
2) des bricoles : présence des softs requis, espace suffisant dans /space.
3) options de fin : shutdown, gravure...
4) menu de config : pour créer des preferences...
5) faire en sorte que ça marche sans X.
6) ??? des idées ?
 
PS : c'est et ça restera de l'utilisation de LL. (pour les raisons expliquées par zeb2/mean et par choix "politico-philosophique" ). Pour le moment lavc/ogg et + tard xvid ou lavc et ogg.