X



【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん@編集中 (ワッチョイ 4381-Xflc)
垢版 |
2018/08/08(水) 04:44:09.82ID:NnYmcXUx0
ソフトウェアエンコーダーに画質は劣るものの、エンコード完了までの処理速度が爆速なハードウェアエンコーダーを語りましょう

●Intel
https://software.intel.com/en-us/media-sdk
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

●NVIDIA
https://developer.nvidia.com/nvidia-video-codec-sdk
・エンコード: https://en.wikipedia.org/wiki/Nvidia_NVENC
・デコード: https://en.wikipedia.org/wiki/Nvidia_PureVideo

●AMD
https://github.com/GPUOpen-LibrariesAndSDKs/AMF
・エンコード: https://en.wikipedia.org/wiki/Video_Coding_Engine
・デコード: https://en.wikipedia.org/wiki/Unified_Video_Decoder
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured
0174名無しさん@編集中 (ワッチョイ f1e9-Y82R)
垢版 |
2018/09/21(金) 01:41:09.43ID:5ndzxww90
資料としてマクロブロックと明言しているものは確かに見当たらないね
ただ、H.264で15%、HEVCで25%もの改善を得るとの文面から考えると、H.264から強化された動き保障精度向上のための
マクロブロック(HEVCではCUとか言うのだったか?)の探索範囲の強化がキモであるわけだから、実質的にマクロブロック
関連の処理の改善がされているだろうことは容易に想像できる
もちろん、Bフレーム関連とかも手は入っているとは思われるが
0178名無しさん@編集中 (ワッチョイ 2dec-coYL)
垢版 |
2018/09/21(金) 15:26:42.06ID:lKRfOAqF0
>>177
>>75>>78のQSV H.264の例で
  A: --brframes 0
  B:--brframes 3 --b-pyramid
を比較すると

  A:3000kbps→B:2100kbps = 30%のビットレート削減 (SSIM=0.988ライン)

  A:36000kbps→B:30000kbps = 17%のビットレート削減 (SSIM=0.92ライン)

になってるけどな。

NVENCのH.264で同様の調査をしてくれる人がいるといいんだが。
0179名無しさん@編集中 (アウアウイー Sa31-jdBG)
垢版 |
2018/09/21(金) 15:46:40.15ID:7HD3xzwNa
>>177
そりゃ0と3を比較したらそうなるよ
NVENCはBフレ自体は既に対応しているのだから、改善したと発表するならば同じBフレ設定条件下でどれだけ変化するのかを比較しないと意味がない
0180名無しさん@編集中 (ワッチョイ 2dec-coYL)
垢版 |
2018/09/21(金) 16:00:58.80ID:lKRfOAqF0
>>179
いや、25%の改善と言ってるのはHEVCでしょ。

NVENCのHEVCは現状Bフレーム未対応なんだから、対応すればビットレート25%削減もできそうだねってことを
QSVのH.264の例を出して書いただけ。

まあHEVCでBフレーム対応するとは限らないし、H.264も改善されてるんだから
Bフレーム以外の改善もあるだろうし、まだなんとも言えんけどね。
0181名無しさん@編集中 (アウアウイー Sa31-jdBG)
垢版 |
2018/09/21(金) 16:31:03.94ID:7HD3xzwNa
>>180
勘違いしていた
NVENCのHEVCは、Bフレに対応していなかったな
対応しているのはQSVのほうだな
とは言え、すでにBフレ対応済のH.264でも15%の改善をし、さらにHEVCでは25%の改善となると、
共通して改善できる部分はマクロブロック関連が1番大きいだろうことは疑いようがない
エンコーダの動作の7割方はマクロブロックがらみなのだから
0183名無しさん@編集中 (アウアウイー Sa31-jdBG)
垢版 |
2018/09/21(金) 16:50:38.73ID:7HD3xzwNa
現物を買った人がマクロブロックの探索モードに、パスカル以前にはなかった新しいモードが搭載されたか確認してくれるのが1番手っ取り早い方法かと
あと、もちろんBフレの対応可否
Bフレについては公式発表が何もなかった時点で期待しにくいけれど…
0185名無しさん@編集中 (ワッチョイWW 69c3-uD9k)
垢版 |
2018/09/23(日) 02:42:30.46ID:j3oG3i0p0
HEVCのブロック捜査処理を最適化すすめて高速化したら、副次的に細部確認すれば解る程度の画質も改善してたという程度だけだったPascalの時もMaxwellから強化されていても捜査モードの追加なんて無かったし

