アカウント名:
パスワード:
また、最近始まった地方の民放の試験放送を見ていると、コントラストが激しく変化する映像(例えば水面を反射する光など)で、ブロック境界がくっきり判別できるのを見てこりゃひどいと思いました。
ただ、それだけで悲観的にはなりませんでした。というのも、MPEG2の映像はエンコーダの性能で画質が大きく違うからです。ニュースではできませんが、ドラマなどは2パスエンコードは当たり前(と
運用上、緊急時などのテロップを重ねての放送できるようにする必要があるため、そういったテロッパーなどの機器を通したあと、電波を出す直前のところで、リアルタイムにMPEG2エンコードを行うしかないんです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
画質は向上する余地あり (スコア:5, 参考になる)
また、最近始まった地方の民放の試験放送を見ていると、コントラストが激しく変化する映像(例えば水面を反射する光など)で、ブロック境界がくっきり判別できるのを見てこりゃひどいと思いました。
ただ、それだけで悲観的にはなりませんでした。というのも、MPEG2の映像はエンコーダの性能で画質が大きく違うからです。ニュースではできませんが、ドラマなどは2パスエンコードは当たり前(と
Re:画質は向上する余地あり (スコア:5, 参考になる)
局に勤める知人に聞いた話では、現行のデジタル放送のシステムでは
> ドラマなどは2パスエンコードは当たり前(というかなっている?)、
なんていうのはまったく不可能だそうです。
運用上、緊急時などのテロップを重ねての放送できるようにする必要があるため、
そういったテロッパーなどの機器を通したあと、
電波を出す直前のところで、リアルタイムにMPEG2エンコードを行うしかないんです。
そういった情報を別ストリームで流して、受信側で合成表示するような規格ができれば、
本ストリームは事前にエンコードしておく、というのも可能になるんでしょうけどねぇ…
Re:画質は向上する余地あり (スコア:5, 参考になる)
デジタル放送には、MPEG2のPESを使った字幕・文字スーパーの方式が規定されています。
リアルタイムで重ねなきゃならないのは、むしろアナログとのサイマルを意識してなんじゃないでしょうか?
(アナログは、映像に重畳したものを出さなければならなず、デジタルでも同じ映像を使うため、親コメントのようなことをするというわけで)
逆に、ここはアナログ放送が無くなったら解決できるわけで、「現行のシステムでは」の制約ですね。
若干関係者なのでAC
それ本当?誤報でなけりゃ設計ミスじゃん、、、 (スコア:3, 興味深い)
デジタルになってまで、
テロップをビットマップで送る意味が分らない。
データ放送なんて事もしてるわけだから
仕様策定の段階で、
ストリームに緊急情報用のビットとかを定義してれば
当然、レイヤー合成で割込み表示とかの処理を
クライアント側で出来るわけなんだが、、、
局に勤める知人とやらの誤認であって欲しい、、、
uxi
Re:それ本当?誤報でなけりゃ設計ミスじゃん、、、 (スコア:0)
もうけようとする人達がいるなら
1000万の方に処理を追いやる方がコスト高になる可能性はあるのう。
それに「設計ミス」じゃなくて「ショボイ設計」な 坊や
Re:それ本当?誤報でなけりゃ設計ミスじゃん、、、 (スコア:0)
Re:画質は向上する余地あり (スコア:3, 参考になる)
> 字幕サービスと同様に、文字を重ねて表示するサービスとして、文字スーパーがあります。
> 文字スーパーは地震、災害、事件、事故を速報するときなど、番組とは連動せずに表示されます。
> 字幕サービスと文字スーパーのデータは画像データと別に送信され、受信機側で合成して表示されます。
> デジタル接続により番組を録画する場合には、文字が重なっていない画像を録画することができます。
> 機種によっては、アナログ接続でも文字が重ならない映像を録画できます。
> なお、速報の文字が画像として送信される場合は文字が重なって録画されます。
# そんなはずは…!と思って探してしまいました。
# ま、局によっては画像として送信する(機材しかない)ことも十分あると思いますが。
Re:画質は向上する余地あり (スコア:1)
>そういったテロッパーなどの機器を通したあと、
>電波を出す直前のところで、リアルタイムにMPEG2エンコードを行うしかないんです。
画質を気にして録画してる人はテロップが出てきたら結構焦ると思う。