マルチメディア シングス プレーヤーが、より適切なオーディオおよびビデオ プレーヤーの選び方について語ります

序文

近年、HTML5 技術の普及、モバイル デバイスの急速な成長、トラフィック料金の継続的な低下により、ビデオは人々が世界を理解し、知識を獲得するための主な方法の 1 つになりました。最近ではオーディオ プレーヤーやビデオ プレーヤーはどこにでもありますが、このプロセスは具体的にどのように実現されるのでしょうか?プレイヤーの原則は何ですか?あるいはプロデューサーとして、自分に合ったプレーヤーを選ぶにはどのような基準を使うべきでしょうか? UCloud は、長年の実践経験に基づいて、お客様に適した回答や提案を提供します。

1. プレーヤーの機能アーキテクチャ

まず、通常のプレーヤーの機能アーキテクチャを見てみましょう。

（図：従来のプレーヤー構成図）

アプリケーション層: UI/統計/DRM(デジタル著作権保護)/マルチビットレート/バレットスクリーン/広告など。

最下層:データ受信モジュール/多重化モジュール/オーディオおよびビデオのデコード、フィルター、レンダリング モジュール/字幕/アプリケーション層の複合機能: DRM、マルチビットレート/統計など。

プレーヤーには多くの機能があるため、この記事では一つ一つ詳しく説明することはしません。以下では、マルチメディア エンジン モジュールに焦点を当てます。

2. マルチメディアエンジン

プレーヤーの中核部分であるマルチメディア エンジンは、主にオーディオおよびビデオ データの読み込み、処理、表示を担当します。 FFmpeg を例にとると、その基本的な操作プロセスは次の図のようになります。

（図：マルチメディア再生フローチャート）

各ステップを詳しく見てみましょう。

1. データ受信（出典）

