アカウント名:
パスワード:
それでもQSVなら・・・QSVならきっと何とかしてくれる・・・
うちのマシンで30分の動画をH.264でエンコードするのに2時間半……10日以上かかるのか…
自宅環境、FullHDをフルエンコした場合、120分の作品なら、140分程度くらいです。H.265になると、1000倍以上速いCPUが必用なのか。泣けてくる。
・Windows8・i7 3930KTMPGEnc Authoring Works 5・x264・1920×1080P・2PassVBR・やや速い（初期値）
#微妙にオフトピックだけど
エンコードベンチを評価するならボトルネックになってるのがエンコーダではなくデコーダだったりするんで注意した方がいい。Xeon を2個のせたマシンでエンコードしているのだが、どうやってもこれ以上エンコードの速度が上がらない事があった。ディスクがボトルネックなのかと思いRAMディスクに入れてみたが上がらない。またよく見るとCPU利用がまだらになっている。そこでペガシスのサポートに聞いたところ、x264やフィルタ処理などのエンコードエンジンの方は十分にスケールするのだが、デコード処理は、型式の制約などもあってデコード処
それは分かる気がする。同じ程度の再生時間の動画でも、ソースのサイズや形式でエンコードにかかる時間が結構違うし、デコーダーにffmpegを使うかQuickTimeを使うかでも違ってくるし。
それでもセルビデオみたいな用途には、って思ったけど、やっぱそれ相応にデコードにもパワーは要るんだろうね・・・
もはやCPUぶん回してエンコードするのは厳しそうです。ハードウェアエンコードとかGPGPUとかって方向で行かないと。下手すると、他のエンコードのファイルをアップロードして、トランスコードしてくれるサービスとかも成り立ちそうなレベル。
RAWデータが大きすぎて、論外ではないかなあ。そもそも、フレッツの都道府県単位のPOIの帯域が一か所あたり10Gbpsとか言ってる時点で、35Mbpsのストリームなんか複数のユーザが連続的に流すなんて無理だろう。
まぁ、RAWはさすがに厳しいと思いますので、トランスコードが前提となると思いますが、たとえば、YouTubeでH.265ダウンロード出来るようになったりする可能性はありそう。googleのコンピューティングリソースなら。
h264とWebMの確執をお忘れで？
量子化の格子を柔軟に分割するのがH.265の特徴ですが、圧縮アルゴリズム自体はH.264と同じなので、デコードのコストは大差ないと思われます。
電気代考えればエンコしないでts保存でHDD積み上げていった方がいいような・・・
エンコードより、むしろデコードにかかる時間とパワーのほうが重要な気がする。
そこらへんはグラボ屋に任せておきましょう
スマホでは動画一本も見終えられない規格とかだと、ダメだろ
同じフォーマットなのかは分かりませんが、2010年のデモではエンコード負荷２倍だったらしい。http://it.srad.jp/comments.pl?sid=509949&cid=1837836 [srad.jp]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
半分のビットレートで同レベルの画質を実現 (スコア:1)
これってどれくらいほんとーなんでしょうか
---
ここで颯爽と THcomp 登場！
Re:半分のビットレートで同レベルの画質を実現 (スコア:4, 興味深い)
でもエンコ時間は100倍近くかかるとか。
Re: (スコア:0)
それでもQSVなら・・・
QSVならきっと何とかしてくれる・・・
Re: (スコア:0)
うちのマシンで30分の動画をH.264でエンコードするのに2時間半……10日以上かかるのか…
Re: (スコア:0)
自宅環境、FullHDをフルエンコした場合、120分の作品なら、140分程度くらいです。
H.265になると、1000倍以上速いCPUが必用なのか。泣けてくる。
・Windows8
・i7 3930K
TMPGEnc Authoring Works 5
・x264
・1920×1080P
・2PassVBR
・やや速い（初期値）
Re: (スコア:0)
#微妙にオフトピックだけど
エンコードベンチを評価するならボトルネックになってるのがエンコーダではなくデコーダだったりするんで注意した方がいい。
Xeon を2個のせたマシンでエンコードしているのだが、どうやってもこれ以上エンコードの速度が上がらない事があった。
ディスクがボトルネックなのかと思いRAMディスクに入れてみたが上がらない。またよく見るとCPU利用がまだらになっている。そこでペガシスのサポートに聞いたところ、x264やフィルタ処理などのエンコードエンジンの方は十分にスケールするのだが、デコード処理は、型式の制約などもあってデコード処
Re: (スコア:0)
それは分かる気がする。
同じ程度の再生時間の動画でも、ソースのサイズや形式でエンコードにかかる時間が結構違うし、
デコーダーにffmpegを使うかQuickTimeを使うかでも違ってくるし。
Re: (スコア:0)
最近はマシンパワーも単純には増加しなくなってるし、マルチスレッドでリニアに高速化が可能、とかでもない限り当分気軽に使える存在にはなりそうにないなぁ。
Re: (スコア:0)
それでもセルビデオみたいな用途には、って思ったけど、やっぱそれ相応にデコードにもパワーは要るんだろうね・・・
Re:半分のビットレートで同レベルの画質を実現 (スコア:3)
もはやCPUぶん回してエンコードするのは厳しそうです。
ハードウェアエンコードとかGPGPUとかって方向で行かないと。
下手すると、他のエンコードのファイルをアップロードして、
トランスコードしてくれるサービスとかも成り立ちそうなレベル。
Re: (スコア:0)
RAWデータが大きすぎて、論外ではないかなあ。
そもそも、フレッツの都道府県単位のPOIの帯域が一か所あたり10Gbpsとか言ってる時点で、35Mbpsのストリームなんか複数のユーザが連続的に流すなんて無理だろう。
Re:半分のビットレートで同レベルの画質を実現 (スコア:2)
まぁ、RAWはさすがに厳しいと思いますので、
トランスコードが前提となると思いますが、
たとえば、YouTubeでH.265ダウンロード出来るようになったりする可能性はありそう。
googleのコンピューティングリソースなら。
Re: (スコア:0)
h264とWebMの確執をお忘れで？
Re:半分のビットレートで同レベルの画質を実現 (スコア:2, 参考になる)
量子化の格子を柔軟に分割するのがH.265の特徴ですが、
圧縮アルゴリズム自体はH.264と同じなので、デコードのコストは大差ないと思われます。
ジークジオン！ (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
電気代考えればエンコしないでts保存でHDD積み上げていった方がいいような・・・
Re: (スコア:0)
エンコードより、むしろデコードにかかる時間とパワーのほうが重要な気がする。
Re: (スコア:0)
そこらへんはグラボ屋に任せておきましょう
Re: (スコア:0)
スマホでは動画一本も見終えられない規格とかだと、ダメだろ
Re: (スコア:0)
同じフォーマットなのかは分かりませんが、
2010年のデモではエンコード負荷２倍だったらしい。
http://it.srad.jp/comments.pl?sid=509949&cid=1837836 [srad.jp]