そもそもエンジン側の処理でQSVみたいにGPGPU処理にしていないからモード切り換え意義が無いんだが
モードの有無で確認出来ると思っている理由が知りたい
0186名無しさん@編集中 (ワッチョイ 61ec-coYL)
垢版 |
2018/09/23(日) 03:29:43.62ID:bRzvZQZ60
>>185
その前に>>169

 > 今回もマクロブロック捜査部分が強化入っている
 > 当該処理が重くなる、より高解像度での処理や、ブロックパターンの複雑なHEVCでより効果が大きいそうな
 > 解像度による速度低下の緩和
 > 複雑なマクロブロック配置の最適化で

という話がどこで聞いたものなのか教えてもらえると嬉しいのだが・・・。

探索モード云々は>>183のちょっと先走った想像にすぎないから、情報の無い段階で考えてもしょうがないと思うけど、
こっそりTuringのNVENCコアに追加された(あるいは従来も実装されてたけど使ってなかった)とかで
今後のSDKの更新で新たに利用可能になるという可能性も・・・、うん、まあ無さそうだけど。
0187名無しさん@編集中 (ワッチョイ 5dc3-coYL)
垢版 |
2018/09/23(日) 03:51:56.86ID:HyLnLbY70
>>185
HWなんだから複数のモード実装して無駄に回路規模増やすとはあまり考えられないし、
新しいモードが追加されることをなんらかのルートを通じて知っていたとかかな

https://devtalk.nvidia.com/default/topic/1038493/video-codec-sdk/details-about-nvenc-in-turing-/post/5285387/#5285387

試した人によると、GTX1080とあまり変わらなかったらしい
25%の性能向上は、今後のドライバの更新、あるいは、新しいSDKでソフトウェア側の対応必須って感じかな

>>186
Turingに対応した新しいSDKがまだ出てないから、分からないよ
新しいモードが追加されるにしてもSDK出ないと使えるようにならないし
0188名無しさん@編集中 (ワッチョイ 5dc3-coYL)
垢版 |
2018/09/23(日) 04:01:14.05ID:HyLnLbY70
モードが追加されるにしても、新しいSDK出ないと分からないし、
そのままエンコードしてもBフレームは出力されないし、性能向上もあまりないんじゃ
現物あっても何も分からないね

>>183はなぜ現物があれば分かると思ったのだろうか・・・
0190名無しさん@編集中 (ワッチョイ 7f81-4Hut)
垢版 |
2018/10/14(日) 02:00:33.76ID:kbRq5SJT0
アホな質問だと思うけど誰か答えてくれると嬉しい
動画のカット・字幕など付けて可逆圧縮のAVI出力したものを最終的に
NVEncCのHWエンコで高速にリサイズしたいんだけど、コーデックに対応してない?から現状無理
って認識であってる?他にうまいやり方あるんだろうか。
0191名無しさん@編集中 (ワッチョイ 7f06-4zPR)
垢版 |
2018/10/14(日) 02:48:45.54ID:Lnrlmmek0
リサイズがしたいのか、NVENCでエンコードしたいのか、可逆圧縮にしたいのかって感じですな
読めるように書き出してあればリサイズはできる。NVENCはエンコーダーであってリサイズはAvitulとかそっちの仕事
リサイズして可逆圧縮で保存したいならNVENCは必要ないので、高速のCPUを買う
あとNVECNで吐き出すものは可逆圧縮じゃないきがする
0192名無しさん@編集中 (ワッチョイ 27ec-4Hut)
垢版 |
2018/10/14(日) 03:18:47.39ID:v7cF/vO60
>>191
いや、>>190は可逆圧縮したAVIファイルをNVEncCで読み込んで
--vpp-resizeや--output-resを使ってリサイズ&エンコードしたいってことでしょ。
--losslessにしたいのかどうかは知らんけど。

>>190
その質問をするなら可逆圧縮に使ったコーデック名(必要ならその設定も)をちゃんと書くべきだと思うが・・・。

