HandBrake 総合スレッド 12

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
http://build.handbrake.fr/
公式：Roadmap（マイルストーンと進捗）
http://trac.handbrake.fr/roadmap
公式：Timeline（詳細な進捗）
http://trac.handbrake.fr/timeline
公式：Active Tickets by Milestone（マイルストーン毎の機能拡張予定など）
http://trac.handbrake.fr/report/3

【前スレ】
HandBrake 総合スレッド 11
http://toro.2ch.net/test/read.cgi/avi/1314361029/

【質問する前に】
フォーラムやドキュメント、FAQに目を通すことで解決できる場合もあります。
質問する場合はあなたの環境や操作、エラー内容を具体的に書きましょう。

【OS】Windows XP, Vista, 7 / MacOS X 10.x / Linux
【バージョン】0.9.1 / 0.9.2 / 0.9.3 / 0.9.4 / 0.9.5 / svnXXXX / 日本語版
【ソース】DVD / avi / mp4, m4v / mkv / ts / m2ts / その他
【コーデック】ffmpeg / x264 / theora / xvid + faac / lame / vorbis / ac3 / dts
【出力ファイルフォーマット】mp4, m4v / mkv / ※avi(0.9.4以後廃止)
【再生環境】プレイヤー、デコーダー、スプリッター等
【操作】〜を〜すると〜になる
【Activity Window】〜エラーが出力されている

Q.Stable と Nightly Builds のどちらを利用するのが良いですか？
A.安定動作を求めるなら Stable、不安定でも機能追加やバグ修正等を求めるのであれば Nightly Builds

Q.字幕を画像焼き込みでなく選択方式にできませんか？
A.mkvならできます。mp4コンテナはvobsubの字幕ファイル形式に対応していないので出来ません。

Q.日本の放送TS or wmv をエンコードすると音が出ない
A.0.9.5 もしくは Nightly Builds を使ってみてください

Q.映像のクロップではなく、黒帯を足せませんか？
A.残念ながら足せません

Q.AAC で 160kbps より大きなビットレートを指定できますか？
A.0.9.5 もしくは Nightly Builds では可能です。

Q.音量を上げられませんか？
A.SvnでGainが追加になりました。また、DRC を試してみましょう
　http://trac.handbrake.fr/wiki/DynRangeCompression
※WinならAACGain、MacはMacMP3Gainで調整可能。

Q.オーディオのないソースはエンコードできますか？
A.少なくとも Nightly Builds では可能です。

Q.DVD のタイトル 1 と 2、チャプター 1, 3, 5 をひとつのファイルにエンコードできますか？
A.残念ながらできません
　DVD2one などでソースを編集するか、個別にエンコードした後でファイルを結合しましょう

Q.エンコードした m4v ファイルのチャプターが認識されません
A.QuickTime 形式のチャプターに対応したプレイヤー（QuickTime, iTunes, VLC）で再生しましょう

Q.エンコード後に m4v ファイルのチャプターを変更できますか？
A.HandBrake ではできません。mp4v2 に含まれる mp4chaps などを利用しましょう
　http://code.google.com/p/mp4v2/
　http://kurtnoise.free.fr/mp4tools/

＜使用例＞
チャプター情報をテキストファイルにエクスポート
　mp4chaps -x hoge.m4v
チャプター情報を修正、インポート（Nero/QuickTime 両形式を有効）
　hoge.chapters.txt を修正
　mp4chaps -i hoge.m4v

Q.HandBrake を自分でビルドするには？
A.BuildSystem のドキュメントやコンパイルガイドを読みましょう
　http://trac.handbrake.fr/browser/trunk/doc
　http://trac.handbrake.fr/wiki/CompileGuide

【エンコード時の設定等】

＃アスペクト比
・H.264 ストリームに SAR を手動で設定する
　→ Anamorphic、keep aspect ratioを無効にして、Advancedにsar=40/33あるいはsar=10/11を追加

＃インタレ処理系フィルタ (detelecine, decomb, deinterlace) と fps 設定
・全編 60i
　→ deinterlace, fps は 29.97
・全編 30p
　→ フィルタなし, fps は 29.97
・全編 24p からのプルダウン済 60i 収録 (ハードテレシネ)
　→ detelecine+decomb, fps は Same as source (23.976 にしない)
　※23.976 固定にすると変なところでフレームが間引かれてカクカクすることがあるので、
　特に固定フレームレートにする必要がないのであれば Same as source の方が良いと思います。
・全編 24p 収録の再生時 2:3 プルダウン (ソフトテレシネ)
　→ フィルタなし, fps は 23.976 (Same as source にしない)
・上記の混合の場合
　→ detelecine+decomb(+縞が残る場合はdeinterlace), fps は Same as source
　　24p 部分のカクカクはあきらめる。
・プログレ化済みソースからの再エンコ
　→ フィルタなし, fps は Same as source

テンプレ以上

落ちてたんで建てておきました☆（ゝω・）vｷｬﾋﾟ

>>1
乙

>>1
乙

【OS】Mac
【バージョン】0.9.9
【ソース】mkv
【コーディック】x264
【出力フォーマット】mp4
【再生環境】iTunes
【設定】H.264/FrameRate:Same/ConstantQuality:20
元ファイルはアニメで24分で２GB程度、BDをリッピングしたものです。
エンコードすると暗部のブロックノイズが気になる程度に現れます。
Youtubeのようにファイルサイズを抑えつつ画質を維持したいと考えています。
アドバイス等いただけると嬉しいです。

日本語版はいつ0.9.9にバージョンアップするんだよ。

もう来ないと思うよ
誰かがいらん事言ったからリリース辞めたんだってさ

348 名無しゲノムのクローンさん：2014/04/22(火) 10:37:01.76
>>332
実はこれが一番問題じゃないかと思う

＞早稲田内部では未だに何が問題か理解されてません
＞新潮４５より

色々深い考えが有って政治やマスコミを動かすインテリジェンス（）の集合かと思っていたが
これだと、なかなか難しいね。

370 ：名無しゲノムのクローンさん：2014/04/22(火) 10:45:29.66

いやほんとそうだと思うよ今回の深層は。
伝統的に科学とも言えない疑似科学で花火打ち上げたり金集めたりと学生サークルのノリでやってる人達が
たまたま再生医療という追い風で政府のブレーンになったり座長になったりして発言力を持っちゃった。
だから本人たちは悪い事をやってる感覚すらなく、何でこんなに追及されなきゃあかんの？ネット民てしつこいんだなぁ
ぐらいのレベルでやってるんだろうと思う。所長とか教授とかやってる年のひとですら。

誤爆

deinterlaceをbobで60pにエンコしたい場合、fpsはどうしてる？
Same as sourceでいいのかな。

俺はDetelecineをデフォにしてFPSを60fpsにしてる
それでも残像が出たらDeinterlaceしてる
Deinterlaceだとギザが出る、Decombだと画質がボケる
Detelecineだとギザが出ないし、画質がちょいシャープになってくれるから
インタレ解除はDetelecineをメインに使ってる

>>14
59.94でしょjk

>>15-16
ありがとう！
今試したところ、自分の映像では
>DetelecineをデフォにしてFPSを60fps
だとギザるので、deinterlace, bob, fps59.94 でやることにします。

ディスプレイが60Hz対応なら60FPSでしょ
http://www.cri-mw.co.jp/product/column/2nt4hm0000001l09.html

VAIOの設定のMotion Reality設定だと、59.94Hzになってるけどな。

2006年()

俺のディスプレイは60Hzだぞ

2010年のVAIOだけど、59.94だわｗｗ

日本語バンだと User Query: Falseってでて変換できないんだがどうやったら治る？

日本語版を使用しての不具合に関しては日本語版配布元で質問してみましょう。

ふと思いついてmp4で字幕を焼き込まないで変換してみたら、普通にできた
Playerはvlcで複数字幕の切り替えも出来たんだけど、対応したのかな？

録画ソース(映画、アニメ)でオススメの設定とか皆さん有りますか？

映画と実写はRF22,アニメとアニメ映画はRF18

＃アスペクト比
・H.264 ストリームに SAR を手動で設定する
　→ Anamorphic、keep aspect ratioを無効にして、Advancedにsar=40/33あるいはsar=10/11を追加

テンプレ古すぎないか　全然これどおりじゃないぞ

言い出しっぺの法則というのがあってだな

HandBrake 0.9.9.5530 GUI使ってま。

PCでは音ズレしないんやが、アンドロ端末のSocのHWデコード、単体メディアプレーヤ類のSocのHWデコードでは音ズレしとったんやが、
FramerateをSame as SourceそのままにVFRをCFRにしたら音ズレしないようになった。

ただ、もう500ファイルほどVFRでエンコしちゃってファイルももう消してもうた後なんやが(´・ω・｀)

>>26
ビットレートは人それぞれだろうけどそれ以外の設定はまとまってるとトラブル少なくなるね。

今更だがインタレ解除でやるより
デテレシネ+decombでやった方が綺麗にできるな時間かかるけど

--decomb=395が結構気に入ってる

てすｔ

最近のA○-Xは24fと29f混在プログレ仕様だから24f固定だとカクつくよ

だから
--decomb=395 --detelecine
で全部解決だつーの

いいえ、細かい事を気にしな方がいいわ、

http://critic20.exblog.jp/22197266/
NHKのニュースと毎日の記事は、改革委の岸輝雄の動きと連動している。
岸輝雄は、6/2に、理研で行われている「STAP細胞」の検証実験に小保方晴子を参加させろと要求、その意向をマスコミに捲き、
理研が進めている小保方晴子懲戒処分のシナリオに待ったをかけた。
岸輝雄は、野依良治による事件の解決の仕方に猛反対で、前回（5/9）、「再調査せず」の決定を下したときも、
調査は未だ不十分で懲戒委へ持ち込むのは拙速だと文句をつけ、調査をやり直ししろと理研を批判していた。

岸輝雄と野依良治の間で熾烈な権力闘争をやっている。2chの議論はその点の認識が弱い。
2chの面々は、岸輝雄を正義の味方のようにナイーブに信じ込んでいるが、それは少し怪しい。
私の見方は少し懐疑的で、岸輝雄が、野依長治を追い落として理研の理事長に収まろうとしているように見えてならない。
岸輝雄の主張は、基本的に正論なのだが、理研叩きの裏側に小保方擁護の真意があるのではないか。
（中略）
その主張の先に、野依良治に対する責任追及の意図があるのは丸見えで、それはまた世論の支持を受けるものでもある。
そして、この岸改革委による反野依の動きと毎日の須田桃子の記事が連動している。両者が手を握っているように窺われる。
果たして、岸輝雄は本当に小保方晴子を断罪する意思があるのか。もし、それがなく、単に野依体制を潰すことだけが
岸輝男の狙いで、理研叩きの正論は政治の道具であったとすれば、われわれは岸輝男に裏切られることになる。
（中略）
私の疑念は、岸輝雄が、裏で下村博文や安倍晋三と繋がっているのではないかというものだ。

（論評）
面白い仮説ですが、もし小保方、さらにはその後ろにいるTWIns、早稲田応用化学と下村、安倍が繋がっているとすれば
今単に揉み消しをやるだけではなく、積極的に理研の首脳部の罪をでっちあげ、組織の頭を挿げ替えることで事件の鎮静化を図ることを
必死になって画策しているはずです。一見正論で解決に向かっているように見えるここ数日の報道も、より大きな悪玉のシナリオに乗っている危険性を加味したほうが良いかもしれませんね。

誤爆失礼

>>4
テンプレの方法でアス比指定しても、sarを正しく解釈してくれる再生プレイヤーは一部（mplayer系）だけだと思うんですが、これって外出ですか
自分はMPCで見るために、エンコ後にMP4Boxでアス比だけ再指定してるんですが面倒です
皆さんはどのようにされてますか？

アンカー
>>5の間違いでした

>>39
とても面倒そうですね。

>>39
MPC Video Decoderのフィルタ設定でストリームからアスペクト比を取得するオプションにチェック入れれば
ちゃんと反映されるようになるよ (デフォルトの半チェックではなく完全チェック)

>>41
バッチ書いてファイル投げるだけにしてるので
作業自体はそんなに大変じゃないすけどね

>>42
「オプション→内部フィルタ→ビデオデコーダ→Use Stream Aspect Ratio」にチェックですね
こんな設定あったとは、、
ありがとうございます！

CLI でQSV使う時のextraoptionって皆さんどうしてますか？

どうすれば良いかの一般値はないけどオプションのガイドをみてトライエラーやってみれば？
https://trac.handbrake.fr/wiki/QuickSyncOptions
まずはデフォルトを基にいろいろ変えてみる。一般的に品質はtarget-usage
あとHaswell以降ならlookaheadを使ってみるとか

トラック1しか変換できなかったんですがどこをいじれば全トラックを1つのファイルにできますか？

>>46
にほんごで

HandbrakeCLI 0.9.9 なんだけどCPU指定オプションないんだな！
メインPCなので復活頼みたい。

CPU占有率についてはOSの機能に任せる方がいいから無くなったんだろ。
OSにやらせれば良いんじゃね？

x264でエンコードするならtheradsオプション使えるけど
普通にプロセス制御うまく出来てるから、いじらないほうが良いと思うけど。

なるほど、OSにやらせるんですね。。
CPUオプションがなくなったのも理由があるでしょうし。

>>1
のフォーラムに今のNightlyのGUI版文字化けうんたら書き込み英語できる人頼むわ。

このままStable版が配布開始になったら日本語文字化けなんだぜ。

>>51
翻訳すれば相手が意味を理解できる「日本語」を書くのだ。
そうでないと「untara」とか書かれちゃうぞ。

>>51
文字化けしてるん？
普段デフォでしてるorファイルリネームで対応から気にしなかったなぁ

0.9.9で、iso化したホビット〜思いがけない冒険のDVDを
変換すると、スタッフロールにて英語字幕は
問題無いけど
日本語字幕は表示されなくなるんだが、HandBrakeの
設定次第でなんとかなるかな？　スタッフロール以外では
日本語字幕もちゃんと表示されるんだよね。

通報しますか

なぜか分からんけどHandBrakeだとDVDの字幕が一部だけ欠けることがあるな

他のソフトのほうがいいの？

そろそろ1.0.0出せ

クロッピングすると字幕の位置がおかしくなるな

そりゃそうでしょ
プレイヤー側で黒帯を追加すれば良い

WIN7でhandbraleCLIなんですが、優先度を下げたいのですが、どのアプリ使ってます？

オートギアというのを試してみたんだけど、HandBrakeCLIを指定してもオートギアのログに変更しますたの記録が出なくて対応していないのかな。

CLI使ってるなら普通にstartコマンド使えばいいじゃんよ…

そりゃhandbraleCLIを使っているのにオートギアでHandBrakeCLIを指定しても意味が無かろうて。

みなさんありがとうございます。
詰みました。
バッチファイルのどこに入れたらいいのか全然分かりません。

こんな感じ
・優先順位通常より下
・startコマンドのプロセスが終了するまで、呼び出し元のコマンドプロンプトを待機

start /belownormal /wait handbreakcli.bat

もちろんバッチファイル（handbreakcli.bat）呼ばずにhandbreakcli.exe直接呼んでもいける
そのときは/wait要らないかも

本当にありがとうございます。
大きなヒントをもらった気がします。もうちっとがんばってみます＜＿＿＞

>>66
補足というか訂正というか・・・：
上でhandbreakcli.batと書いていますが、名前は固定ではありません
任意名のバッチファイルのです
バッチファイルの中身に、handbreakcli.exeの処理を記述してください

>>68
さらに補足：
>>66 にならってバッチファイルを呼び出す場合、
呼び出し先の処理の最後の一行には
exit
を書いてください
書かないと呼び出したコマンドプロンプトが開きっぱなしで
呼び出し元のコマンドプロンプトに戻ってきません

>>67
レスありがとうございます
後出しで、補足してごめんなさい
（昔作ったバッチ読んでるうちに記憶がよみがえってきまして・・・）

>>61
解決したっぽいけど、

俺はprocess Hakerつかって適時みてる

情報ありがとうございます＜＿＿＞

今日まで手動でHandBrakeCLIの優先度を下げていたのですが、順次エンコが終わって、次のエンコが始まるたびに優先度が元に戻るもんで8TS録画の時は厳しいんだろうなぁとエンコ自重していましたが。

あれから、そして今日色々やってみたところ、サブのバッチファイルでメインバッチ呼び出しのところにstart /belownormal /wait ほげ.BATをかましメインバッチにはexitを付けて無事解決しますた。
みなさんに感謝感謝です！

知らない間にnlmeansが導入されてるのね

昨日、一年ぶりぐらいにPCの中を掃除した。
CPUのファンも取り外して徹底的に積もった埃を取り除いた。
昨晩中エンコしてCPUをぶん回したところ、これまでCPU温度が最高62℃位だったのが56℃くらいまで下がった。
皆さん、時々PCの中を掃除しましょうね。

一年でそこまでなるか？
まぁ、季節ごとに掃除してるから気にならないだけかもしれないが

PCの床置きは机上の倍以上は埃を吸い込むな。おまけに
寝床がベッドでなくて布団の上げ下げだと、さらに埃を吸う。

nightly5xxxから久しぶりに新しいnightly入れてQSV走らせたらAviutlのQSVEncより画質良いんだな
エンコした映像の服の縞が全然違って驚いたわ
QSVEncの方は縞が潰れてしまってるけどHandbrakeの方は綺麗に再現されてる
これならHandbrake使った方が綺麗だし簡単でいいね

床置きだが、ベッドで寝るからかな
布団干すときくらいしか上げ下げしない

まあHandBrakeは世界中で使われるからインテル関係者も開発にかなり関わってるのがフォーラム見ても判るわな
QSVEncはAviutilになれてる人には使い勝手良いだろうけど開発は1人だしユーザー層も国内限定だから、その差は出てきてると思う

編集+エンコならAviutlのが使い勝手いいけど、単にmp4変換するならHandbrakeのが良いね
ただ、ファイル名に2バイト文字使うとエラー吐くときあるからエンコ時はファイル名にリネーム必要だけど
分かってて慣れてしまえばどうってことないかな

tsを放り投げてエンコするだけならhandbrakeほど簡単なものは無い

TS 放り投げてエンコするバッチファイルと、それをラップして複数ファイルまとめてエンコするバッチの2つ
作ってエンコしてるわ。マジ楽。

適当な番組のエンコにQSVEncCを使ってたけどHandbrakeも試してみるか
2バイト文字はリネームツール使えばある程度どうにかなるし

バッチで投げるならリネームは必要ない。2バイト文字名での入力にバグがあるのはGUIを使う時のみ

"Windowsの"GUIのみ、かな?

>>85
確かそーだな

まあ、リネームだけだから大したことはないし、ソース弄れれば前スレかなんかでやって使えるようにしてた人いたよな

CLIだとQSVもExtraOptionでいろいろ葬れて、
いい感じに調整出来るからオヌヌメ
https://trac.handbrake.fr/wiki/QuickSyncOptions

QSVをあれこれいじってるんだが、品質でエンコードすると、出力されるファイルの大きさの差が QSV 使わないときよりも大きいな。

863 ：名無しさん＠編集中 [↓] ：2014/02/15(土) 22:23:36.90 ID:F+eSZn+H
GUIのファイル名文字化け治ったわ

HandBrakeInteropのhb_title_s.pathの型をstringからbyte[]に変更して、
HandBrakeInstance.csでエラー出てる
1810行目のPath = title.pathはPath = Encoding.Default.GetString(title.path).TrimEnd('\0')
818行目のbyte[] bytes = Encoding.Default.GetBytes(title.path);はコメントアウトして、その下の行をstring utf8Str = Encoding.UTF8.GetString(title.path).TrimEnd('\0');に書きかえればOK

これを誰かわかりやすく説明してくださりませ

文字化けする箇所の変数の扱いを書き換えてるのだろうと適当に妄想してみた。
口と顔と金銭運が悪いのを承知で敢えて言うけど、それ見て解らんなら諦めれ。
諦めないと言うならば、VisualStudio入れて、書いてある通りにやってみりゃええんでなかろうか。

ちなみに俺は諦めたので、草葉の陰から応援しとく。

俺も諦めてリネームツールでファイル名変えてからやってる

このまま行くとWIN-GUI版は文字化けのまま正式版になるんだろうな。。。

とりあえず本家のbugs forumにレポートしてみる

よろしゅうたのんます。

>>25
Stableだと、mp4でもソフト字幕できるね。
Nightly Buildsだとダメ。何が違うんだろ。HE-AACが使いたいのに残念だ。

ちなみに、ソフト字幕では、PCのVLCとandroidのMX動画プレーヤーで再生可能だった。

Q9650/Q45Exなマシンでエンコード速度15fps程度の設定。
これを1.5倍速/2倍速にしようと思うとマシンの目安どれ位?
CUDAなどはなしの方向で、HandBrake専用で考えてOK。
よろしく。

>>97
この辺を参考に自分で見積ればいい
http://www.servethehome.com/wp-content/uploads/2012/05/Intel-Core-i7-3770K-Handbrake-x264-Benchmark.png

DVD字幕はMP4で字幕選択出来るのに
BDでは強制焼き込みになっちゃうな

nightlyダウンロードできない...

すいません
チャプターが勝手に一つずつしか変換出来なく成ってるのはどうやれば全部一括で変換出来る様に成るんでしょうか？

出来なくなったのなら出来ていたときの環境にもどせばよい

>>102
いえ、最初からできません

チャプターとしてオーサリングされてるのなら一つずつしか変換できないとかいうのはない。
タイトルとして分けてオーサリングされてるのならそれぞれ個別に変換するしかない。

nightlyでHEVCエンコ可能になったな

このソフト、別途 x264をインストール必要はあるのでしょうか？

自動で黒い部分をクロッピングする機能を切りたいのだけど設定どこにある？
たくさんのファイル一気に変換したい時に1つ1つ設定するのめんどい…

>>106
バイナリなら要らない。
ソースtar玉からビルドするときは要る。
SVNリポジトリからビルドするときは要らない(勝手に取ってくる)。

>>107
カスタム0:0:0:0にしてその他の設定をした上でたくさんのファイルをHandBrakeにD&Dすればいいよ。
サイズはオリジナルのままになるけど。

>サイズはオリジナルのままになるけど
そんなことはない。

助けてください。

【OS】Windows 7 Home 64bit
【バージョン】0.9.9.5330 64bit/英語版
【ソース】Blu-RayをISOにしたものを仮想ドライブにマウント
【コーデック】x264
【出力ファイルフォーマット】mp4
【再生環境】 WMP
【操作等】

これまで30分ほどで終了していたエンコードが2時間以上掛かるようになってしまいました。

HandBrakeを三ヶ月ぶりくらいで使ったのですが、特に設定は変えていないはずなのに
エンコードが非常に時間が掛かるようになってしまいました。
ファイルの問題かと思い、以前、30分ほどで終了したファイルを試してみましたが、
そちらも予定終了時間が2時間以上となっていました。

関係ないと思いますが、最近の変化点としては、パソコン用のTVチューナーを
購入したため、それのドライバやTVtest、TVrockといった再生・録画を
インストールしています。

また、以前はエンコードをしている間はファンがかなりの音で唸っていたのですが、
今はまったくファンの音がしません。ですが、CPUはほぼ100%で動作しています。

何か気がつく点はないでしょうか。

ちなみにコンポーネントのスコアの評価を再実行してみましたが、
以前と変化はありませんでした（7.4〜7.9）。

CPUの動作クロックと温度見ろよ

ありがとうございます。直りました。

