3 points par GN⁺ 2023-11-21 | 1 commentaires | Partager sur WhatsApp

Guide de mise à niveau vers HandBrake 1.7.0

  • Avant de mettre à jour HandBrake, vérifiez qu’aucun encodage n’est en attente et il est recommandé de sauvegarder vos préréglages personnalisés ainsi que les préférences de l’application.
  • Les utilisateurs de Windows doivent impérativement installer la version 6.0.x de Microsoft .NET Desktop Runtime. Même si .NET 7 est installé, l’installation de .NET 6 reste nécessaire.

Notes de version de HandBrake 1.7.0

  • La liste complète des améliorations et des corrections de bugs est disponible dans les notes de version sur GitHub.

Signalement de problèmes et envoi de retours

  • Si vous découvrez un bug reproductible ou un problème, ou si vous souhaitez faire un retour, il est demandé de le signaler via l’outil de suivi des issues GitHub.
  • Il est également possible de contacter l’équipe via le canal de support communautaire IRC.
  • L’application HandBrake est développée sur le temps libre d’une petite équipe de bénévoles ; une réponse immédiate peut donc être difficile, mais tous les retours sont lus et les commentaires constructifs sont les bienvenus.

Remerciements et contributions

  • Certaines fonctionnalités de cette version ont été fournies par des utilisateurs ou des entreprises soutenant HandBrake, et les traductions sont rendues possibles grâce à la participation active d’une communauté mondiale de bénévoles.
  • Il est recommandé à celles et ceux qui souhaitent contribuer sans encore l’avoir fait de lire le guide de contribution.
  • Il existe de nombreuses façons de contribuer, même sans être développeur.

L’avis de GN⁺

  • La mise à niveau vers HandBrake 1.7.0 nécessite une sauvegarde des paramètres personnalisés et l’installation d’un nouveau runtime .NET.
  • Cette mise à jour inclut des améliorations et des corrections de bugs, et s’inscrit dans un projet communautaire alimenté par les contributions d’utilisateurs et d’entreprises.
  • Cet article annonce la sortie d’une nouvelle version de HandBrake, un transcodeur vidéo open source, et il est intéressant par l’importance qu’il accorde à la collaboration et aux contributions au sein de la communauté technique.

