【TVMW】TMPGEnc Video Mastering Works 37
レス数が900を超えています。1000を超えると表示できなくなるよ。
ultrafastプリセットでの速さで追いつくなら7980XEの4倍ぐらいは処理能力が必要になる
NVEncだと260〜280fpsぐらいで処理されるからな
コア2.2GHzでブン回せば310fpsとか行くし >>815
GPUもオーバークロックすれば、NVENCの処理は速くなるの？ >>814
10年前からあるx264が現役だしなんの問題もないな >>816
ハイエンドでもローエンドでもエンコーダは一緒だから同世代型番違いで大きな差は無いけど、クロック依存だから多少速くなるってどっかで読んだからOCも効果あるのでは NVEncの細かいモデル間の比較だと、TMSCの16nmFinFET製造なGP104が一番回る
該当するのはGTX 1070/1070Ti/1080だけど、ダイの個体差と廃して考えると電源規模と品質高いほど高クロック動作するので、自ずと上位モデルがブン回る傾向になっちゃうけどね
それでも電源手を抜いているモデルでも2GHzは回るけども（持続できるかは冷却による）
同じ16nmFinFETのGP102（GTX 1080TiとかTITAN Xp）は演算コアの実効規模がデカすぎてGP104ほど回らないし、GP106（GTX1060）はグレード的に電源規模や品質に金が掛かっていないから回らない
（それでも概ね2GHzちょいぐらいは回るけど）
14nmFinFETなGP107（GTX 1050/1050Ti）はSAMSUNG製造でダイは小さいがTMSCの16nmFinFETほど回らないのと、
電源の造りもグレードなりなのもあって、〜2GHzぐらいが精々になる
無理の無いOCなら1.8〜2GHzちょいあたりに集約される（環境と調整で+0.1〜0.2GHz）で1割程度の差しか無いので
費用対効果は価格の安い GP107のGTX 1050/1050Ti が最良
14nmFinFETなGP108（GT 1030/MX 150）はNVEncが使えない（エンジン自体積んでいるかも怪しい、デコーダのNVDecは有る） 世代・旧モデルの差異は
Geforceは2タスク平行処理可能
Quadroは何故か1タスクのみ（Quadro用の機能に確保されてる可能性有り）
Kepler（Kepler世代全て）
・NVEnc実装（H264 8bit）
・FHDでパフォーマンス優先なら200fps越え（公称だと240fps 動作クロックにもよる）
・後継世代より設定による速度低下幅が少し大きい
Maxwell第1世代（GM107 GTX 750/750Ti）
・Kelper比でより高速化（実効1.5倍〜、ハイパフォーマンスなら2倍近く）とH264 10bit対応
・GM108（840M/860M）は使用不可（GT 1030/MX150と同じ扱い）
Maxwell第2世代（GM20x全般、GTX900系）
・HEVC対応（Bフレーム無し、CU上限32x32縛り有りだがH264より高画質は得られる）
・HEVC 4K対応
Pascal世代
・HEVC 10bit対応、8Kサポート
・4K等の高解像度処理時の速度低下を緩和（Maxwellより2倍近く速い）
・HEVC 8Kサポート
・4:4:4クロマサブサンプリング対応
・SAO サンプル適応オフセット対応
・ロスレスエンコード対応
何処まで扱えるかは、ソフトウェア側のSDKによる NVEncのvideoengineはGPUクロックをOCしてもクロックは引っ張られない。
つまり、videoengineはOCできない。 例えば地上波TVドラマ(CMカットして44分くらい)を全10話エンコするとして、みんなは何時間くらいで完了するような環境？
うちは一話2時間くらいでほぼ丸１日かかる >>823
編集しながらバッチ登録してエンコードと編集を同時に行いながらで
5時間も有ればおわるかな。 うちではMKVファイルにエンコード(1pass) >>821
おっ、ありがとう。
H.265/HEVCでBフレームが使うこと出来ればなぁ〜。 mp4、とても遅い、2passでやると1話6時間くらいかかるかな。
全10話だと3日付けっぱコースｗ
i72600でこんな感じ。 NVEncエンコード・Blu-ray規格の動画をカスタム設定で作ることは不可能ですか？ エンコは尺のの1.3倍ぐらいの速度の設定だな
普段からつけっぱなしの録画機でやるからあまり気にしないけど NVEnc選択出来る出力設定でm2tコンテナに直接出力出来ない糞仕様だから、コンテナの詰め替えせんと無理じゃないかな？
解像度やフレームレート、GOP長やVBV、Bフレーム数やビットレート等々の縛りは規格通りにやればいい >>824>>826
2パスの普通MP4だけど、1パスだと速いな
遅いだとやたら遅いけど、体感できるほどそんなに画質に差があるのかよくわからん >>826
x265で8bit出力してるなら、標準（medium）以上にプリセット上げていく都度ほぼ倍々に時間掛かっていく割に圧縮伸率伸びないから、そんなに時間掛かるなら、やや遅い（slow）ぐらいまで落としてみては？
やや遅い（slower）以上は10bitじゃないと処理時間に見合うほどの圧縮率向上は得られないと思う
1440x1080で3Mbps以上割り振っていれば、やや速い（fast）でも静止画比較してやっと解るか解らないかぐらいしか差が出ないんじゃないかな TVMW5ユーザーなんだが、6を購入してx264からx265への乗り換えを検討中。
しかしちょっと懸念が・・・
俺はインタレ保持派なんだが、x265ってインタレ保持は出来ないんだよね？
その場合、H.265コーデックによる圧縮率向上（約半分に）と、インタレ解除によるファイルサイズ増量（約二倍に）とできれいに相殺されて、
俺は全く幸せになれないような気がするんだけど、
どこか勘違いしてる部分はあるかな？
特に無いならがしょうがないから、x265がインタレ保持できるようになるまで寝てるよ。
x264も最初はコーデックの仕様通り、インタレ保持できなかったらしいしね・・・ またインタレース解除するとファイルサイズが倍になるとか思ってる人か…
2週間くらい前にもそんな話題になってるから読み直して来い。
そもそも何でインタレース保持したいんだ？ サイズ云々はともかく画質的にはインタレ保持リサイズなしがベストでしょ >>834
それだけ書き込む手間掛けたうえで、他人に頼るぐらいなら
お試し版落として確認すりゃいいだけじゃね？ お前の手間暇もイミフだがな
まぁ見送りが吉
インタレ解除で倍は言い過ぎだがH.265で半分も同様なんで、確かに相殺されてファイルサイズ縮小は大して期待できん >>829
正規のBlu-ray規格ではないかもしれないが
TAW6でSRになるようなファイルをTVMW6でNVENC使用出力して
PowerDVDでBDフォルダー再生してるけどね H265でインターレース出来るエンコーダは有るけど、
H265自体が規格として正規にインターレース対応してないから、再生環境方が限られていて困る事になる
ネイティブなインターレース環境なんて既に希少なんだから対応しなくていいじゃん！
…という方針らしいがライセンス受けてる側の一部からは対応の要望があるらしい 表示デバイスがインタレからプログレッシブに移行してかなりの年数が経過してるからねぇ
ただ遠い将来、MPEG2やMPEG4が使われなくなった後に過去の膨大な素材を使おうとする段階で苦しむ可能性は高いだろうけど
その頃には今ほどの精度でインタレ解除できる環境が失われているだろうし 265も正規に対応してるでしょ
オプションを非正規と捉えてるなら認識がおかしいのでは
BDのTrueHDやDTS-HDMAも非正規になってしまうぞ UHD BD(HEVC)の規格にインターレースはない。
ついでに30pもない。 コーデックの仕様と映像ディスクの仕様を混同するなよ デコーダーでインタレ表示実装してるやつ今のところ見たことないから規格にあっても意味のない状況 HEVCを商業目的でインタレ運用しているところ自体、聞いた記憶がないなぁ いまだと機器側が1080p出力固定になってるからそもそもインタレでる場面がないんじゃ？
いまでもインタレ必要なのって古い機器使ってる人とかTS抜いてる人とか？ >>849
動画のコマ送り時にインタレ出たりしないの？ HEVCでインターレース自体は可能なんだけど
PAFFとかMBAFFとか、インターレースの為のエンコード方法が規格に含まれていないから、圧縮効率がインターレースなだけで低下するうえ
単純にフィールドを交互に並べた一枚絵として圧縮するのので、量子化係数が上がるほど上下に隣接するフィールド同士の影響を受けて画質も低下しやすい
本来インターレースソースの画質保持のためにやっていたインターレース保持エンコードが意味をなさないのよ
無理にインターレースにしても画質が落ちて、画質を保持しようとすれば無駄にデカくなるだけ >>851
下手に60p化するよりマシだろ
そもそもフィールド分離されてないソースが主なんだから
再圧縮時に分離したところであまり意味ないと思うけどね
最近フィールドピクチャが採用されたBSには効果あるんだろうが
まあ、わざわざ265使わずに264でいいじゃんてことならその通りだと思う 専用の伝送システムなら、HEVCでも送出側と受信側がセットのシステムだから、PAFFやMBAFF対応の独自拡張しとけばいいから問題にならない
汎用じゃ無くて専用だからな 最近エンコ中に
出力プロセスとの通信でエラーが発生しました(6)
とかダイヤログ出て止まって事が多くなったんだけどなんやこれ
バージョンは６の最新なんだけど
出力プロセスとの通信って何？ｗ >>854
今は独自拡張が好まれない傾向が強い
後々のメンテに無駄な金と労力を取られやすいからね >>856
独自拡張を嫌うのはデータとして扱う場合で、機器間の通信規格の中に通す映像がなにで圧縮されているかは関係ない
伝送なんだから、Aの機器に入れた映像が伝送先のBの機器で取り出せればいい訳だし 取り出した結果が独自拡張されたもはやHEVCとも言えない変態ストリームだと色々大変だよな。 普通はSDIで映像信号出し入れなんだから、データで扱うなんざ編集や記録かカムのデータぐらいだろ
映像信号入れて、映像信号で取り出すのにその機械同士が何使って伝送するの気にするのか？ ああそうか経路の一部でってことか・・・。
でもわざわざ「H.265＋MBAFF」みたいな独自拡張をしてまでインタレ伝送を突き詰めるもんなのかな？
そこまでせずとも、おとなしくH.264かH.265の規格の範囲でインタレを使えばいいような・・・。
まあ業界の事情とか知らないからよくわからないけども。 専用の閉じた伝送システムにHEVCをわざわざ金と手前注ぎ込んで独自拡張して使う用途が一体どれほどあるというのか…
C/Pが合わないにもほどがある 受信して映像取り出す側が複数の場合、送信側で受信側の多い方でプログレッシブかインターレース決めてしまえば
受信側にプログレッシブ/インターレース変換機能を用意する数を最小限にして受信設備組めるから、設備単価が安く済むうえ既存設備へのマッチングのバリエーションも増やせる
i/p、p/i変換するのも最低限なんでレイテンシも抑えられる
MBAFFはマクロブロック単位で細工するから、PAFFの方が軽いし処理段組み込みやすい
PAFFなら圧縮前のフレーム生成段で偶数フィールドと奇数フィールドで上下に集めて、上半分が偶数フィールド、下半分が奇数フィールドの1フレームとしてエンコーダに放り込めばいい
受信側もメタデータでPAFFなら、デコード後の上下でフレーム分割してインターレースフィールドと扱うだけで済ませられるから、
メタデータの判定とフレーム加工処理をエンコーダの前とデコーダの後に有れば良いので、エンコーダやデコーダは自体殆ど触らず実装出来るのよ
MBAFFは旨く行けば圧縮稼げるたり速くなる事もあるけど、フレームの内容で処理量や速度に緩急付きすぎるうえ、実装はエンコーダにもデコーダにも手を入れなきゃならない と、微妙にスレの趣旨から外れてるので、ここまでにします
長々すまんかった >>863
それをするのにHEVCでなければならない特段の理由が見いだせない
もっとわかりやすく言えば、わざわざ独自拡張してまでHEVCにしがみつかなければならない理由になっていない
そう言えば理解できるのだろうか >>866
基本的に伝送の際の障害耐性に違いが出る
伝送解像度を上げる際に、FHD→4K/4K→8Kにするのに4倍帯域必要か、3倍帯域でお釣りが来るか
余裕分でエラー訂正のパリティに1/4帯域使うものを1/3帯域に出来るなら、帯域拡大で下がる障害耐性をある程度補填できる
もちろん選択肢的に伝送方式の方に金を掛けて信頼性を担保して、中に通すデータ方式をH264にするという方法もありえるけどね そこまで来ると妄想としか言いようがないな
付き合いきれん >>870
リサイズしないなら264でインタレ保持の方がいいよ >>873
H.264の粗さってなんぞや。
圧縮効率の差はあれど、ビットレートさえ十分に盛ればどちらでも綺麗になるだろうに。 high profileとmain profileの使い方間違ってるとかじゃないの？
H264だとhigh profileは高解像度での再生負荷軽減も盛り込まれてるから、圧縮高めで半端に解像度低いとエッジ部分の色滲みとか目立ちやすい（ビットレート上積みしてhigh10とか4:2:2以上使うとまた変わってくるけど
下手するとmain profile使うよりエンコ遅くて汚いとかになり兼ねないから、8bitでのエンコなら解像度によってはmain profileの方が良い場合も少なくない SDはmain profileにするといいってだけの話を
よくそんなにダラダラ駄文を書けるもんだ SDじゃなくてもドットピッチの大きい大型パネルで見るならmainの方が綺麗だよ
理屈理解しないので決め打ち判断しかしないならそれでもいいけど エンコーダーが正しく実装されているならHighの方が画質は上
仕様書見れば書いてあるのと同義
Baselineについては微妙なところだがあの超時空仕様を100%活用できてるエンコーダーはないから気にしなくて良い 仕様見てそう判断したの？
個別の機能がどういうものか把握してないで
、採用機能が多ければ必ずプラスにしか効果を発揮しないと思っているのなら仕様確認する意味が無い
僅かにあるデメリット部分（8x8 vs. 4x4 transform adaptivityでPSNRのゲイン判定で許容範囲されて大きいマクロブロックなると細部再現性が低下する、判定処理が増える分エンコが重くなる）が解像度の高さ≒高精細度で知覚的に誤魔化しが効く前提なのな
知覚されなければデメリット部分をみなしで無い物として、メリット部分（マクロブロックサイズの上がることで圧縮率の向上分他の画質保持にビットレートを配分出来る＆マクロブロック総数が減ってデコード負荷が下がる）が活きてくるというだけ
同様の事はHEVCにも言えるけど、この妥協的な処理部分が、俗に言われる「〜は高解像度が前提」とも言われる一因なんだがな >>880
細かい仕様なんて知らんけど、そもそもの話としてHEVCも同様なら
「265にすると264の粗さが気になる」とか言い出した>>873に対して
H.264のmainとhighの使いわけがどうこうと言い出した意味そのものがないんじゃないか。
仕様はともかく実用的にmainとhighの使い分けにそこまで有意な差があるかっていうとそうでもない気もするし。
（ちゃんと調べたことはないけど）
それに「264の粗さ」なんて雑な表現からして、そこまでちゃんと考えてはいないだろ、多分。
たまに見かける
・H.265でエンコしたらサイズ半分になった！すげー！（適当にエンコしただけで画質とかちゃんと見てるわけじゃない）
とかと同じようなレベルの話じゃないかと思う。 >>881
同様って書いてるでしょ、同一ではない
そりゃ、素の圧縮性能の差でHEVCの方が同じデータサイズで情報量多く出来るんだから、H264のhigh profileより粗が目立たないわな
考え方が局所的かつ短絡的すぎるんじゃないか？
俺は根拠付きで差が有る事を示しているのに、気もするとかの理由で根拠無く否定されても困るわ じゃぁ先のレスで仕様見て判断したのが、仕様の何処らへんかぐらい教えてくれよ >>883
俺も別に同一なんて言ってないし、元々H.264 vs H.265 の話なのに
main/highの話を持ち出す方がよっぽど局所的で短絡的なような気もするけど。
「粗い」って言葉からそれを連想するのはわからなくもないけど、そちらも別に
「highじゃなくてmainにすればH.265並みに綺麗だよ」
みたいなわけのわからん主張をしたいわけじゃないでしょ。
そちらも書いてるとおり、素の圧縮性能の差で綺麗に見えてるとかそんな話だと思うよ、多分。
実際のところは本人が出てきて意図を説明しないとわからんから、これ以上言いあっても無駄だけど。
あとmain/highの差自体については別に否定してるわけじゃない。
書いた通り自分で検証したことがないので詳しくは知らんというだけ。
個人的には「仕様はともかく実用的に」と書いたとおり、設定を極端に突き詰めるのでもなければ
あまり気にしなくてもいいんじゃねと思ってる程度。 お、おまえら、俺のちょっとした発言でややこしくしてすまんな…
言いたかったのは要するに↓みたいな違いがあるから、H.264だとどうしてもブロックノイズが気になる所が出てくるのよ（個人的感想です）
だから、幾らH.264高画質であろうとH.265の高画質と見比べちゃったら、俺的にはH.264には戻れないなと。
http://www.fujitsu.com/jp/group/labs/resources/tech/techguide/list/image-compression/p08.html >>886
リンク先のどれについて言っているのか、わからんぞ ただ圧縮効率が違うってだけじゃん
264のBDでブロックノイズなんて見たことないし
ビットレート下げすぎなだけだろ ファイルサイズを半分にしたいのか？
半分にするために5倍くらい時間がかかってもいいのか？
ってこと。 >>887
ブロックサイズの最適化の説明
リンク先じゃ容量削減しか話してないが、この最適化が圧縮時の品質に絶大な効果を発揮するのよ、あくまで俺の眼にはね
あ、更に後出しですまんけど、アニメみたいなのっぺりした画面じゃ違い判別出来ないんでは？俺は実写しかエンコしないし。 ブロックサイズの最適化がブロックノイズにって…
やはりプラシーボ効果はすごいね。 いやいや、おまえらが勝手に盛りあがっただけだじゃん ワッチョイ変わってるんだが、>>890（**76-）と>>886（**1f-）は同一人物なのか・・・？ >>885
「H.265並みに綺麗だよ」とは書いていない
お互いの行間の読み違いはあったのかもしれないが
粗さが目立つというのだから、細部表現と解釈して進言しただけだよ
ビットレート不足とか高い量子化係数での圧縮で起きるのはブロックノイズとディテールの喪失だから、粗いという表現にはならないだろうしね
後半のレスの意図は解ったけど、最初の方で
> 仕様見て書いてあるのと同義
としているから、仕様的なもの把握してレス付けているにはおかしいと思ってのレスなのよ >>895
UA同じだしキャリア回線と自宅回線の違いだろ >>855
もしQSVならエンコード部分が止まってる QSVへこれ圧縮してねと投げたのに応答がないから通信エラー
うちのおま環ではSandybridge(P67＆H77のマザー)とHaswell(Z97マザー)のころ頻発してQSVは使い物にならなかった
QSV使うソフトでもれなく止まるんで
いろんなVerのグラフィックドライバ試したりマザーのメモリタイミング緩めてみたりしたけどエラーはなくならず
すっかり諦めてNVEncだけ使ってた
この前KabyLake＋Z170マザーに入れ替えた(DDR3メモリ流用)ときにふと思い出してQSV試したらスイスイ動く クリーンインスコはしてない
使ってない間にWindows10の大型アップデートがあったりドライバが新しくなったからか
Kaby+新マザーにしたからかは今となってはわからん 結局お互い何がしたいんだ？相手の間違いの説得か？それ自分にとって意味あるのか？無駄じゃん ねえ、みんなはPGMX使ってる？
スマホでもメニュー付きの動画再生できるのは結構魅力あると思うんだけどな。
もうオリジナルのメニュー作成とかまでこだわる人が減ってるのかな。 そもそもPCなんかで再生しない
再生するにしてもmadVR通せないものは使わない PGMXのプレイヤーがMX Player Pro並みに使いやすければな
視聴環境の快適性を決めるのはプレイヤーなんだし
PGMXが高機能でも、その専用プレイヤーが糞なら意味が無い
mkv出力の場合は再生トラックが1つに制限されてメニューも使えないから潰しも効かない フルHDのエンコードについてお聞きしたいです
4K動画は除外して教えて頂ければと思います
【CPU】AMD Ryzen5 1400 (4コア8スレッド 3.2GHz)
【グラボ】GeForce GT730
【備考】TMPGEnc Video Mastering Works 6 で NVENC を使用して、H.264/AVCにエンコードする場合
【CPU】AMD Ryzen3 2200G (4コア4スレッド 3.5GHz)
【グラボ】なし
【備考】TMPGEnc Mastering Works 6 で AMD Media SDK を使用して、H.265/HEVCにエンコードする場合
(1)この2つを比較すると、どちらの方が早くエンコードが完了しますか？
(2)また同じ設定でエンコードした場合、画質に大幅な差(例えばどちらか一方で暗所のノイズが極端に目立つとか)はありますか？
(3)AMD Ryzen3 2200G と AMD Media SDK の組み合わせではH.264/AVCにエンコードできないという情報を目にしたのですが、事実でしょうか？ そもそも速度的にNVEnc>VCEだから264と265なら圧倒的にNVEncじゃないの？と思ったけどGT730か。 >>903
(1) 知らん。
(2) 基本的に同じビットレートならAMDのHWエンコードが一番画質が悪い。
H.264/AVCを使おうがH.265/HEVCを使おうが関係なく悪い。
http://mevius.5ch.net/test/read.cgi/avi/1486130737/335
(3) 質問する時は情報源くらいはちゃんと示した方がいいんじゃないの。
とりあえず以下の記事を見てみればいいと思うが。
やはりRavenRidgeのVCEは仕様変更か TMPGを試す
https://blog.goo.ne.jp/krmmk3/e/9d475dfe59f9a3d0b2f941bda3bd7093 2000シリーズのAPUでH264だとエラー出るのはバージョンアップで直ってる
H264でKepler世代のGT730相手なら2200Gの方が1割ぐらい速いんじゃ無いかな VEGAのHWエンコードは綺麗という噂はガセだったのか。
買わなくてよかった。 >>904 ありがとうございます、参考にします
>>905 情報源に関して申し訳ございません、AMD VCEの画質は悪いんですね…
>>906 速さをとるか画質をとるか悩みますね、ありがとうございます >>908
HEVCで画質確保とかね
流石にHEVC使われると、H264では画質容量比で勝てない（QSV相手だと微妙 NVIDIAにしろAMDにしろ、ベンチマークみたいな小学生でもわかるようなものにはキチガイみたいに争うが、
画質のような主観が影響してくるようなもの（=数字のみがすべてではないもの）になると、いつまで経ってもおぼつかない >>910
>>905で示したのはSSIMでの評価だから、主観評価ではまた変わるかもしれないけど、
少なくともSSIMでの評価では、AMDはHEVCを使っても他社のH.264にすら及ばないんだよねえ・・・。
というかQSVもNVEncもHEVCの調整がまだまだ未熟な感じで、>>905の評価から見ると
H.264を使った方が良い結果が出るというケースも多いのではないかという気がする。 NVENCのH.265は凄く綺麗だけどなあ
Bフレが無いから縮まないとか言うが、例えば固定品質35程度まで落として縮めてもそれほど汚くならない 何でもx264やx265基準の画質で評価する人は何処にも出てくるしね（気持ちもわかるが
エンコーダなんだから画質に重きを置くのは解るけど
CPU負荷が少なくて、エンコード実行している環境で他の処理を行う余裕も確保出来るというHWエンコーダの特性も評価しなけりゃな
ソフトウェアエンコーダでHWエンコーダ並みの発熱やCPU使用量に抑えたら、処理速度なんて更に落ちてしまうんだし
ソフトウェアエンコーダの最大の弱点とも言える処理速度面がHWエンコーダの最大の利点なのに、それ度外視して評価されてしまうのもね レス数が900を超えています。1000を超えると表示できなくなるよ。
