Depuis plusieurs mois, afin d'économiser mon espace disque, j'ai pris
l'habitude de réencoder certaines vidéos (images ISO de DVD / Bluray),
mkv « lourds » en « HDLight ».
Le principe est de conserver la taille de l'image initiale (720p ou
1080p), mais de faire « maigrir » la vidéo en l'encodant en x264
(pendant libre du H264), sans perte visible de qualité par rapport à
l'original.
On parvient aussi à « économiser » en encodant les bandes-son en AAC
plutôt qu'en AC3, plus quelques autres astuces.
Débutant dans cette activité et n'y connaissant rien en audio/vidéo, je
me suis largement appuyé sur ce tutoriel :
https://tutox264.wordpress.com/
appris, et obtenu au fil du temps et de discussions avec d'autres
utilisateurs plus avertis que moi, des résultats plus qu'honorables.
- mes questions (vous pouvez virer tout ce qui est au dessus dans vos
éventuelles réponses, ça allègera :)
J'ai découvert récemment le x265 (pendant libre du H265), qui, j'ai pu
le constater en visionnant des exemples, permet encore de diviser en
moyenne par 2 la taille des vidéos par rapport au x264, toujours sans
perte visible de qualité.
J'ai cherché des informations sur le sujet, mais à part le fait qu'on
semble pouvoir obtenir la même qualité qu'en x264 en divisant le
« bitrate » par 2, je n'ai trouvé aucune autre information, et en tout
cas rien de similaire au didacticiel ci-dessus.
Comme il s'avère que Handbrake 0.10 sait encoder en x265 et que VLC sait
le lire, j'ai bien envie de faire des tests, mais avant de partir un
peu à l'aveugle, si vous avez une expérience en la matière, des liens à
me conseiller (l'anglais ne me dérange pas), je suis preneur :)
ça me semble vraiment bcp pour du H264. avec un i3 double coeur j'encode un film en simple passe H264-720p en environ une heure.
Si tu ne dis pas quels paramètres/presets tu utlises, çe ne dit pas grand chose. x264 a des presets qui vont de "ultrafast" à "veryslow", et il y a au moins un rapport de 1 à 10 (sans doute nettement plus, même) de l'un à l'autre.
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné, la compression peut être plus ou moins chiadée suivant le temps de calcul que l'on accepte d'y consacrer.
Le 12/02/2015 à 15:43, Alf92 a écrit :
pehache :
Alf92 :
ça me semble vraiment bcp pour du H264.
avec un i3 double coeur j'encode un film en simple passe H264-720p en
environ une heure.
Si tu ne dis pas quels paramètres/presets tu utlises, çe ne dit pas
grand chose. x264 a des presets qui vont de "ultrafast" à "veryslow", et
il y a au moins un rapport de 1 à 10 (sans doute nettement plus, même)
de l'un à l'autre.
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné,
la compression peut être plus ou moins chiadée suivant le temps de calcul
que l'on accepte d'y consacrer.
ça me semble vraiment bcp pour du H264. avec un i3 double coeur j'encode un film en simple passe H264-720p en environ une heure.
Si tu ne dis pas quels paramètres/presets tu utlises, çe ne dit pas grand chose. x264 a des presets qui vont de "ultrafast" à "veryslow", et il y a au moins un rapport de 1 à 10 (sans doute nettement plus, même) de l'un à l'autre.
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné, la compression peut être plus ou moins chiadée suivant le temps de calcul que l'on accepte d'y consacrer.
Alf92
pehache :
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné, la compression peut être plus ou moins chiadée suivant le temps de calcul que l'on accepte d'y consacrer.
le temps de calcul consacré est celui que choisit ffmpeg :-) avec cette formule :
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné,
la compression peut être plus ou moins chiadée suivant le temps de calcul
que l'on accepte d'y consacrer.
le temps de calcul consacré est celui que choisit ffmpeg :-)
avec cette formule :
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné, la compression peut être plus ou moins chiadée suivant le temps de calcul que l'on accepte d'y consacrer.
le temps de calcul consacré est celui que choisit ffmpeg :-) avec cette formule :
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné, la compression peut être plus ou moins chiadée suivant le temps de calcul que l'on accepte d'y consacrer.
le temps de calcul consacré est celui que choisit ffmpeg :-) avec cette formule :
Ce que je veux dire, c'est que si l'encodage est trop long chez ED que chez toi, c'est très probablement parce qu'il utilise des settings plus qualitatifs et donc plus coûteux.
Le 13/02/2015 13:24, Alf92 a écrit :
pehache :
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné,
la compression peut être plus ou moins chiadée suivant le temps de calcul
que l'on accepte d'y consacrer.
le temps de calcul consacré est celui que choisit ffmpeg :-)
avec cette formule :
Ce que je veux dire, c'est que si l'encodage est trop long chez ED que
chez toi, c'est très probablement parce qu'il utilise des settings plus
qualitatifs et donc plus coûteux.
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné, la compression peut être plus ou moins chiadée suivant le temps de calcul que l'on accepte d'y consacrer.
le temps de calcul consacré est celui que choisit ffmpeg :-) avec cette formule :
Ce que je veux dire, c'est que si l'encodage est trop long chez ED que chez toi, c'est très probablement parce qu'il utilise des settings plus qualitatifs et donc plus coûteux.
Alf92
pehache :
Alf92 :
pehache :
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné, la compression peut être plus ou moins chiadée suivant le temps de calcul que l'on accepte d'y consacrer.
le temps de calcul consacré est celui que choisit ffmpeg :-) avec cette formule :
Ce que je veux dire, c'est que si l'encodage est trop long chez ED que chez toi, c'est très probablement parce qu'il utilise des settings plus qualitatifs et donc plus coûteux.
c'est possible. reste à savoir si le jeu en vaut la chandelle.
autre piste : j'encode bcp plus vite avec ffmpeg en direct qu'avec ffmpeg à tavers une GUI comme Mediacoder ou Super(C) (à paramètres équivalents biensur). j'ignore la raison de cette différence.
pehache :
Alf92 :
pehache :
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné,
la compression peut être plus ou moins chiadée suivant le temps de calcul
que l'on accepte d'y consacrer.
le temps de calcul consacré est celui que choisit ffmpeg :-)
avec cette formule :
Ce que je veux dire, c'est que si l'encodage est trop long chez ED que
chez toi, c'est très probablement parce qu'il utilise des settings plus
qualitatifs et donc plus coûteux.
c'est possible. reste à savoir si le jeu en vaut la chandelle.
autre piste : j'encode bcp plus vite avec ffmpeg en direct qu'avec
ffmpeg à tavers une GUI comme Mediacoder ou Super(C)
(à paramètres équivalents biensur).
j'ignore la raison de cette différence.
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné, la compression peut être plus ou moins chiadée suivant le temps de calcul que l'on accepte d'y consacrer.
le temps de calcul consacré est celui que choisit ffmpeg :-) avec cette formule :
Ce que je veux dire, c'est que si l'encodage est trop long chez ED que chez toi, c'est très probablement parce qu'il utilise des settings plus qualitatifs et donc plus coûteux.
c'est possible. reste à savoir si le jeu en vaut la chandelle.
autre piste : j'encode bcp plus vite avec ffmpeg en direct qu'avec ffmpeg à tavers une GUI comme Mediacoder ou Super(C) (à paramètres équivalents biensur). j'ignore la raison de cette différence.
pehache
Le 13/02/2015 22:37, Alf92 a écrit :
pehache :
Alf92 :
pehache :
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné, la compression peut être plus ou moins chiadée suivant le temps de calcul que l'on accepte d'y consacrer.
le temps de calcul consacré est celui que choisit ffmpeg :-) avec cette formule :
Ce que je veux dire, c'est que si l'encodage est trop long chez ED que chez toi, c'est très probablement parce qu'il utilise des settings plus qualitatifs et donc plus coûteux.
c'est possible. reste à savoir si le jeu en vaut la chandelle.
Avec x264 au travers de Handbrake, encodage d'une video en résolution DVD, sur 4 coeurs de mon i5 :
autre piste : j'encode bcp plus vite avec ffmpeg en direct qu'avec ffmpeg à tavers une GUI comme Mediacoder ou Super(C) (à paramètres équivalents biensur). j'ignore la raison de cette différence.
j'ai constaté des différences de ce genre parfois, mais sans pouvoir être sûr à 100% de l'équivalence des paramètres utilisés.
Le 13/02/2015 22:37, Alf92 a écrit :
pehache :
Alf92 :
pehache :
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné,
la compression peut être plus ou moins chiadée suivant le temps de calcul
que l'on accepte d'y consacrer.
le temps de calcul consacré est celui que choisit ffmpeg :-)
avec cette formule :
Ce que je veux dire, c'est que si l'encodage est trop long chez ED que
chez toi, c'est très probablement parce qu'il utilise des settings plus
qualitatifs et donc plus coûteux.
c'est possible. reste à savoir si le jeu en vaut la chandelle.
Avec x264 au travers de Handbrake, encodage d'une video en résolution
DVD, sur 4 coeurs de mon i5 :
autre piste : j'encode bcp plus vite avec ffmpeg en direct qu'avec
ffmpeg à tavers une GUI comme Mediacoder ou Super(C)
(à paramètres équivalents biensur).
j'ignore la raison de cette différence.
j'ai constaté des différences de ce genre parfois, mais sans pouvoir
être sûr à 100% de l'équivalence des paramètres utilisés.
Ca ne dit pas les paramètres algorithmiques, ça. Pour un profil donné, la compression peut être plus ou moins chiadée suivant le temps de calcul que l'on accepte d'y consacrer.
le temps de calcul consacré est celui que choisit ffmpeg :-) avec cette formule :
Ce que je veux dire, c'est que si l'encodage est trop long chez ED que chez toi, c'est très probablement parce qu'il utilise des settings plus qualitatifs et donc plus coûteux.
c'est possible. reste à savoir si le jeu en vaut la chandelle.
Avec x264 au travers de Handbrake, encodage d'une video en résolution DVD, sur 4 coeurs de mon i5 :
autre piste : j'encode bcp plus vite avec ffmpeg en direct qu'avec ffmpeg à tavers une GUI comme Mediacoder ou Super(C) (à paramètres équivalents biensur). j'ignore la raison de cette différence.
j'ai constaté des différences de ce genre parfois, mais sans pouvoir être sûr à 100% de l'équivalence des paramètres utilisés.
Olivier B.
On Wed, 11 Feb 2015 20:41:05 +0100, Eric Demeester wrote:
j'ai eu exactement la même démarche que toi, mais à l'envers, lorsque je me suis équipé en vidéoprojecteur HD avec une diagonale de 100 pouces, j'ai du refaire ma vidéothèque avec des versions de 10Go minimum (en deça je vois maintenant la différence de qualité) là ou un peut moins de 4Go suffisait pour le videoprojecteur précédent (au dela je ne voyais pas de différence).
Je suppose que tu es parti des enregistrements « originaux », car de ce que je sais, une fois une compression avec perte réalisée, l'opération inverse est impossible.
absoluement, d'ailleurs si c'était réversible on pourrait d'entré sur-compresser les vidéos pour faire un du 700Mo, et faire la réversion ensuite pour revenir en 10Go (je schématise hein...).
Un copain disposant d'un vidéoprojecteur (je ne connais pas la taille mais c'est forcément plus de 46 pouces) s'est dit bluffé par la qualité d'un film que je lui ai passé (Pride 2014 1080p x264 AC3 5.1 MULTI - 2.63 Go), mais je crois qu'il ne dispose que d'un lecteur de DVD, pas de Bluray, ceci pouvant expliquer cela.
C'était mon cas avec l'ancien vidéoprojecteur 1024*768
parcequ'en deça d'un certain débit on a tellement enlevé de détail qu'on ne voit plus de différence entre le 720 et le 1080, et parfois on visionne tout simplement de trop loin pour faire la différence entre du 1080 et du 720, un test en aveugle peut être nécéssaire pour être réelement objectif dans le choix.
Le débit (bitrate ?), si j'ai bien tout suivi, est justement LE paramètre qui semble important à régler correctement, que ce soit en x264 ou x265, pour maximiser le rapport qualité/poids du résultat final.
pas exactement, le rapport qualité/poids ne dépend plutot d'autres paramètres, le plus courant est le nombre de passes, et il y en a d'autres, pas forcément accessibles car on s'y perd, ou parfois synthétisés avec un curseur lent/rapide, car évidement plus on optimise plus ça coute du temps, pour le H264 sur l'encodeur pro que j'utilise l'optimal coute 5 fois plus de temps que le rapide.
C'est un peu sur le ratio à appliquer que j'espérais des conseils, un peu comme dans le tableau fourni dans le didacticiel consacré au x264 que je citais, mais il n'existe visiblement pas encore l'équivalent pour le x265 ; j'ai peut-être mal cherché.
c'est visiblement trop jeune pour le moment.
Par contre je suis fort interressé par ton retour d'utilisation du 265 car je pense l'utiliser dans le cadre professionel.
Comme répondu à Alf92, je vais faire des tests en me basant à la fois sur mes maigres connaissances en la matière et sur les paramètres qu'il m'a fourni, qu'il me reste à comprendre et à transposer pour les faire avaler à Handbrake.
Quand, en revanche, je ne sais pas, quand j'aurai le temps et j'ai tendance à en manquer. Si je me lance, j'essaierai quelques variations d'encodage sur une séquence de 4 ou 5 minutes, puis je les mettrai à disposition pour vous (collectif) permettre de comparer.
volontier
Merci pour vos réponses à Alf92 et toi, je suis content que le sujet intéresse, et ça prouve que Usenet non seulement n'est pas mort, mais s'avère encore parfois plus efficace que le ouibe :)n
certes :-)
-- pas de turlututu. apres l'@robase
On Wed, 11 Feb 2015 20:41:05 +0100, Eric Demeester
<eric.REMOVETHIS@mailody.org> wrote:
j'ai eu exactement la même démarche que toi, mais à l'envers, lorsque
je me suis équipé en vidéoprojecteur HD avec une diagonale de 100
pouces, j'ai du refaire ma vidéothèque avec des versions de 10Go
minimum (en deça je vois maintenant la différence de qualité) là ou un
peut moins de 4Go suffisait pour le videoprojecteur précédent (au dela
je ne voyais pas de différence).
Je suppose que tu es parti des enregistrements « originaux », car de ce
que je sais, une fois une compression avec perte réalisée, l'opération
inverse est impossible.
absoluement, d'ailleurs si c'était réversible on pourrait d'entré
sur-compresser les vidéos pour faire un du 700Mo, et faire la
réversion ensuite pour revenir en 10Go (je schématise hein...).
Un copain disposant d'un vidéoprojecteur (je ne connais pas la taille
mais c'est forcément plus de 46 pouces) s'est dit bluffé par la qualité
d'un film que je lui ai passé (Pride 2014 1080p x264 AC3 5.1 MULTI -
2.63 Go), mais je crois qu'il ne dispose que d'un lecteur de DVD, pas de
Bluray, ceci pouvant expliquer cela.
C'était mon cas avec l'ancien vidéoprojecteur 1024*768
parcequ'en deça d'un certain débit on a tellement enlevé de détail
qu'on ne voit plus de différence entre le 720 et le 1080, et parfois
on visionne tout simplement de trop loin pour faire la différence
entre du 1080 et du 720, un test en aveugle peut être nécéssaire pour
être réelement objectif dans le choix.
Le débit (bitrate ?), si j'ai bien tout suivi, est justement LE
paramètre qui semble important à régler correctement, que ce soit en
x264 ou x265, pour maximiser le rapport qualité/poids du résultat final.
pas exactement, le rapport qualité/poids ne dépend plutot d'autres
paramètres, le plus courant est le nombre de passes, et il y en a
d'autres, pas forcément accessibles car on s'y perd, ou parfois
synthétisés avec un curseur lent/rapide, car évidement plus on
optimise plus ça coute du temps, pour le H264 sur l'encodeur pro que
j'utilise l'optimal coute 5 fois plus de temps que le rapide.
C'est un peu sur le ratio à appliquer que j'espérais des conseils, un
peu comme dans le tableau fourni dans le didacticiel consacré au x264
que je citais, mais il n'existe visiblement pas encore l'équivalent pour
le x265 ; j'ai peut-être mal cherché.
c'est visiblement trop jeune pour le moment.
Par contre je suis fort interressé par ton retour d'utilisation du 265
car je pense l'utiliser dans le cadre professionel.
Comme répondu à Alf92, je vais faire des tests en me basant à la fois
sur mes maigres connaissances en la matière et sur les paramètres qu'il
m'a fourni, qu'il me reste à comprendre et à transposer pour les faire
avaler à Handbrake.
Quand, en revanche, je ne sais pas, quand j'aurai le temps et j'ai
tendance à en manquer. Si je me lance, j'essaierai quelques variations
d'encodage sur une séquence de 4 ou 5 minutes, puis je les mettrai à
disposition pour vous (collectif) permettre de comparer.
volontier
Merci pour vos réponses à Alf92 et toi, je suis content que le sujet
intéresse, et ça prouve que Usenet non seulement n'est pas mort, mais
s'avère encore parfois plus efficace que le ouibe :)n
On Wed, 11 Feb 2015 20:41:05 +0100, Eric Demeester wrote:
j'ai eu exactement la même démarche que toi, mais à l'envers, lorsque je me suis équipé en vidéoprojecteur HD avec une diagonale de 100 pouces, j'ai du refaire ma vidéothèque avec des versions de 10Go minimum (en deça je vois maintenant la différence de qualité) là ou un peut moins de 4Go suffisait pour le videoprojecteur précédent (au dela je ne voyais pas de différence).
Je suppose que tu es parti des enregistrements « originaux », car de ce que je sais, une fois une compression avec perte réalisée, l'opération inverse est impossible.
absoluement, d'ailleurs si c'était réversible on pourrait d'entré sur-compresser les vidéos pour faire un du 700Mo, et faire la réversion ensuite pour revenir en 10Go (je schématise hein...).
Un copain disposant d'un vidéoprojecteur (je ne connais pas la taille mais c'est forcément plus de 46 pouces) s'est dit bluffé par la qualité d'un film que je lui ai passé (Pride 2014 1080p x264 AC3 5.1 MULTI - 2.63 Go), mais je crois qu'il ne dispose que d'un lecteur de DVD, pas de Bluray, ceci pouvant expliquer cela.
C'était mon cas avec l'ancien vidéoprojecteur 1024*768
parcequ'en deça d'un certain débit on a tellement enlevé de détail qu'on ne voit plus de différence entre le 720 et le 1080, et parfois on visionne tout simplement de trop loin pour faire la différence entre du 1080 et du 720, un test en aveugle peut être nécéssaire pour être réelement objectif dans le choix.
Le débit (bitrate ?), si j'ai bien tout suivi, est justement LE paramètre qui semble important à régler correctement, que ce soit en x264 ou x265, pour maximiser le rapport qualité/poids du résultat final.
pas exactement, le rapport qualité/poids ne dépend plutot d'autres paramètres, le plus courant est le nombre de passes, et il y en a d'autres, pas forcément accessibles car on s'y perd, ou parfois synthétisés avec un curseur lent/rapide, car évidement plus on optimise plus ça coute du temps, pour le H264 sur l'encodeur pro que j'utilise l'optimal coute 5 fois plus de temps que le rapide.
C'est un peu sur le ratio à appliquer que j'espérais des conseils, un peu comme dans le tableau fourni dans le didacticiel consacré au x264 que je citais, mais il n'existe visiblement pas encore l'équivalent pour le x265 ; j'ai peut-être mal cherché.
c'est visiblement trop jeune pour le moment.
Par contre je suis fort interressé par ton retour d'utilisation du 265 car je pense l'utiliser dans le cadre professionel.
Comme répondu à Alf92, je vais faire des tests en me basant à la fois sur mes maigres connaissances en la matière et sur les paramètres qu'il m'a fourni, qu'il me reste à comprendre et à transposer pour les faire avaler à Handbrake.
Quand, en revanche, je ne sais pas, quand j'aurai le temps et j'ai tendance à en manquer. Si je me lance, j'essaierai quelques variations d'encodage sur une séquence de 4 ou 5 minutes, puis je les mettrai à disposition pour vous (collectif) permettre de comparer.
volontier
Merci pour vos réponses à Alf92 et toi, je suis content que le sujet intéresse, et ça prouve que Usenet non seulement n'est pas mort, mais s'avère encore parfois plus efficace que le ouibe :)n
certes :-)
-- pas de turlututu. apres l'@robase
michel
Le Tue, 10 Feb 2015 20:29:15 +0100, Eric Demeester a écrit :
Bonjour,
- contexte :
J'utilise Handbrake 0.10 sous Windows 7 ultimate.
Depuis plusieurs mois, afin d'économiser mon espace disque, j'ai pris l'habitude de réencoder certaines vidéos (images ISO de DVD / Bluray), mkv « lourds » en « HDLight ».
Le principe est de conserver la taille de l'image initiale (720p ou 1080p), mais de faire « maigrir » la vidéo en l'encodant en x264 (pendant libre du H264), sans perte visible de qualité par rapport à l'original.
On parvient aussi à « économiser » en encodant les bandes-son en AAC plutôt qu'en AC3, plus quelques autres astuces.
Débutant dans cette activité et n'y connaissant rien en audio/vidéo, je me suis largement appuyé sur ce tutoriel : https://tutox264.wordpress.com/
appris, et obtenu au fil du temps et de discussions avec d'autres utilisateurs plus avertis que moi, des résultats plus qu'honorables.
- mes questions (vous pouvez virer tout ce qui est au dessus dans vos éventuelles réponses, ça allègera :)
J'ai découvert récemment le x265 (pendant libre du H265), qui, j'ai pu le constater en visionnant des exemples, permet encore de diviser en moyenne par 2 la taille des vidéos par rapport au x264, toujours sans perte visible de qualité.
J'ai cherché des informations sur le sujet, mais à part le fait qu'on semble pouvoir obtenir la même qualité qu'en x264 en divisant le « bitrate » par 2, je n'ai trouvé aucune autre information, et en tout cas rien de similaire au didacticiel ci-dessus.
Comme il s'avère que Handbrake 0.10 sait encoder en x265 et que VLC sait le lire, j'ai bien envie de faire des tests, mais avant de partir un peu à l'aveugle, si vous avez une expérience en la matière, des liens à me conseiller (l'anglais ne me dérange pas), je suis preneur :)
Par avance merci pour vos lumières.
Le Tue, 10 Feb 2015 20:29:15 +0100, Eric Demeester
<eric.REMOVETHIS@mailody.org> a écrit :
Bonjour,
- contexte :
J'utilise Handbrake 0.10 sous Windows 7 ultimate.
Depuis plusieurs mois, afin d'économiser mon espace disque, j'ai pris
l'habitude de réencoder certaines vidéos (images ISO de DVD / Bluray),
mkv « lourds » en « HDLight ».
Le principe est de conserver la taille de l'image initiale (720p ou
1080p), mais de faire « maigrir » la vidéo en l'encodant en x264
(pendant libre du H264), sans perte visible de qualité par rapport à
l'original.
On parvient aussi à « économiser » en encodant les bandes-son en AAC
plutôt qu'en AC3, plus quelques autres astuces.
Débutant dans cette activité et n'y connaissant rien en audio/vidéo, je
me suis largement appuyé sur ce tutoriel :
https://tutox264.wordpress.com/
appris, et obtenu au fil du temps et de discussions avec d'autres
utilisateurs plus avertis que moi, des résultats plus qu'honorables.
- mes questions (vous pouvez virer tout ce qui est au dessus dans vos
éventuelles réponses, ça allègera :)
J'ai découvert récemment le x265 (pendant libre du H265), qui, j'ai pu
le constater en visionnant des exemples, permet encore de diviser en
moyenne par 2 la taille des vidéos par rapport au x264, toujours sans
perte visible de qualité.
J'ai cherché des informations sur le sujet, mais à part le fait qu'on
semble pouvoir obtenir la même qualité qu'en x264 en divisant le
« bitrate » par 2, je n'ai trouvé aucune autre information, et en tout
cas rien de similaire au didacticiel ci-dessus.
Comme il s'avère que Handbrake 0.10 sait encoder en x265 et que VLC sait
le lire, j'ai bien envie de faire des tests, mais avant de partir un
peu à l'aveugle, si vous avez une expérience en la matière, des liens à
me conseiller (l'anglais ne me dérange pas), je suis preneur :)
Le Tue, 10 Feb 2015 20:29:15 +0100, Eric Demeester a écrit :
Bonjour,
- contexte :
J'utilise Handbrake 0.10 sous Windows 7 ultimate.
Depuis plusieurs mois, afin d'économiser mon espace disque, j'ai pris l'habitude de réencoder certaines vidéos (images ISO de DVD / Bluray), mkv « lourds » en « HDLight ».
Le principe est de conserver la taille de l'image initiale (720p ou 1080p), mais de faire « maigrir » la vidéo en l'encodant en x264 (pendant libre du H264), sans perte visible de qualité par rapport à l'original.
On parvient aussi à « économiser » en encodant les bandes-son en AAC plutôt qu'en AC3, plus quelques autres astuces.
Débutant dans cette activité et n'y connaissant rien en audio/vidéo, je me suis largement appuyé sur ce tutoriel : https://tutox264.wordpress.com/
appris, et obtenu au fil du temps et de discussions avec d'autres utilisateurs plus avertis que moi, des résultats plus qu'honorables.
- mes questions (vous pouvez virer tout ce qui est au dessus dans vos éventuelles réponses, ça allègera :)
J'ai découvert récemment le x265 (pendant libre du H265), qui, j'ai pu le constater en visionnant des exemples, permet encore de diviser en moyenne par 2 la taille des vidéos par rapport au x264, toujours sans perte visible de qualité.
J'ai cherché des informations sur le sujet, mais à part le fait qu'on semble pouvoir obtenir la même qualité qu'en x264 en divisant le « bitrate » par 2, je n'ai trouvé aucune autre information, et en tout cas rien de similaire au didacticiel ci-dessus.
Comme il s'avère que Handbrake 0.10 sait encoder en x265 et que VLC sait le lire, j'ai bien envie de faire des tests, mais avant de partir un peu à l'aveugle, si vous avez une expérience en la matière, des liens à me conseiller (l'anglais ne me dérange pas), je suis preneur :)
Par avance merci pour vos lumières.
Thierry M.
Olivier B. a couché sur son écran :
minimum (en deça je vois maintenant la différence de qualité) là ou un peut moins de 4Go suffisait pour le videoprojecteur précédent (au dela je ne voyais pas de différence).
t'as une bonne vue, sur écran de 4m de large, sur un epson 6020 encodé correctement, un 2.35:1 sans les bandes noires donc, avec un indice qualité de 0.15 (bit/pixel/frame) ça nous donne 2.5 Go de l'heure - avec son en AC3 6+1 / 640 ce qui est déjà beaucoup: inutile de s'empêtrer avec du DTS on n'est pas des chauves souris (il y'en a qui "entendent" des différences entre un cable d'enceinte tressé dans le sens des aiguilles d'une montre et en sens inverse, alors ceux la vont raler pour sur)
et monter en bitrate au déla (donc entre 5000 et 6000 dans le cas présent) n'apporte rien
--- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com
Olivier B. a couché sur son écran :
minimum (en deça je vois maintenant la différence de qualité) là ou un
peut moins de 4Go suffisait pour le videoprojecteur précédent (au dela
je ne voyais pas de différence).
t'as une bonne vue, sur écran de 4m de large, sur un epson 6020 encodé
correctement, un 2.35:1 sans les bandes noires donc, avec un indice
qualité de 0.15 (bit/pixel/frame) ça nous donne 2.5 Go de l'heure -
avec son en AC3 6+1 / 640 ce qui est déjà beaucoup: inutile de
s'empêtrer avec du DTS on n'est pas des chauves souris (il y'en a qui
"entendent" des différences entre un cable d'enceinte tressé dans le
sens des aiguilles d'une montre et en sens inverse, alors ceux la vont
raler pour sur)
et monter en bitrate au déla (donc entre 5000 et 6000 dans le cas
présent) n'apporte rien
minimum (en deça je vois maintenant la différence de qualité) là ou un peut moins de 4Go suffisait pour le videoprojecteur précédent (au dela je ne voyais pas de différence).
t'as une bonne vue, sur écran de 4m de large, sur un epson 6020 encodé correctement, un 2.35:1 sans les bandes noires donc, avec un indice qualité de 0.15 (bit/pixel/frame) ça nous donne 2.5 Go de l'heure - avec son en AC3 6+1 / 640 ce qui est déjà beaucoup: inutile de s'empêtrer avec du DTS on n'est pas des chauves souris (il y'en a qui "entendent" des différences entre un cable d'enceinte tressé dans le sens des aiguilles d'une montre et en sens inverse, alors ceux la vont raler pour sur)
et monter en bitrate au déla (donc entre 5000 et 6000 dans le cas présent) n'apporte rien
--- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com
olivier B.
Le 17/02/2015 à 19:22, Thierry M . a écrit :
Olivier B. a couché sur son écran :
minimum (en deça je vois maintenant la différence de qualité) là ou un peut moins de 4Go suffisait pour le videoprojecteur précédent (au dela je ne voyais pas de différence).
t'as une bonne vue
je te confirme, bien qu'avec l'age elle a commencé à baisser.
, sur écran de 4m de large, sur un epson 6020 encodé correctement, un 2.35:1 sans les bandes noires donc, avec un indice qualité de 0.15 (bit/pixel/frame) ça nous donne 2.5 Go de l'heure -
cette valeur d 'indice m'est inconnue
avec son en AC3 6+1 / 640 ce qui est déjà beaucoup: inutile de s'empêtrer avec du DTS
aussi bien je suis très exigeant coté vidéo (travers d'ancien ingé vision), que coté audio je me contente de peux, d'ailleurs pour le moment je suis juste en stéréo.
on n'est pas des chauves souris (il y'en a qui "entendent" des différences entre un cable d'enceinte tressé dans le sens des aiguilles d'une montre et en sens inverse, alors ceux la vont raler pour sur)
il ont le droit de râler si le test en aveugle est concluant, mais là je doute ;-) Quand j'étais jeune j'entendais parfaitement siffler les tv tube (donc
15k), aujourd’hui ce n'est plus le cas :-/
et monter en bitrate au déla (donc entre 5000 et 6000 dans le cas présent) n'apporte rien
Tu ne peux pas dire qu'il apporte rien, tu peux dire que tu ne vois pas la différence, ou qu'une majorité de la population ne la voit pas, mais tu dois aussi faire avec ceux qui voient la différence, et donc accepter cette dernière, même si elle n'est pas la norme. Perso, ces débits là, à part pour un dessin animé...
Le 17/02/2015 à 19:22, Thierry M . a écrit :
Olivier B. a couché sur son écran :
minimum (en deça je vois maintenant la différence de qualité) là ou un
peut moins de 4Go suffisait pour le videoprojecteur précédent (au dela
je ne voyais pas de différence).
t'as une bonne vue
je te confirme, bien qu'avec l'age elle a commencé à baisser.
, sur écran de 4m de large, sur un epson 6020 encodé
correctement, un 2.35:1 sans les bandes noires donc, avec un indice
qualité de 0.15 (bit/pixel/frame) ça nous donne 2.5 Go de l'heure -
cette valeur d 'indice m'est inconnue
avec son en AC3 6+1 / 640 ce qui est déjà beaucoup: inutile de
s'empêtrer avec du DTS
aussi bien je suis très exigeant coté vidéo (travers d'ancien ingé
vision), que coté audio je me contente de peux, d'ailleurs pour le moment
je suis juste en stéréo.
on n'est pas des chauves souris (il y'en a qui
"entendent" des différences entre un cable d'enceinte tressé dans le
sens des aiguilles d'une montre et en sens inverse, alors ceux la vont
raler pour sur)
il ont le droit de râler si le test en aveugle est concluant, mais là je
doute ;-)
Quand j'étais jeune j'entendais parfaitement siffler les tv tube (donc
15k), aujourd’hui ce n'est plus le cas :-/
et monter en bitrate au déla (donc entre 5000 et 6000 dans le cas
présent) n'apporte rien
Tu ne peux pas dire qu'il apporte rien, tu peux dire que tu ne vois pas la
différence, ou qu'une majorité de la population ne la voit pas, mais tu
dois aussi faire avec ceux qui voient la différence, et donc accepter
cette dernière, même si elle n'est pas la norme.
Perso, ces débits là, à part pour un dessin animé...
minimum (en deça je vois maintenant la différence de qualité) là ou un peut moins de 4Go suffisait pour le videoprojecteur précédent (au dela je ne voyais pas de différence).
t'as une bonne vue
je te confirme, bien qu'avec l'age elle a commencé à baisser.
, sur écran de 4m de large, sur un epson 6020 encodé correctement, un 2.35:1 sans les bandes noires donc, avec un indice qualité de 0.15 (bit/pixel/frame) ça nous donne 2.5 Go de l'heure -
cette valeur d 'indice m'est inconnue
avec son en AC3 6+1 / 640 ce qui est déjà beaucoup: inutile de s'empêtrer avec du DTS
aussi bien je suis très exigeant coté vidéo (travers d'ancien ingé vision), que coté audio je me contente de peux, d'ailleurs pour le moment je suis juste en stéréo.
on n'est pas des chauves souris (il y'en a qui "entendent" des différences entre un cable d'enceinte tressé dans le sens des aiguilles d'une montre et en sens inverse, alors ceux la vont raler pour sur)
il ont le droit de râler si le test en aveugle est concluant, mais là je doute ;-) Quand j'étais jeune j'entendais parfaitement siffler les tv tube (donc
15k), aujourd’hui ce n'est plus le cas :-/
et monter en bitrate au déla (donc entre 5000 et 6000 dans le cas présent) n'apporte rien
Tu ne peux pas dire qu'il apporte rien, tu peux dire que tu ne vois pas la différence, ou qu'une majorité de la population ne la voit pas, mais tu dois aussi faire avec ceux qui voient la différence, et donc accepter cette dernière, même si elle n'est pas la norme. Perso, ces débits là, à part pour un dessin animé...
Eric Demeester
Bonjour,
pehache (Fri, 13 Feb 2015 21:47:36 +0100 - fr.rec.son-image.video.realisation) :
Un passage rapide, j'ai lu et précieusement archivé la discussion, mais je n'ai pas le temps de faire de tests x265 en ce moment, d'où mon silence.
Juste sur ce point :
Ce que je veux dire, c'est que si l'encodage est trop long chez ED que chez toi, c'est très probablement parce qu'il utilise des settings plus qualitatifs et donc plus coûteux.
J'ai dit « très long », pas « trop long », et ça dépend beaucoup du ou des fichiers d'origine. Ripper un DVD 720p en mpeg2 est bien plus rapide que de faire maigrir un gros MKV, et encore, tout dépend de la manière dont il a été encodé.
J'utilise effectivement a priori des réglages coûteux en CPU, à savoir ceux conseillés dans le didacticiel que je citais : https://tutox264.wordpress.com/
plus un encodage en deux passes, la première « turbo » ou non en fonction de mon humeur.
Si ça intéresse, plutôt que de longs discours, j'ai fait des copies d'écran des réglages de Handbrake lors de l'encodage d'un film en 1080p à partir d'un mkv original de 9 Go :
Je suppose qu'au delà des deux passes, la complexité, et donc le temps de traitement, résident dans les paramètres surlignés en bleu dans ce dernier onglet. Paramètres auxquels je ne comprends pas grand-chose, sauf qu'on m'a dit que c'était bien et que les résultats obtenus semblent le confirmer.
J'obtiens un fichier de 2.33 Go sans perte de qualité visible (pour moi sur mon 27" 1920 x 1080, je précise à nouveau mais ça passe impeccable sur une télé 45").
D'après mes souvenirs, ça a pris 4 heures, parce que le MKV original n'était pas très compressé, d'où le gain de taille qui peut paraitre impressionnant.
[*] j'ai oublié de cocher 'default' pour les sous-titres en français :)
Bonjour,
pehache (Fri, 13 Feb 2015 21:47:36 +0100 -
fr.rec.son-image.video.realisation) :
Un passage rapide, j'ai lu et précieusement archivé la discussion, mais
je n'ai pas le temps de faire de tests x265 en ce moment, d'où mon
silence.
Juste sur ce point :
Ce que je veux dire, c'est que si l'encodage est trop long chez ED que
chez toi, c'est très probablement parce qu'il utilise des settings plus
qualitatifs et donc plus coûteux.
J'ai dit « très long », pas « trop long », et ça dépend beaucoup du ou
des fichiers d'origine. Ripper un DVD 720p en mpeg2 est bien plus rapide
que de faire maigrir un gros MKV, et encore, tout dépend de la manière
dont il a été encodé.
J'utilise effectivement a priori des réglages coûteux en CPU, à savoir
ceux conseillés dans le didacticiel que je citais :
https://tutox264.wordpress.com/
plus un encodage en deux passes, la première « turbo » ou non en
fonction de mon humeur.
Si ça intéresse, plutôt que de longs discours, j'ai fait des copies
d'écran des réglages de Handbrake lors de l'encodage d'un film en 1080p
à partir d'un mkv original de 9 Go :
Je suppose qu'au delà des deux passes, la complexité, et donc le temps
de traitement, résident dans les paramètres surlignés en bleu dans ce
dernier onglet. Paramètres auxquels je ne comprends pas grand-chose,
sauf qu'on m'a dit que c'était bien et que les résultats obtenus
semblent le confirmer.
J'obtiens un fichier de 2.33 Go sans perte de qualité visible (pour moi
sur mon 27" 1920 x 1080, je précise à nouveau mais ça passe impeccable
sur une télé 45").
D'après mes souvenirs, ça a pris 4 heures, parce que le MKV original
n'était pas très compressé, d'où le gain de taille qui peut paraitre
impressionnant.
[*] j'ai oublié de cocher 'default' pour les sous-titres en français :)
pehache (Fri, 13 Feb 2015 21:47:36 +0100 - fr.rec.son-image.video.realisation) :
Un passage rapide, j'ai lu et précieusement archivé la discussion, mais je n'ai pas le temps de faire de tests x265 en ce moment, d'où mon silence.
Juste sur ce point :
Ce que je veux dire, c'est que si l'encodage est trop long chez ED que chez toi, c'est très probablement parce qu'il utilise des settings plus qualitatifs et donc plus coûteux.
J'ai dit « très long », pas « trop long », et ça dépend beaucoup du ou des fichiers d'origine. Ripper un DVD 720p en mpeg2 est bien plus rapide que de faire maigrir un gros MKV, et encore, tout dépend de la manière dont il a été encodé.
J'utilise effectivement a priori des réglages coûteux en CPU, à savoir ceux conseillés dans le didacticiel que je citais : https://tutox264.wordpress.com/
plus un encodage en deux passes, la première « turbo » ou non en fonction de mon humeur.
Si ça intéresse, plutôt que de longs discours, j'ai fait des copies d'écran des réglages de Handbrake lors de l'encodage d'un film en 1080p à partir d'un mkv original de 9 Go :
Je suppose qu'au delà des deux passes, la complexité, et donc le temps de traitement, résident dans les paramètres surlignés en bleu dans ce dernier onglet. Paramètres auxquels je ne comprends pas grand-chose, sauf qu'on m'a dit que c'était bien et que les résultats obtenus semblent le confirmer.
J'obtiens un fichier de 2.33 Go sans perte de qualité visible (pour moi sur mon 27" 1920 x 1080, je précise à nouveau mais ça passe impeccable sur une télé 45").
D'après mes souvenirs, ça a pris 4 heures, parce que le MKV original n'était pas très compressé, d'où le gain de taille qui peut paraitre impressionnant.
[*] j'ai oublié de cocher 'default' pour les sous-titres en français :)
