オープンソースの動画変換ソフト HandBrake 1.7.0
(forum.handbrake.fr)HandBrake 1.7.0 アップグレード案内
- HandBrake を更新する前に、保留中のエンコードがないことを確認し、ユーザー定義プリセットとアプリ設定のバックアップを推奨。
- Windows ユーザーは必ず Microsoft .NET Desktop Runtime バージョン 6.0.x をインストールする必要があり、.NET 7 がインストールされていても .NET 6 のインストールが必要。
HandBrake 1.7.0 リリースノート
- 改善点とバグ修正の完全な一覧は、GitHub のリリースノートで確認可能。
問題報告とフィードバック
- 再現可能なバグや問題を発見した場合、またはフィードバックを提供したい場合は、GitHub の issue tracker を通じて知らせてほしいとのこと。
- IRC コミュニティサポートチャンネルからも連絡可能。
- HandBrake アプリは小規模なボランティアチームが余暇時間に開発しているため、即時の応答が難しい場合があるが、すべての意見を確認し、建設的なフィードバックを歓迎している。
謝辞と貢献
- 今回のリリースの一部機能は HandBrake ユーザーや企業から提供されたものであり、翻訳は世界中のボランティアコミュニティの積極的な参加によって成り立っている。
- 貢献に興味はあるがまだ参加していない人には、貢献ガイドを読んでみることを勧めている。
- 開発者でなくても貢献できるさまざまな方法がある。
GN⁺の見解
- HandBrake 1.7.0 へのアップグレードには、ユーザー定義設定のバックアップと新しい .NET ランタイムのインストールが必要。
- このアップデートには改善点とバグ修正が含まれており、ユーザーや企業の貢献によって成り立つコミュニティ主導のプロジェクトである。
- この記事は、オープンソースの動画トランスコーダー HandBrake の新バージョン公開を伝えるもので、技術コミュニティにおける協力と貢献の重要性を強調している点で興味深い。
1件のコメント
Hacker News のコメント
HandBrake で最終的なファイルサイズを指定すると残りを自動計算してくれないのが残念なら、計算自体は簡単です。
平均ビットレート
[kbps] = 目標サイズ [キロビット] ÷ 長さ [秒]たとえば 2時間48分のファイルを 5GB 以下にしたい場合、2時間48分は 10,080秒で、5GB は 40,000,000kb なので、平均ビットレートは 40,000,000kb ÷ 10,080秒 = 3,968kbps になります。
音声が 256kbps なら、平均動画ビットレートは 3,712kbps 以下である必要があります。
通常は固定品質でエンコードしますが、出力サイズは入力映像に大きく左右されます。
そこで Python ラッパーを作って HandBrakeCLI の出力をパースし、完了率と現在の出力ファイルサイズをもとに最終サイズを推定するようにしました。
ファイルが大きくなりすぎそうだったり、出力品質が悪すぎて品質係数を上げるべきだと判断したりした場合は、早めに中断できます。
“Put that cocktail down. Your HandBrake encode is complete!” というメッセージが、年月がたってもずっと残っているのはうれしいです。
以前は HandBrake のパイプラインが 10ビットになった後も、かなりのフィルターが 8ビットのままだったので、間違ったフィルターを選ぶと気づかないうちにエンコード品質を落としやすかったです。
今はほとんど、もしかするとすべてのフィルターが 10ビットをサポートしているようです。
また FDK-AAC のライセンスのせいでバンドルできず、リリース版の AAC コーデックが劣っていたのですが、最近はそのコーデックも以前ほど悪くないと聞きました。
現行版のこの優れたアプリにも大きな落とし穴があるのか気になります。
いずれにせよ核心的な問題は人手不足です。あるとよい要望機能がたくさん機能天国で止まっています。
どのオープンソースプロジェクトも似たようなものでしょうが。
最近は ChatGPT に
ffmpegのターミナルコマンドを頼んでいます。どんなアプリよりずっと速く、思い通りに調整できます。
試行錯誤したり man ページを読んだりすることが、HandBrake でプリセットを選び、チェックボックスを押したりスライダーを動かしたりするより「ずっと速い」とは言いにくいです。
ffprobeの出力も入れない限りそうです。ソースが DVD なら、アスペクト比の問題、デインターレース、字幕処理など、考慮すべきことがたくさんあります。
今ではどんな man ページでも探索できるように、
--helpに似た--chatgptオプションを探してしまいます。機能一覧が良いです。特に arm64 / aarch64 / Apple Silicon アーキテクチャでの性能改善、最新 FFmpeg によるより高速な HEVC デコードと 30% 高速化した bwdif フィルター、新しい SVT-AV1 アセンブリ最適化による最大4倍の性能向上、不要なフレームコピーをなくしてメモリ効率を高め、動画変換速度を改善した点に期待しています。
HandBrakeCLI について唯一の不満は、stdin からパイプされた入力をエンコードできないことです。
FFmpeg は対応していますし、HandBrake も内部的には FFmpeg を使っていると思っていました。
libavformat、libavcodec、libavfilterを使っています。それでも完全に別のアプリです。デコーダー、一部のデマルチプレクサ、一部のフィルターは同じですが、それらをつなぐ方法は FFmpeg のコマンドラインアプリとはまったく異なります。
あるいは
handbrake-cli -i <(cat video-file.mp4)のような Bash の魔法も可能かもしれません。HandBrakeCLI は使ったことがなく、GUI しか使ったことがないのでよく分かりません。
もちろん別の部分では FFmpeg ライブラリを幅広く使っています。
FFmpeg ラッパーにとどまらない数少ないトランスコーダーの一つなので、長所でもあり短所でもあります。
HandBrake がなぜ目標ファイルサイズオプションを実装できないと言っているのか、簡単に説明してもらえますか？
Android の動画圧縮アプリではこの機能がかなりうまく動くのに、HandBrake の GitHub にある関連機能リクエストでは、メンテナーの一人が現実的には難しいと言っていました。
ffmpeg/vapoursynthフィルターチェーンでも可能です。だから、なぜできないと言うのか想像がつきません。
Windows なら Staxrip をそのまま勧めます: https://github.com/staxrip/staxrip
vapoursynth ベースの Linux 対応アプリもありますが、名前を思い出せません。
あるいは AV1an GUI の一つかもしれません。こうしたツールはいずれも HandBrake よりはるかに多くの機能を備え、目標ファイルサイズにも対応しています。
なぜ今でも「動画 X をファイルサイズ Y に制限する」という単純な機能がないのでしょう？
私はただ 5GB の動画ファイルが欲しいだけなのに、HandBrake は私がよく知らない Vimeo プリセット 50 個のうちどれかを気にしていると思っているようです。
5GB は明らかに CD より大きく、Blu-ray にちょうど 10本入れたいのでなければ Blu-ray 用としては小さすぎます。
あなたに Vimeo プリセットが奇妙に見えるのと同じくらい、世間の大半にはあなたのユースケースが奇妙に見えます。
HDR映像を扱う場合を除けば、常にHandBrakeよりffmpegを好んで使う
入力ソースから出力へHDRメタデータをコピーする適切なffmpegコマンドを見つけられなかった
最後に確認したときは不可能で、MediaInfoのようなツールでメタデータを手動抽出したうえで、各値をffmpegの引数として渡す必要があった
今でもそうなのか知っている人はいる？
-movflagsとuse_metadata_tagsは試した？ffmpeg -i $input_file -movflags use_metadata_tags -crf 22 $output_file出典: https://video.stackexchange.com/a/26076
もう少し詳しく言うと、一般的なHDR動画規格はDolby VisionとHDR10の2つ。どちらもエンコーダ内部での個別対応が必要で、これは
libavformat/ffmpegというよりlibx265側の問題に近い幸い、ソース映像がHDR10なら、全体を通して変わらない伝達関数とトーンマッピングを抽出し、出力メタデータに直接適用できる。FFmpegはこの値をエンコーダに渡すことはできるが、デフォルトではソースからターゲットへコピーしない
方法を説明した記事はhttps://codecalamity.com/encoding-uhd-4k-hdr10-videos-with-f...にある
HDR10でエンコードされた映像を、メタデータを維持したまま別形式へ再エンコードしたことがあり、シェル履歴に残っている最終コマンドはおおよそ
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のようなものだったここで
master-displayとmax-cllの設定は、別のツールで最初の映像から抽出する必要があった色伝達関数。この設定はlibx265のパラメータ文書https://x265.readthedocs.io/en/master/cli.htmlに載っているDolby Visionはさらに難しい。メタデータが動的なのでソースからどう取り出せるのかは確かではないが、コマンドライン引数を通じて
libx265に供給することはできる。残念ながらコマンドラインにしか公開されておらずAPIにはないため、まだffmpegが代わりに処理することはできない関連する参考資料として、伝達関数を抽出してffmpegに渡す手順はhttps://medium.com/@yllanos/how-to-encode-a-4k-hdr-movie-usi...とhttps://codecalamity.com/encoding-uhd-4k-hdr10-videos-with-f...にあり、複数の人が同じ作業をまとめた記事はhttps://www.reddit.com/r/ffmpeg/comments/g3uucr/how_do_i_enc...にある
Dolby VisionからHDR10への変換、HLGとPQに関する内容はhttps://www.reddit.com/r/ffmpeg/comments/nkxbay/how_to_conve...を見ればよく、Dolby Visionの微妙な点はhttps://www.reddit.com/r/ffmpeg/comments/a32yv4/deleted_by_u...にある
リリースそのものの方が、より良いリンクだったかもしれない
ほとんどの人が見たがる変更履歴が入っている
https://github.com/HandBrake/HandBrake/releases/tag/1.7.0