アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
仕様と実装と運用 (スコア:2, 興味深い)
・EWS(緊急警報放送)に自動起動/切り替え
・視聴中チャンネルで文字スーパー出力
のどちらか(もしくは両方の組み合わせ)をもくろんでいたはずです。
ただ、現状の運用は(アナログサイマルであることに配慮し、運用を共通化するために)
従来のアナログ放送と同様、映像信号にスーパーインポーズしたものを
伝送する手法を放送局が選択してしまっていますね...
# 実際は局によりいろいろ異なる事情もあるみたいですが。
よもや大学でこの手の「研究」している人たちがそのあたりの事情を知らずに
動画の圧縮/伸張タイムラグを前提とした試算しているとはとても思えないのですが...
# 学部生のやっつけ卒研じゃあるまいし。
いずれにせよ、批判に際しては
・現状の放送運用に起因する問題
→映像信号として伝送されるため、もろにコーデック遅延の影響を受ける
せっかく文字スーパーなどの仕組みがあるのに活用されていない
・本来の地デジ仕様に起因する問題
→EWSでは選局先の映像・音声で表示させるため、やっぱり情報に触れるまでタイムラグがある
文字スーパーについても多重分離と出力同期で多少のタイムラグは発生する
もう少しPMTのEWS関連記述子をゴニョゴニョすれば200msくらいでメッセージ表示もできると思うんですが...
・現状の受信機実装に起因する問題
→EWSの対応が必須ではないこともあり、自動起動に対応する受信機はほとんどない(選局のみ、など)
あたりの話は踏まえたほうが、建設的な議論になるかと思います。
地デジに難癖つける理由を探している人はともかく。
Re:仕様と実装と運用 (スコア:1)
全機器EWS対応だったとしても仕組み上タイムラグはあるんですね。
その、PMTのナントカをいじって、互換性維持しつつ今後のチューナだけでもタイムラグ削減することって、可能なんでしょうか?
Re:仕様と実装と運用 (スコア:1)
ここ誤解を受けそうな表現なので補足しておきますと、
アナログ放送では確かに音声に信号を重畳していますが、
デジタル放送ではTS信号に含まれるEWSフラグで制御しています。
ですので、EWSそのものに関しては、デジタル放送でも送出に関わるタイムラグはアナログ程度、と考えていいです。
#ここでいう「情報に触れるまでのタイムラグ」は、受信機側のものですよね?
サイマルですので、アナログ用の重畳音声信号もデジタル側に流れますが、
デジタル側は基本的に重畳した音声信号には非対応です。
もう一つ、EWSについてですが、この間の緊急地震速報に関するトピでコメント [srad.jp]したのですが、
現在、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が東京・渋谷から各都道府県に中継している番組関連は、確かに蓄積が入るので遅延が発生しますが、
各都道府県の親局から各中継局への中継はそれほど遅延が発生しないですよ。
#しないわけではないですが桁が違ったはずです。
Re:仕様と実装と運用 (スコア:1)
> アナログ放送では確かに音声に信号を重畳していますが、
> デジタル放送ではTS信号に含まれるEWSフラグで制御しています。
> ですので、EWSそのものに関しては、デジタル放送でも送出に関わるタイムラグはアナログ程度、と考えていいです。
ここ誤解を受けそうな表現なので補足しておきますと :-)
EWSの検出はTMCC信号でまず確認ができます。
こっちはチューナデバイスレベルで検出できますから、
アナログ程度のタイムラグとみなしていいでしょうが、
「なんだかよくわからないがEWSをやっているらしい」までの情報です。
次にTS信号に多重化されたPMTを取得、記述子を確認する(これに0.2秒くらい?)ことで
種別(津波かそれ以外か)と地域、そして実際のEWSをやっているチャンネルを認識できます。
これも「どうやらこのあたりに関係する(津波か災害の)EWSをやっているらしい」程度ですね。
結局、ユーザにとって必要だと思われる情報はその後にEWSのチャンネルに切り替わり、
(更に1~2秒経過して)映像/音声が出力されるまで触れられないわけですから、
アナログ程度とはとてもいえないかと思います。
> #ここでいう「情報に触れるまでのタイムラグ」は、受信機側のものですよね?
よくわかりませんが、ユーザにとっては送出局で想定しうるタイムラグと
受信機側で想定しうるタイムラグの両方を重畳して初めて情報に触れられるのでは?
> ところで、文字スーパー機能(字幕放送用のものではなく、速報用のもの)って、
> 本当に全てのチューナーで実装されているんでしょうか?
運用規格では字幕・文字スーパーは必須とされていますが、
強制力は無いですから実装していない商品があるかも知れません。
TVや単体チューナなどでは私が知る限り対応していないものは見たこと無いですが...
なお、メーカの中の人の端くれ(であったことのある)立場でいうと、
字幕に対応している場合にわざわざ文字スーパーに対応しない理由は無いと思います。
必要なリソースはほとんど変わりなく、検証項目の多くが重なりますので。
なお、ワンセグは別です。あれはそもそも規格に文字スーパーが無い...
以上、Shidho氏には誤解は無いと思いますが、周りで読んでる方のために。
Re:仕様と実装と運用 (スコア:1)
>結局、ユーザにとって必要だと思われる情報はその後にEWSのチャンネルに切り替わり、
>(更に1~2秒経過して)映像/音声が出力されるまで触れられないわけですから、
>アナログ程度とはとてもいえないかと思います。
EWSを「消してるテレビをつけてチャンネルを合わせるための信号」と考えればその通りなんですが、
点いているテレビに字幕を流すためのきっかけとする情報、と考えれば
映像/音声そのものが流れるまでのタイムラグは考えなくていいかな、という話で考えていました。
まあ、現在ほとんど運用されていない字幕スーパー機能を使う、という前提があって、
これの運用がアナログ並みの遅延で可能かどうかという話をしていないので、どちらにせよ仮定の話なんですが。
Re:仕様と実装と運用 (スコア:1)
(たぶん)誰もほかの人は見ていなさそうと思いつつ続けてしまいますが、
> EWSを「消してるテレビをつけてチャンネルを合わせるための信号」と考えればその通りなんですが、
というのはTMCC信号レベルの情報のことですね。
TSレベルの解析しなくても、RF/OFDMチューナデバイスだけで検知できるという触れ込みですが、
(実証実験以外で)まじめに活用しているのはみたことない...
> 点いているテレビに字幕を流すためのきっかけとする情報、と考えれば
> 映像/音声そのものが流れるまでのタイムラグは考えなくていいかな、という話で考えていました。
(PMTにおける)EWS情報は、EWS情報をやっているチャンネルに誘導選局させるための仕組みですから、
見ているチャンネルの文字スーパーで情報が流れているのであれば、
EWS信号とは無関係に、普通に文字スーパーを表示するだけですよね?
また、見ているチャンネル以外で情報が流れているのであれば、
選局に絡む少なくないタイムラグは避けられません。
それでも賢く作っている受信機ではPMTの送出周期程度の待ちで何とかなりそうです。
(基本的に自局の別チャンネルに誘導することが多いので、TSとしては同一だと仮定できそうだし)
ただ、あまり考えずに :-) 実装されている受信機においては、
PCR受信の待ち合わせや、映像出力の待ち合わせまで行ってから文字スーパーを出すケースもあるようです。
字幕と共通実装にしてしまっていることによる弊害だと思われます。
# 字幕はESがノンスク運用なので、映像が正しくデコード出力されているときしか表示してはいけないですからね。
よって、実は少なくない受信機では選局だけでなく、映像が流れるまでのタイムラグが発生してしまいそうです。
またそもそも、文字スーパー自体はユーザ設定によりON/OFFされてしまう性格のものであるため、
EWS運用時の情報を文字スーパーなどで流すことは考えにくいです。
というあたりを踏まえて、
EWSは「ついているテレビに字幕を流すためのきっかけとする情報」にはなりえない
し、
EWSに関しては「映像/音声そのものが流れるまでのタイムラグ」の検討が必須
と思っているのですが、なんか間違ってます?
ちなみに、この手の話では「字幕」と「文字スーパー」はきっちり分けて
記述するようにしたほうが混乱が少ないと思いますよ。
# あなたの「字幕」「字幕スーパー」はすべて「文字スーパー」と読み替えて書いてますが、
# 誤りがあるようならご指摘ください。
以上、長々とお付き合いいただき申し訳ない。
細かい枝葉の話ですし、ほかのひとに読まれているかどうかも怪しいですが、
それでも誰かがググったせいで誤解が拡大再生産されるのは勘弁、なので。
# Wikipediaなんかに書かれた日には目も当てられない...