アダプティブトランスコーディング: それは何ですか? トランスコーディング セマンティックバリエーションのタイプ

トランスコーディングとは、ある方法でエンコードされたファイルを別の方法で変換することを意味します。 トランスコーディングは、可逆から可逆へ、可逆から非可逆へ、非可逆から非可逆へ、また非可逆から可逆へ行うことができます。

トランスコーディングには、foobar2000 などのコンバーターが使用されます。

非可逆 -> 非可逆

非可逆エンコーダによってエンコードが行われるたびに、品質が低下します。 また、128 kbps MP3 を 320 kbps MP3 (またはその他の高品質フォーマット) にエンコードしたとしても、品質を取り戻す方法はありません。

このため、非可逆形式間でのトランスコーディングはあまりお勧めできません。 結果として得られるファイルの品質は、ソース ファイルの品質よりも悪くなります。 ただし、このような操作が行われる理由としては次のことが考えられます。

  • ビットレートを下げるか、ポータブル プレーヤーで使用するために別の形式に変換します。この場合、品質はそれほど心配されない可能性があります。
  • ハードディスクのスペースを節約します。 オーディオ CD の非圧縮データのビットレートは 1411 kbps (605 MB/時間) です。 ロスレス エンコーダを使用すると、ストリームを平均 700 kbit/s (300 MB/時間) に削減できます。 Vorbis、MPC、AAC などの非可逆エンコーダは通常、150 ~ 170 kbps (69 MB/時間) の範囲のビットレートで透明なサウンドを提供します。 MP3 (LAME を使用している場合) の場合、通常、最大 192 kbps (82 MB/時間) のビットレートで透明度が実現されます。 このような場合、大規模な音楽コレクションの場合、可逆圧縮に比べて大幅な節約が可能になります。

ロスレス -> ロスレス

前述の非可逆トランスコーディングとは異なり、この場合、品質は 迷わない。 このようにして、必要なだけ、あるロスレス形式から別の形式に変換できます (たとえば、圧縮率を高めたり、特定のプログラム/デバイスとの互換性を確保したりするため)。

ロスレス -> ロッシー

音楽をロスレスでアーカイブすると、音楽をさらに別の非可逆形式にトランスコードする可能性が保たれます (たとえば、エンコーダの新しいバージョンの場合)。 たとえば、現時点で非可逆フォーマット X が 192 kbps で透過的であり、3 年後には 128 kbps で透過的なフォーマット Y が登場する場合、この場合、X@192 kbps から Y@128 kbps へのトランスコードは可能性が低いです。可逆エンコードとは異なり、許容可能な結果が得られます。 これは、フォーマット X の場合、非可逆エンコードであるため、重要ではないと考えられる一部の情報が削除される一方で、Y エンコーダの意見では、それが重要である可能性があるためです。 その結果、Y のエンコードは大幅に歪みます。

可逆ソースから非可逆にエンコードしている場合は、これを強くお勧めします。 元のロスレスファイルを保存します。 この場合、エンコード結果が満足できない場合は、素材を再エンコードできます。

注意: 一部のコンバータには、ソース ファイルを自動削除するオプションがあります。 無効になっていることを確認してください。

非可逆 -> 可逆

非常に多くの人は、非可逆から可逆にトランスコードする (たとえば、MP3 から FLAC) ことでオーディオ品質を向上できると考えています。 実際、非可逆から可逆への変換は不合理です。なぜなら、素材が非可逆エンコードされると、定義上、損失はすでに発生しており、元に戻すことはできないからです。 したがって、非可逆ファイルから可逆ファイルに変換することはできますが (ちなみに、これは非可逆ファイルの再生中に行われます)、サウンドは変化しません。つまり、実際には、ストレージ形式が変更されるだけです。

このような変換を行う必要がある場合は、ファイル名 (およびできればタグ) で非可逆元の元のファイルを指定して、そのファイルを使用した人がそのファイルがオリジナル (可逆変換) からのものではないことがすぐにわかるようにする必要があります。 ) ソース 。

可逆トランスコーディングから非可逆トランスコーディングが使用されるのはどのような場合ですか:

  1. ソースが古い形式または独自の非可逆形式であるオーディオを、品質を損なうことなくアーカイブします。
  2. 直接変更できないオーディオを非可逆として編集します。
  3. 非可逆 -> 非可逆エンコーディングの中間形式として。

