この章では、ネットワーク (イントラネットまたはインターネット) でのライブ コンテンツのブロードキャストに関する基本事項および方法について説明します。ブロードキャストのタイプ、ブロードキャストのオプション、およびブロードキャストの高度な機能について説明します。ブロードキャストの準備が整っている場合は、第 11 章を参照して、選択したタイプのブロードキャスト方式の使用方法を確認してください。
 |
ヒント : ストリーミング メディアに関する知識がない場合は、第 6 章を参照し、静的なクリップのエンコード処理についての理解を深めてください。また、第 4 章および第 5 章で、オーディオとビデオに関する基本事項を確認する必要もあります。ブロードキャストでは、クリップのエンコード時と同じ選択が必要になる場合が多く、同時に、ブロードキャストの帯域幅およびプロセッサの負荷に関する新たな検討事項が生まれます。 |
ライブ ブロードキャストでは、RealProducer はキャプチャ カードからライブ入力を取得します (詳細は「ライブ オーディオやビデオを入力として使用する」を参照)。続いて、その入力を RealAudio または RealVideo としてエンコードし、RealPlayer 視聴者への配信および複製のためにストリームを Helix Server へ送信します。ブロードキャスト ストリームのエンコードでは、静的なクリップの作成時と同じオーディエンスを使用します (第 7 章に説明があります)。
RealProducer は、RealPlayer に直接ブロードキャストを行うことができません。そのため、Helix Server が必要になります。Web サーバも、ブロードキャストの配信には使用することができません。Helix Server のライセンス、または送信帯域幅などの実際的な検討事項によって、ブロードキャスト配信が可能な RealPlayer 視聴者の数が決まります。ブロードキャストを許可するように、Helix Server を設定します。サーバの設定により、ブロードキャストを RealPlayer 視聴者に配信する方法が次のように決まります。
RealProducer から Helix Server へブロードキャスト ストリームを送信するため、RealProducer にサーバの宛先を定義します。宛先には、サーバのアドレスやアクセスに必要となるパスワードなどの情報が記録されます。宛先をテンプレートとして保存すると、同一のパラメータを使用するブロードキャストを繰り返し実行することが容易になります。ジョブ内にサーバの宛先を複数定義すると、ブロードキャストの実行時に、同一のストリームを複数のサーバに対して送信できます。ジョブにクリップの宛先を追加すると、ブロードキャストをクリップとしてアーカイブすることも可能になります。
RealProducer では、複数のブロードキャスト方式を使用することができます。ブロードキャスト方式は、プッシュとプルという 2 つの基本領域に分けられます。
プッシュ ブロードキャストでは、RealProducer がブロードキャスト ストリームを開始します。ストリームは、ブロードキャストが開始された時点で Helix Server に配信されます。プッシュ ブロードキャスト方式には、次のような種類があります。
プル ブロードキャストでは、RealProducer は、エンコードの開始直後にブロードキャスト ストリームを配信することはありません。代わりに、Helix Server がストリームを要求するまで待機します。これは、最初の RealPlayer ユーザがブロードキャストを要求した時点で発生します。詳細については、「プル ブロードキャストの実行」を参照してください。
固定ビット レート (CBR) のオーディオやビデオのブロードキャストは、最も広範囲のオーディエンスを対象にすることができます。「SureStream CBR クリップ」で説明されているように、SureStream を使用して、ブロードキャスト ストリームを複数のオーディエンスに対してエンコードすることが可能です。ただし、選択したそれぞれのプライマリ ストリームまたはサブストリームによって、エンコード中のプロセッサの負荷は増大し、必要とされる送信帯域幅も増加します。
たとえば、56k Dial-up オーディエンスと 128k Dual ISDN オーディエンスを選択した場合、エンコーディングには 2 倍の処理能力が要求されます。また、RealProducer が使用する送信帯域幅として、185 Kbps 以上が必要になります。
 |
