AdobeおよびOpenSourceのHTTP Dynamic Streamingに基づいたビデオ配信システムの構築

プロジェクトの一環として、お客様の1人は、ビデオをインターネットに変換、保存、配信するシステムを構築するという課題に再び直面しました。 典型的なこのようなタスクは、UGCコンテンツではなくプロフェッショナルのみで、独自の小さな（またはそれほど小さくない）「チューブ」を作成することです。



最初の「チューブ」が作成されて以来、インターネット上のビデオ技術は特定の開発方法を経て、今ではさらに多くのことができるようになり、現代のビデオサイトの要件は多少異なります。



私たちの意見では、最も興味深い最近の傾向は次のとおりです。

• 異なるデバイスから1つのビデオサイトを視聴する機能、
• 適応型HTTPストリーミングテクノロジー

インターネットの消費に非常に便利なモバイルデバイスの最近の出現と急速な普及、およびワイヤレスデータ転送技術の開発の結果、モバイルiOS、Android、およびその他のプラットフォームに最適化されたサイトの2番目のバージョンが必要であることが明らかになりました。 それは、このようなGoogleTVなどの人気の任意WebTVの技術を、となったときのために最適化されたサイトの3番目のバージョン「10フィートのインターフェースは、」すぐに、必要になります。



このすべては、いわゆるに適合します。 人々が近い将来にビデオ（および一般にインターネットコンテンツ）を消費する「3つの画面」の概念-道路上の携帯電話（タブレット）、職場のオフィスのPC、家のリビングルームのテレビ。



この記事の主題であるアダプティブHTTPストリーミングテクノロジーについて詳しく説明したいと思います。



インターネットは、特にリアルタイムでのビデオ配信には本質的にあまり適していません。 一方では、スムーズで連続的なビデオストリームを表示したいのですが、他方では、時間の経過に伴う浮動特性との不安定な接続があり、これに対処するための2つの方法があります-遅延（バッファ）の増加またはストリームビットレートの適応。



適応型マルチビットレートストリーミングテクノロジーの主なアイデアは、ストリームアダプテーションにあります-単一のクリップをいくつかのビットレートでエンコードし、たとえば、ユーザーのネットワークの現在のスループットと推定値の評価に基づいて、特定の時間に可能なビットレートをユーザーにストリーミングするデコード速度（つまり、ユーザーのコンピューターはリアルタイムでストリームのデコードに対応していますか）。



まず第一に、これはライブブロードキャストサービスにとって重要です。ユーザーにとって「ストリームを維持する」ことがより重要である場合、つまり、画質を犠牲にしても、「プリバッファリング」の可能性を最小限に抑える場合です。 しかし、ビデオオンデマンドサービスのために、このような技術はまた、非常に便利です - それは素敵だ動画がすぐに開始したときので、あなたがチャンネルを可能にすると口ごもるしないしようとしている品質が、あります。



実際には、これは、地域内のどこかで不安定/弱いチャネルを持つユーザーだけでなく、wifiネットワークのユーザー、家庭内の複数のユーザーに共通する1つの接続を持つユーザーなどに対するサービスの認識を大幅に改善できることを意味します。 .D。 専用の高品質チャンネルを使用しているユーザーの場合、このテクノロジーは単にチャンネルの速度を自動的に決定し、適切なビットレートでビデオを提供します。 エンドユーザーは、360p、240p、SD、HDなどを知る必要がなくなりました。 -すべてが自動的に行われます。



これらのすべてのメリットに対して支払うべきものは3つあります-

• ストリーミング手順を複雑にし、
• 追加のコーディング費用、
• 追加のストレージコスト。

第一の理由は、すでに準備がオープンソースとして、もはや考慮されないことが一瞬である - このようなシステムを構築するためのビルディング・ブロック、私はあなたに伝え続けています。



もちろん、2番目と3番目の理由は重要ですが、ここではサイト開発者がユーザーがこれらの追加コストに見合うかどうかを自分で決定する必要があります。



現在、私が知っている適応型マルチビットレートストリーミングテクノロジーには、少なくとも3つの実装があります。

• Apple HTTP Adaptive Streaming for iPhone / iPad、
• Silverlight用Microsoft Smooth Streaming、
• Adobe Dynamic Streaming for Flash。

もちろん、ビデオサイトの開発において最も重要なのはAdobeの実装です。AppleHTTP Adaptive StreamingはiOSデバイスとMacOS XのSafariでのみ機能するためです（最近、このプロトコルが実装されている1つのSTBが示されました）。 Flashのような人気を得るまで、言っておきましょう。