まあ一応答えるけど、AMVシリーズなら --avi で読み込めばよさそうだし、avs経由で--avs読みするという手もある。
UtVideoならffmpegで対応してるから、上の手法に加えて--avswでも読めると思う。

ただ、どんな編集ソフト使ってるのか知らないけど、そもそも可逆圧縮AVIを挟む意味あるの?
カットも字幕もAviUtlでやって、NVEnc.auoで出力すればいいだけのような・・・。
0193名無しさん@編集中 (ワッチョイ 7f81-4Hut)
垢版 |
2018/10/14(日) 11:28:47.80ID:kbRq5SJT0
>>191
>>192
まず質問に答えてくれてありがとうございます。

まさに>>192が言ってくれている通り、あらかた編集を済ませたものを-vpp-resizeでリサイズ&エンコードできればなと。
使ってるコーデックはUtVideoの420でAviutlを使用しています。

最終的にvppで2kとか4kとかにリサイズしたくnvenccのhwエンコードの速度に惹かれた次第です
AVI出力も含めたトータルの時間で早くなるのかな?と
そんなのAviutlでsharpen-resizeでも使えばと言われそうですが
せっかくnvenccで出来るのであればと思ったのと、単純に新グラボのSDK?とか
技術的な進歩に対応してるんだから良いんじゃないか?と思った次第です。

他に策があるようなので少し勉強して試したいと思います、ありがとうございました。
0194名無しさん@編集中 (ワッチョイ 27ec-4Hut)
垢版 |
2018/10/14(日) 18:24:58.71ID:ZlTDkV240
>>193
>>192で書いたけど、UtVideo出力せずに、拡張NVEnc出力(NVEnc.auo)で
「フィルタ」タブの「リサイズ」を有効にしてエンコードすれば、それでいいのでは。
NVEncCの--vpp-resizeや--output-res指定と同等だし、
わざわざ可逆でサイズが巨大なファイルを中間出力する意味はないと思うよ。

2Kや4Kへのリサイズというのが拡大するということなら、そもそも拡大自体やめた方がいい気はするけど。
0195名無しさん@編集中 (ワッチョイ 7f81-4Hut)
垢版 |
2018/10/14(日) 21:30:04.16ID:kbRq5SJT0
>>194
自分が一番こだわっているのがHWエンコの速度という部分でして、以前のどこかで質問した時に
Aviutlはデコードの部分に時間がかかると聞きました
だったら最終的な仕上げだけnvenccでやれば良いのでは?と考えに至り

何分使用しているPCが何世代も前のi5、グラボがgtx1050tiという貧弱構成でして・・・

2kや4kの拡大の件も苦肉の策といいますか、やってるゲームをyoutubeにアップしているんですが
1080pであげた物と2kや4kで上げてVP9でエンコされた物を目視で比較するとVP9のほうが綺麗だなと
なぜかは知りませんがエフェクトが激しい場面での破綻がより少ないカンジに見えました

同じ素材をx264(ソフト)やnvenc(ハード)でyoutubeにupしても、2kや4kでupしたVP9の動画のほうが綺麗に見える。
これはもうyoutube側の仕様なのかな?という結論に至り(自分の中で)

正直いいますと2kや4kにはあまりこだわっていないんです
動画編集をやってエンコードを調べていくほど「知りたい」
と思った次第であります、丁寧にお返事ありがとうございます。
0196名無しさん@編集中 (ワッチョイ 47c3-4Hut)
垢版 |
2018/10/14(日) 22:00:48.85ID:ur+KzSlL0
>>195
いくらAviutlでNVEnc使うと遅いって言っても、UtVideoで可逆圧縮出力するよりは速いぞ
デコードが遅いと言うより、Aviutlの中をフレームが通るのが遅いってだけ
もう既にAviutl通してるんだったら、直接NVEnc(NVEnc.auo)で出力したほうが良いに決まってる
0198名無しさん@編集中 (ワッチョイ 7f76-fbiU)
垢版 |
2018/10/15(月) 00:17:08.43ID:25ikQSo00
こういうCPUで、ソフトエンコすればいい。
https://i.imgur.com/TrqBnGs.jpg
0203名無しさん@編集中 (ワッチョイ dfec-4Hut)
垢版 |
2018/10/16(火) 17:00:16.15ID:5Qu0m5+G0
>>195
> 1080pであげた物と2kや4kで上げてVP9でエンコされた物を目視で比較するとVP9のほうが綺麗