オリジナルのロスレスとして偽装されたコンテンツを取り除くために、ファイル共有サービスのユーザーや管理者はスペクトル分析や特別なプログラムを使用することがよくあります。 これらの方法は、CD の購入者が、素材の作成および配布中に非可逆エンコードが実行されたかどうかを判断するためにも使用されます (これは、場合によっては実行されます)。

スポンサーからのお知らせ

Remeshkov.ru: 時計ストラップのオンラインストア。 ここでは、世界の一流メーカー(ロンジン、オメガ、コルムなど)の時計ストラップを購入できます。 時計ベルトの測り方については、お店のウェブサイトでもご覧いただけます。



IP カメラのメーカーによって、サポートされるビデオ圧縮プロセスが異なります。 通常、これらのプロセスは CCTV プロジェクトの要件と部分的にのみ一致します。 ユーザーがビデオに移行すると、機能、柔軟性、快適さの点で欠点を感じ始めます。 唯一の例外は、CCTV システム用に特別に変更された圧縮プロセスです。

カメラの内蔵ビデオ圧縮機能のパラメータはトランスコーディングには影響しないため、カメラの圧縮形式を要件に最も適した他の形式に変換できます。 変更された形式の例には、CCTV ユーザー向けに最適化されているだけでなく、よく知られた標準に準拠する特別なコーデックが含まれます。

トランスコーディング テクノロジの使用に関する議論には次のようなものがあります。

  • 異なるメーカーのカメラを組み合わせる場合 CCTV システムの機能的均質化。 カメラメーカー間の違いにもかかわらず、すべてのトランスコーダー機能が利用可能です。
  • 統合可能性の有無トランスコーダへの画像処理。
  • 関数の使用たとえば、ストリーム解像度をオペレータのモニター ウィンドウのサイズに自動的に一致させる、リアルタイムでのストリーミング動的データ送信 (DLS) です。 これにより、多チャンネルデータ放送のリアルタイム使用帯域を大幅に削減することが可能となります。


まとめ

IP カメラでは論理情報ソリューションがますます登場していますが、トランスコーディング技術の開発はまったく異なる方向に進んでいます。 同時に、カメラは今日、高品質の画像のソースとしても考えられています。 年々、カメラにおける論理機能や情報機能の必要性はますます低くなり、その統合は簡素化され、機能は均一になってきています。 多数の一般的な CCTV 問題に対処する場合、トランスコーディングの分野における集中ビュー アプローチは、個々のカメラの特性によって決まる分散ビュー アプローチよりも多くの利点があります。 この点は、数百のチャネルを持つ大規模システムの場合に特に重要です。

トランスコーディングは万能薬ではありません。 システムの特別な要件に基づいて、その形式と実現可能性、機能上の利点、および必要なコスト削減を決定することができます。 トランスコーディング技術を使用すると、カメラ自体の機能よりも効果的にいくつかの問題を解決できます。 逆に、他の問題はカメラの機能を使用することで解決するのが容易であり、これは分散型論理情報機能の有効性を示しています。 実際、集中型と分散型の論理情報機能の間に矛盾はなく、それぞれが独自の領域で効果的です。

衛星からは、ビデオが MPEG-2 コーデックまたは H.264 (別名 AVC または MPEG-4 Part10) で送信されます。 原則として、簡単にするために、MPEG-4 パート 10 は MPEG-4 と短縮されますが、ここでは、MPEG-4 パート 2 と混同しないことが重要です。MPEG-4 パート 2 は完全に互換性がなく、H.264 にも似ておらず、H.264 で使用されていました。古いIPカメラ。

オーディオは、MPEG オーディオ レイヤ 2 (略称 mp2) または ac3 (a/52) で送信されます。

さらに、現在、H264 は通常、イントラリフレッシュで圧縮されていることを理解することが重要です。 ビデオ ストリームには参照フレーム (IDR またはキーフレーム) がありません。 この圧縮方法を使用すると、ビットレートのジャンプを滑らかにすることができます。

その結果、衛星から送信されたオーディオまたはビデオのオプションはいずれも iPhone では再生されません。 ブラウザではH264のみ再生されます。

インターネット経由で送信する場合、原則として、トラフィックを 3 分の 1 に削減してビデオを mpeg2 から h264 に安全に圧縮できます。

現在、インターネット経由で HD チャネルを送信する場合、ストリームをいくつかの異なる品質に圧縮する必要があります。最高品質の HD から、過負荷のチャネルを補う標準 SD までです。

