ITU、H.265 を承認 61
ストーリー by reo
お手並み拝見 部門より
お手並み拝見 部門より
maia 曰く、
1 月 25 日ジュネーブにおいて、ITU (国際電気通信連合) は新ビデオフォーマット H.265 を承認した (TechCrunch の記事、ITU のプレスリリースより) 。
HEVC (High Efficiency Video Coding) とも呼ばれる H.265 は、現行の H.264 の半分のビットレートで同レベルの画質を実現するとされる。H.265 は 4K 対応も話題になるところだろうが、フル HD / HD 配信のネットワーク負荷も従来の半分に出来るわけで、その普及は意外に早いのではないかと思う。
264と265は互換なし (スコア:2)
動画のことはよくわからんがそのへんはどうなの？
Re:264と265は互換なし (スコア:2)
モジュールレベルでエンコード・デコードの互換性は無いです。
アルゴリズムレベルの互換性というか共通部分は多い(はず)ですけども。
H.261～263というのもありますが根本的な考え方は変わっていません。
zipとgzipみたいなもんです。
たとえは妥当？ (スコア:0)
ようわからん。
アーカイバ(zip)と圧縮プログラム(gzip)の違いのことを言っているのか？
zipのデフォルトの圧縮アルゴリズムとgzipのそれはどちらも deflate/infrate で、header や trailer が違う程度のものでしかない。実際、どちらもデータ部分は zlib で読み書きできるはずだ。
ネットワーク負荷が半分ねえ (スコア:2)
商用なら、そのとおりだろうけど、動画投稿サイトだと、ビットレートを維持して高画質化おいしいですって事になりそうな予感。
Googleもなんかやってるようだ (スコア:2)
VP9が出てる
http://news.cnet.com/8301-1023_3-57561111-93/googles-new-vp9-video-tec... [cnet.com]
Chromiumにもう入ってるようなのでWebM.nextはこれでいくんじゃないかな
http://src.chromium.org/viewvc/chrome?view=rev&revision=172738 [chromium.org]
半分のビットレートで同レベルの画質を実現 (スコア: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)
最近はマシンパワーも単純には増加しなくなってるし、マルチスレッドでリニアに高速化が可能、とかでもない限り当分気軽に使える存在にはなりそうにないなぁ。
Re: (スコア:0)
それでもセルビデオみたいな用途には、って思ったけど、やっぱそれ相応にデコードにもパワーは要るんだろうね・・・
Re:半分のビットレートで同レベルの画質を実現 (スコア:3)
もはやCPUぶん回してエンコードするのは厳しそうです。
ハードウェアエンコードとかGPGPUとかって方向で行かないと。
下手すると、他のエンコードのファイルをアップロードして、
トランスコードしてくれるサービスとかも成り立ちそうなレベル。
Re: (スコア:0)
RAWデータが大きすぎて、論外ではないかなあ。
そもそも、フレッツの都道府県単位のPOIの帯域が一か所あたり10Gbpsとか言ってる時点で、35Mbpsのストリームなんか複数のユーザが連続的に流すなんて無理だろう。
Re:半分のビットレートで同レベルの画質を実現 (スコア:2)
まぁ、RAWはさすがに厳しいと思いますので、
トランスコードが前提となると思いますが、
たとえば、YouTubeでH.265ダウンロード出来るようになったりする可能性はありそう。
googleのコンピューティングリソースなら。
Re:半分のビットレートで同レベルの画質を実現 (スコア:2, 参考になる)
量子化の格子を柔軟に分割するのがH.265の特徴ですが、
圧縮アルゴリズム自体はH.264と同じなので、デコードのコストは大差ないと思われます。
ジークジオン！ (スコア:0)
Re: (スコア:0)
電気代考えればエンコしないでts保存でHDD積み上げていった方がいいような・・・
Re: (スコア:0)
エンコードより、むしろデコードにかかる時間とパワーのほうが重要な気がする。
Re: (スコア:0)
そこらへんはグラボ屋に任せておきましょう
Re: (スコア:0)
同じフォーマットなのかは分かりませんが、
2010年のデモではエンコード負荷２倍だったらしい。
http://it.srad.jp/comments.pl?sid=509949&cid=1837836 [srad.jp]
Re:半分のビットレートで同レベルの画質を実現 (スコア:1)
ききかじりなので間違って覚えてるかもしれませんが……
H.265は圧縮する際に映像のエッジをまたがないよう格子を調整、また大きなエリアで圧縮が可能ならそこでは格子を大きくする、格子を正方形に限定せず長方形の格子も可能にするなど、圧縮率を稼ぐために映像を柔軟に解析して圧縮すると覚えています。
そのぶんエンコードの負荷は増大しますが、デコードの負荷はH.264と大差ないとも。
ファイルサイズ半分でも (スコア:0)
両方置いたら1.5倍になるな。
Re: (スコア:0)
4KのRAWのデータ量はフルHDに対して4倍な訳ですがサイズ半分で2倍と合計して、3倍では？とか思ってしまった。
HD動画配信に限った場合、正味の話配信側がHD視聴可能ユーザ数を重視するかHD配信可能システム限界を重視するかでどっちかを取捨選択する気はしますが。
ま、併用でも転送量は落とせるから美味しい。
Re: (スコア:0)
動画投稿サイトとかでは360p以下の画質しかないのにHDにリサイズしてアップロードされている動画も結構あるので、
そのような動画ではHD画質を捨てていくのもいいのかもしれません。
WebMとの関係が楽しみ (スコア:0)
H.264からH.265だと明らかに数字が上がって良くなったように印象付けがあるし
同じようによくなりましたって印象が欲しければWebMもWebM2とかにしたりするのかな？
H.264と違ってH.265は普及前の段階なので
WebM陣営がどうやって戦ってくるのか楽しみです。
Re:WebMとの関係が楽しみ (スコア:2)
WebMとは違うけど、この辺りがH.265対抗規格かな?
開発元はソニー。H.264の高ビットレート対応版って感じ? ビットレート効率よりも高精細性重視っぽいのでスタジオ向けか?
開発元はXiph.org (Mozillaも協賛)。H.265越えを目指して開発中らしい。採用する技術を模索中って感じ? webM陣営が参加するとしたらこれか?
NHK辺りも4K向けのコーデック持ってそうな気もするがどうなんだろう。
Re:WebMとの関係が楽しみ (スコア:1)
NHKはSHV(言わば8K）向けのコーディックを協力各社と共同開発しているはずです。すでにH.265よりも先進的な要素技術をいくつか発表していたような。日本の映像コーディックのパテントプールに参加しているほぼ全ての企業がNHKと協同研究していますが、NHKは自社独自フォーマットとせず個別要素の開発に専念しているようで名前が出てくることは無いでしょう。
Re:WebMとの関係が楽しみ (スコア:1)
264から265なんて、誤差程度って印象付けしかできないと思うよ。
Re: (スコア:0)
それに対応すろころのFirefoxは30から31にバージョンアップする頃でしょうか・・・？
//WebMにも高速リリース周期を導入、目標はH.2**
Re: (スコア:0)
FirefoxのH.264対応って18でしたっけ？19でしたっけ？
265に対応するのは確かにそのぐらいになるのかもなぁ。
Re: (スコア:0)
Firefox20です。
Media Faundationでの対応なのでOSにコーデックをインストールするだけです。
Re: (スコア:0)
802.11aとかbとかgとかnとかacなんて、バグ修正くらいの印象だもんね。（違）
Re: (スコア:0)
WebNにするんじゃないでしょうか。
特許/計算量/遅延量は? (スコア:0)
いやー、じっくり計算すれば圧縮率は上がるんだろうけどさ。
以前も、どこぞの大学でフラクタルだか何だかの応用で、
既存のcodecをすべて蹴散らす!と息巻いてたとこなかったっけ。
で、結局えらいライセンス料掛かるんで敬遠するとかで普及には時間がかかると。
Re: (スコア:0)
特許のライセンス料については、
「標準化された時点で、リーズナブルな価格に抑えられる」
というのが原則なんですけどね。
この原則に挑戦する人や会社はたぶん出てこないでしょ。大丈夫ですよ（たぶん）。
> フラクタル
なつかしい。:-)
90年代後半から下火だったニューラル・ネットも機械学習で復活しつつあるみたいだし（チェスとかでしたっけ？）、
どこでブレークスルーがあるかは判らんですよ。あきらめの悪い人（←褒め言葉）が世の中には一定数いるんですな。
サイズをとるべきか、それともエンコード時間をとるべきか (スコア:0)
この先サイズが小さくなるとして...
H.nnn ではH.264 と比べて
エンコードサイズが 2^-(nnn-264) 倍となるけど、エンコード時間が 100 ^ (nnn - 264) 倍となるのであれば、
そう遠くないうちに、理論上可能だとしても、実装上時間がかかりすぎて実用にならない時が来るのかもね。
Re:サイズをとるべきか、それともエンコード時間をとるべきか (スコア:1)
H.265が提案されたのは３年前？だったと思うので、
その間にインフラが整って理論に追いついた、って感じでしょうね。
Re: (スコア:0)
いずれ十分な時間をかければすべての映像を1bitで表すことが出来るっ！
「市民、圧縮は義務ですが、」 (スコア:4, おもしろおかしい)
「市民、それは非可逆です。zip | zip | zip」
# 画質が落ちすぎて、白一色 or 黒一色の画面しか再生されない気がする！
Re:サイズをとるべきか、それともエンコード時間をとるべきか (スコア:2, おもしろおかしい)
Re: (スコア:0)
Re: (スコア:0)
なに?計算に時間がかかるだと!?
#Intelがアップ始めました
Re: (スコア:0)
もっとも、いくら計算量がひつようでも、Xeon Phiの派生品が家庭向けPCに搭載されるようなことはないだろうけどね。
ゲーム機がH.265に対応するのは、PSでいうとPS5ぐらいになるのだろうなあ。意外と、PS3でSPE全部ぶん回せば、対応できたりするかもしれないけどね。
Re: (スコア:0)
と言ってたら、10年後にはメインストリームのCPUにコプロセッサとして統合されたPhiちゃんの姿が…！
Re: (スコア:0)
やっぱりGPUにはなれないんだ…larrabeeちゃん改めPhiちゃん
静止画用だと・・・・？ (スコア:0)
Re: (スコア:0)
WebPへの対抗も意識しているのでしょうかね。
Re: (スコア:0)
H.265のイントラフレームを使ってるから、デジカメが映像用にH.265のエンコーダチップを搭載するようになれば簡単に対応出来るだろう。
エンコード処理や消費電力が大きいことは、H.264同様、profileで分けりゃ済むし、時間が立てば解決するだろう。
まあ、PCやネット上で普及しなきゃどうしようもないが・・・
超大昔、bdはグラフィックカードの支援がないとダメと言われた……… (スコア:0)
今やハードウェアエンコーダーがCPUに入るご時世………で、同じことがH.265で繰り返されるんじゃないかなぁと。
でも、CESでQUIALCOMMがH.265のデコードデモやってました。なんで、デコードに関しては何とかなりそう。問題はエンコですね。