RealPlayer 8 Plus と RealSystem® G2 with Flash は、インターネットのストリーミング技術を大きく飛躍させるものです。RealSystem G2 とは、RealNetworks が提供する、コンテンツを作成して RealPlayer に配信するための最新のサーバとツール群の総称です。言うまでもなく、クリップを視聴する際には RealSystem G2 の細々とした部分の大半は、ユーザから見えないようになっています。この章では、ストリーミング メディアのしくみと、RealSystem G2 および RealPlayer がそのしくみの中でどのような役割を果たしているかを説明します。多少技術的な箇所もありますが、理解しやすく説明していますので、最新の成果を興味深く追っていただけるものと思います。
RealPlayer のしくみを理解するには、まずネットワークについて理解しておく必要があります。ネットワークの最も単純な形式は、1 台のコンピュータが別のコンピュータと情報を交換するというものです。これは、手紙のやり取りと大差ありません。
1 台目のコンピュータは、2 台目のコンピュータ宛の情報にアドレスを付加し、両方のコンピュータを接続しているケーブルを通じて送信します。2 台目のコンピュータは、着信するすべてのメッセージのアドレスをチェックし、自分宛のメッセージだけを読みます。
言うまでもなく、コンピュータの数や情報量が多くなると、このプロセスはもっと複雑になります。しかし、ネットワークの規模に関係なく、上で述べた基本原理は同じです。どのコンピュータも一意のアドレスを持ち、すべての情報の断片には、その情報の最終の配信先のアドレスが付けられています。マルチキャストには、マルチキャストをご存じの方用にマルチキャストが説明されています。ご存知でない方は、これ以降の説明で、理解していただけると思います。
一まとまりの情報の断片は、たとえば「はい」という答えのように非常に短い場合も、歌のように非常に長い場合もあります。ネットワーク上の誰もが、メッセージ全体の受信または送信が終わるまでケーブルを占有できるとしたら、あまりうまくはいかないでしょう。電子メールを受信しようとしているときに、ベートーベンの交響曲第五番を誰かが聞き終わるのを待っていなくてはならない場合を想像してみてください。こうした問題を防ぐために、メッセージはパケットと呼ばれる小さな情報単位に分割されます。一般のネットワークでは、各パケットは同じサイズで、上で述べたようにアドレスが付加されています。
この処理は余計な作業のように見えますが、このおかげで情報の流れが円滑になり、ボトルネックを少なく抑えることができます。多数の乗用車に 1 台の大型トレーラーが混じった集団よりも、大きさが一定の多数の乗用車の集団の方が、ランプから高速道路に合流しやすいものです。前の場合では、多数の乗用車がトレーラーの通過を待たなくてはならず、その後もまた、トレーラーが高速道路に空き場所を見つけて合流するまで待たされてしまいます。
情報の流れを処理する「交通巡査」には、ルータ、ブルータ、ブリッジ、サーバ、ゲートウェイなどがあります。ただし、ユーザが考慮する必要があるのは、サーバとルータの 2 つだけです。
サーバとは、ビデオや電子メールなどの情報を (企業で設置している場合はワードプロセッサなどのプログラムも) 保存しているコンピュータのことです。これらのコンピュータは、ネットワーク接続されている他のコンピュータに情報やプログラムをサービスします。どのネットワークにも少なくとも 1 台、場合によっては何台かのサーバがあります。
ルータは、情報の流れをスキャンし、各情報パケットの送信先アドレスを読み取って、そこに到達するための適切なルートに沿ってパケットを送り出します (ルータという名前はここからきています)。
インターネットという特定の 1 つのものがあるわけではありません。ある 1 つのものを指して「これがインターネットだ」ということはできません。インターネットは相互に接続されたネットワークの集まりで、互いに情報をやり取りしています。ネットワークが、相互接続されたサーバおよびコンピュータの集まりであるのと同様です。この接続は、ケーブルや光ファイバなどによる物理接続である場合も、衛星やマイクロ波などを介した接続である場合もあります。身近な例を挙げてみましょう。誰かに電話をかけるために受話器を上げると、通話相手までケーブルで信号が送られる場合もありますが、マイクロ波電波塔または衛星を介して信号が送られることもよくあります。どちらが使われるかは、通話相手との距離や電話をかけている場所によって決まります。
(とばしても結構です。でも、ずっと疑問だったことではありませんか？)
電話システムとは異なり、今日のようなインターネットは誰かが始めたわけではありません。インターネットは「インターネット」として誕生したのではなく、ARPANET (Advanced Research Projects Agency Network) として 1969 年に 誕生しました。
 |
