HandBrake 総合スレッド 16©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
HandBrake は DVD や様々な形式の動画ソースを変換するソフトウェアです。
GPL ライセンスのオープンソースで開発されています。
公式サイト
http://handbrake.fr/
公式:Wiki(FAQ やドキュメント)
http://trac.handbrake.fr/wiki
公式:Discussion forum(サポートフォーラム)
http://forum.handbrake.fr/
非公式:HandBrake 日本語版
http://sourceforge.jp/projects/handbrake-jp/
※日本語版を使用しての不具合に関しては日本語版配布元で質問してみましょう。
公式:Nightly Builds
https://handbrake.fr/nightly.php
公式:Roadmap(マイルストーンと進捗)
https://trac.handbrake.fr/roadmap
公式:Timeline(詳細な進捗)
https://trac.handbrake.fr/timeline
公式:Active Tickets by Milestone(マイルストーン毎の機能拡張予定など)
https://trac.handbrake.fr/wiki/TracTickets
【前スレ】
HandBrake 総合スレッド 15
http://echo.2ch.net/test/read.cgi/avi/1476339828/ >>631だけど、
要するに俺は「B=Q・v」みたいな関係があるんだと期待してた。
(Bがビットレート、Qが画質、vがエンコ速度)
Q=一定下でvを遅くするほど(時間をかけるほど)、ビットレートが小さくなる。
B=一定下でvを遅くするほど、画質が良くなる。
・・・となると思ってた。でも、実際は、
Q=一定下でvを変えると、QもBも変動する。
B=一定下でvを変えた場合は、QもBも不変だった。
最後のは、さすがに一番速いプリセットだと画質が悪化したけど。 >>631
俺もやってみた、実写ソースだが確かに言ってる感じではある。
でも、動画を見ると変換が速いほどノイズが酷く汚い。遅いほど細部が綺麗になっていく印象。まぁ、SD画素なんでFast以下は見た目に変化無いと言えなくはないが…。
https://jisaku.155cm.com/src/1525571266_d8e4ab7f602bba05e025374c01b5d2b46048cf49.png 👀
Rock54: Caution(BBR-MD5:f68c41b6bce4f8b76d46a9fc61dd270c) >>635
それは偶然こういう結果になっただけで何とも言えない >>634
プリセットのどこで画質が山・谷になるかは、
ソース動画によるだろうし、H264かH265にもよるんだろうな。
万全を期すなら、VerySlowにするべきなんだろうな。
プラセボは時間がかかるので除外するとして。
ちなみに、CQ値を変えても、山谷の傾向は変わらないと思う。
俺はCQ=23と25でデータを取ったけど、平行移動したような感じになった。
もちろん、CQ=23の方がビットレートが高い。 エンコーダーでいう一般的な「品質指定」は、「量子化器を固定する=品質が一定」であって、視覚的な「画質」のことではないから
音声エンコードも映像エンコードも最後にモノをいうのはビットレートだよ
この知識を引き出すのはすんごい久しぶりだから間違いはあるかもしれない・・ 全く同じ設定でもプリセットがSlowじゃ無いとブロックノイズが出る動画はあったぞ
エンコードだけして確認後回しにすることが結構あるから時間は掛かるけどいつもSlowで回してる プリセット変えたら同じ設定じゃない件
x265はアップデートが多いから
自分ならそのブロックノイズがでるシーンを切り出してテストソースにする
(ついでにどのオプションが影響してるかも切り分けてみる) >>638
それだとUltraFastが1番良いって事になるじゃん
実際にはどんだけビットレート盛っても砂嵐みたいなノイズの嵐なのにさ みんなはどういう手順で、
満足の行く画質でビットレートが最小になる設定を探してるの?
俺はもう分からなくなったよ。 >>641
どこがいいのよ?
量子化器が必要とするビットレートが増えるのと
品質基準を上げる(数字を小さくする)ことによるビットレートの増価はイコールじゃない >>643
目標を自分で決めてそれに近づける様に設定する
例えば、「720x480の動画を1/4の容量に縮めたい」から、その時に1番画質が良いと思えるCQやEncode設定を自分で試して調整していく
それこそ、>>531のH.265の説明が分かり易い >>645
ファイル容量の目標を決めてるんだったら最適化しやすいんだけど、
その逆で、画質の目標を決めて、
それを満たす最低の容量を探すのは最適化しにくくない?。
エンコ時間をかければ容量が小さくなると思ってたら、
話題になってるように、プリセットをイジると画質も変わってしまうし。
容量を小さくするためにH265にしたら、画質がそれほどよくないし。 >>646
それだと容量は圧縮したい(減らしたい)のに画質は高くしたい(増やしたい)っていうエンコードの矛盾になってくるから難しいというか、どっちかに妥協するしかない
でも、そもそもCQ指定なら圧縮しつつ出来る限り高画質にって設定だから、デフォルトのCQ20でも汚いと思うならもっと数値を下げて高画質化するしかないよ QC=18、veryslowで統一しちゃってる。
たまに2時間映画のBlu-rayエンコで20GB超えるけど
考えるのがめんどくさい。
旅行先のタブレットで見る時用にはSD画質にして容量削減。
youtubeとかニコニコへのアップロードなんてしないので充分。 上限付けても使うときはガッツリ使っちゃうからな…… 2時間で20GBって元素材でいいじゃんてレベルだな >>647
画質とビットレートがトレードオフだってことは理解してる。
でも、そうだとすると、プリセットって何のためにあるんだろう?
ひょっとしてプリセットって、エンコードの精度を設定するものなのかな?
例えば、CQ=20でUltraFastとVerySlowを比べたら、
どちらもCQ=20を目指すんだけど、UFはVSより、
実際にCQ=20になる保証が低いってことなのかな? >>651
要は圧縮する時の計算処理を丁寧にやるか雑にやるかの違いだ
仕事は丁寧にやって欲しい(CQ19)が、速く仕上げろ(UltraFast)って無茶な命令するとHandbrakeは速さ優先で雑に仕事して圧縮率が悪い物になるってこと
詳しくはマウスオーバーすると説明が出るから翻訳しろ Videoタブの設定の参考になりそうなサイトを見つけた。
各設定でエンコした結果を比較できる。静止画だけど。
ttps://mattgadient.com/x264-vs-x265-vs-vp8-vs-vp9-examples/
これによるとEncoder Presetは、
クォリティ指定モードではmediumで十分みたいだな。
それしか表示できないので。
一方、ビットレート指定モードでは遅いほうが綺麗になるようだ。
でもその違いは少しなので、
画質を上げためなら、大人しくビットレートを上げた方が確実だろう。 rect と limit-modes の2つを有効にしたほうがビットレートあたりの画質が大きく改善するから
presetをslowにするか、上記2つのオプションを個別に有効化したほうがいい
(特に低ビットレート帯において顕著) 一時間ドラマ4GBあった動画が8分で0.3GBになったよすげーなコレ >>656
rect と limit-modesを有効にするにはどうしたらいいの?
Extra Options の欄に「--rect --limit-modes」で書けばいいの? >>661
やってみりゃいいんでないの
CLi版は=1か=0で有効/無効の切り替え
オプションは ; か : で区切ったはずだけどGUIのやり方は知らない >>662
やってみたんだけど、全く変化がないんだ。
有効になってないのか、rect と limit-modesの効果がないのか、
判別がつかない。
でも、>>662の書き方にしたら変化が出たので、
これから試してみるよ。ありがとう。 音声のパススルー対応コーデックにOpusの追加希望 新しいやつバッチ登録するとエラーファイル出来まくりでおかしいよな 0.95使いやすくて使ってるんですが
framerateに60fpsの選択が出ないんだが使用?
それとも元のファイルが対応してなくて対応してたら出るのでしょうか? >>666
仕様、てか、未だに0.9.5はどうなのか
慣れてるからって「未だにOSにWin2000使ってます」と言ってる様もんだよ
ま、自分が良ければ良いんだけど 画質なら、動き予測アルゴリズムの--me umhとかによってエンコードの負荷が変わってくるだけではないかな 久々に立ち上げたらエラー出て終了するんだが、何か変わったのか?
ちな、Windows10 新しいhandbrake導入したけど、
dropが入ってるtsファイル処理させようとするとエンコード止まるね。
前のバージョンだと問題なかったのに、、、 MPEG2Repairでデータ修復してみたら?
映像が修復される訳じゃないが、エンコは正常にいくかもしれない >>673
ありがとうございます!
調べてみたらvlcの方がバッチで使えそうなのでそっちで試してみます。 [12:55:58] stream: 1640 new errors (91%) up to frame 81007: missing start code
こういうエラーがいくつも出るようになってTSのスキャンが遅くなった
同じファイルでもVer1.07だと出ないのに みんなどんな動画をエンコしてんの?
DVD?ブルーレイ?
Isoのままじゃダメ? >>681
君はどんなソースをエンコードしたりisoにしてるの? >>682
友達からもらう自作DVDをリッピングしてisoのままです( ◠‿◠ ) 複数ファイルをキューに登録して一括変換する時、
ファイル1つごとに出力設定(例:VideoタブのAvg Bitrateなど)を変えられないの? >>687
キューに入れた後は出来ない
1個づつ設定変えてキューに入れる事は出来る 動画変換するとスタートの映像と音声が揃いません
音声は0秒の位置でスタートし映像は0.2秒でスタートって感じで、0秒〜0.2秒までは黒い画面です
1本の動画だけを見るなら気にならないんですが、何本かの変換した動画を1本にまとめると気になります
出だしの黒い画面を無くし映像と音声をジャストで揃える設定を教えてくださいm(__)m >>691
そんなのなった事ないな
バージョンと元動画の形式を書けば誰か知ってんじゃね >>690
ありがとう
その方法でできた
念のためキューをエクスポートして中身をテキストエディタで確認したら
ちゃんとファイルごとに出力設定が変わってた >>692
バージョンは1.1.0なので最新だと思います
プリセットのGeneralのHQとかSUPER HQをそのまま使ったんですが冒頭に黒い画面が出るんですよね
LegacyのHigh Profileで試した所異常なくできました
何処の項目が悪かったのかは謎ですが、とりあえずこれで変換していこうと思います いつも開発版の方でアプデして使ってたんだけど0%の時点で強制終了するファイルがあったんだけど原因なんなんだろう(大半のファイルは変換できてた)
プリセット消えるのが嫌だったからインストールの時NO押してたんだけどこれのせいだったのかなあ
あと昔のHandbrakeで変換した動画の方がサイズ小さい(設定はいつも変えてなかった)時があるのは例えば夜中にエンコードさせてたからとか関係するの? 夜中に小人さんが昼間より頑張って圧縮してたからとか思っちゃった? >>699
おっさんよ世間に出ろよ、引きこもってなく 新盤クソ遅い!
読み込みで全アクセス、エンコ開始でまた読み込み→なんぼかかるねん!! windwos10_64bit
intelcorei5 8400T
Handbreak1.1.1
環境でQSVエンコしたところ
GPU-ZでGPU LOAD50%しかいきません
intelCorei73770環境の時は75%くらい出ていたので
何か改善策はありませんか? 同じソース使用で
8400Tでavg44.54fps
3770Tでavg140.69fps
になります >>706
ありがとうございます。
BIOS触ってみます。 >>703
QSVはintel driver依存だからdriver version変えてみたら?
intel driverけっこうバグ多くて
バージョンによってQSVがまったく動かないものもあった。
いろいろ試して安定するのを探さないといけない
UEFI, BIOSは関係ないと思う >>600
音ズレしてるファイルは原因探るの面倒くさいからmkvtoolnixで無理矢理直してるわ
例えば60分の動画で先頭で音声が300ms遅くなってて終盤では400ms音声が早い様な場合
先頭のズレは音声を選んでディレイ-300に設定、
終端のズレは映像の方で36000/36007に設定して映像を縮めればいい 音ズレした時は動画と音声を分離して、動画はHandBrake、音声は別のソフトでエンコ
その後、動画と音声を統合してる 0.9.6から使ってるけどいいソフトやね
1.1.1にしてさらに良くなった
仕上がり容量小さくなって画質も上がってる。素人にも使いやすくなった。十分 最新バージョンで一括変換するとき
インポート漏れが発生するんだけど何が原因かな
例:50本の動画が入ったフォルダをドラッグすると最初は50本認識してるが
最終的に37本しか読みこまない
あとちまちま1個ずつドラッグすると全部読める ドラッグ操作はこれに限らず不安定なもんだよ
50個選択して入れられないの? いつの間にか、Nightly buildでVCE対応してる! PCのスペックがしょぼいとブルーレイをmp4に変換するのに時間かかるよね
ソフトの仕様じゃないよね もう少しで32コアが買えそうだからな。
ブルーレイのエンコも捗るよ。 コア数ではコスパ的にもAMDのRyzenの方が多いけど
CPU単独のパワーなら依然Intelなんでしょ?
UHBDに対応してるのもIntelだしエンコもするならやっぱりIntelの方がコア数少なくても有利なんだろうか? x265のultraFastが早くて優秀だな。
これでrfを18くらいにしとけばx264はもういらない感じやね。 x264 veryslow rf18
x265 ultrafast rf18
だとx265の方が倍速くて2/3くらいのサイズになる感じ
画質は大して変わらないように見えるけど厳密にはどうなんかね。 264に比べれば縮むけど、264の半分のサイズにという触れ込み程ではない
265でもっと時間かければもっと縮んだだろうに 横軸にビットレート、縦軸にVMAFやSSIMをとって圧縮効率のグラフを作ると、
x265のultrafastなんて、QSVのH.264 LA-ICQに負けるくらいだな・・・。(ソースにもよるだろうけど)
x264にしてもx265にしても、medium以下のプリセットは圧縮効率ががくっと下がったりするので
トランスコードで使うもんじゃないなとは思う。 mediumとveryfastを比較してみたけど、
veryfastの方が速くてより縮むんだよな
もっと速くしたらもっと縮むだろうか ■ このスレッドは過去ログ倉庫に格納されています