・1080pと2kって同じものでは?

・どれとどれを比較したのかよくわからん。
  ・1080p投稿→H.264/1080p再エンコ
  ・1080p投稿→VP9/1080p再エンコ
  ・4K拡大投稿→VP9/4K(2160p)再エンコ
  ・4K拡大投稿→VP9/1080p再エンコ

・比較条件もよくわからん。4K拡大投稿して4K再エンコされたものを1080p縮小状態で見たら綺麗だったという話なら、
 そりゃそうなることが多いだろうという感じだが。

>>199
> VP9の方が後発なんだから当たり前

そんなわけない。
ビットレートの違いもあるから、H.264よりVP9の方が汚いことも普通にある。
0204名無しさん@編集中 (ワッチョイ dfec-4Hut)
垢版 |
2018/10/16(火) 17:01:06.97ID:5Qu0m5+G0
>>201
> 先月あたりからyoutubeがhevcに対応してるような

「対応」ってどういう意味?
「HEVCでの投稿」ってことなら結構前から対応してたはずだし、
先月あたりから対応と言えばAV1のテスト配信くらいだと思うし、
配信にHEVCを使うなんて話は出てないと思うけど。
0205名無しさん@編集中 (ワッチョイ df68-Zu1O)
垢版 |
2018/10/16(火) 20:25:50.76ID:/AsRmAMe0
WebMの立場は・・・
0206名無しさん@編集中 (ワッチョイ 7f81-4Hut)
垢版 |
2018/10/17(水) 01:49:06.98ID:p2fT1tI10
>>203
自分が比較したのは1080p,1440p,2160p
VP9で再エンコされるラインが1440p以上っぽい

再エンコがh264なのかVP9かで破綻具合が違った(特にエフェクトの激しい場面)
・1080p投稿→H.264/1080p再エンコと
・2K拡大投稿→VP9/1080p再エンコ

自分の見解としてはyoutubeのh264とVP9はコーデックが違うこともあり
ビットレートの配分具合とかそもそも割り当てられる総ビットレートが
違うんだろうな(あたりまえなんでしょうが)と学んだ次第です
0207名無しさん@編集中 (ワッチョイ 07e0-SmB1)
垢版 |
2018/10/17(水) 02:26:19.20ID:VTrg57yl0
 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。
0208名無しさん@編集中 (ワッチョイ c7ec-4Hut)
垢版 |
2018/10/17(水) 23:36:15.65ID:tsUttaVy0
>>206
> VP9で再エンコされるラインが1440p以上っぽい

ちゃんと検証したわけじゃないが、今のYoutubeは

 ・1080pまでの解像度なら、とりあえずH.264の配信ファイルを作る。
  更に何らかの条件(たぶん再生数やチャンネルの再生実績等)を満たす場合は、
  VP9の配信ファイルも作る。(つまり条件を満たせないとH.264のみとなる)

 ・1080pより上の解像度はVP9でしか配信しないのでVP9の配信ファイルを作る
  (そのため4K投稿すれば、ついでに1080pのVP9も作られる)

という感じになってるようでな。
そこそこ再生数が見込まれる場合は1080p投稿でもVP9ファイルが作られるんだ・・・。

>>203でも書いたけど、動画によってはVP9よりH.264の方が綺麗になることもあるし、
「1080pを確実にVP9で見てもらう」なんて目的で4K拡大投稿するのは無意味だと思うよ。

それに4K投稿した場合、視聴者は4K解像度の綺麗な動画を期待すると思うので、
「1080pの動画を雑に拡大しただけの4K動画」なんて見せたら、失望されるかもしれないし。
0209名無しさん@編集中 (スプッッ Sd2a-M9WL)
垢版 |
2018/10/22(月) 13:52:41.31ID:LE74PYGnd
趣味で撮りためたTVアニメや映画をH264で720*480程度にリサイズしてMediacoderでエンコしてたのですが
ハードが逝ってしまい、数年ぶりに環境再構築してます
CPUも劇的に早くなり、フォーマットやソフトを見直しているのですが下記条件をみたす
おすすめのソフトはなんでしょうか?

