アカウント名:
パスワード:
6系統のB-CASスロットを装備する [impress.co.jp]
B-CASカードは6枚(地デジ専用の青×5、3波用の赤×1)が付属する。地デジチューナのうち8系統はタイムシフトマシン専用、2系統は通常録画用で、1系統は視聴専用となる。BS/110度CSデジタルは2系統が通常録画用、1系統が視聴専用となる。
B-CASカードは地上波2系統に対して1枚必要なんですね。BS/CSにたいしては3系統で1枚でよいらしい。
PT1を2台とFriioを1台の環境(地上5波・BS/CS4波)に対してB-CASカード1枚で実験してみたが特に問題なく動いたので、契約的な問題さえなければ無駄な実装はいらないんでしょうね。
久々に爽快なまでの無駄ハイスペック製品を見た気がする。「8chも同時録画してどーすんじゃい」とツッコミつつも買うのが漢。
後はアナログTVでよくあった、9分割表示とかですね。タイムラグが3秒あったら、9分割で全チャンネルを表示するには27秒間待たせることになります。アナログ時代は一瞬だったんですけどね。二チャンネル同時表示とか、往年のアナログ並みの機能を実装できるようになりますね。
デジタル動画の圧縮は、数フレーム分の画像を単位として圧縮しているので、圧縮単位の最後の画像が届くまでその前に受け取った画像もデコードできない。つまりどんなに処理速度が速くなっても、これ以上は圧縮アルゴリズムの原理上縮めようがないという限界が存在する。
さらに、最近の機種になると高リフレッシュレート実現のための擬似中間画像の生成やら、超解像やら、3次元ノイズリダクションやらとメモリと時間をいっぱい喰う処理が入っていたりするので、もっと遅くなる場合もあるかもしれない。
デジタル動画の圧縮は、数フレーム分の画像を単位として圧縮しているので、圧縮単位の最後の画像が届くまでその前に受け取った画像もデコードできない。
微妙に間違ってます。
MPEG2では、「前の時刻の画像との差分を取る」という時間方向の圧縮をしていますが、チャンネルを切り替えた時からデータの受信をは始めても、「差分データ」だけを受け取っただけでは元の画像を復元できませんから、およそ0.5秒間隔で「差分を取らない画像」(Iピクチャ)を送っています。受信側では、Iピクチャを受け取ってから、画像表示を始めることになります。
というわけで、圧縮単位(「GOP」と呼ばれる、Iピクチャから始まる単独でデコード可能なデータのひとかたまり)が全部届かなくても、届き始めたらすぐに表示は可能です。「圧縮単位の最後の画像が届くまでその前に受け取った画像もデコードできない」なんてことはありません。
問題は、この「GOP」の先頭が届き始めるまで、デコードを開始できないということにあるわけで、それに関しては、最大で0.5秒間は待ち時間が発生します。ただし、タイミング良くチャンネルを切り替えると同時にGOP先頭が届く、なんてこともあるわけで、平均としては0.25秒の待ちですね。
ただし、MPEG2についてもうちょっと細かく言うと、Iピクチャを受け取ってからすぐに表示できるかというと、もう1ステップあって、MPEG2では時間方向に「双方向の圧縮」を行ってます。届くデータの流れは1コマ目:Iピクチャ。単独でデコード可能な画像4コマ目:Pピクチャ。1コマ目からの差分2コマ目:Bピクチャ。1コマ目と4コマ目からの双方向差分3コマ目:Bピクチャ。1コマ目と4コマ目からの双方向差分7コマ目:Pピクチャ。4コマ目からの差分…という並び順になってます。ここで、1コマ目のIピクチャを受け取ってすぐに表示すると、次に受信するのは4コマ目なので「1コマ目の次に2コマ目を表示する」ことができません。そこで、Iピクチャはデコード後に1コマ待って(4コマ目のPピクチャのデコードが終わって)から表示します。すると、その次には、上記3番目の「2コマ目の画像」がデコードできて表示できる。
ここで1コマの遅れは発生します。それと、画面走査にあわせて「上から順にデコードして、デコードできた部分はすぐに表示」なんてことはさすがに出来てないでしょうから、「1枚全部デコード終わってから、表示部に送る」という流れになると、ここでさらに1コマの遅れが出る。ここまでは、原理的に回避できないタイムラグ。
あとは、
などで数フレームは遅れるでしょうけど、それでもまあ、GOP待ち時間に比べれば、こっちは誤差じゃないかな。
で、まとめると、チャンネル切替後の待ち時間を3秒から1秒にするのはそれほど難しくないでしょうけど、理論限界0.6秒程度のところで、1秒からさらに縮めるのはかなり茨の道だと思います。
8ch録画だけなら、デコードせずに仕舞い込めば良いわけだしね。
そもそもデコードにはB-CASが必須としても、それを「並列使用してはいけない」って規定が有るのか？その規定があるならFriioのサーバーで共有なんてのは言い訳にならない筈。でも無いなら何でコイツはそんなに積む必要が？レコーダーで2番組同時録画でも普通はB-CASカードは一枚だよね。
「技術的には B-CAS x 1枚でカバーできるので、弊社としてはそうしたいと主張している [nire.com]」だそうで。B-CASとの契約上、1枚で2ストリームしか復号しちゃいけないらしい。
# やはりB-CASはとっととくたばった方がいいと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
B-CASカードは6枚 (スコア:4, 参考になる)
6系統のB-CASスロットを装備する [impress.co.jp]
B-CASカードは地上波2系統に対して1枚必要なんですね。
BS/CSにたいしては3系統で1枚でよいらしい。
PT1を2台とFriioを1台の環境(地上5波・BS/CS4波)に対してB-CASカード1枚で実験してみたが特に問題なく動いたので、契約的な問題さえなければ無駄な実装はいらないんでしょうね。
設計者はドジっ娘 (スコア:0)
久々に爽快なまでの無駄ハイスペック製品を見た気がする。
「8chも同時録画してどーすんじゃい」とツッコミつつも買うのが漢。
Re:設計者はドジっ娘 (スコア:0)
地デジのチャンネルを切り替えるときに、2秒から3秒の反応遅れや黒画面がでます。
「8chを同時デコード」してあれば、地デジのチャンネルを切り替えを、
従来のアナログ放送と同じ感覚で1秒以下で切り替えができます。
2台のテレビを使って、地デジとアナログ地上波のチャネルを同時に出すと、
2秒から3秒のラグが発生しているのが分かります。(地震速報の表示も遅れます)
こちらのほうの遅れは「8chを同時デコード」しても改善できません。
Re:設計者はドジっ娘 (スコア:1, 参考になる)
AV Watchの記事では、
「チャンネル切り替えの速度も高速化。地デジの場合は、“チャンネル”切替ではなく、
“チューナ”切替となる。各チューナが地デジの受信映像を常にデコードしているため、
高速な切り替え操作が行なえる。 」
と紹介されていますね。
ただそのようにチューナー/デコーダーが常にたくさん稼働しているせいなのか、消費電力が、
ディスプレイ部分(320W)＋チューナー部(140W)＝460W
とプラズマディスプレイ並になってしまってます。
REGZAは、あとh.264再生に対応してくれれば(個人的には)完璧なんだけどなあ。
Re:設計者はドジっ娘 (スコア:1)
後はアナログTVでよくあった、9分割表示とかですね。タイムラグが3秒あったら、9分割で全チャンネルを表示するには27秒間待たせることになります。アナログ時代は一瞬だったんですけどね。二チャンネル同時表示とか、往年のアナログ並みの機能を実装できるようになりますね。
Re: (スコア:0)
Re: (スコア:0)
すみません、いつ頃の機種ですか?
うちのはもう5年くらい前の機種ですが1秒程度しか遅れません。
デコード速度が進歩すればどんどん短くなるもんだと思っていたのですが、
今の機種はどうなんでしょう?
Re: (スコア:0)
デジタル動画の圧縮は、数フレーム分の画像を単位として圧縮しているので、圧縮単位の最後の画像が届くまで
その前に受け取った画像もデコードできない。つまりどんなに処理速度が速くなっても、
これ以上は圧縮アルゴリズムの原理上縮めようがないという限界が存在する。
さらに、最近の機種になると高リフレッシュレート実現のための擬似中間画像の生成やら、超解像やら、3次元ノイズリダクションやらと
メモリと時間をいっぱい喰う処理が入っていたりするので、もっと遅くなる場合もあるかもしれない。
Re:設計者はドジっ娘 (スコア:1, 参考になる)
微妙に間違ってます。
MPEG2では、「前の時刻の画像との差分を取る」という時間方向の圧縮をしていますが、
チャンネルを切り替えた時からデータの受信をは始めても、
「差分データ」だけを受け取っただけでは元の画像を復元できませんから、
およそ0.5秒間隔で「差分を取らない画像」(Iピクチャ)を送っています。
受信側では、Iピクチャを受け取ってから、画像表示を始めることになります。
というわけで、圧縮単位(「GOP」と呼ばれる、Iピクチャから始まる単独でデコード可能なデータのひとかたまり)が全部届かなくても、届き始めたらすぐに表示は可能です。
「圧縮単位の最後の画像が届くまでその前に受け取った画像もデコードできない」なんてことはありません。
問題は、この「GOP」の先頭が届き始めるまで、デコードを開始できないということにあるわけで、
それに関しては、最大で0.5秒間は待ち時間が発生します。ただし、タイミング良くチャンネルを切り替えると
同時にGOP先頭が届く、なんてこともあるわけで、平均としては0.25秒の待ちですね。
ただし、MPEG2についてもうちょっと細かく言うと、
Iピクチャを受け取ってからすぐに表示できるかというと、もう1ステップあって、
MPEG2では時間方向に「双方向の圧縮」を行ってます。届くデータの流れは
1コマ目:Iピクチャ。単独でデコード可能な画像
4コマ目:Pピクチャ。1コマ目からの差分
2コマ目:Bピクチャ。1コマ目と4コマ目からの双方向差分
3コマ目:Bピクチャ。1コマ目と4コマ目からの双方向差分
7コマ目:Pピクチャ。4コマ目からの差分
…
という並び順になってます。
ここで、1コマ目のIピクチャを受け取ってすぐに表示すると、次に受信するのは4コマ目なので「1コマ目の次に2コマ目を表示する」ことができません。
そこで、Iピクチャはデコード後に1コマ待って(4コマ目のPピクチャのデコードが終わって)から表示します。すると、その次には、上記3番目の「2コマ目の画像」がデコードできて表示できる。
ここで1コマの遅れは発生します。
それと、画面走査にあわせて「上から順にデコードして、デコードできた部分はすぐに表示」なんてことはさすがに出来てないでしょうから、
「1枚全部デコード終わってから、表示部に送る」という流れになると、ここでさらに1コマの遅れが出る。
ここまでは、原理的に回避できないタイムラグ。
あとは、
などで数フレームは遅れるでしょうけど、それでもまあ、GOP待ち時間に比べれば、こっちは誤差じゃないかな。
で、まとめると、チャンネル切替後の待ち時間を3秒から1秒にするのはそれほど難しくないでしょうけど、
理論限界0.6秒程度のところで、1秒からさらに縮めるのはかなり茨の道だと思います。
Re: (スコア:0)
ひとつは同期再生。アナログテレビでも必要な時間ですが、ISDB-T ではより
複雑な手順を踏む必要があります。自己相関からシンボル同期を確立した後に
TMCC や SP を探してキャリア同期を取るという手順になります。数10～数100ms
(伝送路の状態による)掛かります。
次に時間インタリーブ。単発的なノイズ(落雷など)によってバーストエラーが
発生するのを抑制するために、時間軸方向にシンボルを散らします。受信機側は
散らばったシンボルを元の順序に置き換えます。早く届くシンボルと、遅く届く
シンボルに、最大で 0.5 秒の遅延があります。正しい順序に置き換えるまで
Re: (スコア:0)
8ch録画だけなら、デコードせずに仕舞い込めば良いわけだしね。
Re: (スコア:0)
デコードするようにしたらぶーカスカードなんてクソは1枚だけ
契約すれば済むようにならないんですかね？
素人考えですが。
Re: (スコア:0)
そもそもデコードにはB-CASが必須としても、それを「並列使用してはいけない」って規定が有るのか？
その規定があるならFriioのサーバーで共有なんてのは言い訳にならない筈。
でも無いなら何でコイツはそんなに積む必要が？
レコーダーで2番組同時録画でも普通はB-CASカードは一枚だよね。
聞いた人がいる模様 (スコア:1, 興味深い)
「技術的には B-CAS x 1枚でカバーできるので、弊社としてはそうしたいと主張している [nire.com]」だそうで。B-CASとの契約上、1枚で2ストリームしか復号しちゃいけないらしい。
# やはりB-CASはとっととくたばった方がいいと思う。