データ入力として、ここでのファイルは、ローカル ファイル (File:// プロトコルで始まる) またはネットワーク プロトコル (HTTP、RTMP、RTSP など) を介して入力できます。対応する伝送プロトコルを見つけた後、FFmpeg はプロトコルの特性に応じてローカル マシンまたはサーバーとの接続を確立し、ストリーミング データを取得します。

2. 多重分離（Demux）

ファイルの署名を分析すると、一般的な MP4、FLV、TS、AVI などのファイルのパッケージ形式がわかります。カプセル化形式の標準に従って解凍すると、エンコードされたオーディオおよびビデオ データを取得できます。これは一般に「パケット」と呼ばれます。

3. デコード

デコーダーが初期化されると、以前のソース データ分析から取得されたオーディオ情報とビデオ情報を使用して、それぞれ対応するオーディオ デコーダーとビデオ デコーダーが設定されます。現在、インターネット上で最も一般的なオーディオエンコード方式は AAC (Advanced Audio Coding) と MP3 であり、ビデオエンコード方式は H.264 と H.265 です。パケットを個別にデコードした後、オーディオデコードによって得られたデータは、PCM（パルスコード変調）サンプリングデータであり、一般的に「サンプル」と呼ばれます。ビデオのデコードによって得られるデータは、YUV または RGB 画像データであり、一般に「ピクチャ」と呼ばれます。

4. オーディオとビデオの同期

オーディオとビデオのデコードは 2 つの独立したスレッドであるため、取得されるオーディオ データとビデオ データは別々であり、接続はありません。理想的には、オーディオとビデオの同期は、それぞれの固有の周波数に従ってレンダリングおよび出力することで実現できます。しかし、現実には、ネットワークの切断、ネットワークの弱さ、フレームの損失、バッファリング、オーディオとビデオのデコード時間の違いなどにより同期が妨げられ、望ましい効果を得ることが難しくなります。したがって、ビデオ コンテンツとオーディオ コンテンツが一致するようにするには、オーディオとビデオの同期を実行する必要があります。

5. オーディオとビデオのレンダリング（レンダリング）

オーディオとビデオの同期を調整した後、サンプルと画像をそれぞれサウンド カードとグラフィック カードに送信する必要があります。この部分の作業は、成熟したライブラリによって完了することが推奨されます。一般的なオーディオ ライブラリには、SDL、OpenAL/OpenAL ES、DirectSound、ALSA (Advanced Linux Sound Architecture)、OSS (Open Source System) などがあります。ビデオ ライブラリには、SDL、OpenGL/OpenGL ES、DirectDraw、FrameBuffer などが含まれます。

上記の 5 つの手順を実行すると、基本的な再生プロセスが完了します。

3. 各プラットフォームのビデオ技術の概要

すべてのプラットフォームをカバーするプレーヤーを実現するには、当然ながら技術サポートが不可欠です。この記事では、主に Web、Android、iOS 上のオーディオおよびビデオ テクノロジについて説明し、一般的なオーディオおよびビデオ ソリューションについて説明します。

1. Web-HTML5

技術言語: JavaScript、HTML/CSS

利用環境： HTML5 Videoタグをサポートするすべての端末ブラウザ（PC Windows/Mac/Linux/Unix、Android、iOS）で動画を再生できます。現在のカバー率は95%に達しています。

（図：ビデオ要素の範囲）

関連プログラム:

1.1 タグ

コード例から、HTML5 ビデオ タグは非常にシンプルで使いやすいことがわかります。 controls="controls" では、ブラウザのデフォルトのプレーヤー UI を使用できます (ブラウザによって UI は異なります)。コントロールに値が割り当てられていない場合は、CSS およびビデオ メッセージを通じてカスタム UI とコントロールを実装できます。

1.2 MSE(メディアソース拡張)

Media Source Extensions (MSE) は、主要なブラウザでサポートされている新しい Web API であり、JavaScript でメディアを動的に構築およびストリーミングできるようにする W3C 標準です。 JavaScript がメディア ストリーム フラグメントを HTMLMediaElement に渡すことを可能にするオブジェクトを定義します。

MSE を使用すると、プラグインを必要とせずにメディア ストリームを動的に変更できます。これにより、フロントエンド JavaScript で、JavaScript でのトランスパッケージ、処理、さらにはトランスコーディングなど、より多くの処理を実行できるようになります。そのため、ABR（Adaptive Bitrate）、hls.js、dash.js、flv.jsもこれをベースに実装されています。

MSE はストリームをメディア タグに直接送信することはできませんが、クロスブラウザ プレーヤーを構築するためのコア テクノロジを提供し、ブラウザが JavaScript API を通じてオーディオとビデオをメディア タグにプッシュできるようにします。現在、MSEのカバー率は77.93%に達しています。

（図：MSEカバレッジ）

2. ウェブフラッシュ

技術用語: ActionStript

使用環境: Flash Player がインストールされたブラウザであれば、どのブラウザでもビデオを再生できます (PC Windows/Mac/Linux/Unix、Android、iOS)。インターネットの黎明期にリッチメディアのリーダーであったWeb-Flashは、HTML5の普及により徐々に人々の目から消えていきました。現在では、HTML5 プレーヤーを補完するソリューションとして使用されることが多くなっています。

関連プログラム:

2.1 FLV再生

Flash には、HTML5 ブラウザのデフォルト プレーヤーに似たパッケージ化されたプレーヤーが付属しています。選択可能なプレーヤー UI スタイルがいくつか提供されます。ほんの数行のコードで美しいプレーヤーを素早く構築できますが、柔軟性は低くなります。

2.2 ネットストリーム

Flash はマルチメディアを処理するためのコア クラスです。 HTML5 の MSE と同様に、FLV カプセル化形式の外部データを再生できる appendbytes API を提供します。同様に、このインターフェイスを使用して、ビデオのトランスパッケージ、処理、トランスコーディングなどの操作を実装でき、RTMFP プロトコルと組み合わせることで、P2P ビデオの伝送と再生も実現できます。

2.3 クロスブリッジとFFmpeg

かつて、Flash には CrossBridge (Alchemy、Flascc とも呼ばれる) と呼ばれるブラック テクノロジーがあり、これを使用すると、独自に記述した C/C++ コードを Flash の指定範囲内で実行できるため、コンピューティング効率が大幅に向上しました。 FFmpeg のマルチメディア処理機能と組み合わせると、予期しない結果が生じる可能性があります。

3. アンドロイド

技術言語: Java、JNI (C/C++)

使用環境: Android システム (Android フォン、Android パッド、Android TV、Android Box など)。

関連プログラム:

3.1 メディアプレーヤー

Android が提供するデフォルトのマルチメディア プレーヤーを使用すると、オーディオおよびビデオ データをローカルまたはネットワーク上で再生できます。主にプロトコルのデコードを担当しますが、表示部分は含まれません。表示部分はSurfaceViewやSurfaceTextureと連動して処理する必要があります。

3.2 MeidaCodec (API 16+、Jelly Bean 4.1.x)

Android が提供するハード コーデック クラスは、主にオーディオおよびビデオ データのエンコードまたはデコードに Android 4.1 (API16) で初めて使用されました。 Android 4.3 (API18) では、MediaCodec が拡張され、Surface を介して入力を提供するメソッド (createInputSurface) が追加されました。これにより、入力をカメラ プレビューから取得したり、OpenGL ES を介してレンダリングしたりできるようになりました。

3.3 JNIとFFmpeg

JNI は Java Native Interface の略です。もともとネイティブコンパイル言語、特に C および C++ 向けに設計されましたが、呼び出し規約がサポートされている限り、他のプログラミング言語の使用を妨げるものではありません。 Java を使用してネイティブ コンパイルされたコードと対話すると、通常はプラットフォームの移植性が失われますが、これが許容される場合や必要な場合もあります。たとえば、古いライブラリを使用してハードウェアやオペレーティング システムと対話したり、プログラムのパフォーマンスを向上させたりします。 JNI を強力なエンジン FFmpeg と組み合わせることで、Android プラットフォームのマルチメディア処理機能が向上します。

4. iOS

• 技術言語: Objective C、C/C++、Swift
• 使用環境： iOSシステム（iPhone、iPad）

関連プログラム:

4.1 AVFoundation.framework: AVPlayer、AVPlayerLayer

AVPlayer クラスには、オーディオとビデオのデータ受信、デコード、処理のみが含まれており、表示部分は含まれていません。 AVPlayerLayer と組み合わせて使用​​する必要があります。カスタマイズ性と柔軟性が高く、メッセージも豊富です。これは公式に推奨されており、MPMoviePlayerController に代わるものです。

4.2 AVFoundation.framework: AVPlayerViewController

デフォルトのビジュアル コントロール インターフェイスが提供され、操作と表示用のコントローラーとして使用できる完全なプレーヤーが統合されています。公式に推奨されており、MPMoviePlayerViewController に代わるものです。

4.3 MediaPlayer.framework：MPMoviePlayerController

iOS の基本プレーヤーは、いくつかのシンプルな API を使用してビデオ ファイルを再生できます。すでにデータ受信およびデコード機能が含まれています。 UI にビデオを表示したい場合は、インターフェースに view 属性を追加し、プレーヤー UI を自分で開発する必要があります。 iOS 9.0以降、Appleは正式にこれを放棄しました。

4.4 MediaPlayer.framework：MPMoviePlayerViewController

MPMoviePlayerViewController は、iOS の基本的なプレーヤー ビュー コントローラーです。 MPMoviePlayerController に基づいて View のレイヤーをカプセル化します。デフォルトでは全画面モードで表示され、ポップアップ後に自動的に再生され、モーダルウィンドウとして表示されているときに「完了」ボタンをクリックすると、モーダルウィンドウが自動的に終了します。独自のUIを備えています。 Apple は iOS 9.0 以降、これを正式に廃止しました。

4.5 ビデオツールボックスフレームワーク

VideoToolbox は低レベルのフレームワークです。 iOS 8.0以降、公式ハードウェアコーデックAPIが正式にリリースされました。ビデオの圧縮と解凍のサービスを提供し、それらをバッファ コア ビデオ ピクセル ラスター イメージ形式で保存します。これらのサービスは、セッション オブジェクト (圧縮、解凍、ピクセル転送) の形式で提供されます。アプリケーションは、ハードウェア エンコーダーおよびデコーダー関連のコンテンツに直接アクセスする必要はなく、エンコードとデコードを実装するために videotoolbox を直接使用するだけで済みます。 iOS デバイスでのハードウェア エンコードとデコードの品質はある程度保証されているため、ハードウェア エンコードとデコードを最初に使用し、FFmpeg ソフトウェア デコードを補完的なソリューションとして使用できます。

4.6 FFmpeg

Objective-C は C/C++ の混合コンパイルをサポートしているため、FFmpeg を簡単に使用でき、iOS に強力なマルチメディア処理機能を提供します。

5. まとめ

HTML5、Flash、iOS、Android の観点から見ると、いずれもオーディオとビデオを再生する機能を備えているように見えますが、それらの違いは何でしょうか?自分に合ったソリューションをどのように選択すればよいでしょうか?

まず再生における技術的な違いを比較してみましょう。

私たちは製品シナリオを 4 つのタイプに分類しようとしており、それぞれの提案は次のとおりです。

4. よくある質問

選手を作るのはあなたが思っているほど簡単ではありません。プレーヤーによくある問題をいくつか見てみましょう。

1. オーディオとビデオを同期するにはどうすればよいですか?

システムパッケージのプレーヤーの場合、この問題を心配する必要はありませんが、完全に制御可能なプレーヤーを実装する場合は、データ受信 -> 多重分離 -> デコード -> オーディオとビデオの同期 -> レンダリングに介入する必要があります。オーディオとビデオの同期を処理する理由については前の章で説明しましたが、ここでは実装の原則に焦点を当てます。

オーディオとビデオの同期を行う前に、ちょっとした知識ポイントとして、DTS と PTS を追加しましょう (I フレーム、P フレーム、B フレームは各自で追加してください)。

• D TS (デコードタイムスタンプ):タイムスタンプをデコードします。このタイムスタンプの重要性は、プレーヤーにこのフレームのデータをいつデコードするかを伝えることです。
• PTS (プレゼンテーション タイム スタンプ):タイムスタンプを表示します。これは、プレーヤーにこのフレームのデータをいつ表示するかを通知するために使用されます。

ビデオ エンコードには I フレームが必ず含まれ、B フレームと P フレームが含まれる場合もあります。 B フレームは双方向参照フレームであるため、フレームのデコードと表示の順序が乱れます。したがって、この状況に対処するために DTS と PTS が導入されています。一般的に、B フレームは I フレームや P フレームよりも圧縮率が高くなります。オンデマンド ビデオではより一般的です。通常、ライブ ビデオには B フレームはありません。この場合、DTS と PTS は同じである必要があります。参照フレームの概念がないため、オーディオ エンコードには DTS は必要ありません。

（図：I、P、B、DTS、PTSの関係）

DTS と PTS を理解すると、PTS がオーディオとビデオの同期に重要な役割を果たしていることがわかります。一般的なオーディオとビデオの同期方法には、オーディオベースの同期、ビデオベースの同期、外部クロック同期の 3 つがあります。最初の方法は最も一般的であり、人間の視覚と聴覚により適合しています（オーディオ速度の変更により音声が変わります）。同時に、オーディオの再生レートは比較的固定されており、メインラインとして管理しやすくなります。同期プロセスは次のように要約されます。

a) デコーダーは入力データ パッケージからオーディオ PTS とビデオ PTS を抽出します。

