BBCから新たなビデオコーデック「Dirac」 43
ストーリー by Acanthopanax
from-BBC 部門より
from-BBC 部門より
maia曰く、"internetnews.comの記事(英文)によると、BBCが新たなビデオコーデックのプロトタイプ「Dirac」を開発し、5月11日にC++で書かれたFirst alphaをSourceForgeで公開した(ライセンスはGPL等)。最新のコーデックらしく、Diracはウェーブレット技術を基本としており、QCIF (180x144)からHDTV (1920x1080)までカバーし、MPEG-2の半分のビットレートで済むという。現在、Diracは研究開発の最初の段階であるが、最終的には既存のメジャーなコーデックに匹敵するものとなる事を目指しているようだ。果たして、さざ波に乗ったDiracは、ビデオコーデックの大海を渡る事ができるだろうか。
なお「Dirac」は英国の理論物理学者、Paul Adrien Maurice Dirac (1902－1984)の名から取っている。(参考: ITtmediaの記事)"
BBC Creative Archiveと関係あり？ (スコア:4, 興味深い)
Keep it simple, but not stupid (スコア:3, 参考になる)
Wavelet、MC(動き補償)、算術符号化が
主な符号化ツールのようですね。
勉強不足でGolombというのが何か判りませんが。
Keep it simple.がモットーとのことですが、
いずれにせよ、複雜で重そうなので、
MPEG2代替というより、HDTVコンテンツの
アーカイブ的な用途がターゲットなのかな？
Re:Keep it simple, but not stupid (スコア:2, 参考になる)
-- Takehiro TOMINAGA // may the source be with you!
Re:Keep it simple, but not stupid (スコア:2, 参考になる)
0→1,
1→010, 2→011,
3→00100, 4→00101, 5→00110, 6→00111...
こんな可変長符号方式じゃなかったかな?
Re:Keep it simple, but not stupid (スコア:1)
> Wavelet、MC(動き補償)、算術符号化が
> 主な符号化ツールのようですね。
算術符号化は特許の問題があるかと思いますが(たしかIBMが特許を持っている)
そのあたりはどうなってるのでしょうか?
Re:Keep it simple, but not stupid (スコア:1)
-- Takehiro TOMINAGA // may the source be with you!
Re:Keep it simple, but not stupid (スコア:1, 興味深い)
とりあえずあまり調べてないけど代替技術に
乗り換える必要があるなら乗り換える、
とのこと。
k6-2_500、モバCel_550、Cylix等 愛用中 (スコア:2, 興味深い)
最近のDivXやWMVの場合、VGAサイズですと、再生品質を落としても
Celeron800 Mhz程度の処理能力が無いと快適に再生できません。
圧縮率や画質が上がるのは当然嬉しい事ですが、
再生時の負荷を下げる技術がもっと発達すると
嬉しいな、と思う貧乏人です。
エンコードに関しては、録画と同時に変換でもしないかぎり
等倍速に満たなくても問題は無いのですが。
で、h.264とでは・・・ (スコア:1, 興味深い)
識者の見解求む。
（ついでにITmediaの記事にあるRealNetworksのHelixってのはどんなの？）
Re:で、H.264とでは・・・ (スコア:5, 参考になる)
H.264の圧縮率はMPEG-2の3倍 [nikkeibp.co.jp]だそうですので、H.264には負けますね。
コーデックをGPL公開するということは、特許フリーな技術だけで成立させた、ということなのでしょう。アピールしうるメリットはそれしかないでしょうね。MPEGやHシリーズの特許期限切れが近くなる前に仕様を熟成させ、それを使ってBBCがキラーコンテンツを惜しみなく自由公開するなら、普及の可能性はあると思います。
タダで使えるなら、H.264の2/3の圧縮効率でも充分満足可能でしょう。逆に、BBCが少しでも出し惜しみするようなら、指摘されているように、Helix同様ごくごくマイナーなコーデックで終わるでしょう。
ウェーブレットも算術符号化もすでに既存の動画コーデックに使われており、今のところ目新しい技術は何もなさそうです。
ところでQCIFは176x144なので、タレコミのtypoなのかと思っていましたが、SourceForgeにも180x144って書いてありますね。大丈夫かDirac?!
Re:で、h.264とでは・・・ (スコア:3, 参考になる)
インターネットストリーミング放送をする際の性能は、H.264に少し劣る [theregister.co.uk]そうな。
もっとも、Diracはまだ固まっていないので、もしかしたらH.264を性能的に抜くかもしれません。
ちなみにDiracはwaveletなcodec [kmkz.jp]で、H.264はDCT（離散コサイン変換）なcodecなのだとか。
JPEGはDCT、JPEG2000はWavelet [itmedia.co.jp]とのことです。
Helixについては、
米RealNetworks、オープンソース戦略を採用～ソースコードを一部公開 [impress.co.jp]
IT用語辞典 e-Words : Helix [e-words.jp]
あたりをどうぞ。
アルゴリズムを追求する人達 (スコア:0)
なんか神様のように見えてしまいます
Re:アルゴリズムを追求する人達 (スコア:0)
が、メリットはさほど感じないかなぁ。
1bitあたりの単価が年々下がっている現状では、2倍3倍といった程度では
インパクトが弱い気も。MPEGほど枯れるかも疑問だし。
恐らく既に誰か研究してるんだろうが、拡大縮小に強いとか、
どんな動きでもある一定以上の品質が保てるとか、規格として
変速再生がサポートされてるとか…
ユーザとしては (スコア:0)
そういえば、bluerayのフォーマットって何なんだろう。
Re:ユーザとしては (スコア:3, 参考になる)
DVD-VideoはMPEG-2 PSでしたが、Blu-rayはMPEG-2 TS [www.sony.jp]のようです。
ちなみに対抗規格のHD DVDはMPEG2 TSから、WMVやH.264 [itmedia.co.jp]に対応するそうな。
＃そういえば、カタカナ表記の「ブルーレイ」は「ブル」+「－」＋「レイ」なんですね。＞Blu-ray
Re:ユーザとしては (スコア:1, 参考になる)
Re:ユーザとしては (スコア:1)
フォローありがとうございます～。
メーカー側としては (スコア:1)
どちらが普及するんですかねぇ。
オープンソースでリリースですか (スコア:0)
Re:オープンソースでリリースですか (スコア:2, 参考になる)
＃ パイソンズネタはいいかげんにしろと言われたのでＡＣ
Re:オープンソースでリリースですか (スコア:1)
そんなこと言われたら私の立場なんか…
And now for something completely different...
このネーミングは・・・ (スコア:0)
少なくとも、明言しちゃって良いんですかね・・・ (スコア:1)
文句つけられる前に、BHA（Butt-head Astronomy:頭のカタイ天文学者）に変更しときましょう。
そして、裁判で負けてLAW（Lawyers Are Wimps:弁護士は弱虫だ）に変更しましょう。
あ、今回は物理学者か。
--頭のヨワイMac使用者より
とりあえず、だな‥‥ (スコア:0)
効率もそうですけど、画質のほうは... (スコア:0)
どうなんでしょうか？
折角HDTVをサポートしててもねぇ。
Re:効率もそうですけど、画質のほうは... (スコア:0)
IOかなんかからD1のキャプチャカードがでてるだけで。
帯域の問題と聞いた覚えがあるんですが、どうなんでしょう。
個人的には早くPCIExpressで1080iのキャプチャカードがでないかな、とか思ってるんですが。
できればこのテのコーデックを使ったハード
HDTV対応のキャプチャカード (スコア:1)
http://www.blackmagic-design.com/site/decklinkhd.htm [blackmagic-design.com]
入出力はHD-SDIなので、業務用ですし、対応はMacOSXなので、
Windows系で動かす場合には自分でドライバを書く必要があるかと。
とはいえ、今やってる海外製メーカーのHDのIP転送装置はこいつを
使っているので、メーカーにはあるのかも知れません。
Re:効率もそうですけど、画質のほうは... (スコア:0)
Re:効率もそうですけど、画質のほうは... (スコア:0)
だとすると、無印PCIではいわゆる常時エンコタイプのキャプチャカードしか出せないってことですよね。なんとも微妙すぎる。
試聴だけでCPUパワー持ってかれるのは痛すぎる。ハードウェアエンコード->デコードで生の映像よりは劣化するわけですし。
だとしたら
Re:効率もそうですけど、画質のほうは... (スコア:2, 参考になる)
1920x1080で、秒30コマで、1画素がRGB各8ビットとすると、
1920x1080x30x3=178MB/sですね。普通のPCIじゃ無理です。
64bit 66MHz ですが、放送用規格である HD-SDI による接続であれば、
HDTV 信号をキャプチャーできるカード [focal.co.jp]は存在してます。
もっとも、キャプチャできても、
今度はそれをコンスタントに記録できるハードディスクが必要なわけで、
民生レベルで非圧縮で処理するのは結構厳しいかと思います。
Re:効率もそうですけど、画質のほうは... (スコア:0)
Re:効率もそうですけど、画質のほうは... (スコア:2, 参考になる)
デジタル放送の保存に関しては放送のビットストリームをそのまま保存するのが画質的には最善です。
Re:効率もそうですけど、画質のほうは... (スコア:0)
＃アレなんでAC
Re:効率もそうですけど、画質のほうは... (スコア:0)
だからこそもし技術的に可能でも出すわけにはいかないんじゃないかなぁ。
# もちろん個人的には欲しいけどね。
Dirac故に (スコア:0)
複素数がなんちゃら、iがなんちゃら…
Re:Dirac故に (スコア:1)
(ソース読まずに書いてしまいますが) wavelet 使っているらしいので、Euler の式 [t-kougei.ac.jp]を使えば無理矢理複素数がらみにはできるでしょう。 :-)
# 生の三角関数使わずに exp 使う理由があるとは
# あまり思えませんが。
Re:Dirac故に (スコア:0)
Re:Dirac故に (スコア:1)
# あるいは、非可換の四元数体で、非可逆のフォーマット...あれれ
Re:Dirac故に (スコア:1, おもしろおかしい)
Re:Dirac故に (スコア:0)
んじゃ (スコア:0)
Re:んじゃ (スコア:1)
Kiyotan