Mise à jour : si vous utilisez HandBrake 0.9.9 et que vous préférez utiliser les nouveaux « x264 Presets », j’ai un guide mis à jour pour HandBrake 0.9.9 qui se concentre sur cela dans la section encodage de ce site. Cependant, si vous vous en tenez aux « Advanced Settings » ou si vous voulez des informations plus approfondies sur les Audio Settings, Picture Settings, etc (que je n’ai pas répété dans le nouveau guide), continuez à lire….
Les anciens meilleurs réglages H.264 / x264 pour HandBrake n’étaient pas très complets, et sont devenus obsolètes. Je vais essayer ici de faire un tour d’horizon plus complet des réglages pour vous aider à obtenir les meilleurs réglages x264 / Handbrake possibles pour votre encodage. Attention : la précédente version était courte. Celle-ci est incroyablement longue et détaillée. Si vous êtes débordé (ne vous sentez pas mal, il y a beaucoup à comprendre), débrouillez-vous du mieux que vous pouvez dans Handbrake et utilisez-le comme référence lorsque vous arrivez à une option dont vous n’êtes pas sûr.
L’objectif est d’obtenir la meilleure qualité possible en utilisant x264 avec Handbrake, même si le codage prend beaucoup de temps (ce qui est raisonnable sur un processeur moderne, en tout cas).
Que le ciel vous aide si vous utilisez une vieille Athlon…
Je vais commencer par les paramètres avancés et je vais travailler à l’envers.
Paramètres avancés
Cadres de référence : maximum possible
Cela va jusqu’à 16. Malheureusement, 16 cassera la lecture sur de nombreux appareils (et peut-être sur certains lecteurs logiciels). Donc si vous utilisez par exemple… un iPad3, WDTV, Roku, AppleTV3, etc, vous allez devoir trouver le maximum pour ce lecteur. Le plus simple est de voir quel « Profil » votre appareil prend en charge.
Je vais utiliser un exemple. L’iPad3. La page des spécifications indique « Profil niveau 4.1 » dans la section « TV et vidéo » (pour l’instant en tout cas – cette page pourrait changer à chaque fois que l’iPad4 sortira). Nous ne voulons donc pas aller plus haut que le « niveau 4.1 » si nous voulons que la vidéo soit lue sur l’iPad3.
Ensuite, nous emmenons ce « niveau 4.1 » sur la page MPEG4 de Wikipedia où nous verrons un tas de choses cryptées dans la partie « niveau 4.1 ». En ce qui concerne les cadres de référence, nous devons examiner ce qui suit dans la dernière colonne :
1280×720@68.3 (9)
1920×1080@30.1 (4)
2048×1024@30.0 (4)
Les éléments entre parenthèses (nombre maximum de cadres stockés) signifient cadres de référence.Un DVD typique tient dans les limites de 1280×720 et peut utiliser jusqu’à 9 cadres de référence*.
Pour un BluRay 1080p, jusqu’à 4 images de référence.
Si nous dépassons ce nombre, l’iPad 3 (utilisant le niveau 4.1) risque de s’étouffer en essayant de le lire.
*Pour des raisons de simplicité, je suis prudent ici en mentionnant 9 images de référence pour un DVD. Si vous regardez un niveau inférieur comme le niveau 3.1, vous remarquerez qu’il indique en fait la résolution d’un DVD de 720×480, et qu’il traite 13 images de référence. Vous pourriez donc être en mesure de pousser 13 trames de référence (ou plus) au niveau 4.1 sur un DVD. Il suffit de dire qu’il peut être très difficile de trouver le nombre maximum d’images de référence à votre résolution et à votre fréquence d’images – la page wikipedia ne donne que quelques exemples pour chaque niveau. Si vous êtes très soucieux de trouver le nombre maximum d’images de référence pour votre source, vous pouvez essayer de faire un calcul mathématique ou simplement faire des essais et des erreurs.
Regardez donc les caractéristiques de votre appareil pour trouver le « niveau de profil » et faites-le correspondre avec le lien Wikipédia ci-dessus pour trouver les cadres de référence maximums que vous pouvez utiliser. N’oubliez pas que cela dépend de la résolution et, comme nous l’avons vu dans l’exemple ci-dessus, un DVD peut s’en tirer avec 9 images de référence sur l’iPad 3, tandis qu’un BluRay ne peut s’en tirer qu’avec 4 images de référence.
Si vous ne faites que lire votre contenu sur un ordinateur décent (via VLC par exemple), n’hésitez pas à le faire monter jusqu’à 16. N’oubliez pas qu’il ne pourra probablement pas être lu sur de nombreux appareils matériels actuels (voire aucun). Et un HTPC très lent pourrait même s’étouffer.
Notez que des valeurs élevées prendront sensiblement plus de temps à encoder, même sur une machine rapide. Si le 16 vous fait prendre beaucoup trop de temps pour encoder, n’hésitez pas à passer à quelque chose comme 8 (la valeur par défaut pour le préréglage « plus lent » en x264).
Nombre maximal d’images B : 16
16 est considéré comme un paramètre « placebo » en x264. Cela dit, cela n’ajoute pas une quantité de temps ridicule au codage.
Cela indique simplement à l’encodeur combien de bframes consécutives il peut utiliser. Il y a de fortes chances que l’encodeur ne trouve pas de situation où il serait logique d’utiliser 16 images consécutives. Si vos temps d’encodage sont vraiment mauvais, 8 pourrait être plus raisonnable.
Encodage d’entropie CABAC, transformation 8×8, images P pondérées : oui (coché)
Ils sont tous différents, mais à peu près tout ce qui est relativement récent les soutient. Si vous essayez de lire la vidéo sur un appareil très ancien ou très faible (où beaucoup d’autres paramètres que j’énumère seront probablement problématiques aussi), vous devrez peut-être les désactiver.
CABAC utilise simplement une meilleure compression pour certaines données dans le code.
8×8 Tranform permet à l’encodeur de faire une autre chose technique astucieuse avec les i-frames.
Les P-frames pondérées ont tendance à améliorer la compression lors des fades.
B-frames pyramidales : Par défaut (Normal)
Si vous créez un véritable disque BluRay à partir de votre encodage, utilisez « Strict ». Sinon, la plupart des appareils récents le prennent en charge (si vous utilisez quelque chose de vieux ou de faible, vous devrez peut-être le désactiver).
Les B-Frames sont géniales. Cela les rend encore meilleures. Cela permet d’utiliser les B-Frames comme références pour d’autres cadres (comme d’autres B-Frames !).
B-Frames adaptatifs : Optimal
Nous visons à injecter autant de qualité dans un fichier, alors réglez sur Optimal.
D’après ce que j’ai compris, si vous réglez ce paramètre sur « aucun », les B-Frames seraient mis dans un ordre simpliste « à l’emporte-pièce », ce qui n’est probablement pas idéal. Les deux options « rapide » et « optimal » permettent au codeur de les utiliser de manière efficace, l’option « optimal » faisant un meilleur travail.
Mode direct adaptatif : Auto
Cela concerne la « prédiction des vecteurs de mouvement ». Je suppose que le spatial regarde les images individuelles tandis que le temporel regarde les images multiples. Le spatial est censé être le plus utile, mais comme ce n’est pas *toujours* le cas, l’utilisation de l’Auto est la meilleure façon de procéder pour que le codeur puisse utiliser ce qui est le plus utile.
Méthode d’estimation du mouvement : Multi-Hexagone inégal (umh)
L’UMH est le plus haut que l’on puisse atteindre sans se heurter à des temps de codage déments.
L’encodeur utilise certains modèles d’estimation de mouvement (faites une recherche sur Google si vous voulez savoir à quoi ils ressemblent). Si vous allez au-delà de cette limite et que vous choisissez l’exhaustivité (ou la transformation en exhaustivité – ce qui est considéré comme le réglage « placebo »), cela devient une sorte de recherche stupide par la force brute.
Si vous avez l’intention de passer à l’exhaustif ou à l’exhaustif transformé, votre encodage, même sur une machine rapide, peut prendre des jours, alors demandez-vous si cela vaut vraiment la peine pour l’effet « placebo ».
Sous-pixel ME & Mode Décision : 10 QPRD dans toutes les images
Il suffit de dire que plus c’est haut, mieux c’est, mais 11 prendrait un peu plus de temps et est considéré comme un « placebo ».
Fourchette d’estimation du mouvement : 24-64
Bien que 64 soit considéré comme bien au-delà même du paramètre « placebo », mes encodages de DVD ont eu des temps de codage assez raisonnables (moins d’une heure pour un épisode de 44 minutes), ce qui est la seule raison pour laquelle je les ai laissés aussi élevés. En revanche, les encodages BluRay…. approchent la majeure partie de la journée avec un réglage de 64.
Il est probablement plus judicieux de choisir un réglage de 16 à 24.
C’est la plage maximale en pixels que le codeur recherchera pour le mouvement. Des réglages plus élevés devraient être plus utiles à des résolutions plus élevées (puisqu’une main qui se déplace sur un BluRay parcourt plus de pixels qu’une main qui se déplace sur un DVD, même si elle parcourt la même distance sur votre écran). Il est évident qu’une vidéo à haute résolution aura tendance à être plus sensible à ce réglage qu’une vidéo à basse résolution.
Type de partition : Tous
Si je comprends bien, le paramètre « most » (par défaut) active 4 types de partitions primaires, et « all » active une 5ème, qui est censée avoir une utilité négligeable et ralentit le codage. Le paramètre « some » n’active que les 2 plus critiques/bénéfiques.
Si vous utilisez un processeur moderne 2011/2012, je serais enclin à le régler sur « all ». Je n’ai moi-même pas remarqué d’effets négatifs sur les temps d’encodage (et j’ai utilisé « all » il y a 3 ans sur des systèmes plus anciens également), donc si cela peut aider parfois, autant le garder.
Treillis: Toujours
Il est requis par le réglage de 10 du sous-pixel ME & Mode Decision qui a été utilisé précédemment. Si vous effectuez des encodages à deux passes et que vous trouvez que le premier est terriblement lent, vous pouvez envisager de le régler sur « Encode Only ».
Déblocage :
-1, -1 pour les films (tv/movies) et l’animation 3d (Pixar stuff)
1, 1 pour l’animation (Bambi, etc.)
-2, -2 pour des niveaux élevés de grains de film
Notez que si vous essayez de régler pour conserver le film/grain, vous devez lire les autres réglages manuels sur http://forum.handbrake.fr/viewtopic.php?f=6&t=19426
Les indications ci-dessus sont typiques des réglages de « tune » de x264. Il n’est pas surprenant que cette fonction soit conçue pour réduire le « blocage » de votre vidéo finale. Cependant, cela se fait au détriment du « lissage » de l’image globale.
En général, suivez les suggestions ci-dessus. Si vous voyez un « blocage » dans votre vidéo qui n’existait pas dans la source, il vaut mieux augmenter le réglage RF (ou le débit binaire moyen) d’abord et/ou jouer avec les réglages AQ/Trellis que je mentionne ensuite.
Force de quantification adaptative : (curseur)
1.0 (par défaut) pour la télévision/le cinéma et l’animation 3d (Pixar stuff)
0,6 pour l’animation (Mikey Mouse, Bambi, etc.)
0,5 pour des niveaux élevés de grain de film (vous aurez besoin d’un bitrate élevé ou d’un réglage de qualité)
Il s’agit de valeurs par défaut « tune » x264 et ce sont de bonnes lignes directrices. La façon la plus simple d’expliquer cela est que des valeurs plus élevées ont tendance à enlever quelques bits aux zones très détaillées et à les placer dans des zones moins détaillées (plus plates). J’ai vu que cela s’expliquait par la différence entre ringing (haute qualité d’image) et banding (faible qualité d’image), même si cela dépend de la source.
D’après mes tests, il ne semble pas avoir beaucoup d’impact visuel pour les codages de films à faible débit, bien qu’il puisse affecter la taille du fichier. A moins que vous ne soyez prêt à faire vos propres tests/ recherches, je vous recommande d’utiliser les paramètres recommandés pour une « taille unique ».
Distorsion de taux psychovisuels : (curseur)
1.0 (par défaut) pour la télévision/le cinéma et l’animation 3d (Pixar Stuff)
0,4 pour l’animation (Mikey Mouse, Bambi, etc.)
Encore une fois, x264 « tune » par défaut, et de bonnes directives. Ce réglage présente des similitudes avec le réglage « AQ » ci-dessus en ce sens qu’il se déplace sur des bits. Les valeurs plus élevées tentent de maintenir le « détail » tel que vous le verriez sur la scène, au détriment de la qualité globale.
Treillis psychovisuel : (curseur)
0,15 pour la télévision/le cinéma et l’animation 3d (Pixar Stuff)
0 (par défaut) pour l’animation (Mikey Mouse, Bambi, etc)
0,25 pour des niveaux élevés de grains de film
Attaché dans le cadre du Trellis ci-dessus. Les valeurs par défaut sont de bonnes lignes directrices.
Autres bonnes choses :
Il existe une multitude de paramètres personnalisés que vous pouvez ajouter dans la zone de texte, mais vous devrez peut-être faire une petite recherche.
Il se peut que vous deviez en modifier certains légèrement pour les adapter à Handbrake. Les paramètres dans la zone de texte ont tendance à être au format settinga=1:settingb=5:settingc=32:etc avec deux points ( :) séparant les paramètres. En jetant un coup d’œil à la zone de texte dans HandBrake, vous pouvez probablement comprendre le format.
rc-lookahead – Si vous cliquez sur le préréglage « High Profile » dans HandBrake, vous verrez apparaître cette fenêtre dans la zone de texte (il n’y a pas de boîte d’option ou de curseur). Il existe quelques systèmes dans l’encodeur qui utilisent cette fonction, et plus c’est haut, mieux c’est (max. 250). Cela dit, rc-lookahead=60 est à peu près le maximum recommandé (même le paramètre « placebo » ne va pas plus haut).
Quelques raisons à cela… Premièrement, il engloutit de la RAM. Si vous avez plus de 8 Go de RAM et que vous souhaitez que HandBrake en utilise plus, c’est la solution qu’il vous faut. De même, si vous êtes sur un système 32 bits ou si vous avez 2 ou 4 Go de RAM, j’imagine qu’en augmentant trop la mémoire, vous risquez de faire planter l’encodeur.
La raison suivante est que les valeurs énormes n’ont pas vraiment d’avantage – les grandes valeurs prennent un peu plus de temps pour l’encodage, et la taille / qualité du fichier ne semble pas changer. J’ai tendance à le régler à environ 120, mais je ne peux pas dire que j’ai remarqué un quelconque avantage.
nr – ce n’est pas touché/référencé par HandBrake, mais vous pouvez l’utiliser en ajoutant manuellement nr=100 dans la zone de texte. C’est un débruiteur intégré à x264. La bonne nouvelle, c’est qu’il est intégré, compensé en mouvement, qu’il a peu d’effets secondaires négatifs, qu’il réduit légèrement la taille de vos fichiers et qu’il est rapide. La mauvaise nouvelle est que ce n’est pas terriblement bon (les développeurs x264 sont ouverts à ce sujet) – d’après ce que j’ai compris, ils l’ont ajouté uniquement parce qu’ils avaient déjà des données à compensation de mouvement dans l’encodeur, donc c’était facile à mettre en place.
J’ai utilisé nr=100 et des valeurs allant jusqu’à nr=1000 dans un code avec une source très bruyante/grenue. Il n’y avait pas de différence importante entre 100 et 1000 (bien que la qualité n’ait pas vraiment souffert non plus, et la taille des fichiers a diminué).
Il est surprenant de constater que le dé-bruitage du Handbrake ne pose pas de problème, car il y a du bruit à la source pendant le mouvement. Vous voyez, le débruitage inclus dans handBrake (hqdn3d) est bon pour le débruitage temporel pendant les scènes statiques, mais plutôt mauvais pour le débruitage pendant le mouvement – normalement vous finissez par devoir augmenter le débruitage spatial pour nettoyer cela, mais à un coût énorme pour votre image.
Cependant, le débruiteur x264 fonctionne bien lorsqu’il capte le bruit pendant le mouvement, ce qui complète assez bien le débruiteur hqdn3d de HandBrake. J’imagine qu’il est encore pâle par rapport à d’autres débruiteurs à compensation de mouvement, mais c’est mieux que rien, et comme je l’ai dit, il ne semble pas nuire beaucoup au reste de l’image (si tant est qu’il le fasse… Je ne pourrais vraiment pas le dire – il faudrait que je l’essaie sur une source propre pour voir si je remarque quelque chose).
Il y a un certain nombre d’autres réglages x264 que vous pouvez aussi brancher manuellement sur HandBrake, mais les 2 ci-dessus sont les seuls avec lesquels j’ai joué.
Chapitres :
Par défaut, si vous chargez une source qui comprend des chapitres, ceux-ci seront inclus ici, souvent nommés Chapitre 1, Chapitre 2, etc. Pas très descriptif.
Ici, vous pouvez éditer les noms des chapitres.
Dans les émissions de télévision et les films sur DVD/BluRay, certains comportent une fonction de « sélection de scène » dans le menu qui énumère tous les noms de scènes et vous permet de sauter à une scène (qui est en fait le saut à un chapitre). Si vous le souhaitez, vous pouvez saisir manuellement ces noms de chapitre dans HandBrake. Il est également possible d’importer un CSV avec les noms de chapitres si vous en obtenez un.
Cependant, HandBrake ne permet pas d’éditer autre chose que les noms. Donc si votre vidéo n’a pas de chapitres (ou si vous voulez en ajouter/supprimer), vous devez utiliser un autre programme pour le faire.
Cela dit, dans la partie supérieure de HandBrake, vous pouvez choisir les chapitres à encoder. Parfois, sur un DVD/BluRay, le dernier chapitre sera celui où le générique commence. Si vous ne voulez pas encoder le générique, vérifiez le DVD/BluRay dans un lecteur vidéo (passez au dernier chapitre), et si c’est tout le générique, n’hésitez pas à le laisser en dehors de votre encodage.
Notez que les crédits ne prennent pas un *lot* de bitrate, mais dans le cas d’un encodage comme celui du « Seigneur des Anneaux », ils prennent beaucoup de temps (et les couper peut permettre d’économiser une bonne partie de la taille du fichier). Dans d’autres cas, les couper est tout simplement pratique – je ne suis pas fan de voir des crédits constants quand je regarde 2 ou 3 épisodes d’une même série.
Sous-titres :
Si HandBrake a trouvé des pistes de sous-titres dans votre source, vous pouvez les ajouter ici (autant que vous le souhaitez). La sélection « par défaut » en fera la piste par défaut qui sera lue lorsque la vidéo le sera (s’il n’y a pas de défaut, aucune ne sera lue automatiquement à moins que vous ne les allumiez).
Cependant, tous les appareils ne liront pas les pistes de sous-titres. Cela peut être particulièrement frustrant lorsque vous avez des sous-titres « audio étrangers » ou « forcés ». Par exemple, lorsque Jabba le Hutt parle dans Star Wars ou que quelqu’un parle russe dans une émission de télévision. Dans ces cas-là, vous pouvez « graver » une piste pour qu’elle fasse partie de l’image.
Mais comment savoir quelle piste est sous-titrée en « audio étranger » ? HandBrake vous facilite la tâche : sélectionnez « Recherche audio étrangère » avec « Forced Only » et « Burned In ». Cela vous permettra de rechercher les pistes de sous-titres pour tout ce qui joue 10 % ou moins du temps (ce qui est généralement le cas des sous-titres forcés). S’il trouve un élément répondant à ce critère, il le gravera directement dans l’image pour qu’il soit toujours présent, quel que soit l’appareil sur lequel il joue. Le seul inconvénient est que si vous ajoutez aussi des sous-titres réguliers, ils se chevaucheront pendant la lecture de la vidéo. Donc si vous gravez dans des « sous-titres forcés », vous pouvez envisager d’en laisser d’autres de côté.
L’avantage de la « recherche d’audio étranger » est que si vous n’êtes pas sûr que votre vidéo comporte une ou deux scènes avec de l’audio étranger, vous pouvez l’activer quand même – s’il y en avait, Handbrake le trouvera. S’il n’y en avait pas, rien ne sera ajouté.
Notez que dans certaines sources, les sous-titres sont déjà gravés sur l’image. Un bon exemple est le BluRay de la région des États-Unis pour Le Seigneur des Anneaux (édition étendue). Ne paniquez donc pas si vous ne voyez pas une piste de sous-titres séparée dans votre vidéo… elle est peut-être déjà gravée.
Audio :
HandBrake répertorie les pistes audio de votre source et ajoute automatiquement celle qu’il croit être la principale (généralement en anglais avec le plus de canaux). Vous pouvez ajouter d’autres pistes si vous le souhaitez – il y aura souvent une sorte de Main 5.1ch, un canal Main 2.0, peut-être quelques 2 canaux avec le commentaire du réalisateur, d’autres langues, etc.
En ce qui concerne le codec audio, la plupart des appareils lisent soit l’AAC, soit le MP3. Pour le codec audio, la plupart des appareils lisent soit l’AAC soit le MP3. L’AAC est généralement considéré comme de qualité supérieure de nos jours, bien que la plupart des gens ne remarquent pas la différence.
Pour l’AAC, le codec « CoreAudio AAC » est généralement considéré comme le meilleur. Cependant, il est limité à ceux qui sont encodés sur Mac (il peut cependant être utilisé sur tout ce qui supporte l’AAC, y compris les machines Windows). Si vous êtes bloqué sur Windows, le « faac AAC » est la meilleure option, à moins que vous ne souhaitiez utiliser quelque chose comme MeGUI au lieu de HandBrake (qui supporte un encodeur Nero AAC qui est considéré comme aussi bon que le CoreAudio)
Dolby Pro Logic II est une option de mixage courante – il peut être utilisé sur n’importe quel système à deux canaux, et peut être « simulé » si vous l’utilisez, par exemple, sur un système de cinéma maison à plusieurs canaux, mais vous pouvez lire plus loin les détails de « passage » que vous préférez.
Échantillon – vous pouvez généralement le laisser à « Auto ». Si vous avez une raison de spécifier quelque chose de spécifique (comme 44.1), allez-y, mais notez qu’en le réglant manuellement, vous risquez que le son à faible échantillonnage soit inutilement suréchantillonné, et vice-versa.
Le bitrate – 160 est courant. 128 est souvent considéré comme trop faible (un certain nombre de personnes peuvent faire la différence entre 128 et 160). Vous pouvez pousser plus haut, mais certains appareils ne sont pas classés pour cela. Il est très difficile de distinguer les débits supérieurs à 160, et incroyablement difficile de distinguer tout ce qui est supérieur à 192. Notez que si vous ajoutez des pistes « commentaires », il peut être judicieux de diminuer le débit de celles-ci simplement pour ne pas perdre de place – la qualité de la conversation entre deux personnes n’est pas aussi importante que celle de la piste principale du film, de toute façon, vous n’avez pas besoin d’un débit élevé pour obtenir une bonne qualité de voix simple, et souvent, elles ne sont pas écoutées fréquemment.
Il existe également des options « Passthru », qui sont un peu plus risquées à utiliser car leur utilisation dépend de la prise en charge de l’appareil. Par exemple, vous pouvez passer par AC3, ou DTS, mais si votre lecteur ne le prend pas en charge, vous risquez de ne pas avoir de chance. De plus, ces derniers ne compressent pas le flux audio, donc le passage est une très mauvaise idée si vous visez un encodage de faible taille. Cependant, si vous diffusez votre contenu de manière intensive via un système de cinéma maison 5.1, le passage peut être votre meilleure option.
Vidéo :
Pour le codec, x264 (j’espère que vous n’avez pas lu jusqu’ici sans vous y engager !)
Pour le framerate, « Same As Source » (Framerate variable) est généralement le meilleur, à moins que vous n’ayez une très bonne raison de cibler un taux spécifique. Ce taux est doublé si vous faites quelque chose comme la détélection de la source. Vraiment, « same as source » est génial. Régler quelque chose manuellement risque de créer des problèmes.
Qualité constante ou débit moyen – Les deux fonctionnent de la même manière. Ils font tous deux varier le débit binaire tout au long du codage – en utilisant plus de bits lorsque c’est nécessaire, et moins de bits lorsque ce n’est pas nécessaire.
La différence est que la qualité constante vise un certain niveau de qualité alors que le débit moyen vise essentiellement une taille de fichier.
Notez que les améliorations de type « compression » dans les paramètres avancés ont tendance à les affecter de différentes manières. Avec la qualité constante, les paramètres plus élevés (comme le passage de 1 à 5 cadres de référence) auront tendance à maintenir le niveau de qualité que vous avez défini, mais à diminuer la taille du fichier. Avec un débit moyen, une amélioration (comme le passage de 1 à 5 trames de référence) aura tendance à maintenir la taille du fichier que vous avez choisi, mais à en augmenter la qualité.
Un bon exemple d’un avantage de la CQ est le cas si vous encodez une série télévisée en qualité constante. L’Episode 10 sera aussi bon que l’Episode 1, même si l’Episode 10 a eu un zillion d’explosions, beaucoup de mouvements, etc. Bien sûr, l’Episode 10 pourrait être un peu plus long, mais l’Episode 15, qui a fait parler les gens pendant la majeure partie de l’épisode, était probablement un peu plus court.
D’un autre côté, si vous aviez utilisé un bitrate moyen, les épisodes 1, 10 et 15 auraient probablement la même taille de fichier. L’épisode 1 peut sembler bon, mais l’épisode 10 peut sembler terrible. L’épisode 15 pourrait avoir la même apparence que l’épisode 1, mais il pourrait être plus volumineux qu’il ne l’aurait été si vous aviez utilisé la qualité constante à la place.
En réalité, le seul avantage tangible du bitrate moyen est que vous visez une taille de fichier spécifique. Si vous avez absolument besoin que toutes vos émissions soient à 350mb pour pouvoir en mettre 2 par CD, sortir une calculatrice et calculer le Bitrate moyen est la seule façon de pouvoir le faire facilement. Et comme le débit moyen nécessite deux passages pour être le plus performant (puisqu’il doit déterminer comment exactement il doit emballer tous les bits de manière optimale dans la bouteille de la taille du fichier), vous passez également plus de temps pendant l’encodage – si vous aviez opté pour la qualité constante (qui ne nécessite pas de deuxième passage), vous auriez gagné du temps – du temps que vous auriez pu consacrer à un réglage avancé de qualité supérieure, si ce n’est plus.
La qualité constante semble plus déroutante à première vue. Vous avez un réglage RF, et si vous êtes nouveau dans ce domaine, vous n’avez probablement aucune idée de ce que cela signifie. Pour commencer, des réglages plus faibles signifient ici une qualité plus élevée. RF:16 sera de bien meilleure qualité (et de plus grande taille) que RF:24 par exemple.
En règle générale, RF:20 est un point de départ commun pour les encodages de DVD et RF:22 pour les encodages de BluRay. Si vous êtes très pointilleux sur la qualité, 16-18 pour un DVD pourrait être plus idéal (ou même des chiffres inférieurs si vous êtes déterminé à le rendre indiscernable). D’un autre côté, si vous recherchez des fichiers de très petite taille et que vous êtes prêt à accepter que la qualité ne soit pas aussi bonne que celle de la source, 22-25 peut fonctionner pour les DVD.
Après quelques encodages en qualité constante, vous devriez avoir une bonne idée du réglage que vous préférez, que vous recherchiez une qualité élevée ou des fichiers de petite taille.
Si vous avez besoin d’un bitrate moyen, choisissez le mode 2-pass. Le codeur a vraiment besoin de ce premier passage pour savoir quelles scènes sont complexes (et nécessiteront plus de bits), et quelles scènes sont simples (et nécessiteront moins de bits) avant de commencer à allouer les choses.
Pensez-y de cette façon. Si vous organisez une fête et que vous avez 350 Mo de pizza à distribuer (je sais que la pizza ne se mesure pas en Mo – écoutez-moi bien), il est bon de savoir combien de personnes arrivent à l’avance, et idéalement combien sont des enfants (petits mangeurs) et combien sont des adultes (gros mangeurs). Le système à deux passages est comme ça : il fait des recherches au préalable (lors du premier passage) pour pouvoir couper la pizza correctement afin que tout le monde soit nourri (lors du deuxième passage). Sans ces recherches, vous risquez de commencer à distribuer trop de portions au début et d’en manquer lorsque les adultes arriveront plus tard.
D’accord, ce n’est pas la meilleure analogie (meilleure que celle du « lait » que j’allais utiliser, mais vous avez compris. Le 2-pass est bon si vous optez pour le Average Bitrate. Si le temps d’encodage est un problème, vous pouvez utiliser « Turbo first pass » – il fait moins de recherches approfondies au préalable, mais c’est quand même mieux que rien.
Filtres vidéo
(Recommandé)
Dételecine : Par défaut
Décomposition : Par défaut
Désentrelacement : Off
Deniose : dépend
Déblocage : Désactivé (généralement)
HandBrake est magnifique dans cette région.
Tant pour Detelecine que pour Decomb, HandBrake recherche par défaut les contenus télécinés et entrelacés, puis détélecine et désentrelace si nécessaire (et seulement SI il détecte ces choses). Cela signifie que vous pouvez régler et oublier. Si vous avez un problème vraiment bizarre avec un encodage, vous pouvez aller les activer manuellement, mais 99% du temps, ce n’est pas nécessaire. Réglez-les par défaut et laissez HandBrake déterminer s’ils sont nécessaires.
Denoise…. La version courte est la suivante Si vous avez du bruit (ou du grain de film) dans votre SOURCE dont vous voulez vous débarrasser, commencez par le réglage « Faible ». Cela « lissera » un peu votre image, mais réduira au moins le bruit/film. Si « Faible » n’est pas suffisant, je vous conseille vivement de lire le texte et d’utiliser des réglages personnalisés car « Moyen » et « Fort » ont tendance à trop adoucir l’image, ce qui fait ressembler les gens à des poupées Ken & Barbie.
Il est à noter que le dénivellement, en adoucissant les détails, réduit également la taille des fichiers (ou augmente la qualité) de votre encodage. Si vous êtes d’accord avec les résultats du filtre « Faible », c’est une bonne astuce pour réduire la taille du fichier de votre encodage de manière substantielle. Cependant, vous risquez de lisser ou de banderoler votre code, alors ne soyez pas trop zélé.
Deblock…. est censé supprimer le « blocage » qui existe dans votre SOURCE. Il lisse vraiment la vidéo au point qu’elle cause probablement plus de dégâts qu’elle n’en répare (je ne le supporte pas). Si votre source présente un blocage important pour une raison quelconque, il peut être intéressant de l’utiliser.
Notez que le débloqueur de HandBrake a un effet similaire à celui des réglages de bruit élevé. Parce qu’il lisse de manière drastique, il a tendance à détruire le grain et les autres bruits. Cela signifie que vous pourriez l’utiliser efficacement comme un débloqueur. Dans certains cas, il fera un meilleur travail de débruitage que le débruitoir.
Photo
Je suppose que vous n’essayez pas de redimensionner la vidéo (si c’est le cas, je suis sûr que vous êtes capable de trouver comment).
L’anamorphoseur est presque toujours utilisé, car il agit comme le ferait un DVD et fonctionne bien avec les lecteurs de logiciels informatiques et divers appareils. Pour en savoir plus sur ce que cela signifie, la meilleure façon de procéder est probablement de consulter le site HandBrake.
Auparavant, on recommandait l’utilisation de l’Anamorphic LOOSE, car il rend tout divisible par 16 pour le codeur. Cependant, d’après ce que j’ai compris, le codeur s’est amélioré, et Anamorphic STRICT est généralement la meilleure façon de procéder maintenant (puisque loose pourrait faire un léger redimensionnement, ce que nous ne voulons généralement pas).
Recadrage – Automatique est généralement bien. HandBrake recherche (et coupe) les barres noires dans la source. Presque tous les lecteurs ajouteront leurs propres barres noires (puisque la vidéo est réglée sur Anamorphique), donc l’encodage est inutile.
Vous pouvez bien sûr les définir manuellement si vous avez une bonne raison de le faire.
—
Eh bien, c’est tout. Le tout sur une seule (très longue) page, de sorte que vous n’êtes pas exposé à un zillion de publicités dans un article de plusieurs pages.
Je devrais terminer en notant que tout ceci n’est peut-être pas correct à 100%. J’ai recueilli les informations auprès du plus grand nombre de sources possible, mais il y a de fortes chances que j’aie lu quelque chose que je n’aurais pas dû prendre au pied de la lettre.
Alors prenez-le avec un grain de sel, et faites vos propres tests avant de passer une semaine à encoder une série télévisée pour découvrir que tout s’est horriblement mal passé parce que j’ai fait une erreur quelque part :p
Bonne chance !
Mais j'ai forcé des sous-titres dans Star Wars III pour obtenir un discours extraterrestre à travers
Cependant, il a également brûlé dans le nom des réalisateurs en haut de l'écran chaque fois que quelqu'un de nouveau dans le Directors Cut a parlé
L'audio ne contenait pas le commentaire, car je ne le voulais pas, mais j'ai maintenant une copie avec les noms des directeurs qui arrivent toutes les deux minutes environ
Un moyen d'obtenir les sous-titres extraterrestres que je veux sans les noms des commentaires ?
Je pense que cela se produirait avec la plupart des DVD qui ont une piste de commentaire
Oui, c'est un peu un cas limite. Handbrake scanne chaque piste de sous-titres pour trouver quelque chose qui apparaît 10 % du temps ou moins. En général, ça marche bien, mais comme vous l'avez constaté, s'ils trouvent une autre raison d'afficher les sous-titres moins de 10 % du temps... pas si bien que ça.
Une chose qui *devrait* fonctionner (bien que cela prenne du temps) est de lire une partie du DVD par le biais de quelque chose comme VLC (c'est gratuit, ça lit à peu près tout) et de trouver quelle piste de sous-titres contient les sous-titres forcés. Pendant la lecture du DVD dans VLC, dans le menu du haut, choisissez "Vidéo / Piste de sous-titres" et échangez-les, de préférence à peu près au moment où Jabba parle. Je pense que vous trouverez probablement deux pistes de sous-titres qui jouent pour sa voix - une qui ne contient que des sous-titres forcés et une autre qui contient tout. À ce stade, vous pouvez essayer de faire correspondre la bonne piste à la liste de sous-titres dans Handbrake.
Faites un encodage rapide la première fois (juste au cas où vous n'auriez pas trouvé la bonne correspondance).
Si, pour une raison quelconque, vous avez encore des problèmes, faites-le moi savoir - j'ai encodé Star Wars il y a longtemps, mais je peux à nouveau déterrer les DVD et voir si je peux réduire le nombre de choses pour vous si nécessaire.
j'ai utilisé HandBrake 0.9.8, et je me souviens dans HandBrake 0.9.5 il avait la possibilité d'utiliser petit (taille de fichier personnalisé).
merci pour votre réponse :)
une idée de rendre la taille plus petite (la moitié de l'avant) mais pas réduit la qualité d'image du tout ?
merci pour votre réponse
note : à partir de votre paramètre ci-dessus, la taille de mon fichier de série tv maintenant 80% de la taille précédente
Cela dit, quelques petites choses que vous pourriez essayer...
-activer le filtre de débruitage (faible ou personnalisé) dans les paramètres de l'image. Cela adoucira probablement un peu l'image, mais devrait aider à réduire la taille du fichier. Assurez-vous qu'il est acceptable.
-utiliser 16 b-frames
-utilisez autant de cadres de référence que possible. Notez que l'encodage prendra plus de temps (et si vous en utilisez trop, il risque de ne fonctionner que sur l'ordinateur et non sur les appareils portables)
-Renforcez la RF au maximum que vous pouvez supporter.
N'oubliez pas que si vos vidéos xvid sont déjà de petite taille (faible débit binaire), il sera très difficile de réduire encore la taille des fichiers sans nuire sensiblement à la qualité de l'image lors du recodage. C'est beaucoup plus facile si vous utilisez un xvid de plus grande taille avec un débit binaire plus élevé (ou idéalement, le flou de la source ou le DVD qui aura un débit binaire énorme). Plus vous utilisez de bits dans la source, mieux Handbrake & x264 peuvent faire leur travail !
Bonne chance.
Si vous utilisez quelque chose comme "Playon" pour diffuser vos films sur une PS3, Google TV ou WII (ou même sur votre tablette ou votre téléphone), il n'est généralement pas conseillé de "passer" par un codage audio DTS, car cela a tendance à provoquer une gigue ou une pause de la vidéo et d'autres problèmes de synchronisation avec les appareils DLNA. Il en va de même avec les conteneurs MKV. Il est préférable de s'en tenir au MP4. Quant à l'audio, votre meilleure option serait probablement d'encoder en AAC ou AC3, ce qui m'amène à un autre problème. Vous avez besoin d'un minimum de 320 à 384Kbits/s pour préserver le son surround 5.1, donc si vous prévoyez d'entendre le woosh du Faucon Millenium passer d'abord de votre haut-parleur avant gauche à votre haut-parleur arrière gauche, 160Kbits/s ne suffiront pas. Les canaux ont tendance à être fusionnés lorsqu'il n'y a pas assez de bande passante pour les séparer. En fonction de votre source, vous pouvez généralement coder en AAC jusqu'à environ 320 et en AC3 jusqu'à environ 640.
En général, je prends le DTS et je l'encode en AC3, puis je choisis 640Kbits/s
Quelque chose a été implentend dans x264 qui est appelé 'Macroblock Tree Ratecontrol » (mbtree). Cette option est activée par défaut. Et si c'est activé, ça visse des scènes sombres. Pour l'éteindre, il y a le paramètre no-mbtree qui doit être réglé sur 1 :
no-mbtree=1
Il suffit d'ajouter ceci à la case « chaîne d'option avancée ». Ensuite, cela pourrait ressembler à quelque chose comme ceci, par exemple :
weightp=1:subq=9:rc-lookahead=10:trellis=0:b-adapt=2:deblock=-1,-1:no-mbtree=1
Il n'y a pas de case à cocher pour la chose mbtree, donc vous devez le faire via la chaîne avancée. Pour moi, ce décor a fait des merveilles pour des scènes sombres. Au moins pour mon DVD Madame Bovery፦)
http://forum.doom9.org/showthread.php?t=159259
Quelqu'un a écrit :
« [...] J'ai noté qu'avec mb-tree sur l'encodage au même débit que le no-mbtree on a une qualité inférieure dans les zones granuleuses sombres, [...] »
Et un autre gars :
« [...] MB-tree suit essentiellement les détails à travers le temps. Quelque chose qui « est là » pour plusieurs cadres... est plus important que quelque chose qui n'est là que pour un seul cadre.
Le grain, selon la quasi-définition, est un « détail qui change chaque image ». Il n'est donc pas difficile d'imaginer ce que MB-tree « pense » du grain. Et bien sûr, dans un paysage sombre, chaque déviation indésirable est beaucoup plus évidente [...] »
Juste pour informer les gens de mes tests d'encodage :
Je suis arrivé à la conclusion qu'un encodage en 2 passes combiné avec no-mbtree=1 est une bien meilleure idée pour les films dans lesquels les scènes sombres posent un problème. Surtout quand vous avez des films dans lesquels les scènes sombres sont en quelque sorte granuleuses et floues. Par exemple, le DVD de Madame Bovary est plutôt pauvre, le film date de 1991 et il a l'air délavé. Un Bluray serait bien sûr bien meilleur. Mais je n'ai qu'un DVD pour l'instant.
Comment l'ai-je abordé ? J'ai mis no-mbtree=1 dans la boîte à chaîne des options avancées. Ensuite, j'ai utilisé un encodage à 2 passes et j'ai restreint le débit. En effet, si vous définissez no-mbtree=1, le débit binaire de chaque image augmente, non seulement pour les scènes sombres, mais aussi lorsque no-mbtree=1 n'est pas nécessaire. Ainsi, avec un encodage de qualité constante, vous vous retrouveriez avec un fichier d'une taille nettement plus importante. Afin de contrôler cela, le débit binaire doit être limité. Mais quel débit binaire utiliser ? Eh bien, j'ai simplement fait quelques tests avec un encodage de qualité constante, rendu 1 ou 2 chapitres du dvd pour savoir quelle pourrait être la taille de fichier attendue. Puis, avec un calculateur de débit, j'ai obtenu le débit vidéo moyen. Il y a beaucoup de calculateurs de débit sur Internet. J'ai utilisé celui-ci :
http://www.dr-lex.be/info-stuff/videocalc.html
Ensuite, j'ai entré le débit vidéo pour l'encodage en 2 passes, j'ai réglé tous les autres paramètres dans les paramètres d'encodage (important : à cause des scènes sombres, Subpel & ; ME Mode devrait être réglé sur 9 au moins) et j'ai commencé à encoder. Et le résultat a été très satisfaisant : taille de fichier résonnable et qualité bonne ou au moins acceptable même dans les scènes sombres difficiles.
D'ailleurs, merci beaucoup ! Vos informations ont été très utiles. Avant de découvrir votre article de blog, je ne savais rien sur le réglage fin des paramètres d'encodage de Handbrake. Après avoir lu votre récapitulatif, j'ai compris beaucoup plus de choses et j'ai pu creuser moi-même. Maintenant, je suis capable d'obtenir de bien meilleurs encodages pour une taille de fichier identique ou inférieure.
Notez que si par "bloqué" vous entendez un bégaiement, en fonction de la taille du fichier, il se peut que votre disque dur ne puisse pas suivre le débit de données dont la vidéo a besoin - en particulier si un autre programme accède au disque dur en arrière-plan. Cela s'applique également si le fichier est très fragmenté, bien que cela ne devienne généralement un problème dans OSX que si votre disque dur commence à être vraiment plein. Bien sûr, si vous utilisez un disque dur externe USB2, il y a toujours la possibilité que la vitesse de l'USB2 ne soit pas suffisante pour suivre le rythme.
Si vous pensez que c'est un problème de débit, vous pouvez essayer d'augmenter la valeur RF (en réduisant la qualité, mais aussi le débit et la taille du fichier). Si vous utilisez un RF de disons... 18, essayez d'augmenter la valeur pour dire... 25 pour un essai. Si elle fonctionne bien à RF25, vous pouvez commencer à la modifier jusqu'à ce que vous trouviez un bon équilibre entre le fait de ne pas bégayer et l'apparence.
Une autre possibilité que je devrais probablement mentionner (bien qu'elle soit quelque peu improbable)... J'ai entendu dire que l'ajout de métadonnées (MetaX par exemple) peut parfois faire apparaître des vidéos dans certains lecteurs. Vous pourriez donc essayer de lire le fichier dans iTunes juste après l'encodage - ne le passez pas par MetaX. Si cela fonctionne, vous pouvez essayer quelque chose comme iDentify au lieu de MetaX - il contient une option dans les préférences pour "Optimiser les fichiers après le balisage" qui réécrira le fichier pour aider à éviter that edge-case particulier avec le balisage.
Bonne chance !
je pense aussi que c'est un problème de disque dur. mais cela fonctionne bien avec VLC. J'ai comparé ma vidéo avec la vidéo d'itunes store. ma vidéo a un débit binaire total de 3574 kbps, la vidéo du magasin ont 412 kbps. donc cela pourrait b le problème. Alors, comment puis-je définir le mode de débit à constante non variable et comment définir le débit total dans HandBrake ? Y a-t-il une différence entre le mode birate et le mode de fréquence d'images ? un de plus, une différence entre 'bitrate' et 'bitrate total' ?
Désolé pour mon mauvais anglais
MERCI à l'avance
"Total débit binaire" est spécifique, et se réfère généralement au débit binaire moyen sur l'ensemble de la vidéo (3574 dans votre cas). Le terme "débit binaire" n'est pas aussi précis en soi, et sa signification dépend du contexte.
Bitrate et framerate sont deux choses totalement différentes qui ne sont pas directement liées l'une à l'autre. Je soupçonne que vous regardez "RF" et que vous le lisez peut-être à tort comme "frame rate". RF signifie en fait "facteur de débit", et si vous le réglez sur plus haut, le débit sera plus bas.
Vous avez demandé comment régler le mode de débit binaire sur constant dans votre code, mais pour être honnête, vous ne voulez probablement pas vraiment cela. Cela donne des fichiers énormes qui ont tendance à avoir l'air très pauvres lorsque vous arrivez à des scènes complexes à fort mouvement. Essentiellement, cela gaspille des bits dans des scènes où il n'en faut pas beaucoup et il n'y a pas assez de bits lorsque vous arrivez à des scènes qui en ont besoin. C'est aussi beaucoup plus difficile à faire/utiliser dans Handbrake - je crois qu'il y a des moyens de l'imiter via certaines chaînes d'options avancées (en fixant un taux variable min/max), mais il n'y a rien dans l'interface graphique. Votre meilleure option est probablement de choisir un débit moyen inférieur (ce sera votre nouveau "débit total"), ou si vous avez utilisé la qualité constante, d'augmenter la valeur RF à un chiffre plus élevé.
j'ai essayé cela
Codage d'entropie CABAC, Transformation 8×8, P-Frames pondérés, Pyramide B-Frames, CABAC => Tous désactivés
Réf cadres, Maximum de trames B =>2
Mode Direct adaptatif : Auto
Estimation du mouvement = Multi-hexagone inégal
Sous-pixel ME & Mode Décision = 10
Qualité=> Moy bitrat, 4122 kbps
fréquence d'images : constante, 29,97
Maintenant, itunes le lit bien et la taille du fichier est ok pour moi (film de 105min est 3.57 Go), de toute façon je ne sais pas beaucoup sur ce que font ces paramètres.
et encore merci u, le maître de Handbrake
Si mon fichier source est un fichier AVC TS (Level Main 3.1) avec 2 cadres de référence, y a-t-il un avantage à le pousser au-delà de 2 dans HandBrake ? Merci.
Je suis tombé dans un accroc si tu peux m'aider, s'il te plaît. Je sauvegarde mon Bluray, la vidéo est VC1 Advanced @L3, lorsque j'encoder en utilisant ces paramètres, je finis avec un haut @L3 .1 (je redimensionnement aussi à 720p). Existe-t-il un moyen d'encoder ceci et de résultat à Haute @L4 .1 ?
Merci pour toutes vos connaissances et grand site :)
J'ai récemment commencé à capturer et encoder du contenu sportif 1080i (NRL en Australie) à des fins d'archivage et je voudrais obtenir la meilleure qualité possible ! Sans avoir d'énormes tailles de fichiers évidemment.
J'utilise maintenant vos paramètres comme modèle :)
Proposez-vous d'autres ajustements qui seront plus efficaces en ce qui concerne le sport ?
Après avoir lu, je suppose que je devrais définir la plage d'estimation de mouvement à au moins 64.
Déblocage à -1, -1 ?
rc-regard anticipé à au moins 60.
Toutes les suggestions seraient géniales et merci pour ce guide incroyable !
Je serais enclin à vérifier et à m'assurer que décomb et dételecine sont réglés sur défaut - vous pourriez essayer d'expérimenter avec quelques essais pour voir si vous obtenez beaucoup de différence entre cela et le réglage manuel du désentrelacement, pensez vous.
Si vous optez pour l'archivage, vous pouvez utiliser un paramètre RF inférieur à ce que vous le feriez normalement (qualité supérieure). Vous aurez de plus grandes tailles de fichiers, mais parce que les émissions sportives sont quelque chose que vous ne pouvez pas exactement aller dans le magasin 10 ans plus tard et acheter un DVD/BluRay de... vous voulez vraiment vous assurer que la qualité résiste au fil du temps. Vous n'avez qu'une chance avec ce type de contenu (une fois que vous avez supprimé la source, vous aurez du mal à le retrouver), alors assurez-vous d'être satisfait.
Oui, j'utilisais à l'origine Deinterlace jusqu'à ce que je lise ceci. Ensuite, j'ai vérifié avec Decomb et c'était bon ; ça avait l'air identique et le journal a montré qu'il désentrelaçait toutes les images sauf une.
Je vais peut-être essayer de tester les temps d'encodage pour voir si le désentrelacement est plus rapide (peut-être parce qu'il n'a pas besoin de vérifier chaque image) puisque je sais que la vidéo source est de toute façon entrelacée.
C'est un excellent conseil concernant les paramètres de qualité, vous m'avez convaincu de passer à RF 19 ou peut-être même 18. Au départ, je faisais RF 20 et j'obtenais des fichiers d'environ 6,5g, mais je suis heureux d'utiliser un peu plus d'espace en gardant cela à l'esprit. Il est impossible d'obtenir de vieux jeux ici, à moins que ce ne soit une finale, et même dans ce cas, vous auriez de la chance de l'obtenir s'il avait 10 ans.
J'ai passé du temps hier soir à tester différents réglages sur mon fichier d'exemple. J'ai enregistré tous les détails tels que les heures de codage et la taille des fichiers.
Mon hypothèse de départ était que parce que j'utilise le CRF, la qualité de la vidéo serait la même, mais que la taille du fichier changerait à chaque ajustement.
C'était généralement le cas, mais il y avait une anomalie, à savoir le Treillis psychovisuel ; lorsque j'ai augmenté ce paramètre à 0,15 (par défaut, 0), cela a en fait augmenté la taille du fichier de 4 %. Est-ce que cela augmente la qualité de la vidéo, même si j'utilise le CRF ?
De plus, lorsque j'ai modifié le Deblock(-1 -1) et la plage d'estimation du mouvement (16, 24, 32 et 64), la taille du fichier est restée la même dans tous les cas, donc je suppose qu'il ne détecte plus de mouvement (MER) ou d'artefacts (Deblock).
Je suis vraiment nouveau dans tout cela, donc toutes les hypothèses ci-dessus pourraient être totalement incorrectes. J'enverrai mes résultats dans un nouveau message et vous pouvez l'afficher si vous pensez que quelqu'un pourrait le trouver utile.
Je n'ai testé que les images de référence ; les images B ; la plage d'estimation du mouvement ; le sous-pixel ME et le mode décisionnel/treillis (combinés) ; le treillis psychovisuel et le déblocage.
Tout d'abord, Deblock n'a pas modifié la taille du fichier ni augmenté les temps de codage.
Cadres de référence :
4 - (valeur de base)
9 - 40% Augmentation du temps de codage ; 0,35% Réduction de la taille du fichier
B-Frames :
4 - (valeur de base)
16 - 32,5% Augmentation du temps de codage ; 1,27% Réduction de la taille des fichiers
La plage d'estimation du mouvement n'a PAS modifié la taille du fichier, mais a augmenté les temps de codage :
MER 24 - (valeur de base)
MER 16 - 3% Diminution du temps de codage
MER 32 - 6,5% Augmentation du temps
MER 64 - 23,5% Augmentation du temps
Le sous-pixel ME & Mode Decision/Trellis (combinés) a eu le plus grand impact bénéfique sur la taille du fichier :
9 & Encodeur seul - (base)
10 et toujours - 26,5 % Augmentation du temps ; 5,96 % Diminution de la taille du fichier
Treillis psychovisuel (augmentation de la taille du fichier au lieu de sa réduction) :
0 - (valeur de base)
0,15 - 6,5 % Augmentation du temps de codage ; 3,97 % Augmentation de la taille du fichier
Il ne s'agit évidemment que de tests mineurs, et chacun pourrait obtenir des résultats différents en fonction de sa vidéo source.
Juste pour être clair, si le CRF tends pour maintenir la qualité, ce n'est pas toujours le cas. En particulier, des choses comme le Treillis Psychovisuel (des trucs qui bougent sur des morceaux pour essayer d'augmenter la qualité perçue) peuvent mettre des bâtons dans les roues, comme vous l'avez remarqué. Visuellement, il y a probablement aussi une différence entre le code avec 0 et celui avec 0,15 bien qu'elle soit probablement faible puisque vous utilisez une faible valeur CRF (peut-être même pas assez pour le remarquer visuellement). Pour rendre les choses plus passionnantes, l'un ne sera pas nécessairement "meilleur" que l'autre non plus - la question de savoir si les gens aiment le résultat des améliorations de la qualité perçue se résume souvent à une préférence personnelle. Soit dit en passant, si vous essayez de comparer x264 avec autres encodeurs et de comparer le rapport signal/bruit entre eux, d'après ce que je me souviens, PSY Trellis est l'une des choses que vous n'êtes pas censé/autorisé à utiliser.
Les modifications des images de référence/B, l'estimation du mouvement, etc. devraient toutes conserver la même qualité visuelle.
J'aurais probablement dû mentionner dans la rédaction... le déblocage dans les paramètres avancés (listés comme 0,0 etc) d'après ce dont je me souviens stocke en fait des informations qui sont envoyées au decodeur lorsque vous jouez le fichier, donc il n'a pas (ou ne devrait pas avoir) d'effet sur la taille du fichier - il indique juste au décodeur combien débloquer la vidéo finale. Je suppose que j'aurais pu vous faire gagner un peu de temps si j'avais été plus précis à ce sujet lors de la rédaction (désolé !). Le déblocage dans les "paramètres vidéo" aura cependant un impact substantiel sur la taille du fichier s'il est utilisé, puisqu'il débloque la source avant l'encodage (bien qu'il ait l'air terrible la plupart du temps imo - ne l'utilisez pas !)
Super, donc PSY Trellis augmente la qualité perçue, j'ai jeté un coup d'oeil rapide et je n'ai pas pu remarquer de différences, mais je vais vérifier sur la télévision plutôt que sur le moniteur.
Tout va bien avec le Deblock, je peux maintenant faire quelques tests avec le fichier sur mon lecteur multimédia et voir si je remarque des différences, donc merci pour cette info aussi, et pour la confirmation sur les autres paramètres.
Il est intéressant de savoir que le changement des cadres de référence était en fait le pire rapport coût/bénéfice parmi ces réglages, étant donné que c'est le plus connu. C'est peut-être seulement le cas pour le sport.
Je devrais également mentionner que j'encode en 720p, mais vous l'avez probablement compris car j'ai utilisé 9 trames de référence pour les tests. Si je fais du 1080p à la CRF 20, cela me donne un fichier de 12 gigas :0
J'archive chaque match de la saison pour l'équipe que je suis, donc je ne peux pas me permettre d'utiliser autant d'espace ; l'encodage du temps double aussi.
D'après ce que j'ai pu rassembler, un fichier de 6 à 8g est plus agréable en 720p, même sur mon 52". Un fichier de cette taille en 1080p ne serait qu'environ CRF 24-25 (pas sûr parce que j'ai utilisé deux passes en comparant les résolutions) donc cela semble logique je suppose.
Encore une fois, merci pour votre aide, je vais continuer à jouer avec les réglages. J'espère pouvoir enfin prendre une décision afin de me débarrasser de ces fichiers de capture originaux de 20g de la saison dernière :)
Je voulais juste vous déposer un grand merci pour la mise en place de ce guide Handbrake - il est le plus clair, le plus complet de son genre que j'ai trouvé en ligne, et a été incroyablement utile dans la tâche de convertir ma collection de films en fichiers !
Tout d'abord. Excellent guide Handbreak !
J'ai une question au sujet du par.
J'utilise les « paramètres de base » pour un haut profil mp4 rip avec un recadrage anamorphique strict et automatique. Lorsque je regarde le film avec les sous-marins en VLC, les sous-marins sont déplacés vers le haut dans le film. Environ la même distance que lorsque son dérecadrée.
Puis-je faire quoi que ce soit pour placer les sous-titres dans la bonne position pour ne pas couvrir le film ?
(Je suis de Suède donc s'il vous plaît ne jugez pas mon anglais : D)
Cela dit, il peut être possible d'ajouter un "rembourrage" noir au bas de la vidéo pendant la lecture - vous devrez parcourir les paramètres avancés de VLC, mais si vous ajoutez suffisamment de rembourrage, les sous-titres devraient s'y retrouver. (Editer : Je suppose que si votre source a déjà des barres noires, une autre option serait de désactiver le recadrage dans les paramètres d'image de Handbrake, mais sachez que l'encodage de barres noires n'est souvent pas idéal en raison du fenêtrage que vous obtiendrez sur certains écrans).
L'autre option consiste à utiliser un autre lecteur vidéo - VLC n'est pas connu pour sa grande flexibilité en matière de sous-titres, mais certains autres lecteurs multimédia le sont.
Merci !
b-adapt=2:rc-lookahead=120:direct=auto:trellis=2:ref=4:bframes=16:me=umh:subq=10:merange=64:analyse=all:psy-rd=1.0,0.15:deblock=-1,-1:nr=200Note :
- ref=4 est pour un BluRay 1080p afin qu'il soit diffusé sur mon AppleTV, iPad3, etc. Je l'ai augmenté à ref=12 pour les DVD (480p) mais de temps en temps, il y a quelques blocs de macro brouillés sur l'AppleTV et Quicktime/iTunes, alors je le ramène à 9 si je ne pense pas que je vais le regarder tout de suite pour m'assurer qu'il a survécu.
- nr=200 Je vais utiliser couramment parce que je ne peux pas faire la différence en termes de qualité visuelle. Lorsque j'essaie de réduire encore plus la taille des fichiers (séries TV ou films dont je me moque), je passe à 400. Si la source est vraiment bruyante, j'utiliserai 800 sans trop d'hésitation.
- Si vous êtes impatient, je réduirai l'estimation du mouvement et les sous-pixels à leurs valeurs par défaut (Hexagone, et 7) pour accélérer le codage.
- J'ai tendance à utiliser les paramètres de débruitage personnalisés dans les "options d'image" parce que les pixels dansants me rendent fou, donc ça nettoie tout en diminuant la taille du fichier. 0:0:3:2, 0:0:2:1, et 0:0:4:1 sont quelques uns des réglages que j'utilise fréquemment sur presque toutes les sources (juste le débruitage temporel - je n'utiliserai pas le débruitage spatial à moins que ce soit une source bruyante). Il est très rare que je n'utilise rien ici.
Gardez à l'esprit que, surtout lorsqu'il s'agit de choses comme les réglages psy-rd, cela devient tout autant un art qu'une science - vos préférences personnelles vont commencer à entrer en jeu.Profil personnalisé
b-adapt=2:rc-lookahead=50:bframes=16:ref=4:direct=auto:me=umh:subq=10:merange=24:analyse=all:trellis=2:deblock=-1,-1
Le profil élevé ne devrait pas le remonter comme ça en supposant que vous utilisez la même valeur RF pour les deux - voyez s'il a ajouté une 2e piste audio lorsque vous l'avez sélectionnée (après avoir sélectionné un préréglage, il est souvent conseillé de regarder les options et de s'assurer qu'aucune piste audio n'a été ajoutée et que la résolution n'a pas été modifiée).
Est-il normal que cela prenne 2 à 2,5 fois plus de temps pour encoder en utilisant les paramètres personnalisés vs Normal ou High Profile ?
2,5 heures, c'est un peu long pour un épisode de 30 minutes (je vais me risquer à dire que vous n'êtes pas sur un Ivy/Sandy-bridge i5/i7). Si vous devez laisser tomber quelque chose pour réduire la durée, je commencerais probablement par les B-frames et le sous-pixel ME / Mode Decision (laissez tomber à 7, comme dans le cas de l'épisode par défaut). Cela devrait vous permettre de vous rapprocher des temps de codage que vous voyiez avec High Profile.
Gardez à l'esprit que si vous utilisez la "qualité constante" (RF), la suppression de ces éléments n'affectera probablement pas la qualité. La taille des fichiers sera plus importante - puisque vous vous situez de toute façon dans la zone des 315-341 Mo (ce qui n'est pas un écart important), le temps pourrait être plus important pour vous que les ~25-30 Mo.
J'ai une question sur votre chaîne d'options avancées "point de départ". La plupart de ces paramètres ne sont-ils pas les mêmes que ceux qui sont définis par les menus déroulants et les curseurs du panneau Avancé de Handbrake ? Par exemple, "ref=" n'est-il pas le même que le menu déroulant des "cadres de référence" ? Deblock=" n'est-il pas identique aux deux menus déroulants "Deblocking" ? Pour autant que je sache, les seules options uniques dans votre chaîne sont rc-lookahead et nr.
Si elles sont identiques, alors pourquoi est-il nécessaire de répéter ces paramètres dans la chaîne ? Et si vous définissez des paramètres différents pour la même option dans le panneau par rapport à la chaîne (par exemple, en fixant le menu déroulant des cadres de référence à 6 mais en écrivant "ref=4" dans la chaîne), lequel a la priorité ?
Enfin : utilisez-vous parfois vbv-bufsize ou vbv-maxrate ? J'ai remarqué qu'ils apparaissent automatiquement dans la chaîne pour le paramètre High Profile, mais tout ce que j'ai lu en ligne indique que les deux réduisent la qualité de l'image. Des idées ?
Merci ! J'apprécie beaucoup !
En effet, cette chaîne d'options est dérivée des menus déroulants du panneau avancé. C'est en remplissant le panneau avancé que cette chaîne se propage réellement (j'ai ajouté manuellement le "nr" comme vous l'avez remarqué).
Je l'avais collée parce que Zac avait spécifiquement demandé le code en bas de l'onglet avancé - il est possible qu'il cherchait une courte ligne résumant tout ce que j'ai utilisé qu'il pourrait convertir manuellement en listes déroulantes.
À votre question sur la répétition de ces paramètres de listes déroulantes dans la chaîne, Handbrake le fait automatiquement. Vous ne devriez pas les répéter manuellement ou quoi que ce soit d'autre : contentez-vous de vous fier aux listes déroulantes où vous pouvez (la plupart des paramètres), et ajoutez manuellement tout ce qui n'est pas dans les listes déroulantes et que vous pourriez vouloir utiliser (nr, etc).
Quant à vbv-bufsize et vbv-maxrate, je ne les attribue pas manuellement - ils sont remplis automatiquement en fonction du profil et du niveau. Si vous les omettez (peut-être en plus d'omettre "level=x.x"), votre vidéo pourrait provoquer l'étouffement de certains appareils. Par exemple, un iPhone 4 n'est classé que pour prendre en charge le niveau principal 3.0. Cela donnera des options avancées qui incluent "level=3.0:vbv-bufsize=10000:vbv-maxrate=10000". Si vous supprimez ces valeurs (ou si vous les augmentez), la vidéo risque de s'étouffer lors de sa lecture sur l'iPhone 4.
En ce qui concerne la qualité, ce que vbv-bufsize et vbv-maxrate actually do est le "cap" de la taille du tampon et du débit instantané. Donc, dans une situation où l'encodeur veut réellement dépasser ce plafond (mais ne peut pas), oui, vous perdrez généralement la qualité. Mais dans les situations où l'encodeur n'allait pas atteindre ce plafond de toute façon, cela n'aura aucun impact sur la qualité.
Vous pouvez voir un exemple extrême de cela en encodant un court clip (disons 10 secondes) d'une vidéo au niveau principal 1.0 . Le débit binaire sera tellement limité (vbv-bufsize=175:vbv-maxrate=64) que la vidéo aura une apparence affreuse ou n'aura même pas un débit suffisant pour fonctionner. Des niveaux plus élevés augmentent la limite, mais un niveau trop élevé (ou le fait de n'utiliser aucun niveau) peut rendre la vidéo suffisamment complexe pour qu'elle ne puisse pas être lue sur certains appareils.
J'espère que cela vous aidera !
Merci beaucoup ! !!
Je me suis demandé ce qu'il était advenu des options de l'encodeur du panneau vidéo une fois la case des options avancées cochée. Vous avez dit que le "tune" correspond en gros aux curseurs avancés. Donc, ajouter des chaînes pour le niveau et les vbv est la seule façon d'annuler les valeurs par défaut qui apparaissent en gris ("x264 Unparse"), correct ? Est-ce qu'il en va de même pour "Preset" et "Profile" - vous avez besoin de chaînes ?
De plus, je n'ai pas d'option pour "Motion Estimation Range" dans mon panneau avancé (Handbrake 0.10.0). Je ne trouve rien en ligne sur la raison de son absence. Cette option a-t-elle été supprimée avec la version 10 ? Je suppose que je pourrais l'ajouter sous forme de chaîne comme dans votre exemple.
Merci encore pour votre aide détaillée - elle est très appréciée ! J'ai utilisé le frein à main dans le passé et j'en ai été satisfait, mais j'essaie maintenant de comprendre les options pour obtenir des résultats de meilleure qualité. Vos postes ont beaucoup aidé !
Gardez à l'esprit que certains profils restreignent également certaines choses comme les cadres de référence, les b-frames, etc. Donc combiner des profils avec des paramètres avancés peut devenir un peu périlleux... par exemple si vous définissez un profil qui ne prend en charge que 3 cadres de référence mais que vous sélectionnez manuellement 16 cadres de référence dans les options avancées, je ne sais pas lequel a la priorité. C'est l'une des raisons (il y en a quelques-unes) pour lesquelles j'ai choisi d'utiliser les préréglages x264 et de ne me plonger dans les options avancées que lorsque je cherche à faire quelque chose d'assez spécifique. Le guide que vous lisez ici a été réalisé avant l'apparition des préréglages x264 et avant que je ne commence à me préoccuper de la lecture sur des appareils non PC. Certaines des choses que j'ai énumérées ici peuvent certainement être utiles pour la lecture, l'apprentissage et la compréhension, mais lorsqu'il s'agit de pomper des codes (en particulier pour la lecture sur des appareils), les préréglages rendent la vie beaucoup plus facile.
La "Motion Estimation Range" (encore une fois, 1.0.7) n'apparaît que sur les méthodes d'estimation de mouvement les plus élevées (UMH, Exhaustive, Transformed).
Merci encore de m'avoir aidé. J'ai maintenant effectué de nombreux tests de conversion en utilisant à la fois vos paramètres avancés et les préréglages, juste pour comparer la taille des fichiers, la lecture, la qualité, etc. J'ai constaté que CQ18 donne un fichier à peu près de la même taille que l'original, alors que CQ22 est à peu près deux fois plus petit. La quantité du cadre de référence est le principal facteur du temps de traitement. Le préréglage le plus lent était celui qui se rapprochait le plus de vos paramètres avancés, tandis que le plus lent prenait environ 20 minutes de plus (probablement les 16 images de référence).
J'ai eu une observation étrange à partager avec vous. J'ai utilisé des cadres de référence dans le voisinage 6-8 (conversions SD de DVD). Je suis principalement sur un Mac, qui joue les exportations HandBrake sans problème. Cependant, sur mon ordinateur Windows (Windows 7 ultimate), ni Windows Media Player ni RealPlayer ne peuvent gérer les MP4 Handbrake avec plus de 6 cadres de référence. L'image est bloquée, horriblement pixellisée, se décompose....unwatchable. J'ai confirmé que c'est bien le réglage du cadre de référence.
Je pourrais probablement télécharger un pack de codecs qui corrigerait le problème, mais il m'a semblé intéressant qu'un système d'exploitation assez récent sur un ordinateur décent s'étouffe avec les cadres de référence. J'ai cru comprendre que c'était davantage un problème avec les anciens appareils et que les ordinateurs étaient plus avancés dans leur prise en charge des profils et des niveaux. Avez-vous déjà rencontré un problème de ce genre ? C'est suffisant pour me convaincre de m'en tenir à 6 comme valeur de référence. :-)
Merci encore - vos poteaux de frein à main ont été absolument inestimables pour m'apprendre ce programme !
Jen
Cela peut être important si le profil est plus élevé que ce que le décodeur CPU/GPU permet, mais que le lecteur vidéo essaie quand même de faire passer les vidéos à travers eux plutôt que de se rabattre sur le logiciel.
Vous pourriez éventuellement tester cela en créant 2 vidéos basse résolution (en les laissant tomber pour dire... environ 430x240), en utilisant Main/3.0, et en vous fiant aux préréglages de vitesse. Dans la vidéo n°1, utilisez une vitesse qui pousse les images de référence >= 7 (probablement lente, très lente ou placebo, mais regardez la ligne ref=x pour vérifier). Dans la vidéo n°2, utilisez une vitesse plus rapide qui conservera les images de référence < =6 OU conservez la vitesse préréglée et tapez manuellement quelque chose comme "ref=5" dans la case "Additional options" (appuyez sur Entrée après ou modifiez une autre option pour vous assurer qu'elle est prise en compte dans le "un-parse").
En ce qui concerne les problèmes très similaires, les Apple TV 2 & 3 (je ne connais pas aTV 4) ont un bug qui les empêche de lire des vidéos avec 16 images de référence. Ou du moins, c'est le cas pour moi. 15 images de référence fonctionnent très bien. La meilleure supposition est que quelqu'un à Apple a dérapé sur une situation 1-16 -> 0-15 -> 1-15 qui se produit parfois lors du codage en boucle, mais je ne peux que spéculer ici.
Des conseils pour que mes fichiers encodés ressemblent à ceux de mon lecteur DVD ?
vbv-maxrate=25000:vbv-bufsize=31250
-Neil
Quels que soient les réglages, j'éprouve toujours un problème subtil avec les saccades lors des mouvements qui traversent l'écran. C'est toujours pire avec les encodages DVD qu'avec les BluRay. Je dispose d'un double cœur à 3 GHz avec 6 Go de RAM et d'une NVIDIA GeForce 210 510mb fonctionnant en HDMI sur un récepteur Denon, puis sur un écran LCD à LED de 55 pouces. J'ai essayé d'augmenter la priorité du VLC à un niveau élevé dans Task Mgr, et j'ai aussi essayé de contourner le récepteur. Ces mêmes codages fonctionnent parfaitement sur mon ordinateur portable plus lent lorsque je copie le fichier sur le lecteur local.
Certains ont mentionné que l'AC3 Passthru Audio pourrait être le problème. J'y ai réfléchi et j'ai essayé différents formats audio, mais cela ne semble pas faire de différence. L'avantage de l'AC3 Passthru, tel qu'il est écrit dans le guide Handbrake, est que vous ne perdez pas le canal du subwoofer comme vous le feriez dans d'autres formats. Sans le passage, vous vous retrouvez avec un son de type Dolby 5.0.
J'ai également essayé de copier le fichier sur le disque dur du système d'exploitation local (à partir du disque de données "vert", également interne) et je l'ai testé là où c'est un SSD. IO n'est donc pas un problème.
J'ai déjà mis à jour la carte vidéo une fois et je le referais si je savais que cela pouvait aider. Ou je peux envisager de construire une machine plus puissante avec un quadruple noyau 64. Le processeur Dual Core actuel est un Intel et le système d'exploitation fonctionne en 64 bits. Le VLC est une version 64 bits. Il semble que la lecture de Windows Media Player soit légèrement supérieure, mais il ne lit pas l'audio AC3 Passthru. Lorsque l'on teste un film codé sur Windows Media Center qui a un AAC par exemple, il y a encore un peu de saccade, bien que légèrement réduite.
Toutes les suggestions que vous pouvez faire sont les bienvenues. J'ai passé d'innombrables heures à faire des recherches et à essayer d'aller au fond des choses. Merci encore pour cette superbe vidéo.
Si c'est le cas (vous avez juste affaire à un film en 2,35:1), la réponse à votre question sur une solution simple est essentiellement "non", mais si vous aviez l'intention de le faire quand même, vous auriez en gros 3 options. Vous pourriez :
- Couper une partie du côté gauche/droit de la vidéo (c'est dans les paramètres de l'image) ce qui équivaut à couper une partie de l'image. Pour que ce film remplisse complètement l'écran de votre iPad2, vous devez couper environ 126 pixels à partir de la gauche et 126 pixels à partir de la droite (si Handbrake a déjà coupé en haut/en bas, laissez ces valeurs intactes).
- Choisissez le format d'image dans Handbrake (encore une fois, les paramètres de l'image) et essayez de le faire ressembler à 1,33:1 (le format total de votre iPad). Cela aura pour effet d'étirer tout à la verticale. Il vous faudra faire des expériences ici - le simple fait de le régler sur Anamorphic None pourrait suffire, bien que si l'iPad l'envoie toujours dans les boîtes aux lettres, vous devrez peut-être aussi désactiver "Keep Aspect Ratio" et le régler sur 468x352. Vous pouvez aussi essayer "Custom Aspect Ratio" et jouer avec la largeur et la hauteur du PAR.
- Mélanger un format personnalisé avec le recadrage. Ne recadrez pas autant, et n'ajustez pas autant le rapport hauteur/largeur. Il est possible que les choses aient l'air un peu moins mauvaises que si vous alliez à fond dans une de ces directions.
Le recadrage est l'option la moins terrible à mon avis, mais ce n'est pas encore génial - il faut couper un *lot* d'image pour passer de 2,35:1 à 1,33:1 (le rapport d'aspect de votre iPad). Pour référence, votre MBP, s'il est récent, est probablement de 1.6:1 .Pour être honnête, si vous pouvez le gérer, je le laisserais tel quel. Au-delà de l'énorme quantité de travail et du temps qu'il faut (et du fait que d'ici à ce que vous ayez terminé, tout sera probablement mauvais sur sauf un iPad2), découper ou étirer des parties de l'image ne m'a jamais plu pour commencer.
Edit: j'ai juste mélangé une vidéo 2:35:1 sur mon iPad3 et j'ai remarqué qu'il y a un bouton qui ressemble à une fonction de "zoom" situé à côté du curseur temporel. C'est probablement la chose la plus facile à utiliser - le résultat final est similaire au recadrage, mais il est plus rapide et vous n'êtes pas obligé de recadrer la vidéo elle-même.
En m'appuyant fortement sur votre excellent guide, j'ai eu l'impression pendant un certain temps que je devenais assez habile pour atteindre mes objectifs de taille/qualité de fichier, en déchirant mes blu-ray. J'étais heureux de pouvoir réduire la taille des films plus anciens et plus granuleux d'environ 7 à 10 Go, et celle des films plus récents de 4 à 6 Go. C'est ainsi que j'ai acquis un fichier .mp4 d'un film récent, réalisé par le groupe YIFY. Cela m'a vraiment fait perdre la tête - 1h58 de durée d'exécution, 1,72 Go de flux vidéo, à 1080p avec pratiquement aucune perte de qualité. L'image est peut-être un peu plus douce que la source originale (pure spéculation, je n'ai pas vu l'original) et le son n'est définitivement pas à la hauteur de mes attentes (142 Kbps max. stéréo AAC). Une certaine précision des couleurs peut avoir été perdue. Mais bon... c'est tout de même bien mieux que ce que j'ai pu faire dans Handbrake.
Il y a quelques trucs en ligne sur la technique YIFY, mais rien de terriblement détaillé ou convaincant.
Restreindre à un seul noyau améliore la qualité ? Vraiment ? Je suis sceptique...
Quoi qu'il en soit - Des opinions sur la façon dont YIFY fait son truc ?
Santé
cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=1862 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Notez que je n'ai trouvé qu'un seul code (datant de 2012), et que ce ne sont que les paramètres que quelqu'un a publiés sur TPB (probablement via MediaInfo ou un autre programme similaire). Il est très possible que leurs codes varient tous - en général, les groupes de diffusion ont plusieurs contributeurs et les soumissions sont basées sur des directives minimales et des "règles de scène".
En ce qui concerne la partie "single-core", je serais également très sceptique. Il faudrait se renseigner sur les forums de doom9.org pour en être sûr, mais à ma connaissance, l'impact qualitatif de fils de discussion multiples est extrêmement marginal, à moins que vous n'ayez un *lot* de fils utilisés (ce qui n'arrive par défaut que si vous avez beaucoup de cœurs). Selon le wiki x264, plus de 16 threads, ce qui, d'après ce que j'ai compris, n'arriverait pas à moins que vous n'ayez plus d'un système à 11 cœurs. Et même dans ce cas, je doute que l'effet soit perceptible. En fait, dans l'encodage YIFY que j'ai trouvé, d'après les paramètres affichés, il semble qu'il y ait 3 threads, donc on peut supposer qu'ils utilisent une machine à double cœur.
Tout cela dit, d'après ce dont je me souviens, les codes YIFY (ainsi que la plupart des groupes) ont tendance à être un peu plus doux - probablement juste le résultat de la perte de détails en x264 lorsque vous arrivez à de faibles débits, mais il est toujours possible qu'ils prétraitent leur matériel, en le faisant passer par un dé-bruit ou quelque chose d'autre à l'avance pour aider à garder les choses en bon état à un faible débit. Vous pouvez essayer d'encoder votre source à un débit similaire à celui que vous avez trouvé et voir à quoi elle ressemble - si elle ne ressemble pas, commencez à modifier certaines options. Si vous finissez par utiliser des paramètres identiques à ceux qu'ils ont utilisés et que vous obtenez des résultats différents, il y a de fortes chances qu'ils effectuent un prétraitement (ou qu'ils falsifient les valeurs d'encodage stockées dans les métadonnées, bien que, d'après ce que j'ai compris, cela soit généralement mal vu dans la communauté).
1. mon tutelle est basée sur l'obtention du maximum de chaque chose, et plus somthymes, 2kb lessis 2kb les
2. eyeffa a mis à jour le clair postal le confucius, maintenant anna mate il clair dat 4 single thread encode plus rapidement qu'un seul 4 thread encode, donc y u faible cumme sum slackware ?
3. (fatigué de parler en argot, donc) apparemment le groupe YIFY utilise un paramètre unifié qui est mis à jour de manière centralisée, mais ce qui me dérange c'est que parfois ils semblent faire des encodages basés sur la RF alors que d'autres fois ils font des encodages basés sur le bitrate (comme leur encodage 720p de TPBAFK est de 699mb), et les encodages basés sur le bitrate m'énervent.
4. Comme je ne suis pas affilié à YIFY, je suppose qu'ils utilisent la magie pour rendre les vidéos compatibles avec le débit binaire afin de pouvoir offrir des vidéos à faible débit binaire sans perdre la compatibilité avec certains appareils.
5. évidemment, je n'ai pas vraiment d'autre idée sur le fonctionnement de x264 que "ça transforme mon dvd en un joli petit fichier de 300mb", mais j'imagine qu'il y a ce réglage qui met un CPU multi-cœur à 100% de sa charge, ce qui entraîne une réduction de la qualité
6. pas en rapport mais le 1080p de Youtube SUCITE ! Je ne sais pas pour vous mais je pense que le gars avec le PC haute performance devrait être capable d'obtenir une meilleure qualité que le gars avec la tablette, je déteste les encodages CUDA, bon sang !
1) Une exécution monofilière pourrait très bien réduire de quelques Ko (ou ajouter quelques Ko de qualité) - la seule façon d'en être sûr serait de poser la question à l'un des développeurs x264 ou de faire des tests SSIM/PSNR à threads=1 et de comparer avec la valeur par défaut sur un système multicœur. Je suis personnellement sceptique parce que s'il y avait vraiment quelque chose de tangible à faire en limitant les threads, je me serais attendu à ce qu'ils le fassent dans le préréglage --placebo. Mais de toute façon, l'utilisation d'un seul fil/coeur ne peut certainement pas *maltraiter* la qualité.
2) C'est juste. En fait, si vous faites cela avec un encodage par lots et plusieurs instances, je serais très enclin à essayer les threads=1 ici simplement parce qu'il ne devrait plus y avoir d'inconvénient (et même si vous ne gagnez que quelques Ko, vous n'avez rien perdu pour l'obtenir).
3) L'attachement à des codes basés sur le débit binaire pour atteindre certaines tailles de fichiers est compréhensible. Pendant très longtemps, le XviD à 350/700MB était standard (les gros films étant découpés en plusieurs fichiers de 700MB) et beaucoup de gens ont construit leur stockage et leurs configurations autour de cela. Lorsque les groupes de diffusion ont commencé à passer de XviD à x264, cela n'a pas été bien accueilli par tout le monde et je pense que les autres restes, comme les tailles de fichiers cibles, seront encore là pendant un certain temps. Les release groups peuvent faire la transition rapidement, mais leur... uhh.... ".... ne sont pas toujours prêts pour les dernières technologies.
4) Je ne sais pas si j'irais jusqu'à dire "magique" ;) . En regardant votre texte, il semble que le déblocage soit réglé sur 6,6, ce qui est en fait assez faible. Vous pouvez vous en tirer avec un débit binaire beaucoup plus faible en utilisant quelque chose comme ça, plutôt que de dire -1,-1, car les artefacts et/ou le macroblocage seront bien aplanis.
5) Je n'ai pas vérifié, mais je ne serais pas surpris si certains des préréglages les plus rapides le faisaient. Par ailleurs, d'après mon expérience, l'utilisation d'un autre encodeur H264 (pas x264) a tendance à bloquer l'utilisation du CPU et finit le plus souvent par être de moins bonne qualité que x264, donc techniquement cela pourrait compter ;)
6) Je suis d'accord - les encodages de YouTube sont en général de très mauvaise qualité. Cela dit, d'après leurs statistiques, ils ont 72 heures de vidéo téléchargées par minute. Ce qui représente plus d'une heure par seconde. Et avouons-le, il faut un matériel assez puissant pour transcoder plus d'une heure de vidéo par seconde, même en basse résolution. Pour le 1080p, ils transcodent également vers de nombreuses résolutions inférieures en même temps. Leurs options seront soit d'avoir des fichiers de taille énorme (que la plupart des connexions "haut débit" ne peuvent pas gérer en temps réel), soit de diminuer la qualité pour garder une bande passante raisonnable. Essayer de réduire drastiquement la taille tout en maintenant la qualité demande simplement trop de puissance de calcul. Je doute que les téléphones et les tablettes soient le problème ici - la plupart des appareils actuels ont un décodeur H264 intégré qu'ils pourraient utiliser (et qu'ils utilisent probablement) et qui surpasse largement la puissance de décodage de nombreux PC de 2-3 ans. Le seul problème que vous rencontrez avec les smartphones/tablettes actuels a tendance à se produire lorsque vous dépassez le niveau 4.1 du H264 - la plupart ne font pas 60 images/seconde à 1080p par exemple, ce qui pourrait expliquer pourquoi YouTube n'a pas encore adopté cette technologie. Mais c'est une toute autre discussion.
2) Il semble que j'apprends quelque chose de nouveau chaque jour. La première chose que je vais essayer la prochaine fois que je transcoderai quelque chose, c'est d'ajouter thread=1 à la ligne de commande (regardez-moi ici, surprenant les gens par la quantité de choses que je ne connais pas). J'en ai assez de x264 qui immobilise mon ordinateur chaque fois que je lance Handbrake.
3) Voici une autre possibilité (basée sur une supposition totalement non professionnelle) - dans un encodage YIFY, parfois les artefacts sont évidents alors que d'autres fois les artefacts sont moins visibles. Je pense que YIFY pourrait faire des codages basés sur le débit binaire à dessein et avec une méthode plus merdique de détermination de la distribution des bits de sorte que non seulement ils font gagner du temps sur l'encodage, mais la distribution de qualité légèrement inégale signifierait que tandis que certaines parties de la vidéo seraient merdiques, d'autres seraient vraiment belles, et ce sont les segments qui les nettoie que V10
4) "Magie" signifie évidemment un logiciel externe qui optimise une vidéo pour l'encodage en la rendant compatible avec le débit binaire.
Quant à deblocking=6,6, j'ai fait quelques expériences supplémentaires et j'ai découvert que si les filtres externes (tels que le filtre intégré de Handbrake) adoucissent votre vidéo de manière très sensible, deblock=6,6 n'adoucit pas beaucoup une vidéo. Au lieu de cela, il améliore simplement la qualité visuelle sans compromettre les détails, et aide également beaucoup à la visualisation d'une vidéo basse résolution à des résolutions plus élevées.
5) me rappelle quelques souvenirs - le premier transcodage h264 que j'ai fait était sur un logiciel appelé "ultra video converter", il m'a fallu deux jours pour "convertir" un encodage 720p de South Park BLU au format mkv sur un celeron 733 basé sur Coppermine. A part cela, le seul autre logiciel h264 que j'ai utilisé est format factory, qui utilise x264 (je crois). J'ai aussi exporté un projet vidéo via quicktime h264, mais c'était juste meh. Donc non, je n'ai pas vraiment d'expérience avec les encodeurs h264 autres que x264, et je ne peux donc pas vraiment faire de commentaires à ce sujet.
6) bien que la vitesse d'encodage soit une raison certaine, il n'est pas nécessaire de faire baisser trop la qualité pour garder une bande passante raisonnable. J'ai essayé d'utiliser un préréglage normal (ref=1:weightp=1:subq=2:rc-lookahead=10:trellis=0:8x8dct=0) dans Handbrake pour transcoder un brrip de 11 Go de rappel total 130min 1080p (2012) en RF23, et la taille du fichier résultant était inférieure à 2. La qualité de l'encodage 1080p CUDA de youtube à 3000kbps est tout simplement inacceptable pour les vidéos avec mouvement, et je trouve souvent que les versions 480p sont beaucoup plus regardables à condition qu'il n'y ait pas de détails intenses dans la vidéo.
L'option a également fonctionné certainement, car avant mon (Win 7 64 montrant) 8 cœurs étaient tous entièrement occasionnés, ce qui entraîne une charge CPU totale de 96 à 99%. Avec l'option ajoutée, la charge CPU totale ne faisait que sauter entre 20 et 30%.
Le fichier était un aperçu de 30 secondes d'une série de DVD. En utilisant denoise=ultra light et RF 20 avec x264 preset très lent, la taille du fichier sans limitation de thread était de 4.028.992 octets et avec threads=1 était de 4.022.272 octets.
Malgré le résultat plus petit, je ne limiterai pas les threads à 1 à l'avenir, car l'amélioration résultante de 0,1% ne justifie pas une augmentation du temps de rendu par facteur 4 à 5.
http://mewiki.project357.com/wiki/X264_Settings
fils
Par défaut : automatique (threads basés sur des trames : 1,5 * processeurs logiques, arrondi vers le bas ; threads basés sur les tranches : 1 * processeurs logiques)
Permet l'encodage parallèle en utilisant plus d'un thread pour augmenter la vitesse sur les systèmes multicœurs. La perte de qualité de plusieurs threads est principalement négligeable à moins d'utiliser des nombres très élevés de threads (disons, au-dessus de 16). Le gain de vitesse doit être légèrement inférieur à linéaire jusqu'à ce que vous commencez à utiliser plus de 1 thread par 40px de vidéo verticale, à quel point le gain des threads supplémentaires diminue fortement.
x264 a actuellement une limite interne sur le nombre de threads défini à 128, réalistes vous ne devriez jamais le définir aussi haut.
Merci d'avoir expliqué certains des coulisses du vaudou.
J'ai quelques questions cependant -
Pourriez-vous expliquer certains des paramètres débruités que vous avez mentionnés dans les messages précédents ? S'il y a quelque chose qui me bogue, c'est d'avoir un transcode qui se transforme soudainement en ordures quand il y a une coupure à une scène sombre...
J'ai aussi lu quelque part (ne me souviens pas où, aurait pu être les forums HB) où il a été indiqué que l'ordre dans lequel les paramètres ont été saisis dans la boîte d'options de codeur x264. Y a-t-il un mérite à cela ?
Merci !
Désolé pour le poste. J'ai trouvé la discussion « débruiter ». C'est ce que je reçois pour rester juste dans la discussion Handbrake.
La quête
C'est une application pour Xbox 360 et Windows 8... Dunno à propos de Windows Phone, cependant.
En examinant les propriétés des fichiers de ma collection téléchargée, je constate que les normes visibles pour les sorties de scènes h264, après le passage de XviD et AVI, se sont progressivement installées sur 720x404 pour les rips TVHD (non 720p) avec une fréquence d'images de 23,97 et des débits de données totaux de seulement 1000 environ. En conséquence, j'ai enregistré des enregistrements TV en 720x404 à 23,97 fps (variable), 1000kbps en double passe, audio AAC (faac) à 48 hz et 128 kbps, puis tous les réglages par défaut de Handbrake dans l'onglet avancé. Grâce à ces paramètres, je suis capable de convertir une émission de télévision de 42 minutes (sans publicité) de 4,5 gb en 330 mb environ en 15 à 20 minutes, en supposant que mon ordinateur ne fasse rien d'autre (Intel Core I-7, 16 gb RAM, Win 7, 64 bits, Intel SSD). Je suis généralement satisfait des résultats, et leur qualité se compare assez bien à celle des sorties de scènes, mais grâce à ce guide, j'espère pouvoir les améliorer bientôt ! Jusqu'à présent, j'ai expérimenté en changeant uniquement les paramètres avancés pour les valeurs recommandées ci-dessus. Malheureusement, les améliorations de la qualité d'une rediffusion enregistrée d'un ancien épisode de Matlock n'ont pas justifié le quasi quadruplement du temps d'encodage. Tout conseil serait apprécié !
J'ai travaillé en partant du principe que la fréquence d'images de 23,97 était un élément essentiel pour obtenir une qualité décente avec des fichiers de taille inférieure, car 23 images par seconde semble nécessiter beaucoup moins de données que 30 images par seconde, ce qui, je pense, est le cas de la plupart de mes enregistrements TV (j'ai ouvert un enregistrement d'un épisode récent de "Touch" qui me posait problème et l'outil d'information que j'utilisais a indiqué que le fichier WTV était de 60 images par seconde ! Je ne connais pas grand-chose à ce sujet, mais cela me semblait peu probable). Quoi qu'il en soit, après avoir lu ceci, je me pose des questions sur mes réglages car Matt semble être un grand fan de l'utilisation de la fréquence d'images originale. Quelqu'un pourrait-il commenter la différence entre les fréquences d'images en ce qui concerne le calcul de la qualité/taille ? Pour autant que je sache, l'oeil humain ne devrait pas être capable de faire la différence, mais je n'ai jamais vraiment regardé, donc très probablement, je me trompe !
Quoi qu'il en soit, merci pour cet excellent guide, et je suis sûr que j'y reviendrai souvent en essayant d'améliorer mes codages.
Cependant, il semble que vous vous soyez contenté de la qualité que vous obteniez auparavant. Si c'est le cas, vous voudrez peut-être trouver un encodage cible - un moment dont vous seriez encore satisfait - et commencer à augmenter les paramètres jusqu'à ce que vous l'atteigniez.
Pour ce qui est des fréquences d'images, je vais essayer de deviner que les 60 images par seconde que vous avez vues proviennent d'une émission 1080/60i (ce qui est courant pour les émissions en direct aux États-Unis et au Canada, mais pas dans le reste du monde). Souvent, pour les anciennes émissions de télévision, c'est un contenu de 30 images par seconde qui est simplement entrelacé pour obtenir le 60i. Pour les films diffusés en 1080/60i (généralement 24fps par défaut), il s'agit généralement d'un contenu de 30fps qui est ensuite entrelacé pour obtenir le 60i.
Quoi qu'il en soit, je suis certainement favorable au maintien de la fréquence d'image d'origine (après qu'elle ait été désentrelacée et détélécinée par Handbrake). Pour un enregistrement télévisuel, il *devrait* généralement atteindre 30 ou 24 images par seconde à la fin, en supposant que tout se passe comme prévu. Je n'aime pas changer la fréquence d'images pour plusieurs raisons... Tout d'abord, je ne me souviens pas comment HB/x264 fonctionne, mais il doit y avoir soit une baisse soit un mélange des images (probablement la première). L'effet peut aller du bégaiement de l'écran pendant les panoramiques à l'aggravation des scènes à fort mouvement, en passant par... enfin, un certain nombre de choses. Certains contenus peuvent s'en sortir assez bien, mais d'autres peuvent en souffrir.
Deuxièmement, en raison du fonctionnement de x264, cela n'équivaut pas nécessairement à la réduction de taille à laquelle on pourrait s'attendre. Par exemple, en passant de 30 à 24 images par seconde, vous pouvez vous attendre à un fichier dont la taille est de 80%. Mais en réalité, x264 fait un excellent travail de réutilisation des données de trame (c'est à cela que servent toutes ces B-frames et ces cadres de référence ! Vous pouvez bien sûr tester cela pour voir quelle réduction de taille vous obtenez - je peux bien sûr me tromper, mais je soupçonne que la réduction de taille ne sera pas si importante.
Merci beaucoup pour le grand guide
Cela dit, les nuits ont peut-être changé quelque peu - je n'en ai pas attrapé un depuis des siècles, et donc je ne peux pas dire avec certitude d'une façon ou d'une autre. Si toutes les options de l'interface graphique « correspondent » à ce que j'avais écrit, il est probablement sûr de supposer qu'il n'y a pas eu de changements significatifs. IIRC une grande partie du développement vers les nuits dernière fois que j'ai pris un coup d'oeil semblait être orienté vers l'inclusion d'OpenCL (ou était-ce QuickSync d'Intel... ? ma mémoire me manque) qui ne devrait rien rendre obsolète ici, mais pourrait ajouter quelques options supplémentaires dans l'interface graphique que vous voudriez examiner si c'était le cas.
merci beaucoup.. :)
Contrairement à la plupart des autres paramètres, lorsque l'on augmente le nombre de B-frames et de tailles GOP (b+p frames), malgré l'efficacité croissante du codec, on perd en fait un tout petit peu de détails. Les images B et P cumulent des informations de mouvement de compression avec pertes arrondies, donc, perdent des informations d'image fines originales, plus vous en avez alors, et plus le GOP est grand, plus les informations fines seront perdues de manière cumulative. Ceci est particulièrement vrai pour les sources bruyantes/graineuses comme les images haute iso-résolution d'un DSLR. Ils augmentent cependant l'efficacité de la compression globale et donc, sur une taille de fichier réduite, la qualité globale. Cependant, dans un réglage de qualité constante sur un cénario où la qualité globale est plus importante que l'efficacité de la compression, il faut envisager la possibilité d'utiliser un petit nombre d'images b ou même aucune, au détriment de (beaucoup) grandes tailles de fichiers. C'est un scénario courant chez les vidéastes à petit budget et semi-amateurs (comme moi) qui préparent des fichiers "maîtres" à éditer. La caméra GH2 de Panasonic est bien connue pour son micrologiciel piraté où les utilisateurs peuvent affiner les paramètres du codec pour produire des fichiers de la meilleure qualité possible encodés en interne. La plupart des micrologiciels qui recherchent cette meilleure qualité dans les débits binaires limités qu'une carte SD peut gérer, implémentent généralement les tailles GOP les plus basses possibles (comme 2 ou 4 images b/p pour chaque image i).
Il reste encore une question : HB peut utiliser Profils h.264 principale + haut ou l'onglet avancé. Existe-t-il un moyen d'encoder en 10 bits (high 10), au lieu de haut sans perdre l'onglet avancé ? Peut-être un paramètre de console ?
À ma connaissance, HandBrake ne prend pas encore en charge 10 bits. Depuis un certain temps, j'ai regardé les choses, mais la dernière fois que je me souviens, c'est un binaire x264 entièrement différent (qui fonctionne pour d'autres fronts x264 qui appellent simplement la CLI de x264 et peut échanger entre les binaires, mais n'est pas aussi facile à implémenter dans HandBrake car il utilise libx264). Je doute qu'il soit sur la liste des priorités pour les développeurs HB à implémenter car la prise en charge du décodage H.264 10 bits est pratiquement inexistante dans le matériel/périphériques autonomes, et les périphériques ne prendront probablement pas en charge 10 bits tant que le décodage matériel H265 (HEVC) deviendra grand public.
Quelqu'un peut me corriger si je me trompe, mais je soupçonne que vous devrez utiliser un autre frontal qui entonnera votre source directement via le binaire x264 10 bits.
Je vois déjà la différence entre un fichier source en 720p et 8/10 bit. Comme 350 Mo pour 8 bits et 294 Mo pour 10 bits - qualité identique ou même légèrement meilleure. Ce qui est drôle, c'est que mon bon vieux Samsung Galaxy S2 peut le lire très bien, comme tous les appareils androïdes qui ont une vitesse décente. J'ai utilisé ce fichier sur mon téléviseur et il l'a lu aussi, peut-être en mode de repli ? J'ai essayé de suivre cette piste et je suis arrivé à la théorie selon laquelle l'encodeur capte la source habituellement en 8 bits, l'encode avec une précision de 10 bits, puis laisse la sortie en 8 bits. Si j'ai raison, cela voudrait dire que le seul facteur limitant la lecture est la vitesse de l'appareil, et peut-être que certaines options fantaisistes, comme les sous-marins stylisés, doivent être modifiées ou au moins envisagées.
Je sais que je peux utiliser le x264.exe dans la console ou par exemple megui pour encoder en 10 bits, si je change le binaire, mais celui-ci est encore plus compliqué qu'une version console. Cela dit, je ne vais pas perdre des heures à essayer de comprendre quand Handbrake fait un travail décent. À mon humble avis, Handbrake est le plus avancé des encodeurs vraiment gratuits qui existent. D'autres aiment limiter vos options ou pire encore : modifier votre fichier avec des publicités à afficher dans le flux vidéo encodé.
Grand article mais je regarde cela d'une sorte de la direction opposée à savoir fichier maximum et aussi près de l'original que possible. Des configurations suggérées pour cela s'il vous plaît ?
Merci !
Si la taille du fichier n'a pas d'importance du tout, les choses deviennent assez simples :
- Si vous utilisez "Qualité constante", poussez le curseur RF vers la droite (nombre plus petit).
- Si vous utilisez le "débit moyen", augmentez le débit.
...en fait, si vous poussez le curseur RF jusqu'à "0", la nouvelle vidéo sera identique à votre vidéo source (sauf si vous avez activé le débruitage, modifié la résolution, etc.), bien que la taille du fichier soit incroyablement grande - beaucoup plus grande que ne l'était votre source originale, en général.D'un autre côté, si vous voulez que la taille du fichier soit raisonnablement saine, RF:10 donnera généralement quelque chose qui se rapproche de la taille de votre source originale, et à moins que vous ne passiez quelques minutes à examiner attentivement les deux vidéos côte à côte lorsqu'elles sont en pause, vous ne verrez probablement pas beaucoup de différence.
Si vous approchez la valeur RF de ces niveaux, la plupart des options avancées n'auront pas beaucoup d'importance si vous ne vous souciez pas vraiment de la taille du fichier. Vous pouvez régler le drapeau de déblocage sur -1/-1 (film/3D) ou -2/-2 (film granuleux) pour vous assurer que les choses restent nettes à la lecture.
Si vous décidez que la taille importe au moins un peu... une valeur RF de l'ordre de RF18-RF10 vous donnera probablement un résultat assez proche de l'original de toute façon. Sélectionnez "Pas de décimation DCT" juste pour vous assurer que les blocs ne sont pas lâchés. Il vaut probablement aussi la peine de taper manuellement "no-dct-decimate" (sans les guillemets), car cela ne devrait pas avoir d'inconvénient de vitesse aux hauts débits binaires auxquels ces valeurs RF ont tendance à se trouver.