b) オーディオ再生スレッドを作成し、固有のサンプリング周波数でオーディオを再生します。

c) ビデオ更新スレッドを作成し、一定の頻度（10 ミリ秒）で定期的な検出を実行します。

d) オーディオとビデオのタイムベース (time_base) を同じタイムベースの PTS に変換します。

e) ビデオ更新スレッドで現在の実際のオーディオ PTS とビデオ PTS を計算します。

• currentRealVideoPTS = 表示される現在のビデオ フレーム PTS + 現在のビデオ フレームの経過システム時間。
• currentRealAudioPTS = 最後に再生されたオーディオ フレーム PTS + 現在のオーディオ フレームの経過システム時間。

f) currentRealVideoPTS と currentRealAudioPTS の差を計算します。

g) diff <= 0 の場合、ビデオの表示が遅く、フレーム データをすぐに表示する必要があることを意味します。

• diff > 0 の場合、ビデオは適切な遅延で表示されます。

h) 1フレームのデータのオーディオとビデオの同期検出が完了します。

上記の方法の核となる概念は、遅延評価アルゴリズムを通じてビデオ フレームの再生速度を遅くしたり速くしたりして、オーディオとビデオを妥当な範囲内で同期させることです。

2. 数秒でビデオを開くにはどうすればいいですか?