確認したところ、最大周波数は33%、温度は50〜60度でした。
ファンを確認したところ、埃が溜まっていたため掃除機で吸いだしたところ、
ファンが回るようになりました。

ファンが回らない→ターボブーストが効かない→最大周波数33%より上がらない
という流れだったようです。

エンコードをやり直したところ、現在は最大周波数100〜130%くらいで推移しています。
エンコードしながら他の作業しても軽いｗ

買って一年、もっと早く掃除するべきだったのかもしれません。
以前のパソコンは埃が溜まると熱暴走で強制的に電源が落ちたので
掃除の時期がすぐに分かったのですが、今のパソコンは特に
変化がなかったので気が付きませんでした。

本当にありがとうございました。

1.0.0リリースされたら日本語化を復活して欲しいです

>>113
掃除もだけど、埃が出にくい、入りにくいようにする努力もしようぜ

DVDfabがCUDAとH.265に対応したんだが

fabて一時期鯖止まってたけどなくなっていないのか？
とうに潰れたと思ってた

>>117
comドメインが差し押さえられたけど、cnドメインで絶賛営業中

fabをリッピング以外の目的で使うのは情弱

fabで磯から、mkvBD50無劣化変換すると
結構容量減る場合がある

0.10beta出てる

ガタッ

48ｋhzまでしか対応してないんだっけ？

32bit切り捨てられた？

ベ、ベータ版だから（震え声）

Vista32bitの俺はWin9まで待つ

【OS】Windows 8 Pro 64bit
【バージョン】0.9.9.5330 64bit/英語版
【ソース】地デジTS、３時間もの
【コーデック】x264
【出力ファイルフォーマット】mp4
【再生環境】 MPC
PictureのSizeはStrict
フィルターのDeinterlaceはslow
ビデオのクォリティはRF25
オーディオは96ｋｂ/ｓ
この設定で２時間以上のTSエンコすると何故か320ｘ180、200ｋｂ/ｓ
とか低解像度で出力されてしまう。

同じ条件で３０分とかなら普通に出来る。

7年くらい続いたv0.9.X時代も終わりか。
ついに時代はv0.10.Xの時代へ。

>>126
ワンセグ含んでるTSってオチ？

>>128
いや、テレ東とかNHKとか普通の地デジ
ワンセグ含んでるかどうかはよくわからん。

TSSplitterを三年間ググってろ

TSSplitterググったけど混在とかそういう原因じゃないような気がして、HandBrakeって時間的制約ってあったっけ？
HandBrakeでダメだったTSファイルをFreemake Video Converteｒでエンコしたらちゃんとできたし（ただRF設定とか細かい設定ができない）
2時間以内なら問題なく出来るところが分からん。

320×180はワンセグの解像度だからtsのデータからエンコする素材を選ぶ時にそっちを選んじゃってる気がする
tssplitterでSDとHDを分離してみてからHDを使って同じ条件でエンコしてみてよ

tsの別のストリームを選んでるかどうかってログには出力されないんだっけ

>>132
了解そういう可能性か・・・tssplitter勉強してやってみる。

Stableはよ

nightlyやベータだと、軒並みmp4のソフト字幕が無効になるんだが、今後のバージョンも潰されたままってことなの？

opusに対応しないの？

【OS】Windows8.1
【バージョン】0.9.9以上
【ソース】ts
【コーデック】x264
【出力ファイルフォーマット】mp4＆mkv
【再生環境】プレイヤー関係なし
【操作】
Ver0.9.8まで「既存プリセットを選択後、VideoタブでAvg bitrateを選んで複数の動画をエンコードしてから、出来た動画を結合する」という使い方をしていたが、0.9.9やNihgtly buildへアップデートすると結合出来なくなった。

ちなみに、どのプリセットを選んでも同じく結合が出来ないがConstant Qualityにすると結合出来る。
これは0.9.8と0.9.9以降だと、どちらが正常な動作なんだろうか？

>>138
mkvのmkvmargeもmp4のyambも違うビットレートの追加結合はエラー返すから、
0.9.9からの仕様が正解だと思う。というか、今まで結合出来ていたのが不思議。

>>139
結合はUniteogmでしていたのですが、確かにビットレートが違くても結合出来てました。
もちろん、再生もどのプレーヤー使っても完璧でした。けど、0.9.9以降が正解なんですね。

しかし、Constant Qualityでもビットレートが違うのに結合出来るっていうのは？？
1パスか2パスとかは関係ないようなんですが、そういう仕様ってことで納得するしかないのかな…。

【OS】Windows8.1
【バージョン】0.9..3-ｊｐ-B1
【ソース】イメージファイル
【コーデック】x264
【出力ファイルフォーマット】mp4
【再生環境】プレイヤー関係なし
【操作】
CPU使用率が100％でCPU温度が100度まで上がります。
4790K　定格ですが少しエンコードの時間が伸びても良いので
負荷を減らしたいです。
このソフトの設定ででCPUの使用率を変える事はできますか？

電気エネルギーを熱エネルギーに変化させる次世代コンバーター

>>141
QSV使えばどうかな？

>>141
エンコードするならクーリング環境見直した方が良いよ
新CPU出るたびに買い換えるオタクなら短命でも構わないんだろうけど

>>141
>>144の言うとおり、ウチの環境でリテールクーラーでも80度代
サイズの兜2、釜クロスで60度代なので負荷を減らすことよりも冷却を考えたほうがいい。
但し、ケース内にドライアイスを入れたら氷柱ができてしまったことがあるので注意

ついでに負荷を減らすなら、タスクマネージャーで優先度下げてバックグラウンドに移したり、使用コアを減らす方法があると思うけど、Handbrake自体にそんな機能があるかどうかは忘れた。

優先度下げるのは設定にある
使用コア減らす設定は多分無い
CLIを直接使うなら start /low 等で優先度下げられる

言い忘れたがスレッド数ならx264側で下げられる

クーラーの取り付け方が悪いだけ。100もいったら勝手にクロック落ちるだろ

バトルエンコーダー白瀬

>>143
このバージョンで可能ですか？
>>144
タワーのケースで中はわりとスカスカなんですが・・・
ケースファン*3　リテールクーラーより少しマシなCPUクーラーです。
>>145
リテールクーラーで80度台なんですか？
>>149
もちろん100度でクロックが落ちます。
ブッシュピンじゃなく後ろにプレートがあり螺子でしっかり固定するタイプですが
確認の為、暇なときにばらしてみます。
負荷が少ない時は40度くらいなんですけどね・・・

>>151
とりあえず、自作板に行ってCPUの冷却について相談してこい
話はそれからだ

>>151
ケース内スカスカでも負圧だから冷えないんじゃないの？
>>1521氏の言うとおり冷却スレで相談か実店舗で店員にでも相談したら？

Battle Encoder Shirase

>>154
窓8.1で動かないからスルーしてんじゃないの？
うちは7までしかないからわからんが

ねじは締めればいいってものじゃないからな。傾いてる典型例だ。

>>151
まさかグリス塗ってないとか無いよなｗ

>>157
グリスはシルバーグリスです。

>>158
てめえのマシンは自作機()じゃなくて駄作機なんだよ！
まず、その糞シンをどうにかするところから始めろってみんな言ってるだろ？

>>159
それは理解しています。なんとか対策する予定です。
ただ時間がないので時間が取れる時までの応急的な対応で
ハンドブレイクに詳しい皆さんがいるスレで
ハンドブレイク上で負荷を減らせる設定はないかと思いまして。
もちろん電源OPの詳細設定からCPUを90％くらいにすれば良いのですが
全コアフル稼働は使用してるソフトウェアではハンドブレイクしかないので
電源OPの設定を変えるのも気が進まなくて。
レスくれた皆さんありがとうございました。
とりあえず電源OPで負荷減らし、時間が取れる時にハードウェアの問題を解決します。

バトルエンコーダー白瀬

いや、即座に根本対策しろよ

なお、ここはハードスレでもハンドブレイクスレでもない。

武器が一定時間持てなくなりそうな技っぽいなハンドブレイク

Handbrake = ハンドブレーキ

http://youtu.be/t14JeJXtFOQ
http://youtu.be/FB0ji_3Uees

snake スネイク スネーク スネーキ スネエキ
cake ケイキ ケーキ ケイク
lake レイク レーク
shake シェイク シェイキ
brake ブレエク ブレーク ブレーキ ブレエキ

カタカナなんてどうでもいい

アイスコーヒー
アイスモーヒー
ナイスコーヒー
マイスモーヒー
ナイスコーチ
アイソワライ
コーヒーコーヒー
タンスノーヒー
アツイコーヒー
アイツモーイー
ハインサイティー
アイアンヒーロー

うっぜえなあ

動画をプリセットにない形式にエンコをしようと色々と調べて試行錯誤している
動画の形式って、色々面倒な経緯があったり、やたら規格があって面倒くさいな

ついでに圧縮の方法について勉強しておこうと思ったが俺には無理だ
離散コサイン変換？量子化マトリックス？エントロピー符号化？

わけがわからないよ

そんな言葉と意味を勉強する時間より全ての圧縮パターンを試す方が早いだろう

上下の黒い帯部分に字幕を表示したり、縦方向に字幕を表示することってできる？

休みにPCバラしてファン*2増設、新品のシルバーグリスで
CPU100％張り付きを2時間くらいHandbrakeでエンコードしましたが
90度くらいで踏みとどまる様になりました。
85度前後をウロウロです。
これでハンドブレーカーの仲間入りです。
レスくれた人ありがとうございました！

ブレイクする人がブレイカーなら、ブレーキする人はブレーキャーなのかな。
何はともあれ、おつかれさん。

90度前後でも2時間程度なら問題ないんかな、使い続けたら寿命が縮みそうだが。
でも、まぁリテールでその程度なら思った以上にシルバーグリスの効果ありってことなのか。

>>173
リテールクーラーより少しはマシなのをつかってます。
ttp://www.scythe.co.jp/cooler/monochrome-pro.html
0.9..3-ｊｐ-B1のバージョンをつかってます。
ハンドブレーカーさんのおすすめバージョンはどのバージョンでしょうか？

svnリポジトリの先頭

ケースの都合だろうが簡易水冷なら60℃くらいになるよ。
エンコ設定の意味を把握するまでは正式版、わかったら常に最新。バグか設定が悪いか判断できないとね。結局、３つくらいのバージョンを常に使うエンコ厨になる。

俺も前のマシンで異常発熱してて頭を捻ってたけど
試しに標準で付いてたIntelのリテールクーラーに戻したら発熱が収まったことあるよ
調べたらブッシュピンが1本弛んでた
関係無いかもしれないけど参考までに

そのCPUのレビュー記事見ると
OCすれば90度近くになるってあるけどねぇ

ケースに入るならトップフロー型よりサイドフロー型の方がいいよ。
ちなみに、ウチはi5-4690SにETS-T40-TBの組み合わせだけど、室温26℃でエンコても48℃ぐらい。

http://www.enermaxjapan.com/cpu-cooler/ETS-T40/ETS-T40-TB.html

>>174
そのクーラーじゃエンコPCにはリテールと同じようなもんだよ、ケース内がスカスカなら>>179のいうようにサイドフロー型にしなよ
エンコ時でも10〜20度下がるぞ。

そしてHandBrake0.9.3はさすがに古いから、日本語翻訳版がいいならとりあえず0.9.5だね。
正式版の0.9.9や0.10βは不安定な事もあるから、個人的には0.9.8がオススメだけど。

最近のチップは温度が危険域になると処理を落として温度を抑えるんでしょ?
だからといって冷却設備が要らないとか言わないけどね。

>>180
レスくれた皆さんありがとうございます。
サイドフロー型にしたいんですが、マザボをケースに入れたまま交換は難しそうなので
ケースから出すとなれば億劫ですね。
連休があればチャレンジしようとおもいます。
0.95試してみます。

>>182
一週間も前に>>144で言われてたのにまだやってたのかよｗ

レアな話題より啓蒙も兼ねていいんじゃない。qsvとaacパスするーがやっと動くようになったとかレアでしょ。

HandBrakeCLIでx264で使う場合の--qualityの数値は
x264の--crfと等価ですか？

>>185
GUIだとそのへんチップヘルプで説明してるよ。Linux版では。

相変わらず性格悪いですね。

>>186
公式のCLIガイドにも書いてあるから、わざわざLinux版の情報を出してやってまで教えてやる必要は無いってのに、面倒見のいい奴だなお前は。

英語できない奴は平気で嘘をつくよな。

Stableはよはよ

必殺ハンドブレイク
手は死ぬ

文字化け直らないね

日本語でバグ報告しても開発者は文字化けして読めません。

Nightly 6404でそれっぽいのキタ

WinGui: Currently hb_title_s.path is directly marshalled as string.
But this isn't good because path is UTF-8 encoded C string,and fails with non-ASCII characters.
To fix this, treating path as raw UTF-8 byte array and converting to string in ConvertTitle() method should work.
Patch Submitted by Taihei, review 760

さっさとビルドするか、もうちょい待てばDLできるでしょ

そうだね。何とか0.10に間に合ったか。

文字化けなおるーーーーーーーーーーーーーーー！！！！！！！！！！！！！！！！！！！！！！

これは朗報。

CLI版使ってるけどGUI版使うときもあるから。

qsvでエンコするにはnightlyの使わないと項目ないよね？
ファイルが日本語だと読み込み時にエラーで相変わらずだめだった
これが治りそうなの？

GUIのみビルドして試したら治ってる。
と、おもったらNightly BuildsのDL更新されてた。

Nightlyの今ダウンできるやつで文字化け治った感じになっとるね！！！！！！！！！！！！

日本語名出力に対応したか

これで0.10.0を安心して迎えられるな
QSVもx265も正式サポートして他のエンコードソフトに比べても爆速高品質の最強バージョンになりそう

一応記念としてageとくは。

0.10.0は前Windowsの32bit版は出さないとwikiに書いてあったけど最近出すことに訂正したみたいだね。
メモリの制約があるから非推奨とは書いてあるけど。XPがサポート対象外になるのは残念だけど
マイクロソフト自体がXPサポート対象外の時代だからしゃあないか。

XPにも64ビット版があるだろ
誰も覚えていないかもしれないけど

ライセンス持っているけど使ったことねえやｗ

おおx265対応したのか

検索窓にQSVって打つとこのソフトが候補で出るｗ

一応Bug ReportもFixedにしといたよ
https://forum.handbrake.fr/viewtopic.php?f=12&t=30408
実は日本語名のDVD-ISOファイルを直接読ませる（Source欄にD&DするとかCLIで直接インプットファイルにするとか）と
チャプタ情報を正しく読み込めないという別のバグが残ってるんだけど、そもそもBlu-rayのISOは直接読めないんだし
端折らずISOはVCDとかでマウントしましょうということで、大した問題じゃない。

それにしても対応したTaiheiって人は日本人みたいなHN

mp4に勝手にiTunes Info入れるのをoffにできませんか？

何かTSファイルバッチ処理させるとフリーズしてたり出来たファイル音ズレしてたりするんで様子見

CLIのQSV対応版って32bitだと使えないよね？

0.10.0ベータ版使えば？一応32bit版あるしQSVが64bit限定とは書いてない。

>>209
Nightly6404の話？きのうから試しに20個ぐらいtsをエンコしてるけど、Stable版やNightly5671と同じぐらい安定してるよ。
もともと0.9.9になって音ずれは起きにくくなってるんだけど、特に変わってない。
音ずれは一旦エンコしたのをソースにして再度エンコした時に時々出るぐらいで、この辺も同じ。

なんだこの便所の落書きスレは

tsのAACをパススルーするとER Parametricになってしまうのは変わらずか。
再生環境が限られるのでffmpegで一手間かける必要があるから、結局最初からffmpegでエンコしてる。
QSVは便利なんだけどね。

お、重箱隅のネガキャンちゃんが深夜の連投か。最近変なレスが時々付くようになってるしな
それだけhandbrakeも有名になったって話だは

TSで録画した5.1chの音声付きのをエンコするときみなさんどうしてます？

ぱすするー

マジっすか。
パススルー自分ちょっとやってみたんですが、エンコードが完了しないんですよね。

5.1ch番組でもEDCBで2秒のりしろ、番組冒頭、本編始まるまで5.1chじゃないですもんね。

>>215
HandBrakeが今更有名になってるとかｗ
そいつは昔から5.1chAACパススルーに粘着してる奴だから無視するだけ
http://toro.2ch.net/test/read.cgi/avi/1314361029/89-
エンコードするのに音声だけオリジナルのままを求める奇妙な一点張り

オリジナル維持にこだわるならエンコードしなきゃいい話なのに

脳内で会話してる人がいるな。5.1chが2chでエンコードされると0.5秒周期でノイズが入る。splitterの問題かと思ってる。こいうのはパススルーで後でスマレン使う。ソースのチャンネル数をいちいち気にするのが面倒なのでパススルーにしとく。

Nightly 6409に移行完了
x265が随分速くなってるな。x265側の開発が進んでるおかげだけど。

6409のICCでのmakeが通らん。ムラムラしてきた。

>>220
解約したから確認していなかったけどWOWOWをエンコすると出るノイズはまだ残っていたのか。
少し前のバージョンだとノイズが入らないので今に治ると思っていたんだが

元tsからノイズは出る。tvtest, powerdvdでは出ない。mpc, vlcだと出たと記憶してる。変に再エンコするとノイズが固定化される。

>>216
Star-chの5.1は問題がないが、WOWOWの5.1chのイントロのタイトル画面はクセモノ。
TSの切り出し開始位置によって5.1chとして認識されたり、2chとして認識されてしまったりします。
私は、15秒間なり30秒間の短い長さで先頭を切り出してみて、TSmuxeRにかけて、
ちゃんと音声が5.1chだと認識されることを確認することで、開始位置を十分に
吟味したうえでその開始位置から切り出したTSを使うようにしています。
(Mediainfoで5.1chと認識されてもTSMuxeRでは音声トラックが認識できない場合が
あります。　TSMuxeRのほうがチェックが厳しい。)　ffmpegでaac(5.1)→ac3(5.1)の
トランスコードをしていますが、このようにチェックを経て得た終始同じ音声モードの
TSを入力する限り、問題が起きたことは一度もありません。

>>225　追加付記すると、入力TSはMurdocCutterでエラーチェックを行って、
エラーなしであることが確認できたものだけを扱っています。　Dropなど
エラーがあるTSは当然、対象外です。

>>225
ありがとうございます。
確かにクセモノだと思ってました。

Nightly buildが毎日の様に更新されるけど、これってexeだけ上書きで良いの？
それとも毎回きちんと入れ直さないと意味ない？

更新された部分による
例えばこの前の文字化け修正なんかはexeを入れ替えても意味はなくて
HandBrakeInterop.dllを置き換えないとダメ

changelogを見てどこが修正されたか分かるならファイルごとの置き換えでも良いんじゃない？

265早くなってんのか
石がx980だけどそろそろ試してみるかな
いつもはBlu-rayを猿でそのまま264にしてるが実時間の半分ってとこ

>>230
対象によるとは思うけど同じcrf値でx264の1.8〜2.2倍の時間に収まるようになった感じ
マルチコアはx264より効きが良いみたいなので、980xなら有効かもね

>>231
レスありがとうございます
OCで4GまであげてるけどQSV無いし時間はそこまでこだわらないんで
容量削減できるからアリですね
猿はクダ使ったら早いけど不安定なんだよな
最新では265対応してるけどちょっと比較してみるかな

x265やっぱり早くなってるのか
6295から最新版にしたら2倍以上早くなっててビビった
プリセット間違えたかと思ったよ

X265スレにもあったけどもう実用レベルだね

>>220
0.9.9以降のデコーダーの問題。VLCでも同様。
これについては今の所諦めて0.9.8使ってる。
パススルーだと音ズレがでない？

>>229
なるほど、ファイルごとの上書きってことならOKなんだな。サンクス。

>>236
CLI中心に使うなら配布されてるHandBrakeCLI.exeをどんどん更新していくだけでOK

>>235
cliでtsなら最近ずれたことはない。guiでisoとかは週変わり。先週はズレてたけど6408あたりでなおった。安心はできない。全部qsvでのはなしだけどね。

それより、NtghtlyとかベータはなぜMP4のソフト字幕が無効になるのか。

6409は6170と比べてH.265はほぼ倍の速度になるけど、全く同じ設定で出力サイズは1割ちょい大きくなるな
HandBrakeじゃなくてx265 1.3の特性になるけど、まあ今は速さを上げていくのが優先なんだろうな

x264スレで過去のx264とのSSIMやPSNRの比較が出てるけど、画質も明確に向上している

ツーツ→オプション設定→一般タブ　
出力ファイルのとこの「MP4ファイルの拡張しを「.m4v」にする｣のチェックを外しても
.m4v　になってしまうのはどういうことなんでしょうか

最新版を使ってないからじゃないの？

自作のCPU選んでるんだけど、HandBrakeでx264エンコする場合、同じ周波数のi7とi5ってどれくらい時間違うの？
ケチらずにi7にすべきぐらい違うかな？

教えて。エロい人。

i7とi5の差って20%くらいでしょ？

244です。ありがとう。

スクリプト書いて寝てる間にシーケンシャルに処理するようにしようと思うから、20%位なら許容出来そうな気がする。
それよりも、録画鯖も兼用だから消費電力を考えてi5-4690Sあたりにしようかな。

>>245
x264実用エンコベンチだと単純に1.5倍差があるみたいだが。設定値にもよるが。

qsvならほぼ同じ。気のせいかブロックノイズが目立たなくなってるから最近はqsvばかり使ってる。速さ慣れるとx264に戻れない。265とかマゾ。

>>248
分かるわー
あの速さと電気代に慣れたらもう戻れない（笑）

x265ではまだ最適化されてないでいいのかな？
x264とx265を比べても容量、画質に別段の差なんてなかった
違うのはx265の方が時間がかかったくらいか

それは正直、君の頭が悪い

x265でエンコするなら、x264のビットレートの1/2〜2/3位を目指さないと
容量的な恩恵は無いと思う。それでも画質は同等並に保てるから265は凄い。

>>252
なるほど thx ビットレート下げて比べてみるよ。
同じビットレートで比べたから違いがわからなかったのかも。

ベータ版でTSエンコが何故か出来ないわ
264、265、qsv全部試してもダメだった正式版まで待つかな

同じビットレートならサイズが同じになるのが当たり前だね。
あとGUIでやる時はx265はデフォルトがpreset veryfastにセットされてるから注意
これだとスピードはx264より遅くサイズはちょっとしか違わないって感じになる
presetはmediumにすること。

>>254
多分何かの指定が間違ってるんだろうから待っても無駄

ビデオ系ソフトはソフトの集合体だから正式版という考えは捨てたほうが良いよ。正式版出したそばから修正されるものだから。

>>255
んーもう一度見直して見るわありがとう

265の熟成具合から見るといまのところはまだ264エンコの方がいいですか？

>>258 やってみればわかると思うけど　なにも良くならない　からね
これほど空気感あると、今後よっぽどメリットがないと消えそうだよ

まぁ変わらないなら265でもいいか　ってことでも有るんだけど
現状、再生する側も揃ってないのでしばらく放置でいいんじゃね

HBでエンコ可能になった頃に磯エンコで試したけど「で？」という感想しかわかなかったよ

マカーはバカー

なんで必死になってx265は無意味という嘘をつき続けるんだろうか
なんかの工作？
それとも純粋に頭が悪くて両者の比較をする能力が無いのか