Adobeはかなりの時間のためのRTMPプロトコル内ダイナミックストリーミングを実装しており、ごく最近（フラッシュ10.1の出現で）それがHTTPストリーミングを使用することが可能となりました。 これは非常に重要なステップです。以前は、ダイナミックストリーミングを使用するには専用のストリーミングサーバーが必要でしたが、今ではほとんどの作業がクライアントに転送され、サーバーサポートは通常のHTTP静的まで簡素化されています。



実際、ビデオをいくつかのビットレートでエンコードし、たとえば5秒間フラグメントに切り分けて高速アップロードサーバー（以下の図を参照）に静的ファイルを配置するか、mp4ファイルからのサーバーまたはストリーミングモジュールがある場合その場で必要なフラグメントをカットし、それをストレージレベルに配置し、リクエストを何らかの効果的なキャッシュにルーティングします。 さらに、このキャッシュはCDNサービスプロバイダーで使用できます。 適応型HTTPストリーミングテクノロジーの主な利点の1つは、外部CDNとキャッシュの使いやすさです。キャッシュの事前入力について心配する必要はありません。







プロキシキャッシュでは、要求されたコンテンツの「コンテンツ」の断片がキャッシュされるため、キャッシュは非常に効果的です。 そして、これらの作品は、比較的小規模であり、異なる管理戦略のキャッシュを考え出すことができます - 作品を「保存」するとき、彼が削除されたとき、など これにより、CDNサービスの開発者に最適化メカニズムを自由に開発できます。 かつてrutube配信システムの最初のバージョンでは、「ピース単位」キャッシングの同様のメカニズムを開発しました。これにより、プロジェクトは、最小限の機器で長時間ビデオを効率的に配信できました。



方法があったNetStreamオブジェクト-アドビのみんなからのHTTPダイナミックストリーミングをサポートするためのプログラミングの観点からは1つの単純なことやるappendBytesにします 。 入力配列の形式は、FLV形式のバイトストリームです。 実際、これによりバイトストリームの再生が可能になり、配信の問題は別のタスクになります。 たとえば、これらのバイトをHTTPスライス経由で配信し、HTTPストリーミングを取得できます。



AppleとMicrosoftのシステムは、「ブラックボックス」内に配信および再生システムを実装しており、Adobeはシステムを独自にプログラムすることを可能にします。 また、オープンソースメディアフレームワークの一部として、このようなシステムのオープンな実装を行いました。 OSMFは、ActionScript3でのビデオプレーヤーの記述を簡素化する基本クラスのセットです。これには、特にHTTPダイナミックストリーミングのサポートの実装が含まれます。 さらに、このプロトコルの仕様と実装の詳細は、アドビが公開しようとしています。 こことここで見ることができます 。 Flashに競合他社が存在せず、彼らの将来が完全にクラウドレスに見えた前に、これを想像できますか？



そのため、問題の説明に戻ります。ビデオホスティングを行いたい場合、デスクトップバージョンではフラッシュおよびHTTPアダプティブストリーミングテクノロジーを使用します。



ビデオを変換して配信するためのこのようなシステムをどのように組み立てますか？



mp4、コーデック-x264およびfaac、ツール-ffmpeg、mencoderでエンコードします。 無料の選択肢がある場合、商用ソフトウェアはあまり好きではありません。



現時点では、このテクノロジーの以下の実装を認識しています。

• 商用ソフトウェア。 AdobeおよびWowzaの商用サーバーにはこのテクノロジーが実装されており、OSMFをプレーヤーの基盤として使用できます。 オプションはおそらく良いですが、高価です。
• Adobe自体からは無料ですが、閉じられた実装があります。 これは、ソースファイルを特定のf4f形式にリパッカーし、そのような再パッケージ化されたファイルで動作するapacheのモジュールです。 短所-なぜ問題なのかを理解するために、ソースが閉じられているため、ffmpegで作成されたmp4ファイルを操作できません。
• CodeShopのUSP 。 長所-サーバー部分の素晴らしいオープンな実装、短所-クライアントは閉じられており、実際には、ソフトウェアはオープンソースではありますが商用です。 このテクノロジーを使用するサイトが商用の場合、広告を表示するか、視聴料を請求します。ライセンスを購入する必要があります。

私は10年インターネットでビデオ技術に携わっている会社で働いており、いくつかの経験があり、Adobe HTTP Dynamic Streamingプロトコルのドキュメントを見て、Tubeプロジェクトの方がサーバーサポートを自分で簡単に実装できると判断しました。 。 また、OSMFのプロトコルのクライアント実装は、BSDライセンスの下で公開されています。