最適化できるポイントはいくつかあります。

• a) サーバーは、プレーヤーが最初に有用なデータをデコードできるように、キーフレームデータを送信します。
• b) プレーヤーは、デコーダー関連のパラメータを外部からプリセットすることにより、オーディオおよびビデオデコーダーの選択プロセスを最適化し、デコーダータイプの検出にかかる時間を短縮できます。
• c) ビジネスレベルで最適化し、HTTP-DNS サービスを使用して正確なスケジュールを実現し、再生データを取得するための最適なサーバーを選択します。
• d) オーディオおよびビデオサービスノードの品質を向上させる。

3. 低レイテンシーを実現するにはどうすればよいでしょうか?

遅延という用語は、生放送を指します。まず、ライブ放送システムのアーキテクチャ図を見てみましょう。

（図：UCloudライブ放送システムアーキテクチャ図）

図からわかるように、遅延を引き起こす可能性があるリンクは次のとおりです。

a) ホスト側からアップロードノードにストリームをプッシュする際の遅延。

HTTP-DNS にアクセスして、アンカーに最適なノードを選択し、伝送遅延を削減できます。

b) アンカーがパケットを送信する際の遅延。

アンカーは、ローカル データをできるだけ早くアップロード ノードに送信する必要があります。ネットワーク環境が弱い場合は、期限切れのデータが大量にローカルでブロックされるのを回避するための適切な制御戦略が必要です。