これからまだチューニングが進むと思うけど熟成と言う意味ではもう十分実用域だからな
使えないのではなく、使いこなせてないだけの話
今の一部メディアみたいに265を魔法のコーデックみたいに持ち上げてるのは何も分かってない証拠だが
10GBかかってた容量を単純に5GBに減らす選択肢として選べるようになったのは良いこと
HandBrakeだと265でも264でもQSVでも都合に合わせて好きに選べるんだから、どう使うのかは使う側次第ってだけの話

ただ普通にデフォ設定で結果が同ファイルサイズになるようにcrf調整してエンコして、画質見比べればいいだけ。
そんなことさえも出来ない馬鹿が嘘吹きまくってる。

釣りにマジレスしてんのもどうかと思うなぁ。喜んで屁理屈並べて来るだけだと思うぞ？
敢えて言えばx265の価値を知りたかったらx265スレに行けってことじゃね？
HandBrakeはそれを使いやすく実装してるだけの話なんだから。

H.264で十分高画質になるビットレートでエンコしてれば、同じビットレートでH.265エンコしても差はわかりにくい。
違いがわからないという人は、低めのビットレートで比較してみりゃいいんだよ。

>>264
いや、Handbrakeにはx265も内蔵されてんだから、このスレの話題だよ

釣りにマジレスするなとか茶化すようなこと言う話題じゃない。

>>266
別に必死に反論するほどの話でもないから適度に流しとけばいいんだよ。

いまどきビットレート指定でエンコしてる奴なんているの?

うるせえなあ

じえんだろ。ほっとけ。

>>267
必死でもなんでもない当然を言ってるだけ。

Blu-rayエンコのおすすめ設定を教えてください。
再生はパソコンでMPCHCのみで出来るだけ綺麗にエンコしたいです。
x265使用予定で寝てる間にするので時間は気にしません。

出来るだけ綺麗にって言うと1080ｐエンコだけど
俺は720ｐでやってる、理由はパッと見1080ｐと画質に差がない
容量が1080ｐに比べて半分以下に抑えられる

で設定は>>27でDenoiseのWeakでやってる

>>27の設定って逆じゃね？実写でRF22とかビットレート低くすぎになって画質汚いくない？
時間度外視なら2PassでAvg6000くらいにしとかないと「出来るだけ綺麗」とはならないんじゃ。
あ、x265ならAvg3000程度でもいいのかな。

実写は29.97fpsでRF20以下だと容量がでかくなり過ぎる、24fpsは知らん

皆さんありがとうございます
いつも猿で高画質設定を選んでエンコしてるだけなのでさっぱりなんです
めんどうなので限界まで高画質寄りにしてます

とりあえず解像度やフレームレートはそのままエンコに拘りたいと思います
再生はMPCHCにSVPで倍速補完なのでヌルヌル高画質を求めています
アニメはピクサーもの、あとは実写が多いです

ググってはみましたがここの皆さんの方が詳しそうなのでここで聞いてみました

まとめると
1080pエンコ
RF22以下
2pass
AVG3000から6000（h265）

ということでよろしいでしょうか？
自分の目でも色々と検証したいと思います

libx265って2pass出来ないハズ。

今は出来る

>>278
ﾊｯ いつの間にかそうなったのか。失礼した!

かなり最近2pass整備された

>>276
やればすぐ気がつくけど、Constant Qualirt(RF指定)とビットレート指定(2pass)は排他関係なので
どちらか一方しかできない。
あとここでビットレートビットレート言う連中が後を絶たないが、HandBrakeがおすすめしているのは
Constant Quality(RF指定)の方。

HandBrakeのおすすめはCQの方なのかぁ。
でも、固定クオリティであって固定ビットレートじゃないから、同じ可変ビットレートならABRなAgv bitrateで2Passの方が綺麗に仕上がると思うんだけど。
まぁ、こんなの個人の勝手か。

ストレージ容量とかの関係で出力ファイルサイズを制限しつつ高画質を維持しなければならないとか、個々のファイルに対して画質とファイルサイズとのバランスを極限まで詰めるエンコ修行僧でもなければCQのほうがいろんな入力ソースに対応できて簡単かつ早いからね

1080ｐと720ｐは誤差の範囲だけどな、俺は720ｐにエンコして
メディアプレイヤーで1080ｐにアプコンして再生してるが
まあ元が1080ｐがじゃなきゃイヤ！っていうならそれで良いんじゃない

>>282
https://trac.handbrake.fr/wiki/ConstantQuality
https://trac.handbrake.fr/wiki/AvgBitrateAndTargetSize

できるだけ綺麗に　とか言ってるとなんでエンコするんだこいつ?と思われるだけだよ。普通は目標サイズと折り合いをつける設定になるからそんな聞き方じゃ答えられない。　エンコが趣味ならかまわないが。元サイズよりでかいの作るなよ。

綺麗に残したいならAvisynthで軽くノイズ除去とWarpsharpしてデインタレするだけでかなりよくなるし
ファイルサイズもノイズ除去した分、良く縮む。そして綺麗。
Handbrakeはそこまでするのは面倒だけど、とりあえず縮めておきたいレベルの使い方だなぁ。

>>285
論破してくて反論するわけじゃないんだが、例えばHandBrakeデフォのCQ RF20だと、どんな動画もほぼ1200〜1500平均にされちゃうんだよ。
絵がほぼ動かないやつだと800平均とかなっちゃったり。でもRF小さくすると想像以上にサイズでかくなったりもするし。

いくらソースに合わせてクオリティを維持してくれるからって、CQで800平均にされた動画とAvg 2Passで1500にした動画じゃ後者の方が当然綺麗な訳で（サイズは縮まないけど）。
そうなるなら、ABRで自分の好きなビットレート指定した方が結果的にバラバラなクオリティにされるより良いと思ってるんだよね。もちろん2Passは絶対条件だから無駄に時間食うけどさ。

最近サイズ指定(2パス)だとボケる事に気付いてからRF18〜21に切り替えた

CQなのにばらばらのくおりてぃー

>>288
「プラシーボ」という単語が頭に浮かんだ。
videoタブのPresetスライドバーのplaceboな。

ビットレート指定が良いと思ってるのは動きの少ないところばかりで見ているから。CQが良いのは動きの激しいところで破綻が少ないところ。ビットレートの変化の幅が違うと思えばいい。
abrじゃビットレートを高くするしかない。当然サイズは縮まらない。これじゃダメだと気づくとCQを使うようになる。

サイズはh265で半減するんじゃね？

>>288
こいつ嫌いって奴、俺以外にいる？

同じ設定で5％しか容量が変わらないって聞いたが

>>288
死んで欲しい

>>288
こいつ死ねばいいのに

>>292
すまんな、バラバラなビットレートだな。
で、そのビットレートの変化の幅をRF20〜22でABR以下に押さえ込んでるんじゃ意味ないって事だよ。

結局はエンコの目的で十人十色なんだし、やっぱり無駄話だったな。>>296の言うとおり死んでくるわ

CQの動作を理解できてない事はわかった。あるいはabrの動作も勘違いしてる可能性がある。エンコ道の道は険しい。

まあエンコは人それぞれ、ただ答えられない質問はレス付かねーよ、ってことでほっとけよ
またじえんちゃんが話に加わりたそうにしてるし、くだらんことでスレ消費するな

>>288
死ね

>>288
大丈夫だ おれは支持するぜ

ここは何時の時代のエンコ系スレでつか？

糞アニメのエンコになにこだわってんだよバカどもwwww

svn6419で文字化けは直ったけど、フォルダ形式で出力したDVDのVIDEO_TSが
読み込めなくなってるのは直ってないな

handbrake qsv 264エンコで、たまーにフレームの前後が入れ替わってガタガタの動画ができるんだけど、同じ現象出てる人いない？
元のTSは普通に見えるから、何が原因になるのか見分け付かないんだよなあ...

プレイヤーを疑え
その次に
インデクサーを疑え

bffなやつでなって俺も困ってる。tff指定とbff指定で違う場所がカクカクになったりコムノイズが出る。仕方なくdecomb指定するがきれいにならない。

svn6419 のpreset regular-normalで地デジのバラエティ1時間をエンコ
昨日までi5 750@4G,x264でFPS Ave40
今日からi5 [email protected],igpu@1600Mhz,H264(IntelQSV)でFPS Ave310
プリセットQSV画質で十分な俺的には今年一番の感動
日記終わり

>>308
あらbffの時って見方はしてなかった。ちょっと見てみる。�d！

abrくん達はファイル全体のビットレートを平均化分配してくれてると信じてるんだね。285のabrの説明の And remember, that gets split between ~24-30 frames.　という文に注意してくれ。
ほぼ1秒毎の平均を揃えてるんだよ。capped abrただのcbrなんだよ。1秒間激しい動きが続いたらmax bitrateは一瞬しか出ない。動きがなくとも次の1秒へbitの持ち越しはできない。1秒間に静と動がある場合に効果がある。
abrくん達が想い描いている動作はCQが内包してるんだよ。さあ、再エンコの時間だ。

>>288
磔の刑

TＳをこれでエンコしてる人はCMカットしないでそのままx264なりQSVなりやってるの？

>>313
カットしない。と言うか出来ない。ただ丸投げしてサイズ縮めるエンコ用かな。

>>313
CMカットはmurdoc cutter.
CMカットしないのは週単位などまとめてフォルダつくってフォルダごとエンコード。
CMカットするとあるチャンネル(音声2系統)は読み込み時handbrakeごとこけちゃうので別ソフトでエンコード。

CMカットって録画機側でやることじゃないの？
カット済みのをリプってエンコするから、PC上でCMカットとか無いわ

お、また自演ちゃんの難くせが始まったぞ！（笑）以後CMかっとの話は相手にするなよｗ
録画機だのチョンだの言ってる時点で家電系の荒らしちゃんと思われ

ここまで分析力ゼロだと生きてるのも辛いだろ？ID:qfEnRwj1
肉片になっていいよ

>>318
録画機ってなんですか？

>>316 >>319

