アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall
仕様と実装と運用 (スコア:2, 興味深い)
・EWS(緊急警報放送)に自動起動/切り替え
・視聴中チャンネルで文字スーパー出力
のどちらか(もしくは両方の組み合わせ)をもくろんでいたはずです。
ただ、現状の運用は(アナログサイマルであることに配慮し、運用を共通化するために)
従来のアナログ放送と同様、映像信号にスーパーインポーズしたものを
伝送する手法を放送局が選択してしまっていますね...
# 実際は局によりいろいろ異なる事情もあるみたいですが。
よもや大学でこの手の「研究」している人たちがそのあたりの事情を知らずに
動画の圧縮/伸張タイムラグ
Re: (スコア:1)
ここ誤解を受けそうな表現なので補足しておきますと、
アナログ放送では確かに音声に信号を重畳していますが、
デジタル放送ではTS信号に含まれるEWSフラグで制御しています。
ですので、EWSそのものに関しては、デジタル放送でも送出に関わるタイムラグはアナログ程度、と考えていいです。
#ここでいう「情報に触れるまでのタイムラグ」は、受信機側のものですよね?
サイマルですので、アナログ用の重畳音声信号もデジタル側に流れますが、
デジタル側は基本的に重畳した音声信号には非対応です。
もう一つ、EWSについてですが、
Re: (スコア:1)
でも、緊急警報放送を使ってよいと法改正したとすると、ディレイ対策は必須ですよね。
スーパーだけだったら速く出せるんでしょうか?
>ところで、文字スーパー機能(字幕放送用のものではなく、速報用のもの)って、
>本当に全てのチューナーで実装されているんでしょうか?
門外漢なので分かりませんが、「2012年、地デジのチューナが変わります!」
とかやったら非難囂々でしょうね。やっぱり。
# 今の仕組みをうまく使って何とかできると思いたい。
# テレビという媒体はやはり使いでがあるので切り捨てるのはもったいないし。
Re:仕様と実装と運用 (スコア:1)
規格上は、文字スーパー(字幕でなく、速報等で用いるもので、映像音声とは別のレイヤーで送るもの)は、
100msに1度は送るように、かつリアルタイムに表示可能、となっていますので、
最大0.1秒程度のディレイで送れるようにはなりそうです。
># 今の仕組みをうまく使って何とかできると思いたい。
調べましたが、文字スーパーは字幕機能と同じレベルで実装規定が書かれていました。
字幕非対応のチューナーがあると、速報スーパーも表示出来なくなるっぽいです。
エンコーダーを改良してMPEG2エンコード速度を1秒未満(0.1秒とか)に改良するのと、
字幕表示機能を強制するのと、どっちが現実的か、という話になるのかも。
Re:仕様と実装と運用 (スコア:1)
1秒未満ぐらいの遅延なら、技術が上がればなんとかなりそうですけど、
MPEG2の規格上「0.1秒」なんてのは原理的に絶対無理です。
MPEG2では動き予測・動き補償といって、時間方向に「双方向」に差分を取って圧縮するシステムになってます。そのため、圧縮するデータ列の入れ替えが行われてます。
1. 1コマ目について、差分は取らずまるごと圧縮 (Iピクチャ)
2. 4コマ目について、1コマ目との差分を取って圧縮 (Pピクチャ) (ここで、4コマ目まで待つ必要がある)
3. 2コマ目について、1コマ目と4コマ目の両方からの差分を取って圧縮 (Bピクチャ)
4. 3コマ目について、1コマ目と4コマ目の両方からの差分を取って圧縮 (Bピクチャ)
5. 7コマ目について、4コマ目との差分を取って圧縮 (Pピクチャ)
6. 5コマ目について、4コマ目と7コマ目の両方からの差分を取って圧縮 (Bピクチャ)
(以下略…)
って感じ。
こういう時間軸方向の圧縮を行っているため、「圧縮に必要なデータを揃える」段階で、データの先読みが必要な分遅延が必ず発生します。
I/Pピクチャ間にBピクチャが3枚入ったら、それだけで3コマ=0.1秒の遅延確定です。
あとは「フレームバッファに1コマ分の画像データを貯めてから圧縮処理を始める」段階でも1コマ分の遅延が出てきますね。
でもって、デコーダの方でも、
1. 1コマ目(Iピクチャ)について展開 (1コマ目の画像はすぐには表示しない)
2. 1コマ目の展開画像に対し4コマ目の差分データを適用して4コマ目の画像を展開 (ここで1コマ目を表示)
3. 1コマ目と4コマ目の展開画像に対し2コマ目の差分データを適用して2コマ目の画像を展開 (2コマ目を表示)
4. 1コマ目と4コマ目の展開画像に対し3コマ目の差分データを適用して3コマ目の画像を展開 (3コマ目を表示)
5. 4コマ目の展開画像に対し7コマ目の差分データを適用して7コマ目の画像を展開 (2で展開した4コマ目を表示)
6. 4コマ目と7コマ目の展開画像に対し5コマ目の差分データを適用して5コマ目の画像を展開 (5コマ目を表示)
(以下略…)
といった感じで処理を行うので、こっちでも遅延が発生します。
各コマ毎のデータ量が一定じゃない(ビットレート固定の場合でも、時間圧縮の無いIピクチャやPピクチャのデータ量は大きくなる)ので、そのバッファリングでもやっぱり遅延が発生するとか。
とにかく、デジタル処理上はいろんな所に遅延の要因があり、
個々の遅延は大したこと無くても、つもりつもって大きな遅延になってしまいます。
あと、地デジ放送が時報を諦めた理由の一つとして、中継の問題もありますね。
アナログ信号の中継は、来た信号を蓄積なんかせずにそのまま次に回すので遅延が問題になりませんが、
デジタルの場合、中継が入るとそこで「データの蓄積」処理が入るので、遅延を一定にできない、とか。
Re:仕様と実装と運用 (スコア:1)
ところで、
>アナログ信号の中継は、来た信号を蓄積なんかせずにそのまま次に回すので遅延が問題になりませんが、
>デジタルの場合、中継が入るとそこで「データの蓄積」処理が入るので、遅延を一定にできない、とか。
どの中継のことを指すかにもよるのですけど、
NHKが東京・渋谷から各都道府県に中継している番組関連は、確かに蓄積が入るので遅延が発生しますが、
各都道府県の親局から各中継局への中継はそれほど遅延が発生しないですよ。
#しないわけではないですが桁が違ったはずです。