c) アップロードされたノードのサーバー クラスターへのデータ配布、トランスパッケージ化、およびトランスコーディングには時間がかかります。

配信レベルが増えるほど、待ち時間も長くなりますが、これは主にサーバー間のネットワーク状態に依存します。

d) ビューアからダウンロードノードまでの遅延。

HTTP-DNS にアクセスすることで、視聴者にとって最適なノードを選択し、伝送遅延を削減できます。

e) プレーヤーにはローカル バッファーがあります。

従来のビデオ プレーヤーにはローカル キャッシュがあります。適切なキャッシュ設定により、ユーザーの視聴体験が向上し、ビデオのフリーズ回数が減ります。レイテンシの要件が高い場合は、バッファ期間を短縮したり、バッファを削除したりすることもできます。

4. プレーヤーがフリーズする理由は何ですか?

上の写真を見ると、詰まりの原因として考えられるのは次の通りです。

• a) ホスト側でのストリーミングとアップロードノードでの伝送がスムーズではありません。
• b) サーバー間の伝送に問題がある。
• c) 視聴者とダウンロードノード間の伝送がスムーズではありません。

V. 結論

これを読めば、さまざまなプラットフォームでの基本的な再生プロセスとオーディオおよびビデオ処理技術について、基本的な理解が得られたことと思います。しかし、複数のプラットフォームに対応した優れたプレーヤーを作るのは簡単ではありません。互換性の適応、災害復旧、パフォーマンス チューニング、再生品質の統計フィードバック、新しい機能の反復など、多くの作業を行う必要があります。したがって、優れたプレーヤーは常に磨きをかける必要があり、UCloud はこの分野での運用をサポートするためにさらに多くのリソースを投資し続けます。

著者について

Liu Yufeng は現在、UCloud ストリーミング メディア ターミナルの R&D マネージャーを務めています。彼はマルチメディア業界を愛しており、Web、Android、iOS のテクノロジーに重点を置いています。彼はインターネットとマルチメディアの分野で約 10 年の研究開発経験を持っています。現在は、UCloud Video Cloud SDK および Live Cloud SDK のアーキテクチャ設計、R&D 管理、運用を担当しています。以前はテンセントで勤務し、主にWebフロントエンドマルチメディアの研究開発を担当していました。 】