　 ∧＿∧＿　　　　　　　　 ＿＿
　(　・∀|[ﾆ:|ol 　 　　　　 　|　i ＼　＼
　（　つ ∩￣ 　 　　　　　　|　i　　l ＝l
　と＿）＿） 　 　　　　　　　|　|__ノ　 ノ
　　　　　　　　　　　　　　　|￣￣|￣￣|

　　　　　　CMカット

　 ∧＿∧　　　　 　　　　　 ＿＿
　(　・∀・)　　　　　　　 　　|　i ＼　＼
　（　Ｕ Ｕ　 ＿　　　　　　　|　i　　l ＝l
　と__）__） |[ﾆ:|ol　　　　　　|　|__ノ　 ノ
.　　　　　　 ￣　　　　　 　|￣￣|￣￣|



既にCMカットAAがあるって凄いよなって思いましたまる

murdoc cutterとtssplitterでしこしこがんばってDVDbox買ったみたいなファイル作って
がんばってたこともあった。レンタルしたけどHDDとか1万もする物は買えない無職、でも電気代は
親もちだからエンコして保存しよってがんばってた時期もあった。
でももはやそんなことに時間使うの面倒…録画→バッチで5分でサイズ縮まるし、わざわざ
CMカットとか…エンコにかかる時間以上に手間ひまかけるいみがわかんなくなってやめた

自動CMカットとか色々あるだろうけど、HandBrakeはいかに簡単にエンコするかに重点を置く人が使うからな
そういう複雑な処理をしたいのならAviUtlで色々導入して使えばいいだけ

TSSniperでええやん

自動CMカットなんて貧乏くさい話はやめようぜ。かまってちゃんがまた喜ぶだけだし

AviUtilはいろいろ弄れるんだけどどの機能も結局はそこそこだからね
ロゴ除去だのCMカットだのも結局手間かかって使いにくいじゃん、というのは使い込んで初めてわかる
その点HandBrakeはエンコード特化だけど、その分野では世界的だし能力も発展性も高い
本格的に使うのに十分な能力だし、これ使い出すと変な小細工は要らないなと思えて来るわ

handbrakeは失敗が少ないのが良いね
時間の余裕のない人間にとっては一回決めたセッティングで
確実に動いてくれるのが重宝

今時CMカットは自動でやるもんだろ
自動CMカットの最終プロセスのエンコにHandBrakeが組み込めるなら使うけど
現状使えないからCMカットを伴わないエンコはHandBrakeを使う場合があるって程度だな
どの程度使い込んででこんなこと言ってるのか知らんが「使いにくい」なんてのは
判断するのは個人個人だろ

自動でできると思い込んでるのが間違いで今どきテレビ局も勝手にカットされにくいようにいろいろ工夫してるもんだが

まあツッコミどころ満載にしてレスを待つのはかまってちゃんの典型的なパターンだな。
HandBrakeはもともとそういう所じゃないものに特化してるんだから、あれもこれも求めてるふりして、ないからと難くせつけるのはお門違いな話だな
別のスレでブツブツ言って慰めてもらえ

話でっかくしてるだけじゃん そこキレるところなんかね

あーもう、qsv 264でインタレ解除したらどうしても稀にフレーム順番狂う〜
みんなどうしてんの？

>>330
kwsk

まあ問題無い動画の方が圧倒的に多いんだが、たまに問題が出るTSをエンコしたらGOP単位のIフレームが前後の順番狂ってるように見える(TS自体はまとも)
これ同じパラメータでエンコしたら問題100%再現するんだけど、なんかbframesを3から6にしたり、TS短めに切ったりすると現象出たり出なくなったりしてワケわからん。もう少し追い込んでみるわ

beta版ソース読み込むと物によっては文字化けするんだけど

今のベータ4は>>194のパッチの前にリリースされたので当たり前

某有名シェアソフトでキッチリCMカットしてこれのQSVでエンコ
快適すぎてたまらんわ
CMカットはシェアウェアに限るねえ

え？

そっとしておこう

有名なシェアソフト？
murdoc cutter ってシェアソフトなの？

・よくわからんゴミシェアウェアを見つけて得意げに自慢してるつもり
・なにか良いシェアウェアが無いか知りたくて釣りをしてるだけ

どっちだろね。

目黒の秋刀魚みたいな感じ

シェアで入手したソフトの事かも

Constant Framerateにチェックをいれてエンコしてるのにmediainfoで見るとVFRな動画になってるんだけどなんなんですか？
仕様ですか？

same as source にするとcfrは無視されるよ。
ログを見てればわかる

QSVの早さに感動した

>>343
23.976fpsのソースで23.976にしてcfrにしてもmediainfoでみると
モード : VFR モード
フレームレート : 23.976 fps
最小 : 23.974 fps
最大 : 23.981 fps

こんなかんじでVFRの動画になります
仕様ですか？

昔から
気になるならmkvを選ぶといいよ

Mediainfoで見てみたけど自分のはCFRになってるよ。

DVDに入ってるおまけ映像とかが変換できません。
こういうのってどうやって変換すればいいのかな？

別タイトルになってんだろ。

その別タイトルになってる場合どうやって変換すればいいのかな？

>>350
普通にプルダウンメニューにあるはず。
なければリッピング時にカットしたんじゃないか？

それよりどうしてそんなに上から目線なの？

この流れでどこから上から目線に見られたのか、ゆとりの俺にはわからんわ

>>351
それよりどうしてそんなに上から目線なの？

H.265のencoder optionsのオススメはどれですか? そのままfast?
どこかに比較しておすすめ書いてたサイト見た気がするんだけど
見つけられなくて。

それって「車欲しいんだけど何がおすすめ？」って聞いてるのと変わらねーんじゃ？

>>354
preset と cfr を弄って自分の目で確かめるのが良いぞ。
標準だと preset medium, cfr 28 になるはず。
俺は色々弄った挙げ句 preset fast, cfr 24 でおちついてるけどね。

>>356
漠然とした質問なのに教えてくれてありがとう!

出来上がったm4vファイルをPCで再生するぶんには問題ないのに、
DVDプレイヤーで再生したときだけカクついてしまうのは何が原因なんでしょうか？
エンコはプリセットのNormal設定で、プレイヤーはパイオニアのBDP-3130という機種です。
USBメモリにファイルを入れてそこから再生しているのですが・・・
よろしくお願いします。

円盤は一定速度でまわってるからねー

ポータブルってのがあったけど普通のと何か違うのかな？

PS3の時は「うちら三下には難易度高いっすサーセンｗｗ」みたいな逃げが出来たけど
性能低い上に作りにくいんだからその言い訳が出来ないのが

誤爆すみません　

linuxmint17 64bit (ubuntu trusty)なんですけど
出力形式がmkvだけなのをmp4も表示させるにはどうしたらいいですか？
どのppaから入れればいいですか？nightly? beta?

最新のnightlyで>>207の問題も修正されたっぽいね
バイナリはまだだけど

みなさん乙です！

対応してくれたんだ。言ってみるもんだね。一応>>207と言ってみたけどこれはあると便利
特に画像管理ツールからISOを直接エンコードできるのが使い勝手いいんだよ。

バイナリ上がった

6443で確かに>>207の問題解消を確認。日本語ISOファイルを直接エンコできるようになった。
（今までは直接エンコすると途中で終了してログの表示もエラーだらけだった）
一応bugs forumにも報告しとかなきゃ

>>368
つまりは2バイトコード文字も問題ないって事？

yes.
Bugs Forumで御礼したらTaihei Mommaって人が両方対応してくれたから感謝してねん、とレスが来たけど、
名前からするとこの人なのかな？
http://i-scover.ieice.org/iscover/page/AUTHOR-33AF7F76-1441-642D-C480-804975A6CE3E
ありがとっす！

関係者ぐっじょぶ！

東⚫︎大学 大学院 修了
こんなグレーなソフトによく本名で関わったな
いくらソースコード書いただけとはいえ
俺なら本名ではやらない


コヨーテも乙
日本人が書く英語は理解が容易いな
よく伝えたと思うで

>>372
気色悪い奴だな、お前

>>373
お前もな

お前だけだハゲ

自分自身は外資にいたことがあるので、こういう事は日常茶飯事でした。
HBの愛用者であればせっかく大きな貢献をしてくださったTaiheiさんの
個人情報を詮索するのは自重いただいた上で、率直に感謝いただけるとありがたいです。
また今後もサポートいただけると心強いですし。

>>376
そう思うなら2chでわざわざ名前を出すのはやめといたほうがいいよ。嫌がらせに近い。

>>375
あん？やんのかこら

>>372
グレー？

>>372
グレーとか言ったらエンコできるソフトみんなそうじゃん

おまわりさん、>>372です

【高音質】AACオーディオ総合7【mp4/m4a】
http://anago.2ch.net/test/read.cgi/software/1375770923/

対応したの日本の人だったのか。強力な援軍は身近にいたんだな
これからも日本人の立場で機能向上の力になってください

>>383
本当にそう思う。
外国のマイナーなソフトは日本人の事考えているのなんて希だからね.。
英語でも今のところ問題ないけど、本家が正式に日本語メニューや表示に
対応してくれればちょっと嬉しい。

今回のFIXで本当は中韓とか2バイトコード系の人みんな恩恵受けるはずなんだよな
ただ実際に要望して対応したのが日本人だけだったわけで。
その辺の人達がどの程度HandBrake使ってるのかは知らないけど。

>>384
今のメニューは日本語どころかフランス語やスペイン語にも対応してない英語オンリーだから
そもそもの多国語対応って所から話を始めないと。
ちなみにHandBrakeはこの世界では十分メジャーだと思うけど、オープンソースの世界で
日本語が考慮される機会は少ないって話ね。

昔の DVD にて、コード変換エラーで HandBrake が読み込めないやつがある。
メニューに Shift-JIS か何かの文字を使ってるからかもしれない。
コード変換エラーのときは、エラー終了せず、コード変換しない などの対応とってくれないかな。

無視しようぜこいつ

>>386
無理

だいたいWindowsのAPIがプラットフォーム依存の文字コードのC文字列 or wcharの二択なのが悪い

>>384

HandBrakeのDLL使ったVidcoderのベータ版は日本語メニューあり

>>138-140の動画結合の件。

Avidemux2.6.8使ったら、0.9.9以降でも全く問題なく結合出来たのでご報告を。
同じPresets使ってたってビットレートが全く同じになる事はありえないのに、「違うビットレートの動画は結合出来ない」ってのは、やっぱり変だと思う。
詳しく知らないが内部でmkvmargeを使ってるソフトは全滅。バージョンが違うとなぜ結合出来ないかも不明だけど、解決したって事で。

>>391 >>138-140
>全く問題なく結合出来た

「問題なく結合できた」のではなく、「無理やり仕様違反のファイルを作った」だと思うよ。
以下のスレを見てくれば、H.264のファイルの結合には色々な問題があることがわかると思う。

　　AviUtl総合スレッド78
　　ttp://anago.2ch.net/test/read.cgi/software/1409719204/

俺も正直よくわかってないけど、Handbrakeでも--stitchableは指定されていないようだし、
仮に指定したとしても正しく結合できるのかどうかはわからない。QSVもどうなるのかよくわからない。

Avidemuxがどういう結合処理を行っているかは知らないけど、多分まともな処理じゃないと思う。
仕様違反でも平気で再生しちゃう再生系が多いから一見問題無いように見えるかもしれないけど、
ある日突然まともに再生できなくなったり、別の再生系で再生できなかったり、
映像崩壊が起きたりしても文句は言えないってことだと思う。

正直やめておいたほうがいいと思うけど、どうしても結合したいなら、
壊れたファイルを生成しているかもしれないという覚悟は持っておいたほうがいいと思う。

う〜ん、AviUtlスレの住人は元々エンコに1mmのズレも許さない「エンコの鬼」みたいな人らだし、そもそもそこで議論してるのって「分割→結合は悪！」って感じだからちょっと違う気もするが、まぁ言いたいことは分かった。
けれど、「今後、万が一、最悪、仕様変更があって見れなくなった場合は再エンコすればいいだけなんじゃないの？」って単純に思っちゃうけどね。

×問題なく結合できた
○自分の環境では問題ないファイルが出来上がった

って、感じですかね。単純に一例を報告しに来ただけなんで。もう消えます。

1行目はいい表現だな

0.10 がβからRelease Candidate版になったね

BSの録画した映画をエンコすると音がプチプチ切れる感じになるんだけど、回避策ってあるの？

パススルーしろ

ありがと
やってみる

できた！ありがと。

でも、作ったmp4がDivXプレーヤーだと音が出ないorz
WMPだと音が出るからDivXのもんだいかな。

ソースは5.1chかな？ダウンミックスできないプレーヤーなんじゃないかな。
それとそろそろmp4やめてmkvにすることをおすすめする。

>>400
mkvを勧める理由を聞いてみたい

字幕を複数入れて切り替えられる、音声を複数入れて切り替えられる

いつもslowでやってるのにふとなぜかplaceboでやってみたら
予想の斜め上をいく遅さw
泣きそうです

コンテナの自由度がmkvの方が高い。mp4はコンテナだけど実質入れられるものが決まっている。ac3音声は無いとかチャプターは実は無かったとか。iPhoneしか使わないならmp4でかまわないと思うけどね。再生環境も充実してきたpcとandroidならmp4を卒業していい頃だと思う。

>>399
久しぶりにこのスレ見に来たけど、なんか>>219に変わり者扱いされてるし。。。
そのリンク先に5.1chソースのエンコについて書いてるよ。もう一年以上前の話なんだな。

Handbrakeのバージョンもだいぶあがってるので新しいnightly(6469)で試してみたけど、結果は変わらず。
普通に5.1chAACソースをエンコするとぶつぶつノイズ発生。
パススルーするとVLCでは再生できるものの、iOS端末やiTunesで音声のないトラックができる。
DivXプレイヤーで音が出ないのもおそらく同じ原因だと思う。

で、うちは結局ソースの音声を自動選別して、5.1chソースのときはVLCでmovコンテナに再構築してからエンコするようなバッチ組んでる。
5.1chAACソースなんてエンコする機会ほとんどないからいくつも試したわけではないけれど、一応問題回避できてるつもり。

音声パススルーはハードデコードだと音出ないよ
ソフト側でデコードやると音は出る

DVDは問題なくMP4に変換できるんだが
BDだけ変換後再生できない。トホホ

HandBrake-6502svn-x86_64-Win_CLIでQSVを使うにはどのようなオプションを指定すればいいですか？
ググッたら-e qsv_h264というのが出てきましたが-e x264と大差ないです
CPUはCore i5-2520MなのでQSVを使えるはずですが・・・

HandBrake-6502svn-x86_64-Win_CLIでQSVを使用してH.264に
エンコードするにはどのようなオプションを指定すればいいのでしょうか？
ググッたら-e qsv_h264というのが出てきましたが-e x264と変わらないようです
CPUはCore i5-2520MなのでQSVに対応しているはずなのですが・・・

あ、ミスった。すみません。>>408は無しでお願いします

txtくらい全部開いてよめ。guiでlogみろ。

QSVのオプション自体はこちらで
https://trac.handbrake.fr/wiki/QuickSyncOptions
-e qsv_h264 の指定は正しいけど、それでqsvが働いていないようであれば
そもそもそのマザーでQSVを働かせる方法を調べること。

グラボからディスプレイに出力してるせいでQSVが機能してないとかよくあるパターンだね〜
そういう時はこれを参考にすると良いよ
https://mirillis.com/en/products/tutorials/action-tutorial-intel-quick-sync-setup_for_desktops.html

>>408
お前にはムリ
いつまでも鈍足エンコでがんばれやwwww

HandBrake　0.99.5530(32 bit)win

HDD内に保存してあるisoから特定の箇所だけ時間指定でエンコード
したいのですが、ソースの設定で時間を設定しスタートしても1.2秒で終わってしまい出来ません。
チャプター単位なら出来ます。やり方が間違ってるのか既出なバグなのか
判断がつかないのでどなたかアドバイス下さい。

Avisynthの.avsファイルを読み込ませるにはどうしたら良いの？
makeAVIS使ってもコーデックが無いと怒られてダメ

>>415
レスがないってことは既出のバグではないということ。何かを間違ってるかバグの新発見者になったかのどっちか
すくなくともうちで同じことをやってもファイル名が日本語かどうかに関係なく再現しないね

地デジ5.1ch録画のパススルーだけど、これちゃんと5.1chで再生できてる？
2chミックスダウン再生でノイズは確かになくなるんだけど、
5.1ch環境で再生するとセンタースピーカーからしか音が出ない。
録画の生データで再生するとちゃんとサラウンド再生されるから、

再生環境の問題ではないと思うんだけど。

264+ﾊﾟｽｽﾙｰの動画は何で再生していますか？

>>417
レス有難う御座います。
色々手元にある十数枚程度のDVDで試したのですが、タイトルが1つだけのDVDだと
時間指定でどれもエンコできないかったです。
タイトルが複数あるあるDVDは大丈夫みたいですね。

tsはch数が変わるのが当たり前だから真面目に再生しているんじゃないかな。tsじゃなかったら先頭のch数しか見ないプレーヤーがあってもおかしくない。
という感じで再生環境のせいだと思う。

TSをCMカットして(mediaInfoに読ませて)5.1で認識されてても
HandBrake側だと2chで読まれる時があるから
その時は余計にTSの頭カットしないと5.1として読まなかった。自分の場合

>>419
AVアンプ経由のVLCとかで試してるんだけど、
前処理とかエンコ設定とかもあるから、整理してからまた報告するよ。

>>421>>422
ステレオ再生じゃなくて、センター１本からしか出ないんだよね。
結局HandBrakeでお手軽一発ととはいかないのかなぁ。

Handbrakeのバージョンと再生ソフトの名前とバージョンは必須やで。

>>423
ttps://forum.videolan.org/viewtopic.php?f=12&t=104007
古いが似たやつ

Handbrakeはおいらの4770kマシンに
2hもののDVDをmkv H265 18 slowで3hかけて1Gにする
という仕事をくれた
64GBのSDカードの使い道も出来た

この恩は一生忘れない

DVD画質に3時間って遅くね
1GBってのもでか過ぎ

DVDならQSVで15分くらいで終わる画質でいいや

つりだろ

x265使いこなせてるヤツなんていんの？

そのまえにx265を「使いこなす」の定義から説明してもらわないとな

i7殻割5ギガOC水冷マシンでXメンの最新ブルレイを
10分でi-phone画質に一発で決めるx265エンコ設定を
知ってるとかじゃね？

iPhoneってx265再生できるアプリとかあんの？

大量のファイルを字幕焼き込んでmp4にしたい場合、
どういう設定をしたら簡単にすむでしょう？
burn in ってなんで初期設定でチェック入れることができないんでしょう・・・・。

cliを使う。コマンドわからなきゃログ表示すれば 書いてあるから試そう。余計なお世話だがわざわざ焼きこむ必要はあるん？

ライブBDをiPhone6用にするなら
ビットレートは12000くらいでいいんでしょうか？

x265良いと思うんだけどスレで盛り上がらないのわ何で？(´･ω･｀)

エンコ時間が実用域に達してないから。

画質が言うほど綺麗じゃない
ビットレートがさほど抑えられない

まあQSVは速いけど画質ウンコ
ソフトなら264よか265のがマシという消去法

>>440
「ソフトなら264よか265のがマシ」って、どういうところがマシなん？

>>441
同じビットレートなら人の顔とかの細かいところは265のが
キレイで背景とかが大雑把になるカンジに見える
大雑把さが酷すぎて気になることもあるけど
好みじゃね？

当初のx264も>>438-439って感じだった。
それから5年10年経ってやっと一般的に使えるレベルで普及しているから、x265も実用レベルになるのは東京オリンピックの頃だろう。

適応的量子化マトリクスの効果と言えなくもないが同じビットレートでそんな差なら265はまだいらないと思っちゃう。改良されるのをウオッチしてくれるのはありがたいがスレ違いになるだろうね。

x265のpreset mediumにしただけで、同ビットレートでx264の品質を簡単に超えるけど。

エンコが遅いのは紛れもない事実だが、画質に問題があるって言ってる人は意味わからん

265が遅いと嘆いてるのはただの貧乏人

そうでもないよ

>>445
そんなに体感できるのか、stableはよはよ

>>448
こないだ1.4が出たでしょ？

低ビットレートでの限界品質とかを調べるならともかく、
普通のエンコでH.264とH.265を同じビットレートで比較してもあまり意味ないだろ。
（理想としては）半分のビットレートでH.264と同等の画質を実現するのがH.265なんだから。

いや、どっちのテストも意味あるからｗ

>>450が限界品質でエンコしてるってことだけは認めてもいい

>>452
いや、してねーし。
同じビットレートならH.265が上なのは基本的に当たり前だというだけなんだが、まあいいや・・・。

あたりまえだと思ってない人がちょっと上にいるでしょｗ
何を見てるんだよ

>>454
それを論破するのに「同じビットレートなら」という書き方をしてるのがなんかもどかしいってだけだよ。

同じビットレートなら264でいい
265の利点であるビットレート半分が全然活きてない

というわけで全会一致で265＞＞＞＞＞264です

えっ？いや俺は賛同してないっす

汎用性

H.264出たての頃にXvidと比べて同ビットレートなら明らかに画質がいいって書いたら
否定する奴いたの思い出すわ

>>455
そりゃ君の頭が悪いからもどかしく感じるんでしょ。

同じビットレートで比較してx265のほうが画質がいい、ということと、
同じ画質ならビットレートを低く出来る、ということは、
同じ意味を別の表現で言ってるだけなんだから

この程度の理解も出来ないからグズグズ無駄に人に絡んで煙たがれるんだよ

ID:e4yPvugg

>>461
何が気に障ったのか知らんが、えらく攻撃的で気持ち悪い奴だな・・・。
別にお前だけじゃなく、>>442から「同じビットレートなら」という書き方が続いたのが、
個人的に気になっただけだっつの。

初心者（あるいはバカ）相手に「同じビットレートならx265のほうが画質が上」と説明すると、
「x264で必要十分な品質（ビットレート）でエンコされた動画」と、
「x265でそれと同じビットレートでエンコした動画」とを比較して、
　　「違いがよくわからないしエンコくっそ遅いし意味ねー」
とか言い出したりするもんなんだぜ・・・。（実体験）
ケースバイケースだけど、今は一定以上の品質に達したエンコをしてる人が多いだろうし、
その先の画質の差なんて、エンコの鬼でもない一般人にとっては誤差レベルでどうでもいいってことも多い。
>>450でも少し書いたように、ビットレートを抑えて多少荒れたエンコになってしまってるもんならわかりやすいだろうけど。

そんなこともあったし、「同じビットレートで〜」という説明は言葉足らずで誤解を生みやすいので、
　　「x264と同じ画質を、より低いビットレート（より小さいファイルサイズ）で実現できるよ。」
という表現のほうが直接的でわかりやすいと思ってる。
初心者相手ならなおさら。

>>463
長々書いてあるけど内容ゼロだな。
反省も無いし。

>>464
反省ときたか。なるほど。つい失笑してしまったｗ

そもそも「同じ画質」というのが実証しにくくて分かりにくいものだということが、全く分かってない件

大雑把な話しかしてない気がするが、「画質」の細かい定義にまで踏み込む必要があるんだろうか。
別に止めないけど。

ID:V8nx0hV0がx264とx265で同じ画質作れちゃうプロなんだから仕方ない
同じビットレートでとか甘えたこと言ってるシロウトは頃されるよ？

人が満足できる画質はその人にとっては一定なので、それが提供できるならx265のほうが
ファイルサイズが抑えられる程度に考えられないのかね。
あとはかかる時間をどう評価するかという話。

>>469
それくらいで十分だよな。

何だ自演か
アホらし

画質ってのは最終的にはその人の主観だってことですよ。

お前ら、離散コサイン変換からやり直せ

>>469
え？

ファイルサイズ主義のキチガイが暴れ続けてる

プロ：縁故エンジンが違う絵を同じ画質に作り上げてファイルサイズを比べる
凡人：ビットレートを同じにして絵を見比べっこする

【結論】はいはいプロの圧勝

画質なんてSSIMやPSNRを数字で比較すりゃいいだけなんだがｗ
見た目で判定するような馬鹿はいないだろ

そもそも、「同じ画質でビットレート半分」なるものを検証したかったら
画質が同じかどうかを調べなきゃいけない。
結局、画質判定が重要な鍵になってることには変わりがない。
そこを見た目や主観で決めようとしてるのがビットレート半減派やファイルサイズ主義のキチガイ勢
最初っから画質を数値化して数値で比較しなきゃ始まらないのに、出発点から狂ってるｗ

で謳い文句通り半分になるんですか？

>>478
ソースや設定によるんじゃね。

それにしても酷いスレだな。読解力皆無なのかアスぺなのか知らないけど、揚げ足取りばかりで笑う。

DVDを4GBにエンコして画質比較してるやつがいるらしいな。想定しているdpiの違いもわからず拡大してノイズを探してくれ。

>>479
ばればれの自演してるあほもいるしな

>>477
> 画質なんてSSIMやPSNRを数字で比較すりゃいいだけなんだがｗ
> 見た目で判定するような馬鹿はいないだろ

いや、RF指定でエンコしてみてビットレートが自分が思ってたより低かったりすると、
そんなSSIMみたいなデジタルな値はほっといて、「ビットレートが高いほうが画質がいいし」と
画質指定を全否定する輩がいる世界なんですよ。
「ビットレートはこれくらいであるべき」というバイアスが最初からかかってます。

ということでこのへんは事実の画質がどうかはもうどうでもよく、「見た目」という完全な主観(思い込み、いや宗教?)
の世界で語るのが出てくるんです。
オーディオ業界でよくあるやつです。
そういう輩にはいくら理屈で説明しても通じないんです。
SSIMやPSNRと「自分の見た目」との関係を証明するのは事実上無理ですから。

SSIMがデジタルな値？新しいね
イミフのビットレート至上主義というキチガイ世界に隣接して住む自分も
同じキチガイですという紹介文ならblogかFBでやるといい

ssimはこのくらいの値であるべき君
間違えちゃぁいないが、もしかしてハイビジョンもdvdも同じ品質でエンコしちゃうのかな？

svn5903から放置だったけど、最新svnは264のエンコスピード上がってる？

いきなりaviutilスレみたいになってるなwww

実写AV(60i)をエンコしたいんだがDeinterlaceとDecombどっちがいいんだお？

実写AV(60)をエンコしたいんだが　に見えて熟女通り越してBBAとかマニアだなと思ってしまったわ

消したいのはシマじゃなくてシワってか

実写女優(60)が援交・・・

QSVデコードonにしてエンコしたものをandroidでHW再生するとカクつくんだけど同じ症状の人いる？

>>491
kwsk

>>491
エンコ時のデインタレ設定の有無、ビットレート（VBRかCBR)
コンテナの種類、格納プロファイル
Android側の使用ソフト、ソフト側のインタレ解除の有無
ファイルの場所(SDからの再生なのか、ネットワーク越しなのか)等々

情報が足りなさすぎる

ちなみに、MX動画プレイヤーの再生時、H/W+と相性の悪いファイルはあった

一番重要なのは端末機種名だろう

再生環境はME173、MX動画プレイヤーでインタレ解除なし、HW、HW+ともにダメでBSPlayerやプリインソフトでも同じ
本体、SD、ネットワークともにX
設定は
-f mp4 -e qsv_h264 -q 20 --h264-profile=high --h264-level="4.1" -r auto --cfr -a 1 -E faac -B 128 -6 auto -R auto --encoder-preset=balanced

--encoder-preset=balancedをなくすかbaselineに収めると正常に再生可能

解決してるじゃないか、Androidで再生って時点で「見れりゃ良し」でしょうよ。

泥タブ再生でHWデコードにこだわると何がいいの？
おいらDVDをx265エンコmkvにしてMXとVLC両方とも
問題ないように思ってるけどHWデコードの選択すら
出来ないから全くよくわからない

電池持ちと発熱で有利

>>498
スマホタブで電気食うのディスプレイだしｷﾆｼﾅｲ

0.10.0が正式リリースされたね
ttp://handbrake.fr/news.php?article=27

ダウンロードしたユーザー数が少ないため、PCに問題を起こす可能性があります

みんなもっとダウンロードしなさい

無意味な警告を出すブラウザを使わなきゃいい

ブラ・・・ウザ・・・？

>>500
落ちてる？開けないや

今は落ちてるみたいだな。

落ちてるね
DLだけならここからできるよ
ttp://www.videohelp.com/tools/HandBrake

0.10.0
QSVではなくx264 にするとすんごい遅くなる。
0.9.9.5530 でTSエンコで 50FPS 出てたのが
0.10.0だと 8FPS！
プレビューだと50FPSくらい出るのが不思議？？？

>>507
何種類かの設定でやってみたけどそんな傾向はないな。tsのx264で特に今までと違う振る舞いなどないぞ？
例によってどんな環境でどんな設定で起きたのか書かないと意味がないわな

新しくなったDenoiseフィルタの負担が、かなり大きい気がする。

0.9.9.5530
BD(1920x1080）をretina iPadとPS3 Media Server兼用にx264エンコードしようと思うんだけど
Anamorphicの設定は何が適しているんでしょうか

現状、Noneでアス比固定にして、Mod=16だとHeightが1088になり、iPadでは問題ないがPMS側で再生できず

Mod=8にしてH=1080になるようにするか、AnamorphicをStrictにするか・・・

5.1ch 問題が解決されていれば 0.98 から解放されるのだけど。
0.98 の不満は二ヶ国語の LR を別々に分けられないこと。

シアターはうるさいし邪魔になるだけ

自分も>>507と同じようになるわ
設定は前バージョンと一緒にしてはいるんだけど何でだろ

自分の環境だと
　x264　FPS 60
　QSV 　FPS 130
　x265　FPS 15
だったから、0.10.0以前と変わってないな

【OS】Windows 8.1 64bit
【CPU】Core i5-2400 CPU @ 3.10GHz
【バージョン】0.10.0 (64bit)
【ソース】ts
【コーデック】x264 / QSV / x265
【プリセット】Normalから何も変更せず
【出力コンテナ】mp4

おかしいと言うやつに限って環境や設定を書こうとしない法則。
>>508で言われてるのに何故書かないんだろうな。

【OS】 7 64bit
【CPU】i7　3770
【バージョン】0.10.0 (64bit)
【ソース】TS
【プリセット】high
【video】x264(vfr)
【audio】AACpass
【フィルタ】Detelecine(def)、Decomb(fast)
【出力コンテナ】mp4

8〜9fpsしか出ず

>>513
svn6551でも同じ症状が出たけど、ツール・設定・ビデオの「DXVAデコーディング（試）」をオフにしたら、直った

バグレポートしろよ

QSV未対応のCPU使ってる奴はDecoding設定のDisable QuickSync Decodingにチェック入れないと不具合出るみたい

ログ見るとG530がQSVサポートYesになってんのが謎

[15:29:48] CPU: Intel(R) Celeron(R) CPU G530 @ 2.40GHz
[15:29:48] - Intel microarchitecture Sandy Bridge
[15:29:48] - logical processor count: 2
[15:29:48] Intel Quick Sync Video support: yes
[15:29:48] - Intel Media SDK hardware: API 1.4 (minimum: 1.3)
[15:29:48] - H.264 encoder: yes
[15:29:48] - preferred implementation: hardware (any)
[15:29:48] - H.265 encoder: no

エンコの季節がやってまいりました

バグなのか何か環境依存なのかの判断はbugs forumも読んでみてね
https://forum.handbrake.fr/viewforum.php?f=12
DXVAデコードの問題は7月ぐらいから報告されてるけど、結局そのままでリリースしたっぽい
まあもともと「効果は限定的」と但し書きが付いてる機能なので、何か意図がない限り必ず外しとくのが安全

AMDならグレーアウトするから、単純にintelかAMDでかしかCPUを判別してないのか。

C2Qだけどグレーアウトしてるよ

機能を見ているのか

x265クオリティでエンコ早ければもう何もいらない

ウチもC2Qでグレーアウト

あぁ、「AMDのAPUとintelのGPU内蔵CPUを〜」って言うべきだったな。
いくらなんでもGPU持ってないC2QやFXを判別出来ないほどじゃないだろと思い込んでたからさぁ。

なんか、ごめんな。

QSVの話題ついでに質問なんだけど、
同世代のCoreシリーズ内ならGPUの性能差（EU数など）はQSVのパフォーマンスに影響ないの？
例えば同じIvy Bridgeで、同じクロックでGPUだけ違う場合。（例：i3 3225 対 i3 3220）
前者はHD4000で後者はHD2500だけど、QSVは別回路で共通設計だから差は出ないか誤差程度って以前聞いた。

その比較はPC雑誌でよくやってたよ。全く影響ない。Ivy vs Haswellでも誤差。
けれど、後発でQSV対応になったPentiumGとCeleronだけ同じQSVエンコでも3倍差が開いてた。
それでも「Core iは2分、Pentium Gは6分」みたいな差だったけど。

>>531
そうなんだ、サンクス。
当時、QSVパフォーマンス重視して3240よりも3225を選んだのだけど、
ゲームとか一切しない俺には全くの無駄な選択だったわけだ orz

0.10.0でQSV試してみた、ソースは1920x1080@24pでエンコした24分27秒のMP4、QSV、Balanced、QP20、High4.1を指定

4770　：217fps 162秒（2分42秒）でエンコ完了 ※DDR3-1600
3770　：187fps 188秒（3分08秒）でエンコ完了 ※DDR3-1600
G1840：137fps 257秒（4分17秒）でエンコ完了 ※DDR3-1333

G1840と4770はQSVエンコ後のファイルサイズ一致、3770は7%程サイズが小さい

QSVはEUと専用回路の両方を使うから、EU自体のクロックや数も多少は影響する
http://i.imgur.com/sEVuW3z.jpg

QSVより　ソフトだけの方が、当たり前だが画質いいね。

なんでハードエンコだと画質悪くなるんだろうか？

x264だってultrafastにすればQSV並みに速くなるけど画質は落ちるでしょ
画質と速度はトレードオフなんだ

じゃあPentium3とかでエンコードすればいい。

ここはひとつK6-IIで。

まじかよPentiumPro133MHz探してくる

すみません、音声のオフセットって調整できますか？

BTで動画見ているので、エンコード時に350msec進められると、とても嬉しい。

プレーヤー側でやることじゃないか？

>>542
アンドロイドだと、対応しているアプリが
BSとDice位しかないんですよ。

MX使いたいもんで、エンコード時にできたらと思いまして。

>>537
そういう事じゃないと思うんだけど…

>>543
そうなんだ。delay設定は見当たらないね。muxしなおすのがいいのかな。
でも、うちもbtにmxが普段使いだが音がずれることはない。たまになるファイルはデコーダ変えて対処できてる。ヘッドフォン3機種とスピーカーの4種類使ったことがあるが気になったことはい。apt-x非対応ばかりだから遅延は多目のはずだが。ちなnexus7 2013。
そもそも遅延大きすぎじゃない？変なファイル作るより再生環境を見直した方がいいんじゃないかな。

>>544
>>534のスライドに書いてあるじゃん
flexibilityとperformanceは両立しない

TS地上波ソースを、1440x1080のままエンコして再生時に16：9（1920x1080）表示するにはどう設定すんの？
BSは単純に1：1すれば良いのは分かった。

動画側にアスペクト比を埋め込めばいい
あとはアスペクト比をちゃんと扱えるプレイヤーで再生するだけ

x265きてるー
さっそくつかってみようと思ったがProfileはデフォルトでnoneか･･･これはMainにすりゃいいのかしら
TuneはPsnrとSsimがあるな、ぐぐってもさっぱりわかんね
ProfileとTuneはどうすりゃいいのか教えて偉い人達

同じ画質で映像ビットレートが約半分ってことは
ビットレートはいつもやってるConstant Quality20より下げたほうがよさげだのう

x265のTuneはDVD→mkvエンコやったときnoneとssimとで
仕上がりのファイルサイズ全く変わらなかったよ？

>>545
Nexus7(2012)とSC-01Eなので、少々非力なのは否めないところ。有線だと問題ないんですけどね。
BTレシーバーは SONY MW600、DRC-BTN40 Jabra Clipper。おいらと後輩のセッティング

微妙な遅れに気がつくまではなんともなかったのですが、気がついちゃった後は微妙に気持ち悪い。今まで通りmmgでセコセコ調整します。

offset調整はオプションでできないので、これ以降はスレ違いになるのでお暇します。

>>536
QSV以外のハードエンコは何で画質が悪いんだろう？
浮動小数の精度が良くないからかなぁ。

QSVも悪いでしょう

速度を考えたら十分だね。

Q・S・V！Q・S・V！

ハードエンコはウンコ

ハードウンコはエンコ

最近便秘気味なんだよな

ビューラック飲むといいよ。エンコはそれからだ。

http://myanimelist.net/forum/?topicid=687193
フォーラムのこのスレッド見てたんだけど、今もまだ10bitでエンコードできないの？

Mediatek SoCのBDプレイヤーで再生できない（色がおかしくなる）ので10bitエンコはやめてください。

FlashPlayer（）でめっちゃ緑っぽくなるので10bitエンコはやめてください、というのはどうでもいいけど
10bitエンコするような変態はHandbrakeには頼らないだろ。

m2tsの生ファイルから直でエンコするならこのソフトが一番楽だからねえ・・・。
だから画質がかなり綺麗になる10bitエンコもこのソフトでできればいいんだが。

【OS】Windows7 64bit
【CPU】Core i5-4670 CPU @ 3.40GHz
【バージョン】0.10.0 (64bit)
【ソース】ts
【コーデック】x264
【プリセット】High Normalから変更せず
【出力コンテナ】mkv

この環境と設定で5分の動画エンコードすると速度がAvg 17FPSくらいしか出ないんだけどこれくらいが正常なのかな？
QSVをオフにしないと遅くなるって上の方で見たけど、設定見ても該当部分がグレーアウトしててオフにできないんだけど・・。

>>564
元々QSV使えない状態だから。

デバドラで、CPU内のGPUが無効になってる。

>>565
なるほど、どうもありがとう。
これくらい遅いのが普通なのね。
あと音声をAAC(avcodec)で160kbpsでエンコした後に、
真空波動研でmkvファイルの詳細みると音声7.5kbpsって表示されるのはどっちがおかしいんだろう

0.10ってVideoのUse Advanced Tab Insteadの細かい設定なくなった？

なくなってないぞ

intel core i7-4770でHigh profileで2時間30分の動画をH.264でmkvにエンコードしたけど、
4時間半もかかっちまった・・。
平均FPS14くらいまで落ち込んだし、いくらなんでも遅すぎ・・・。
handbrakeのバージョンは0.10だけど、早く改善しないかなこれ
>>567
途中で送信したまま寝落ちしたわすまんな
オプションのユーザーインターフェイスでAdvanced Tabが出るように設定すれば出る

改善って何を改善して欲しいの？
前のバージョンから変わったのはデフォルトの音声コーデックぐらいで
エンコ自体は殆どx264そのものだから、何と比べてどういう設定で遅くなるのか自分で調べない限り
フォーラムとかでも素人扱いで相手にされないよ？

バージョンアップしてから例えば1920x1080を1280x720にするために
looseにしてsizeを1280にしようとしても720以上に上げれなくなる場合が
あるんだけど俺だけかしら

010になってリサイズ関連はシビアになったからできないのは仕様

なわけないだろう

急にDVDドライブのスキャンが終わらなくなった
さっきまで普通に動いてたのに・・・

>>566
7.5kbpsでまともに聞こえるAACエンコードはなかなかないだろ。

せやな
あと音声をFLAC 24bitにすると真空波動研で0bitって出てワロタ
もうちょっとなんとかしろや

再生互換性のためにmodulusはなるべく、16にしておくべき？
TVソース縦1080がmod=16だと1088になるんで、mod=8で1080のままにしておきたいんだけど。

>>568-569
オプションにあったのね
教えてくれてありがとう

0.10にしたら、mp4にしてもデフォルトでm4vになる？
一度MVKにしてからMP4にすると、.mp4になるんだが。

あと、2-pass Encoding、Tourb first passがチェックできないのはなぜ？
(Avg Bitrateには数値を入れている)

テンプレにある

＞・全編 24p 収録の再生時 2:3 プルダウン (ソフトテレシネ)
＞　→ フィルタなし, fps は 23.976 (Same as source にしない)

なんだけど、Same as sourceだと駄目な理由って何かあるの？
全編24fpsって主に映画のDVDだよね

テンプレ3以降の情報は古い物も多いのでツッコミは入れないこと

>>564-565
SpecみるとQSV使えるCPUみたいだけどなんでQSV使えないの？

0.10 release noteみるとQSV対応とかいてあるし、
encoderの設定にもQSVの項目あるみたいだけど

http://ark.intel.com/products/75047/Intel-Core-i5-4670-Processor-6M-Cache-up-to-3_80-GHz

0.9.9.1から0.10にしたらencodeが劇的に速くなった気がする。
気のせいかな

ソースはNHKのテニス5分間、1920x1080, mp4, H264
filterはdeinterlace=slow のみ
前は11分だったが、8分20秒で終わった

CPU遅いとかいうつっこみはナシで
SandyBridgeのCeleron G530だから

H.265対応開始したからそっち試したら予想時間が30分越えで中止
サイズ半分になるメリットあっても時間がかかりすぎるわ
intelのハードウェアエンコーダーがH265対応するまではだめなのかな

>>582
だから、CPU内のGPUがドライバで有効になってないからQSVが使えないんだけど？
意味わからんの？

デバイスマネージャーでディスプレイアダプタのとこにinteli（R)　HDてのｇあるから、有効にしてみろ。

>>584
「元々QSV使えない」という
>>565 の表現が悪いから誤解をしただけだよ

Windowsで設定変更すれば使えるようになると書けばいい
設定変更で使えるなら、「元々QSV使えない」ことにはならない

それと俺は564ではない。

>>585
はいはい。
悪いのは全て他人ね。

設定変更って言えば設定変更だけどちょっと不親切すぎるな

いつからデバドラにそんな機能がついたんだ。

そーいや、グラボで画面出力してるとQSV使えないんだっけか
windows8か8.1ならGPU同時利用できるドライバがつかえたはず(だった気がする)
windows7だとどうやったっけな
とりあえずオンボードグラフィックから画面出力しないと内部GPUが死んだままでQSV使えなかった気がする

ID:HsVCMaqZは日本語の勉強をした方がいい

グラボ刺すとQSV使えないとか騒ぐ情弱っぷり
出来なくて騒ぐほどのもんでもないし何なの

Win 8でIvy以降ならオンボードグラフィックから画面出力しなくてもQSVを有効にできる模様
ttp://www.4gamer.net/games/128/G012877/20130404012/

このドライバ以前はオンボードグラフィックから画面出力しないとQSVが有効にならなかったはず

i7とか速いCPUもってる人に質問
Full HDでH.265でエンコードするとどれくらいの時間かかるの？

3770kで6fpsくらいかな
設定にもよるけどmediumでそんくらい

>>592
8いいなー
使ってもないのに画面出力するのかなりうざい
そもそも画面出力しなきゃいけない意味がわからん

まあ別にケーブルとディスプレイ繋がなきゃいけないわけでもなかったし
大差ないと思うが

isoからのエンコなんですが、あるisoデータが複数タイトルとしてスキャンされてしまいキューに追加しようとすると
you must turn on automatic file naming and set a default path in preferences before you can add to the queue.
とエラーが出てしまいます

キューに追加する前にデフォルトのパスを設定するにはどの設定を変更すれば良いのでしょうか
また、一つのisoデータ内の複数タイトルを連続でエンコするのはできないのでしょうか

0.10 でも音声 5.1ch TS ファイル→MP4 でポツポツ音の雑音が入るから、0.9.8 に戻しちゃった

0.9.8だとポツポツ言わないのか
いいこと聞いた

handbrakeの語源を教えてください

手動ブレーキと動画の関係があるのですか？

俺もステレオの番組は最新版使って、5.1chのは0.9.8使ってる。
なんで直らねーんだろなぁ？

ＭＰ4にする時って音声はパススルー？

>>594
ありがとう
通常は30FPSだからencodeするには
再生時間の5倍くらいの時間がかかるってことかな？

i7でもそんなに時間かかるとなるとH265も微妙だなぁ
サイズ半分なら時間もせいぜい2倍くらいかと思ってた

>>601
だれも報告してないからじゃないの？
5.1ch再生環境持ってないからか気が付きもしなかった。

>>602
AAC パススルーだと、VLC や MPC-HC で再生できないので AAC→AAC(faac) エンコードしてる。

MPCで再生出来てるけど

>>602
もしかして元ソースは放送波TS？
AACパススルーだと家電のメディアプレーヤーやBDプレーヤー、PS3で再生できない。
VLCとかMPCで見るぶんなら問題ないが。俺も劣化させたくないので何とかパススルーで運用したいんだけど。

うちは fdk_aac でやってるわ。
TSソースをDemuxして出てきたaacと比べて劣化してるかどうかなんて聞き分けられないし。

誰か教えてください

　

5.1chの人、ID変えながらいつまでも粘着してるぐらいなら、フォーラムにしっかり報告しなよ（笑）
そういうニーズが少ないから対応されてないだけの話なのに、日本の放送のごく１部の5.1chサラウンドがどーしたとかいう
超ローカルな話題に気付かれるはずないだろ？

そういう話なの？

まあここのスレには本家に改善要望出したり実際にfix上げたりする人も揃ってるみたいだから
本当に深刻な問題ならさっさと解決させてるだろ
そうなってないのは大した話じゃないか、ただの冷やかしと見られてる証拠

根本的にはスレチなんだよ。handbrakeの問題じゃない。

>>597にもアドバイスお願いします

>>609
>>598-599は俺じゃねぇし、思い込みの激しい奴だな

サクッと英語が書ければとうにやってるわｗ
ということで誰か報告してくれないかなー(ﾁﾗｯﾁﾗｯ

>>613
暇だから597について考えてみよう
メッセージからさっするにきっとPreferencesのAutomatic File Namingのチェックが外れて
自動でパスと名前が入ってないんじゃないか
(Tools→Options→Output Filesの中)

これにチェックを入れて適切に設定する。もしくはDestinationのBrowseボタン押して
自分の保存したい場所に好きな名前つけたらいいだけなんじゃねえの?

isoデータ内の複数タイトルを連続エンコは出来る。
1つのタイトルをエンコ設定終わったらQueueに入れるだろ
でTitle切り替えてまたエンコ設定終わったらQueueに入れるだけ

>>609
まともに誰かに助けて欲しいんなら難癖つけてるだけじゃなくてまともに報告すれば？
現象出るチャンネルは限られるしパススルーにしても困ってしまうってのは敢えて家電で再生したいというチミの特殊ケースなんだろ？
そういう条件を敢えて曖昧にして騒いで、そうやってすぐに逆ギレする所もどう見ても荒らしで、誰もたすけくれんわなw

アンカ間違ったわ>>614のチミな

>>616
逆ギレしてんの貴方にしか見えないけどｗ

>>614
英語ができないのなら他の人が報告しやすいように準備するべき


日本語で、症状、環境を詳しく書いたり、
サンプルのファイルをアップロードしたりやれることはあるはずだ

というかノイズが出るというくらいならgoogle translateで通じるだろ
環境かいて、サンプルファイルを用意するだけだ

>>619
>サンプルのファイルをアップロード
今時放送波録画したものをアップロードとかさすがにできないでしょ。
http://www.star-ch.jp/muryo/index.php?refid=pickup
今日と明日のスターチャンネルの無料放送、どっちもサラウンド放送だから
録画環境のある人はこれでサンプル入手どうぞ。

>>620
海外の開発者もいるんだからサンプル用意しないとわからないだろ
そういう具体的なもの用意しなければ修正されるわけがないんだ

地上波も録画時間が短ければアップしても問題ない
YouTubeでも1分間の動画とかは削除されない
ジャニーズとか変な地雷を扱わなければまず問題ない

それでも気になるならCMとか番組宣伝とかにすればいい
拡散するほど喜ばれるのがCMだから

>>620
バグ報告はここだよ。IDが必要だけど無料でできる
https://forum.handbrake.fr/viewforum.php?f=12
とにかく言いたいことがあるなら片言でもいいからここに上げることだ
重要なのは起きる条件と起きない条件を明確に書くこと
単に日本のWOWOWの放送が、とか言っても理解はされないからサンプルも重要

>>621
短かろうがCMだろうが、訴えられないという根拠はないわけで、
handbrakeの修正なんかのためにそんなリスクを負うつもりないよ。

>>622
俺このスレ自体はちょいちょい見てるけど、あくまで通りすがりだから。
5.1chの放送波なんて俺自身はほとんど目にする機会ないし、
最近じゃ録画>エンコとかほとんどしなくなったから正直どうでもいいんだ。
ただ困ってる人は相変わらずいるようなので、とりあえずサンプル入手手段は提示したから、
興味ある人がやればいいぐらいにしか思ってない。
ごめんね。

バグがすぐ再現するサンプルは絶対必要だよ
ソフトウェア業界にいるからわかるけど
サンプルがないようなバグ報告は無視されることが多い

>>622
片言はさすがにちょっと
ここに日本語書いて英訳してもらえばいい

>>623
CMとかのアップロードでは逆に訴えられる根拠のがないわ
損する人がだれもいないなら訴えられる可能性はゼロだ。

内容みて問題無さそうな動画はたくさんYouTubeにアップしてるが
削除されたことも警告されたこともない

>>623
どこにいるかもわからないそういうレアケースで困っている人のために
興味もないのにいいかげんな書き込みを続けてるわけだ
そういう暇があるんならもっと他の事に時間とエネルギーを使いなよｗ
ま、この人の場合ほとぼりも醒めたころにまた戻って来て同じ書き込みを続けるんだろうけど
次からは「HandBrakeなど興味もない通りすがりで単なる煽り目的です」とかコテつけろよな。

>>626
なんでそんなに煽るかね。
昔は俺も5.1chの問題は悩んだよ。
だからプツプツノイズが気になる人の気持ちはわかる。
でも今はどうでもよくなっただけ。

どうでもいいのに朝な夕なスレに張り付いて自分にとってどうでもいい事を連呼する
それを世間一般には荒らしと言うんだよ。よく覚えとき

どうしたらいいのかが分からなくて音声がサラウンドのやつの録画ファイルが溜まる一方ですよ。

>>618の貴方なんて書き方からするとメーカー系かな？なんかHandBrakeとぶつかるようなソフトって最近出てたっけ？

>>630
そういう貴方は陰謀論厨だね。

流れをまとめるとHandbrakeは使えない糞アプリ。
ということでOK。

休みが近いんだなぁ〜
音声は再エンコすればいいだけ。時間もかからん。

vbv-maxrateってqsv_h264の品質ベースじゃ効かないのかよ詐欺じゃん

5.1ブツブツは出るソースと出ないソースがあるんだよな。
何が違うか追求してない。

なんか勘違いしてる人いるようだけど、特定のブツブツが出るソースは再生環境とかじゃなくて、
デコーダーが問題らしく、同じソースをVLCで再生してもブツブツなる。
でも、私が見たことあるのは全部放送波だったので、
同じような環境の人はソース提供できないだろうなと思う。

今は放送波を変換することがなくなったので、私には関係なくなったけど、気になってた時は
0.98で問題ないのでそれで済ませることにしてた。

お目覚めかい＞粘着くん（笑）

>>635
粘着してんのお前だろ
出待ちしてんのか

荒らしちゃんの行動パターンは単純なんだよ（笑）
日曜夕方だしそろそろ他人を装って来てる頃だと思って見てみたらドンピシャだったわ
おまい単細胞荒らしの良いサンプルになるわｗ

>>637
荒らさないでくれない

>>631で糞アプリとまで言い切ってるぐらいなら来なきゃいいのに、
その糞が気になって気になってしかたがないみたいね。>>634>>636の人は。

tsエンコすると時々えらい低解像度で固定されるんだけどなんなん？

tssplitterでHD画像だけ残したものでエンコ
http://eltransportador.up.n.seesaa.net/eltransportador/image/tssplitter.PNG?d=a0
以後は「現在のサービスだけ録画」でワンセグを録画しないようにする

スレみるの忘れてたｗ
レスくれた人遅レスすまん

そう、tsエンコの時の音声のつもりで聞いたんだ
みんな察してくれてありがとう

俺は音ズレが怖くてパススルーでやってんだけど家電で再生出来ないとかは知らなかったよ
5.1だとなんかブツブツ音してるしどうしたもんかなと思ってたんだよ
AACでエンコしなおしたりとかもうちょっと試していい感じになるやつ探してみるよ

数年前のやつはMP3にしても音ズレしなかったんだけどね・・・
今となってはエンコ速度が遅すぎて使えないもんになっちゃったけどｗ

TVMW6はもうちょっと期待したんだけど酷えな
あっちのスレで言ってみたけどステマも酷い
普通に自動エンコに使う分にはこっちで十分だな
何より大量エンコでも安定してるのが良い

>>641
ありがとうごぜぇますorz

0.9.9だと問題なかったのに
0.10.0って、キャプチャー指定すると、おかしくならない？

例えば、
10キャプチャーだとしたら、
３と４のキャプチャーを指定すると
キャプチャーが2,3,4っとなる

キャプチャーってなんぞ？

Chapters(チャプター)のことじゃね？

32bit版0.10.0入れたら2-passにチェック入れると「x264_encoder_open failed」
とかなんとかエラー吐いて止まるようになったorz
マシンパワーの制約上ABR 1500kでエンコしたいのに。
同志いますか？Win8.1

>>646
言う通りです。打ち間違いm(_ _)m
×キャプチャー
○ Chapters(チャプター)

>>615
遅レスですが、無事解決しました。
ありがとうございました。

300本ほど動画を登録して一度に処理させようとしているのですが
30本くらい処理を終えて次の動画のエンコード準備中に固まり
最終的にはWindowsを巻き込んでフリーズするという現象をもう3回くらい繰り返してます。
処理内容はしっかり保持されているので登録しなおしはしなくて済んでいますが
あまり何度もWindowsを強制シャットダウンするのはあまりいい気分ではありません。
これだけ大量に処理をさせたことがないので元々あるバグなのか
ウチのPC環境が悪いのか判断しかねています。
OSはWindows8.1 Pro 64bit、Handbrakeのバージョンは0.10.0.6534です。
どなたかわかる方いらっしゃいましたらアドバイスお願いします。

こういうアプリケーションでOSがフリーズって、ハードウェアかOSに入れたドライバ類がおかしいんでしょ。

CLI 版落として来てバッチ処理した方が良いよ。
本数はずっと少ないけど、一晩連続エンコさせても問題無いわ。

御二方ともレスありがとうございます。
とりあえずCLI版で試してみます。
これでも同じようにとらぶるのであればウチの環境が悪いとハッキリしますので
では、失礼しました。

>>651
連続処理したから悪いということではないかもしれない。
ログを確認して異常終了したファイルをつきとめて
コーデックとかコンテナを調べてみるとよいとおもう

特定の動画だけエンコードできない現象がでてる
必ずHandBrakeがフリーズするファイルがあった
Windows Media Videoのファイル。

あとはなぜか途中でエンコードがとまり不完全なファイルになるファイルもあった。
再生は問題ないのにエンコードできないファイルがある。

Windows Mediaでエンコードされたwmvファイルを
HandBrakeにドロップすると、HandBrake0.10が必ずフリーズ終了しますが
これって既知のバグですかね？

真空波動研Liteのコピペではこんなファイルです

640x480 24Bit Windows Media Video 9 29.97fps 1000.00kb/s
Windows Media Audio 9 48.00kHz 16Bit 2ch 128.02kb/s
[WindowsMedia] 01:00:44.000

同じPCで再生はまったく問題なくできています。Media PlayerとVLC Media Player

その後ですがやはり症状は改善されず何度かやり直しをしてみました。
すると一度だけブルースクリーンが表示され、その内容がどうもOC関連のもののようでした。
そこでBIOSでCPUコア電圧とキャッシュ電圧を少し昇圧したところ見事に改善され残りのファイルを一度に処理出来ました。
OCCTでのテストをパスしていたので大丈夫だと思っていたのですがまだまだ設定の詰め方が甘かったようです。
結果、Handshakeとは全く別な問題でした。
スレ汚し申し訳ありませんでした。

shake! shake! Handshake!

まどマギの音声プッシースルーするとﾎﾜﾝﾎﾜﾝなるな
TsMuxも不正な形式で読めないし

TSが溜まる一方です＞＜

ドピュッ

nightlyで最近の３つくらいのバージョンでソースの日本語ファイルが文字化けしてまたエンコードできなくなった
この前治ったのにどこをいじったらまたなるのか。。

これで
元素材地上波TS、映像が264へ、音声が地上波AACのコピー、コンテナm2ts、MuxをtsMuxeRを選ぶとエンコ成功しますか、エラーになりますか？

日本語で

日本語

日本

日

ロ

コ

＿|

|

．

　

>>664
日本語だから

いいえ、ちがいますん。

>>674
え？

>>664
日本人？

相変わらずこのスレはのりがいいなぁｗｗｗ

>>662
冗談抜きで何言ってるのかよくわからん
解読するに
地上波のｔｓファイルをH264でエンコ、音声はパススルー
んで、コンテナがm2ts・・・？？？

これってmpeg2用のコンテナちゃうの？
俺はコンテナについては全然知らんけど、少なくともH264使うならmp4かmvk使うもんなんじゃないの？後はm4vやらaviあたり？

>>678
> これってmpeg2用のコンテナちゃうの？
> 俺はコンテナについては全然知らんけど、少なくともH264使うならmp4かmvk使うもんなんじゃないの？後はm4vやらaviあたり？
MPEG2とH.24が同居した地上波のTSが空から降ってきてるだろ。

H.24ってR18みたいなもんか。

いつも0.9.8のiphone&ipod touchでエンコードしてるんですが
どうやら0.9.9や0.1.0だとプリセットのiphone&ipod touchの設定が変わってしまってるようで
もう我慢できないくらい異常に遅いです
0.1.0で0.9.8のiphone&ipod touchと同じ設定にするにはどこをいじればいいのでしょうか？

>>681
いったん0.98に戻して設定メモすればいいだけだろ

>>678
ファイル名の事じゃないの
日本語名のファイルを読み込むと文字化けしてエンコードできなくなっている
Nightly build 6509までは大丈夫だった

>>683
どう見ても>>663へのアンカー間違いだろ。

>>684
上見てなかったごめん

tsMuxeRは内包されていないんで答えようがないよな

>>683
今のところNightlyを使わなきゃいけない理由があまりないから急ぎじゃないと思うんだけど
またバグレポート上げてもらいたいね。
症状は前のNightlyの時と似てるのかな？GUIで文字化けで止まってCLIでは動くとかだったら
もしかしたらその部分が前のソースに巻き戻ってるのかもね

最近GUI-CLIのやりとりがJSONベースに変わったからまたおかしくなってる
というかWinGUIのメンテナは非ASCIIな文字列の扱いを何も理解してないっぽいな

コードを眺めるにMarshal.PtrToStringAnsi(jsonMsg);でJSON内のUTF-8なPathを破壊してるんだろうな
unmanagedなUTF-8文字列からstringに変換しなきゃいけないんだろうけど
MSは一発でmarshalできるメソッドぐらい用意しといてほしいものだ

しぶいな

H265とH264をほぼ同じ設定で比較したけど、サイズが1/2どころか1/3になったわ。
H265の画質でちょっとおかしいなと思ったのは、ピントがずれている所からピントがあってからまたピントがずれるという場面があるのですが、ピントのあっている時間が短くなった。

>>691
まじでー
H265はTuneとProfileを何にしていいかわからないからいまだにH264でやってるわ
両方デフォルトのNoneでいいのかしら･･･

>>692
Tuneはssim、profileはmain10にしてた。

ssimはかなり有力という情報があった。main10は俺の直感。

>>693
ほーなるほどね
俺も1回エンコしてみるかな
Quality(もしくはAvg Bitrate)はH.264でやる時に比べて値さげた?

>>694
同じ値にしたよ。

>>691
うちではH.265でエンコードしたらH264よりサイズが大きくなった
ものもあった。
詳細な設定は特にいじってない、基本Normalで、RF=20

時間かかったあげくにサイズ肥大化では話にならないとおもって
H265は当分使えないな、という感想だった
HandbrakeのH.265の実装コードの品質がまだ良くないのかな？

理論的にはH.264の半分サイズになるときいてたけど
どうやったらそんなに小さくなるのやら

恐ろしいな。
俺も様子見を決め込むか。

>>696
まだまだ情報が少ないからなあ

ある動画をH.264を仮にRF=20でやるとしてH.265もRF=20でやったら
ほとんど意味がなく、RFをさげてやると画質はH.264と変わらず容量が減る
みたいな情報をどこかで読んだような読まないような
つまり最適なRFが20近辺じゃない可能性っての?

かなり適当情報なのであしからず

おぉ！いつの間にかH.265対応済みだったのか！！！
いっぺん試してみよ。

CLI版には --gain で音量の上げ下げを調整できるオプションがあるのですが、GUI版では見つけられませんでした。
此のオプションはCLI版のみなのですか?

仕方なく、今は MP3gain でノーマライズしているのですが、エンコード時に一発でできると楽ちんなので。今のところ普通にエンコしたものは83db前後なので、+8 したい。

>>698
それは逆だろ。crfを合わせればエンコーダ側がそれを指標にした画質に調整するから
同程度の画質での圧縮率の高さをうたっているx265はそれなりにサイズが小さくなる
今まで100個以上のソースをx265でエンコードしてるけど、サイズはだいたいx264の4割〜6割になってるよ
これをよく判らずにビットレート指定なんかでやると時間は激増するのにサイズが変わらないなんて変な感想になる
同じビットレートなら同じサイズなのは当たり前だし、x265にとってはより高度な画質を目標にするわけだから
時間も倍どころか4倍6倍かかることになる。

>>701
つまりいつもAvg Bitrate指定してやってるやつはH264と同じ値入れてるとだめだけど
RF指定でやってるやつはいつもと同じ値で問題なしってことかな?
また間違ってたらすまん

>>691 >693 >695 >697
IDから見て同一人物っぽいけど
>>697 見るとH.265使ったことがないようにも見える
釣りだったのかな

ファイル小さくなったと書かれていたからもう一度
設定変えながらテストしてみた
やっぱりH.265にしてもほとんどファイルサイズ変わらなかった。
x265は時間かかるだけムダなかんじだわ

H.264 vs H.265
で設定変えながらテストした結果を報告

Source: 地デジTS, 「4月は君の嘘 2期のED曲」 1分30秒
HandBrake: 0.10
CPU: SandyBridgeのIntel Celeron G530 (QSV非対応)
OS: Windows7 x64

共通の設定
Filter: deinterlace = Slowのみ
Quality: Constant Quality 20RF
Preset: VeryFast(Default)

-Test01
Video Codec: H.264
Time: 2分55秒
Size: 50.3MB

続く

-Test02
Video Codec: H.265
Time: 11分09秒
Size: 49.6MB
x265 Tune = None
x265 Profile = None

-Test03
Video Codec: H.265
Time: 8分40秒
Size: 49.6MB
x265 Tune = Ssim
x265 Profile = Main
Test02に比べ時間がかなり短くなった。ファイルサイズは変わらず。

-Test04
Video Codec: H.265
Time: 8分13秒
Size: 49.6MB
x265 Tune = Ssim
x265 Profile = Main10
Test03に比べ時間が少し短くなった。ファイルサイズは変わらず。

上のテスト結果からの結論
x265 Tune や　x265 Profile の設定を変えてもファイルサイズは変わらなかった。
時間はけっこう変わったけど、H.264に比べるとやはり遅い。
H.264と比べてほとんどファイルサイズが小さくならなかったので
現時点ではH.265は時間と電気代の無駄な感じがした。
再生できるプレイヤーが限られるのもデメリット

まだH.265は成熟していないから最悪の場合、のちのち再エンコードなども
できないファイルになる可能性もあるかもしれない

まあ未完成なのは間違いないけど、よくわからずやってるのか、または釣りっぽい内容だな
どれを使うかは自分の理解度と好みに合わせればいいだけだから、あまり意地にならないように

エンコード後のビットレートの記載が無いからお察し。
両方同じRFじゃ265の意味なくないか? もっと下げて良いと思うヨ。
ビットレートが低くても264の画質を表現出来るのが売りでもあるんだし

>>707
釣りっぽいって何を言ってるの？
変な設定してるわけでもないし時間もファイルも実測値だよ

理解度だのなんだのと俺のせいにしたいようだけど
デフォルト設定でぜんぜん使い物にならないレベルなのは
まだクオリティが低い証拠だよ

釣りとかいうならファイルサイズ半分になる設定あげてみなよ
できないでしょうけど

>>708
>>701 の人もビットレート指定するなって書いてあるだろ
だからRF20のままやってるんだよ

そもそもRF20ならH.264でもH.265でも同程度の画質になるはず

自分もH.265やったことあるけど、まだまだ実用段階じゃない感想
サイズが半分は誇張もいいとこだろと思うホント

>>707-708
Quality設定のConstant Qualityのところ
左側がLower Qualityになってるだろう
ここは品質レベルを相対的に指定できる、という意味のはず

x.264使用時と同じRF20にしてもx.265でファイルサイズが
小さくならなければあるべき姿とは言えないはずだよ

>>703-706 >>709-710
ソースがほとんど動きのない比較的単調なアニメ映像で、プリセットもveryfastじゃ、あまり差が出なくても仕方ない。
　　ttp://peace.2ch.net/test/read.cgi/avi/1418567936/152
と同じソースで、画質の指標の１つであるSSIMも含めてx264とx265の差を調べてみると以下のような感じ。

------
・x264 veyfast ssim crf20
　　SSIM Mean Y:0.9927184 (21.378db)、kb/s:6947.97
　　x264エンコード時間 : 0時間 1分24.1秒
・x265 veryfast ssim crf20 Main
　　global : 2018, Avg QP:19.80 kb/s: 7069.76 SSIM Mean: 0.993587 (21.930dB)
　　x265エンコード時間 : 0時間 3分49.3秒
・x265 veryfast ssim crf20 Main10
　　global : 2018, Avg QP:19.66 kb/s: 6994.06 SSIM Mean: 0.995943 (23.918dB)
　　x265エンコード時間 : 0時間 4分59.4秒
------
・x264 medium ssim crf23
　　SSIM Mean Y:0.9933164 (21.750db)、kb/s:4556.61
　　x264エンコード時間 : 0時間 2分 3.4秒
・x265 medium ssim crf23 Main
　　global : 2018, Avg QP:25.51 kb/s: 3708.01 SSIM Mean: 0.991439 (20.675dB)
　　x265エンコード時間 : 0時間 4分27.2秒
・x265 medium ssim crf23 Main10
　　global : 2018, Avg QP:25.11 kb/s: 3814.37 SSIM Mean: 0.994015 (22.229dB)
　　x265エンコード時間 : 0時間 6分35.7秒
------

veryfast crf20ではビットレート（とサイズ）はほぼ変わらないがx265のほうがSSIM値は高い。
medium crf23ではx265のほうがより低いビットレート（とサイズ）となっており、
x265のMainのほうはややSSIMが低いが、Main10はより高いSSIM値を実現している。
時間やサイズ、画質などを総合的に考えて、使うも使わないも各自で好きにすればいいだけ。

H.265がH.264と比べて画質同じで半分のサイズになることもあるけど一番効果が出た時だけそうなるって感じやね。
アニメとかだとあんまり差が出ないかもしれない。

IDも複数使ってるようだし待ってましたの反応から見ても、そろそろ荒らし認定して良いな
狂ったように書き込み始めるだろうけど放置しとけばおk

>>708
> エンコード後のビットレートの記載が無いからお察し。
同一ソースの結果サイズが書いてあるのにビットレート記載を気にするお前の頭がお察しって奴だよなｗ

必死にcrf値を揃えてテストしてみたようだけど、
x264とx265ではcrfの定義が違う
揃えたところで比較データとして意味が無い
揃えるなら、ビットレートやファイルサイズを揃えないと。

これで何度目だ？
crf値同じにして比較してﾄﾞﾔｧってデータ出すバカ

>>717
ん？まさか俺に言ってるんじゃないよな？
同じRF値でうんたらかんたらと言ってる流れがあったから
同じcrf値でのSSIM等を出して違いを比較しただけなんだが。

こんな時間帯からアツい書き込みは止めとけよ。自演がバレバレだぞ？我慢できなくなっちゃった？

>>718
個人的には無駄だとは思わないけど
x264とx265のcrf値に互換性はないよ

>>720
ああ、たしかにそれを最初に書いておかないとSSIMを出した意味もわかりにくかったか・・・。すまん。

RFを20から25に変更するとだいたいファイルサイズが半分になる

H.264 、 RF20
H.265 、 RF25

この２つを比較してH.265の画質がH.264と同等以上ならば
H.265の宣伝通り、画質同等でサイズ半分が正しいことになる

>>703
元のソースがたまたま、H.265と相性が良かっただけだと思って、697の発言をしたんだよ。
HandbrakeのH.265で圧縮したのは、そのソースが一回きりだよ。
要するに、H.265を使ったことがあるのは一回だけだよ。

なんか>>722のように「x265はサイズ半分で同じ画質」という言葉に
妙にこだわってる奴がいるようだけど、上の流れを見たうえでRF値とサイズだけで語るってアホかと・・・。

そもそもサイズ半分なんてただの目標だし、仮に達成されたとしても限定的なソースだけで、
どんなソースでも半分になるってわきゃねーし、x265はまだ開発中のもんだし、騒ぐだけアホらしい。

>>724
同等品質でどれだけ小さくなるかは重要なところだろ
1割しか小さくならないならあまり意味がなくなるが
半分になるならエンコードに2-3倍時間かけてもいいという人は多いはずだ

HandBrakeのRFがあいまいで気に入らないならビットレート指定に置き換えてもいい。
いくつかサンプル平均をとってみるとだいたい
RF20なら4300kb/s、RF25なら2100kb/sくらいになっていた。

だから4300kb/sのx264と、2150kb/s指定のx265の品質をチェックしてみると
いうのはいい方法だと思う
それで同等だと感じたらもう今後は全部x265でエンコードでいいんじゃないか
エンコードの時間よりサイズを優先したい人なら

ビットレートは指標にならん。

>>725
>>713でプリセットの話とかも出てるわけだが全く理解してないんだな・・・。
いつもデフォのveryfastでエンコしてるの？
そんな単純な話じゃないし、それを理解しないまま「半分」だけにこだわっても意味ないよ。
エンコードについてもっとしっかり勉強したほうがいい。

>>727
単純な話ではないといっていたら自分なりの結論さえ出せないだろ

パラメータが多いのならば
たくさんあるパラメータのうち重要度が低いものは固定しておいて
重要度の高いものを変えて変化を見るしかない

結局、画質とサイズは右上のQuality設定で9割は決まる
品質あげたければQualityをあげろ、ということ

あとssimとかはサイズにほとんど影響を与えない
x265 tuneも関係ない
Optimizeとかいてあるとおりここは重要ではない

x.265 presetも重要ではない
x264でさえもVeryFastからMediumに変えると
時間が増えたあげくにサイズも肥大化した例も経験済み
だからここも大して重要じゃないからVeryFast固定で検証してる
ここもOptimizeの項目だ。

右上でQualityをさげつつ、Mediumにしてる人とかいたけど
そんなちぐはぐな設定してたらどっちが効果でてるかわからなくなるわｗ

>>727
勉強しろだのずいぶん上から目線だけどあんたよりよっぽどテストしてると思うわ
いろいろ変えて40回以上は試したし

左下のOptimize Videoのところは「サイズには」たいした影響を与えない
Optimizeという言葉から連想されるとおりの結果だった

>>728-729
釣りなのかもしれんが、x264やx265やエンコードについてちゃんと理解しないまま何度試そうが、
ただ空回りするだけであって、まともな検証結果にはならんし、まともな結論も出せんよ。

どう考えても重めのプリセットのほうが低ビットレートで高画質に出来るでしょ。

>>730
だからそういう上から目線で中身のないレスはいらないよ

いちユーザーは理論を勉強する必要もないし
HandBrakeの実装コードに深入りする必要もないんだ

設定のどこをどう変えたらどういう結果になったか、
だけ調べていけば、カンタンお勧め設定みたいなものはわかるはずだ

ひとりで全部やるのは時間がかかるが
ここの住人でパラメータ変えて検証すればある程度見えてくるだろ
あんたみたいにソースによって違うだのと言ってたら始まらない

>>731
VeryFastとかの設定があるx265 presetのところの話？
それなら上に書いたように予想と逆になることがあるんだよ
速度落としたのにファイルサイズ大きくなってるわ、っていうケースね

その辺は開発陣もわかってるから「Optimize扱い」なんじゃないの
品質あげたければ俺は右上のRFまたはビットレート指定を上げるよ

>>732
基礎すら理解せずHandbrakeで大雑把なパラメータだけ適当に触って遊ぶのは個人の自由だけど、
基本を勉強する気が無いのに支離滅裂なことばかり書き散らかしてるから忠告（警告）してるわけで。
もう一度言うが、検証するというなら、ちゃんと勉強して意味を理解したほうがいいよ。

一例にすぎないが、>>713と同じソースで試した結果を貼っておく。
x264とx265で、それぞれcrf=20でプリセットをveryfast,medium,slowerに変えたもの。
一応指定するパラメータをあわせたが、上のほうでも書かれてる通り、
x264とx265とではパラメータの値の意味合いも異なるってことも理解すべき。

------
　　・x264 --preset veryfast --tune ssim --ssim --crf 20
　　　　SSIM Mean Y:0.9927184 (21.378db)、kb/s:6947.97
　　　　x264エンコード時間 : 0時間 1分24.1秒
　　・x264 --preset medium --tune ssim --ssim --crf 20
　　　　SSIM Mean Y:0.9946209 (22.693db)、kb/s:5822.43
　　　　x264エンコード時間 : 0時間 2分12.7秒
　　・x264 --preset slower --tune ssim --ssim --crf 20
　　　　SSIM Mean Y:0.9948708 (22.900db)、kb/s:5058.01
　　　　x264エンコード時間 : 0時間 5分 3.5秒
------
　　・x265 --preset veryfast --tune ssim --ssim --crf 20
　　　　 SSIM Mean: 0.993587 (21.930dB)、kb/s: 7069.76
　　　　x265エンコード時間 : 0時間 3分49.3秒
　　・x265 --preset medium --tune ssim --ssim --crf 20
　　　　 SSIM Mean: 0.993411 (21.812dB)、kb/s: 5071.90
　　　　x265エンコード時間 : 0時間 4分37.0秒
　　・x265 --preset slower --tune ssim --ssim --crf 20
　　　　SSIM Mean: 0.994393 (22.512dB)、kb/s: 4461.91
　　　　x265エンコード時間 : 0時間56分31.6秒
------

>>733
忠告だの警告だのって
あんたがH.264やHandBrake開発したわけでもないのに偉そうにするなっての

ユーザーが仕様の詳細や理論やソースコードを理解する必要はない


　　・x265 --preset slower --tune ssim --ssim --crf 20
　　　　SSIM Mean: 0.994393 (22.512dB)、kb/s: 4461.91
　　　　x265エンコード時間 : 0時間56分31.6秒

H.264なら1分24秒程度で終わるようなものを
56分もかけてエンコードするやつがいるわけがない
事実上役に立たないような設定コピペしてなにがしたいんだ

Slower設定がこんなに悲惨ならVeryFast固定でテストしてた俺のほうが
ずっとましな設定使っていたということになるだろｗ

まあ予想通りだけど、
　　> x.265 presetも重要ではない
　　> 左下のOptimize Videoのところは「サイズには」たいした影響を与えない
というアホな書き込みへの反証だってことすら理解できない気の毒なお脳の持ち主でしたね。

わいも適当にエンコードしてみたで
連番pngをエンコードしたからディスクのアクセスとかに時間かかってるし
作業しながらエンコードしてるからエンコード時間は参考程度に

https://www.dropbox.com/sh/pgrrh44t895ggwr/AACgcf9g1eeZulKUYl2ebjgTa/sintel_trailer_2k.txt?dl=0
https://www.dropbox.com/sh/pgrrh44t895ggwr/AABkbPu1pnO4w9mAhjqOfN6Oa?lst

ID:kqacNe4AもID:aEq4zpaLも、必死に「同じcrf値でx264とx265を比較する」という妄想から抜け出せてないｗ

x264とx265では、crf値の定義が違うんだから、同じcrf値にすること自体に意味が無いんだよ

比較したいなら、同じソース動画を、エンコ結果が同じビットレートになるようにエンコして、
その時のSSIMを比較するしかないの。

同じビットレートってのも妄想だよ。

>>736
おつおつ。

>>737
>>733でもちゃんと書いてんのに、なんでこう流れも内容も読めない奴ばかりなのか・・・。

ID:kqacNe4A
ID:aEq4zpaL
基地外同士の幼稚な戦いは他のスレたてて勝手にやってくれよ

>>737
批判されてRFってのが割といいかげんなのはわかったし
だから後からはビットレート指定でもいいと書いてるだろうよ
>>725 とか

>>739
おまえも>>733でRF指定してるだろｗ
意味合いが違うと主張するならRF指定はするべきじゃないはずだ

しかもいろんなパラメータ同時に変えてるせいで意味不明になってる

同時にいろんなパラメータ動かしたら組み合わせが無限になって
収拾付かないだろう

>>741
>>735

>>736を見てみたけど、勘違いする人がいるかもしれないので一応補足。
MP4をクリックして出てくるプレーヤーは再エンコされた荒い画質で再生するものなので、
置かれているMP4ファイルは、ちゃんとダウンロードしてMPC-HCとかでフルスクリーンで見ないと
それぞれの画質が正しく確認できない。
x264とx265の違いを見るなら、とりあえず以下の２つがお勧めだと思う。
同じ400kbpsでエンコ時間も同じくらいだけど、画質は x265veryfast >> x264slower。

[sintel_trailer_2k_x264slower_400kbps.mp4]
SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 0.959798
OverallPSNR:40.7928
総エンコード時間:0時間4分24.6秒
ttps://www.dropbox.com/sh/pgrrh44t895ggwr/AAByQHVRizhpu1tKf52wnUaoa/sintel_trailer_2k_x264slower_400kbps.mp4?dl=1

[sintel_trailer_2k_x265veryfast_400kbps.mp4]
SSIM: Structural Similarity Index Metric 0.23
Average SSIM= 0.963623
OverallPSNR:42.2195
総エンコード時間:0時間4分37.2秒
ttps://www.dropbox.com/sh/pgrrh44t895ggwr/AABfvizIuvCv_DzdNdUl0xjqa/sintel_trailer_2k_x265veryfast_400kbps.mp4?dl=1

>>743
SSIMやPSNRはどのツールでチェックしてるの？

HandBrakeの Encode LogにもSSIMの値が出てくるけど
既にエンコード済みのファイルのSSIMをチェックしたい

>>744
SSIMは少なくとも、入力されたオリジナルと出力されたエンコード後のフレーム同士で計算する物だから
エンコード済ともなると比較対象が無いから算出出来ないハズよ

>>744-745
sintel_trailer_2k.txtにちゃんと書いてくれてるよ。
Avisynthに２つのクリップからSSIMやPSNRを計算してくれるプラグインがある。

> ※画質の比較にはAvisynthのCompareとSSIMフィルタを使用しました
> SSIM(clip1, clip2, "csv", "txt",scaled=false)
> Compare(clip1, clip2, "", "txt")

>>740
頭の足りない2人の争いじゃなくて1人の自演な。文体も一緒なら狂ったように書込む時間帯も一緒
ただ笑われたいだけなんだろうから、笑ってやるだけで放っておけばOK。
100歩譲ってもx265スレでやる話題なのに相手にされないからここに来てるんだろ。気になるならssimやRFでNGにしておけば。

それよりHandBrakeスレとしては>>683の文字化けの件を早めになんとかしなきゃな

もう直ってるからそれ

これか？早いな
Changeset [6701] by sr55 WinGui: Fix an issue with non-ASCII characters in the new JSON Scan …

特に急いで縁故する動画がないときは以前H256でやったヤツを
Placeboにしてゆーーーっくりやり直してるおいらが通りますよ(´･ω･)

初心者が勘違いすると後々面倒だから書いとくが、tuneでssim指定するなよ。264, 265たる機能をオフにする設定だからな。数値上の基準画質をつくるようなものだ。効果を見るための基準に使うんだよ。
人が気づかないように情報を間引くのが目的だから数値化は難しいんだよ。

>>4の
mp4chapsのバイナリないぞ
ソースからビルドしようにもVS2013だとエラーでまくってビルドできない

>>752
世の中にはGoogleっていう便利なサイトや親切な人がいてな。
テンプレにも書き足したほうがいいかもしれんね。

この記事はためになった
http://bucci.bp7.org/archives/26839

SSIMが0.985以上になるような設定だと画質がかなりいいようだ。

x265で、VeryFast指定だとSSIMの値はこうなった。ソースはアニメ
RF20で、SSIM=0.9867
RF23で、SSIM=0.9848
RF25で、SSIM=0.9827
RF30で、SSIM=0.9752
RF35で、SSIM=0.9625

x264でも調べてみたが、x265に比べてRFを落とすにつれてSSIMが大きく低下していく。
RF35ではSSIM=0.9534、この辺になると相当画質が悪い

お手軽x265設定としては
x265, RF23, VeryFastあたりにしておけばSSIM=0.985くらい
になって、画質と時間のバランスが良さそうだった。

同じソースでMediumも試したが微妙だった
サイズはVeryFast比で15%程しか小さくならいのに、時間は45%程度増えた
さらにSSIMが悪化し0.9838になった。
サイズが15%減ったのも画質悪化の分と考えられる
x265 presetでスピードを落とすほどサイズ・画質でよい結果が得られるというわけではない。

x264でも心理的な画質の調整をしたらSSIMは落ちるから
SSIMの低下＝画質の低下とは限らないよ。

>>755
つまり、Mediumの時はVeryFastの時よりもRF値を小さくすることが出来る＝画質が上がる
ということだよ

なんで「ファイルサイズが15%減って画質落ちた(´・ω・｀)」で思考停止しちゃの？ｗ

というか、何度も指摘されてるように、RF値を使って議論するなよ

>>757
実際にVeryFastからMediumに変えて
SSIMが低下していたんだよ。RFは同じ23設定だ。

ごちゃごちゃ文句いってないで自分で丁寧に記録つけて実験してみろよ
色々やってみりゃわかるっての
思った通りにはならないんだよ
「Presetを右にずらして時間かけたほどよい結果にはならない」
約束されているのは、多く時間がかかるということだけだｗ


＞何度も指摘されてるように、RF値を使って議論するなよ

ソースが違ったら同等画質でもビットレートは変わる。
同一ビットレートなら解像度かえても画質が変わる
ビットレートはRFよりさらに議論に適さないと思うよ

RFで文句を言う人がいるからSSIMも書いてる

>>758 訂正
「Presetを右にずらして時間かけたほどよい結果にはならない」じゃなくて
「Presetを右にずらして設定し時間かけるほどよい結果にはなるとは限らない」

>>756
うん、x265とかではSSIMよりももっと高度で複雑な評価を
してるのはわかった。
けどそれを客観的に評価する方法はないわけでしょう？
だからSSIMで計測してる

実際に目視でのチェックもやってるけど
それはここに書いても誰にも伝わらないからね

>>754 の実験どおりRF指定はある程度SSIMとリンクしているし
品質をRFで設定するのは悪いとは思わない

伸びてると思ったらエンコのプロが講釈しててワロスｗ
一般ユーザーはそんなのいちいち気にしない
そもそも理解してない奴がお手軽で使えるのがhandbreakだし誰が使おうが自由
大雑把にｘ264の半分の容量で画質がほぼ同等のプリセットを一発提示すればそれで済む話なのに警告やら理解とかアホかｗ

あげちまった。
続きをどうぞ

なるほど>>754-762が全部自演と考えればこいつがこのスレでlこのあと何をしたいのか判るな。お仕事乙！

もしかしてQSVではインタレ保持出来ないのかコレ

ID:zX+W65ZDは多分こないだのID:aEq4zpaLと同一人物でしょ。
少しは調べる気になったようだけど、自分の思い込みが強すぎて人の話に耳を貸そうとせず、
RF値を基準にするという考えからいまだに抜け出せてない（本人は抜け出してるつもりかもしれんが）から、
初めて知ったらしいSSIMという数値に踊らされてしまっていて、色々なパラメータの組み合わせを
色々な視点から見るという姿勢に欠けており、せっかく>>757が書いてくれた内容も理解しようとせず、
無駄に反発してるだけ。エンコのプロどころか、初心者が背伸びして恥を晒してるだけだろ。
もうちょい人の話を謙虚に受け止めて考えてみりゃいいのに。

>>765
人の意見耳を傾けてるからSSIMも書くようになったんだろ

ビットレート指定のほうが的外れだぞ
ビットレートは同じ設定でもソースによって変わってくる

品質を指定してエンコードしたい場合はRF指定が基本
>>754 のとおりRFで品質をあげればちゃんとSSIMも上がってる

Mediumのほうが良いと思い込んでる人のほうが
よっぽど思い込みが強い奴だろ
俺はちゃんとエンコード実験してから考えを書いてる

>>757 が支離滅裂なのを理解できないお前も理解不足
SSIMが0.01違うというのは大きさな差だ
RF1段階か2段階は下のレベルの品質に落ちてる

>>765
リンク貼ったこれも読んだか？
http://bucci.bp7.org/archives/26839
ここにも
「ビットレートに関してはソースによって大きく変化する」
と書いてあるだろ
これ事実

あるレベル以上の品質を指定してエンコードしたときの
処理時間、サイズのバランスを話題にしてるんだから
ビットレート指定なんてのは的外れなわけ

ソース変わるごとに大きく変わるのならお手軽設定には使えない
ビットレート指定はファイルサイズを事前に決めたいときに使うものだよ

PresetをVeryFastから変更することで品質をあがると思い込んでる人に
ついてはそれは間違ってるとはっきり書いた。
あくまでもこれはOptimize項目でうまくいかないこともある
品質の指定はRFが基本。コマンド指定の、-q

>>766-767
なるほど。やっぱりこの間はSSIMの意味も理解せずに騒いでたわけか。
「２ちゃんでは間違ったことを偉そうに書くと答えが教えてもらえる」と言われてるけど、
本当にそれを実践してるというわけね。それは普通荒らしって言うんだけどな。
素でやってるなら「無自覚な荒らし」ってやつなんだが、迷惑な奴だなあ・・・。

荒らしではないID:XDC7hd9e先生による有益な書き込みまーだー？

同じソース、同じエンコーダーでの比較なら普通に有用（個人的に）。
だけどもオプション（今回はプリセット）による影響を調べるならビットレート指定で比較したほうが良いとされてる。
実際の利用でビットレート指定をする人は少ないだろうけども。
早い話、品質ベースは使用オプション等をもとにビットレートを決めるのにたいして
ビットレート指定なら同じ土俵でオプションの影響を直に調べられるから。

変なのが一人増えた

長々と書いたわりには　ID:XDC7hd9e　の書き込みが人の批判だけで終わっててワロタｗ

こないだID:aEq4zpaL（ID:zX+W65ZD）の相手をしたら、当人はもちろん他のスレ住人にも流れや内容が
全く読んでもらえなかった上、色々と変な決めつけまでされたりして散々だったからな・・・ｗ
俺の書き方にもちょっと説明不足な面はあったと反省してるけど、相手するとずっと続けそうだし、
講釈は嫌われてるみたいだし、スルーしたほうがええんちゃうの？

俺はどちらかと言うとID:XDC7hd9e(ID:kqacNe4A)の意見に同意するけど相手の批判するならただの罵倒じゃなくて
数値やら根拠を出したほうがいいと思うよ。ID:XDC7hd9eになってからの書き込みはものすごくみっともない。

>>772 >>769
ほんとID:XDC7hd9e　は人の批判しかしてないよね
やだやだ

>>773
HandBrakeやエンコードの話も一切してないあんたのが荒らしだわｗ

俺は自分なりの結論というかお気楽設定はわかったから延々と続ける気はない。

けどここの住人の指摘で勉強になったこともあったから
感謝の意味もこめてさんざん実験した結果をちゃんと報告したんだよ
まだx265試してない人には、お気楽おすすめ設定を提案できたはずだ。

x265のお気楽でかんたんな設定

そこそこ高品質狙いなら
x265でRF=23指定し、Preset=VeryFastはいじらない、ってやつ

これでSSIM=0.985以上のそこそこ高品質でできるし
x264に比べて平均36%近くはサイズ小さくできた。
もちろん圧縮率はソースによって変わる、あくまで平均。
ファイルサイズ半分にしたければもうちょっと品質を落とす必要があるかもしれない。

画質そんなにこだわらない動画はRFはもっと落としていい。
もちろん処理時間が大幅に短くなるメリットもある
RF23, 25, 27, 29の4種類くらい試せば落としどころは見つかると思う。

「VeryFastはいじらない」ってのはデメリットもいろいろあるから。
ソース次第で意図せずにRFで指定した品質よりも落ちることがある。
Medium変更で処理時間はほぼ確実に大幅に増えてしまう。
サイズはちょっと落ちるけどデメリットのが大きいと感じる。
よっぽど暇な人以外は、VeryFastのままでいいと思う

RF君は頭悪すぎるんだよ

例えば、
　エンコ後のビットレート1Mbps固定にし、
　プリセットVeryfastとMediumtonoSSIMを比較する

たったこれだけのことが出来ない。
延々とRFいじって悶えてる

>>777
ビットレートが画質と直接の関係があると勘違いしてる
あなたのほうが頭が悪いよ
同じ勘違いしてる人はたくさんいてずいぶんバカにされたけど

エンコード方法が少しでも違えば
同一ビットレートでの比較は意味をなさない

x264やx265といった違うVideo Codecでの比較もしているのだから
同一ビットレート指定は意味不明なわけ

何を言ってもこんな感じで、自分が無知無能であることを受け止めずに、
アドバイスしてくれた相手をバカにし続けてるのがRF君なんで、
彼にバカにされたいマゾな人はアドバイスしてあげればいいと思うよ。

まぞです。
>>775
36%小さいというのは良い情報だ。スレチな話題だったがひとつの目安にするよ。 ssimの呪縛から解放されてるともっといいけど。
fastよりmediumの方がサイズ的に小さくなるのは時間をかけて間引くところを探すからだ。当然ssimは悪くなる。が、人は気づけない。というのが264,265のシナリオ。おわかりのように目的で設定は異なる。
動画投稿サイトへ何か上げると知見が広がるよ。容量が少ないから俺の動画だけ汚い！きれいにすると再生時間が短い！ってなる。パラメータをチューンしないと見れたもんじゃない。

あとビットレートは結果であって設定するものじゃない。原理的に設定できない。円盤焼き用に無理やり近似で出してるだけ。つまりdvd焼いてた頃の知識はまったく通用しない。

>>778
小学校理科からやり直せ。
ここまで低能だと人生悲惨だろうな

>>778
同じビットレートで画質がいいならそのコーデックが優秀ってことだろｗ

エンコ後の動画の下のチャプター○○って表示を入れないようにするにはどうしたら良いでしょうか
また、エンコ後の動画から消すにはどうしたら良いでしょうか

>>779
あんた>>777だろｗ
777が頭が悪いなんていう言い方するからお返ししただけだ
HandBrakeやエンコードの話をしないなら書込みをしないでくれ

>>780
平均で36%という数字のサンプルは5種類（アニメ4、実写1）程度なんで
あくまでも参考ね
動画はYouTubeにアップしてるよ、
アップロードするのはx264, Full HD, RF20, VeryFastのほぼデフォルト
だけど綺麗になってるよ
画質いじらなきゃいけないのはニコニコとか？

>>782
圧縮の効率がｘ265の方が優れているのは明白だし、そこは疑問はもうもっていない
x264と比較したいのは、エンコード時間やファイルのサイズだよ

同一コーデックでもオプションを変えれば微妙に異なるロジックで
エンコードをしていることになるしビットレート指定は微妙だよ

HandBrakeの推奨してる品質指定はRF指定だし

>>780
＞mediumの方がサイズ的に小さくなるのは時間を
＞かけて間引くところを探すからだ。当然ssimは悪くなる。

呪縛といってもそれしか客観評価する方法ないらしいしなあ
俺はUltraFast, VeryFast, Mediumの3種類をテストしてた。
それで3種類だとVeryFastが一番SSIMが高くなった
だから設定を右にずらすほどSSIMが下がるわけでもなかった。

RF23 UltraFast , SSIM=0.9825, time=6分17, size=27.7MB
RF23 VeryFast , SSIM=0.9848, time=8分31, size=32.0MB
RF23 Medium , SSIM=0.9838, time=12分18, size=24.1MB

ファイルサイズが一番大きいのはUltraFastだと予想できるけど
実際はVeryFastが一番大きかった。

結局、profile指定を変更すると予想と違う結果になることがある
エンコードが終わってみないとわからないデメリットがあるのは確かだと思う

そのRFの調整が甘いという可能性は考えないの？
実験しようという熱意は凄いと思うんだけど・・。
一度でいいから2passでやってみてよ

何も理解できてない荒らしこと、ID:XDC7hd9e先生早くしてよ
日付変わっちゃったじゃん

各プリセットのcrf20〜30まで2刻みで適当にエンコードしてみたよ

http://i.imgur.com/SbLBEBw.png

先生、>>783にも

>>788
おつ。なんかx264veryfastだけcrfが+2されてるような図にも見えるね。
しかし問題はこのグラフの意味をRF君が理解できるかどうか・・・。

スレが伸びてたら読み飛ばせ！

>>788
これはちょっとソースが特殊だったかもしれない(736と同じ映像)

ソースをここのspeed_bagに変えてもう一回やってみた
http://media.xiph.org/video/derf/

http://i.imgur.com/NzrIHvN.png

>>792
検証オツです。
さすがにこう見るとHEVCは優秀だなｗ
同じSSIMを満たすのにやたらビットレートを低く保てるのがすげー

ということでx265のplacebo最強だな

Mediumでさえ途方もない時間かかるのに
Placeboなんて使えないわ

はやくIntel QSVがH.265対応してくれないかな

>>794
怖いもの見たさで>>713、>>733と同じソースをx265のplaceboでエンコしてみてる途中だけど、
さっき見たら52分かけて38%しか終わってないという状態で、予定時間を見る限りでは2時間を余裕で超えそうだｗ
終わったらそれも含めてID:YxYXecfT氏と同じようなグラフも出してみるよ。

結局こいつ>>707 あたりでバカにされたから意地になって延々と自演してるってことでFA?よけい馬鹿を晒してるだけにしか見えんなｗ

>>797
原因はそんなとこだろうしRF君が馬鹿晒して続けてるのはその通りだけど、自演要素は別に無いだろ。
自演だと言ってる人は何を自演だと言ってるんだろな。理由がわからん。

>>713、>>733と同じソースでPreset別のSSIMとビットレートとエンコード速度をグラフにまとめたから貼っとくわ。
　　http://2sen.dip.jp/cgi-bin/upgun/up1/source/up1461.jpg
RF君にゃ読みとれないかもしれないが、他の人にはある程度の参考にはなるだろ。

そうやってすぐにエサに食いつくところだぁ（笑）

>>798
RF君は頑なにビットレートを見ずに比較し続けてるけど
結局はビットレートでプロットすれば、x265のMediumがx264を余裕で凌駕してることは
グラフにもあるように自明なんだよね

昨日、16bppの2passでプリセットだけ変えてエンコしてみたけど
SIMM値は　medium　＜　veryfast　だった
16ppの調整はまだまだってこと？

＊x265単体で--tune simmあり

>>798
おお、分かりやすい
乙です

流れ切って悪いがx264crfエンコで上限ビットレート設定って出来る？

>>802
もちろんできますん。

>>798
1枚目のグラフは誤解を招くよ
ビットレートを品質の基準だと考えている人がまだいるし
既に誤解した人も現れている様子

縦軸にSSIM、つまり縦軸に品質を指定したら
横軸は品質以外の数値にしないといけない
サイズの指標のつもりでビットレートにしたのであれば
誤解を避ける意味でも横軸はファイルサイズにしたほうがいい

ビットレートは品質を比較する基準にはならない

>>804
またRF君降臨かｗ

お前の中ではビットレートとファイルサイズが別物なんだ？ｗ
　ビットレート＝ファイルサイズ/動画の再生時間
だろがｗ
同じソース動画で議論する限り、ファイルサイズ比較とビットレート比較は同じことなんだよ

>>800
ビットレートを見てないんじゃない

俺は「ビットレートは品質比較の指標に使えない」
ということを理解してる
あなたは理解していない
そこの違い

ビットレートなんてCodecが違えば比較できなくなるし
ソースが変わればまったく違う値になる

同等品質(SSIM)ならx265のほうがファイルサイズが
小さくなることくらいはわかってる

ビットレート信者の人ほんと多いんだな

>>802
設定できるのはAverage Bitrateだよ
あくまでも平均値

Advancedとかには設定あるのかもしれないけど
そっちは深入りするつもりはないので知らない

>>805
ビットレートとファイルサイズはきれいに比例関係にはならない
自分でエンコードしてファイルサイズとの比率を計算してみなさい

＞同じソース動画で議論する限り、ファイルサイズ比較とビットレート比較は同じことなんだよ
違うよｗ
ビットレートがN倍になったらファイルサイズがN倍になるかといったらそうはならない
これが理解できない人は頭が悪いｗ

>>808
> ビットレートがN倍になったらファイルサイズがN倍になるかといったらそうはならない
> これが理解できない人は頭が悪いｗ
頭悪いんで、N倍にならない理由がさっぱり分からんなｗ

>>808
RF君（ID:fiYi2V7w）にはグラフの意味も読み取れないだろうと思っていたが案の定ひどすぎた。
言われた意味をちゃんと考えようとせず、支離滅裂な脳内理論で他人を馬鹿にして迷惑をかけるのも相変わらずだね。
複数の条件を入力するとパニックになって整理できず、枝葉末節や気づいた点だけにとらわれてしまって
論理的に考えることができないみたいだけど、
　　・「ビットレートとファイルサイズはきれいに比例関係にはならない」という君の考えは間違い。
　　　以前も書いた通り基礎知識が無さすぎるので、>>805の説明をしっかり考えてみよう。
　　・>>798の上のグラフは、
　　　　　「このソースをエンコードした場合、各コーデックの各プリセットは
　　　　　　このビットレート（ファイルサイズ）で、この品質（SSIM）を実現しているよ」
　　　という意味のグラフ。
　　　　　・同じビットレートの場合、どのプリセットのSSIMが最も高いのか
　　　　　・同じSSIMの場合、どのプリセットが最もビットレートが低く済んでいるのか
　　　など、プリセットごとの違いの意味をしっかり考えてみよう。
の２点から始めればいいと思うよ。
そろそろ自分でも何を言ってるのかわからなくなってきたんじゃない？
根本的に色々間違ってるから、一度リセットして謙虚に考えないと馬鹿のままで終わるよ。
釣りならそろそろやめてね。

>>802
vbv-maxrateとvbv-bufsizeってのを調べてみるといいと思う。
ただ「上限ビットレート」という概念にはちょっと注意が必要だけど。

自演の流れ切って悪いが、こいつ「ら」本人以外は内容は誰も気にしてないと思うが、ssimはもともとこういう使い方をするもんじゃないから、うっかりグラフ見て良く調べたな！なんて感動しないように。スルーするだけでおｋ

頭の悪さぐあいが丁度同じぐらいの２人がたまたま出合っていがみ合いながらも奇妙に噛み合った話が長続きしてるわけだからな。
これが同じ人の自演でないなら奇跡以外のなにものでもない。偶然の出会いを神に感謝して自分たちでblog作って続けるべきでは？
ここでバカの自演と白い目でみられながら続けてるよりずっと幸せだと思うよｗ

単発君達も自演自演と随分元気だな。
>>811が何を言いたいのかよくわからないが、SSIM以外でソース比の画質を
数値としてグラフ化できるような適切な指標があるなら教えてもらいたいもんだけどな。
あと俺は面倒だから--tune ssim --ssimで済ませちゃったけど、>>751、>>756あたりの話は理解してるよ。
もう１人の人はもっとちゃんとした値を出すためかエンコ後にAvisynthのSSIM()を使ってるみたいだけど。
それでも内容に問題があるなら具体的に指摘してくれ。RF君じゃあるまいし、ちゃんとした指摘なら聞くよ。
そもそもRF君の相手なんぞするなというのはその通りだけどｗ

まあ本当はssimじゃなくてpsnrを使うべきなんだと思うよ
あくまでもちょっとした参考程度だからそこまで気にすることはない

>バカの自演と白い目でみられながら続けてる
別に本人気にしてないんじゃない？白い目で見られようが自演が見え見えだろうが、「ホクをばかにしたこのスレを見返してやる！」と心に決めてやってるんだろ（笑）
真面目にx265を詰めたいんならx265スレにとっくに移動してるわけだし。

>>810
＞このビットレート（ファイルサイズ）で

「ビットレートとファイルサイズはきれいに比例関係にはならない」
これの意味がわからないひとは上から目線で説教たれるレベルにないぞ

ファイルサイズとビットレートがきれいに比例関係になっているか調べてみなさい
アニメだけでなく実写のものも見ること
ちゃんと電卓で計算してみればわかる事実だよ

横軸をサイズの意味で表現したいならファイルサイズにしたほうがいい

「ビットレートがN倍になったらファイルサイズがN倍になるかといったらそうはならない」
これ理解できる？

>>815 あんまりそうやって煽らない方がいいんじゃない？
↑みたいに顔真っ赤にして意地になって話続けようとするだけだと思うよ

ビットレートの定義が違うからレスが伸びる。
普通は円盤焼きを意識して1秒毎のビット数を指す。だから指標にならない。264,265にはこのビットレートという考えはない。ファイルサイズと時間から便宜上記録しているだけだ。だからファイルサイズと同義。誤解されるので横軸はファイルサイズの方が良い。

>>817
バカは意地になるから面白んじゃないかｗ
くだらないスレ違いの議論でのスレの無駄遣いを抑えたいなんて考えてる訳じゃないから勘違いしないように
頭弱い奴を煽ってバタバタになって、涙目で必死に書き込みしてる様が可笑しくってしょうがないんだよｗ

少なくとも俺は今更こんなとこでx265の設定つめる気なんて無いがなあ。
RF君の妄言を放っておいて勘違いしてしまう人がいたら気の毒っていうか、
なんとなくバカにバカと言いたい気分というか、それだけなんだが・・・ｗ
徒労感と暖簾に腕押し感は半端ないけど、意地になるから面白いってのはなんかわかるわ。

RF君(ID:fiYi2V7w)、今日も無知晒して大敗北か

>>820>>821
そうやってID使い分けるのもう少し整理しなよｗ　自演にもなってない自演すぎてバカ丸出しだぞ？

>>822
お前さんこそ自演だと騒いでるだけだし、バカ度で言えばRF君に並ぶかもしれないと思ってるんだけど大丈夫？
わざわざRF君に反応しちゃってる俺みたいなバカより酷いと思うぞそれ。

対立厨＋自演厨の手法ですか、基本的過ぎますね。何かくだらん話はやめろと言われると
「そうなんですよXX君の話がくだらなくて」
と子供みたいな言い逃れ、ガキですね。まだ冬休み続いてるのかなぁ。

まあ彼が2人か3人の人格に分かれてまで何を訴えたいのか、じっくり観察させてもらえばいいじゃないかｗ
どうせスレとしては当面のバグも解消してるし話題の少ない時期だから、スレ埋めてもらったところで大した実害はないし。
x265に関する話題は子供の落書きです、と後で注意書き書いとけばおｋ

ID:0sxXuTukこいつまだいたのか

今更言うのも恥ずかしいけど788と792のグラフの動画を作るときに--tune ssimを付けるの忘れるという初歩的なミスをしていました。
付け直してエンコードしました。
混乱させてしまって大変申し訳無い。

http://i.imgur.com/ZQl3NLq.png
http://i.imgur.com/dTiyhbx.png

せっかく検証してるなら以後はx265スレでやられてはいかがですか？似たような事が何度も話題になってますし
http://peace.2ch.net/test/read.cgi/avi/1418252184/
それともそっちに行けない理由が何かあるんでしょうか？

x265スレに持っていくレベルの話じゃないだろ。RF君に至っては初心者スレに行く資格も無い。

>>829
初心者ってのはビットレートが品質を表すと思って
いたおまえのことだ

x265最高君の流れまだ続いてるのか

W○W○Wとか☆チャンのパススルー音声問題はXMediaRecodeで再コンテナ（映像音声コピー）するとバッチリ治るな
5.1に切り替わる地点でカット編集すると尚完璧

>>830
>初心者ってのはビットレートが品質を表すと思って

正しくね？
もちろんビットレートが全てとは言う気もないけな

ガキの対立ごっこの自演は他でやれよ粘着くんｗ

夜中まで書き込み昼過ぎに活動再開
幸せそうな生活だよな

まあ、状況によっては同等画質でファイルサイズ半分っていうんだから
どこかでデータは省いているのは間違いないよな・・・

画質なんて基本ビットレートとエンコ時間に比例するよな

拾ってきた動画と自分でエンコした動画比べると全く違うんだよな
同じくらいのビットレートなのにｗ
特に黒い背景のところとかなんて俺のなんてもうね・・・ｗ

ま、handbreakeでお手軽エンコでエンコ時間も短いから当然なんだけどね

人間にとっては無くてもわからねーだろって間引いてるのもまたエンコードだからな。

x265は映画のオープニングとかでよくある背景真っ暗で製作会社のロゴとかが出て来る場面の
背景処理の粗末さが、人物にフォーカスが当たる場面の精細さの割に目立つかな…

仕方ないことだと思うけど

まあ例えば
MotionJpeg50MbpsとMpeg2-15Mbpsが同じぐらいの画質なんでビットレート至上主義じゃないなぁ・・・

>>840
そら別の形式を比較しちゃダメっしょｗ
MPEG2とh.264でも相当違うしね

そいや、みんなって2passってやる？
俺の中では2passってのは容量削るもんだと思ってんだけど画質が良くなるって言う奴がいるんだよな

そんな粘着くんの独り語りはここには向いてなさそう。以後はこちらでどうぞ↓
http://wktk.2ch.net/test/read.cgi/mental/1405001637/

使い方しだいでしょ。
基本的にビットレートの変動幅が小さくなるぶん画質は安定するしさ。
ぼくは容量を抑えたいからcrf使ってる。

>>841
自分の指定したビットレートへ如何に近づけるかってのが2passだと思ってるから俺は使わないな。
ビットレートの概算が出来ればファイルサイズの予測もある程度出来るから、どっちの解釈でも
大きく逸れたりはしないだろうけどｗ

>>841 >>844
おおまかなサイズを指定したいときに使うのが
ビットレート指定でしょ
品質はHandBrakeにおまかせ

おおまかな品質を指定したいときに使うのがcrfの指定
サイズはHandBrakeにおまかせ

おはよう粘着くん。
そういうお前にうってつけのスレがあるから行ってみたらどうだ？
http://wktk.2ch.net/test/read.cgi/mental/1421022064/

ID:VoYuaSL5がスレ常駐のRF君ね

>>832
もう少しｋｗｓｋ

TS→Handbrake→XMediaRecodeということ？

0.10にしてからdolby pro logic2で音が崩れやすくなってる気がする
スピーカー変えたから崩れた部分が聞き取りやすくなっただけかもしれんけど

音声エンコーダで変わったのはデフォルトがfaacからlibav aacになった所だけど。
気になるならfdk-aacも試してみては？

intel QSVってH.264専用？
pc新調したから糞重い設定でテストしてみたかったんだけど、なんか残念・・・

QSVの今のバージョンはMPEG2/MPEG4出力対応とあるから一応MPEG2出力の機能もあるけど
需要の関係で大抵のソフトはH.264のMPEG4出力のみ。デコードにはQSVも使うだろうけど
どうしてもMPEG2出力に使いたければTMPGEとかが最近言ってるみたい。まああのソフトはもともとMPEG2向けだから

>>850
うーん、音質はやっぱりFDKのがいいね、エンコ速度が３割ほど落ちるのが辛い
妥協してavcodecのステレオ128ｋでまわすことにする
どうしても気になるレベルの作品だけFDK使えばいいかなー

G1820のQSVだとBest Quality選べないのね・・・

QSVのquality指定はHaswell以降でないと7段階じゃなく3段階までしかない筈で、スライダーに出てこないのも
それが理由なだけと思われ。どっちかの端に寄せとけばbest quality相当になるはず。3段階だからといって
品質が悪いモードしかないというのじゃなく選べるステップが少ないだけ。
logで見たときにCLIのtarget-usageで1が指定されていればbest quality相当

QSVってHaswellの新型CPUは未対応？
Intel Core i7 4790K使ってるけど、未対応って出る。

>>856

グラボ挿してるなら>>412-413とか

>>856
CPUそのものは対応してる
IvyのCeleronですらQSV対応

グラボ挿してて設定してないんだろうな

設定する必要などない
ハードエンコはウンコ

お気に入り動画はtsのまま残すし
どうでも良い動画のみエンコするから
qsvエンコで十分なんだよな〜

cliでqsvエンコするときに target-usage 1（best quality） lookaheadをオンにする場合 引数は
--encopts=target-usage=1:lookahead=1
であってますか？
なんだか初歩的な質問で申し訳ございません・・・

マルチバイトファイル名で質問です。

一時 svn で i18n対応版があったと思うんだが、現行版は i18n 対応せず？
コンパイルオプションで(ライブラリも？)サクッと対応可能だと思うんだけど、マルチバイト対応は眼中に無しなんでしょうか。

ん？別に今は2バイトファイル名で使えてるのでは？
気分的にコンパイルオプションを変えてほしいと言うだけの話ならフォーラムに投稿するべき

今は問題なく使えるでしょ。

Windowsアプリで想定しているネイティブなマルチバイト文字列はUTF-16LEもしくは言語ごとの標準(日本ならCP932)だが
libhbはUTF-8だからやり取りするときに正しく変換しないと化けるという話であって
コンパイルオプションでどうにかなる問題ではない。

QSVはさっさとH265対応せい

QSVだと24フレ化にならない動画あるな

>>866
何が言いたいのかよくわからないので具体的にkwsk

撮り貯めた映画をQSVエンコしてんだけど
同じ設定
dettelecine=default
decomb=default
でやってるけど実写はちゃんと出来上がり23.976フレになってるけど
1作品（アニメ映画）だけ29.97フレになってカク付く

送出側ですでに縞なしになってる。
たまーに縞解除済みテレシネソースが存在してる（青・赤・緑のテーマカラーを持った有料チャンネルで）。

そのアニメがもとから24fpsからテレシネ化されてない可能性
デジタルリマスターしてない作品やモノによってはデジタルアニメでもたまにある

>>863,864

ありゃ、日本語ファイルokですか?!　ログ見たらエラー吐いていたので未対応だと思っていた。
追試しやす..orz

SVN6507からSVN6798に変えたやけど2passの1pass目を速くする"Turbo"が効かないんだけどウチだけ？

同じ動画を264と265でエンコしたけど
暗部は264の方が綺麗に仕上がるわ

51チャプターある動画をエンコードしようとしたら途中でエンコードできないで強制終了しちゃう
結局10チャプターくらいで分割して結合したんだけど無劣化だと微妙にビットレートが違うせいなのかうまいこと結合できない
誰かいいツールか解決策を知らないか？

>>874
必要なチャプターのみで編集しISO出力する。

そのISOをマウントしてVOBファイルのみ取り出す。

vobmergeで一つのvobにしてhandbreakに読ませる

win7 64bit 　メモリ１６０００で８０００をramdisk

最新版、起動しないんだけど・・・何故？

>>876
頭が悪いから

そういうのはいいです＾＾

全角半角英数混在。数値の単位が書いてないから読み手が類推しなくてはいけない。
内容が漠然とし過ぎていて答えようにも、逆にこっちが聞きたくなることが多いから余計めんどい。

結局めんどい。

16000なんて中途半端な容量のメモリあったっけ
1024の倍数にしかならないと思ってたわ

>>880
16000GBだよ

どこのスパコンだよ

メモリで16000と言えばPC3-16000のことしか思い浮かばなかった

>>872
svn6822で"Turbo"復活確認！

x264とx265をslow&crf23でエンコしてみたけど
暗くて動きのある場面でx265はブロックノイズ出た

サイズはx265の方が小さいけど
半分のビットレートで同画質って嘘だろ

またcrf君か、、、

ノートPC ny2300s
http://faq.epsondirect.co.jp/faq/edc/app/servlet/relatedqa?QID=023652#spec

Win7 Core i5 HM76 Express HD グラフィックス 4000でメモリを16Gに換装
その内メモリ８Gをramdiskに振り分けてる

Handbrake.exeをクリックしてもタスクマネージャのプロセスには表示されるけど
一向に起動しない
ノートPCだけどエンコするには十分だと思うんだけど・・・。

何故・・・？

バージョンを「最新版」としか書かないのは死亡フラグ

最新版っていうからには Windows 10 だろ

あ

>>887
最新版使ってるからだろ

>>887
16Gbのメモリか
珍しいの使ってるな

品質指定の変換は当てにならないの？
どんなのビットレートで変換するかわからないから元よりでかいファイルを出力したりするから

末端の一利用者は気にせず使ったらいい。
画質と容量を求めるならそれしかないし。

>>894
それって品質指定の変換？
平均ビットレート？
どっち？

品質指定の数字の目安って何かありますか？

もち品質指定だよ。
アンブガーとか言わずある程度、割り切った人向け

1080のHDなら
実写：　24〜25
アニメ；　22

720のHDなら
実写；　23（ソースによるが24だと厳しい
アニメ；　22

480のSDなら
実写：　22前半
アニメ：　22

これプラスqcompとかdeblockのポリシーもあるんだけど略

そうか
元が綺麗な動画ばかりならいいんだけど広いとかできたないのがあるからアンブにしとくわ
本当に綺麗なやつだけ品質指定しとくわ

結局動画の拡張子とかあるけどなんなん？
動画の圧縮とか品質はコーデックに依存するイメージ持ったんやけど

拡張子はwindowsが判断するだけのものじゃなかったっけ
コンテナとよく混同されるけど関係ないよ

>>899
ごめん拡張子じゃなくてフォーマットだわ
おれの前のイメージはフォーマットごとに中身も違うイメージだったけどコーデックを知ってからは結局コーデックが開くのに肝心でフォーマットはあまり関係ないイメージ

>>900
イメージイメージと曖昧な連呼ばかりせずに、少しはちゃんと調べろよってイメージ。
Handbrakeスレじゃなく初心者スレでやるべき話だろってイメージ。
初心者スレに行くにしても、質問するならもう少し会話が成り立つようにまともに書けよというイメージ。

WおWおW　☆チャン　パススルー音声問題（ﾎﾜﾝﾎﾜﾝ音声）解決、俺のやり方

今までどおりこのソフトで音声パススルー指定してMP4エンコさせて終わらせる
出来上がった音声ﾎﾜﾝﾎﾜﾝ状態のMP4をXMediaRecodeに放り込んで
[ビデオ]と[音声トラック]タブのモードをそれぞれ「コピー」に選択して
[形式]のプロファイル：カスタム　形式：MP4　ファイル拡張子：mp4 に選んで[リストに追加]ボタン押して再エンコ（MUX）する

これだけ

必要ならクロップ/プレビューで頭と尻カット指定すれば2ch→6ch(5.1ch)の切り替え時の不具合解消される
（TMPGEnc Video Mastering Works 5とMPCだと音声2chと誤判定するみたい）

要は放送TSのMPEG2 AACがMP4コンテナに格納されると規格外で不具合出るってだけ
XMediaRecodeで再MUXするとMPEG4 AACにプロファイル書き換えられて正常になる

>>902
今までありがとうございました＜＿＿＞

902をHandBrake内でやるとやっつけでこんな感じか
http://pastebin.com/aTAqYQZv

これでパススルー時の問題は解決するけど、通常のエンコードでブツブツ言うのは
TSからaacを抜き出してQuickTimeやfaadでデコードすると問題ないのでffmpeg/libavのバグでしょう
古いバージョンだとOKというのはおそらくデコードにfaadを使っていたためだと思われる
https://trac.handbrake.fr/changeset/3793

>>904さんビルドがあれば一発で事足りるんすよね？
是非！是非！

x.265期待はずれだったわ
同ビットレートでも暗部はx.264方が綺麗だし・・・

x264で暗部が綺麗になったのはつい最近なんだけどなぁ

その無意味なコピペいつまで連投する気なんだろうね

結局x265ってビットレートが低くても
誤魔化してそこそこ見れる絵になる感じやね

だからビットレート上げても
そこそこの絵にしかならないから
保存用にはx264の方が使える

まぁ、そんな戯言はあらゆるデータから否定されてるんだが

そうなんだが構ってほしい一心の書き込みに構った時点でチミもネットに向いてないよ

あぁ、そういう古い2ch感捨てたほうがいいよ？
今は2chのスレ上でのどうこうってどうでもいいことだから
重要なのは、Google上に何が残るかってこと

昔の感覚で「荒らしはスルー」「釣られるな」とか言ってると、
スレが嘘や捏造だらけになって、それがGoogleに拾われて検索にヒットするようになる
そうなったら荒らしの大勝利なの。
つーかそれが奴らの目的ｗ

正確な情報でコツコツカウンターしていくのが今の2chの使い方

なんだ自演の子だったか

265をタブレット(atom3745)で再生したら80%まで跳ね上がったからタブレットには不向きだね
再生負荷ってこのことか

そりゃ再生支援に対応してねーからなw
今のNVとAMDの最新世代は265に対応しているんだっけか

そうかー
ハードレベルで再生してるんか
まだまだ途上なんやね

904で触れたTSソースの5.1ch AACデコードの問題をffmpegをデバッグしながら調べてみた
結論から言うとffmpegのAACデコーダの実装がいい加減なせい
以下詳細

・ADTSヘッダを読むと、チャンネルのマッピングやタグがデフォルト値に設定される
・AACビットストリーム内のPCEを読むと、チャンネルのマッピングやタグがPCEから読んだ値に設定される

・ADTSヘッダはADTS AACであれば全てのフレームに存在するが、PCEは特定のフレームにしか存在しない
・そのためADTS AACでは、PCEを発見してマッピングやタグが書き換えられても、次のフレームではすぐにデフォルト値に戻される

・PCEを読んでマッピングやタグが書き換わると、デコード用バッファのリセットが発生するためにノイズの原因となる
・地デジTSの場合、2chのビットストリームにはPCEが存在しないため、問題は起こらない
・しかし5.1chだとPCEが存在するため、ADTS AACの場合PCEを読む度にノイズが発生する
・ADTSでないAACの場合、最初にPCEが届く際にノイズが発生する可能性はあるが、それ以降は問題ない(*)

少なくとも
・ADTSヘッダの情報でチャンネルを設定した場合、PCEは無視
・PCEが届いたら以後はADTSヘッダのチャンネル情報は無視
のいずれかが最低限取るべき対策であると思われる。

(*)これはffmpegでの話で、libavの方は
・ADTSでないAACの場合、PCEが届いてタグがデフォルト値から書き換わると、以降そのチャンネルが無音になる
という挙動になる (>>418あたりがそれを踏んでるぽい)。

いつもありがとうございます＜＿＿＞
勉強になります！

作者に日本仕様のADTSとPCE問題改善要望しよう

ちゃんと動くようにすることはできるんだけど
それが仕様的に正しい修正かどうかが分からんのよね

あとMPC-HCとかLAV filtersとかWindows用のメジャーな動画関係のソフトはffmpegに依存してるけど
HandBrakeはlibavなので対応が微妙に面倒という問題もある
AACデコーダに関してはffmpegのほうが問題が少ない雰囲気なのだが

ffmpegが分離してffmpegは過去のものになるのかと思ってたら
ffpegのほうが安定してるとか、どういうことなんだろ？

一括変換は一つ一つファイルを選んでキューに貯めるしかないんだよね？

5.1ch AACの件、とりあえずバイナリを作ってみたから興味がある人は試してみてね
http://www1.axfc.net/u/3404374

>>922
GUIでは Source->OpenFolder で指定フォルダ直下の全ファイルを一括読み込みできるよ。
"Title"が読み込んだファイル数ぶんとなる。

>>923
ありがとうございます！！
後から試します！

その辺の動きはエンコーダにFDKを使えばまた違うの？

>>923
0.10.0のCLIのほうで☆のtsを試してみたところバッチリでした！
>>904のパッチを当てたものを自分でビルドしようとして挫折してたので助かりました
ありがとうございます

HandBrake-svn6867_x86_64-Win_GUIがバスターさんに(#ﾟДﾟ)ｺﾞﾙｧ!!されるんだが…
なんか仕込んだのか？

>>928
情弱ウィルスソフトだから仕方ないでしょバスター

>>929
その前verまで何ともなかったからさ
誤検出ならいいんだけどちょいと怖いわな

ヒューステリック系の検知を実装してるセキュリティソフトなら
Nightly build とかそういうのには頻繁に反応するよ。
殆どが誤検知。

>>926
エンコーダじゃなくてデコーダの問題だから何選んでも一緒だと思う

>>932
なるほどサンクス

>>579
これって、未だレスなしだよね。

実は自分も2パス選べず困っている。どうすればチェックマークを付けることができるのだろう？

>>934
試してみたけど、チェックボックスの下半分くらいをクリックしても駄目みたいだから
上半分あたりをクリックすればいいだけじゃね？

TABキー使え

ビットレートのテキストボックスを選択
TABキー押す
スペースキー押す（2-Pass Encodingがチェックされる）
TABキー押す
スペースキー押す（Turbo first passがチェックされる）

>>923
ﾌﾞﾁｯ…ﾌﾞﾁｯ…ﾌﾞﾁｯって入ってたのがキレイに消えてWOWWOW!!って感じ
感謝感謝

0.10のAACどのビットレートでも17khzで頭打ちになってる？

人からもらったDVDをエンコしてるがVHS取り込みらしく解像度が320x480 orz

ソース解像度以上でエンコはアナモルのとこCustomでイケるらしいが
widthは弄れず小さいままなのに
DisplayWidthだけデカくしてホンマにいけるの？

プレイヤーで再生時にデカい再生ウィンドウの中で小さい解像度のまま再生されないか?

結構前のバージョンから拡大エンコは出来なくなってたんじゃ？

>>935-937
助かりました。おかげでチェックできました。tabとスペースのコンボが一番楽でした。

>>923
の使い方が分からない･･･

何が分からないのかよく分からんけど
GUIで使いたいなら該当するverをインストールしてインストール先のexeとdllを置き換える

>>944
ありがとう
patch　ファイルはインストール先に移動させるだけでいいの？

いやいや
それは自分でコンパイルしたい人用

>>944
親切に教えてくださって　ありがとう

assファイル埋め込みできん！仕様？

0.10.1が出そうなのかな

上で話題になってるプチプチって音が途切れて聞こえるのは自分の家のスピーカが悪いせいだと思ってた。
しょうがないからAudio TrackでAuto Passthruを追加して、ごまかしてた。

QSV試そうと思ったら非対応だった。残念、オイラのThinkPad E420。
将来対応してくれないもんかなぁ。

ソフト側で個別対応するようなもんじゃないから環境の問題だろ
とりあえずビデオドライバアップデートしろ

早くQSVのインタレ保持対応してくれよ！

>>940
0.9.6で出来ました

QSVエンコならCRF値はどのくらいが良いの

20

>>956
プロレスを20でQSVエンコしたら、元ファイルより大きくなってしまった... ドラマとかは問題ないんだが。
Avg Bitrate 2048 でエンコしてみたが、こちらはバッチイ画像になってしまった。

動きが多い動画はQSVに向かないのかな。変換速度は魅力なんだが。

>>957
MPEG2やH264の圧縮原理を考えれば動きが多い映像の圧縮率が低くなるのは当たり前じゃん。
QSVじゃなくてx264でエンコードしてもビットレートが５倍とか変わってくるよ。ドラマにしたって、部
屋の中で話してるシーンが多いドラマと外に出て走り回ってるようなドラマでは倍違ったりする。

>>917
このソフトとは全然別のとこから検索で来たんだけど
5.1chのtsでプチプチノイズでるのはこういう原因だったのか
iosもandroidもほぼすべてのts対応動画ソフトがffmpeg依存だから
全部仲良くこの不具合持ってて悩んでた

元ファイルよりも大きくなってしまうことがある CRF のメリットって何だ？

>>923
神だわ
AndroidのBSPlayerが、
自前でクロスコンパイルしたlibffmpegを食わせられるっぽいから
パッチの中身参考に書き換えてビルドして読ませたら、
5.1chのtsもノイズなしで再生できるようになったよ
スレ違いだがすげー助かったありがとう

>>960
2passよりビットレートのふり幅が大きい

>>960
指定した品質を保ってエンコードしてくれることでしょ。
ビットレート指定だと、ビットレートが足りなくて画質が悪くなったり、
逆にビットレートを必要以上に無駄遣いしすぎたりすることになりえるし。

各ソースに対してどのくらいのビットレート振ればいい感じの品質になるかを判断するのって相当エンコード経験がないと無理だよね

そんなこたぁ無い

RF 0 とかにしてんじゃねえの?

>>963
そーなんだけどさ。
自分がエンコードするときって、タブレットに持ち出して見るってのが主目的。
4GBの壁があるんで、場合によって元ファイルより大きくなってしまうのは非常に困ります。
元々サイズを小さく(HD → SD)にするために使っているんで、
・画質が悪くなるのは我慢(エンコするんだから、元ファイルより良くなることは無い)
・無駄遣いは我慢(概ね時間に比例してファイルサイズが決まるんで、1時間800M位でok)

人それぞれいろいろな使い方があるので、Avg Bitrate でエンコしている自分からみてCRF使うシーンが思い浮かばなかったもんで。

プロレスくらいの動きで元ファイルより大きくなるとは思えないな
元ファイルがSDの低ビットレートとかだと大量発生してるモスキートノイズ等までエンコしようとして
無駄にビットレート食っちゃうことがある
x264だとvbv-maxrateとか他パラメータで調整できるんだけど
HandbrakeのQSVは設定できる余地がほとんどないから罠に陥りやすい

HandBrakeの、じゃなくてQSVの、設定できる余地な。HandBrake自体はQSVもx264もパラメーターはほぼ仕様のまま使えるんだけど
QSVはx264みたいにあれこれ弄れるわけじゃない

>>968
ですよねー。動きが多いといっても、たかがプロレス。もしかすると根本的に設定を間違っているのか？
下記設定でエンコードした結果なんですが、
前：735,268KB
後：991,710KB
でした。2台手持ちの機器で試したけど、エンコ後のファイルサイズは概ね一緒。
どなたかアドバイスください。

エンコード元ファイル
http://www1.axfc.net/u/3411691

Picture
Source
Width:720 Anamorphic:Loose Modules:16
Cropping:Automatic

Filters
Filters
Detelecine:Off Decomb:Default Denoise:Off Deblock:Off

Video
Video
Video Codec:H.264(Intel QSV) FPS:Same as source
Optimise Video
QSV Preset:Balanced H.264 Profile:High H.264 Level:Auto
Quality
Constant Quality:20

Audio
Audio Tracks
Codec:AAC(avcodec) Bitrate:128 Mixdonw:Dolby Pro Logic II

0.9.9のfaacか0.10のfdk-aacって同一ビットレートならどっちが良いんだ？

>>970
レスラーの動きがそんなに大したことないといっても、カメラのズームや切り替わりを短時間でやってるし（それに
伴って当然背景も変わる）、ビットレート膨れ上がって当然と思うけど。

もう265のplaceboしか愛せない

>>970
そのソース、MPEG2-TSかと思ったらH.264のTSじゃないか。
既にH.264のを再度H.264でエンコードしなおしてサイズが増えるのは元ソースよりも画質よくなるような
設定になってるってことだ。もちろん実際に画質がよくなるわけはないし、リサイズしてポータブルに持ち
出しとかするんじゃなきゃ、わざわざQSVで再エンコードする意味が分からん。

>>974
持ち出し用なんです。Nexus 7 16Gなんで、容量を節約したい。

>>970
20QPだとソース以上のビットレートを使ってるから24QPくらいにすればいいと思う

>>975
ソースがレコーダーで、それをごにょごにょで抜き出したんだろ？
もともとHWエンコーダーで圧縮されてるものを、さらにQSVでエンコードするのに必要以上の画質を
指定しても意味ねえよ。お前が求める画質なんてお前以外分からないんだから、数値を変えて自分
で納得する値を探しなよ。

タブレット用なら30QPでもいけんじゃね？

>>977
はい、通常時はH.264(ｘ264) Fast Aｖｇ Bitrate：2048 でエンコードしております。
時間かかるけど、QSVよりソフトエンコードの方が綺麗なので。

自分は持ち出し用に使っていますが、Handbrake の主目的って持ち出し用じゃないんですか?
人それぞれなのは分かっていますが、System Preset を見ても持ち出し用と考えるのが自然に思えるんだが。

市販のDVDをhandbreakで、mp4に変換すると、途中で止まってしまう、もしくは、途中までしか変換しないなぜなんでしょう？？？

>>980
プロテクトのかかっているDVDは、当たり前だけどHandbrakeではエンコできないよ
そういうソフトじゃないから

DVDのプロテクトに関しては別のスレで聞いてくれ

市販のDVDを、mp4に変換すると、22.14パーセントで止まってしまう、
なぜなのでしょうか？

今後の事を考えるとH.265でエンコしていくのが良いのかね
新型PS4もH.265対応する様な情報出てるし・・・

良い子で厨が湧いてくるからやめれ

>>983 元ソース、１次変換、２次変換とあると思うけど
１次変換はH264がまだしばらくいいと思う
H264すっ飛ばして、H265を１次変換にするにはまだちょっと先かなと思ってる

>>982
http://www.slysoft.com/ja/anydvdhd.html

さっさとx265 1.5よろ

trunkには入っとるでしょ