その結果、高品質の OTT サービスを提供するには、衛星からのビデオを他のコーデックおよび品質にトランスコードする必要があります。

トランスコーディングと再パッケージ化を混同しないことが重要です。 トランスコーディングは、次のような非常にリソースを大量に消費する操作です。

  • ストリームをエンコードされたビデオ/オーディオに解凍する
  • 生のビデオ/オーディオへのデコード
  • サイズやその他のパラメータを変更する
  • エンコードバック
  • 輸送用に梱包して流通させる

パックとアンパックは比較的簡単な操作で、ストリーミング サーバーは 1 台のコンピュータで最大 1000 チャンネルを処理できます。 コンピュータのサイズと能力に応じて、1 台のコンピュータで 1 ~ 30 チャンネルまでトランスコードできます。

トランスコーディングには、外部またはプロセッサに内蔵された、特殊な専用デバイス、中央プロセッサまたはビデオ カードを使用できます。

特殊なデバイスは、ほとんどの場合、ある種のプログラムを備えたコンピュータか、非常に高価で非常に特殊な機器、または単に不当に高価なデバイスであり、メーカーの会社のマーケティング活動によって独占的に販売されており、販売されていないためです。可能な限り多くの、または重要な結果を達成できるようにします。

H.264

CPU でビデオを処理するためのプログラムはいくつかありますが、概して、現在、CPU で H.264 コーデックへの圧縮に使用するのに適したライブラリは、無料の libx264 と有料の MainConcept の 2 つだけです。 それ以外の場合は、出力結果とリソースの使用の両方の点で、悪いか、はるかに悪いかのどちらかです。

MainConcept を使用する方法については、この記事では考慮しません。libx264 についてのみ説明します。

H.264 コーデックは、一部の Google デバイスを除くすべての最新のデバイスでサポートされているため、今日のビデオの事実上の標準となっています。

それに代わるものは事実上ありません。 現在、H.265 が登場し、開発が進められており、すでに大きなサポートを受けていますが、今のところ、H.265 を扱うことは将来への投資です。

Google のコーデック: VP8 と VP9 は、本当に役立つものというよりは、Google が自らの覆いを覆したいという願望に基づいています。 結果として品質が低下し、ハードウェア デコードがサポートされないため、デバイスの価格が上昇します。

ビデオをエンコードするときは、次のパラメータの間でバランスを取る必要があることを理解する必要があります。

  • エンコーダ内のフレーム単位の遅延
  • CPU使用率(1フレームの圧縮にかかる時間(ミリ秒))
  • 出力画質 (ピクセル化の程度と色)
  • 出力ビットレート

あらゆるタイプのブロードキャストにとって、CPU 使用率は非常に重要です。 エンコーダ設定で CPU のフル負荷以上が必要な場合、ビデオをリアルタイムでエンコードする時間がなくなり、ビデオ ストリーミングが失われます。

VOD の場合、そのような厳しい制限はなく、ビットレートを下げたければ、1 時間の映画を 3 時間エンコードできます。 同時に、ブロードキャスト ビデオの場合、通常は、1 台のコンピュータで 4 チャネルではなく 10 チャネルを処理するために、プロセッサの能力をすべて使用するわけではありません。

エンコーダ内の遅延に関しては、ビデオ会議では重要ですが、IPTV ではまったく重要ではありません。 テレビ放送時に 5 秒の遅延があっても、サービスの品質は変わりません。

ビットレートと品質の関係は非常に明確です。送信する画像に関する情報が多ければ多いほど、より良く表示されます。 通常、より多くの遅延とより多くのクロック サイクルを必要とするより効率的な圧縮ツールを選択し、ビットレートを下げることで画質を向上させることができます。

「当社のエンコーダは世界最高のエンコーダである」という保証をよりよく理解するには、この複雑な関係を理解することが必要です。 少なくとも 4 つのパラメータで比較する必要がありますが、最終的には、1 つのチャンネルを希望の品質と出力ビットレートでトランスコードするのに 1 回あたり、および 1 か月あたりどれくらいの費用がかかるかということになります。

トランスコーディング用の Flussonic メディア サーバー

トランスコーダーは、Flussonic Media Server の別個のパッケージとして含まれています。

Flussonic Media Server は、UDP/HTTP MPEG-TS、RTMP ソースからビデオをデコードし、いくつかの品質とサイズでエンコードできます。

