アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはシンプルである。必要なのはそのシンプルさを理解する素質だけである -- Dennis Ritchie
仕様と実装と運用 (スコア:2, 興味深い)
・EWS(緊急警報放送)に自動起動/切り替え
・視聴中チャンネルで文字スーパー出力
のどちらか(もしくは両方の組み合わせ)をもくろんでいたはずです。
ただ、現状の運用は(アナログサイマルであることに配慮し、運用を共通化するために)
従来のアナログ放送と同様、映像信号にスーパーインポーズしたものを
伝送する手法を放送局が選択してしまっていますね...
# 実際は局によりいろいろ異なる事情もあるみたいですが。
よもや大学でこの手の「研究」している人たちがそのあたりの事情を知らずに
動画の圧縮/伸張タイムラグ
Re: (スコア:1)
ここ誤解を受けそうな表現なので補足しておきますと、
アナログ放送では確かに音声に信号を重畳していますが、
デジタル放送ではTS信号に含まれるEWSフラグで制御しています。
ですので、EWSそのものに関しては、デジタル放送でも送出に関わるタイムラグはアナログ程度、と考えていいです。
#ここでいう「情報に触れるまでのタイムラグ」は、受信機側のものですよね?
サイマルですので、アナログ用の重畳音声信号もデジタル側に流れますが、
デジタル側は基本的に重畳した音声信号には非対応です。
もう一つ、EWSについてですが、
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なんかに書かれた日には目も当てられない...