備考 : Lossless コーデックでエンコードした場合を除き、オーディオのみの RealAudio ストリームはすべて CBR であり、SureStream の使用をサポートしています。 |
可変ビット レート (VBR) のビデオをブロードキャストする場合は、各出力に対してそれぞれ 1 つの VBR オーディエンスを選択します。RealProducer の送信帯域幅は、RealPlayer 視聴者のネットワーク接続と同様に、選択したオーディエンスで必要となる最大帯域幅に対応している必要があります (オーディエンスの一覧は第 7 章で参照できます)。たとえば、350k Download (VBR) オーディエンスで想定される最大帯域幅は毎秒 700 キロビットです。
|
備考 : VBR ストリームをブロードキャストする場合、VBR の特性を理解しておく必要があります。「ストリーミングとブロードキャスト用の VBR クリップ」で、基本的な知識を確認できます。 |
マルチキャスト以外のプッシュ ブロードキャスト方式を使用する場合、Helix Server へのブロードキャスト ストリームの配信時に、TCP または UDP のどちらを使用するかを指定します。ネットワークのオーバーヘッドがより小さくなるという理由から、UDP プロトコルをお勧めします。ただし、伝送路損失の大きい環境でブロードキャストを配信する場合は、TCP を使用することも可能です。
|
備考 : アカウント ベースのブロードキャストの接続監視では、データ転送ストリームが UDP または TCP のいずれの場合でも、常に TCP が使用されます。 |
RealProducer でコネクションレス型の UDP プロトコルを使用する場合、ブロードキャスト パケットが到着したか、または紛失したかという情報の通知は行われません。これにより、通常、ネットワーク通信のオーバーヘッドが減少し、ブロードキャストの品質が向上します。データの再送信が必要な場合は、Helix Server が RealProducer に対して通知を行います。このように、UDP を使用すると、ブロードキャストのパフォーマンスを向上させることができます。
RealProducer と Helix Server の間のファイヤーウォールによって、UDP パケットが遮断される場合があります。この場合、最善の対処方法は、RealProducer と Helix Server がブロードキャストの伝送に使用するポートで UDP パケットの通過を許可するようにファイヤーウォールの設定を行うことです。該当のポートは、ブロードキャスト方式によって異なります。詳細は、第 11 章で各タイプのブロードキャストの設定に関するセクションを参照してください。
ブロードキャストで TCP プロトコルを選択する場合、RealProducer と Helix Server は双方向通信を確立します。伝送中にブロードキャスト パケットが失われると、ネットワーク自体がパケットの再送信を要求します。これにより、パケット損失が多くなりがちなネットワーク上のブロードキャストにおける、TCP の信頼性が向上します。また、UDP 通信を許可するような設定ができないファイヤーウォールでも、パケットが通過する可能性はより高いといえます。
ただし、TCP を使用すると、ネットワークおよびコンピュータのオーバーヘッドが高くなり、効率が悪化する場合があります。Helix Server では、RealPlayer へのブロードキャストの流れを維持するために、すべてのストリーム パケットを必要とはしません。パケットが失われると、ネットワークが RealProducer からのパケットを再要求します。しかし、そのパケットが使用できなくなっている場合があります。また、パケットが使用可能な場合でも、Helix Server への到着が遅すぎて役に立たないことがあります。結果として、RealProducer および Helix Server では、ブロードキャストに不要なネットワーク要求もある程度処理することになります。
通常の状態では、Helix Server は、視聴者へのブロードキャストの前にライブ ストリーム入力のバッファは行いません。しかし、RealVideo をブロードキャストする場合、RealPlayer は、映像イメージを表示する前にビデオのキー フレームを受信する必要があります。標準的な RealProducer のエンコーディング設定では、可能性として、ブロードキャストの再生開始から 10 秒が経過した後にキー フレームが表示されます。したがって、ビデオの映像トラックが表示されるまでの 10 秒間、視聴者はサウンドトラックを聞くことになります。
最大キー フレーム間隔を短縮することにより、ブロードキャスト中のこのような遅延を減らすことが可能です (詳細は 「最大キー フレーム間隔」で説明されています)。ただし、これにより RealVideo コーデックの圧縮ゲインが減少し、フレーム レートが低速になったり画質が低下する場合があります。発生する遅延は、キー フレームがストリームにエンコードされる実際の頻度や、視聴者がどの時点でブロードキャストに参加するかに応じて、視聴者ごとに異なってくるという点にも注意してください。
SMIL 1.0 または SMIL 2.0 を使用して、ライブ ブロードキャストに収録済みコンテンツを追加することができます。SMIL ファイルでは、ブロードキャストをほかのクリップと同様に扱い、RealPlayer がオンデマンド クリップの代わりにライブ ストリームを指し示すような URL を提供します。ブロードキャスト ストリームを SMIL 領域に割り当てることによって、プレゼンテーションのレイアウトを調整したり、ブロードキャストを連続的に再生したり、オンデマンド クリップと並行して再生したりすることが可能になります。
たとえば、SMIL では、オンデマンドの RealPix スライド ショーとライブの RealAudio を同時に配信することが可能です。ただし、オンデマンド クリップとライブ ストリームを同期させることはできません。これは、オンデマンド クリップではユーザがプレゼンテーションを要求した時点でタイムラインが開始されるのに対して、ブロードキャスト ストリームではブロードキャストが実行された時点でタイムラインが開始されるためです。
たとえば、ブロードキャスト開始の 2 分後にユーザ A がプレゼンテーションを要求し、同じく 4 分後にユーザ B がプレゼンテーションを要求したとします。ブロードキャスト開始から 10 分が経過すると、どちらのユーザも同じオーディオを聞いています。しかし、ユーザ A の RealPix クリップは 8 分を、ユーザ B のクリップは 6 分を指しています。このように、2 つのタイムラインの関係は、ユーザによって異なります。
 |