1 commentaires

 
GN⁺ 2023-11-21
Avis sur Hacker News
  • Si vous regrettez que HandBrake ne calcule pas automatiquement le reste quand on indique la taille finale du fichier, le calcul lui-même est simple
    Débit moyen [kbps] = taille cible [kilobits] ÷ durée [secondes]
    Par exemple, pour faire tenir un fichier de 2 h 48 min sous les 5 Go, 2 h 48 min font 10 080 secondes et 5 Go font 40 000 000 kb ; le débit moyen est donc 40 000 000 kb ÷ 10 080 s = 3 968 kbps
    Si l’audio est à 256 kbps, le débit vidéo moyen doit donc être au plus de 3 712 kbps

    • Ce calcul n’est correct que pour un encodage à débit constant
      En général, on encode à qualité constante, et la taille de sortie dépend fortement de la vidéo d’entrée
      J’ai donc créé un wrapper Python qui analyse la sortie de HandBrakeCLI et estime la taille finale à partir du pourcentage terminé et de la taille actuelle du fichier de sortie
      Si le fichier risque d’être trop gros, ou si la qualité de sortie est trop mauvaise et qu’il faut augmenter le facteur de qualité, on peut arrêter tôt
  • Ça me fait plaisir que le message « Put that cocktail down. Your HandBrake encode is complete! » soit toujours là après toutes ces années

    • J’aime ce genre de détail. Ça donne l’impression de remettre un peu d’âme, ou de fantôme, dans la machine
  • Avant, même après le passage du pipeline de HandBrake en 10 bits, pas mal de filtres restaient en 8 bits ; il était donc facile de dégrader la qualité d’encodage sans s’en rendre compte en choisissant le mauvais filtre
    Aujourd’hui, la plupart des filtres, peut-être même tous, semblent prendre en charge le 10 bits
    Par ailleurs, à cause de la licence de FDK-AAC, il n’était pas possible de l’inclure, et le codec AAC de la version publiée était moins bon ; mais j’ai entendu dire qu’il n’était plus aussi mauvais qu’avant
    Je me demande s’il reste de gros pièges dans la version actuelle de cette excellente app

    • Depuis la 1.6, tous les filtres prennent en charge les hautes profondeurs de bits. La qualité de l’encodeur AAC est désormais plutôt correcte, et sur macOS on peut utiliser l’encodeur AAC d’Apple, donc ce n’est pas un problème
      Quoi qu’il en soit, le problème principal est le manque de personnes. Beaucoup de fonctionnalités qui seraient bienvenues sont bloquées au paradis des fonctionnalités
      Comme dans à peu près tous les projets open source
  • Ces jours-ci, je demande à ChatGPT de me donner des commandes de terminal ffmpeg
    C’est beaucoup plus rapide que n’importe quelle app et on peut ajuster exactement comme on veut

    • Il suffit de cliquer sur le fichier, de choisir « open with handbrake », puis de cliquer sur « convert ». J’ai du mal à imaginer plus rapide
    • Dire qu’on peut « ajuster exactement comme on veut » signifie en réalité comprendre les options de ffmpeg et leurs interactions
      Faire des essais-erreurs ou lire les pages de manuel n’est pas vraiment « beaucoup plus rapide » que choisir un preset dans HandBrake, cocher des cases ou déplacer un curseur
    • Mais ChatGPT ne connaît pas le format du fichier. Sauf si vous mettez aussi la sortie de ffprobe dans le prompt
      Si la source est un DVD, il faut tenir compte de beaucoup de choses : problèmes de ratio d’image, désentrelacement, gestion des sous-titres, etc.
    • ffmpeg est vraiment le seul programme auquel j’aimerais voir appliquer du no-code visuel
      Maintenant, je me surprends à chercher une option de type --help, comme --chatgpt, pour pouvoir explorer n’importe quelle page de manuel
    • C’est plus rapide, mais aussi plus sujet aux erreurs. L’app permet aussi d’ajuster comme on veut, donc sur ce point c’est match nul
  • La liste des fonctionnalités est intéressante. J’attends surtout avec impatience les améliorations de performances pour les architectures arm64 / aarch64 / Apple Silicon, le décodage HEVC plus rapide grâce au dernier FFmpeg, le filtre bwdif 30 % plus rapide, les nouvelles optimisations en assembleur de SVT-AV1 offrant jusqu’à 4× de performances, ainsi que la suppression de copies de frames inutiles pour améliorer l’efficacité mémoire et la vitesse de conversion vidéo

  • Mon seul reproche à HandBrakeCLI, c’est qu’il ne peut pas encoder une entrée passée via stdin
    FFmpeg le permet, et je pensais que HandBrake utilisait FFmpeg en interne

    • HandBrake utilise libavformat, libavcodec et libavfilter, qui font partie des bibliothèques FFmpeg
      Mais cela reste une application complètement différente. Les décodeurs, certains démuxeurs et certains filtres sont les mêmes, mais la manière de les relier n’a rien à voir avec l’application en ligne de commande FFmpeg
    • Les pipes nommés, ça ne marche pas ?
      Ou peut-être un tour de magie Bash du genre handbrake-cli -i <(cat video-file.mp4) ?
      Je n’ai jamais utilisé HandBrakeCLI, seulement l’interface graphique, donc je ne sais pas vraiment
    • Ce qui m’a surpris quand j’ai découvert HandBrake, c’est qu’au lieu de simplement utiliser FFmpeg, il fabrique lui-même beaucoup de composants
      Bien sûr, il utilise largement les bibliothèques FFmpeg pour d’autres parties
      C’est l’un des rares transcodeurs qui ne se limite pas à être un wrapper autour de FFmpeg, ce qui est à la fois une force et une faiblesse
  • Quelqu’un peut-il expliquer simplement pourquoi HandBrake dit ne pas pouvoir implémenter une option de taille de fichier cible ?
    Les apps Android de compression vidéo le font plutôt bien, mais dans la demande de fonctionnalité correspondante sur le GitHub de HandBrake, l’un des mainteneurs disait que c’était difficile en pratique

    • C’est littéralement une fonctionnalité fournie par tous les encodeurs sous-jacents. C’est possible même avec des chaînes de filtres ffmpeg/vapoursynth exotiques
      Je n’arrive donc pas à imaginer pourquoi ce serait impossible
      Sous Windows, je recommanderais simplement Staxrip : https://github.com/staxrip/staxrip
      Il existe aussi une app équivalente sous Linux basée sur vapoursynth, mais je ne me souviens plus de son nom
      Ou alors c’est peut-être l’une des interfaces graphiques pour AV1an. Tous ces outils prennent en charge une taille de fichier cible et proposent beaucoup plus de fonctionnalités que HandBrake
  • Pourquoi n’y a-t-il toujours pas une fonction simple du type « limiter la vidéo X à une taille de fichier Y » ?
    Je veux juste un fichier vidéo de 5 Go, mais HandBrake semble considérer que je me soucie de l’un de ses 50 presets Vimeo dont je ne sais pas grand-chose

    • Je ne comprends pas pourquoi vous voulez précisément une limite de 5 Go. Vous avez des tiroirs remplis de clés USB de 5 Go à remplir ?
      5 Go, c’est nettement plus qu’un CD, et trop petit pour un Blu-ray, sauf si votre but est d’en mettre exactement 10 sur un Blu-ray
      Votre cas d’usage paraît aussi étrange au reste du monde que les presets Vimeo vous paraissent étranges
  • Sauf lorsqu’il s’agit de traiter des vidéos HDR, je préfère toujours ffmpeg à HandBrake
    Je n’ai pas trouvé de commande ffmpeg appropriée pour copier les métadonnées HDR de la source d’entrée vers la sortie
    La dernière fois que j’ai vérifié, ce n’était pas possible, et il fallait extraire manuellement les métadonnées avec un outil comme MediaInfo, puis passer chaque valeur comme argument à ffmpeg
    Quelqu’un sait si c’est toujours le cas ?

    • As-tu essayé -movflags avec use_metadata_tags ?
      ffmpeg -i $input_file -movflags use_metadata_tags -crf 22 $output_file
      Source : https://video.stackexchange.com/a/26076
    • Oui, il semble qu’il faille encore extraire les métadonnées soi-même et les renseigner manuellement
      Pour détailler un peu, les deux standards vidéo HDR courants sont Dolby Vision et HDR10. Tous deux nécessitent une prise en charge spécifique côté encodeur, ce qui relève davantage de libx265 que de libavformat/ffmpeg
      Heureusement, si la vidéo source est en HDR10, on peut extraire la fonction de transfert et le tone mapping, qui ne changent pas globalement, et les appliquer directement aux métadonnées de sortie. FFmpeg peut transmettre ces valeurs à l’encodeur, mais il ne les copie pas par défaut de la source vers la cible
      Un article expliquant la méthode se trouve ici : https://codecalamity.com/encoding-uhd-4k-hdr10-videos-with-f...
      J’ai déjà réencodé une vidéo encodée en HDR10 dans un autre format tout en conservant les métadonnées, et la commande finale restée dans mon historique shell ressemblait à peu près à ffmpeg -i Movie-with-HDR.mkv -c:v libx265 -map_metadata:s:0 0:s:0 -map_metadata:g:0 0 -x265-params crf=21:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)":max-cll=1000,240 Movie-output.mkv
      Ici, les paramètres master-display et max-cll correspondent à la fonction de transfert des couleurs qu’il a fallu extraire de la première vidéo avec un autre outil. Ces réglages figurent dans la documentation des paramètres de libx265 : https://x265.readthedocs.io/en/master/cli.html
      Dolby Vision est plus compliqué. Les métadonnées étant dynamiques, je ne sais pas exactement comment les récupérer depuis la source, mais il est possible de les fournir à libx265 via des arguments de ligne de commande. Malheureusement, elles ne sont exposées qu’en ligne de commande et pas dans l’API, donc ffmpeg ne peut pas encore s’en charger à votre place
      Pour référence, le processus d’extraction de la fonction de transfert et de passage à ffmpeg est décrit dans https://medium.com/@yllanos/how-to-encode-a-4k-hdr-movie-usi... et https://codecalamity.com/encoding-uhd-4k-hdr10-videos-with-f..., et un billet où plusieurs personnes ont synthétisé la même opération se trouve ici : https://www.reddit.com/r/ffmpeg/comments/g3uucr/how_do_i_enc...
      Pour la conversion de Dolby Vision vers HDR10, ainsi que les sujets liés à HLG et PQ, voir https://www.reddit.com/r/ffmpeg/comments/nkxbay/how_to_conve..., et pour les subtilités de Dolby Vision : https://www.reddit.com/r/ffmpeg/comments/a32yv4/deleted_by_u...
  • Le lien vers la release elle-même aurait sans doute été meilleur
    Il contient le journal des modifications que la plupart des gens voudront probablement consulter
    https://github.com/HandBrake/HandBrake/releases/tag/1.7.0