メモ |
|---|
| 実のところ、合衆国の電話システムも、誰かが今日あるような かたちで始めたのではありません。最初は多数の小規模な私企 業があり、それが合併して 1 つの大企業になったのです (現在 は、より小規模のいくつかの企業に再び分離しています)。 |
ARPANET の当初の目的は、大学、米軍、および米国防総省から業務を請け負った企業が常に (たとえ、自然災害や戦争の最中であっても) 相互連絡を維持し、容易に情報交換できるようにするためでした。ARPANET は 4 台のサーバで立ち上げられました。今日のインターネットに 800 万台を超えるサーバがあることを考えると、隔世の感があります。
1973 年に ARPANET は DARPANET (Defense Advanced Research Projects Agency Network) になりました。DARPA は、ネット間接続 (インターネットワーキング) 経由の情報交換についての研究のパイオニアでした。彼らの研究をもとにして開発されたのが TCP/IP (Transmission Control Protocol/Internet Protocol)です。現在、TCP/IP は、コンピュータで送信されるすべての情報パケットが適切な順序で正しい場所に到達するようにアドレス付けする際の標準的な方法となっています。
この画期的な通信インフラをいちはやく利用し始めたのは大学でした。セキュリティがかけられた DARPA サブシステムを核として、各大学がサーバと接続を追加していき、インターネットが生まれました。長い間、インターネットは、大規模な電子メール システムおよび掲示板システム (投稿されたメッセージに対して、同様な方法で返信するシステム) としてしか使われませんでした。
1990 年、CERN (欧州共同原子核・素粒子研究所) は、Tim Berners-Lee の助力と Ted Nelson のアイデアを得て、今日 World Wide Web として知られている情報共有方式の標準化作業に取りかかりました。
 |