この機能は、セットトップ ボックスだけでなくタブレットでもビデオを表示する必要がある場合に必要になります。そこでは、利用可能なコーデックの選択肢がセットトップ ボックスよりも大幅に少なくなります。

iPhone でビデオを再生するには、衛星からの H264 をトランスコードする必要があることに注意することが重要です。これは、通常、衛星はスムーズなビットレートを実現するためにイントラリフレッシュ エンコード モードを使用し、ビデオを作成するためです。 iPhoneでは再生されません。

Flussonic Media Server は、1 つの構成ファイルによって制御され、トランスコーディングのステータスを自動的に監視するため、トランスコーディングを整理する場合、VLC やその他のオプションよりも便利です。 VLC では、トランスコーディング ステータスを監視するために大量の監視スクリプトを作成する必要があります。

Flussonic Media Server のトランスコーディング用の次の重要な機能は、サーバーの 1 つに障害が発生した場合のストリームの自動再バランスです。 20 台のトランスコーダーのうち 1 台が夜間に故障した場合、残りのトランスコーダーはトランスコーディング用のストリームを自動的にキャプチャするように設定でき、ストリーマー自体はバックアップ トランスコーダーからストリームを取得します。

米。 2 マルチチャンネルストリーミングによる個別ストリームの特徴

解凍と圧縮はコンピューターのパフォーマンスに厳しい要求を課し、多数のチャネルによってその要求が増大しますが、ほんの数年前には異例だったデータ処理機能が、現在では最新のハードウェアで手頃な価格で利用できるようになりました。 さらに、専用の CCTV エンコーダはトランスコーディング プロセスのオーバーヘッドを削減し、トランスコーディング ハードウェアの追加コストがストレージと伝送コストの節約、および安価なカメラの使用によって相殺されるため、実用的かつコスト効率が高くなります。

トランスコーディングの利点
カメラ ビデオ ストリームを直接使用してトランスコーディングするとどのようなメリットがありますか? トランスコーディングが適切な場合とそうでない場合は何ですか? いくつかの問題を詳しく見てみましょう。

JPEG IP カメラの使用
Motion-JPEG圧縮技術を用いたIPカメラは現在でも広く普及しており、低価格で高画質なカメラも数多く存在します。 ただし、このようなモデルのアキレス腱は、JPEG 圧縮プロセスの効率が比較的低いことです。 H.264 などの最新のプロセスと比較して、このようなカメラは何倍ものデータを生成するため、データの保存と送信のコストが 4 倍以上増加します。
ただし、トランスコーディング プロセスを使用して JPEG を H.264 などに変換すると、H.264 画像を直接生成するカメラと同じコストで JPEG カメラを CCTV システムで使用できます。 カメラのコストが低いため、トランスコーディング用のハードウェアを購入するコストが相殺されます。 H.264 へのトランスコーディングは、ストレージ要件を直接的に削減しますが、逆の見方をすると、録画時間も同様に長くなります。 この場合、効率向上係数は 4 以上になります。

自由に可変のマルチチャンネルストリーミング
CCTV システムのユーザーが異なれば、必要なビデオ特性も異なります。 リアルタイムの視聴と録画のために、誰もが独立したチャンネルを必要としています。 経済的な理由から、イベントがないときはチャネルは低フレーム レートと低画質で動作することがよくありますが、イベントが発生すると両方とも自動的に増加します。 ただし、リアルタイム ブロードキャストには明らかに高フレーム レートのビデオが必要です。 この目的の矛盾を妥協することなく解決するには、元の画像を同じカメラからの 2 番目の独立したビデオ フィードから分離する必要があります。 多くのカメラが少なくとも 2 つのチャネルで画像ストリーミングをサポートできるのはこのためです。 ただし、計算上の制限により、2 つのスレッドの相互依存が生じます。 その結果、ユーザーはデュアル チャネル モードで低いフレーム レートを受信するか、このオプションは高いカメラ解像度では使用できません。 ハイエンドのデュアルチャネル機能を備えたハイエンドのカメラでも、2 つ以上のストリームが必要になると限界に達します (図 2)。
トランスコーディング テクノロジを使用すると、カメラのタイプに関係なく、カメラ チャネルごとに自由に可変の数のビデオ チャネルを作成できます。 これにより、意図した用途に応じた理想的な画像パラメータが保証されます。