その結果がOpenHttpStreamerプロジェクトであり、LGPLの下でOpenSourceに組み込むことにしました。

公式プロジェクトページ-http://inventos.ru/OpenHttpStreamer

ソースはGitHub- https://github.com/inventos/OpenHttpStreamerで入手できます 。

Ubuntu 10.10、Fedora 12、Debian（Squeeze）でビルドしようとしました。 機能-scons 、g ++バージョン4.3.0以降、およびboost> = 1.39が必要です。



使用方法：

$ git clone https://github.com/inventos/OpenHttpStreamer.git

$ cd OpenHttpStreamer/mp4frag

$ scons configure && scons

$ sudo scons install







すべてが/ usr / local / bin / mp4fragでうまくいけば、静的フラグメントを作成するためのコンパイルされたユーティリティがあります。



$ mp4frag

Allowed options:

--help produce help message

--src arg source mp4 file name

--video_id arg (=some_video) video id for manifest file

--manifest arg (=manifest.f4m) manifest file name

--fragmentduration arg (=3000) single fragment duration, ms

--template make template files instead of full fragments

--nofragments make manifest only







ffmpegを2つの品質でエンコードします-400および700 kbit / s（概算）



$ ffmpeg -y -i test.mpg -acodec libfaac -ac 2 -ab 96k -ar 44100 -vcodec libx264 -vpre medium -g 100 -keyint_min 50 -b 300k -bt 300k -threads 2 test-q1.mp4

$ ffmpeg -y -i test.mpg -acodec libfaac -ac 2 -ab 96k -ar 44100 -vcodec libx264 -vpre medium -g 100 -keyint_min 50 -b 600k -bt 600k -threads 2 test-q2.mp4







2つのmp4ファイル、test-q1.mp4とtest-q2.mp4を取得し、そこから静的フラグメントを生成します。



$ mp4frag --src test-q1.mp4 --src test-q2.mp4 --manifest=test.f4m







結果は、ファイルディスクリプタ（「宣言」）である - test.f4m静的およびIは、フォルダ内の破片を見つけた0/1 /



test.f4m 0/1 /静的を提供できるWebサーバーのDocRootの下に拡散し、OSMFをエンジンとして使用してフラッシュ上に単純なプレーヤーを作成するか、既製のプレーヤーを使用するだけです。



簡単なテストのために、OSMFプレーヤーのアセンブリを使用できます。

これを行うには、

1.サーバーのDocRootの下（test.f4mと同じ場所）に、このようなcrossdomain.xmlを配置します。

<?xml version="1.0"?>

<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">

<cross-domain-policy>

<allow-access-from domain="inventos.ru" />

</cross-domain-policy>







2.ブラウザのリンクにアクセスしてくださいhttp://inventos.ru/OpenHttpStreamer?url=http://your_http_host/test.f4m





何かが動作しない場合はいつものように、私たちのサーバーのログを見て - のcrossdomain.xml、test.f4m、ファイル・セグメントへのプレイヤーから控訴するかどうか。 すべてが正しいかどうかを確認すると便利です-必要なアドレス自体を「プル」します-

wget -O - -S «http://your_http_host/test.f4m»

wget -O - -S «http://your_http_host/1/Seg1Frag1»







結論として、現在リポジトリにあるものについてのいくつかの言葉。 これまでのところ、静的リパッカー-mp4fragのみが記述されています。 nginxのモジュールは開発中です。 アーキテクチャとアルゴリズムについてはすでに考えており、積極的にプログラミングを行っており、今週または来週、文字通りリリースする予定です。これについてもっと書いてほしいと思います。



オリジナル（ffmpeg変換後のmp4）形式でコンテンツを保存する動的生成モジュールが必要です。これは、他の目的（他のプラットフォームへのストリーミング）に適したかなり普遍的な形式だからです。 興味深いオプションがあります-断片化されたmp4を使用しますが、あまり一般的ではありません。



必要なフラグメントにすばやくアクセスするためにmp4のインデックスを作成し、コンテンツ自体の隣の別のファイルにインデックスを配置するという簡単な方法を考え出しました。 インデックスサイズは、ソースファイルの約1％になります。 ソースmp4の目的のmdatフラグメントにすばやくアクセスした後でも、flvヘッダー（OSMF実装の機能）を追加してデータをリミックスする必要があるため、静的に比べてパフォーマンスが低下します。 ただし、高速のWebキャッシュおよびキャッシュ応答を介してこのモジュールの要求をプロキシすることにより、高いパフォーマンスと優れた汎用性の両方を実現します。