ストリーミング2.0：明日ラジオとテレビを待っているものは何ですか？

周囲の世界は変化しており、カセットはディスクに、ディスクはファイルに、ファイルはストリーミングに置き換えられていますが、考えてみれば、これは革命ではなく進化です。 革命は現在、主に新聞とジャーナリズムに付随しており、ラジオとインターネットは単に適応しています。 印刷されたジャーナリストは、何倍もダイナミックになった世界をマスターする必要がありますが、テレビやラジオ放送の形式は本質的には変わりません。 たとえば、Dozhd TVチャンネルはインターネット視聴者をカバーし始めましたが、放送自体に技術的なブレークスルーは起こりませんでした。 コンテンツ配信メカニズムの観点から見ると、アーカイブを見て復号化を読み取​​ることができない限り、データ転送メディアのみが変更されています。 テレビは質的な開発ではなく、量的な開発に移行しています。メガピクセルが増加し、ポケットベルや携帯電話がツイーターやフォーラムに置き換えられています。 まもなくデジタルラジオが届きますが、実際には同じストリーミングの別のパッケージにすぎません。 革命はありません。



今日の記事では、オーディオおよびテレビ放送の技術革新についての私の理解を共有したいと思います。 より正確には、その技術的基礎。 私は似たようなものに出会うことができませんでした。良い例へのヒントに感謝します。



これは、オーディオとビデオのストリーミング用のオープンドラフトプロトコルに関するもので、プレーヤーとレシーバーの最大限の機能を使用できるようにします。

技術概要

HTMLとCSSに精通している人にとっては、説明は簡単です。 HTMLページは無限であると想像してください。ただし、その場で補足し、スタイル、画像、およびJavaScriptを置き換えることができます。 そして、このHTMLが視覚的なページとしてではなく、マルチメディアストリーミングのオーディオまたはビデオコンテンツとして記述されていることを想像してください。



もう1つの「現実と並行」として、YouTubeを思い出します。 ビデオを含むページを開くとき、最初にHTMLをロードし、次にリソース（javascript、CSS、画像、フラッシュモジュール）をロードし、以前に使用されていて変更されていない場合はキャッシュからこの一部を取得し、フラッシュモジュール（またはブラウザー自体） 、HTML5）がストリーミングコンテンツ（実際の動画）のプルを開始した場合、キャンペーンには動画をオーバーレイする個別のチャネル広告が読み込まれます。



その結果、プレーヤー-レシーバーは、いくつかのロジックに従って、 MIDIバックグラウンドミュージック、音声、コマーシャル、テキストなどのコンポーネントからオーディオストリームを収集することがわかりました。 このロジックの一部は、プレーヤーとレシーバーの設定に保存され、一部-このコンテンツは空中から送信されます。 プレーヤーの受信機は、音声合成エンジンを使用するか、画面にテキスト/グラフィックス/ビデオを表示できます（受信機にある場合）。 そしてもちろん、彼は「オンエア」する前にコンテンツを事前にロードし、他のニーズに使用できるようにするバッファリングを持っています。 たとえば、広告は1回だけ送信され、その後1日に何度もスクロールしますが、その時点で何か他のものが読み込まれます。



デジタルラジオやテレビとの主な違いは、アーキテクチャが受信機を同じタイプの1つのストリームに制限せず、プロトコルと「古い」デバイスとの互換性を維持しながら、受信機と送信機を改善できることです。 たとえば、 5〜10年で音声が完全に合成され、別のチャネルを使用して、オーディオブック全体のテキストをMIDI音楽で駆動できます。 実際には、受信者の所有者は、ライブブロードキャストに加えて、前後に聞くことができる多くのキャッシュコンテンツを受信し、「フラッシュドライブに」保存し、「ライブブロードキャストから」最初に巻き戻し、「拡張バージョン」などで聞くことができます。 d。 コンテンツのキャッシュと再利用が積極的に使用されているという事実。

そのようなコンテンツの受信者は何ですか？

はい、実際には専用の「ブラウザ」を備えたコンピューターです。 受信機は、より洗練され（ラジオの場合、小さな画面、大きなメモリ、優れたオーディオ部分を備えている）、よりシンプルにすることができます。 彼らは、フィードバックをサポートする（サーバーにリクエストする）か、サポートしない（プレイ、「彼らが提供するもの」）かもしれません。



このようなプロトコルの専用のプレーヤー-レシーバーには、複数の並列チャネル、タイムライン上でのカーソルの移動、各チャネル内の対応する部分の混合、キャッシュされたリソースがあります。 チャンネルの1つはマネージャーです。実際には、ユーザーの好みを考慮して、他のチャンネルからコンテンツを1つに収集するプログラムです。 たとえば、一部のチャンネルには「音声字幕」が含まれる場合があります。これは、受信者が独立して発声する場合も、まったく発声しない場合もあります。

プロトコルは何ですか？

実際、これはフィードバックをサポートするストリーミングプロトコルであり（受信機がこれに対応している場合）、マルチメディアコンテンツに特化した特別な制御/マークアップ言語です。

送信機はどうあるべきですか？

インターネットとラジオでは、アーキテクチャは多少異なります。 チャネルの負荷を最小限に抑えることが望ましいフィードバック（たとえば、インターネット）のシステムの場合、Webサービススキームは機能します-受信者が要求を行い、リソースまたはストリームを受信します。つまり、スキームはネットワーク上で利用可能なものと類似しています。 非フィードバック無線チャネルの場合、リソースを定期的に転送して、チャネルを完全に均等にロードできます。 ここで、テレテキストと同様に-情報が来たので、受信者はそれを書き留めて準備ができています。あなたがそれを引き出して使用する必要がある場合、そしてそこにいない間-それは静かです、誰もがはい、待っています。 混合モードが可能です-電源を入れるとすぐに音声が流れ、MIDIのBGMが追いつきます。コマーシャルは別のチャンネルに読み込まれます。これは、時間の開始時にプログラムによってオンにする必要があります。



これにより、いずれかのニーズに適合した「スマートレシーバー」を構築する機会が増えます。

下位互換性

このプロトコルの興味深い機能は、既存の「古いラジオ」または「古いテレビ」と互換性があり、新しいシステムに穏やかに切り替えることができることです。 実際、このようなシステムに切り替えると、既存のブロードキャストを含むチャンネルが最初に作成され、次にオプションのチャンネルが1つ追加されて同じものを送信しますが、論理的に部分（広告、ニュース、天気など）に分割され、徐々に表示されます主にこの「高度な」チャネルのセットを使用するデバイスと「古いラジオ」のユーザーは小さくなり、その結果、完全にオフになります。



既存のシステムのうち、オーディオストリーミングの分野では何も見つかりませんでした。また、セットトップボックス（settopboxes）の分野では、いくつかのリモートに類似したシステムが見つかりませんでした。 たとえば、HbbTV-Hybrid Broadcast Band TVなどの技術があります。 情報ナビゲーションとビデオストリームを組み合わせた特別な受信機。 たとえば、放送と並行してフットボール選手に関する詳細情報を見ることができます。



上記のCMMLテクノロジに近いCMMLテクノロジがあります-連続メディアマークアップ言語または関連するAnnodexまたはKate ...しかし、それらはあまり開発されておらず、それらに具体化された概念は上記の一部にすぎません。



このような何かが「離陸」すると思いますか？