柔軟で遅延のないデータ フロー制御
多くの IP カメラは、ビデオ ストリームのプロパティを変更する機能が非常に限られています。 したがって、解像度、品質、およびフレーム レートは、数回の大幅な増分でしか調整できません。 さらに、品質パラメータ モードの切り替えには 1 秒以上の長い時間がかかることがよくあります。 このような場合、イベント発生時の画質やフレームレートを向上させても、実際のアラームから画質が変化するまでに時間がかかりすぎ、重要な情報のかなりの部分が失われるため、あまり意味がありません。 この問題は、システムを常に高画質で実行することで解決できる場合がありますが、これはコストの増加につながる必要はありません。
トランスコーディングでは、カメラに関係なく、小さな調整ステップで結果のビデオ画像を調整できるすべてのパラメータが有効になります。 トランスコーダを最適に調整すると、切り替えにかかる時間を最小限に抑えることができます。 これにより、上記の警報状況においても遅延なく高画質を確保することができる(図3)。

ビデオのトランスコーディングの必要性

現在、デジタル ビデオ圧縮テクノロジは、ほぼすべての種類のビデオ アプリケーションで重要です。 通信メディアの収束傾向が強まっているため、データ圧縮や相互運用性などのパラメータの重要性はさらに高まっています。
デジタル ビデオの最も著名な用途には、DVD、高品位テレビ (HDTV)、ビデオ電話/テレビ会議、そして最近ではビデオ監視などがあります。 これらのテクノロジーにはそれぞれ独自の開発の歴史があるため、それぞれに独自の圧縮アルゴリズムがあります。
トランスコーディングは 2 つの重要な役割を果たします。 まず、既存のデバイスと新しいデバイスの間の通信が可能になります。 たとえば、既存のビデオ会議システムの多くは、H.263 ビデオ エンコード規格に基づいています。 新しいビデオ会議システムは、基本的な H.264/AVC プロファイルを使用します。 したがって、これらのシステム間の通信を可能にするには、リアルタイム ビデオ コード変換が必要です。 第二に、情報ネットワーク、特にインターネットのビデオ伝送容量には限界があります。 したがって、現在、ほとんどのビデオは MPEG2 形式で DVD ディスクに保存されています。 ビデオ オン デマンド サービスや IP ネットワーク経由のビデオ ストリーミングでは帯域幅の制限があるため、このビデオ データをより圧縮された形式に変換する必要があります。 これは、送信前にビデオをリアルタイムでトランスコードすることによって実現されます。 一般に、トランスコーディングにより、ビデオ品質を損なうことなくネットワーク帯域幅の最大 50% が解放されます。
ビデオ会議でのトランスコーディング

したがって、トランスコーディングのアプリケーションの 1 つはビデオ会議システムです。 このようなシステムで使用される典型的なトランスコーディング方式を考えてみましょう (図 1)。 1 つの DSP (DSP2) は入力ビデオ ストリームをデコードし、再構成されたビデオ フレームを生成します。これは Serial RapidIO インターフェイス (sRIO) 経由で別の DSP (この例では DSP1) に送信されます。 DSP1 は、再構築されたビデオ フレームを必要な形式にエンコードします。 通常、ビデオ会議の一方の側では H.263 ベースの機器が使用され、もう一方の側では H.264 ベースの機器が使用されます。
ネットワーク トラフィックを管理するホスト プロセッサは、PCI バス接続を通じて複数のデジタル シグナル プロセッサ (この場合は 4 つ) と通信します。
この例におけるプロセッサ間の対話の主な特徴は、sRIO インターフェイスを介した接続です。 DSP 間で転送されるデータは非圧縮ビデオであり、通常は 30 フレーム/秒であるため、デバイス間の通信リンクの帯域幅要件は非常に高くなります。
標準の NTSC 解像度 (720 x 480 ピクセル) YUV 4:2:0 でビデオを撮影した場合、各フレームのサイズは 720 × 480 × 1.5 = 518400 バイトになります。 したがって、毎秒 30 フレームの周波数では、ライン スループットは約 124 Mbit/s になるはずです。
sRIO インターフェイスの選択は、ビデオ データ転送速度と柔軟なスイッチング構造のサポートの要件によって決まります。 sRIO は、1.24 Gbps、2.5 Gbps、3.125 Gbps の 3 つのデータ レートをサポートします。 このインターフェイスは、SerDes テクノロジーを使用してデータ ストリームへのクロック同期を復元し、8-b/10-b エンコーディングを使用します。 このシリアル インターフェイス仕様は、単線 (1X) ポートと 4 線 (4X) ポートをサポートします。 sRIO インターフェイスの物理層は、デバイス間の通信を確立するときに使用されるハンドシェイク メカニズムと、巡回冗長コードに基づくエラー検出手順を定義します。 インターフェイスの物理層は、スイッチング マトリックス内のルーティングに使用されるパケットの優先順位も設定します。
sRIO のスループットを最大限に活用するには、プロセッサにこれらのインターフェイスが必要です。 このようなプロセッサは、Texas Instruments によって提供されています。 たとえば、TMS320C6455 信号プロセッサには、4 つの同時接続と 20 Gbps のピーク往復データ レートを提供する sRIO インターフェイスが組み込まれています。
プロセッサー TMS320C6455

