HandBrake 総合スレッド 16©2ch.net
レス数が900を超えています。1000を超えると表示できなくなるよ。
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/ >>826
いろいろありがとう。
まずVidCutterでのフレーム移動の件だけど、これは俺の環境が悪かったみたい。
「Hardware decoding」を切ったらちゃんと操作に応じてフレーム動いたわ。
きっとGT710なんてゴミ使っているせいだな。
で、プログレ化の件は、少し言葉足らずだった。
「インタレ解除してるようだ」と言いたかった訳ではなくて、
「インターレースだと示す情報が欠落しているようだ」と言いたかった。
そう判断したのはMPCのプロパティ。
カット前は「スキャンの種類：インターレース」になっていたのに、
カット後は「スキャンの種類：プログレッシブ」になっていた。
MediaInfoも入れてみたけど同じ感じ。
「First Video Stream」という項目は見当たらなかったけど、
カット前は「スキャンの種類：インターレース」で、
カット後は「スキャンの種類」という項目が無くなっていた。
動画自体はインターレースなフレームのまま。（ちゃんと縞が残っている）
だからエンコ時にどうとでもなるし、これはさほど問題じゃなかったな…。 長かったから2回に分ける…。
インタレ保持にしたいのは以下の理由。
これはもう好みの話だね。
・エンコード時にインタレ解除もすると、単純にその分時間が掛かるから。
・インタレ解除は再生機器（ただのテレビだけど）に任せたいから。
→ 下手にエンコ時にインタレ解除するよりも(俺には)綺麗に見える。
・プログレッシブで動画の滑らかさを維持するなら
bobでインタレ解除した上で59.94fps化する必要があり、
tff=1でインタレ保持するより容量が増えるから。
VidCutterが使えるようになったんで、もう少し試行錯誤してみる…。 むしろ、GT710のHWデコが良い仕事したせいだろ CMカットとかやる保存用エンコにhandbrake使うのはちと厳しいな
保存用はHEVCでエンコしたいからVFRインタレ解除だわ あれ、VidCutterやっぱり狙ったところで切れてないぞ…
今度は確信を持ってフレーム選択したのに
もう疲れた
>>832
どういうこと？ TV番組のCMは、その時代の象徴だと思うから切らないな 自分も保存を目的とするならTV放送は放送枠の時間全て残す。
TV放送ってのはCM含めてスポンサーにどこがついてるとかCM内容はどうだとかが世相を表すのは勿論、番組内容にスポンサー配慮だったりで影響与えてたりするからね。 カットすると字幕データと合わなくなるんだよな
やりようはあるんだろうけど面倒くさい >>830
3年前くらいのPentium G(internal GPU)とかでもフレーム移動は
すばやくできるからVidCutterはCPU, GPUは低スペックでも動くはず。
上下、左右キーを押しっぱなしにしてもフレームのカウンターかなり速く動くでしょう。
ただ1フレームレベルで正確にcutしようとするとH.264で30分のファイルだと
異常に時間がかかる。5分たっても砂時計だからいつも自分で停止してしまう。
これはバグなのかスペック不足なのかわからない。
1フレームレベルで切りだすのはencode前の短いクリップだけにしている。
メモリたくさん(16GB以上)積んでる人は、VidCutterで30分位のH.264でも
1フレームレベル(SmartCut=ON設定)で普通の時間でCut, Joinできるのか気になる。 >>834
左側のハサミのマークをONにしないと1フレームレベルの正確なCut, Joinはできない。
時間がかかるからなのかデフォルトはOFFになっている。 >>839
フリーで対応してるのはamatsukazeくらいか >>830-831
encode前のファイルをMediaInfo18.05でチェックしたけど
VidCutter5.5でCM cut, joinした後でも
Scan type : Interlaced
になってたよ。
VidCutter使う前に処理したソフトに問題があるんじゃないの？何使ったんだろう。
MKVToolNix v23とVidCutter5.5で処理した後のmkvでは問題は起きていない。 >>843
VidCutterのプログレ化の原因わかった。SmartCutだ。
目的が「Iフレーム以外での正確な切り出し」だから、ずっとSmartCut有効にしてたんだよね。
SmartCut無効だと「スキャンの種類：インターレース」が残るわ。
けど、目的は上記の通りなので、SmartCut無効にするならそもそもこれを使う必要性が無い。
そして、さっき試した限りだと、
SmartCut有効でも「確かにIフレーム以外でも切り出せるが精度が甘い」という所感…。
環境はRyzen1700にメモリ16GB。（あとGT710…）
30分程度のtsをMKVToolNixに通しただけのmkv(要はmpeg2)でしか試してないけど、
SmartCut有効でも「異常に時間がかかる」ってほどでは無かったかな、時間は計っていないけど。
でも、何回も繰り返し試験するのは気が進まない程度には遅い感じ。 フリーでも字幕くらい余裕だろ
っていうか、録画した時点で字幕ファイルも別に生成されるので、
そのまま再生するだけで字幕は表示される
.srtファイルを埋め込んでエンコードするのは難しくないし、
個人的には埋め込まずに.srtファイルのまま表示させるのが好きなので、
カットしなければいいだけ いや、カットに対応してるのがamatsukazeくらいだって言ってるんだけど・・・ >>844
mpeg2(mkv)をSmartCut=ONにしてclipのcut実験（join無し)してみた
たしかにMediaInfoでも
Scan type : Interlaced
が消えるね。
ただ実際のVideoはInterlacedのままだった。
VLC Media PlayerでInterlacing=OFFにすると縞ノイズが出る。
あとうちではSmartCut=ONで1フレーム単位のcutは正確にできている。 >>844
848続き
mpeg2(mkv)をSmartCut=ONにしてCut&Joinだと、挙動は変わるかもしれない。
かもしれないと書いたのはメモリ不足が原因なのか、
SmartCut=ONでJoinすると長いファイルは処理が終わらないから。
SmartCut=ONにしてCut&Joinをするときに限り、実際にプログレッシブに
なるかもしれない。Joinの有無で変わっている可能性ある。
インターレースはアナログTVの古い方式だしエンコードするときに
ふつうにプログレッシブに変えたほうがいいんじゃないの。
エンコード時間が増すのは事実だけど、エンコード時に解除するほうが
解除の処理方法の選択肢が多いと思うし。再生時のCPU負荷も減る。 H265はインタレ保持に対応しないし、
GPUのインタレ解除の画質向上はもう望み薄だし
インタレ保持は完全に時代遅れだな VLCのインタレ解除は想像以上に綺麗だぞ
Yadifなのに2xでここまで違うかって感じ 2xってダブルレート(=Bob)ってことでしょ。普通じゃね？
インタレ動画を再生するときにダブルレートにしないプレーヤーなんて見たことないぞ bobがデフォのプレーヤーってあるか？
デッキで再生する時の話か？？ 例えば、横方向に流れる字幕は下手なインタレ解除すると乱れてしまう。
インタレ設定をあれこれするのが面倒なら、インタレ保持もまた選択肢としてありでは。 >>853
あーVLCで「自動」にすると30pになるのか。VLCなんて普段使わないから知らなかったわｗ
でも、ハードウェアアクセラレーション有効にすればbobになるよ
普通にGPUでインタレ解除すればBobになる
mpcやwin10デフォの「映画＆テレビ」ってアプリでさえデフォでGPU使うからbobになる
LAVのソフトウェアデインタレでYADIF選んでもデフォでbobでしょ。まぁ選べるけど
30pにインタレ解除するプレーヤーなんて糞画質すぎて見れたもんじゃないよｗ
>>854
下手なインタレ解除ならしない方がいいというのには同意する
だから、handbrakeが時代遅れなんだよね
amatsukazeならKFMのVFR化で全く問題ない
なめらかに動いて気持ちいいよぉ〜 インターレース解除の種類なんて気にしたこともなかった。
VLC PlayerのAutomaticのBlendとかいう設定で不満はないな
>>851
VLCのインターレース解除はきれいなほうなのか
>>853
VLCだとデフォルトではなぜかDeinterlacingはOFFになってるね
Deinterlacing設定しらないときはTVTestとかでtsを再生してたわ
>>854
横方向に流れる字幕ってアニメとかでよくあるような
インターネットへの動画放流をやめましょうとかのいらない情報だよね？
その乱れまで気にする人なら円盤買うとかエンコードしないほうが幸せになれる気がする >>856
yadifってhandbrakeにもあるしffmpegにもあるしLAVフィルタにもあるしffdshowにもあるしavisynthにもあるし
どれも同じじゃね？VLCだけ実装が違うのか？
VLCのyadif(2x)でフルHD再生すると結構フレーム落ちしてカクつくんだよね
CPUはi7-6700だからそんなしょぼい環境でもないんだけど
だから自動だと30pになっちゃうのかな
まぁ普通はGPUでインタレ解除すればいいんだけど handbrakeでyadif bobでエンコしたやつはカクつかないできれいに見えるわ 60iテロップはその部分だけ60pにしてVFRにすれば全く問題ない
handbrakeじゃできないんだけどｗ インターレース解除は要は動き予測みたいなもんだから、
厳密解なんか無い
簡単なアルゴリズムで高速にやろうとするとたまに騙される >>857
よく読んで。俺はDeinterlacing方式ごとの画質違いはよくわからない。
VLCのAutomatic - Blendの設定で不満ないからそのままだった。
VLCのデフォルトはDeinterlacing=OFFだし, automaticに変えても
デフォルトは"Blend"だったと思う。YadifやBobは選択肢で選べるけどデフォルトではないはず
HandBrake - Filtersでは
Deinterlace:Yadif
Preset: Default
Interlace detection: off
だけ設定している。 YouTube、知らない間にH.265のアップロードに対応してた
そろそろエンコードするならH265にしたほうがいいのかな
同等画質ならファイル小さくなるのはいいけど
エンコード時間がH264に比べて2.5倍くらいになってしまうようで悩む
同じRF24, Medium, 1080p設定だとH264よりH.265のほうが画質がいい気がするけど
コーデック変わったら同じRFが指す画質も全然違うもの？ >>862
あたりまえ
x265はx264から+2〜3ぐらいで同サイズ（同ビットレート）のより高画質になる x265はそうかもしれんけど、H.265がそう決まってる訳ではない >>848-849
VidCutterの件、何度もありがとう。
# 流石にスレ違いなのでこれで最後にする（つもり）。
まずプログレ化云々の話だけど、Joinは関係無い。
830で書いた時点でJoinもしてたけど、インタレ縞はしっかり残っていた。
あくまでヘッダ上の情報に過ぎない話。
あと「1フレーム単位の正確なカット」だけど、
俺の環境では指定範囲外のフレームが残ったり、逆に欠落が出たりした。
（元のファイルと1フレームずつ比較した。）
なのでもう諦めた。
ここからはHandBrake関係する話。
インタレ解除は、831に書いたように再生機器に任せたい派。
というかエンコ時にいちいち設定を検討するのが面倒なので、
再生機器に丸投げしたいんだよね。
放送の元素材がプログレッシブなら、
テレビ放送の際にインタレ化（テレシネ化？）されても
インタレ縞なんて無いフレームの方が多いよね。
それなのに無闇にインタレ解除のフィルタを掛けたら、
時間を掛けてわざわざ汚くしてるようで何か気に食わない。 インタレ保持だとfluid motionが効かないんじゃボケ >>866
handbrakeのインタレ解除は画質悪いから、しないほうがいいで正解
ただ、KFMDeintみたいにちゃんとしたインタレ解除なら
元ソースのフレームレートを認識して
逆テレシネ、ソースそのまま、Bob化を使い分けるから
汚くなることはないよ
それなりに計算量はあるけど このソフトって書き出しはffmpeg使ってますか? 皆さんDVDとかエンコするときチャプター作ります？
チャプター名もいちいち打ち込んだりします？ >>740
> 開発版にいつのまにかNvidia NVEncでエンコ出来るモードがあった
こういうブログ記事もありますね。
https://negativo17.org/handbrake-with-nvenc-support/
この人は、nvenc を slowest モードで使っていて、それだと
エンコーディング作業を完全にはGPUにお任せしないので、
GTX1060のビデオエンジン使用率は33%にとどまってます。
（CPUの使用率や温度には言及ナシ。残念）
HDDも値下がり傾向ですし、圧縮率については妥協して、速度と品質を重視、
というのも一法ですよね。
いずれにせよ、Handbrake が重い腰を上げて nvenc サポートを始めたのは嬉しい。
なお内部では、ffmpegを呼び出してる模様。 飛ばして見たりしない派だしそもそも飛ばすなら動画編集の段階で消すから付けないな nvenc+ffmpegがサポートされたら良いよね フィルターはCPUを使う仕様だから、GPUを100％使わないんだろう H.265 NVENCできないのが残念だな。
クオリティ派の人はソフトエンコだから関係ないのかもしれないけど。 >>878
今落とせるNightlyで可能。H.265ができるのは900番台はGeForce 950、960のみ
1000番台だとNVENC不可なGT1030以外は多分大丈夫
ノート用のはちょっとわからない ただ現状HandbrakeのNVENC H.265は最適化が進んでいない感じ
GTX960 の NVENC H.265 と G4560 の intel QSV H.265 の GUI での比較で QSV の方が 40% くらいサイズが小さい
CUIを使って細かくパラメーターを変えるとまた違うのかもしれないけれど >>881
どういう設定でやったのか知らないけど、例えば同じQP値でも、
エンコーダーが異なれば仕上がり画質も変わってくるのは当たり前なのだから、
最適化が進んでないという話ではないと思うよ。 >>882
確かにその通りだね。設定は↓みたいな感じ。Autoで Video Codec だけ変えていって試してみただけ
https://i.imgur.com/YIKGF2w.jpg
HandBrakeのバージョンは "Nightly-2018081395601-a9daef1-master（2018081401）"
AMD VCEにも対応していて intel QSV よりサイズは小さくなるんだけど Fire TV で再生できないとか
他にもいくつか問題があって Auto だとちょっと使えない感じ
Avg Bitrate 指定の方がいいのかも
あと GTX970、980 も NVENC H.265 に対応しているみたい m2tsだから信用できないソースではあるんだけど、フォルダごとドラッグで読み込ませると
たとえば96のtitleが登録されたりする。だけどqueにつっこむと90とかしか登録されない
登録されないファイルだけ1個づつadd queするとちゃんと登録される
何が悪いんだろ？ すまない
勘違いしていた
>たとえば96のtitleが登録されたりする。だけどqueにつっこむと90とかしか登録されない
>登録されないファイルだけ1個づつadd queするとちゃんと登録される
は
96個のファイルが入っているフォルダをドロップすると90のtitleしか認識しないが
ファイル1個1個をつまんで投下してやると登録される
の間違いでした 小出しで連投してすみません
フォルダをドラッグすると
title:1 Chapters:1 to 1
title:2 Chapters:1 to 1
title:4 Chapters:1 to 1
みたいな感じでスキップされるtitleがあります
title:3に相当するファイルをほうりこむとちゃんと登録でき、エンコードできます 前もあったけど、大量読込みバグちょくちょくあるみたいだな
正常に読める分ずつ放り込むしかない あれはバグじゃなくて軽いプロテクトなんじゃないかと思ってる
何か異常なタイトル情報を混ぜておいて、全部対象にするとハマるようにしてある
通常のプレイヤーからはアクセスできない隠しタイトル 仕様みたいなもんですか
ビデオカメラから取り込んだものなのでプロテクトでは無いとは思うんですが
異常な情報でもあったんでしょうね
ちまちま確認しながらエンコードしてくことにします 読み込む時、5分以下は無視とか時間設定無かったっけ？ GPU encodingが話題になってたから
Intel QSV(H.264)久々に試してみたが圧縮率がひどすぎて笑った。
Quality=20, Balanced設定で
111MBのファイルがエンコード後は107MB。3.7%しかサイズ変わらず
QSV使い道が分からない。
NvidiaやAMDのencodeはH.264, H265と比べてどの程度優秀なの？ >>894
GPUエンコは保存用じゃなくて持ち歩き用
すぐに変換出来るから、見たら捨てるって動画に使う >>894
エンコード後のサイズがでかいなら20じゃなくてもっと大きくすればいいだろ
お前の頭ではパラメータの調整もできないのか？ｗ
> NvidiaやAMDのencodeはH.264, H265と比べてどの程度優秀なの？
エンコーダと規格はどうやって比較するんだ？ 897に言われなくてもパラメータ変えて試していた
x265のパラメータ変えて40回ほどテストしていたがx265はやたら時間
かかるわりにサイズ小さくならないな。
そしてx265スピードにうんざりしてQSVのH.264テスト始めた
QSVはデフォルトのQP20がどうしようもない設定だった。
エンコード前よりもファイルが大きくなる笑える設定さえある。
しかし26より下げるとQSVの存在意義がわかってきた。
encoding speedはハードウェアだけあってすさまじい
x265いじった後だと感動的スピード HandBrakeのx265はRF20-Mediumで時間かけて処理しても
静止画でみるとかなりにじみがでている。
本当に画質こだわるファイルはエンコードしないままにするしかないし
ある程度の画質劣化は妥協できるファイルならQSVとかハードウェアでさくっと
エンコードでいい気がしてきた。 エンコーダの差なんて、サイズにするとせいぜい1割程度だからね
HWエンコーダでエンコしてもサイズ10%盛ればソフトエンコと変わらない画質
20%盛ればソフトエンコよりも画質が良くなる
サイズ10%を縮めるのに倍以上時間かけたいって人が
そんなにいるとは思えないだよなぁ ハードエンコの倍とかその程度で済むソフトエンコできるCPU積んでる人って羨ましい x264ソフトエンコードで高画質設定で
新しく組んだRyzen7 2700xは
今まで使ってたi7 6700kの２倍の速度に成った
やはり時間掛かってもソフトエンコを高画質設定でするのが画質は良いね 画質を良くしたいならあんまり縮めなければいいだけで、
CPUパワーを使う本質はやっぱりサイズなんだよな >>900
その程度しかかわらないのか
サイズをプラス10%程度で同等品質になるという結果のURLとか
あったら教えてほしい。細かくみてみたい。
ネットで見る限りファイルサイズ、品質、スピードでバランスいいのはQSVのx265な気がしてきた。
x265の遅いという弱点をQSVのH/W encodingのスピードでカバーする感じ。
QSVでx265で使えるよう新しいCPUに変えるか 大半の作業はIvy Bridgeで何も困らないのになあ >>908
遅いといってもQSVのx264との比較でしょう
QSV-x265がQSVのx264の2倍になったところで十分に早い
ソフトウェアのx265に比べたら爆速
>>907
QSV x265対応はSkylake以降らしいね HandBrakeでの結果ではないけどここにQSV x265のFPSがでていた。
サンプル画像もあった
tinyurl .com/y8hex5cj
要スペース削除
x265は13 fps
QSV HEVCは173 fps。悪魔的スピード >>910
Ryzenは速いといいたいの？
x265で170 fps以上だせるRyzenを教えてよ
software encodeでそのレベルの速度が出せるとは思えないけど >>913
techgage.com/article/a-performance-review-amds-ryzen-5-2600x-ryzen-7-2700x-processors/4/
ここみるとAMDでもintelでも同じ傾向で
HandBrakeでx265はx264の2.0-2.5倍の計算量。
QSV x264は超高速だからx265にして1/2-1/2.5になったところで十分速い
コアを増やして力業でsoftware encodeしたって対抗できる差ではないだろう
911では13倍もの性能差がでている。 JPEGを高速に表示できるフレームバッファとか、
浮動小数点演算を高速で実行できるコプロセッサみたいな感じで、
USBあたりにぷすっと刺すだけでH265演算を高速に代行してくれるような、
専用ハードが作れないものだろうか Thunderbolt3接続の外付けGPUを使え
ただし、今まで待ったのであればNVIDIAの新型GPUが登場するのを待ってもいいかも 出すとしてもエンコーダーとセットでないと意味ないしな
専用ハードに任せられる処理を切り出したら、それはGPUでもできる気がするし >>915
USBならUSB PD対応じゃないと電気が足りないでしょ
普及しているUSB3.1 Gen1だと900mA 5Vまでしか供給できない
USB PDはほとんどのマザーが対応していなくて高コスト
あとQSVはencode専用ハードウェアを使っているから
QSVみたいにCPUでやるのが一番コスパいいよ
wikipedia.
Quick Sync is a dedicated hardware core on the processor die.
This allows for a much more power efficient video processing.
>>916
Thunderboltは廃止らしい。独自規格乱立させてきたAppleもUSBに移行
>>919
動画の処理はiGPUかdGPUでやるのが効率いいね 来年に廃止はThunderboltじゃなくてLightningだっけ
>>921
アンカーつけてどの話題が具体的書けよ >>922
Lightningの廃止は聞いたことある。
ThunderboltはIntelの規格じゃなかったか。 NVENCでエンコードしたら520fpsも出て速過ぎワラタ >>923
やっぱり記憶違いか
廃止はThunderboltじゃなくてLightningだな
>>924
ハイエンドのカード？
NVENCのx265? x264のどっち?
再生速度の17倍以上は速すぎるな
QSVはNVENCより遅いけど画質はNVENCより上らしい
520fpsなんて体験したらソフトウェア処理には戻れなそう >>900
HWエンコで設定そのままでやったらサイズが倍のファイルが出来上がった事があったんで
それ以来HWエンコは使ってないわ
バグ持ちのバージョンだったのかもしれんけど >>926
QSVはデフォルト設定だとファイル大きすぎになったはず。
x264ならBalancedのQP26以下にしていくとファイル小さくなるよ
Skylake以降ならQSV x265のがいいとおもう
QSV x264では高画質にするとファイルがあまり小さくならず
サイズ優先すると画質が物足りないからね
x264の2倍時間がかかるが十分はやいしクオリティとサイズを追求できる。
スピード、サイズ、クオリティのバランス。 HWはとにかく速度重視で仕事を上げてくるので、
もっと落ち着いて丁寧に仕事させるのが大変 冬の就寝中にx265でハードエンコすればあら不思議！
部屋はホカホカで起きる頃にはエンコも終了！
ってわけでエンコは冬にやろうね！ レス数が900を超えています。1000を超えると表示できなくなるよ。
