From a58403389e1bc87b919373c7ca3bca2d7249549c Mon Sep 17 00:00:00 2001 From: gpoirier Date: Sat, 29 Jul 2006 15:31:22 +0000 Subject: Part 2 of the various fixes features by Jerome Ferrari git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@19242 b3059339-0415-0410-9bf9-f77b7e298cf2 --- DOCS/xml/fr/encoding-guide.xml | 230 ++++++++++++++++++++--------------------- 1 file changed, 112 insertions(+), 118 deletions(-) (limited to 'DOCS') diff --git a/DOCS/xml/fr/encoding-guide.xml b/DOCS/xml/fr/encoding-guide.xml index 1266f6422b..d48763b0da 100644 --- a/DOCS/xml/fr/encoding-guide.xml +++ b/DOCS/xml/fr/encoding-guide.xml @@ -2147,9 +2147,9 @@ Notez l'usage des options et . - Traitez-la comme entrelacée. Certaines frames des parties progressive auront - besoin d'être dupliquées, ce qui entraînera en un sautillement inégal. Encore une - fois, les filtres dés-entrelaçant peuvent passablement dégrader les parties + Traitez-le comme entrelacée. Certaines images des parties progressives auront + besoin d'être dupliquées, ce qui entraînera un sautillement irrégulier. Encore une + fois, les filtres désentrelaçant peuvent légèrement dégrader les parties progressives. @@ -2159,18 +2159,18 @@ Notez l'usage des options et . -Notes de pied +Notes de bas de pages - A propos de découpage: + A propos de recadrage: Les données vidéo d'un DVD sont stockées dans un format appelé YUV 4:2:0. Dans - la vidéo YUV, la luma ("luminosité") et le chroma ("couleur") - sont stockés séparément. Parce que l'oeil humain est somme toute moins sensible - à la couleur qu'il ne l'est à la luminosité, dans une image YUV 4:2:0 il y a - seulement un pixel de chroma pour 4 pixels de luma. Dans une image progressive, - chaque carré de quatre pixels de luma (deux sur chaque coté) ont un pixel de - chroma commun. Vous devez découper un YUV 4:2:0 progressif à des résolutions paires, + la vidéo YUV, la luminance ("luminosité") et la chrominance ("couleur") + sont stockés séparément. Parce que l'oeil humain est d'une certaine façon moins sensible + à la couleur qu'à la luminosité, dans une image YUV 4:2:0 il n'y a + qu'un pixel de chrominance pour 4 pixels de luminance. Dans une image progressive, + chaque carré de quatre pixels de luminance (deux de chaque coté) a un pixel de + chrominance commun. Vous devez recadrer le YUV 4:2:0 progressif à des résolutions paires, et utiliser un décalage pair. Par exemple, est correct mais ne l'est pas. @@ -2179,44 +2179,45 @@ Notez l'usage des options et . Quand vous avez à faire à un YUV 4:2:0 entrelacé, la situation devient un peu plus - compliquée. Au lieu que chaque série de quatre pixels de luma partage un pixel - de chroma dans une frame, chaque groupe de quatre pixels de luma - dans chaque champs partage un pixel de chroma. Quand les - champs sont entrelacés pour former une frame, chaque ligne de scan est un - pixel de haut. Maintenant, au lieu que tout les quatre pixels de luma soient - dans un carré, ils sont deux pixels côte à côte, et les deux autres pixels - sont côte à côte deux lignes de scan plus bas. Les deux pixels de luma dans la - ligne de scan intermédiaire sont à partir de l'autre champ, et donc partage un - pixel de chroma différent avec deux pixels de luma deux lignes de scan plus loin. - Toute cette confusion rend nécessaire d'avoir des dimensions de découpe verticales - et des décalages en multiple de quatre. Le décalage horizontal peut rester égal. + compliquée. Au lieu d'avoir chaque série de quatre pixels de luminance se partager un pixel + de chrominance dans une image, chaque série de quatre pixels de luminance + dans chaque champs se partage un pixel de chrominance. Quand les + trames sont entrelacées pour former une image, chaque ligne de scan fait un + pixel de haut. Maintenant, au lieu d'avoir la série de quatre pixels de luminance + dans un carré, il y a deux pixels côte à côte sur une ligne et les deux autres pixels + de la série sont côte à côte deux lignes de scan plus bas. Les deux pixels de luminance dans la + ligne de scan intermédiaire appartiennent à une autre trame, et donc partage un + pixel de chrominance différent avec deux pixels de luminance deux lignes de scan plus loin. + Toute cette confusion rend nécessaire d'avoir des dimensions de recadrage + et de décalage verticales multiples de quatre. Dans le sens horizontal, il suffit que les + dimensions restent paires. - Pour la vidéo télécinée, je recommande que le découpage prenne place après l'inverse - téléciné. Une fois la vidéo progressive vous avez seulement besoin de découper par - nombres pairs. Si vous voulez vraiment gagner la légère accélération que la découpe - peut offrir, vous devez découper verticalement par multiples de quatre - ou bien le filtre inverse-téléciné n'aura pas les bonnes données. + Pour la vidéo télécinée, il est recommandé que le recadrage se fasse après le + téléciné-inverse. Une fois que la vidéo est progressive, il vous suffit de recadrer par + nombres pairs. Si vous voulez accélérer légèrement la vitess d'encodage, en jouant sur les + dimensions de recadrage, vous devez recadrer verticalement par multiples de quatre + ou bien le filtre de téléciné-inverse n'aura pas les données adéquates. - Pour la vidéo entrelacée (pas télécinée), vous devez toujours découper verticalement - par multiples de quatre à moins que vous n'utilisiez avant de découper. + Pour la vidéo entrelacée (pas télécinée), vous devez toujours recadrer verticalement + par multiples de quatre à moins que vous n'utilisiez l'option avant. A propos des paramètres d'encodage et de la qualité: - Juste parce que je recommande ici ne veut pas dire - que cela ne devrait pas être utilisé autre part. Avec , + Le fait que l'option est recommandée ici ne veut pas dire + qu'elle ne devrait pas être utilisée autre part. Avec , est l'une des deux options de libavcodec - qui augmente le mieux la qualité, et vous devriez toujours utiliser au moins - une des deux à moins que la baisse de vitesse d'encodage ne soit prohibitive - (e.g. encodage temps réel). Il y a plusieurs autres options libavcodec - qui augmentent la qualité d'encodage (et réduisent la vitesse d'encodage) mais ceci est au delà - de la portée de ce document. + qui augmente le plus la qualité, et vous devriez toujours les utiliser + à moins que la baisse de vitesse d'encodage ne soit prohibitive + (ex: encodage en temps réel). Il y a bien d'autres options de + libavcodec qui augmentent la qualité d'encodage + (et réduisent sa rapidité) mais ceci est au delà du propos de ce document. @@ -2224,12 +2225,12 @@ Notez l'usage des options et . A propos de la performance de pullup: - Employer (avec ) - sur une vidéo progressive est sûr, et est habituellement une bonne idée à moins qu'il - ait été vérifié que la source est entièrement progressive. - La perte de performance est petite pour la plupart des cas. Sur un encodage minimal, - ralentit MEncoder de 50%. - L'ajout du traitement du son et d'options avancées pour masquent cette + Utiliser l'option (avec ) + sur une vidéo progressive est sans danger, et c'est généralement une bonne idée à moins qu'il + soit certain que la source est entièrement progressive. + La perte de performance est faible dans la plupart des cas. Sur un encodage minimal, + ralentit MEncoder de 50%. + L'ajout du traitement du son et d'options avancées de masquent cette différence, en limitant la perte de performance due à l'utilisation de à 2%. @@ -2251,7 +2252,7 @@ Vous pouvez encoder vers les codecs suivant (la liste suivante est plus ou moins -codecs vidéo de <systemitem class="library">libavcodec</systemitem> +Codecs vidéo de <systemitem class="library">libavcodec</systemitem> @@ -2330,8 +2331,8 @@ Vous pouvez encoder vers les codecs suivant (la liste suivante est plus ou moins -La première colonne contient les noms de codec qui doivent être passés après la -configuration de vcodec, comme ceci: +La première colonne contient les noms de codec qui doivent être donnés après la +configuration de vcodec, par exemple comme ceci: @@ -2370,8 +2371,8 @@ Un exemple avec la compression MJPEG: -La première colonne contient les noms du codec qui devra être passée après l'option -acodec, comme ceci: +La première colonne contient les noms de codec qui doivent être donnés après l'option +acodec, par exemple comme ceci: @@ -2383,12 +2384,12 @@ Un exemple avec compression AC3: Contrairement aux codecs vidéo de libavcodec, - ces codecs audio ne font pas un usage intelligents des bits qu'on leur donne - vu qu'ils ont des modèles psycho-accoustiques minimaux (quand ils en ont) - ce que la plupart des autres implémentations de codec comportent. - Cependant, notez que tous ces codecs audio sont très rapides et fonctionnent qu'importe - leur environnement à partir du moment où MEncoder a été - compilée avec libavcodec (ce qui est le + ses codecs audio ne font pas un usage avisé des bits qu'ils consomment + car ils leur manquent certains modèles psycho-acoustiques minimaux (quand ils en ont) + ce que la plupart des autres implémentations de codecs possèdent. + Cependant, notez que tous ces codecs audio sont très rapides et sont disponibles + à partir du moment où MEncoder a été + compilé avec libavcodec (ce qui est le cas la plupart du temps), et ne dépend pas de bibliothèques externes. @@ -2400,17 +2401,17 @@ Un exemple avec compression AC3: Idéalement, vous voudriez probablement juste dire à mencoder de passer en mode "haute qualité" et passer à autre chose. - Ce serait sûrement sympa, mais c'est malheureusement dur à faire vu que les - différentes options d'encodage donnent différents résultats de qualité + Ce serait sûrement sympa, mais c'est malheureusement difficile à implémenter car les + différentes options d'encodage donnent des résultats de qualité différents en fonction du matériel source. - Ceci vient du fait que la compression dépende des propriétés visuelles + Ceci vient du fait que la compression dépend des propriétés visuelles de la vidéo en question. Par exemple, un film d'animation et un film d'action ont des propriétés très différentes et nécessitent des options différentes pour obtenir un encodage optimal. - La bonne nouvelle, c'est que certaines options ne devraient jamais être mise à - part, comme , , et . - Voir ci-dessous pour une description détaillée des options d'encodage communes. + La bonne nouvelle, c'est que certaines options ne devraient jamais être omises, + comme , , et . + Voir ci-dessous pour une description détaillée des options d'encodage les plus communes. @@ -2419,49 +2420,48 @@ Un exemple avec compression AC3: vmax_b_frames: 1 ou 2 est bon selon le film. - Notez que si vous avez besoin d'avoir votre encodeur décodable par DivX5, vous - aurez besoin d'activer le support closed GOP, en utilisant l'option de + Notez que si vous avez besoin d'avoir votre encodage décodable par DivX5, vous + aurez besoin d'activer le support "closed GOP", en utilisant l'option de libavcodec, mais vous aurez besoin de désactiver la détection de scène, ce qui n'est pas une bonne idée étant donné que cela affectera un peu l'efficacité d'encodage. - vb_strategy=1: aide aux scènes avec de rapides - mouvements. - Sur certaines vidéos, vmax_b_frames peut affecter la qualité, mais - vmax_b_frames=2 avec vb_strategy=1 aideront. + vb_strategy=1: aide pour les scènes avec beaucoup de + mouvement. Sur certaines vidéos, l'option vmax_b_frames peut affecter la qualité, mais + utiliser vmax_b_frames=2 avec vb_strategy=1 aide. - dia: portée de recherche de mouvement. Le plus large - est l'écart; ce sera mieux, mais aussi plus lent. - Des valeurs négatives sont une échelle complètement différente. + dia: portée de de la passe de recherche de mouvement. + Plus la valeur de cette option est élevée, meilleure sera la qualité et plus l'encodage sera lent. + Les valeurs négatives représentent une échelle complètement différente. De bonnes valeurs sont -1 pour un encodage rapide, ou 2-4 pour un plus lent. - predia: pré-passe de recherche de mouvement. - Pas aussi important que dia. De bonnes valeurs sont 1 (par défaut) à 4. Cela - demande preme=2 pour être vraiment utile. + predia: portée de recherche de mouvement en pré-passe. + Pas aussi important que dia. De bonnes valeurs vont de 1 (par défaut) à 4. Cela + requière preme=2 pour être réellement utile. cmp, subcmp, precmp: Fonction de comparaison pour l'estimation de mouvement. - Testez avec des valeurs de 0 (défaut), 2 (hadamard), 3 (dct), et 6 (taux de + Testez avec les valeurs 0 (défaut), 2 (hadamard), 3 (dct), et 6 (taux de distorsion). 0 est le plus rapide, et suffisant pour precmp. Pour cmp et subcmp, 2 est bon pour les animations, et 3 est bon pour les - actions en direct. - 6 peut-être ou non un peu mieux, mais c'est lent. + films d'action. + 6 peut être (ou non) un peu meilleur, mais est lent. - last_pred: Nombre de prédicateurs de mouvement - à prendre depuis la frame précédente. - 1-3 (ou dans ces eaux) améliore la vitesse de l'encodage quasiment sans contrepartie. - De plus hautes valeurs ralentiront sans avoir de gain réel. + last_pred: Nombre de prédicteurs de mouvement + à prendre depuis l'image précédente. + 1-3 (ou dans ces eaux) améliore la qualité pratiquement sans perte en vitesse. + De plus hautes valeurs ralentiront l'encodage sans réel gain. @@ -2471,82 +2471,76 @@ Un exemple avec compression AC3: qprd: quantification adaptative basée sur la - complexité du macrobloc. - Peut aider ou aggraver la situation ceci dépend de la vidéo et des autres options. - Cela peut causer des artefacts à moins que vous ne paramétriez vqmax à certaines + complexité des macroblocs. + Peut aider ou gêner selon la vidéo et les autres options. + Cela peut causer des artefacts à moins que vous ne paramétriez vqmax à des valeurs raisonnablement petites (6 c'est bien, voire peut-être 4); vqmin=1 devrait aussi aider. qns: très lente, spécialement quand combinée - avec qprd. - Cette option dira l'encodeur à minimiser le bruit dû à la compression - d'artefact au lieu de faire strictement ressembler la vidéo encodée à la - source. - N'utilisez pas ceci à moins d'avoir déjà bidouillé tout ce qui est possible - et que les résultats ne sont pas encore assez bons. + avec qprd. Avec cette option, l'encodeur minimise le bruit dû aux artefacts de compression + au lieu de faire correspondre strictement la vidéo encodée à la source. + Ne l'utilisez pas à moins d'avoir déjà peaufiné tout le reste et que les + résultats ne soient pas encore assez bons. - vqcomp: Bidouille du contrôle de taux. - Quelles sont les bonnes valeurs qui dépendent du film? - Vous pouvez de manière sûre laisser cela de côté si vous voulez. + vqcomp: mise au point du contrôle de débit. + La nature du film définiera quelles sont les bonnes valeurs à appliquer + Vous pouvez sans problème laisser cette option de côté si vous voulez. Réduire vqcomp met plus de bits sur les scènes de basse complexité, l'augmenter - les met sur les scènes de haute complexité (défaut: 0.5, portée: 0-1. portée - recommandée: 0.5-0.7). + les met sur les scènes de haute complexité (défaut: 0.5, portée: 0-1. recommandé: 0.5-0.7). - vlelim, vcelim: Paramètre le seuil du seul - coefficient d'élimination pour les plans de luminance et de chroma. - Ceux-là sont encodés séparément dans tous les algorithmes de style MPEG. - L'idée derrière tout ceci est d'utiliser certaines bonnes heuristiques + vlelim, vcelim: Définit le coefficient du seuil d'élimination pour + la luminance et les plans de chrominance. + Ils sont encodés séparément dans tous les algorithmes de style MPEG. + L'idée derrière tout ceci est d'utiliser de bonnes heuristiques pour déterminer quand le changement dans un bloc est inférieur au seuil que vous avez spécifié, et dans ce cas, de simplement encoder le bloc comme étant "sans changement". - Cela économisera des bits et accélérera peut-être l'encodage. vlelim=-4 et - vcelim=9 semblent être de bonnes valeurs pour les films en direct, mais - semblent ne pas aider avec les animations; quand vous voudrez encoder une animation, - vous devrez probablement les laisser inchangés. + Cela économise des bits et accélére peut-être l'encodage. vlelim=-4 et + vcelim=9 semblent être de bonnes valeurs pour les films de "scènes réelles", mais + semblent ne pas aider avec les films d'animation; quand vous voudrez encoder une animation, + vous devriez probablement les laisser tel quel. qpel: Estimation de mouvement de quart de pixel. - MPEG-4 utilise la précision de moitié de pixel pour sa recherche de mouvement - par défaut, donc cette option vient avec un surplus car plus d'information seront - stockées dans le fichier encodé. - La compression gain/perte dépend du film, mais n'est habituellement pas très - efficace sur les animations. - qpel induit toujours un surcoût significatif dans le temps de décodage du CPU - (+25% en pratique). + MPEG-4 utilise une précision d'un demi pixel pour sa recherche de mouvement + par défaut, donc cette option augmente la quantité d'information qui est + stockée dans le fichier encodé. Le gain ou la perte en terme de compression + dépend du film, mais ce n'est habituellement pas très efficace pour les animations. + qpel induit toujours un surcoût significatif en temps de décodage (+25% en pratique). - psnr: n'affecte pas l'encodage courant, - mais écrit un fichier journal donnant le type/taille/qualité de chaque frame, et - imprime un résumé du PSNR (rapport maximal du signal sur le bruit) à la fin. + psnr: n'affecte pas l'encodage + mais écrit un fichier journal donnant le type/taille/qualité de chaque image, et + imprime un résumé du PSNR (rapport signal sur bruit) à la fin. -Options à éviter: +Options qu'il n'est pas recommandé de changer: - vme: La valeur par défaut est la mieux. + vme: La valeur par défaut est la meilleure. lumi_mask, dark_mask: Quantification adaptative - pyscho-visuelle. - Vous ne voulez pas jouer avec ces options si vous tenez à la qualité. - Des valeurs raisonnables peuvent être efficaces dans votre cas, mais soyez prévenu - que ceci reste très subjectif. + pyscho-visuelle. Vous ne voulez pas jouer avec ces options si vous tenez à la qualité. + Des valeurs raisonnables peuvent être efficaces dans votre cas, mais soyez prévenu, + ceci reste très subjectif. - scplx_mask: Essaie d'éviter l'apparition d'artefacts - carrés, mais le post-traitement est le mieux. + scplx_mask: Essaie d'empêcher l'apparition d'artefacts + dûs aux blocs, mais le post-traitement est plus efficace. -- cgit v1.2.3