sRIO インターフェイスに加えて、C6455 プロセッサには、理想的なトランスコーディング デバイスにする重要な機能が追加されています。 これらの機能特徴は 4 つの主要なブロックに組み合わせることができます。
多数の高速 I/O インターフェイスを利用可能。 システム設計者はさまざまなソリューションを使用するため、ビデオ処理アプリケーション用のデジタル信号プロセッサは、システム モジュールをボード レベルで接続するための I/O ポートを提供する必要があります。 前述したように、C6455 にはデバイス間通信用の sRIO ポートが組み込まれています。
C6455 のその他の I/O オプションには、1 Gbps イーサネット メディア アクセス コントローラ (EMAC)、32 ビット デュアル データ レート メモリ コントローラ (DDR2-500)、周辺デバイスを接続するための 66 MHz メモリ コントローラ バスなどがあります。 (PCI)。 内蔵 ATM インターフェイス (UTOPIA 2) により、C6455 プロセッサを通信インフラストラクチャで使用できます。
チップ内でデータを効率的に移動します。 効率的なデータ移動のためのシングルチップ アーキテクチャは、以前のプロセッサと比較した C6455 プロセッサの主な利点の 1 つです。 ビデオ処理アプリケーションでは、デジタル信号プロセッサはホスト プロセッサに対するスレーブ デバイスとして機能します。 したがって、高スループット、低遅延、およびマスターとスレーブ間でデータを並行して転送する機能が重要です。 これらの要件によってデバイスのアーキテクチャが決まりました。周辺デバイス、内部メモリ、プロセッサ コアは、C6455 プロセッサの効率的なスイッチド セントラル リソース (SCR) を通じて相互に通信します。
データフローを最適に構成することも重要です。 これは、256 ビット メモリ バスと内部ダイレクト メモリ アクセス (IDMA) の使用によって改善されました。 IDMA を使用すると、ペリフェラル バスとの間でだけでなく、内部メモリの 2 つのレベル間でデータをバックグラウンドで移動できるようになります。
大容量のオンチップメモリ​​。 オンチップのスタティック SRAM は、ダイナミック オフチップ SDRAM よりもはるかに高速ですが、製造コストが高いため、その容量ははるかに小さくなります。 一般的なビデオ アプリケーションの場合、オンチップ メモリは主に 2 つの目的を果たします。1) 頻繁に使用されるコードとデータを保存し、2) 処理の前後に一時データをロード/アンロードします。 通常、利用可能なオンチップ メモリの量が多いほど、アプリケーションのパフォーマンスは向上します。 C6455 デジタル シグナル プロセッサには、なんと 2 メガバイトのスタティック RAM が搭載されています。
ソフトウェアの互換性。 多くのビデオ アプリケーション プログラムは、トランスコーディングが広く使用されるずっと前に開発されているため、ソフトウェアの下位互換性は重要です。 新しいプロセッサで既存のソフトウェアを使用するには、命令セットを変更するのではなく、プロセッサ コア アーキテクチャを変更することによって DSP のパフォーマンスを向上させることをお勧めします。 C6455 プロセッサは、2 つのアーキテクチャ上の革新を備えています。 1 つ目は循環バッファーの導入に関連しており、短いサイクルでコードを処理するためのソフトウェア パイプラインの効率が向上する可能性があります。 2 つ目は、元の 32 ビット命令の 16 ビット バージョンを使用することです。これにより、プログラム コードのサイズが大幅に削減され、キャッシュ メモリにアクセスする際の「ミス」の割合が減少します。
トランスコーディングシステムのプロトタイプ