追加情報 |
|---|
| 最も一般的なインターネット アドレスの中にある「www.」が World Wide Web を表していることはご存知でしょう。今日もな お、Berners-Lee は、W3C (World Wide Web Consortium、 http://www.w3c.org/) を通して、Web の発展と方向付けに携 わっています。 |
インターネットが物質的なものの集まりであるのに対し、WWW は、パケットの転送方法、および HTML (Hypertext Mark-up Language) を使って Web ページを作成する方法に関する標準 (規則) の集合と言えるでしょう。これらの標準が作成される前はフォーマット コードはばらばらで、たとえて言えば、あるワードプロセッサが作成したファイルを別のワードプロセッサが読めるかどうかわからないのと似た状況でした。HTML のおかげで誰でも容易に情報を共有できるようになりました。情報はますます高速で流れ始めました。
|
|
追加情報 |
|---|
インターネット アドレスが HTTP:// で始まっていることにお気
づきでしょうか。HTTP ( Hyper Text Transfer Protocol ) は、プ
ロトコルと呼ばれる別の種類の標準です。ブラウザとコンピュー
タが着信した情報を読み取ることができるのは、送信された情報
が HTML であることを HTTP が通知するから です。HTTP は、
着信情報を意味のあるものにするためにサーバとコンピュータが
使う共通の辞書のようなものです。RealPlayer ではアドレスが PNM:// (Progressive Networks
Media) または RTSP:// (Real-Time Streaming Protocol) で始
まっているのにお気づきのことと思います。RealPlayer はこのア
ドレスを認識して対話します。PNM は古いプロトコルですが、
現在でも多数のクリップで使われています。新しい RealSystem
G2 コンテンツでは、クリップのアドレスの前に RTSP:// と書か
れています。アドレス (URL) がそう表示されるように、お気に入
りを編集してください。これらのプロトコルは、RealPlayer を職
場で使っている場合、ファイヤウォールと関連して重要になりま
す (ファイヤウォールとセキュリティを参照)。
|
80 年代中頃から 90 年代の始めになると、より安価で高速のハードウェアが一般に普及し始めました。インターネットは、テキスト ベースのシステムから、画像、サウンド、ビデオ、および動画を含むシステムへと飛躍的に発展しました。なぜでしょうか。普通のテキスト (単語や文字) を復元するのに必要な情報量はごくわずかです。情報があるページ全体を比較的少数のパケットですばやく送信するのは簡単なことで、接続速度が遅くても問題ありません。サウンド ファイルも小さくできますが、サウンドの品質と長さによります。このことは、画像とサイズのあまり大きくない動画にも当てはまります。サイズの大きい動画やビデオには、独特の問題があります。サイズの大きい動画やビデオは、基本的には静止画像の束の集まりで、動いているように見せるためには高速で表示する必要があります。
最近まで、インターネット上のビデオやサイズの大きい動画を、品質を落とさずに再生するベストの方法は、ファイル全体をダウンロードして、自分のコンピュータから実行することでした。ファイルを自分でダウンロードする場合、ダウンロードに時間がかかり、ファイルの保存が完了するまで長い時間待つ必要があることはわかっています。しかし、ときには、ムービーやサイズの大きい動画を開始するだけのために、とても長い時間待たなければならないことがあります。これは、その間にムービーや動画がハードドライブ上の一時ファイルにダウンロードされており、それがすんだあとで再生が開始されるからです。
次はストリーミングです。ストリーミングは、サウンド、ビデオ、動画、その他のメディア タイプのファイルを、小さな断片に分割して送信先に送ります。これは、コンピュータがネットワークやインターネット経由で情報を送信する通常の方法とよく似ています。
このような疑問が湧くかもしれません。「さっきの説明によれば、いずれにせよ情報は小さな断片の形でコンピュータに送られてくる。それとどこが違うの？」いい質問です。
図6-1： 一冊の本を 1 ページずつ送る |
図6-2： 一冊の本を 1 ページずつ受け取る |
|---|---|
その答えを知ると、RealPlayer がどうしてこれほどエキサイティングなのかわかります。RealPlayer は、ファイル ストリームが着信するに従って次々とそれを読み取り、ファイルの残りが到着するずっと前に再生を開始することができます。誰かの次に小説を読むときに、その人が本全体を読み終えて小説全体を一度に渡してくれるのを待つのではなく、その人が読み終えたページを１枚ずつ渡してくれる場合と同じです。
もちろん、ファイルが着信すると同時に次々に読み取られて再生されるだけなら、再生は何度も中断されるはずです。Web ページがなかなか画面に表示されないことがあるのと同じです。しかも、Web ページは大半のメディア ファイル (オーディオ、ビデオ、動画など) よりはるかに小さいのです。RealPlayer では、バッファという別の技術をストリーミングと組み合わせて、再生が円滑に行われるようにしています。
バッファとは、パケットをすべて手元に集めてから再生することです。
上から不規則に水がしたり落ちていくコップを思い浮かべてください。コップの底の小さな穴から一定量の水が流れ出るようになっているとします。コップに充分な水が溜まっている限り、水は一定の速度で流れ続けます (図6-3：バッファを参照)。
RealPlayer は、ファイルを再生し始めても、引き続きパケットを貯えます。このため、情報パケットがコンピュータに届くのが多少遅れても、音楽が途切れたりすることなく、快適に聞き続けることができます。
これまでの説明は、ストリーミングの動作についてであって、ストリームそのものについての説明ではありません。他はさておき少なくとも RealPlayer のストリームには別の説明が必要です。一つ一つのストリームはそれぞれ特定の種類の情報を伝送します。ビデオを見ているとき、画像部分と音楽部分はそれぞれ別のストリームで受け取っているのです。RealPlayer は、たとえば言葉が正しいタイミングでニュースキャスターの口から発音されたり、画面に合わせて音楽が適切に強められたりするように、これら 2 つの独立したストリームの同期を取ります。
また、ストリームは帯域幅に合わせて最適化することができます。帯域幅とは、ケーブルの特定の地点を通って特定の長さの時間内に受け渡すことができる情報の量のことです。帯域幅が広くなれば、受け渡される情報量も多くなります (図6-4：帯域幅を参照)。インターネットに接続する場合は、受信できるストリームの帯域幅はモデムの速度によって決まります。
28.8kbps モデムは、1 秒間に約 28,800 ビットを受信できます。56K モデムは、1 秒間に約 56,000 ビット、28.8kbps モデムの約 2 倍のビットを受信できます (1 ビットは一桁の 2 進数で伝達できる情報の単位)。これらの数値は、電話回線の接続が完璧な場合 (非常にまれ) を想定して算出されたものです。実際の数値はさまざまに異なります。
この速度をボーレートと呼ぶことがありますが、これは不正確な呼び方です。実際には、ボーとは、搬送波と呼ばれるベース サウンドが 1 秒間に変化する回数のことです。含まれる情報は、サウンドがどう変化するかで表されます。もともとは 1 回の変化 (たとえば高い音から低い音へ) で 1 ビットの情報を表していました。圧縮技術の発展により、搬送波の周波数が一回変化するごとに 1 ビットより多くの情報を伝送できるようになりました。重要な点は、受信する帯域幅が広くなると、サウンドやビデオの品質も高くなるということです。
RealPlayer でストリームを見るためには、誰かがストリームを作成する必要があります。これは、元のパフォーマンスや放送が記録されたあとで、ストリームに変換されるということです。具体的には、どのようにするのでしょうか。図6-5：オーディオ ストリームの作成方法を見てください。ここに、コンテンツの作成に必要な 4 つのステップを示しています。
パフォーマンスがキャプチャされます。キャプチャするとは、あとでストリームに変換できるように、何らかの方法で記録または作成するということです。動画などのように、コンテンツによっては、 パフォーマンスでなく、絵だけで作成されているものもありますが、考え方は同じです。あとでストリームに変換できるように、オリジナルをコンピュータ上にキャプチャします。
キャプチャされたパフォーマンスは、コンテンツ プロバイダの意図した通りのプレゼンテーションを視聴者が受け取れるように編集されます。
編集されたパフォーマンスがストリームにエンコードされます (エンコードを参照)。基本的にはこれで、ストリーミングされるファイルはできあがりです。
RealPlayer で再生できるように、エンコードされたファイルが RealServer 上に置かれます (実際のストリーミング過程を参照)。
|
|
追加情報 |
|---|
| これは、ライブ放送の場合でも同じです。テレビのライブ放送で は、カメラやマイクを使ってパフォーマンスやイベントを記録 し、数秒後に視聴者に送信できる形式にその場で変換します。 |
ファイルをストリーム化できるように準備する処理をエンコードと言います。エンコード処理では、ファイルをそのまま送信して読めるように、読み取り可能な複数のパケットに分割します (図6-1：一冊の本を 1 ページずつ送るを参照)。クリップやクリップ内のストリームはすべて、特定のビットレートに合わせてエンコードされます(SureStreamも参照)。ストリームの解像度を上げる と、情報量が増えるため、情報を実用的な速度で通過させるために必要な帯域幅も広くなります。
|
|
追加情報 |
|---|
| エンコードは、 RealNetworks 社の RealProducer®などのツール (http://www.realnetworks.comまたは http://www.jp.realnetworks.com で入手可能) を使って行いま す。RealPlayer はこれらのファイルを読んだり、エンコードして 新しいファイルに記録したりすることができます。 |
クリップの再生時にステータス バーを見ると、ストリームがどれくらいの帯域幅でエンコードされているかがわかります (図3-11：ステータス バーを参照)。示されている数値は、現在受信中のストリームの帯域幅です。オーディオ ストリームが 1 個の場合は単純です。20Kbps (キロビット/秒) のオーディオ ストリームを受信中であれば、その数値がステータス バーに表示されます。複数のストリームを受信している場合はどのように表示されるのでしょうか。ストリームの帯域幅が加算されて表示される、というのが正解です。たとえば、10Kbps の帯域幅でエンコードされたオーディオ ストリームを含む、12Kbps でエンコードされた Macromedia Flash アニメーションを受信中の場合、ステータス バーには 22Kbps として表示されます (図6-7：複数ストリームを参照)。
お使いのモデムのパイプライン (使用可能な帯域幅) に制限がある場合は、その制限以上にモデムを高速にすることはできません。通常、コンテンツ プロバイダは、さまざまな帯域幅に対応するようにストリームをエンコードします。帯域幅を広くすると、情報量が多くなり、高品質の再生ができるようになります。RealPlayer はバッファを使うことにより (RealPlayer Plus はPerfectPlay も使用可能。PerfectPlayを参照)、インターネットで多少速度が落ちてもその影響を吸収します。しかし、56K モデム用にエンコードされたストリームを 28.8K モデムを使って見るためには、大量の情報をバッファする必要があります。バッファするということは、待ち時間ができることとメモリ使用量が増えることを意味します。
エンコードされているものを読み取るためには、デコードしなければなりません。コンピュータ上で情報をデコードするにはコーデックを使います。コーデックという語は、モデムという語と同様に、2 種類の処理の名前を組み合わせて作成された言葉です。
モデムは、コンピュータのデジタル信号を、従来の電話回線で送信できるアナログ情報 (音波)に変換します。コーデックは、デジタル情報を読み取り、プレイヤ用のアナログ情報に変換して、ユーザが聞けるようにします。CD プレイヤが使うコーデックは、CD のデジタル情報をスピーカまたはヘッドフォンで聞ける音波に変換します。
RealPlayer は、各タイプのファイル ( ビデオ、テキストなど ) をそれぞれを処理できるコーデックまたはプラグインでデコードします。
|
|
追加情報 |
|---|
| [環境設定] の [アップグレード] タブを見ると、インストール されているプラグインとアドインがわかります ([アップグレード ] 環境設定を参照)。 |
RealPlayer の最初のインストール時に、RealAudio、RealVideo、RealPix、RealText、RealG2 with Flash など、いくつかのプラグインがインストールされます。これらの様々なタイプの各メディアは別々にエンコードされ、別々のストリームで送信されます。RealPlayer はそれらのストリームをデコードおよび同期化して再生します。
弊社は、これらのプラグインを更新し、また新しいプラグインを追加して RealPlayer をさらに進化させていきます。
 |
ヒント |
|---|
| AutoUpdate を使うと、常に最新のプラグインをご利用になれま す。必要な手順は [ヘルプ] メニューの [アップデートのチェッ ク] を選択するだけです。また、更新されたプラグインを必要と するクリップを再生しようとすると、更新が必要なことを知ら せるメッセージが表示されます。そのままアップグレードする こともできます。 |
ここに、エンコードされたデータ ストリームがあるとします。このストリームはプラグインでデコードされ、RealPlayer がその全情報をプレゼンテーションに変えます。しかし、これらのストリームはもともとどこにあり、RealPlayer はどのようにしてこれを見つけたのでしょうか。
インターネットは、相互に接続された一群のサーバです。サーバは他のコンピュータに情報をサービスします (おおざっぱな定義ですが、ここでは適切です)。クリップとは、プレゼンテーションを構成する任意の数のストリームのことです。すでに説明したように、1 本のクリップがビデオ ストリームやサウンド ストリームなど複数のストリームで構成されていることもあります。クリップそのものも、1 本のクリップであったり、または複数のクリップが連続して並んだものであったりします。クリップ、また複数のプレゼンテーションの場合マルチクリップという呼び名はここから来ています。
クリップやマルチクリップを聞こうとして Web ページのリンクをクリックしたときに何が起きるかを見てみましょう。
すべての Web ページは、Web サーバと呼ばれる特別なサーバに保存されています。クリップ (ライブまたはあらかじめ記録されたもののいずれも) を聞くために Web ページのリンクをクリックすると、Web サーバは、そのリンクに関連付けられている小さなポインタ ファイルをブラウザに送信します。
ブラウザは、そのファイルが普通のページではないことを認識し、ファイルを読み取れるプログラムが何かをチェックします。RealPlayer ファイルであることがわかると、RealPlayer を起動し、ファイルを RealPlayer に渡します。
ファイルは非常に小さく、RealServer 上でのクリップの名前と 場所だけが含まれています。Player は、実際のストリームを送信する RealServer に接続し、クリップに対して早送り、巻き戻しなどの操作ができるように接続を維持します。チャネルやライブ ステーションの場合、RealPlayer は RealServer と直接対話するので、ポインタ ファイルは必要ありません。
RealServer は Web サーバと似ていますが、ブラウザにページをサービスするのではなく、RealPlayer にストリームをサービスします。RealServer は Web サーバと協調動作して、インターネットなどのネットワーク環境にマルチメディアを提供します。
|
|
メモ |
|---|
| ここで、Web やインターネットと言わずに「ネットワーク環境」 という言葉を使ったのはなぜでしょうか。RealServer™ は、企 業ネットワークにおいて社内でのアドレス、トレーニング、お よびその他の情報を社員が容易に使用できるようにするために も使用されているからです。RealServer は、 http://www.realnetworks.comまたは http://www.jp.realnetworks.comからダウンロードすること ができます。 |
RealPlayer と RealServer は相互通信ができるので、RealServer は適切なストリームを取り出してユーザに送信することができます。RealServer が、高いビットレート (T1 などの高速接続) でエンコードされたストリームを送信してきたときに、28.8K モデムしか持っていない場合、快適な再生は期待できません。
では、クリップを再生しようとするときに、自分の RealPlayer に合ったストリームを取ってくるにはどうしたらいいのでしょうか。上で述べたように、RealPlayer は、ストリームを送信する RealServer と対話することができます。対話のプロセスを正確に示すと、次のようになります。
ビットレートをアップシフトするこの機能は、SureStream と呼ばれる RealSystem G2 の機能です。
RealSystem G2 以前は、実際の接続が速くなろうが遅くなろうが、クリップ全体を受信するまで、最初に接続したビットレートに固定されていました。新しい RealSystem G2 ストリームは、同一ファイル内で複数の異なるビットレート用にエンコードできるので、RealServer がユーザの現在の接続に最も適したストリームを判断して取り出すことができます。
SureStream もユーザの接続を監視します。混雑しすぎていると判断すると、いくつかのストリームのビットレートを下げます。コンテンツ プロバイダは、快適な再生にとってより重要と判断されるストリーム を選択することができます (たとえば、アニメーションの場合の音質)。SureStream は、ユーザの接続が予期よりも良好と判断すると、すべてまたは一部のストリームの帯域幅を広くし、より高い品質のプレゼンテーションを送信できるようにします。ビットレートのアップシフトやダウンシフトは自動的に行われます。
SureStream は、RealPlayer で再生可能なもののうち、比較的新しいプレゼンテーションを表示しているときに特に重要になります。SMIL プレゼンテーション (SMILを参照) を再生する場合、プレゼンテーションを構成する各コンポーネントのストリームは、それぞれに関連付けられたビットレートを持っています。それらのビットレートの合計が、大量のバッファを行わずにクリップを再生するために必要な最低限の接続速度です。たとえば、8Kbps のキャスターの声、12Kbps の Macromedia Flash アニメーション、および 5Kbps の RealText コンポーネントから構成されているプレゼンテーションを、頻繁にバッファすることなく再生するには、最低限 25Kbps の接続 (8+12+5=25) が必要です。 各ストリームは 1 本の「川」となって RealPlayer が再生するプレゼンテーションの全体を構成します (図6-7：複数ストリームを参照)。
もちろん、RealPlayer は、より高いビットレートのストリームを再生できるように、自動的にバッファします。そのため、低速の接続でも、高い品質のメディアを楽しむことができます。高いビットレートを低速の接続で見るためには、バッファに要する時間という代償を支払う必要がありますが、それでもファイル全体をダウンロードする時間に比べればはるかに短いものです。
さて、お楽しみはこれからです。RealPlayer は、単一のプレゼンテーションとして同時に提供される複数のクリップを再生できます。これは SMIL で行われます。SMIL は Synchronized Multimedia Integration Language の頭文字を取ったもので「スマイル」と発音します (気の利いた略し方だと思いませんか？ ) 。SMIL は、Web で使われている最新の言語セットの 1 つです。HTML (Hyper Text Mark-up Language) は、Web ページがテキストおよび画像をユーザのコンピュータ画面に表示する方法をコントロールしますが、SMIL は、複合メディア プレゼンテーションを RealPlayer 用にストリーミングし、RealPlayer 内で展開する方法をコントロールします。
「複合」とは、プレゼンテーションに複数のクリップが含まれているということです。RealPlayer はこれらのクリップを受信し、別のスペースで提供される各クリップと同期を取ります。たとえば、音楽ビデオ (RealVideo) を見、歌詞 (RealText) を読み、音楽 (RealAudio) を聞き、コンサートのスチール写真 (RealPix) を参照することができます。これらはすべて同時に提供されます (図6-8：SMIL プレゼンテーションを参照)。
たとえば新しい RealPlayer を紹介するチュートリアルは、RealAudio、RealPix、および RealText を含む SMIL プレゼンテーションです。プレゼンテーションの各構成要素は別々に作成、エンコード (エンコードを参照) され、そのあとで、それらを同時に提供できるように、SMIL を使って RealPlayer にレイアウトが通知されます。
|
|
追加情報 |
|---|
| SMIL についての詳細は、次を参照してください。 http://www.w3c.org/AudioVideo/ |
ストリーミングの中で、マルチキャストは言わば有機化学のような位置づけになります。有機化学や、その他のハイレベルな自然科学の講義を受講したとき、最初に「今までに教えられたことは間違いだからすべて忘れなさい」と言われたことはありませんか。
そこまで極端なことを言う必要はありませんが、たしかにマルチキャストは、ネットワーク環境のユニークなプロセスです。ネットワークでは、どの情報パケットも特定のコンピュータだけに宛てられています。これは、同時にインターネットに接続しているコンピュータがそれぞれ別のことをしている場合にはとても有効な方法です。しかし、たとえば 25,000 人のユーザがすべて同じコンサートまたはスポーツ イベントにチャネルを合わせている場合はどうでしょうか。これらの人々はまったく同じものを見ているにもかかわらず、それぞれが固有のストリームを持っていなければなりません。こういう事態が起きると、インターネットの通信速度は極度に遅くなり、快適な再生はとても望めなくなります。
マルチキャストは、この問題を画期的な方法で解決します。1 個または少数のストリームを作成し、イベントに接続しているすべての Player に、同じストリームを読むように指示したらどうでしょうか。このようにすると、各ストリームの複製は 25,000 個 ではなく少数あるだけでいいので、混雑は減り、接続の信頼性は高く、応答は速くなります。
放送にマルチキャストを使える場合は、プレイヤは自動的にマルチキャストを選択します。
|
|
追加情報 |
|---|
| マルチキャストを使うには、インターネット サービス プロバイ ダ (ISP) が提供する特別なハードウェアと、他のホスト サービス がインターネット上にある必要があるので、常に使えるとは限り ません。また、[転送] 環境設定で特定の転送だけを使うように 設定している場合もマルチキャストは使えません ([転送] 環境設 定を参照)。 |
セキュリティは、インターネットに仕事で接続する人にとっても個人の楽しみとして接続する人にとっても大きな課題の 1 つです。仕事の場合は特に、セキュリティの取り扱いには特別な配慮と方法が必要です。このため、ネットワークでは一定の予防措置をとるのが普通になってきました。
職場でコンピュータにログインするときは、ほとんどの場合、ユーザ名とパスワードを入力しないとネットワーク全体にアクセスできないようになっています。これが、セキュリティの 1 つのタイプです。パスワードによるセキュリティは、コンピュータへのアクセスを、現在の場所で制御することを主要な目的として設計されています。ファイヤウォールは別のタイプのセキュリティで、コンピュータとネットワークを外部の侵入から保護するように設計されています。
ファイヤウォールの説明は複雑ですが、RealPlayer ユーザに関係のある特性が 1 つあります。通常、ファイヤウォールはネットワークの門番の役割をします。インターネットや他サイトのコンピュータと通信する場合、外部のトラフィックはすべてファイヤウォールを通過します。このトラフィックのほとんどは片方向です。つまり、ファイヤウォールは、Web ページの要求など外部へのコマンド送信は許可しますが、双方向通信は、外部のコンピュータやプログラムに内部のコンピュータやプログラムを制御される危険があるので許可しません。この方法を使って、ネットワーク被害や情報の盗難を最小限に抑えています。
しかし、RealPlayer が適切に機能するには、双方向接続が必要です。双方向通信ができないと、クリップの早送りもできず、自分のシステムがもっと広い帯域幅のストリームを受信できることを RealServer に伝えることもできません。RealPlayer は、ネットワークをどんなセキュリティ上の危険にもさらすことなく、ファイヤウォールを通して動作できますが、 [プロキシ] 環境設定を変更する必要がある場合があります ([プロキシ] 環境設定参照)。
プロキシ サービスは、[転送] 環境設定と協調して、RealPlayer が双方向接続でインターネットに接続できるようにします。システムの他の部分への保護はそのまま提供されます。プロキシ サービスは中継役となり、ファイヤウォール内部のユーザに代わって要求を送信します。たとえば、Web プロキシは Web ブラウザの代理として要求を行う方法を知っています。多くのプロキシ サーバ / ファイヤウォールでは、ファイヤウォール内部で実行されているすべてのプログラムが特別な設定オプションを持つ必要があります。RealPlayer はプロキシを使って動作可能ですが、設定が必要です ( [プロキシ] 環境設定を参照 )。
|
|
追加情報 |
|---|
| ファイヤウォールの詳細、または職場から RealPlayer を使うと きに問題が起きた場合の解決方法などについては、次の Web ページを参照してください。http://service.jp.real.com |
800 万台を超えるサーバ、各サーバが運営する無数の Web ページ、インターネットは圧倒的に巨大です。この中からコンテンツを見つけ出すのかと思うと尻込みしてしまいます。しかし RealPlayer には検索の手助けとなるいくつかの機能が組み込まれており、ユーザに代わって選別したコンテンツを紹介してくれる Web ページへもアクセスできます。
最も役に立つツールは、RealPlayer に組み込まれている ラジオ チューナー、マイ チャネルおよび Real.com Take 5です。いずれも、ライブ クリップまたはあらかじめ記録されたクリップへの、多数のロード済みリンクを持っています。さらに、ラジオ チューナーはライブ ステーションをコンテンツのタイプで検索することができます ( ラジオ チューナー参照 )。
ラジオ チューナーからは、Web 上のラジオおよび TV の最新コンテンツ リストへ接続できます。
検索からは、興味のある事柄に関連する単語または語句を入力して、関連するストリーミング メディアを探せます ( 図3-10：Real.com メディア バーを参照 )。検索を行うと、Web ページを検索する場合と同様に結果が表示されたページが返されます。検索機能を使うには、インターネットに接続している必要があります。
ガイドを使うと、リアルガイドに直接接続します。リアルガイドはもっとも広い範囲をカバーするメディア ハブで、無料のインターネット オーディオおよびビデオ メディアおよび関連のプログラムがあります。インターネットではやっているプログラムを見つけたら、ワンクリックで再生できます。広い範囲をカバーしたリストから、ダウンロード可能なミュージックや、個人カレンダーを選択して、プレミア プログラムへアクセスしてみましょう。2,500 以上のラジオやテレビ ステーション、8000 の Web サイト、および 500 のライブ イベントが提供されています。
RealPlayer の [Web サイト] サブメニュー ([お気に入り] の下) は、音楽からエンターテインメント、スポーツ、ニュースにいたるまで、すべての情報を提供します。このメニューは RealNetworks 社と常に情報を交換していて、接続が正しいことを常に確認しています。サイトが移動した場合は、弊社がそのサイトを追跡してユーザの手間を省きます。
特に関心をもっていただけると思うのは、リアルガイドです。リアルガイドは RealNetworks 社が提供する Web ページ群で、インターネット中のいたるところのプログラムへリンクしています。特定のトピックの、ライブまたはあらかじめ記録されたストリーミング メディアをカバーしています。