詳細情報 : SMIL の詳細については、『RealNetworks プロダクション ガイド』を参照してください。 |
ライブ コンテンツをブロードキャストする場合、チャンスは一度だけです。機器が正常に作動するか、ブロードキャストの結果が期待どおりになるかを確認するために、テストを行うことをお勧めします。ライブ ブロードキャストは、収録済みファイルのようには編集することができないため、あらかじめ慎重にオーディオ レベルを設定し、ビデオ ショットを想定しておくことが重要です。
テスト中もライブ ブロードキャストの実行時も、RealPlayer でブロードキャストを視聴し品質を確認するようにしてください。RealPlayer が接続した後、適切な時間内にコンテンツの再生が開始されることを確認します。例としては、プッシュ ブロードキャストでは 15 秒以内、プル ブロードキャストでは最初の要求に対して 30 秒以内が適切です。RealPlayer の再生に関する統計を表示し、フレーム レートが適切であること、および過剰なパケット損失が発生していないことを確認してください。
SureStream を使用してブロードキャストを行う場合は、RealPlayer の帯域幅に関する設定を変更することで、さまざまな SureStream のストリームを表示することが可能です。テスト中に問題が発生した場合、ストリーム数の削減が必要になることがあります。また、エンコーダを実行するために、より処理能力の高いコンピュータが必要になることもあります。
|
詳細情報 : ブロードキャスト時にプロセッサの負荷を管理する方法についての詳細は、「ブロードキャストの負荷管理」を参照してください。ライブ ブロードキャストでのオーディオとビデオのエンコーディングに関するヒントは、第 4 章および第 5 章で確認できます。 |
この章で説明されているブロードキャストの手法は、ライブ コンテンツのブロードキャストに関してのみ適用されます。Helix Server の SLTA (Simulated Live Transfer Agent) を使用して、静的なクリップをライブ イベントのようにブロードキャストすることができます。収録済みの同じ曲をすべての視聴者に同時にブロードキャストするラジオ局のような効果が得られます。さらに、SLTA により、ブロードキャスト中に更新可能なプレイリストを定義することも可能になります。
SLTA を使用する場合、静的なクリップを第 6 章に説明されている手順でエンコードします。SLTA ブロードキャストで使用されるすべてのクリップは、同一のオーディエンスに対してエンコードされる必要があります (この場合、オーディエンスの数は 1 つであっても複数であってもかまいません)。次に、クリップを Helix Server に転送し、SLTA プレイリストを設定します。続いて、Windows または UNIX のコマンド ラインから SLTA ユーティリティを実行します。詳細については、『Helix Universal Server アドミニストレーション ガイド』の「擬似ライブ ブロードキャスト」の章を参照してください。
最も単純なブロードキャスト方式では、プッシュまたはプルのブロードキャスト方式を使用して、単一のストリームを単一のサーバに送信します。または、マルチキャストを使用して、単一のストリームを複数のコンピュータに送信します。一方、RealProducer では、複数のストリームを複数の宛先に送信することができます。同様に、Helix Server には、ほかのサーバにストリームを転送するための複数の機能があります。後続のセクションでは、ブロードキャスト ストリームを複数の宛先に配信する方法について説明します。
RealProducer を使用すると、単一のエンコード済み出力に対して複数のサーバの宛先を定義することができます。これにより、同一のブロードキャストを複数の Helix Server に転送することが可能になります。プッシュ ブロードキャストでは、各宛先を具体的に定義します。プル ブロードキャストでは、Helix Server が RealProducer からブロードキャストをプルするタイミングで、新しい宛先が作成されます。
出力に対して定義する新たなサーバの宛先は、送信帯域幅の要求として追加されます。たとえば、ブロードキャスト ストリームが 350 キロビットの場合、2 番目の宛先に送信を行うことで、帯域幅の合計は少なくとも 700 キロビットに増加します。ライブ エンコーディングでのプロセッサの負荷は、各宛先に対して同一のストリームが送信されるため、複数の宛先を使用した場合でも増加することはありません。
並行出力 (複数出力) を使用すると、2 つ以上のストリームを異なるプロパティによってエンコードすることができます。例としては、ライブ オーディオを、ダイヤルアップ モデムのユーザ向けに低帯域幅の SureStream CBR ストリームとしてエンコードし、かつ、ケーブル モデムのユーザ向けに高帯域幅の VBR ストリームとしてエンコードしたい場合などがあります。単一のストリームを CBR と VBR の両方のストリームにエンコードすることはできないため、異なる 2 つの出力が作成されます。
「宛先と出力」 に示すように、エンコード済みの各出力は、同一の宛先サーバまたは異なる宛先サーバに送信することができます。同一の Helix Server で両方のストリームをブロードキャストする場合は、ストリーム名は異なるものにする必要があります。これにより、Web ページでは、視聴者が低速のブロードキャスト、または高速のブロードキャストのいずれかを選択できるようになります。
出力が追加されるごとに、RealProducer ではより多くの処理能力を要求するようになります。このため、コンピュータが負荷に十分対応できる処理速度を持っていることを確認する必要があります。各出力に必要とされる処理能力は、選択されたオーディエンスによって異なります。複数レートの SureStream エンコーディングでは、単一オーディエンスのエンコーディングよりも多くの処理能力が要求されます。同様に、ビデオのエンコーディングでは、オーディオのみの入力よりも多くの処理能力が要求されます。
|
詳細情報 : 並行出力を設定するには、付録 B で説明している手順に従ってジョブ ファイルを作成します。続いて、第 14 章で説明しているコマンド ライン アプリケーションを使用してブロードキャストを実行します。 |
各 Helix Server では、ブロードキャストを受信することのできる視聴者数に上限があります。この上限は、送信帯域幅の量といった実質的な制約や、サーバのライセンスなどに基づくものです。大規模なブロードキャストを実行する場合は、想定されるオーディエンスへの配信を確実にするために、複数の Helix Server を使用する必要があります。RealProducer では、ブロードキャスト ストリームを複数の宛先サーバに送信することが可能ですが、多くの場合、サーバ自体がブロードキャスト ストリームを転送 (またはスプリット) するほうがより効率的です。
上の図は、単純なスプリット構成を表しています。トランスミッタの役割を果たす 1 台の Helix Server に、RealProducer がブロードキャスト ストリームを送信します。次に、このサーバは、ストリームをレシーバの役割を果たす 3 台の新たな Helix Server に対してスプリットします。トランスミッタとレシーバは、それぞれ複数の視聴者に対してブロードキャストをストリームします。
RealProducer がストリームをトランスミッタに配信する方法は、トランスミッタがストリームをスプリットする方法とはまったく異なるものです。たとえば、RealProducer ではアカウント ベースのプッシュを使用してトランスミッタと通信し、トランスミッタでは複数のレシーバへマルチキャストを行うことによってストリームをスプリットするといったケースが考えられます。同様に、RealProducer ではブロードキャスト ストリームをトランスミッタにプッシュするが、レシーバではトランスミッタからストリームをプルするように設定されているといったケースもあります。
|
詳細情報 : スプリット構成を設定する場合、熟練した Helix Server 管理者によるサポートが必要です。使用可能なオプションについては、『Helix Universal Server アドミニストレーション ガイド』で「トランスミッタとレシーバ」の章を参照してください。 |
後続のセクションでは、Helix Server にブロードキャストを行う際に使用するオプションの機能について説明します。状況に応じて、Helix Server 管理者はサーバ上で機能を有効にしたり、変更したりする必要があります。
アカウント ベースまたはパスワードのみのプッシュ方式によるブロードキャストでは、同じライブ イベントをエンコードする複数の RealProducer を使用して、エンコーダ冗長性を実現することができます。各ブロードキャスト ストリームを開始する際には同じストリーム名を指定しますが、そこで、「.1」や「.2」といった、固有の通し番号付きのデリミッタ (区切り文字) を追加します。RealProducer が Helix Server に接続している間は、接続順に基づきキューが生成されます。例としては、次のようになります。
live.rm.2 1 番目に接続します。live.rm.3 2 番目に接続します。live.rm.1 3 番目に接続します。
通常の環境では、すべての視聴者がストリーム live.rm を受信し、そのストリームをどの RealProducer がエンコードしたかについては意識しません。この例では、live.rm が live.rm.2 として生成されています。live.rm.2 を配信する RealProducer にエラーが発生した場合は、RealPlayer はキュー内の次の live.rm ストリーム、つまり live.rm.3 に接続します。live.rm.2 は、復旧するとキューの最後に配置されます。続く live.rm.3 にもエラーが発生した場合は、メディア プレーヤーは live.rm.1 に接続します。以下、同様に処理が行われます。
|
備考 : エンコーダ冗長性は、Helix Server では自動的に有効になります。ただし、これによって、ブロードキャスト URL が変更されます。Helix Server 管理者は、ストリームの識別子として、チルダ (~) などの異なったデリミッタの使用を要求することもあります。エンコーダ冗長性を使用する前に、こうした問題について管理者に確認を行ってください。 |
|
ヒント : 最適な冗長性を実現するためには、各エンコーダをできるだけ独立させる必要があります。たとえば、別々の電源とネットワーク接続を使用する複数の RealProducer コンピュータを用意し、各コンピュータに別々のビデオ カメラを接続します。 |
|
詳細情報 : エンコーダ冗長性の設定オプションについては、『Helix Universal Server アドミニストレーション ガイド』の「ユニキャスト」の章を参照してください。 |
ライブ イベントをブロードキャストする際に、今後のオンデマンド ストリーミング用にイベントをクリップに記録することも可能です。RealProducer または Helix Server のいずれか、あるいは両方を使用して、クリップのアーカイブを行うことができます。主な考慮事項としては、ディスク容量の問題があります。長時間のブロードキャストをクリップに書き込む場合、ブロードキャストの帯域幅によっては大量のディスク容量が消費される可能性があります。サーバには、RealProducer を実行するコンピュータよりも、使用可能な容量がより多く存在していることがあります。また、サーバ上でアーカイブを作成すると、オンデマンドでストリームする場合に、アーカイブ クリップを後からアップロードする必要がなくなります。
RealProducer 上でブロードキャストをアーカイブするには、サーバの宛先と共にクリップの宛先を定義します。既存のアーカイブがオペレーティング システムの制限 (通常 2 または 4 ギガバイト) に達した場合、RealProducer は自動的に新規のクリップを作成します。コマンド ラインからブロードキャストを実行する、またはブロードキャスト用のジョブ ファイルを手動で作成する場合は、ブロードキャスト時間やファイル サイズに基づいて、ファイルのローリングに関する制限値を新たに指定することができます。
|
詳細情報 : アーカイブ クリップの作成方法については、「宛先クリップの作成」を参照してください。コマンド ラインを使用したファイルのローリングについては、「出力と宛先のオプション」を参照してください。ジョブ ファイルを使用してファイルのローリングを定義する方法については、「ファイルの宛先」セクションで説明しています。 |
Helix Server 管理者は RealMedia ブロードキャストのアーカイブを有効にすることができます。RealProducer と同様に、Helix Server では、ブロードキャスト時間 (15 分ごとに新しいファイルなど) やファイル サイズ (ファイルごとに 20 メガバイトなど) に基づいて、複数のアーカイブ ファイルを作成することが可能です。また、管理者は、ストリーム名の仮想パスの記述に基づいて特定のブロードキャスト ストリームのみをアーカイブする、選択的なアーカイブ ルールを設定することもできます。
|
詳細情報 : アーカイブに関する詳細は、『Helix Universal Server アドミニストレーション ガイド』の「ユニキャスト」の章を参照してください。 |
ブロードキャストをエンコードする場合、live.rm といったストリーム名を定義します。news/live.rm のようにして、ストリーム名の前に仮想パスを付加することもできます。仮想パスは、物理的なディレクトリまたはマウント ポイントには関連付けられていません。仮想パスは、Helix Server へのフラグとして使用され、アーカイブまたはスプリットでの特定のルールに適用されます。
Helix Server 管理者は、仮想パスの記述に基づいてアーカイブ ルールを設定することができます。たとえば、管理者は、あるディレクトリでは news/ パスを含むすべてのブロードキャスト、別のディレクトリでは sports/ パスを使用するすべてのブロードキャストを、それぞれアーカイブすることが可能です。仮想パスは、スプリット (「サーバのスプリット」を参照) においても使用されます。仮想パスによって、どのブロードキャスト ストリームがどのレシーバにスプリットされるかを定義することができます。
|
備考 : 使用するパス名については、Helix Server 管理者に確認してください。ブロードキャスト ストリーム名に仮想パスを使用した場合、ブロードキャストへの URL にも同様に仮想パスを含める必要があります。 |
|
詳細情報 : サーバサイドのアーカイブ ルールについては、『Helix Universal Server アドミニストレーション ガイド 』の「ユニキャスト」の章を参照してください。スプリット ルールについては、同ガイドの「トランスミッタとレシーバ」の章を参照してください。 |
ライブ コンテンツをブロードキャストする場合、RealProducer を実行するコンピュータでオーディオ入力やビデオ入力がリアルタイムでエンコードされることが重要です。それが実行されない場合、エンコード処理がメディア入力よりも遅れ、ブロードキャストが停止してしまいます。RealProducer では、必要に応じて処理の負荷を自動的に低減する複数の機能が提供されています。後続のセクションでは、こうした負荷管理機能について説明します。また、必要とされる処理能力を実現するために使用を控えるべきエンコーディングのオプションについても説明します。
|
備考 : 固定ビット レートのブロードキャスト用に選択する SureStream オーディエンスの数は、処理要件に大きな影響を与えます。詳細については、「CBR ブロードキャスト」を参照してください。 |
|
ヒント : 2 つまたはそれ以上のプロセッサを持つコンピュータを使用してエンコードを行うと、より高品質の結果が得られます。RealProducer で複数のプロセッサを管理する方法については、「RealVideo コーデック」に説明があります。ライブ ブロードキャスト中は、RealProducer を使用するコンピュータの処理速度にかかわらず、ほかの不要なアプリケーションやサービスは実行しないようにしてください。 |
ブロードキャストを行う前に、RealProducer を使用するコンピュータをテストして、処理の負荷に対処可能かどうかを確認することができます。
「ブロードキャストのテスト」セクションの説明に従って、テスト ブロードキャストを実行することが最適の方法です。ブロードキャスト中に、コマンド ライン アプリケーションの出力やログ ビューアの表示を確認し、負荷の低減およびフレームの損失に関するメッセージがないかチェックします。ブロードキャストのテストの完了後に統計を調べ、ビデオの平均フレーム レートが十分であるかどうかを確認します。
|
詳細情報 : 「ログ メッセージの表示」および「統計のモニタ」の各セクションを参照してください。 |
ブロードキャストの負荷テストに使用可能な Helix Server がない場合、第 6 章の説明に従って RealMedia クリップへのライブ入力をキャプチャします。オプションとオーディエンスは、ブロードキャストで使用するものを選択してください。RealProducer がクリップの再生時間内でクリップをエンコードできれば (たとえば 60 秒のビデオ ファイルを 45 秒でエンコードできた場合など)、通常、ブロードキャストの負荷に対処することが可能です。
|
ヒント : ビデオ クリップでテストを行う場合は、「ビデオ オプションの選択」の説明に従って 2 パス エンコーディングを無効にします。 |
「エンコーディング コンプレキシティ モード」で説明されているように、ビデオのコンプレキシティ レベルを low、medium、high のいずれかに設定することができます。デフォルトの設定 high が使用されている場合、RealProducer では、エンコーディング処理がビデオ入力に追いつかない状況が発生すると自動的にレベルを下げます。これによりビデオ品質が低くなりますが、ブロードキャストの流れは維持されます。したがって、RealProducer が使用されているコンピュータでほかのアプリケーションのために処理能力を確保したい場合を除いては、ブロードキャスト中に手動でのレベル変更を行う必要はありません。
デフォルトでは、RealProducer は最高品質のビデオを提供する RealVideo 10 を使用しますが、この場合、処理能力も最大限必要となります。最良の結果を得るためには、RealVideo 10 を使用し、かつ、RealProducer によってエンコーディング コンプレキシティを自動的に低減するようにします。RealProducer Plus を使用しても依然として処理能力が不足している場合は、要求される処理能力が少ない RealVideo 9 に切り替えることができます。RealVideo 8 に切り替えた場合は、RealVideo 9 よりも要求される処理能力がさらに少なくなります。
|
ヒント : YUV12 (I420 とも呼ばれます) は、RealVideo コーデックで使用されるネイティブな色形式です。ビデオ入力を I420 でキャプチャすると、エンコーディング前に色形式を変換する必要がなくなるため、パフォーマンスが向上します。 |
RealProducer は、必要に応じてエンコードされるフレーム レートを低くし、メディア入力ストリームに速度を合わせます。ほとんどのオーディエンス設定では、15 fps または 30 fps の推奨フレーム レートが指定されます。RealProducer は推奨レートを実現しようと試みますが、CPU 使用率が最大の状態でエンコーディング処理が開始された場合は、必要に応じて低速のレートでエンコーディングを実行します。フレーム レートの低減を確認するには、ログ ビューアをチェックします。エンコーディング時に適切なフレームレートを維持するためには、CPU に高い負荷を要求するほかの機能を不使用にするか、より高速なコンピュータを使用してブロードキャストを実行する必要があります。
|
備考 : RealProducer では、選択されたブロードキャスト オーディエンスの帯域幅の制約によって、エンコードされるフレーム レートを低くする場合もあります。こうしたレートの低減は CPU のボトルネックが原因ではないため、RealProducer のログでは報告されません。その代わり、RealPlayer の再生に関する統計パネルで、ブロードキャスト ストリームのフレーム レートを確認することができます。 |
「RealVideo フィルタ」では、ブロードキャスト中に使用可能なビデオのプレフィルタについて説明しています。黒レベル補正フィルタ、インタレース除去フィルタ、低ノイズ フィルタは、それほど処理能力を必要としないため、それ以外のフィルタよりも安定的に使用できます。ビデオのサイズ変更は、プロセッサに過大な負荷を要求します。ブロードキャスト中は使用しないでください。一方、ビデオの切り取りを実行すると、エンコーディング対象となるビデオのデータ量が減るため、エンコーディングの処理速度が向上します。
|
ヒント : 可能であれば、ビデオ キャプチャ カードを使用して、ビデオ入力を適切なサイズに設定してください。一般的に、ハードウェアを使用したサイズ変更は、ソフトウェアを使用したサイズ変更よりも高速です。ビデオの高さおよび幅を設定するためのヒントについては、「エンコード時のビデオのサイズ」を参照してください。 |
RealAudio コーデックでは、一定のサンプリング レートを持ったオーディオ入力が必要となります。RealProducer は必要に応じて、エンコーディング前にオーディオを適切なレートに再サンプリングします。推奨のサンプリング レートをオーディオ入力で使用すると、再サンプリングを回避することができます。詳細は、「サンプリング レート」を参照してください。
RealProducer のグラフィカル アプリケーションを使用してブロードキャストを実行する場合、RealNetworks では、ビデオ入力とエンコード済み出力の映像表示をオフにして、プロセッサの負荷を小さくすることを強くお勧めします。詳細は、「ビデオ出力のモニタ」セクションを参照してください。
|
©2004 RealNetworks, Inc. 詳細については、RealNetworks の Web サイトを参照してください。 画面左側に目次フレームが表示されない場合は、ここをクリックしてください。 |
