パスワードを忘れた? アカウント作成
262175 story
テクノロジー

H.264を超える映像圧縮技術HVC/H.265のデモが公開 52

ストーリー by kazekiri
次世代規格 部門より

maia 曰く

ITU-TとISO/IECで次世代映像符号化方式 MPEG HVC(High-performance Video Coding)/ ITU-T H.265(仮称)の策定に向けたプロジェクトが2009年にスタートしているが、そのデモがCEATECの三菱電機ブースで紹介されていたそうだ(GIGAZINEの記事)。MPEG-2の約4倍、MPEG-4 AVC/H.264の約2倍にあたる圧縮性能らしい。スケジュールでは、2012年策定。QVGAから8K×4K(フルHDの16倍)まで対応するというHVC/H.265。今から楽しみである。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • >8K×4K(フルHDの16倍)

    というフレーズから、現在NHK他が開発中のスーパーハイビジョン(SHV または UHDTV)までサポートするということか。
    GIGAZINEの記事にあるように伝送レート24Mbpsなら、今のBSデジタル放送の1チャンネル分で送れるね。
    #データ放送まで含められるかは知らないけれど。

    と、なんとなく思った。

    --
    masamic
    • by Anonymous Coward

      まさに三菱電機とNHK放送研究所の共同研究だそうですね。
      スーパーハイビジョンの研究成果のスピンアウトというところかも。

  • H264の通った道 (スコア:1, すばらしい洞察)

    by Anonymous Coward on 2010年10月09日 16時50分 (#1837673)

    (TVショッピング風に)でも、その分デコード処理は重いんでしょう?
    html5:videoに使うにも、また特許料だなんだでもめるんでしょう?

    # 263,264,265... この数字どういう連番なのか実はわかってない。

  • by SIGLAL (37805) on 2010年10月09日 17時52分 (#1837689)

    BDが出始めのころ…HD-DVDがまだ存命だったころ
    圧縮は魔法の技術じゃないから大容量メディアはやっぱり必要なんだよ!
    って言われてたような気がします。
    (偉い人の発言ではなくてネットからの野次程度だったとは思いますが)

    やっぱりまだ縮むんですねぇ
    素人なのでどこまでいけるのか判りませんが…

    • by Anonymous Coward

      もしこのニュースで
      ・圧縮が魔法の技術だと思った
      ・最終的に必要なメディア容量は0
      だと思ったのなら、脳容量が縮んでる可能性が高いと思われ。

      • Re:まだ縮むの? (スコア:3, おもしろおかしい)

        by barrel (25979) on 2010年10月09日 22時31分 (#1837808)

        て、THComp...

        親コメント
        • by Anonymous Coward

          動画の圧倒的多数は人類にとって無意味なホワイトノイズですし、1bitでも壊れたら動かなくなるプログラムと違って1ピクセルの輝度が1つ変わったところでほとんど問題ありません。
          ですから意味がある動画に片っぱしsNJBT7zkzpsだのsm1234567だのというIDを振っていけばわずか十数バイトに動画を圧縮できる…という話でしょうか。

    • by Anonymous Coward
      プロセッサの能力が向上した結果、
      より高度で複雑なアルゴリズム(特にリアルタイム処理が必要な再生用)
      の採用が現実的になったりします。

      さらに数年すればH.265以上のものが出てきても
      不思議じゃないのではないですかね。
      • 理論的限界は近いだろうにと思ってるのですが、
        2倍も縮んじゃうのなんでだろう?と考えたら、
        その理由はきっと不可逆圧縮だからなんでしょうね。
        可逆圧縮で2倍差が出るとかだったら胡散臭い。
        そのうち圧縮しやすいようなソースを作る技術とか出てきそう。
        漫画太郎先生は圧縮しやすいとか。

        親コメント
      • 確かH.264自体、そのあたりの複雑度と効果のバランスを少々無視しても取り入れていって、ちりも積もれば山となるといった発想で成り立ってませんでしたっけ。

        まあそれはそれとして、元記事の画像見たら画像に合わせてマクロブロックサイズを適切に選択することがH.265の特徴に上がっているけど、H.264でもできたような。
        もしかしてH.264の可変マクロブロックってフレーム単位ないしスライス単位でブロックサイズを統一しなきゃいけない?そんなことはないよね。
        ということはマクロブロックでなくDCT変換するときのブロックサイズということかな。これは計算量増えそうだなあ。
        親コメント
    • by Anonymous Coward
      もちろん魔法じゃないんでそう簡単に性能が良くなるわけじゃないです
      けれども,どんどん解像度が上がった高精細度の画像(縦・横のビットサイズが大きい画像)に関しては,新しい圧縮手法の方がパフォーマンスが良いということです
      おそらくVGAサイズの小さな画像であれば,新・旧の手法の差は微々たるものになるでしょう
    • by Anonymous Coward
      MPEG2で圧縮するには容量が必要だった。Blu-layの容量もMPEG2が基準。そのころH.264はMPEG2より汚なかった。
    • by Anonymous Coward

      某ゲームによるとブラックホールを使えば脳内の記憶を一瞬で数バイトに圧縮して携帯で送れるらしいので
      最終的にすべてのデータは1bitで表せますよ!

  • by Anonymous Coward on 2010年10月09日 18時31分 (#1837703)

    知りたいことと言えば、

    1. Freeで公開してくれる?
    2. エンコードにどのくらいのパワーが必要?
    3. デコードにどこくらいのパワーが必要?

    でしょうか。

    • Re:知りたいこと (スコア:3, 参考になる)

      by Anonymous Coward on 2010年10月09日 19時41分 (#1837736)

      まあ、最終的にどうなるかはわかりませんが、現時点及びこれまでの経緯からの推測としては、

      > Freeで公開してくれる?
      何をもって「Free」と言っているのかはわかりませんが、
      今までのデジュール標準な規格と同じ枠組み(ISO/IECとITU-Tの合同でやってるところも含め)進んでいるようですし、
      規格そのものやリファレンス実装はフリーで公開、
      製品などでの利用に当たってはパテントプールに一定の支払いを要求というように、
      技術情報にはタダでアクセスできるけど、製品利用は特許で縛るってかたちじゃないでしょうか。
      # 正確には規格化そのものとパテントプールの運用は別の話だけどね。

      > エンコードにどのくらいのパワーが必要?
      > デコードにどこくらいのパワーが必要?

      現時点では明確にされてませんが、要件目標として
        アンカー規格(=H.264/AVC)に対して複雑度を3倍~半分の範囲
      としていたかと。

      例によってどの演算器をどの範囲で利用するかなどのプロファイル分けはするでしょうから、
      圧縮率や品質を犠牲にして半分の負荷にするか、負荷を承知でより低レート・高品質に倒すかなど、
      用途に応じて選択するのではないでしょうか。

      どのみち、現行の動画コーデック規格と同様、利用の大半はハードエンジンやDSPなどのアシストを前提として
      製品化されていくでしょうから、そのあたりで困りそうなのはPCなどでソフトでコードするような
      「ニッチな」:-) 用途くらいなので、3倍程度なら負荷としては許容範囲かな。
      # 実際は4k/8kや4:4:4、120fpsなどの高品質かつ3Dなどの多視点な動画が主戦場になりそうなので、
      # コーデックの複雑度が3倍といっても、アプリケーションとして掛かる負荷はそれどころじゃなさそうですが、
      # そのあたりはDSP/GPUの世代進化による高クロック化、大容量化にも期待ってことで。

      親コメント
      • Re:知りたいこと (スコア:2, 参考になる)

        by Anonymous Coward on 2010年10月09日 23時22分 (#1837836)
        展示会場で聞いてみたところ、h.264と比較して
        エンコードが2倍、デコードが1.x倍程度の負荷らしいです。
        これはシミュレーション結果らしいですが、
        傾向は似た感じになるんじゃないかと。
        親コメント
    • by Anonymous Coward

      個人的にはリアルタイムエンコードのタイムラグも気になりますね。
      主な用途から想定して大した問題ではなさそうですけど…。

      地デジとアナログの同時視聴でタイムラグが凄かったので何となく。

      • by Anonymous Coward
        >リアルタイムエンコードのタイムラグ

        >地デジとアナログの同時視聴でタイムラグ
        って何の関係が?
        • by Anonymous Coward
          要するに、ストリームのブロックサイズが大幅に増えるようだと放送・ストリーミング用途には使えないよねって話でしょう。

          ブロックサイズが増えれば、時間的に離れたフレームの内容も圧縮のネタに使えるようになるので圧縮効率が上がるわけですが、圧縮・展開共にバッファサイズを広く取って遅延を発生させる必要が出てきます。
  • でも市販は (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2010年10月09日 19時38分 (#1837733)

    これが普及したところで1枚のBDに入れるアニメの話数は変わりません。

    • Re:でも市販は (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2010年10月10日 1時01分 (#1837868)

      >これが普及したところで1枚のBDに入れるアニメの話数は変わりません。
      ところがアメリカにおいては、いままで2枚組で販売していたモノが1枚で全話収録できるようになる
      有用にして驚異の新技術であるのです!

      親コメント
    • by Anonymous Coward
      地デジの画質も変わりません。
  • by Anonymous Coward on 2010年10月09日 19時18分 (#1837722)
    HVCって言うんだーと思ってWikipediaたっら、英語版ではHEVC(High Efficiency Video Coding)になってますね。日本語の方はHVC(High-performance Video Coding)と。H265.netの人は
    > HVC – High-efficiency Video Coding (Note: not High-performance Video Coding? I prefer the latter)
    って書いてますね。まあまだ決定じゃないってことですかね
    • HVC-001 [1983.jp]は忘れさられたのね。
      その他周辺機器もHVC番号だったと記憶。

      親コメント
    • by Anonymous Coward on 2010年10月09日 22時32分 (#1837809)

      HVCはISO/IEC MPEG側の呼称、ITU-T VCEG側はNGVC(Next Generation VC)とかEPVC(Efficient Performance VC)とか呼んでたかと。
      # 規格化される前なので、ITU-T側でもH.265とは公式には書かず、せいぜいH.26xくらいですよね。

      んでもって、二つの規格団体が(前回のH.264|AVCと同様に)立ち上げた合同作業部会(JCT-VC)での呼称がHEVCってことで。

      規格化後はたぶんISO/IEC、ITU-Tそれぞれの呼称を併記することになるんだろうから、
      最後には「HEVC」ではなく「MPEG4 HVC|H.265」とかになるんじゃないの?
      MPEG側がJCT-VCでの呼称を取り込んだりするかも知れないけど。

      > ついにHなビデオコーデックか

      以前からITU-TのAV・マルチメディア関連の規格は「Hなシリーズ」ですが何か。
      # こう書くと「AV」までがなんだか怪しげだな...

      親コメント
      • by Anonymous Coward
        AVやHを卑猥な単語と受け取るのは日本の文化ですよ。
  • by Anonymous Coward on 2010年10月09日 21時21分 (#1837777)

    (to

    • by Anonymous Coward

      > mpeg-7とやらはどこへ・・・?

      あれは入れ物を(横方向へ)拡張する、という話なので全然違う話題ですね。
      ちなみに消えてなくなりました。

    • by Anonymous Coward
      MP5とかMP7とかMP20プレイヤーならあったような。
  • by Anonymous Coward on 2010年10月10日 3時28分 (#1837892)
    それなりの画質が、より小さいデータ量で得られる、なんてものより、
    より高画質な映像が、既存の方式と同等のデータ量で得られる、
    というものが欲しいんだけど。

    何かを犠牲にすりゃ、そりゃデータ量は減るでしょうよ。
    けど犠牲にして失った部分を取り戻すような方向の進化もしてほしいのね。
    • by Anonymous Coward

      > より高画質な映像が、既存の方式と同等のデータ量で得られる、
      > というものが欲しいんだけど。

      動画コーデックのメインストリームであるMPEG2 Video→MPEG4 AVCはそういう進化*も*していると思うが。
      ニーズに合わせてよりスケーラビリティを持ったりもしてるけど、適切なプロファイルや圧縮率を指定すれば
      同程度のビットレートで以前より高品質な動画を残したりとかも出来るわけで。

      今回話題になってる次世代コーデックも同様な要件を含んでいたはず。

      展示会や報道発表なんかでは、素人にもわかりやすい例として
      「以前と同等の画質をより低レートで」見せることが多いと思いますが。

      ただ、もともと「充分に綺麗な画像」を元の情報量を超えて綺麗にするようなものではないので、
      旧コーデックでも充分にビットレートを新しいコーデックに割り当てても、
      画質的な差はほとんど出ないと思われます。
      # オリジナルの動画よりも高品質を求めるのであれば、超解像とかの別の技術の出番かと。

  • by Anonymous Coward on 2010年10月10日 6時51分 (#1837901)
    タイトルだけ見て、某中華系のmp5、mp6、mp7的な話かと思ってしまったが真面目な話だったのね(汗)
typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

読み込み中...