18/04/11 17:50:41.60 OUJRzihv0.net
HEVCでインターレース自体は可能なんだけど
PAFFとかMBAFFとか、インターレースの為のエンコード方法が規格に含まれていないから、圧縮効率がインターレースなだけで低下するうえ
単純にフィールドを交互に並べた一枚絵として圧縮するのので、量子化係数が上がるほど上下に隣接するフィールド同士の影響を受けて画質も低下しやすい
本来インターレースソースの画質保持のためにやっていたインターレース保持エンコードが意味をなさないのよ
無理にインターレースにしても画質が落ちて、画質を保持しようとすれば無駄にデカくなるだけ
852:名無しさん＠編集中
18/04/11 18:14:41.31 saI1okAg0.net
調べたら業務用で使われてるみたいだな
853:名無しさん＠編集中
18/04/11 18:35:16.39 7iAxOCgz0.net
>>851
下手に60p化するよりマシだろ
そもそもフィールド分離されてないソースが主なんだから
再圧縮時に分離したところであまり意味ないと思うけどね
最近フィールドピクチャが採用されたBSには効果あるんだろうが
まあ、わざわざ265使わずに264でいいじゃんてことならその通りだと思う
854:名無しさん＠編集中
18/04/12 01:16:40.28 VfB7DrWl0.net
専用の伝送システムなら、HEVCでも送出側と受信側がセットのシステムだから、PAFFやMBAFF対応の独自拡張しとけばいいから問題にならない
汎用じゃ無くて専用だからな
855:名無しさん＠編集中
18/04/12 09:46:06.53 z+PEpnvC0.net
最近エンコ中に
出力プロセスとの通信でエラーが発生しました(6)
とかダイヤログ出て止まって事が多くなったんだけどなんやこれ
バージョンは６の最新なんだけど
出力プロセスとの通信って何？ｗ
856:名無しさん＠編集中
18/04/12 10:37:07.86 WANQhGIfM.net
>>854
今は独自拡張が好まれない傾向が強い
後々のメンテに無駄な金と労力を取られやすいからね
857:名無しさん＠編集中
18/04/12 12:47:20.17 VfB7DrWl0.net
>>856
独自拡張を嫌うのはデータとして扱う場合で、機器間の通信規格の中に通す映像がなにで圧縮されているかは関係ない
伝送なんだから、Aの機器に入れた映像が伝送先のBの機器で取り出せればいい訳だし
858:名無しさん＠編集中
18/04/12 13:18:09.30 SxbRi3C8M.net
現場を知らない人間の戯言にすぎない
859:名無しさん＠編集中
18/04/12 13:27:54.68 ZcyNWyhH0.net
取り出した結果が独自拡張されたもはやHEVCとも言えない変態ストリームだと色々大変だよな。
860:名無しさん＠編集中
18/04/12 19:47:34.17 VfB7DrWl0.net
普通はSDIで映像信号出し入れなんだから、データで扱うなんざ編集や記録かカムのデータぐらいだろ
映像信号入れて、映像信号で取り出すのにその機械同士が何使って伝送するの気にするのか？
861:名無しさん＠編集中
18/04/12 21:12:41.90 ZcyNWyhH0.net
ああそうか経路の一部でってことか・・・。
でもわざわざ「H.265＋MBAFF」みたいな独自拡張をしてまでインタレ伝送を突き詰めるもんなのかな？
そこまでせずとも、おとなしくH.264かH.265の規格の範囲でインタレを使えばいいような・・・。
まあ業界の事情とか知らないからよくわからないけども。
862:名無しさん＠編集中
18/04/12 21:39:44.45 XFPntgD7M.net
専用の閉じた伝送システムにHEVCをわざわざ金と手前注ぎ込んで独自拡張して使う用途が一体どれほどあるというのか…
C/Pが合わないにもほどがある
863:名無しさん＠編集中
18/04/13 06:40:25.45 Sg2lKLiA0.net
受信して映像取り出す側が複数の場合、送信側で受信側の多い方でプログレッシブかインターレース決めてしまえば
受信側にプログレッシブ/インターレース変換機能を用意する数を最小限にして受信設備組めるから、設備単価が安く済むうえ既存設備へのマッチングのバリエーションも増やせる
i/p、p/i変換するのも最低限なんでレイテンシも抑えられる
MBAFFはマクロブロック単位で細工するから、PAFFの方が軽いし処理段組み込みやすい
PAFFなら圧縮前のフレーム生成段で偶数フィールドと奇数フィールドで上下に集めて、上半分が偶数フィールド、下半分が奇数フィールドの1フレームとしてエンコーダに放り込めばいい
受信側もメタデータでPAFFなら、デコード後の上下でフレーム分割してインターレースフィールドと扱うだけで済ませられるから、
メタデータの判定とフレーム加工処理をエンコーダの前とデコーダの後に有れば良いので、エンコーダやデコーダは自体殆ど触らず実装出来るのよ
MBAFFは旨く行けば圧縮稼げるたり速くなる事もあるけど、フレームの内容で処理量や速度に緩急付きすぎるうえ、実装はエンコーダにもデコーダにも手を入れなきゃならない
864:名無しさん＠編集中
18/04/13 06:41:18.14 Sg2lKLiA0.net
と、微妙にスレの趣旨から外れてるので、ここまでにします
長々すまんかった
865:名無しさん＠編集中
18/04/13 07:09:20.38 PQhsL5Ov0.net
ぼくのかんがえたさいきょうのこーでっく
866:名無しさん＠編集中
18/04/13 08:24:08.54 BRGPg0RxM.net
>>863
それをするのにHEVCでなければならない特段の理由が見いだせない
もっとわかりやすく言えば、わざわざ独自拡張してまでHEVCにしがみつかなければならない理由になっていない
そう言えば理解できるのだろうか
867:名無しさん＠編集中
18/04/13 11:57:16.34 Sg2lKLiA0.net
>>866
基本的に伝送の際の障害耐性に違いが出る
伝送解像度を上げる際に、FHD→4K/4K→8Kにするのに4倍帯域必要か、3倍帯域でお釣りが来るか
余裕分でエラー訂正のパリティに1/4帯域使うものを1/3帯域に出来るなら、帯域拡大で下がる障害耐性をある程度補填できる
もちろん選択肢的に伝送方式の方に金を掛けて信頼性を担保して、中に通すデータ方式をH264にするという方法もありえるけどね
868:名無しさん＠編集中
18/04/13 12:40:21.44 dqXETo/hM.net
そこまで来ると妄想としか言いようがないな
付き合いきれん
869:名無しさん＠編集中
18/04/13 12:44:39.98 e5RXuBbxM.net
端から妄想だろ
870:名無しさん＠編集中
18/04/13 13:00:38.55 BuU++oam0.net
で、H.265はやっぱ60p化した方が良いの？
871:名無しさん＠編集中
18/04/13 13:02:20.48 yCpqnivr0.net
おｋ
872:名無しさん＠編集中
18/04/13 13:41:11.21 e5RXuBbxM.net
>>870
リサイズしないなら264でインタレ保持の方がいいよ
873:名無しさん＠編集中
18/04/13 14:41:55.87 m+b9vXped.net
265にすると264の粗さが気になる
874:名無しさん＠編集中
18/04/13 15:27:21.28 +CW60tiR0.net
>>873
H.264の粗さってなんぞや。
圧縮効率の差はあれど、ビットレートさえ十分に盛ればどちらでも綺麗になるだろうに。
875:名無しさん＠編集中
18/04/13 16:48:38.94 Sg2lKLiA0.net
high profileとmain profileの使い方間違ってるとかじゃないの？
H264だとhigh profileは高解像度での再生負荷軽減も盛り込まれてるから、圧縮高めで半端に解像度低いとエッジ部分の色滲みとか目立ちやすい（ビットレート上積みしてhigh10とか4:2:2以上使うとまた変わってくるけど
下手するとmain profile使うよりエンコ遅くて汚いとかになり兼ねないから、8bitでのエンコなら解像度によってはmain profileの方が良い場合も少なくない
876:名無しさん＠編集中
18/04/13 18:10:18.97 e5RXuBbxM.net
SDはmain profileにするといいってだけの話を
よくそんなにダラダラ駄文を書けるもんだ
877:名無しさん＠編集中
18/04/13 20:37:36.91 Sg2lKLiA0.net
SDじゃなくてもドットピッチの大きい大型パネルで見るならmainの方が綺麗だよ
理屈理解しないので決め打ち判断しかしないならそれでもいいけど
878:名無しさん＠編集中
18/04/13 21:01:11.30 PQhsL5Ov0.net
なんだ適正な視聴距離も取れないただのバカか
879:名無しさん＠編集中
18/04/13 22:12:22.03 ImuHi7Loa.net
エンコーダーが正しく実装されているならHighの方が画質は上
仕様書見れば書いてあるのと同義
Baselineについては微妙なところだがあの超時空仕様を100%活用できてるエンコーダーはないから気にしなくて良い
880:名無しさん＠編集中
18/04/14 04:19:28.35 EMVmu1/I0.net
仕様見てそう判断したの？
個別の機能がどういうものか把握してないで
、採用機能が多ければ必ずプラスにしか効果を発揮しないと思っているのなら仕様確認する意味が無い
僅かにあるデメリット部分（8x8 vs. 4x4 transform adaptivityでPSNRのゲイン判定で許容範囲されて大きいマクロブロックなると細部再現性が低下する、判定処理が増える分エンコが重くなる）が解像度の高さ≒高精細度で知覚的に誤魔化しが効く前提なのな
知覚されなければデメリット部分をみなしで無い物として、メリット部分（マクロブロックサイズの上がることで圧縮率の向上分他の画質保持にビットレートを配分出来る＆マクロブロック総数が減ってデコード負荷が下がる）が活きてくるというだけ
同様の事はHEVCにも言えるけど、この妥協的な処理部分が、俗に言われる「～は高解像度が前提」とも言われる一因なんだがな
881:名無しさん＠編集中
18/04/14 12:42:14.60 yQp2n2100.net
>>880
細かい仕様なんて知らんけど、そもそもの話としてHEVCも同様なら
「265にすると264の粗さが気になる」とか言い出した>>873に対して
H.264のmainとhighの使いわけがどうこうと言い出した意味そのものがないんじゃないか。
仕様はともかく実用的にmainとhighの使い分けにそこまで有意な差があるかっていうとそうでもない気もするし。
（ちゃんと調べたことはないけど）
それに「264の粗さ」なんて雑な表現からして、そこまでちゃんと考えてはいないだろ、多分。
たまに見かける
・H.265でエンコしたらサイズ半分になった！すげー！（適当にエンコしただけで画質とかちゃんと見てるわけじゃない）
とかと同じようなレベルの話じゃないかと思う。
882:名無しさん＠編集中
18/04/14 13:01:20.51 qZj3121hM.net
根拠一切なし
883:名無しさん＠編集中
18/04/14 13:51:20.32 EMVmu1/I0.net
>>881
同様って書いてるでしょ、同一ではない
そりゃ、素の圧縮性能の差でHEVCの方が同じデータサイズで情報量多く出来るんだから、H264のhigh profileより粗が目立たないわな
考え方が局所的かつ短絡的すぎるんじゃないか？
俺は根拠付きで差が有る事を示しているのに、気もするとかの理由で根拠無く否定されても困るわ
884:名無しさん＠編集中
18/04/14 13:54:23.08 EMVmu1/I0.net
じゃぁ先のレスで仕様見て判断したのが、仕様の何処らへんかぐらい教えてくれよ
885:名無しさん＠編集中
18/04/14 15:01:25.57 yQp2n2100.net
>>883
俺も別に同一なんて言ってないし、元々H.264 vs H.265 の話なのに
main/highの話を持ち出す方がよっぽど局所的で短絡的なような気もするけど。
「粗い」って言葉からそれを連想するのはわからなくもないけど、そちらも別に
「highじゃなくてmainにすればH.265並みに綺麗だよ」
みたいなわけのわからん主張をしたいわけじゃないでしょ。
そちらも書いてるとおり、素の圧縮性能の差で綺麗に見えてるとかそんな話だと思うよ、多分。
実際のところは本人が出てきて意図を説明しないとわからんから、これ以上言いあっても無駄だけど。
あとmain/highの差自体については別に否定してるわけじゃない。
書いた通り自分で検証したことがないので詳しくは知らんというだけ。
個人的には「仕様はともかく実用的に」と書いたとおり、設定を極端に突き詰めるのでもなければ
あまり気にしなくてもいいんじゃねと思ってる程度。
886:名無しさん＠編集中
18/04/14 15:49:26.15 RnS3gyzzd.net
お、おまえら、俺のちょっとした発言でややこしくしてすまんな…
言いたかったのは要するに↓みたいな違いがあるから、H.264だとどうしてもブロックノイズが気になる所が出てくるのよ（個人的感想です）
だから、幾らH.264高画質であろうとH.265の高画質と見比べちゃったら、俺的にはH.264には戻れないなと。
URLﾘﾝｸ(www.fujitsu.com)
887:名無しさん＠編集中
18/04/14 16:07:07.31 hRt25UUT0.net
>>886
リンク先のどれについて言っているのか、わからんぞ
888:名無しさん＠編集中
18/04/14 16:22:40.98 6VCNeJPr0.net
ただ圧縮効率が違うってだけじゃん
264のBDでブロックノイズなんて見たことないし
ビットレート下げすぎなだけだろ
889:名無しさん＠編集中
18/04/14 16:36:22.35 PaVPSmYH0.net
ファイルサイズを半分にしたいのか？
半分にするために5倍くらい時間がかかってもいいのか？
ってこと。
890:名無しさん＠編集中
18/04/14 17:14:51.19 zRFq/N790.net
>>887
ブロックサイズの最適化の説明
リンク先じゃ容量削減しか話してないが、この最適化が圧縮時の品質に絶大な効果を発揮するのよ、あくまで俺の眼にはね
あ、更に後出しですまんけど、アニメみたいなのっぺりした画面じゃ違い判別出来ないんでは？俺は実写しかエンコしないし。
891:名無しさん＠編集中
18/04/14 17:23:42.86 6VCNeJPr0.net
そうなんだすごいね！
としか言えない
892:名無しさん＠編集中
18/04/14 17:26:53.88 PaVPSmYH0.net
ブロックサイズの最適化がブロックノイズにって…
やはりプラシーボ効果はすごいね。
893:名無しさん＠編集中
18/04/14 17:33:14.81 qZj3121hM.net
まるで話にならない
とんだ茶番だ
894:名無しさん＠編集中
18/04/14 18:46:41.41 zRFq/N790.net
いやいや、おまえらが勝手に盛りあがっただけだじゃん
895:名無しさん＠編集中
18/04/14 19:44:12.53 yQp2n2100.net
ワッチョイ変わってるんだが、>>890（**76-）と>>886（**1f-）は同一人物なのか・・・？
896:名無しさん＠編集中
18/04/14 19:46:09.70 GApf2DWFM.net
>>885
「H.265並みに綺麗だよ」とは書いていない
お互いの行間の読み違いはあったのかもしれないが
粗さが目立つというのだから、細部表現と解釈して進言しただけだよ
ビットレート不足とか高い量子化係数での圧縮で起きるのはブロックノイズとディテールの喪失だから、粗いという表現にはならないだろうしね
後半のレスの意図は解ったけど、最初の方で
> 仕様見て書いてあるのと同義
としているから、仕様的なもの把握してレス付けているにはおかしいと思ってのレスなのよ
897:名無しさん＠編集中
18/04/14 19:49:45.86 6VCNeJPr0.net
>>895
UA同じだしキャリア回線と自宅回線の違いだろ
898:名無しさん＠編集中
18/04/15 12:18:04.37 j6EEyX/E0.net
>>855
もしQSVならエンコード部分が止まってる QSVへこれ圧縮してねと投げたのに応答がないから通信エラー
うちのおま環ではSandybridge(P67＆H77のマザー)とHaswell(Z97マザー)のころ頻発してQSVは使い物にならなかった
QSV使うソフトでもれなく止まるんで
いろんなVerのグラフィックドライバ試したりマザーのメモリタイミング緩めてみたりしたけどエラーはなくならず
すっかり諦めてNVEncだけ使ってた
この前KabyLake＋Z170マザーに入れ替えた(DDR3メモリ流用)ときにふと思い出してQSV試したらスイスイ動く クリーンインスコはしてない
使ってない間にWindows10の大型アップデートがあったりドライバが新しくなったからか
Kaby+新マザーにしたからかは今となってはわからん
899:名無しさん＠編集中
18/04/15 21:18:56.26 eLaaw28E0.net
結局お互い何がしたいんだ？相手の間違いの説得か？それ自分にとって意味あるのか？無駄じゃん
900:名無しさん＠編集中
18/04/16 23:24:21.68 GppZnShyd.net
ねえ、みんなはPGMX使ってる？
スマホでもメニュー付きの動画再生できるのは結構魅力あると思うんだけどな。
もうオリジナルのメニュー作成とかまでこだわる人が減ってるのかな。
901:名無しさん＠編集中
18/04/17 05:56:45.15 ctiwZ4jS0.net
そもそもPCなんかで再生しない
再生するにしてもmadVR通せないものは使わない
902:名無しさん＠編集中
18/04/17 07:36:06.22 G8gaxn+mM.net
PGMXのプレイヤーがMX Player Pro並みに使いやすければな
視聴環境の快適性を決めるのはプレイヤーなんだし
PGMXが高機能でも、その専用プレイヤーが糞なら意味が無い
mkv出力の場合は再生トラックが1つに制限されてメニューも使えないから潰しも効かない
903:名無しさん＠編集中
18/04/18 19:53:18.17 2CTL27y90.net
フル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にエンコードできないという情報を目にしたのですが、事実でしょうか？
904:名無しさん＠編集中
18/04/18 20:07:38.88 lvLDYbodd.net
そもそも速度的にNVEnc>VCEだから264と265なら圧倒的にNVEncじゃないの？と思ったけどGT730か。
905:名無しさん＠編集中
18/04/18 20:31:33.53 HTI1sHZw0.net
>>903
(1) 知らん。
(2) 基本的に同じビットレートならAMDのHWエンコードが一番画質が悪い。
H.264/AVCを使おうがH.265/HEVCを使おうが関係なく悪い。
ｽﾚﾘﾝｸ(avi板:335番)
(3) 質問する時は情報源くらいはちゃんと示した方がいいんじゃないの。
とりあえず以下の記事を見てみればいいと思うが。
やはりRavenRidgeのVCEは仕様変更か TMPGを試す
URLﾘﾝｸ(blog.goo.ne.jp)
906:名無しさん＠編集中
18/04/18 20:36:45.00 JUcogrVTM.net
2000シリーズのAPUでH264だとエラー出るのはバージョンアップで直ってる
H264でKepler世代のGT730相手なら2200Gの方が1割ぐらい速いんじゃ無いかな
907:名無しさん＠編集中
18/04/18 21:00:31.04 7SeINJZF0.net
VEGAのHWエンコードは綺麗という噂はガセだったのか。
買わなくてよかった。
908:名無しさん＠編集中
18/04/18 21:16:41.88 2CTL27y90.net
>>904 ありがとうございます、参考にします
>>905 情報源に関して申し訳ございません、AMD VCEの画質は悪いんですね…
>>906 速さをとるか画質をとるか悩みますね、ありがとうございます
909:名無しさん＠編集中
18/04/18 21:20:35.22 BBCsCn2U0.net
URLﾘﾝｸ(i.redd.it)
910:名無しさん＠編集中
18/04/18 21:48:53.47 JUcogrVTM.net
>>908
HEVCで画質確保とかね
流石にHEVC使われると、H264では画質容量比で勝てない（QSV相手だと微妙
911:名無しさん＠編集中
18/04/18 21:50:33.12 sej781kfa.net
NVIDIAにしろAMDにしろ、ベンチマークみたいな小学生でもわかるようなものにはキチガイみたいに争うが、
画質のような主観が影響してくるようなもの（=数字のみがすべてではないもの）になると、いつまで経ってもおぼつかない
912:名無しさん＠編集中
18/04/18 22:02:30.66 HTI1sHZw0.net
>>910
>>905で示したのはSSIMでの評価だから、主観評価ではまた変わるかもしれないけど、
少なくともSSIMでの評価では、AMDはHEVCを使っても他社のH.264にすら及ばないんだよねえ・・・。
というかQSVもNVEncもHEVCの調整がまだまだ未熟な感じで、>>905の評価から見ると
H.264を使った方が良い結果が出るというケースも多いのではないかという気がする。
913:名無しさん＠編集中
18/04/19 02:19:00.51 Tq19pKtn0.net
NVENCのH.265は凄く綺麗だけどなあ
Bフレが無いから縮まないとか言うが、例えば固定品質35程度まで落として縮めてもそれほど汚くならない
914:名無しさん＠編集中
18/04/19 09:05:10.32 eLewtFFkM.net
何でもx264やx265基準の画質で評価する人は何処にも出てくるしね（気持ちもわかるが
エンコーダなんだから画質に重きを置くのは解るけど
CPU負荷が少なくて、エンコード実行している環境で他の処理を行う余裕も確保出来るというHWエンコーダの特性も評価しなけりゃな
ソフトウェアエンコーダでHWエンコーダ並みの発熱やCPU使用量に抑えたら、処理速度なんて更に落ちてしまうんだし
ソフトウェアエンコーダの最大の弱点とも言える処理速度面がHWエンコーダの最大の利点なのに、それ度外視して評価されてしまうのもね
915:名無しさん＠編集中
18/04/19 09:19:03.27 eLewtFFkM.net
画質の容認範囲は人それぞれではあるけど
個人的には概ね1440x1080ならH264で4Mbps～5Mbpsあたり有ればHWエンコーダでも十分満足がいく画質は得られると思うんだけどね
これが3MbpsとかならQSVのHEVCでもギリギリなあたりで
3Mbps以下とか2Mbpsオーダーならx264やx265の出番だろうけど
ここらへん画質面でHWエンコーダを一概に切り捨て判断するに至るかは、処理時間の他にも保存容量へのコスト容認範囲の差がデカいんだろうなと思う
916:名無しさん＠編集中
18/04/19 09:31:07.74 eLewtFFkM.net
HWエンコーダ使用での環境構築とか、話題が出たので
個人的な主観的なもので済まないが、GPU内蔵HWエンコーダの特徴とか
QSV
HWエンコーダとしては画質に定評あり、エンコードでのオプションが豊富だがGPGPU依存度が高く、動作クロックはもちろんグレードによるEU搭載規模や搭載メモリクロックなど、多くの要素で性能に差が出やすい
EUの補助を切るとNVEnc以下の画質になってしまうがNVEncばりの低延滞にも対応可能であったりと機能性が高い
省電力モデルの場合QSVの負荷だけでは、コアのクロックが上がり切らない場合があり、本来の性能が出せない場合もあるので注意が必要
画質傾向は全体的に少しボケ気味（画質容量比が良い一因？
同時実行数に上限は無い様だが、HWデコーダはGTのグレードで差が有るかも（Core i系6、atom系3～4、不足はSDKのソフトウェア処理で補填の模様
917:名無しさん＠編集中
18/04/19 09:31:52.16 eLewtFFkM.net
NVEnc
HWエンコーダのスピードキング、低延滞至上主義
画質はVCE/VCN以上QSV未満、HEVCにはBフレームが無い仕様
GPGPU依存度が無くグレードによる性能差は基本的に無い（動作クロック依存）が、製品グループによって同時実行数の違いや、
上位グレードはエンジン搭載数に違いがあり、同時処理を行っても処理速度低下を起こしづらいものもある
画質傾向は暗部階調表現が弱く、細部がザワついた感じになるが、QSVより全体のボケ感が無い
同時実行数は一般的には2つ（TVMW9では2決め打ち？）TeslaやQuadro 2000番以上は無制限、デコーダは制限があるか不明
VCE/VCN
速度がQSV並で画質がNVEnc以下という、もうちょっと頑張れな
GPGPU依存度もQSV並みだが使用範囲を制限しているのかグレードによる性能差は無い（動作クロック依存）、こいつもHEVCにBフレーム無し
VCN世代でHEVCの画質が微妙に良くなっているという噂がある（公式資料かは不明
FluidMotionが主役でコッチがオマケという話も…
画質傾向はQSVとNVEncの中間的でバランスが良く悪くは無い
同時実行数には制限が無さそう、デコーダも制限不明
918:名無しさん＠編集中
18/04/19 09:47:19.57 eLewtFFkM.net
以上
長々スレ汚しすまんね
HWエンコーダが使える環境は少なくは無いだろうから
TVMWで使わないにしろ、録画したTSとか嵩張るデータを画質に影響が殆ど出ないと自分が思える範囲で、
まずは1/2なりにでも縮ませておくとかには十分使い物にはなるし
個人的には巧く活用していきたいところ
Googleに上げて処理させる場合も、高いビットレートで10GB以下に収める用途とかには手早く処理を済ませてアップロードにすぐ移行出来るし、活用範囲は意外とある
919:名無しさん＠編集中
18/04/19 09:49:32.28 eLewtFFkM.net
>>917
TVMW9てなんぞｗ 6の間違い…
920:名無しさん＠編集中
18/04/19 10:01:33.05 RdF3i7pKa.net
長文連投ガイジ
921:名無しさん＠編集中
18/04/19 10:15:52.90 eLewtFFkM.net
サーセンｗ
922:名無しさん＠編集中
18/04/19 10:17:14.93 eIam/zYw0.net
長文が読めないやつは、ただのコミュ障だからほっとけ
923:名無しさん＠編集中
18/04/19 11:28:39.51 DaOv9Dyp0.net
ID:eLewtFFkMの個人的な感想だろ
オナニー駄文見せられてもなぁ
924:名無しさん＠編集中
18/04/19 11:40:42.03 kh5TqII70.net
個人の感想でも的外れな内容じゃないなら参考になるだろ
参考にできないぐらい酷い内容なら叩くのもわかるが
925:名無しさん＠編集中
18/04/19 12:04:05.50 +JVJ+M9/M.net
いやーキモいっす
NG登録したいからコテ付けてくれ
926:名無しさん＠編集中
18/04/19 12:44:49.09 fhOUU6jdd.net
長文でも参考になるからいいと思うけど
927:名無しさん＠編集中
18/04/19 13:11:30.21 /y1uKNMH0.net
まあちょっと長いかなとは思うが、結構参考になるし、
ガイジだのオナニーだのコテつけろだの言ってるだけの連中よりマシなのは間違いない。
>>917
>VCE/VCN
> ～こいつもHEVCにBフレーム無し
PolarisではH.264でもBフレーム使えなくなったけどね。RavenRidgeはどうなんだろ。
Video Encode API: BFrames not supported on RX 4xx? ・ Issue #8 ・ GPUOpen-LibrariesAndSDKs/AMF
URLﾘﾝｸ(github.com)
928:名無しさん＠編集中
18/04/19 13:21:38.13 DJb3fFUtM.net
まぁBフレームへの対応って、もちろんしているに越したことはないけれど、一部のアニヲタがやっているみたいに
ギリギリまで容量を節約したいとかではなく、ほどほどの容量でよいという用途ならば、
Bフレームへの対応そのものは、必須というわけではないしねぇ
Bフレーム対応の実装が中途半端だと、画面全体がざわついた感じになることもあるし
929:名無しさん＠編集中
18/04/19 13:25:30.00 /y1uKNMH0.net
うん。Bフレームが使えるか使えないかって話であって、圧縮率や画質的にどうなったのかはまた別問題だね。
930:名無しさん＠編集中
18/04/19 15:08:26.65 6x7FDW6O0.net
画質最優先でエンコードするのであれば、本来的には動きの多いシーンでの再現性が低下する要因になる
Bフレームは使わずに、通常設定を駆使して使用するコーデックの基礎的な圧縮メソッドを徹底活用する方が
いいのは間違いないからねぇ
ただし、H.264でBフレームなしを単純にBaseline Profileと理解するのは早計だが
H.264は規格策定の途中でHigh Profile(AVCHD)とかの考えが出てきて、積み増し積み増しの状態になって
いるから、利用する側にとってもどれを使うべきなのかがわかりにくくなっているように感じるね
そういう意味ではオプションに頼らずとも基礎の部分がしっかりしているH.265(HEVC)にて、
Bフレームなしのビットレート余裕あり状態が案外使いやすいと言えなくもないか
（プロファイルの選択は事実上、10bit使うかどうかだけの判断でいいわけなので）
931:名無しさん＠編集中
18/04/19 15:23:52.42 q59zVScr0.net
変な改行やめて
932:名無しさん＠編集中
18/04/20 02:47:27.85 3IIJGeeBM.net
PascalのNVEncで良いところは、H264→HEVCでパフォーマンスが半分も落ちないところ
TVMW6で単発処理だと最高速まで回しきれないので、2つ同時処置で使い切る感じになるけど、それでもQSVのH264の単発と同等ぐらいの速度は出せるので
再生環境的にHEVCでも構わない人には良いと思う
933:名無しさん＠編集中
18/04/20 02:59:41.72 3IIJGeeBM.net
そこから2/3程度の速度になっても良いなら、QSVのLA-ICQでNVEncのHEVCとほぼ同等画質なH264のファイルが作れる
更にそこから1/4（実質等倍速＋α程度）に遅くなっても良いなら、HWエンコーダでの最高画質とも言えるQSVのHEVCという感じ
ここから先は、x264やx265の領域
934:名無しさん＠編集中
18/04/20 03:49:12.94 3IIJGeeBM.net
じゃぁ、QSVのHEVC画質はx264相当でどれぐらい画質か？ というと
QSVがcrf=20なら、x264ならcrf=22程度
crfが小さいほど差が縮まる傾向だが、よく使われると思うcrf 20～22前後あたりだと、x264換算で概ねcrfを+2出来る
もちろんcrfが高い方がファイルサイズも縮むうえx264だからQSVのcrfを+2するより尚更縮む
そのうえ、困った事に有る程度のCPUクロックが必要にはなるが、消費電力を度外視すれば現行のCore iやRyzenの4コアならx264のfasterやveryfastプリセットであたりでCQPを回せば、QSVのHEVC並みか少し速い程度の速度で処理出来てしまい
クロックが更に高かったりコア数が多いほど、x264の方が早くて綺麗となり兼ねなかったりする
なので、2コア世代のi3やPenriumより上位の4コア以上な環境の人なら、消費電力を気にしなければ時間効率的にHWエンコーダを使うなら、QSVのLA ICQやNVENcのHEVCまでに留めて、それ以上の画質や圧縮効率が必要ならx264にスイッチした方がいい
935:名無しさん＠編集中
18/04/20 05:21:10.22 p/Cih/QP0.net
だからコテつけろよ
936:名無しさん＠編集中
18/04/20 10:49:56.99 CjKWf1iLd.net
その為のワッチョイだろう
937:名無しさん＠編集中
18/04/20 11:51:50.39 X6aN0xI4M.net
x265を使って18コア36スレッドのCPUでBフレームなしの場合のエンコード時間と、QSVでBフレームなしのエンコードだと、何倍くらいの時間差になるのだろ？
938:名無しさん＠編集中
18/04/20 12:09:04.44 C3gtM1HZM.net
18コアCPUにiGPUつきのものなんてあるの？
939:名無しさん＠編集中
18/04/20 12:28:55.66 X6aN0xI4M.net
ない
QSVについては別のiGPU搭載CPUで1番速いもので測定することになる
940:名無しさん＠編集中
18/04/20 12:30:52.69 C3gtM1HZM.net
それなんの比較になるの？
941:名無しさん＠編集中
18/04/20 12:36:05.94 X6aN0xI4M.net
エンコード時間の比較と書いたわけだが
942:名無しさん＠編集中
18/04/20 12:36:44.70 C3gtM1HZM.net
じゃあどんな意味があるの？
943:名無しさん＠編集中
18/04/20 12:38:24.51 X6aN0xI4M.net
頭悪い子かい？
944:名無しさん＠編集中
18/04/20 12:39:59.53 C3gtM1HZM.net
頭悪い比較してるくせになにいってんだこいつ
945:名無しさん＠編集中
18/04/20 12:42:14.10 X6aN0xI4M.net
やはり頭悪い子だったか
以後レスしなくていいよ
返答しないから
946:名無しさん＠編集中
18/04/20 12:43:50.94 C3gtM1HZM.net
( ´,_ゝ｀)ﾌﾟｯ
947:名無しさん＠編集中
18/04/20 12:44:38.39 CjKWf1iLd.net
18コアじゃ複数同時エンコしないとCPU使い切らないから、QSVの方が圧倒的に速い
948:名無しさん＠編集中
18/04/20 12:55:14.33 X6aN0xI4M.net
>>947
速いのはわかってる
問題は時間差で何倍程度の差があるのだろうかということ
CPU最速とiGPU最速比較で、例えば3倍程度しか変わりませんならば、消費電力の問題と初期投資費用を無視してもよいならx265のみに絞る選択肢もないわけではない
949:名無しさん＠編集中
18/04/20 13:52:41.89 PbP8t3sj0.net
圧縮率にも触れてないし、そんなに色々無視できるならx265にしとけばいいだろって思うし、
最速環境持ってる人限定の選択肢を持ってない奴が考えてどうするんだろうって思う。
950:名無しさん＠編集中
18/04/20 14:42:30.72 36ZYDVpB0.net
設定次第で結果なんていくらでも変わるからそれに答えられるやつはいないだろう
自分で試せとしか言いようがないんだわ
951:名無しさん＠編集中
18/04/20 17:20:42.74 C3gtM1HZM.net
ID:X6aN0xI4Mの頭の出来じゃそんな環境用意できるわけがない
952:名無しさん＠編集中
18/04/20 17:52:23.70 36ZYDVpB0.net
別の考え方としては、たまにしかエンコしないなら低スペックでも十分と言える
大量にエンコするなら予算の許す限りハイスペックにしたほうがいい
時間がどうのこうのなんて気にするのは最初だけですぐにどうでも良くなるよ
編集してエンコ設定してバッチ登録して放置する事になるのは変わらないわけだしさ
953:名無しさん＠編集中
18/04/20 19:12:27.24 weEZMhQn0.net
帰宅してバッチエンコが終わっていなかったときの悲しさと来たらもうw
954:名無しさん＠編集中
18/04/20 22:39:04.86 eQU7vdAF0.net
大量にエンコする人は電気代やパーツの寿命も念頭に置く
速いほうが電気代↓とパーツ寿命↑に繋がる
955:名無しさん＠編集中
18/04/20 22:44:45.66 Kq0vytARd.net
ターゲットにするビットレートとかファイルサイズも人それぞれだけどね
地デジソースで1440x1080のまま3Mbps未満とかが要求キツければ、自ずとHWエンコは対象じゃ無くなってしまうだろうし
956:名無しさん＠編集中
18/04/22 01:46:41.64 ez3peqCL0.net
これ多重音声ってどうやったら作れるの？副音声入れたい時
957:名無しさん＠編集中
18/04/22 05:23:30.59 XxahlrqW0.net
>>956
多重音声ストリームのことなら
映像＋音声で普通にエンコードしてmp4を作る
クリップ情報→音声のプルダウンメニューで音声ストリームを変更して、映像なしのmp4を作る
高度なツール→MPEGツールの多重化で、上で作った二本を合成
958:名無しさん＠編集中
18/04/22 07:24:34.12 Ahkelk580.net
いつまでそれをやらせるんだよ…
最早普通にあるものなんだから高度でもないだろうに…
959:名無しさん＠編集中
18/04/22 07:28:40.96 czt06LDv0.net
muxerは別のもの使った方がはやい
960:名無しさん＠編集中
18/04/22 22:49:03.89 n6ATBf5jM.net
Ryzen2のx264頑張ってるな
URLﾘﾝｸ(i.imgur.com)
961:名無しさん＠編集中
18/04/22 22:55:43.71 r4L5tvJp0.net
元記事を貼らずにimgurで画像だけ貼るのはちょっと。
【レビュー】クロック向上で注目される第2世代Ryzenをベンチマーク - PC Watch
URLﾘﾝｸ(pc.watch.impress.co.jp)
962:名無しさん＠編集中
18/04/22 23:15:26.71 n6ATBf5jM.net
エンコさえ良ければいいやん
963:名無しさん＠編集中
18/04/23 05:48:23.77 1g7bJt1N0.net
相変わらずAVX2はダメそうだな
964:名無しさん＠編集中
18/04/23 08:12:04.12 Yo1Q+IiIa.net
このソフトで2700x使って撮ったTSを265エンコすると全コア40％くらいしか使ってくれないから余り速くないな
965:名無しさん＠編集中
18/04/23 12:53:16.66 sukaORLRM.net
たった40%でIntelに肉薄と考えるべきだな
966:名無しさん＠編集中
18/04/23 13:23:10.13 dJZNq6MOM.net
メルトダウンのインテルなんて誰も買わんよ
967:名無しさん＠編集中
18/04/23 14:24:16.12 Nzvt+5c+d.net
>>964
それエンコ設定の問題では
968:名無しさん＠編集中
18/04/23 14:50:56.22 8DV5yJuva.net
>>967
265だと色々設定弄っても改善しなかった
264だと全コアフルに使ってくれるんだけどね
969:名無しさん＠編集中
18/04/23 14:57:04.56 VTe/QlaNd.net
>>968
その色々てのが問題なんよ
264でも「100パー使ってくれない」って人は大勢いて、俺も昔エンコ設定によってはそうなる事は確認した
だから頑張って
970:名無しさん＠編集中
18/04/23 16:48:55.13 pr2sR9Wz0.net
頑張ってってそのエンコ設定が良けりゃどうしようもない
971:名無しさん＠編集中
18/04/23 17:17:55.63 nFnbf/Dzd.net
それは>>968の問題だしな
諦めるのもまた良しだが原因を勘違いしてはいけないって話よ
972:名無しさん＠編集中
18/04/23 17:38:49.11 KZIEJTel0.net
わいもエンコ速くしたくてRyzen機に買い替えたのにあんま速くなんない
3本同時エンコで１００％行くからいいんだけど、なんか解せない
973:名無しさん＠編集中
18/04/23 17:46:25.63 1g7bJt1N0.net
--threads上げてみたら？
974:名無しさん＠編集中
18/04/23 18:49:01.78 3GKMwNYaa.net
>>971
そもそもこのアプリの265使って全コアフル近くまで使い切ってくれる設定ってあるの？
あるなら色々と検証してみるけども
975:名無しさん＠編集中
18/04/23 19:17:32.09 6xUxGokX0.net
お帰りください
976:名無しさん＠編集中
18/04/24 10:14:25.14 6FOcUX6F0.net
アプデきてるね
977:名無しさん＠編集中
18/04/24 15:58:24.37 iOoSFxYT0.net
きてないが
978:名無しさん＠編集中
18/04/24 19:26:23.37 MoWY7Ec80.net
きてるが
979:名無しさん＠編集中
18/04/24 19:53:46.78 .net
更新履歴
URLﾘﾝｸ(tmpgenc.pegasys-inc.com)
2018.4.24 / Ver.6.2.8.35
不具合修正
・120％以上のDPI環境で、一部の画面表示、レイアウトがおかしくなる問題を修正しました。
・タイムラインモードで、[レイヤー内の全クリップを前につめる] オプション を使用すると、隙間が発生する場合がある問題を修正しました。
・AMD Ryzen 2000 シリーズのCPU環境で、AMD Media SDK H.264 エンコーダーを使用すると、出力設定に依存して、フレームレートが正しく出力されない場合がある問題を修正しました。
その他
・その他、細かい修正を行ないました。
980:名無しさん＠編集中
18/04/24 19:58:12.76 /PIEYl5+0.net
ｷﾀｰ!
981:名無しさん＠編集中
18/04/24 20:13:09.81 ID34y6L40.net
スレでアプデ来たって書き込み見てから、うちのTVMW6起動してみても更新のお知らせがポップが表示されない
でもサイトで確認するとちゃんと来てる
更新しないままでいると、お知らせポップが出るのは書き込みから2～3日後ってことが多い
って人、他にも居るのでしょうか？
982:名無しさん＠編集中
18/04/24 20:14:46.70 mD4Calbq0.net
いますん
983:名無しさん＠編集中
18/04/24 20:35:44.24 ID34y6L40.net
URLﾘﾝｸ(i.imgur.com)
アプデしてから確認してもやっぱりアップデート情報が来てなかった
更新ボタン押しても、本日の新着情報はありませんって出る
976みたいに早く気がつく人って、サイトで確認してるの？
984:名無しさん＠編集中
18/04/24 21:06:20.04 iOoSFxYT0.net
>>977の辞典ではペガシスのトップから入ってお知らせにもダウンロードにもまだなかったんだが
一体どこから確認したのか
985:名無しさん＠編集中
18/04/24 21:18:40.53 2iSJFINm0.net
地雷
986:名無しさん＠編集中
18/04/25 00:00:47.25 HvyKHG7j0.net
メール登録からとか？
987:名無しさん＠編集中
18/04/25 00:19:27.88 Okg1B/KY0.net
プレビュー頻度によってCPU使用率とエンコ時間に差が出るんだ
知らなかった・・
988:名無しさん＠編集中
18/04/25 00:47:50.42 mv1ogCLf0.net
だって、ながら観してる訳だし…
989:名無しさん＠編集中
18/04/25 03:57:37.18 M1WETpBc0.net
>>983
Pegasys-Infoに来ないのは単純に配信忘れじゃね？
たまにエンコ作業でしか使わないし、現状困っているバグは無い
ぶっちゃけアプデ通知がすぐに来なくてもどうでもいいレベル
990:名無しさん＠編集中
18/06/07 08:39:30.07 UBhmhB/rU
TMPGEnc Video Mastering Works で FFmpeg 使えるようにしてください