トランスコーディングは、企業のトレーニング システム、ビデオ オン デマンド アプリケーション、ビデオ ブロードキャストなどで、IP ネットワーク経由で DVD からデータを転送する場合にも必要です。 この場合、ソースビデオ形式はMPEG2で、ターゲット形式は主にWMV9です。 デジタル シグナル プロセッサのプログラム可能性により、ソース/ターゲット ビデオ形式のほぼすべての組み合わせを簡単にサポートできることに注意してください。
ビデオ データをトランスコードするには、フォーマット変換、ビデオ ストリームのビットレートの低下、時間的および空間的解像度の低下など、多くの技術的問題を解決する必要があります。 したがって、さまざまなインテリジェントビデオトランスコーディングスキームが開発されています。 その主な原則は、入力ビデオ ストリームに含まれる情報を最大限に再利用することです。
このセクションでは、柔軟なハードウェア/ソフトウェア インフラストラクチャに基づくアーキテクチャを使用して、あらゆるトランスコーディング スキームに適したプロトタイプのビデオ トランスコーディング システムについて説明します。 さまざまなターゲット ビデオ トランスコーディング シナリオを満たすために、ビデオ ストリームが完全にデコードされてから、新しい制約に従って再エンコードされる最も単純なトランスコーディング スキームが選択されます。
システムのデータ フローは、ハード ドライブに保存された MPEG2 圧縮ビデオ ファイルから図の左側 (図 2) で始まり、Windows Media Player によってビデオが再生されるフラット パネル ディスプレイで終わります。 このデモでは、ビデオは標準 NTSC 解像度 (720 x 480 ピクセル) で、1 秒あたり 30 フレームでトランスコードされます。
DSP1 上で実行されるストリーム レシーバ モジュールは、MPEG2 ストリームをバッファリングし、MPEG2 デコーダ モジュール用の入力データを編成します。 取り込み操作は、本質的に TCP/IP スタックである TI のネットワーク開発キット (NDK) を使用して制御されます。 DSP2 プロセッサ上で実行される ASF パケット形成モジュールは、WMV9 モジュールで圧縮されたデータから ASF フォーマットのパケットを生成します。 DSP2 には、Windows Media Player からのストリーム要求を処理し、ASF パケットを送信する NDK ベースの http サーバーも含まれています。 Windows Media Player は ASF パケットをデコードし、画面にビデオを表示します。
データ伝送の最も興味深く複雑な側面の 1 つは、sRIO インターフェイスを介した 2 つのデジタル シグナル プロセッサの相互作用です。 各ビデオ フレームが送信されると、次のことが発生します。 DSP1 はビデオ フレームの送信を完了した後、sRIO プロトコル仕様では DOORBELL と呼ばれるデータ パケットを送信します。 DOORBELL パケットは、DSP2 プロセッサでシステム割り込みを生成し、フレームの存在を通知します。 これに応答して、DSP2 は WMV9 形式へのエンコード プロセスを開始します。 フレームのエンコードが完了すると、DSP2 は DOORBELL パケットを DSP1 に送信します。 この場合、DSP1 で次のフレームの送信を継続する準備ができていることを示す割り込みが DSP1 で生成されます。 実際には、スイッチング バッファ方式が使用され、エンコード/デコードとデータ転送操作が並行して実行されます。
グラフィカル ユーザー インターフェイス (GUI) ブロックは、システムに組み込まれた制御および監視機能を提供します。 sRIO リンクとギガビット MAC (GMAC) リンクのアクティビティがリアルタイムで表示されます。 通信チャネル上で MPEG-2 データ ストリームを送信する場合、平均転送速度は 8 Mbit/s で、これは標準解像度で 30 フレーム/秒の周波数でエンコードする場合に一般的です。 通信チャネル上で ASF パケットを送信する場合、平均送信速度は 4 Mbit/s です。 これは、WMV9 形式が同様のビデオ品質を提供しながら、帯域幅の約 50% を解放できることを示しています。 sRIO インターフェイスを備えた通信チャネルの場合、平均データ転送速度は 124 Mbit/s です。

したがって、sRIO インターフェイスと組み合わせた TI の C6455 デジタル シグナル プロセッサの機能と、C6455 プロセッサに基づく前述のプロトタイプのトランスコーディング システムのデモンストレーションは、IP ネットワーク経由でビデオを送信するという複雑なタスクを現在、両方とも首尾よく解決できることを示しています。そして将来的には。