画面サイズは720*480程度で十分
H264より新しいフォーマット希望
複数ファイルを連続で処理したい(夜間とか)
実時間以下でエンコード終了したい
できればフリーソフトが良い

アドバイスお願いします
0211名無しさん@編集中 (スプッッ Sd2a-M9WL)
垢版 |
2018/10/22(月) 14:18:57.41ID:LE74PYGnd
>>210
CPUはi5-8400です、オンボードビデオですが
VGAはGT730という骨董品があまってます
付けたら遅くなりそうですはめてません
ram16G、osはssd240Gにwin10home載せて全然あまってます
0216名無しさん@編集中 (ワッチョイWW 1f9f-24Vo)
垢版 |
2018/10/24(水) 00:57:56.65ID:vZuwSmRm0
同じHD630のKabyだけどなんかもっさりしてて
GT730の方が体感はよかった 当然Kelperな730
ゲーム一切やらないけどブラウザ描画や動画再生に支援使われて
2GB版のメモリ1GBくらい食ってる
逆にHD630がQSV専用になってしまってる
0219名無しさん@編集中 (ワッチョイ f306-iIDB)
垢版 |
2018/10/24(水) 08:13:14.82ID:/AKji+A80
速度優先で画質捨ててた、とりあえずHW時代だもんねぇ・・・
NVENCも世代ごとによくなってるってリリースにある通り
詳しくはWikiかなにかにまとめてあったともうぐぐってくだちゃい(-_ゞゴシゴシ
0220名無しさん@編集中 (スプッッ Sdc3-M9WL)
垢版 |
2018/10/24(水) 11:26:08.81ID:Y/cx0/8Md
10年近く前からmediacoderのcuda使ってたんですけど
今の主流のエンコはなんですか?
intelのqsvもすごいって聞きますが
gpuのnvencやvce、cpuパワーでソフトエンコなど皆さんどんな
ハードとソフト使ってるんでしょうか?
0230名無しさん@編集中 (ワッチョイ 6a9f-nBLa)
垢版 |
2018/10/24(水) 18:38:04.53ID:ZQP/1nQ80
>>227
Tiと無印に違いがあるというより、「無印とTiの間に何か関連性がある」という発想自体が間違い
GTX1080と1080Tiのように、Tiが付いたら中身が全く別物になるパターンもある
法則性があるわけではないので、何が違っているのかは自分で一つ一つ把握するしかない
0235名無しさん@編集中 (ワッチョイWW 9fc3-8G0i)
垢版 |
2018/10/25(木) 00:22:09.56ID:STwk5yxX0
RTX2070はTU106だから、GP106のGTX1060と一緒でNVEncのエンジンが1基しかないと思う
Maxwell以降は上位のチップには2基積まれて、エンコ2本同時までは速度が落ちない(ただし3本以上同時エンコできるのはQuadroのミドル以上
0236名無しさん@編集中 (ワッチョイ 5980-7TBo)
垢版 |
2018/10/25(木) 00:35:02.83ID:nkF+Xa5s0
数は1つでいいや
問題は性能で
Bフレーム使えるみたいだけどその他もどれくらい
性能が上がってるのか気になる
気になるけど買えない
2060待ち
0237名無しさん@編集中 (ワッチョイWW 9fc3-8G0i)
垢版 |
2018/10/25(木) 00:35:57.68ID:STwk5yxX0
>>235
106じゃなかった、104だすまん;
処理速度自体の向上は「高解像度で速度低下しづらくなった」ってだけなんで4K以上でエンコしないと殆ど動作クロックなりの速度よ
0239名無しさん@編集中 (ワッチョイ bf81-o90R)
垢版 |
2018/10/25(木) 04:20:47.52ID:WTE0P24Q0
479分 14GBあるAVを容量節約のためにNVENCでH.265の低ビットレートでエンコードしたが速くていいわ(汚い穴が綺麗に見えてしまうので低ビットレートで充分)
0246名無しさん@編集中 (ワッチョイWW 9fc3-8G0i)
垢版 |
2018/10/25(木) 12:36:20.43ID:STwk5yxX0
そもそも、H265の圧縮率向上の根幹はI/Pフレの圧縮率向上が大きいからな
だからNVEncのマクロブロック配置ロジックの強化されてもH264に効果が殆ど無くてH265の方に効果が出てる
元々がGPUのクラウド化で画面転送するためのエンジンを転用・下位モデルにも解放してるものだし
わざわざ面倒な方の性能向上するぐらい低レイテンシ保持が大事という
0247名無しさん@編集中 (スプッッ Sdaf-2TN5)
垢版 |
2018/10/25(木) 13:41:09.39ID:bUPCRSoJd
265のエンコご優れてるのは分かったのですが
動画再生時デコードにパワー要りますよね?
古いpc環境とか人にも見せたいとか、モバイルでも見たいなら
264の方がまだ使い勝手が良いですか?
0249名無しさん@編集中 (ワッチョイ f7ec-7TBo)
垢版 |
2018/10/25(木) 17:26:52.29ID:rQ/d4Tyo0
>>244
ありがと。それはどの機種での数値だろ?
できれば結果全体をpaste.binあたりに貼ってもらえると嬉しい。
(調べた人が0って意味じゃないよね?)

>>245
NVEncのH.264ではBフレ対応してるし、低レイテンシ重視の時はBフレ切ればいいだけだと思うけどね。
まあH.265でいまだにBフレ対応してないってのは何か理由があるんだろうけども。

>>247
原理的にはH.264よりもH.265の方がデコード自体は軽いと聞いた気がする。
ただ、H.264は既にほとんどの環境でHW再生支援が効くのに対して
H.265は少し前の環境だとHW再生支援が無いことも多いので、そのあたりの差はでてくる。
そのへんを気にするならH.264を使った方がいいと思うよ。
0256名無しさん@編集中 (ワッチョイ 8fc3-7TBo)
垢版 |
2018/10/26(金) 20:48:35.08ID:4O36bTgr0
NVEncCのデフォだとBフレーム使ってくれないけど、 -b 5 とか指定すればちゃんと使ってくれた

frame type IDR 59
frame type I 59, total size 6.44 MB
frame type P 871, total size 36.53 MB
frame type B 4297, total size 51.27 MB
0264名無しさん@編集中 (ワッチョイ 45ec-7TBo)
垢版 |
2018/10/27(土) 00:03:15.28ID:ys8cVnL20
Nvidiaのフォーラムで見つけたTuringのNVEnc関連の話題

●Details about NVENC in Turing?
  https://devtalk.nvidia.com/default/topic/1038493/video-codec-sdk/details-about-nvenc-in-turing-/

  ・RTX2080も2080Tiも、NVEncユニットを1つしか積んでないような気がする
   (2本並列エンコするとパフォーマンスが半分になる。GTX1080とかでは2つ積んでたのに。)

  ・デコードは速いけど、エンコードはGTX1070や1080よりかなり遅い

    ※ただ、テスト時のドライバが410.57とか410.66と書かれていて少し古いのが気になる。
      RTX2080に対応したのは411.63かららしいが・・・。

    ※テスト条件等もところどころ曖昧。

●Video Encode and Decode GPU Support Matrix
  https://devtalk.nvidia.com/default/topic/1039145/video-codec-sdk/video-encode-and-decode-gpu-support-matrix/

  Q.新しいSDKのリリースとかサポート一覧表の更新の予定は?
  A.「今の時点では数か月以内としか言えないっす。」
0270名無しさん@編集中 (ワッチョイ 57e8-wZW4)
垢版 |
2018/10/27(土) 01:09:28.23ID:EhqLT3Ob0
>>267
10xxも併売するらしいから無理じゃない?
NVIDIAはNVENCを付加価値にしてるから
実売1万円以下のカードに乗ることは当分無さそう。
AMDに頑張ってほしい、
5千円で買ったx30,x40でNVENCが動くって今では無理だもんな
0271名無しさん@編集中 (ワッチョイWW 9fc3-U+1r)
垢版 |
2018/10/27(土) 01:52:47.92ID:Q9KzXn1A0
Bフレ数は参照距離とかの兼ね合いで品質評価や圧縮効率にも影響するからエンコーダと設定値による
基本的に参照距離より大きくなると圧縮効率が下がるからBフレ増やす意義が下がる
■ このスレッドは過去ログ倉庫に格納されています

ニューススポーツなんでも実況