From 2e8119be9a7474b3f86c53db044cfaa7ec27cbea Mon Sep 17 00:00:00 2001 From: Uoti Urpala Date: Mon, 16 Jul 2012 22:10:28 +0300 Subject: docs: delete outdated translated manpages/docs Delete all manpages and XML documentation in languages other than English. The XML documentation was badly out of date. The content of translated manpages was somewhat out of date, and manpage formatting will change to use reStructuredText instead of raw troff format. If updated translations are created for some languages later, I think it's better to maintain those outside the main repository. --- DOCS/xml/fr/bugreports.xml | 508 ---- DOCS/xml/fr/documentation.xml | 183 -- DOCS/xml/fr/encoding-guide.xml | 5401 ---------------------------------------- DOCS/xml/fr/faq.xml | 1233 --------- DOCS/xml/fr/install.xml | 492 ---- DOCS/xml/fr/mencoder.xml | 823 ------ DOCS/xml/fr/ports.xml | 888 ------- DOCS/xml/fr/skin.xml | 1158 --------- DOCS/xml/fr/usage.xml | 1946 --------------- DOCS/xml/fr/video.xml | 3002 ---------------------- 10 files changed, 15634 deletions(-) delete mode 100644 DOCS/xml/fr/bugreports.xml delete mode 100644 DOCS/xml/fr/documentation.xml delete mode 100644 DOCS/xml/fr/encoding-guide.xml delete mode 100644 DOCS/xml/fr/faq.xml delete mode 100644 DOCS/xml/fr/install.xml delete mode 100644 DOCS/xml/fr/mencoder.xml delete mode 100644 DOCS/xml/fr/ports.xml delete mode 100644 DOCS/xml/fr/skin.xml delete mode 100644 DOCS/xml/fr/usage.xml delete mode 100644 DOCS/xml/fr/video.xml (limited to 'DOCS/xml/fr') diff --git a/DOCS/xml/fr/bugreports.xml b/DOCS/xml/fr/bugreports.xml deleted file mode 100644 index 88ed6bb9ac..0000000000 --- a/DOCS/xml/fr/bugreports.xml +++ /dev/null @@ -1,508 +0,0 @@ - - - -Comment rapporter les bogues - - -Les bons rapports de bogue sont une contribution précieuse pour tout projet en -développement. Mais tout comme pour écrire un bon logiciel, les bons rapports -de problèmes exigent du travail. Rendez-vous compte que la plupart des -développeurs sont extrêmement occupés et reçoivent un nombre colossal d'emails. -Donc bien que votre retour soit crucial pour l'amélioration de -MPlayer et soit très apprécié, comprenez que vous -devez fournir toutes les informations que nous -demandons et suivre de près les instructions de ce document. - - - - - - - -Rapport de sécurité lié aux bogues - - -Au cas où vous trouveriez un bogue exploitable, laissez-nous le temps de le -corriger avant de le révéler. Vous pouvez envoyer vos alertes de sécurité à -security@mplayerhq.hu. -Veuillez ajouter [SECURITE] ou [CONSEILLE] dans le sujet. -Soyez sûr que votre rapport contienne une analyse complète et détailée du bogue. -L'envoi d'un correctif est hautement apprécié. -Veuillez ne pas retarder l'envoi de votre rapport juste pour l'écriture d'une -preuve que le bogue est exploitable, vous pouvez envoyer ceci dans un autre -message. - - - - - - - - -Comment réparer les bogues - - -Si vous pensez avoir les talents nécessaires vous êtes invité à essayer de -réparer le bogue vous-même. Ou peut-être l'avez-vous déjà fait ? -Veuillez lire ce court document -(en anglais) pour trouver comment faire inclure votre code dans -MPlayer. -Les gens de la liste de diffusion -MPlayer-dev-eng -vous assisterons si vous avez des questions. - - - - - - - - - -Comment faire des tests de regression en utilisant Subversion - - - Un problème qui peut survenir quelque fois est «cela marchait avant, -et plus maintenant...». -Voici une procédure étape-par-étape pour tenter d'indiquer quand exactement -le problème s'est produit. Ceci n'est pas pour les utilisateurs -occasionnels. - - - -Premièrement, vous aurez besoin de récuperer l'arbre des sources de MPlayer depuis le dépot -Subversion. -Les instructions peuvent être trouvé au bas de -cette page. - - - -Vous aurez donc dans le repertoire mplayer/ une image de l'arbre Subversion, du coté -client. -Maintenant mettez à jour cette image à la date voulue : - -cd mplayer/ -svn update -r {"2004-08-23"} - -Le format de date est AAAA-MM-JJ HH:MM:SS. -Utiliser ce format de date vous assure que vous pourrez extraire les patches -selon la date à laquelle elles ont été fusionnés au dépot, comme dans l' -archive MPlayer-cvslog. - - - -Maintenant procéder comme pour une mise-à-jour normale : - -./configure -make - - - - -Pour un non-informaticien qui lit ceci, la méthode la plus rapide d'arriver au point -où le problème se produit est d'utiliser une recherche dichotomique — qui est, -chercher la date où est survenu le problème en divisant à plusieurs reprises l'intervalle -de recherche par moitié. -Par exemple, si le problème se produit en 2003, commencez en milieu d'année, puis demandez-vous -"Le problème est-il déjà présent à ce moment?". -Si oui, revenez au premier Avril; si non, allez au premier Octobre, -et ainsi de suite. - - - -Si vous avez beaucoup d'espace libre sur le disque dur (une compilation complète des sources prend actuellement -100 MO, et environ 300-350 MO si les symboles de déboguage sont activés), copiez la -plus vieille version fonctionnelle connue avant de la mettre à jour; cela sauvera du temps si -vous devez y revenir. -(Il est habituellement nécessaire de lancer 'make distclean' avant de recompiller une -version plus récente, donc si vous ne faites pas une copie de sauvegarde de votre arbre -source original, vous devrez tout recompiler dedans quand vous reviendrez -à la version présente.) - - - -Quand vous avez trouvé le jour où le problème survient, continuez la recherche -en utilisant l'archive mplayer-cvslog (triée par date) et en affinant par des -mises-à-jour depuis Subversion en précisant heure, minute et seconde : - -svn update -r {"2004-08-23 15:17:25"} - -Cela vous permettra de trouver facilement le patch exact à l'origine du problème. - - - -Si vous trouvez le patch qui est la cause du problème, vous avez quasiement gagné; -signalez le à -MPlayer Bugzilla ou -souscrivez à -MPlayer-users -et postez-le là. -Il y a une chance pour que l'auteur s'empresse de suggérer un correctif. -Vous pouvez également décortiquer le patch jusqu'à ce que le bug vous saute aux yeux :-). - - - - - - - - -Comment rapporter les bogues - - -Tout d'abord veuillez essayer la dernière version Subversion de MPlayer -car votre bogue y est peut-être déjà réparé. Le développement évolue -très rapidement, la plupart des problèmes des versions officielles sont -rapportés dans les jours voir les heures qui suivent, donc n'utilisez -que la version Subversion pour rapporter les bogues. Ceci -est également valable pour les paquets binaires de MPlayer. -Les instructions Subversion peuvent être trouvées en bas de -cette page -ou dans le README. Si tout cela ne vous aide pas, veuillez vous référer -au reste de la documentation. -Si votre problème n'est pas connu ou non résolvable avec nos instructions, alors merci -de rapporter le bogue. - - - -Merci de ne pas envoyer de rapports de bogues en privé à chaque développeur. -C'est un travail commun et il y a donc pas mal de gens que cela pourrait -intéresser. -Parfois d'autres utilisateurs ont rencontré les mêmes ennuis que vous et -savent comment contourner le problème même si c'est un bogue dans le code -de MPlayer. - - - -Merci de décrire votre problème avec le plus de détails possibles. -Faites un petit travail de détective pour restreindre les conditions -d'occurrence du problème. -Est ce que le bogue ne se montre que dans certaines situations ? -Est-il spécifique à certains fichiers ou types de fichier ? -Apparaît-il avec un seul codec ou est-ce indépendant du codec ? -Pouvez-vous le reproduire avec tous les pilotes de sortie ? -Plus vous fournissez d'information, plus grandes sont nos chances de résoudre -votre problème. -Merci de ne pas oublier d'inclure également les informations importantes -requises plus bas, sinon nous ne pourront pas établir un diagnostic précis -de votre problème. - - - -Un guide excellent et bien écrit pour poser des questions sur les forums -publiques est - -Comment Poser Les Questions De Manière Intelligente par Eric S. Raymond. -Il y en a un autre (en anglais) appelé -How to Report -Bugs Effectively par Simon Tatham. -Si vous suivez ces règles vous devriez pouvoir obtenir de l'aide. -Mais merci de comprendre que nous suivons tous les listes de diffusion -volontairement sur notre temps libre. -Nous sommes très occupés et ne pouvons garantir que vous aurez une solution à -votre problème ou même une réponse. - - - - - - - - -Où rapporter les bogues - - -Souscrivez à la liste de diffusion mplayer-users : - -et envoyez votre rapport à - où vous pourrez en discuter. - - - -Si vous préférez, vous pouvez utiliser notre tout nouveau -Bugzilla à la place. - - - -La langue de cette liste est l'Anglais. -Suivez les Règles de la Netiquette -SVP et n'envoyez de mails en HTML sur -aucune de nos listes de diffusion. -Vous ne serez qu'ignoré ou banni. -Si vous ne savez pas ce qu'est un mail en HTML ou pourquoi c'est mauvais, -lisez ce sympatique document -(en Anglais). -Il explique tous les détails et a des instructions pour désactiver le HTML. -Notez également que nous ne ferons pas de CC (copie conforme) individuelle -et que c'est donc une bonne idée de souscrire pour recevoir votre réponse. - - - - - - - - -Que rapporter - - -Vous pouvez avoir besoin d'inclure des fichiers de log, de configuration -ou d'échantillon. Si certains sont très gros alors il vaut mieux les uploader -sur notre serveur FTP -en format compressé (gzip et bzip2 préférés) et indiquer uniquement leur -chemin et nom dans le rapport de bogue. -Nos listes de diffusion ont une taille de message limite de 80k, si vous -avez quelque chose de plus gros vous devrez le compresser ou l'uploader. - - - - - -Information Système - - - - -Votre distribution Linux ou système d'exploitation et version, ex. : - - Red Hat 7.1 - Slackware 7.0 + paquets de développement de la 7.1 ... - - - -Version du noyau : -uname -a - - -Version de la libc : -ls -l /lib/libc[.-]* - - -Versions de gcc et ld : - -gcc -v -ld -v - - - -Version des binutils : -as --version - - -Si vous avez des problèmes avec le mode plein-écran : - - Type de gestionnaire de fenêtre et version - - - -Si vous avez des problèmes avec XVIDIX : - - Profondeur de couleur de X : -xdpyinfo | grep "depth of root" - - - - -Si seul le GUI (ou IHM - Interface Homme Machine) est boguée : - - Version de GTK - Version de GLIB - Position dans le GUI au moment où le bogue se produit - - - - - - - - - -Matériel et pilotes - - - - -Info CPU (cela ne fonctionne que sous Linux) : -cat /proc/cpuinfo - - -Fabricant et modèle de votre carte vidéo, ex. : - - Puce ASUS V3800U: nVidia TNT2 Ultra pro 32Mo SDRAM - - Matrox G400 DH 32Mo SGRAM - - - -Type et version des drivers vidéo, ex. : - - Pilote X intégré - nVidia 0.9.623 - Utah-GLX CVS 2001-02-17 - DRI avec X 4.0.3 - - - -Type de carte son et pilote, ex. : - - Creative SBLive! Gold avec pilote OSS de oss.creative.com - Creative SB16 avec pilotes noyau OSS - GUS PnP avec émulation OSS ALSA - - - -En cas de doute, joignez-y le résultat de lspci -vv sur les systèmes Linux. - - - - - - -Problèmes de configuration - - -Si vous rencontrez des erreurs pendant l'éxecution de ./configure, -ou si l'auto-détection ou autre chose échoue, lisez config.log. -Vous pourriez y trouver la réponse, par exemple des versions multiples -mélangées de la même librairie dans votre système, ou vous avez oublié -d'installer les paquets de développement (ceux avec le suffixe -dev). -Si vous pensez que c'est un bogue, incluez -config.log dans votre rapport de bogue. - - - - -Problèmes de compilation - - -Veuillez inclure ces fichiers : - -config.h -config.mak - - - - - -Problèmes de lecture - - -Merci d'inclure la sortie de MPlayer en verbosité niveau 1, -mais rappelez-vous de ne pas tronquer la sortie en le -copiant dans votre mail. Les développeurs ont besoin de tous les messages -pour diagnostiquer correctement un problème. Vous pouvez rediriger la sortie -dans un fichier comme ceci : -mplayer -v options nomfichier > mplayer.log 2>&1 - - - -Si votre problème est spécifique à un ou plusieurs fichiers, alors merci d'uploader -le(s) fautif(s) sur : - - - - -Uploadez aussi un petit fichier texte ayant le même nom que votre fichier -mais avec une extension .txt. -Décrivez le problème que vous avez avec ce fichier et incluez votre adresse -e-mail ainsi que la sortie de MPlayer en verbosité niveau 1. -Généralement les premiers 1-5 Mo sont suffisants pour reproduire le problème, -mais pour être sûrs nous vous demandons de faire : -dd if=votre_fichier of=petit_fichier bs=1024k count=5 -Cela coupera les 5 premiers Mo de 'votre_fichier' -et les sauvera dans 'petit_fichier'. -Essayez alors de lire le petit fichier, et si le bogue persiste vous pouvez -envoyer le petit fichier par ftp. N'envoyez jamais -ces fichiers par e-mail SVP ! -Envoyez-les par FTP, et postez seulement le chemin/nom des fichiers sur le serveur -FTP. Si le fichier est accessible en téléchargement à partir d'Internet, alors -envoyez seulement son adresse URL exacte. - - - - - - -Plantages - - -Vous devez lancer MPlayer à l'intérieur de -gdb et nous envoyer le résultat complet ou si vous -avez un core dump du plantage vous pouvez extraire -des informations utiles du fichier Core. Voici comment : - - - - -Comment conserver les informations sur un plantage reproductible - - -Recompilez MPlayer avec les instructions de -déboguage activées : - -./configure --enable-debug=3 -make - -et ensuite lancez MPlayer à l'intérieur de gdb en utilisant : -gdb ./mplayer -Vous êtes maintenant à l'intérieur de gdb. Tapez : -run -v options-pour-mplayer nomfichier -et reproduisez votre plantage. -Aussitôt que vous l'avez fait, gdb va vous renvoyer à la ligne de commande -où vous devrez entrer - -bt -disass $pc-32 $pc+32 -info all-registers - - - - - - -Comment extraire les informations significatives d'un core dump - - -Créer le fichier de commande suivant : - -bt -disass $pc-32 $pc+32 -info all-registers - -Ensuite exécutez simplement la commande : -gdb mplayer --core=core -batch --command=fichier_de_commande > mplayer.bug - - - - - - - - - - -Je sais ce que je fait... - - -Si vous avez créé un rapport de bogue correct en suivant les étapes -ci-dessus et que vous êtes persuadé qu'il s'agit d'un bug dans -MPlayer, et non un problème de compilateur -ou d'un fichier endommagé, vous avez déjà lu la documentation et vous -n'arrivez pas à trouver une solution, vos pilotes son sont OK, alors -vous pouvez souscrire à la liste mplayer-advusers et y envoyer votre -rapport pour obtenir une réponse plus intéressante et plus rapide. - - - -Soyez prévenu que si vous posez des questions de newbie (débutant) ou -des questions dont les réponses sont dans le manuel, vous serez ignoré -ou insulté au lieu de recevoir une réponse appropriée. -Donc ne nous insultez pas et ne vous inscrivez à -advusers que si vous -savez vraiment ce que vous faites et vous sentez en mesure d'être un -utilisateur avancé de MPlayer ou un développeur. -Si vous correspondez à ces critères il ne devrait pas être difficile de -trouver comment on s'inscrit... - - - - diff --git a/DOCS/xml/fr/documentation.xml b/DOCS/xml/fr/documentation.xml deleted file mode 100644 index 98fe7f2935..0000000000 --- a/DOCS/xml/fr/documentation.xml +++ /dev/null @@ -1,183 +0,0 @@ - - - - -<application>MPlayer</application> - Le Lecteur Vidéo - -30 Novembre 2004 - - 2000 - 2001 - 2002 - 2003 - 2004 - 2005 - 2006 - 2007 - 2008 - 2009 - 2010 - MPlayer team - - - License - MPlayer is free software; you can redistribute it and/or modify - it under the terms of the GNU General Public License as published by the - Free Software Foundation; either version 2 of the License, or (at your - option) any later version. - - MPlayer is distributed in the hope that it will be useful, but - WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY - or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License - for more details. - - You should have received a copy of the GNU General Public License - along with MPlayer; if not, write to the Free Software Foundation, - Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. - - - - - -Comment lire cette documentation - - -Si c'est votre première installation, assurez-vous de tout lire d'ici -jusqu'à la fin de la section Installation, et de suivre tous les liens que vous -pourrez trouver. Si vous avez d'autres questions, retournez à la -table des matières, lisez la -ou faites une recherche dans ces fichiers. -La plupart des questions devraient trouver leur réponse ici et le -reste a probablement déjà été demandé sur nos -listes de diffusion. -Regardez leurs archives, -il y a beaucoup d'informations intéressantes à y trouver. - - - - - - -Introduction - - -MPlayer est un lecteur de vidéos pour GNU/Linux -(fonctionne sur de nombreux autres Un*x, et processeurs non-x86, voir la -section ). -Il lit la majorité des fichiers MPEG, VOB, AVI, OGG/OGM, VIVO, ASF/WMA/WMV, -QT/MOV/MP4, FLI, RM, NuppelVideo, yuv4mpeg, FILM, RoQ, PVA, Matroska supportés -par de nombreux codecs natifs, XAnim, RealPlayer et les DLLs Win32. -Vous pouvez regarder les VideoCD, SVCD, DVD, 3ivx, RealMedia, Sorenson, -Theora, ainsi que les vidéos au format MPEG-4 (DivX). -L'autre point fort de MPlayer est la grande -variété de pilotes de sortie supportée. -Il fonctionne avec X11, Xv, DGA, OpenGL, SVGAlib, fbdev, AAlib, libcaca, -DirectFB, mais vous pouvez utiliser GGI et SDL (et ainsi tous leurs pilotes) -et également certains pilotes de bas niveau spécifiques à certaines cartes -(pour Matrox, 3Dfx et Radeon, Mach64, Permedia3) ! -La plupart d'entre eux supportent le redimmensionnement logiciel ou -matériel, vous pouvez donc apprécier les films en plein écran. -MPlayer supporte la décompression matérielle -fournie par certaines cartes MPEG, telles que la DVB -et la DXR3/Hollywood+. -Et que dire de ces superbes sous-titres ombrés et lissés (14 -types supportés) avec des polices européennes/ISO 8859-1,2 -(Hongrois, Anglais, Tchèque, etc.), Cyrilliques, Coréennes, ainsi que de -l'Affichage Sur Ecran (ou OSD = On Screen Display) ? - - - -Ce lecteur peut lire les fichiers MPEG endommagés (utile pour certains VCDs), -ainsi que les mauvais fichiers AVI qui ne sont pas lisibles par le célèbre -Windows Media Player. -Même les fichiers AVI sans index sont lisibles, et vous pouvez reconstruire -leurs indexs soit temporairement avec l'option , -soit de manière définitive avec MEncoder, autorisant -ainsi l'avance/retour rapide ! -Comme vous pouvez le constater, la stabilité et la qualité sont les choses -les plus importantes, mais la vitesse est également formidable. -Il y a également un puissant système de filtres pour faire de la manipulation -vidéo et audio. - - - -MEncoder (Le Movie Encoder de -MPlayer) est un simple encodeur de vidéos, conçu -pour encoder des vidéos jouables par MPlayer -(AVI/ASF/OGG/DVD/VCD/VOB/MPG/MOV/VIV/FLI/RM/NUV/NET/PVA) -dans d'autres formats jouables par MPlayer -(voir plus bas). -Il peut encoder avec des codecs variés comme MPEG-4 (DivX4) -(1 ou 2 passes),libavcodec, -audio PCM/MP3/MP3 VBR. - - - - -Fonctionnalités de <application>MEncoder</application> -Encodage à partir de la grande variété de formats de fichiers -et de décodeurs de MPlayer - - Encodage dans tous les codecs - libavcodec de FFmpeg - - - Encodage vidéo depuis les tuners TV compatibles V4L - - - Encodage/multiplexage vers fichiers AVI entrelacés avec index propre - - - Création de fichiers à partir de flux audio externes - - - Encodage 1, 2 ou 3 passes - - - MP3 audio VBR - - - PCM audio - - - Copie de flux (stream) - - - Synchronisation A/V de la source (basé sur PTS, peut être désactivé avec l'option - ) - - - Correction FPS avec l'option (utile - pour l'encodage d'un VOB 30000/1001 fps en AVI 24000/1001 fps) - - - Utilise notre très puissant système de plugins (crop, expand, - flip, postprocess, rotate, scale, conversion rgb/yuv) - - - Peut encoder les sous-titres DVD/VOBsub et - le texte des sous-titres dans le fichier de destination - - - Peut ripper les sous-titres DVD en format VOBsub - - - - - -MPlayer et MEncoder -peuvent être distribués selon les termes de la GNU General Public License Version 2. - - - - -&install.xml; - -&usage.xml; -&video.xml; -&ports.xml; -&mencoder.xml; -&encoding-guide.xml; -&faq.xml; -&bugreports.xml; -&skin.xml; diff --git a/DOCS/xml/fr/encoding-guide.xml b/DOCS/xml/fr/encoding-guide.xml deleted file mode 100644 index 5026788674..0000000000 --- a/DOCS/xml/fr/encoding-guide.xml +++ /dev/null @@ -1,5401 +0,0 @@ - - - -L'encodage avec <application>MEncoder</application> - - -Faire un MPEG-4 ("DivX") de bonne qualité à partir d'un DVD - - - Il y a une question qui revient souvent :"Comment puis-je recopier un DVD avec la - meilleure qualité possible pour une taille donnée ?". Ou encore : - "Comment puis-je recopier un DVD sur mon disque dur avec la meilleure qualité - possible ? je m'en fiche de la taille du fichier, je veux la meilleure - qualité." - - - - Cette dernière question est peut-être un peu mal posée. Après tout, si vous ne vous - souciez pas de la taille du fichier, pourquoi ne pas simplement copier le - flux MPEG-2 du DVD en entier ? Bien sûr, votre AVI finira par faire 5Gb, - mais si vous voulez la meilleure qualité, sans vous soucier de la - taille, ceci est probablement votre meilleure option. - - - - En fait, la raison pour laquelle vous voulez convertir un DVD en MPEG-4 - est que vous tenez réellement compte - de la taille du fichier. - - - - Il est difficile de proposer une recette sur la façon de créer des MPEG-4 - de très haute qualité à partir de DVD. Il y a plusieurs facteurs à prendre en compte, et vous - devriez comprendre ces détails ou vous serez déçus par les résultats. Ci-dessous - nous allons examiner quelques-uns de ces problèmes, et voir un exemple. Nous - supposerons que vous utilisez libavcodec pour encoder - la vidéo, bien que la théorie s'applique également à d'autres codecs. - - - - Si vous ne vous sentez pas de taille, vous devriez utiliser une des - interfaces graphiques listées sur la page de notre projet dans - Section - MEncoder. - Ainsi, vous devriez être capable de faire de encodages de DVD de haute qualité - sans trop réfléchir, ces outils sont faits pour prendre les bonnes décisions à votre place. - - - -Préparer l'encodage : identifier le matériel source et le nombre -d'images par secondes - - Avant même de penser à encoder un film, il est nécessaire de passer par quelques étapes - préliminaires. - - - - La première et plus importante étape avant l'encodage sera la détermination du - type de contenu utilisé. Si votre matériel source provient d'un DVD ou de la télévision - hertzienne/câble/satellite, il sera stocké sous l'un de ces 2 formats : - NTSC pour l'Amérique du nord et le Japon, et PAL pour l'Europe, etc. - Il est important de réaliser que ceci est uniquement un format adapté pour - la télévision et cela ne correspond souvent pas - au format original du film. - L'expérience montre que le NTSC est bien plus dur à encoder car il y a plus - d'éléments à identifier dans la source. - Afin de produire un encodage acceptable, vous devez connaître le format original. - Négliger cette étape créera divers défauts dans votre encodage, dont de hideux effets - de peigne et des images dupliquées ou même perdues. De plus, ces artefacts - sont mauvais pour l'efficacité d'encodage : vous obtiendriez une moins -bonne qualité - pour le même débit. - - - -Identification du nombre d'images par seconde de la source - - Voici une liste de types de matériel source courants, où vous devriez les trouver et - leurs propriétés : - - - - Film standard : produit pour une - diffusion cinématographique en 24 images par secondes. - - - Vidéo PAL : Enregistrée par une - caméra à 50 trames par secondes. - Une trame consiste en l'ensemble des lignes paires (ou impaires) d'une - image. - La télévision a été créée de façon à afficher alternativement l'une ou - l'autre de ces trames créant ainsi une forme de compression analogique bon - marché. - L'oeil humain est censé compenser cette alternance de trames mais dès lors - que vous - comprenez l'entrelacement, vous apprendrez à le voir sur la télévision et vous ne la regarderez - plus de la même façon. Deux trames ne font pas une image - complète, car elles sont capturées avec un décalage d'1/50e de seconde et donc, à moins - qu'il n'y ait pas de mouvement, elles ne s'alignent pas parfaitement. - - - Vidéo NTSC : Enregistré par une - caméra à 60000/1001 trames par secondes, ou 60 trames par secondes dans - l'ère noir/blanc. - A part cela, similaire au PAL. - - - Dessins animés : Habituellement - dessiné en 24 images par secondes, peut exister en mélange variés de - nombre d'images par secondes. - - - Infographie : peut être de - n'importe quel nombre d'images par secondes mais certains sont plus communs que d'autres; - 24 et 30 sont typiques du NTSC et 25 du PAL. - - - Vieux films : nombre d'images par - secondes généralement plus bas. - - - - - -Identification du matériel source - - Les films composés d'images entières sont dits progressifs, - alors que ceux composés de trames indépendantes sont appelés - soit entrelacés soit vidéo - bien que ce dernier terme soit plutôt ambigu. - - - Pour compliquer le tout, certains films sont un mélange des 2. - - - La distinction la plus importante qui doit être faite entre ces formats - est que certains utilisent des images entières alors que d'autres, des trames. - Avant d'être visionnable sur un téléviseur, - tout - film (DVD inclus) doit être converti dans un - format basé sur des trames. Les diverses méthodes par lesquelles ceci peut être fait - peuvent être rassemblées sous le terme anglais "telecine", parmi lesquels l'infâme - NTSC "3:2 pulldown" en est une variété. - A moins que la vidéo source ne soit déjà basée sur des trames (et avec le bon nombre de trames par seconde), - vous avez un film dans un format autre que celui d'origine. - - - - Plusieurs variétés communes de pulldown : - - Pulldown PAL 2:2  : Le plus joli de - tous. - Chaque image est affichée pour la durée de deux trames par extraction des lignes - paires et impaires, puis en les affichant par alternance. - Si l'original est à 24 images par secondes, ce procédé accélère le film de 4%. - - - pulldown PAL 2:2:2:2:2:2:2:2:2:2:2:3 : - Toutes les 12 images, une image est affichées pour la durée de 3 trames au - lieu de deux. Cela - permet d'éviter le problème de l'accélération de 4% mais rend le processus bien plus - difficile à inverser. Cette technique est généralement utilisée dans les productions - musicales où l'accélération de 4% endommagerait sérieusement la qualité musicale. - - - Téléciné NTSC 3:2 : Les images sont - alternativement - affichées pendant une durée de 3 ou 2 trames. Cela donne un nombre de trames par seconde - de 2,5 fois le nombre d'images par seconde de l'original. - Le résultat est aussi très légèrement ralenti de 60 trames par secondes à 60000/1001 - trames par seconde pour maintenir la vitesse d'affichage NTSC. - - - Pulldown NTSC 2:2 : Utilisé pour - montrer du 30 images par secondes sur du NTSC. Joli, comme le pulldown PAL - 2:2. - - - - - Il y aussi des méthodes de conversion entre vidéos NTSC et PAL - mais cela sort du cadre de ce guide. - Au cas où vous rencontriez un film au format NTSC ou PAL et vouliez l'encodez, - le mieux serait de trouver une copie du film dans le format original. - La conversion entre ces deux formats est hautement destructrice et ne peut - être inversee proprement, votre encodage en souffrirait grandement s'il était - fait à partir d'une source déja convertie (en NTSC ou PAL). - - - Quand des vidéos sont stockées sur un DVD, les paires de trames - consécutives sont rassemblées en une image même si elles ne sont pas censées - être affichées au même moment. - Le standard MPEG-2 utilisé dans les DVDs et la télévision numérique fournit - un moyen à la fois d'encoder les images progressives originales et de stocker le - numéro des trames auxquelles une image doit être montrée dans l'en-tête de cette image. - Si cette méthode est utilisée, on dit que le film est "soft-téléciné" - puisque le procédé impose uniquement au lecteur DVD d'appliquer le pulldown sur le film - plutôt que d'altérer le film lui-même. - Ce cas est de loin préférable puisqu'il peut être facilement inversé - (en fait, ignoré) par l'encodeur et puisqu'il préserve la qualité au maximum. - Malgré cela, beaucoup de studios de production de DVD et d'émission n'utilisent pas - les techniques d'encodage correctes, au lieu de cela, elles produisent des films en "hard telecine" - dans lesquels des trames sont dupliquées dans l'encodage MPEG-2. - - - Les étapes pour gérer correctement ce genre de cas seront évoquées plus tard dans ce guide. - Pour l'instant, nous allons vous donner quelques indications pour définir à quel type - source vous avez à faire : - - - - Régions NTSC : - - Si MPlayer affiche que le nombre d'image a changé en - 24000/1001 quand vous regardez votre film et qu'il ne change plus après cela, c'est - presque certainement un contenu progressif qui a été "soft téléciné". - - - Si MPlayer affiche un nombre d'images par seconde alternant - entre 24000/1001 et 30000/1001 et que vous voyez un effet de peigne par moment, alors - il y a plusieurs possibilités. - Les segments en 24000/1001 images par seconde sont très certainement un contenu progressif, - "soft teleciné" mais les parties en 30000/1001 images par secondes peuvent être soit - un contenu en 24000/1001 images par seconde "hard-telecinées", soit une vidéo NTSC en - 60000/1001 trames par seconde. - Utilisez les mêmes conseils que ceux pour les deux cas qui suivent pour savoir lequel. - - - Si MPlayer montre un nombre d'images par seconde constant - et que chacune des images des scènes de mouvement souffre d'un effet de peigne, alors - votre film est une vidéo NTSC à 60000/1001 trames par seconde. - - - Si MPlayer montre un nombre d'images par seconde constant - et que deux images sur cinq souffrent d'un effet de peigne, votre film est "hard téléciné" - en 24000/1001 images par seconde. - - - - - Régions PAL : - - Si vous ne voyez jamais d'effet de peigne, le film est en pulldown 2:2. - - - Si vous voyez un effet de peigne apparaissant et disparaissant - toutes les demi-secondes, alors le film a subi un pulldown 2:2:2:2:2:2:2:2:2:2:2:3. - - - Si vous voyez toujours un effet de peigne dans les scènes de mouvement, - alors le film est en PAL à 50 trames par secondes. - - - -Astuce: - - MPlayer peut ralentir la lecture d'un film en utilisant - l'option ou le jouer image par image. - Essayer afin de regarder le film - très lentement ou presser la touche "." répététivement pour avancer - image par image et ainsi identifier la "signature" du pulldown si - celle-ci n'est pas visible à vitesse normale. - - - - - - -Quantificateur constant contre multipasse - - - Il est possible d'encoder votre film à de très différentes qualités. - Avec un encodeurs vidéo modernes et quelques compression pré-codec - (antibruit et redimensionnement) il est possible d'obtenir une - trés bonne qualité pour un film grand écran de 90-110 minutes sur 700Mb. - De plus, à part les plus longs, tous les films peuvent être encodés - à une qualité presque parfaite sur 1400Mb. - - - - Il y a trois approches possibles pour encoder une vidéo : débit - constant (CBR), quantification constante, et multipasse (ABR pour average - bitrate ou débit moyen). - - - - La complexité des images d'un film et donc le nombre de bits requis pour - les compresser peut varier grandement d'une scène à l'autre. - Les encodeurs vidéos modernes peuvent s'ajuster à ces besoins en faisant - varier le débit. - Cependant, dans des modes simples comme le CBR, le compresseur ne connaît - pas le besoin en débit pour les scènes à venir et ne peut donc pas excéder - le débit moyen requis pour de longues portions du film. - Des modes plus avancés, comme l'encodage multipasse peuvent prendre - en compte les statistiques des passes précédentes, ce qui règle le - problème ci-dessus. - - -Note : - - La plupart des codecs qui supportent la compression ABR supportent seulement deux - passages alors que d'autres comme le x264, - le Xvid et le - libavcodec supportent le multipasse - ce qui améliore légèrement la qualité à chaque passe même si ces améliorations - ne sont plus visibles ou mesurables après environ la quatrième passe. - Ainsi, dans cette section, deux passes et multipasse seront utilisés indifféremment. - - - - - Dans chacun de ces modes, le codec vidéo (tel que - libavcodec) - sépare les images vidéo en macroblocs de 16x16 pixels et applique ensuite - un quantificateur sur chaque macrobloc. Plus le quantificateur est bas, meilleure - est la qualité et plus le débit est grand. La méthode utilisée par - l'encodeur pour déterminer quel quantificateur utiliser pour un macrobloc donné - varie et est très configurable. (ceci est une simplification - à l'extrême du processus, mais il est utile de comprendre le principe de base). - - - - - Lorsque vous spécifiez un débit constant, le codec vidéo encode la vidéo - en excluant les détails autant qu'il le faut et aussi peu que possible - de façon à rester en dessous du débit spécifié. - Si la taille du fichier vous est vraiment égale, vous pourriez aussi bien - fixer un débit constant infini (en pratique, dela signifie une valeur assez - haute pour ne pas poser de limites, tel que 10000Kbit). Sans réelle - restriction de débit, le codec utilisera le plus - bas quantificateur possible pour chaque macrobloc (tel que spécifié par - pour libavcodec, - qui vaut 2 par défaut). Dès que vous spécifiez un débit suffisament bas pour - que le codec soit forcé d'utiliser un quantificateur plus grand, vous ruinez - très certainement la qualité votre vidéo. Pour éviter ça, vous devriez probablement - réduire la résolution de votre vidéo en suivant la méthode décrite plus tard - dans ce guide.En général, vous devriez éviter le CBR si vous vous souciez de - la qualité. - - - - Avec un quantificateur constant, le codec utilise - le même quantificateur (spécifié par l'option pour - libavcodec) sur chaque macrobloc. - Si vous voulez un encodage de la meilleure qualité possible, cette fois encore - en ignorant le débit, vous pouvez utiliser . Cela - donnera le même débit et le même PSNR (Peak Signal-to-Noise Ratio, rapport signal - sur bruit de crête) que le CBR avec =infini et la valeur - par défaut de  : 2. - - - - Le problème avec la quantification constante est que cela utilise le quantificateur - spécifié que le macrobloc en ait besoin ou non. En fait, il doit être possible - d'utiliser un quantificateur plus haut sur un macrobloc sans sacrifier la - qualité visuelle. Pourquoi gaspiller les bits avec un quantificateur inutilement - bas ? Votre microprocesseur est sûrement a largement assez puissant, - tandis que votre disque lui, a une taille limitée. - - - - Avec l'encodage deux passes, la première passe va encoder le film comme - en CBR, mais va garder un journal des propriétés de chaque image. Ces données - sont ensuite utilisées pendant la seconde passe de façon à choisir intelligemment - quels quantificateurs utiliser. Lors des scènes d'action rapide ou celles ayant - beaucoup de détails, des quantificateurs plus élevés seront probablement utilisés. - Pendant les scènes avec peu de mouvements ou avec peu de détails, ce seront - des quantificateurs plus bas. Normalement, la quantité de mouvement est bien plus - importante que la quantité de détail. - - - - Si vous utilisez , alors vous gaspillez des bits. - Si vous utilisez , vous n'avez pas la meilleure - qualité d'encodage. Supposez que vous encodez un DVD avec - , et que le résultat est 1800Kbit/s. Si vous faites - un encodage en deux passes avec , la vidéo produite - aura une meilleure qualité pour le - même débit. - - - - Maintenant que vous êtes convaincu que l'encodage deux passes est la bonne méthode, - la vraie question est maintenant de savoir quel débit utiliser. Il n'y a pas de - réponse toute faite. Idéalement, vous devriez choisir un débit offrant un compromis - entre qualité et taille de fichier. Cette valeur varie selon la vidéo source. - - - - Si la taille ne compte pas, un bon point de départ pour un encodage de très haute - qualité est environ 2000kbit/s plus ou moins 200kbit/s. - Pour les vidéos comportant beaucoup d'actions ou de détails ou si vous avez - de très bon yeux, vous pouvez choisir 2400 ou 2600. - Pour certains DVDs, vous pourriez ne pas voir de différence à 1400kbps. C'est une - bonne idée que d'essayer sur des scènes avec différents débits pour se rendre - compte. - - - - Si vous avez fixé une taille limite, alors il faudra d'une certaine façon calculer - le débit. Mais avant cela, il faudra définir l'espace que - vous réservez aux piste(s) audio et vous devrez - les encoder en premier. - Vous pourrez alors calculer le débit souhaité avec l'équation - suivante : - Débit = (taille_fichier_final_en_Mo - taille_fichier_son_en_Mo) * - 1024 * 1024 / durée_en_secondes * 8 / 1000 - Par exemple, pour ramener deux heures de films sur un CD de 702Mo avec une piste - son de 60Mo, le débit vidéo sera alors de : - (702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000 = 740kbit/s - - - - -Contraintes pour une compression efficace - - - De par la nature intrinsèque de la compression MPEG, de nombreux - paramètres entrent en jeu afin d'obtenir une qualité maximale. - Le MPEG découpe la vidéo en carré de 16x16 appelé macroblocs. Chacun - d'entre eux est composé de 4 petits (8x8) blocs contenant des informations sur - la luminosité (intensité) ainsi que de 2 blocs (donc à résolution moitié) - contenant des informations chromatiques (pour les teintes rouge-cyan et bleu-jaune). - Même si la longueur et la largeur du film ne sont pas des multiples de 16, - l'encodeur utilisera des macroblocs de 16x16 pour couvrir l'image entière, - l'espace restant sera alors perdu. - Si votre intérêt est de conserver une très bonne qualité, utiliser des résolutions - non multiples de 16 n'est pas une bonne idée. - - - - La plupart des DVDs ont aussi des bandes noires sur les bords. Négliger - ces parties peut grandement altérer la qualité de plusieurs manières. - - - - - - La compression MPEG est aussi dépendante du domaine de transformation des - fréquences, en particulier du "Discrete Cosine Transform (DCT)" (similaire à une - transformée de Fourier). Ce type d'encodage est efficace pour les - formes et les transitions douces, mais fonctionne moins bien avec les contours - acérés. Afin d'encoder correctement, il demandera plus de bits, sinon des - artefacts de compression apparaîtront, aussi connus sous le nom de "ringing". - - - - La transformation en fréquence (DCT) prend place séparément dans chaque - macrobloc (en fait, dans chaque bloc), donc le problème n'apparaîtra - que si un bord franc se situe dans ce bloc. Si vos bordures noires commencent - exactement sur un multiple de 16, ce ne sera pas un problème. En pratique, - les bordures ne sont jamais bien alignées, et il sera certainement - nécessaire de les couper pour éviter ces défauts. - - - - - - En plus des transformations au niveau des fréquences, la compression MPEG - utilise des vecteurs de mouvements représentant les changements d'une image - à la suivante. Ces vecteurs de mouvements voient leur utilité grandement - réduite quand la prochaine image à un contenu totalement différent. Quand - il y a un mouvement qui sort de la région encodée, cela ne pose pas de problème - aux vecteurs. En revanche, cela peut poser des problèmes avec les bandes - noires : - - - - - - Pour chaque macrobloc, la compression MPEG stocke un vecteur identifiant - quelle partie de l'image précédente devrait être copiée dans les macroblocs - de l'image suivante. Seules les différences devront alors être encodées. - Si le macrobloc s'étend et prend en compte une des bordures noire de l'image, - alors le vecteur de mouvement écrasera la bordure noire. Cela veut dire que de - nombreux bits sont gaspillés pour re-noircir la bande noire ou alors (plus probable) que le vecteur - de mouvement ne sera pas du tout utilisé et que tout le macrobloc - devra alors être ré-encodé. Dans tous les cas, l'efficacité de l'encodage en est - grandement améliorée. - - - - Une fois encore, ce problème n'existe que si les lignes des bordures noires - ne sont pas un multiple de 16. - - - - - - Enfin, supposons que l'on ait un macrobloc à l'intérieur d'une image et qu'un - objet se déplace dans ce bloc proche d'un bord de l'image. Malheureusement, le - MPEG ne sait pas faire "copier juste la partie qui dans l'image et laisser tomber - la partie noire". Donc la partie noire sera alors aussi copiée, ce qui fait encore gaspiller - beaucoup de bits pour compresser un morceau d'image qui n'est pas sensé être là. - - - - Si l'objet en mouvement parcourt depuis le bord noir jusque dans la zone encodée, - le MPEG dispose d'optimisation spéciales pour copier en répétition des pixels - depuis le bord de l'image lorsque celui vient de l'extérieur de la partie encodée. - Ces optimisations deviennent inutiles quand le film à des bandes noires. Contrairement - aux problèmes 1 et 2, même les bordures noires multiples de 16 n'aident pas dans ce cas. - - - - - - Malgré le fait que les bordures soient entièrement noires et quelles ne changent jamais, - elles impliquent un léger surplus dû au plus grand nombre macroblocs à coder. - - - - - - Pour toutes ces raisons, il est préférable de couper entièrement ces bandes - noires. Dans la même optique, s'il y a une partie contenant du bruit ou de la - distorsion d'image près d'une bordure, la coupure l'enlèvera et permettra d'avoir - une amélioration significative de la qualité de l'encodage. Les puristes parmi les vidéophiles - souhaiteront préserver l'encodage le plus proche possible de - l'original, à moins qu'ils n'encodent avec un quantificateur constant, la qualité - gagnée après la suppression des bandes noires améliorera grandement la qualité - finale de l'encodage au regard des quelques informations perdues. - - - - - -Découpage et Redimensionnement - - - Vous vous souvenez de la section précédente que les dimensions (à la fois largeur et hauteur) - de l'image finale doivent être des - multiples de 16. Cela peut être réalisé par recadrage (découpe), - redimensionnement ou une combinaison des deux. - - - - Lors du recadrage, il y a quelques règles qui doivent être respectées pour éviter - d'endommager votre film. - Le format YUV normal, 4:2:0, stocke la chrominance (la couleur) de manière - sous-échantillonnée, c'est à dire que la chrominance est échantillonnée moitié moins - souvent que la luminance (intensité). Sur le schéma suivant, L indique l'échantillonage en luminance et C en chrominance. - - - - - - - - - - - - - - - - - - - - - L - L - L - L - L - L - L - L - - - C - C - C - C - - - L - L - L - L - L - L - L - L - - - L - L - L - L - L - L - L - L - - - C - C - C - C - - - L - L - L - L - L - L - L - L - - - - - - - Comme vous pouvez le voir, les lignes et colonnes de l'image viennent naturellement par deux. - Ainsi, les dimensions de votre recadrage ainsi que ses distances au bords d'origine - doivent être paires. Si elles ne - l'étaient pas, les chrominances et luminances ne seraient plus alignées. - En théorie, il est possible d'avoir des dimensions impaires, mais cela - requière un nouvel échantillonage de la chrominance, ce qui - engendre potentiellement des pertes d'information et n'est pas supporté par - le filtre de recadrage. - - - - Ensuite, la vidéo entrelacée est échantillonnée de la façon suivante : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Trame impaire - Trame paire - - - L - L - L - L - L - L - L - L - - - - - - - - - - - C - C - C - C - - - - - - - - - - - - - - - - - - - L - L - L - L - L - L - L - L - - - L - L - L - L - L - L - L - L - - - - - - - - - - - - - - - - - - - C - C - C - C - - - - - - - - - - - L - L - L - L - L - L - L - L - - - L - L - L - L - L - L - L - L - - - - - - - - - - - C - C - C - C - - - - - - - - - - - - - - - - - - - L - L - L - L - L - L - L - L - - - L - L - L - L - L - L - L - L - - - - - - - - - - - - - - - - - - - C - C - C - C - - - - - - - - - - - L - L - L - L - L - L - L - L - - - - - - - Comme vous pouvez le voir, le plus petit motif à se répéter est sur 4 lignes. - Donc, pour la vidéo entrelacée, la hauteur de votre recadrage et sa distance - verticale aux bords doivent être des multiples de 4. - - - - La résolution native pour un DVD NTSC est 720x480 et 720x576 pour un