(57)【要約】【課題】ライブビデオエンコーディングおよびストリーミングにおけるフレーム複写およびフレーム拡張のためのシステムおよび方法の提供。【解決手段】本発明の実施形態は、現在フレームを再エンコードする代わりに、現在のエンコードされたフレームを複製し、次に、いくつかの異なるアダプティブビットレートストリームのために、必要に応じて複製されたフレームを異なるビットレート、解像度、および／またはコンテキストに調節し得る、ライブエンコーディングシステムを提供する。加えて本発明の種々の実施形態は、再パッケージ化および／または再エンコードされている現在フレームの持続時間を拡張することができる。これらの技術を利用して本発明の実施形態によるライブエンコーディングシステムは、受信されたデータ内のギャップ、データのより低速のフィード、および／またはサーバハードウェアに対する重い負荷により効率的に対処することができる。【選択図】図３
2019193312.tif 000002
【特許請求の範囲】
【請求項１】
明細書に記載された発明。
【発明の詳細な説明】
【技術分野】
【０００１】
（発明の分野）
本発明は、概して、ライブ入力ストリームからのアダプティブビットレートストリームのライブエンコーディングの分野に関する。具体的には、本発明は、ライブ入力ストリームからのアダプティブビットレートストリームのライブエンコーディングを最適化および改良するためのいくつかの技術に関する。
【背景技術】
【０００２】
（発明の背景）
ストリーミング技術は、トップストリーミングを経由してライブをサポートする段階まで進歩している。ライブイベントは、現在、ライブエンコーディングサーバによって生成されるアダプティブビットレートストリームから閲覧されることができる。多くの場合、ライブエンコーディングサーバは、ＭＰＥＧ−ＤＡＳＨフォーマット（すなわち、Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒ  ＨＴＴＰ）を利用する。ＭＰＥＧ−ＤＡＳＨ（ＩＳＯ／ＩＥＣ  ２３００９−１）は、インターネットを経由してマルチメディアコンテンツをストリーミングするための規格である。ＭＰＥＧ−ＤＡＳＨは、Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ（ＭＰＥＧ）によって開発された。ＭＰＥＧは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＭＰＥＧ−７、ＭＰＥＧ−２１、およびその他を含む、以前のマルチメディア規格の開発に関与している。ＭＰＥＧ−ＤＡＳＨは、従来のＨＴＴＰウェブサーバから送達されるインターネットを経由するメディアコンテンツの高品質ストリーミングを可能にするアダプティブビットレートストリーミング技術である。典型的には、ＭＰＥＧ−ＤＡＳＨは、それぞれがＨｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）を介して読み出されるビデオのセグメントを含む小さなファイルのシークエンスを使用し、各セグメントは、プレゼンテーションの短い間隔の再生時間を含む。プレゼンテーションは、ライブイベントであり得、かつ／または規定された持続時間を有し得る。アダプティブビットレートストリームは、３００ｋｂ／ｓ、５００ｋｂ／ｓ、および３ＭＢ／ｓ等の種々の異なるビットレートにおいて利用可能にされることができる。複数のアダプティブビットレートストリームへのソースストリームのライブエンコーディングおよび／またはトランスコーディングは、かなりのコンピューティングリソースを要求し得、ライブエンコーディングハードウェアは、幾分高価である。
【発明の概要】
【課題を解決するための手段】
【０００３】
(発明の詳細な開示）
ここで図面に目を向けると、本発明の実施形態によるライブエンコーディングシステムが、図示される。いくつかの実施形態では、ライブエンコーディングシステムは、（限定ではないが）スポーツイベント、ライブニュースカバレッジ、ウェブライブストリーム、および／または単一もしくは多重化されたメディアストリーム等のライブメディアフィードを受信する。メディアストリームは、プロバイダによって送達されている間にクライアントによって常に受信されてクライアントに提示されるマルチメディアを含む。ストリーミングは、ストリームを介してメディアを送達するプロセスを指す。ライブエンコーディングシステムは、ライブ入力ストリームからエンコードされたメディアストリームをクライアントに提供することができる。さらに、ライブエンコーディングシステムは、受信されたライブメディアフィードを、異なる最大ビットレートを有するいくつかの異なるアダプティブビットレートストリームにエンコードすることができる。ライブエンコーディングシステムはさらに、（限定ではないが）ＨＴＴＰ要求を含むプロトコルを介して、ライブメディアプレゼンテーションにおけるエンコードされたアダプティブビットレートストリームをストリーミングクライアントに伝送し、かつ／またはエンコードされたアダプティブビットレートストリームをクライアントデバイスへの配信のためにサーバに提供することができる。ライブメディアプレゼンテーションのエンコードおよび伝送は、これらの動作を実施するために使用されるハードウェアに対して負荷をかけ得る。本発明の実施形態は、ライブエンコーディングおよび伝送動作を実施するハードウェアに対する負荷を低減させるためのいくつかの技術を提供する。例えば、本発明の多くの実施形態によるライブエンコーディングシステムは、いくつかの尺度に従って、ネットワークおよび／またはサーバ負荷レベルを評価することができる。負荷は、多くの場合、ライブエンコーディングシステムが実施している作業（例えば、計算、エンコーディング動作、メモリ動作等）の量として測定される。評価に基づいて、ライブエンコーディングシステムは、ライブメディアフィードからのビデオのフレームがエンコードされる方法を調節することができる。例えば、ライブエンコーディングシステムのいくつかの実施形態は、現在フレームを再エンコードする代わりに、現在のエンコードされたフレームを複製し、次いで、いくつかの異なるアダプティブビットレートストリームのために、必要に応じて、複製されたフレームを異なるビットレート、解像度、および／またはコンテキストに調節する。加えて、ライブエンコーディングシステムの種々の実施形態は、再パッケージ化および／または再エンコードされている現在フレームの持続時間を拡張することができる。これらおよび他の技術を利用して、本発明の実施形態によるライブエンコーディングシステムは、受信されたデータ内のギャップ、データのより低速のフィード、および／またはサーバハードウェアに対する重い負荷により効率的に対処することができる。
【０００４】
ネットワーク伝送レベルが、ライブエンコーディングプロセスに影響を及ぼし得る。例えば、ライブメディアフィードが、ライブ入力ストリームからライブエンコーディングシステムへのネットワーク伝送レベルにおいて中断を被ると、ライブエンコーディングシステムは、着信データ内のギャップに遭遇し得る。着信データ内のギャップは、出力データ内のギャップを生産し、かつ／または要求されたときにライブエンコーディングシステムが出力フレームを送達し損なうことをもたらし得る。本発明のいくつかの実施形態によるライブエンコーディングシステムは、ギャップが起こったときを決定するために、着信メディアフィードを評価することができる。これらの評価は、（限定ではないが）着信フレームレート、着信ビットレート、到着したフレーム間の時間、および／またはネットワーク帯域幅測定値を含む、いくつかの尺度に基づき得る。本発明の多くの実施形態によるライブエンコーディングシステムは、いくつかのアダプティブビットレートストリームへの着信メディアストリームの再パッケージ化中に、フレームを複製すること、および／またはフレームを拡張することによって、データ内の検出されたギャップを補償することができる。フレームを複製すること、および／またはフレームを拡張することによって、ライブエンコーディングシステムは、ネットワーク条件が、クライアントが依存する要求された時間におけるフレームの可用性を危険に曝すことなく安定化する機会を可能にすることができる。具体的には、ライブエンコーディングシステムは、ライブストリーミングされるメディアのライブエッジよりも遅れ得る。クライアントは、典型的には、プレゼンテーションのライブエッジにおいてライブストリームからフレームを要求する。本明細書で使用されるとき、用語「ライブエッジ」は、まだ利用可能ではないセグメントを要求するリスクを伴わずにクライアントが要求し得る、ライブストリームの直近のエンコードされたセグメントを指す。まだ利用可能ではないセグメントを要求することは、（限定ではないが）遅延、ＨＴＴＰ未検出エラー等の多数のストリーミングエラーをもたらし、帯域幅が輻輳した繰り返し要求をもたらし得る。
【０００５】
サーバ負荷レベルも、同様にライブエンコーディングプロセスに影響を及ぼし得る。ライブエンコーディングシステムが、ライブエンコーディングサーバとして実装される場合、サーバハードウェアは、エンコーディングプロセスによって負担がかかりすぎる状態になり得る。ライブエンコーディングサーバがライブエッジよりも遅れる場合、クライアントはライブエッジにおいて成される要求に依拠するため、いくつかのアダプティブビットレートストリームは、失敗し得る。具体的には、ライブストリーミングクライアントは、ライブエンコーディングシステムが、リアルタイムよりも低速ではないセグメントを生成するという仮定に基づいて、ビデオのセグメントを要求することができる。本発明の多くの実施形態によるライブエンコーディングシステムは、現在フレームを拡張し、出力フレームのタイムスタンプを調節することによって、サーバ負荷を補償することができる。拡張されたフレームは、軽微かつ／または感知することが困難な視覚的エラーを生産し得るが、要求を保存し、クライアントがライブストリーミングのために依存するＨＴＴＰサイクルを受信する。さらに、本発明の実施形態によるライブエンコーディングシステムはまた、複製された現在フレームによって、および、出力ストリームのために、必要に応じて複製された現在フレームのフレームコンテキストを調節することによって、サーバ負荷を補償することもできる。
例えば、本願は以下の項目を提供する。
（項目１）
ライブエンコーディングシステムを使用して、入力ストリームを複数のアダプティブビットレートストリームにエンコードする方法であって、前記方法は、
ライブエンコーディングシステムを使用して、入力ストリームを受信することと、
前記ライブエンコーディングシステムを使用して、エンコード条件を評価することと、
前記ライブエンコーディングシステムを使用して、前記入力ストリームの所与のセグメントを複数のアダプティブビットレートセグメントにエンコードすることと
を含み、前記入力ストリームの所与のセグメントを複数のアダプティブビットレートセグメントにエンコードすることは、
前記評価されたエンコード条件が第１の閾値を満たすとき、前記入力ストリームの前記所与のセグメントから少なくとも１つのフレームを拡張し、前記複数のアダプティブビットレートセグメントのうちの少なくとも１つにおいて、前記入力ストリームの前記セグメントから拡張された少なくとも１つのフレームを使用することと、
前記評価されたエンコード条件が第２の閾値を満たすとき、前記入力ストリームの前記所与のセグメントから少なくとも１つのフレームを複製し、前記複数のアダプティブビットレートセグメントのうちの少なくとも１つにおいて、前記入力ストリームの前記セグメントから複製された少なくとも１つのフレームを使用することと、
前記評価されたエンコード条件が前記第１の閾値または前記第２の閾値のいずれも満たさないとき、前記ライブエンコーディングシステムを使用して、前記入力ストリームの前記所与のセグメントのフレームを前記複数のアダプティブビットレートセグメントにエンコードすることと
を含む、方法。
（項目２）
少なくとも１つのネットワークを経由して、前記エンコードされた複数のアダプティブビットレートセグメントを複数のストリーミングクライアントにストリーミングすることをさらに含む、項目１に記載の方法。
（項目３）
前記ライブエンコーディングシステムを使用して、エンコード条件を評価することはさらに、以前のセグメントと前記所与のセグメントとの間の到着時間を決定することを含み、前記第１の閾値は、異なるセグメントの到着間の特定の時間量である、項目１に記載の方法。
（項目４）
前記以前のセグメントと前記所与のセグメントとの間の到着時間を決定することはさらに、前記以前のセグメントと前記所与のセグメントとの間のタイムスタンプ差を前記ライブエンコーディングシステム上のクロック実装と比較することを含む、項目３に記載の方法。
（項目５）
前記ライブエンコーディングシステムを使用して、エンコード条件を評価することはさらに、前記ライブエンコーディングシステムを使用して、前記入力ストリームから受信されているデータの量を計算することを含み、前記第１の閾値は、規定された時間量にわたって受信された特定のデータ量である、項目１に記載の方法。
（項目６）
前記複数のアダプティブビットレートセグメントは、異なる最大ビットレートにエンコードされる、項目１に記載の方法。
（項目７）
前記入力ストリームは、ライブストリームである、項目１に記載の方法。
（項目８）
前記ライブストリームは、オーディオトラック、ビデオトラック、字幕トラック、およびマルチメディアトラックの群から選択されるメディアを備える、項目７に記載の方法。
（項目９）
前記ライブエンコーディングシステムを使用して、エンコード条件を評価することはさらに、前記ライブエンコーディングシステムを使用して、前記ライブエンコーディングシステムに対する負荷の量を計算することを含み、前記第２の閾値は、前記ライブエンコーディングシステムが実施している特定の計算作業量である、項目１に記載の方法。
（項目１０）
前記入力ストリームは、特定のエンコードを有し、前記入力ストリームの前記セグメントから複製された少なくとも１つのフレームは、同一の特定のエンコードを有する、項目１に記載の方法。
（項目１１）
ライブエンコーディングシステムであって、前記ライブエンコーディングシステムは、
少なくとも１つの処理ユニットと、
コンピュータ命令を備えるライブエンコーディングアプリケーションを記憶するメモリであって、前記ライブエンコーディングアプリケーションは、前記少なくとも１つの処理ユニットに、
入力ストリームを受信することと、
エンコード条件を評価することと、
前記入力ストリームの所与のセグメントを複数のアダプティブビットレートセグメントにエンコードすることと
を行うように命令し、前記入力ストリームの所与のセグメントを複数のアダプティブビットレートセグメントにエンコードする命令はさらに、
前記評価されたエンコード条件が第１の閾値を満たすとき、前記入力ストリームの前記所与のセグメントから少なくとも１つのフレームを拡張し、前記複数のアダプティブビットレートセグメントのうちの少なくとも１つにおいて、前記入力ストリームの前記セグメントから拡張された少なくとも１つのフレームを使用することと、
前記評価されたエンコード条件が第２の閾値を満たすとき、前記入力ストリームの前記所与のセグメントから少なくとも１つのフレームを複製し、前記複数のアダプティブビットレートセグメントのうちの少なくとも１つにおいて、前記入力ストリームの前記セグメントから複製された少なくとも１つのフレームを使用することと、
前記評価されたエンコード条件が前記第１の閾値または前記第２の閾値のいずれも満たさないとき、前記入力ストリームの前記所与のセグメントのフレームを前記複数のアダプティブビットレートセグメントにエンコードすることと
を行う命令を含む、メモリと
を備える、ライブエンコーディングシステム。
（項目１２）
前記ライブエンコーディングアプリケーションはさらに、少なくとも１つのネットワークを経由して、前記エンコードされた複数のアダプティブビットレートセグメントを複数のストリーミングクライアントにストリーミングする命令を含む、項目１１に記載のライブエンコーディングシステム。
（項目１３）
前記エンコード条件を評価する命令はさらに、以前のセグメントと前記所与のセグメントとの間の到着時間を決定する命令を含み、前記第１の閾値は、異なるセグメントの到着間の特定の時間量である、項目１１に記載のライブエンコーディングシステム。
（項目１４）
前記以前のセグメントと前記所与のセグメントとの間の到着時間を決定する命令はさらに、前記以前のセグメントと前記所与のセグメントとの間のタイムスタンプ差を前記ライブエンコーディングシステム上のクロック実装と比較する命令を含む、項目１３に記載のライブエンコーディングシステム。
（項目１５）
前記エンコード条件を評価する命令はさらに、前記入力ストリームから受信されているデータの量を計算する命令を含み、前記第１の閾値は、規定された時間量にわたって受信された特定のデータ量である、項目１１に記載のライブエンコーディングシステム。
（項目１６）
前記複数のアダプティブビットレートセグメントは、異なる最大ビットレートにエンコードされる、項目１１に記載のライブエンコーディングシステム。
（項目１７）
前記入力ストリームは、ライブストリームである、項目１１に記載のライブエンコーディングシステム。
（項目１８）
前記ライブストリームは、オーディオトラック、ビデオトラック、字幕トラック、およびマルチメディアトラックの群から選択されるメディアを備える、項目１７に記載のライブエンコーディングシステム。
（項目１９）
前記エンコード条件を評価する命令はさらに、前記ライブエンコーディングシステムに対する負荷の量を計算する命令を含み、前記第２の閾値は、前記ライブエンコーディングシステムが実施している特定の計算作業量である、項目１１に記載のライブエンコーディングシステム。
（項目２０）
前記入力ストリームは、特定のエンコードを有し、前記入力ストリームの前記セグメントから複製された少なくとも１つのフレームは、同一の特定のエンコードを有する、項目１１に記載のライブエンコーディングシステム。
【図面の簡単な説明】
【０００６】
【図１】図１は、本発明の実施形態による、ライブエンコーディングシステムを図示するネットワーク図である。
【図２】図２は、本発明の実施形態による、ライブエンコーディングシステムによって実施される高レベルプロセスを図示するフローチャートである。
【図３】図３は、本発明の実施形態による、欠落している入力フレームを補償するためにフレームを拡張するライブエンコーディングシステムの実施例を概念的に図示する。
【図４】図４は、本発明の実施形態による、欠落している入力フレームを補償するためにフレームを拡張するライブエンコーディングシステムの代替実施例を概念的に図示する。
【図５】図５は、本発明の実施形態による、遅延された入力フレームを補償するためにフレームを拡張するライブエンコーディングシステムの実施例を概念的に図示する。
【図６】図６は、本発明の実施形態による、遅延された入力フレームを補償するためにフレームを拡張するライブエンコーディングシステムの代替実施例を概念的に図示する。
【図７】図７は、本発明の実施形態による、システム負荷を補償するためにフレームを複製するライブエンコーディングシステムの実施例を概念的に図示する。
【図８】図８は、本発明の実施形態による、ライブエンコーディングシステムおよびストリーミングに関するデータフロー図である。
【図９】図９は、本発明の実施形態によって利用され得る、ＭＰＥＧ−ＤＡＳＨに関するＭｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＭＰＤ）データモデルの実施例である。
【図１０】図１０は、本発明の実施形態による、ライブエンコーディングサーバのアーキテクチャを概念的に図示する。
【発明を実施するための形態】
【０００７】
本発明の多くの実施形態によるライブエンコーディングシステムの動作および機能の簡潔な概観を議論したが、本発明の実施形態によるライブエンコーディングシステムに関するシステム、サーバ、および方法のより詳細な議論が、以下に続く。
【０００８】
（ライブエンコーディングシステムに関するネットワークアーキテクチャ）
本発明の実施形態による、ライブエンコーディングシステムに関するネットワークアーキテクチャが、図１に図示される。システム１００は、ライブエンコーディングをサポートするために、必要に応じてアプリケーションサーバ、データベースサーバ、および／またはデータベースを含む、ライブエンコーディングサーバおよびサポーティングハードウェア１０２を含む。ライブエンコーディングサーバおよびサポーティングハードウェア１０２は、コンテンツソース１１４からライブメディアコンテツおよび／または非ライブコンテンツを受信することができる。コンテンツソース１１４は、メディアをライブエンコーディングサーバおよびサポーティングハードウェア１０２に提供するために使用されるハードウェアを含むことができる。コンテンツソース１１４から受信されるメディアは、（限定ではないが）ウェブストリーム、ライブメディアブロードキャスト、テレビ放送、ライブイベントカバレッジ、ライブカメラからのビデオフィード、以前に記憶されたメディア、未加工メディアフィード、エンコードされたメディアフィード、ならびに／またはローカルおよび／もしくは遠隔ストレージから受信された静的ファイルを含むことができる。
【０００９】
ライブエンコーディングサーバおよびサポーティングハードウェア１０２は、コンテンツのストリームを提供するために、ネットワーク１０４を経由して、いくつかのデバイスの群と通信することができる。デバイスの群は、（限定ではないが）ウェブ、ファイル、および／もしくはメディアサーバ１０６、コンピューティングデバイス１０８、ならびに／またはモバイルデバイス１１２を含む。これらのデバイスの群からのデバイスのユーザは、ローカルストリーミングクライアントを利用して、提供されたストリーミングコンテンツを閲覧することができる。加えて、ウェブ、ファイル、および／またはメディアサーバ１０６からのウェブサーバはまた、提供されたストリーミングコンテンツの付加的下流閲覧者および／またはクライアントのためのホストとしての役割を果たすことができる。
【００１０】
図１に図示されるように、ライブエンコーディングサーバおよびサポーティングハードウェア１０２は、アプリケーションサーバと、データベースサーバと、データベースとを含む。種々の実施形態では、ライブエンコーディングサーバおよびサポーティングハードウェア１０２は、異なる数およびタイプのデバイスを含むことができる。例えば、ライブエンコーディングサーバおよびサポーティングハードウェア１０２は、単一コンピューティングデバイスが十分なストレージ、ネットワーキング、および／またはコンピューティングパワーを有する場合、単一コンピューティングデバイスとして実装されることができる。しかしながら、ライブエンコーディングサーバおよびサポーティングハードウェア１０２はまた、種々のタイプおよび複数の場所の複数のコンピューティングデバイスを使用して実装され得る。例えば、ライブエンコーディングサーバおよびサポーティングハードウェア１０２は、ライブメディアをエンコードするためのライブエンコーディングサーバおよびライブエンコーディングサーバによってエンコードされたセグメントに関するＨＴＴＰ要求に応答するためのＨＴＴＰサーバとして実装され得る。ライブエンコーディングサーバおよびサポーティングハードウェア１０２は、アプリケーションサーバ、データベースサーバ、およびデータベースを含むように示されているが、当業者は、本発明が図１に示されるデバイスに限定されず、付加的なタイプのコンピューティングデバイス（例えば、ウェブサーバ、および／またはクラウドストレージシステム）を含み得ることを認識する。
【００１１】
図１に図示される実施形態では、ネットワーク１０４は、インターネットである。ライブエンコーディングサーバおよびサポーティングハードウェア１０２は、ネットワーク１０４を通して、かつ無線接続１１０を経由して、モバイルデバイス１１２から要求を受信し、モバイルデバイス１１２にメディアセグメントを伝送することができる。無線接続１１０は、（限定ではないが）４Ｇ接続、セルラーネットワーク、Ｗｉ−Ｆｉネットワーク、および／または特定用途の要件に適切な任意の他の無線データ通信であり得る。ライブエンコーディングサーバおよびサポーティングハードウェア１０２は、ネットワーク１０４を通して、コンピューティングデバイス１０８ならびにウェブ、ファイル、および／またはメディアサーバ１０６と直接通信することができる。他の実施形態は、デバイス間で通信するために、イーサネット（登録商標）または仮想ネットワーク等の他のネットワークを使用し得る。当業者は、本発明が図１に示されるネットワークタイプに限定されず、付加的なタイプのネットワーク（例えば、イントラネット、仮想ネットワーク、モバイルネットワーク、および／または特定用途の要件に適切な他のネットワーク）を含み得ることを認識する。
【００１２】
具体的アーキテクチャが図１に示されているが、電子デバイスおよびネットワーク通信を伴う異なるアーキテクチャが、ライブエンコーディングシステムを実装し、本発明の実施形態による動作を実施し、機能を提供するために利用されることができる。
【００１３】
（ライブエンコーディングサーバに関するシステムおよびプロセス）
ライブエンコーディングシステムでは、クライアントは、多くの場合、ライブエンコーディングエッジにおけるフレームを要求および受信することが可能であることに依拠する。エンコーディングおよび／または伝送における任意の中断は、クライアントに、必要とされるフレームの受信の失敗、ＨＴＴＰ要求の失敗、画像途切れ、および閲覧者による一般的な苛立ちをもたらし得る。本発明の多数の実施形態によるライブエンコーディングシステムは、以下に議論される技術を通してライブエンコーディングにおける損失および中断を軽減するために、着信メディアおよび／またはエンコーディングシステム負荷のリアルタイム分析を使用することができる。
【００１４】
図２は、メディアを受信し、ストリームを生成し、生成されたストリームをライブストリーミングクライアントに提供する際に、本発明の実施形態によるライブエンコーディングシステムによって実施され得る、プロセス２００を概念的に図示する。いくつかの実施形態では、プロセス２００は、図１と関連して上記に説明される実施形態によるライブエンコーディングサーバによって実施される。特に、プロセス２００は、メディアの連続的ライブエンコーディングおよびライブストリーミング中にＭＰＥＧ−ＤＡＳＨライブエンコーディングサーバによって実施されることができる。
【００１５】
メディアが、受信されることができる（２１０）。上記に言及されるように、メディアは、多数の異なるタイプ、フォーマット、規格、および／またはプレゼンテーションを包含することができる。多くの場合、受信されるメディアは、すでにエンコードされたメディアのライブフィードである。受信されるメディアは、（限定ではないが）入力ストリーム、ライブメディアフィード、テレビフィード、衛星フィード、ウェブストリーム、ならびに／またはローカルおよび／もしくは遠隔ストレージから受信される静的ファイルを含むことができる。
【００１６】
ストリームが、受信されたメディアから生成されることができる（２２０）。生成されたストリームは、（限定ではないが）ＭＰＥＧ−ＤＡＳＨ、Ｈ．２６４／ＡＶＣ、ＨＴＴＰ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ、Ｓｍｏｏｔｈ  Ｓｔｒｅａｍｉｎｇ、および／または任意の他のアダプティブビットレートフォーマット等の多くの可能なフォーマットであり得る。生成されたストリームは、次いで、ネットワーク接続を経由してストリーミングクライアントに提供されることができる。典型的には、生成されたストリームは、異なる最大ビットレートであり、異なるエンコードパラメータに従ってエンコードされる。いくつかの実施形態では、ストリームは、ライブエンコーディングサーバの再パッケージ化アプリケーションを利用して生成される。再パッケージ化アプリケーションは、受信されたメディアを出力ストリームに再パッケージ化する。それによって、再パッケージ化アプリケーションは、ストリームを生成するために、必要に応じて、種々のエンコーダおよびデコーダを利用することができる。
【００１７】
ストリームの生成は、ライブメディアが受信されるにつれて実施される連続的プロセスであり得る。ライブメディアの受信に応答したストリームの連続的生成中、ライブエンコーディングシステムに対する負荷レベル、通信ネットワークにおける負荷レベル、メディアの受信におけるギャップ、および／またはストリームの生成におけるギャップが、評価されることができる（２３０）。さらに、異なる実施形態は、ライブエンコーディングサーバ動作の他の側面を評価し得る。該評価を実施することは、いくつかの副動作を含むことができる。例えば、ライブエンコーディングシステムは、受信されたメディアの着信データレートおよび／またはフレームレートをチェックすることができる。受信されたメディアの着信データレートおよび／またはフレームレートは、ライブエンコーディングシステムの内部論理に従って決定されるフレーム時間と比較されることができる。内部論理は、（限定ではないが）受信されたメディアのタイムスタンプ、ライブエンコーディングシステム上のクロック実装、および／または受信されたメディアの宣言フレームレート等の信頼性のある時間を決定するいくつかのソースを含むことができる。いくつかの実施形態では、ライブエンコーディングシステムは、全体的着信データレートを計算するために、着信フレーム間の時間の差異を測定することができる。ライブエンコーディングシステムは、次いで、計算された全体的着信データレートを監視し、着信データ内のギャップまたは潜在的サージを識別することができ、潜在的サージは、ライブエンコーディングシステムの処理パワーに負担をかけ得る。これらの評価のうちの１つまたは複数のものは、ライブエンコーディングシステムに関するライブエッジ要件を満たすために、ライブエンコーディングシステムが、適切な時間にフレームを受信していないこと、および／または時間内にフレームをエンコードすることに失敗することを示すことができる。
【００１８】
ライブエッジのために時間内にフレームを生成することに失敗するリスクを軽減するために、受信されたメディアのフレームは、随意に、複写および／または複製されることができる（２４０）。いくつかの実施形態では、複写されたフレームは、種々の生成されたストリームと関連付けられる新しいフレームコンテキストを考慮するために修正されることができる。異なるフレームコンテキストは、（限定ではないが）異なる解像度、異なるフレームタイプ（Ｉフレーム、Ｂフレーム、および／またはＰフレーム等）、異なる最大ビットレートを含むことができる。受信されたメディアからのストリームの生成は、多くの場合、受信されたメディアを異なるフォーマットに再エンコードすることを伴い、この場合、受信されたメディアは、エンコードされたフレームを含む。受信されたメディアの再エンコードは、ライブエンコーディングシステムによって実施されるものの中でも、よりリソース集約的な動作であり得る。複写されたフレームは、次いで、比較的に高コストな再エンコード動作を伴わずに生成されたストリームにおいて利用されることができる。さらに、複写されたフレームはまた、受信されたメディアからエンコードされたフレームに加えて、受信されたメディアからの未加工フレームから複写されることもできる。
【００１９】
しかしながら、ライブエンコーディングプロセスの一部としてフレームを再エンコードする代わりに、エンコードされたフレームを複製することは、Ｈ．２６４／ＡＶＣにおける仮想参照デコーダ（ＨＲＤ）の特定の要件に反する出力ストリームをもたらし得る。定義上、ＨＲＤは、その入力がコンプライアントストリームであるとき、オーバーフローもアンダーフローもしてはならない。大きいエンコードされたフレームを複製し、低い最大ビットレートストリームにおいて複製されたストリームを利用することは、ＨＲＤ要件を満たさないバッファオーバーフローを引き起こすリスクがある。しかしながら、ソフトウェアデコーダクライアントは、そのより柔軟なバッファに起因して、問題を伴わずにこれを補償することができる。ソフトウェアデコーダクライアントは、複製されたフレームを処理するために、付加的ＣＰＵサイクルを要求する。ハードウェアデコーダクライアントは、複製されたフレームがより低い最大ビットレートストリームにおいて使用されるとき、可能性として考えられるバッファオーバーフローに起因するエラーに遭遇する。本発明のいくつかの実施形態は、ハードウェアデコーダにおけるバッファオーバーフローのリスクを軽減するために、より低い最大ビットレート出力ストリームに対して複製されたフレームのビット値の低減を提供する。さらに他の実施形態では、複製されたフレームは、その独自の特定の最大ビットレート出力ストリームに対してのみ使用され、それによって、高ビット値フレームが低最大ビットレートストリームにおいて利用されることを防止する。これは、出力ストリーム毎に別個のエンコーディングプロセスを含めることによって遂行されることができる。
【００２０】
さらに、いくつかの実施形態では、フレームは、入力ストリームから複製および／または複写されることができ、この場合、入力ストリームおよび出力ストリームは、同一のフォーマット、最大ビットレート、および／または解像度を共有する。これは、所望の出力ストリームが入力ストリームと同一である場合に起こり得る。これが起こる場合、再エンコードは、スキップされることができ、いくつかの実施形態は、単純に、入力ストリームから即時デコードリフレッシュ（ＩＤＲ）フレームを複製することができる。上記に議論されるように、該いくつかの実施形態では、結果として生じる出力ストリームは、非ＨＲＤ準拠であり得る。
【００２１】
ライブエッジのために時間内にフレームを生成することに失敗するリスクを軽減するためのさらなる技術では、受信されたメディアのフレームは、随意に、拡張されることができる（２５０）。フレームを拡張することは、所与のフレームの割り当てられたタイムスタンプとは異なる時間において、所与のフレームを出力ストリームにパッケージ化することを含むことができる。以前の評価に応じて、フレームの異なる拡張が、起こり得る。メディアのフィードおよび／または受信の際にギャップが検出される場合、現在フレームが、出力ストリームの生成において拡張され得る。ライブエンコーディングサーバの一部として再パッケージ化アプリケーションを利用する実施形態では、再パッケージ化アプリケーションは、出力ストリームへのフレームの再パッケージ化中に拡張を実施することができる。ビデオにおける視覚アーチファクトおよび／または知覚ストールを低減させるために、再パッケージ化アプリケーションは、複数のステップにおいてギャップを補償するために、いくつかのより小さいフレーム拡張を複数のフレームにわたって拡散させることができる。より小さい拡張は、ストリーミングクライアント閲覧者から拡張を隠す役割を果たすことができる。
【００２２】
生成された出力ストリームは、ストリーミングクライアントに提供されることができる（２６０）。生成された出力ストリームは、異なる最大ビットレートであり得るが、それぞれ、単一のメディアプレゼンテーションを表す。したがって、所与のメディアプレゼンテーションが、異なる最大ビットレートを有するいくつかのストリームにおいてストリーミングクライアントに提供されることができる。生成された出力ストリームの提供は、生成された出力ストリームからのセグメントに関するＨＴＴＰ要求を介して達成されることができる。
【００２３】
プロセス２００に提示される動作は、直線的順序において提示されているが、種々の実施形態は、該動作を異なる順序において実施することができる。例えば、クライアントへのストリームの生成および提供は、ライブメディアが受信されるにつれて連続的に実施されることができる。したがって、プロセス２００に提示される動作の順序は、単に、例示的であり、受信されたメディアのフレームからのストリームのライブ生成のための循環的プロセスの一部として、連続的に実施されることができる。いくつかの実施形態のライブエンコーディングシステムによって実施されるプロセスの概観を議論したが、以下の議論は、該プロセスの一部として実施され得る、フレーム拡張およびフレーム複製のいくつかの実施例を提供する。
【００２４】
（フレーム拡張およびフレーム複製の実施例）
上記に議論されるように、本発明の実施形態によるライブエンコーディングシステムは、評価されたネットワークおよび／またはサーバ条件に応答して、フレームを拡張する、および／またはフレームを複製することができる。フレーム拡張および／またはフレーム複製は、ドロップされた入力フレーム、遅延された入力フレーム、および／またはエンコーディングシステム負荷を補償することができる。図３、図４、図５、図６、および図７は、本発明の実施形態による、フレーム拡張およびフレーム複写のいくつかの実施例を概念的に図示する。前述の図に提示される実施例は、フレーム複製および／またはフレーム拡張の影響を示すために図示されるライブエンコーディングプロセスの抽象図である。本発明の実施形態によるライブエンコーディングシステムは、図３、図４、図５、図６、および図７の実施例に図示されていない付加的詳細、構成要素、および／または機能を含む。タイムスタンプ、フレーム番号、および／またはフレーム持続時間に関する具体的な数は、例示目的として提示される。本発明の実施形態は、図３、図４、図５、図６、および図７に提示される具体的な値に限定されず、ライブエンコーディング動作のために要求されるような広範囲の可能なタイムスタンプ、フレーム番号、および／またはフレーム持続時間を組み込むことができる。さらに、単一の出力ストリームのみが以下の図に示されているが、本発明の実施形態は、典型的には、異なるエンコードパラメータを伴う異なる最大ビットレートにおける複数の出力ストリームを生成する。
【００２５】
図３は、本発明の実施形態による、欠落している入力フレームを補償するためにフレームを拡張するライブエンコーディングシステムの実施例を概念的に図示する。示されるように、ライブエンコーディングシステム３００は、入力ストリーム３１０を受信し、出力ストリーム３６０を生成する。図３に図示される実施例では、ライブエンコーディングシステム３００のライブエンコーディングプロセスは、連続的な、入力ストリーム３１０の受信および出力ストリーム３６０の生成中に実施される。入力ストリーム３１０は、上記に議論される入力ストリームおよび／またはメディアのいずれかであり得る。ライブエンコーディングシステム３６０は、上記に議論される技術のいずれかを介して、生成された出力ストリーム３６０をストリーミングクライアント（図示せず）に提供することができる。ＨＴＴＰ要求を受信し、出力ストリームからのセグメントを伝送する等の技術がある。
【００２６】
示されるように、入力ストリーム３１０は、識別されるタイムスタンプおよび持続時間を伴ういくつかのフレームを含む。フレームは、フレームビデオ等のメディアの一部を含むことができる。タイムスタンプは、略語「ＴＳ」によって示される。持続時間は、略語「Ｄ」によって示される。先に言及されたように、図３に示される値は、例示的である。本発明の実施形態は、ライブエンコーディングをサポートするために、必要に応じて、種々の異なるタイムスタンプおよび持続時間値を受信および処理することができる。フレーム５  ３２０は、５に等しいタイムスタンプ値と、１に等しい持続時間値とを有する。
【００２７】
ライブエンコーディングシステム３００は、規定された時間に入力ストリーム３１０からフレームを受信することが予期される。フレームが規定された時間に受信されないと、ライブエンコーディングシステム３００は、ライブエンコーディングクライアントによって予期されるライブエッジのために時間内に出力ストリーム３６０を生成することが可能ではない場合がある。ライブエンコーディングシステム３００は、上記に議論されるような種々の尺度を使用して、フレームが入力ストリーム３１０から欠落しているかどうかを評価することができる。ライブエンコーディングシステム３００によって維持される内部クロックを、ライブ入力ストリーム３１０の受信されたフレームのタイムスタンプと比較すること等がある。ライブエンコーディングシステム３１０はまた、フレームを拡張する前に満たされなければならない、欠落しているフレームに関する閾値を含むことができる。ライブエンコーディングシステム３１０は、少なくとも２つのフレームギャップを補償するために、フレームを拡張することを選択する前に、２つの欠落しているフレームの閾値を含む。異なる実施形態は、順序通りの欠落しているフレームの代わりに、時間のセグメントにわたって欠落しているフレーム等、異なる数のフレームおよび／または異なる閾値測定値に基づき得る、異なる閾値を含み得る。ビデオのライブエンコーディングは、本質的に、リソース集約的なプロセスであり、したがって、種々の実施形態は、エンコーディングシステム負荷、クライアント途切れ、ネットワーク帯域幅安定性、ビデオ品質、ならびにビデオのライブエンコーディングに影響を及ぼし得る他のメトリックおよび／または条件等のエンコード条件の評価と関連する種々の閾値を利用することができる。上記に議論されるように、本発明の異なる実施形態では、フレームの具体的カウントおよびその送達は、計算され、フレームカウントおよび時間の異なる閾値と比較されることができる。さらに、異なる実施形態は、そのようなストリーミング条件、処理サイクルカウント、フレームのセットのエンコードのための時間ベンチマーク、ネットワーク転送レート、送達および表示されるフレームレート、および視覚品質／忠実度の種々の測定値を評価するための異なるメトリックを使用することができる。具体的な値が本明細書に提供されていないが、異なる具体的な値（２４フレーム毎秒を下回る下落、特定のガンマ値を超える表示失敗を引き起こす視覚エラー、毎秒エンコードされるフレーム等）が、本発明の精神から逸脱することなく本発明を実装するために、必要に応じて利用されることができる。
【００２８】
入力フレームは、（限定ではないが）入力ストリームのプロバイダとライブエンコーディングシステムとの間のネットワーク接続の失敗が存在するとき、入力ストリームに欠陥が存在するとき、および／またはライブエンコーディングシステムの内部エラーが存在するとき等、種々の異なる状況下で欠落し得る。示されるように、入力ストリーム３１０は、フレーム３３０およびフレーム３４０が欠落している。ライブエンコーディングシステム３００は、フレーム８  ３５０のタイムスタンプをフレーム５  ３２０のタイムスタンプおよびライブエンコーディングシステム３００によって維持される内部クロックと比較することによって、このギャップを検出することができる。欠落しているフレームの閾値が満たされると、ライブエンコーディングシステム３００は、フレーム内のギャップを補償するために、フレームを拡張することができる。種々の実施形態は、上記に議論されるもののいずれかを含む、異なる閾値スキームを使用することができる。
【００２９】
示されるように、ライブエンコーディングシステム３００は、出力ストリーム３６０を生成する際に、入力ストリーム３１０からフレーム５  ３２０を拡張する。拡張されたフレーム３７０は、欠落しているフレーム３３０および３４０をカバーするために、３に等しい持続時間値を有するように拡張される。拡張されたフレーム３７０は、ライブストリーミングクライアントによって要求されると利用可能になり、中断のないライブストリーミングをサポートするために要求されるライブエッジを保存する。しかしながら、フレーム持続時間を拡張することは、過剰に使用される場合に視覚アーチファクトをもたらし得る。
【００３０】
図４は、フレーム拡張の影響を隠すことに役立つ、フレーム持続時間を拡張する代替方法を概念的に図示する。示されるように、ライブエンコーディングシステム４００は、入力ストリーム４１０から出力ストリーム４６０を生成している。入力ストリーム４１０は、フレーム４３０および４４０が欠落している。このギャップを補償するために、ライブエンコーディングシステム４００は、フレーム５  ４２０およびフレーム８  ４５０の持続時間を拡張し、また、フレーム８  ４５０のタイムスタンプ値を調節することができる。出力ストリーム４６０に示されるように、拡張されたフレーム５  ４７０は、２の持続時間値を有するように拡張されており、拡張されたフレーム８  ４８０も、同様に２の持続時間値を有するように拡張されている。しかしながら、拡張されたフレーム８  ４７０に関するタイムスタンプは、拡張されたフレーム８  ４８０が拡張されたフレーム５  ４７０の直後に利用可能になるように、７になるように調節されている。欠落しているフレームの周囲に拡張を分配することによって、ライブエンコーディングシステム４００は、フレーム持続時間拡張によって引き起こされる視覚アーチファクトの一部を隠すことができる。
【００３１】
図５は、本発明の実施形態による、遅延された入力フレームを補償するためにフレームを拡張するライブエンコーディングシステムの実施例を概念的に図示する。示されるように、ライブエンコーディングシステム５００は、入力ストリーム５１０から出力ストリーム５６０を生成している。しかしながら、フレーム遅延５３０および５４０は、フレーム６  ５５０の到着遅れをもたらす。ライブエンコーディングシステム５００は、フレーム遅延を検出し、補償するためにフレーム持続時間拡張を使用することができる。先の実施例とは異なり、いかなるフレーム損失も存在しない。ライブエンコーディングシステム５００は、出力ストリーム５６０を生成し、出力ストリーム５６０は、３に拡張された持続時間を伴う拡張されたフレーム５と、８に調節されたタイムスタンプ値を伴うフレーム６
５８０とを含む。拡張されたフレーム５７０は、ライブストリーミングクライアントによって要求されると利用可能になり、中断のないライブストリーミングをサポートするために要求されるライブエッジを保存する。上記に議論される実施例と同様に、フレーム持続時間を拡張することは、過剰に使用される場合に視覚アーチファクトをもたらし得る。
【００３２】
図６は、フレーム拡張の影響を隠すことに役立つ、フレーム遅延を補償するためにフレーム持続時間を拡張する代替方法を概念的に図示する。示されるように、ライブエンコーディングシステム６００は、入力ストリーム６１０から出力ストリーム６６０を生成している。上記のように、フレーム遅延が、６３０および６４０において起こる。この遅延を補償するために、ライブエンコーディングシステム６００は、フレーム５  ６２０およびフレーム６  ６５０の持続時間を拡張し、また、フレーム６  ６５０のタイムスタンプ値を調節することができる。出力ストリーム６６０に示されるように、拡張されたフレーム８  ６７０は、２の持続時間値を有するように拡張されており、拡張されたフレーム８も、同様に２の持続時間値を有するように拡張されている。しかしながら、拡張されたフレーム８  ６７０に関するタイムスタンプは、拡張されたフレーム８  ６７０が拡張されたフレーム５  ６７０の直後に利用可能になるように、７になるように調節されている。遅延されたフレームの周囲に拡張を分配することによって、ライブエンコーディングシステム４００は、フレーム持続時間拡張によって引き起こされる視覚アーチファクトの一部を隠すことができる。
【００３３】
本発明の実施形態は、図３、図４、図５、および図６に関して上記に議論されるフレーム拡張技術に限定されない。種々の実施形態は、図３および図５に示されるようなフレーム持続時間の連続的拡張ならびに／または異なる状況において図４および図５に示されるようなフレーム持続時間の分散的拡張を利用することができる。さらに、フレーム持続時間を拡張することは、欠落しているフレームおよび／または遅延されたフレームに起因して実施されることに限定されない。
【００３４】
ライブエンコーディングサーバは、典型的には、ライブエッジ要件を満たす、ライブストリームをエンコードする有意なコンピューティングパワーを必要とする、非常に強力かつ高価な機械である。しかしながら、強力なサーバであっても、過負荷になり得、それより劣ったサーバは、なおさらである。特に、エンコードされたフレームを再エンコードすることは、サーバリソースの深刻な消費となり得る。図７は、本発明の実施形態による、サーバ負荷を補償するためにフレームを拡張するライブエンコーディングシステムの実施例を概念的に図示する。示されるように、ライブエンコーディングシステム７００は、入力ストリーム７１０を受信し、出力ストリーム７６０を生成する。図７に図示される実施例では、ライブエンコーディングシステム７００のライブエンコーディングプロセスは、連続的な、入力ストリーム７１０の受信および出力ストリーム７６０の生成中に実施される。ライブエンコーディングシステム７００が、負荷７４０下で示される。この負荷を補償するために、ライブエンコーディングシステム７００は、エンコードされたドメイン内のエンコードされた入力ストリームからフレームを複製することができる。
【００３５】
示されるように、ライブエンコーディングシステム７００は、エンコードされたフレーム４  ７２０およびエンコードされたフレーム５  ７３０を受信する。ライブエンコーディングシステム７００は、エンコードされた出力ストリーム７５０を生成する際にこれらのフレームを複製する。複製されたフレーム４  ７６０および複製されたフレーム５  ７７０のためのフレームフィールドは、新しいフレームコンテキストを考慮するために、調節される必要があり得る。しかしながら、これらの調節は、再エンコード動作と比較して、有意に少ない処理リソースを要求し得る。複製されたフレーム４  ７６０および複製されたフレーム５  ７７０は、エンコードされたフレーム４  ７２０およびエンコードされたフレーム５  ７３０と同一の持続時間値およびタイムスタンプ値を有する。
【００３６】
本発明の実施形態は、図７に概念的に図示される実施例において上記に議論される具体的フレーム複製技術に限定されない。種々の実施形態は、未加工のエンコードされていない入力ストリーム等の種々のフォーマットの入力ストリームを伴うフレーム複製および／または複写を利用することができる。さらに、本発明の実施形態は、サーバ負荷の時間中にのみフレーム複製および／またはフレーム複写を実施することに限定されない。例えば、本発明のいくつかの実施形態は、サーバ負荷が臨界レベルに到達するまで待機することなく効率的なライブエンコーディングを維持するために、連続的エンコーディングプロセスの一部としてエンコードされたフレーム複製を実施することができる。該いくつかの実施形態は、より低いパワーのライブエンコーディングサーバ上で利用され得る。
【００３７】
（ＭＰＥＧ−ＤＡＳＨライブエンコーディング）
ＭＰＥＧ−ＤＡＳＨ（ＩＳＯ／ＩＥＣ  ２３００９−１）は、インターネットを経由してマルチメディアコンテンツをストリーミングするための規格である。ＭＰＥＧ−ＤＡＳＨは、Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ（ＭＰＥＧ）によって開発された。ＭＰＥＧは、ＭＰＥＧ−２、ＭＰＥＧ−４、ＭＰＥＧ−７、ＭＰＥＧ−２１、およびその他を含む、以前のマルチメディア規格の開発に関与している。ＭＰＥＧ−ＤＡＳＨは、ＨＴＴＰを使用して、適応セグメント化メディア送達を提供する。ＭＰＥＧ−ＤＡＳＨ仕様は、ＭＰＤおよびセグメントフォーマットのみを定義する。留意すべきこととして、ＭＰＤおよびセグメントを含むメディアエンコードフォーマットの送達、ならびにフェッチ、適応ヒューリスティックス、およびコンテンツ再生に関するクライアント挙動は、ＭＰＥＧ−ＤＡＳＨ規格内で定義されていない。
【００３８】
図８は、本発明の実施形態による、ＭＰＥＧ−ＤＡＳＨを利用するライブエンコーディングシステムに関する例示的データフロー図を概念的に図示する。図８は、メディアフィードデータ８１０と、ライブエンコーディングシステム８２０と、ＨＴＴＰ要求８３０と、要求されたストリームセグメント８４０と、ストリーミングクライアント８５０と、メディアプレゼンテーション記述８６０とを含む。示されないが、メディアフィードデータ８１０、ＨＴＴＰ要求８３０、要求されたストリームセグメント８４０、およびメディアプレゼンテーション記述８６０は、通信ネットワークを経由して伝送されることができる。通信ネットワークは、（限定ではないが）インターネットを含むことができる。
【００３９】
示されるように、ライブエンコーディングシステム８２０は、メディアフィードデータ８１０を受信している。メディアフィードデータ８１０は、少なくとも上記に議論されるタイプの受信されるメディアを含むことができる。ライブエンコーディングシステム８２０は、受信されたメディアフィードデータ８１０から出力ストリームを生成することができる。受信されたメディアフィードデータ８１０からの出力ストリームの生成中、ライブエンコーディングシステム８２０は、メディアフィードデータ８１０の受信のレート、ライブエンコーディングシステム８２０に対する負荷レベル、メディアフィードデータ８１０の伝送をサポートする通信ネットワークにおける負荷レベル、メディアフィードデータ８１０内のギャップ、および／またはライブエンコーディングシステム８２０によるストリームの生成におけるギャップの評価に基づいて、メディアフィードデータ８１０からフレームを複製する、および／またはメディアフィードデータ８１０からフレームを拡張することができる。
【００４０】
ライブエンコーディングシステム８２０はまた、ＨＴＴＰ要求８３０を受信する。ＨＴＴＰ要求に応答して、ライブエンコーディングシステム８２０は、要求されたストリームセグメント８４０を提供する。ＨＴＴＰ要求８３０は、生成された出力ストリームのうちの１つからの具体的セグメントに関するバイト範囲要求を含むことができる。ライブエンコーディングシステム８２０は、別個のライブエンコーディングサーバおよびＨＴＴＰサーバを含む、複数のコンポーネントを含むことができる。ＨＴＴＰサーバは、クライアントとのメディアセグメントおよび要求のＨＴＴＰ通信をサポートすることができる。さらに、ＨＴＴＰサーバは、ストリーミングクライアント８５０へのメディアセグメントの送達を補助するために、ＨＴＴＰベースのコンテンツ配信ネットワーク（ＣＤＮ）を利用することができる。
【００４１】
ＭＰＥＧ−ＤＡＳＨは、ストリームセグメントに関するＨＴＴＰ要求を介してアクセスされ得る、いくつかのアダプティブビットレートストリームを記述する良好に構築されたＸＭＬマニフェストをクライアントに提供するために、Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ（ＭＰＤ）を使用する。各ＭＰＤは、いくつかの記述されるアダプティブビットレートストリームを介して閲覧され得る、単一メディアプレゼンテーションに対応する。ＭＰＤは、アクセス可能メディアセグメントおよびアクセス可能メディアセグメントに関する対応するタイミングを記述する。ＭＰＤは、（階層の最上位から下降して）メディアプレゼンテーション、ピリオド、アダプテーションセット、リプレゼンテーション、およびセグメントを含む階層データモデルである。メディアプレゼンテーションは、ライブブロードキャスト、ライブストリーム、ライブイベント、および／または事前記録されたメディアプレゼンテーションを含むことができる。メディアプレゼンテーションは、継ぎ合わされる、および／またはいくつかのピリオドを含むことができる。ピリオドは、デフォルトでリンク付けられず、機能のいずれの損失も伴わずにピリオド間で継ぎ合わされた広告ピリオドを有することができる。ピリオドは、いくつかのアダプテーションセットを含むことができる。アダプテーションセットは、ライブスポーツイベントからの異なるカメラ等、同一プレゼンテーション上の異なる視点を含むことができる。加えて、異なるアダプテーションセットは、オーディオアダプテーションセットおよびビデオアダプテーションセット等の異なるフォーマットを含むことができる。各アダプテーションセット内には、いくつかのリプレゼンテーションが、含まれ得る。リプレゼンテーションは、同一プレゼンテーションからの異なる帯域幅および／または最大ビットレートレベルの選択をサポートする。したがって、ＭＰＥＧ−ＤＡＳＨのクライアントは、帯域幅および／またはクライアント負荷が許容するような異なるリプレゼンテーションに切り替えることによって、アダプティブビットレートストリーミングを使用することができる。各リプレゼンテーションは、ＨＴＴＰを介して要求され得るメディアのセグメントを含む。ＨＴＴＰ要求は、各セグメントと関連付けられる事前フォーマットされたＵＲＬにおいて受信される。
【００４２】
図９は、ＭＰＥＧ−ＤＡＳＨからの例示的Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  ＭＰＤデータモデルを概念的に図示する。示されるように、メディアプレゼンテーション９１０は、いくつかのピリオド９１５−９２５を含む。ピリオド９１５−９２５は、それぞれ、異なるピリオド開始時間を含む。開始時間１００秒におけるピリオド９２０は、いくつかの含まれるアダプテーションセット９２５−９３０を示すように拡大される。アダプテーションセット１  ９２５は、メディアプレゼンテーション９１０のカメラ１からのビデオを含む。アダプテーションセット２  ９３０は、メディアプレゼンテーション９１０に関するオーディオを含む。アダプテーションセット３  ９３５は、メディアプレゼンテーション９１０のカメラ２からのビデオを含む。アダプテーションセット１  ９２５は、リプレゼンテーション１  ９４０およびリプレゼンテーション２  ９４５を示すように拡大されている。リプレゼンテーション１  ９４０は、アダプテーションセット１  ９２５に関する５００ｋｂ／ｓリプレゼンテーションである一方、リプレゼンテーション２  ９４５は、アダプテーションセット１  ９２５に関する２５０ｋｂ／ｓリプレゼンテーションである。初期化セグメント１００およびメディアセグメント９５５−９６５が、リプレゼンテーション１  ９４０内にある。これらのセグメントは、それらの中に含まれるメディアを受信するために、ＨＴＴＰを介してストリーミングクライアントによって要求される。
【００４３】
留意すべきこととして、図９に図示される楕円の事例は、付加的ピリオド、アダプテーションセット、プレゼンテーション、およびセグメントの可能性を示す。図９に提示される例示的ＭＰＤは、単に、本発明の種々の実施形態によってサポートされる任意の種々の構成からの１つの可能な実施例である。例えば、本発明の異なる実施形態は、図９に図示される実施形態において例示目的として提供されるものよりも多くの他の最大ビットレートをサポートすることができる。
【００４４】
（ライブエンコーディングサーバアーキテクチャ）
本発明の実施形態によるライブエンコーディングサーバ１０００のアーキテクチャが、図１０に図示される。ライブエンコーディングサーバ１０００は、不揮発性メモリ１０３０と、揮発性メモリ１０２０と、ネットワークインターフェース１０４０と通信するプロセッサ１０１０を含む。図示される実施形態では、不揮発性メモリは、入力データ対処アプリケーション１０５０と、デマルチプレクサアプリケーション１０５５と、リパッケージャアプリケーション１０６０と、ＭＰＤ組み合わせアプリケーション１０６５と、ＭＰＤ生成アプリケーション１０７０と、ＨＴＴＰ要求アプリケーション１０７５と、オーディオデコーダアプリケーション１０８０と、オーディオエンコーダアプリケーション１０８５と、ビデオデコーダアプリケーション１０９０と、ビデオエンコーダアプリケーション１０９５とを含む。留意すべきこととして、ライブエンコーディングサーバ１０００は、ストリームのためのＭＰＤファイルを準備し、ＨＴＴＰ要求を通して出力ストリームのセグメントをストリーミングクライアントに提供する、ｍｐｅｇ−ｄａｓｈフォーマットライブエンコーディングサーバである。他の実施形態は、異なるフォーマットを利用し、該異なるフォーマットをサポートするために、必要に応じて、異なるアプリケーションを含み得る。
【００４５】
入力データ対処アプリケーション１０５０は、ネットワークインターフェース１０４０から入力ストリームを受信する。入力ストリームは、（限定ではないが）ビデオコンテンツのライブストリーム、メディアプレゼンテーション、ビデオ専用ファイル、オーディオ専用ファイル、スポーツイベント、ウェブストリーム、および／またはｍｐｅｇ−ｄａｓｈ規格ストリームを含むことができる。入力データ対処アプリケーション１０５０は、入力ストリームの識別を含む、付加的機能を実施することができる。識別は、入力ストリームとともに含まれるメタデータを使用して、ならびに／または入力ストリームの特性およびパラメータを評価して実施されることができる。
【００４６】
デマルチプレクサアプリケーション１０５５は、入力ストリームから個々のエレメンタリストリームを多重分離する。例えば、デマルチプレクサアプリケーション１０５５は、入力ストリーム内のオーディオ、ビデオ、および／または字幕ストリームを取り出すことができる。多重分離されたストリームは、他のアプリケーションによって実施される後続動作において分析、デコード、および再エンコードされることができる。
【００４７】
リパッケージャアプリケーション１０６０は、全体的ライブエンコーディングサーバ動作の一部として、再エンコード、複写、およびフレーム拡張動作を実施することができる。リパッケージャアプリケーション１０６０は、ストリームを再パッケージ化するために、必要に応じて、入力データ対処アプリケーション１０５０、デマルチプレクサアプリケーション１０５５、ネットワークインターフェース１０４０、および／またはライブエンコーディングサーバ１０００の任意の他の構成要素から入力ストリームを受信することができる。リパッケージャアプリケーション１０６０は、必要に応じて、ビデオデコーダアプリケーション１０９０およびビデオエンコーダアプリケーション１０９５を利用して、受信されたメディアの着信ライブフレームをいくつかの出力ストリームに再エンコードすることができる。再エンコード動作中、リパッケージャアプリケーション１０６０は、いくつかの尺度に従って、ライブエンコーディングサーバ１０００のネットワークおよび／またはサーバ負荷レベルを評価することができる。これらの評価に基づいて、リパッケージャアプリケーション１０６０は、サーバ負荷レベルを低減させるために着信フレームを複写し、かつ／または着信ネットワーク帯域幅において予測される降下を補償するために特定のフレームを拡張することができる。リパッケージャアプリケーション１０６０は、フレームのタイムコードおよび／またはタイムスタンプを操作することによって、フレームを拡張し、出力ストリームにおけるその持続時間を増加させることができる。リパッケージャアプリケーション１０６０は、ＨＴＴＰ要求アプリケーション１０７５を利用して後でクライアントにストリーミングすることに備えて、出力ストリームの再パッケージ化され、再エンコードされ、複写され、かつ／または拡張されたフレームをＭＰＤ組み合わせアプリケーション１０６５および／またはＭＰＤ生成アプリケーション１０７０に提供することができる。
【００４８】
ＭＰＤ組み合わせアプリケーション１０６５は、リパッケージャアプリケーション１０６０によって生成された複数の出力ストリームを単一プレゼンテーションに組み合わせる。ＭＰＤ組み合わせアプリケーション１０７０は、組み合わせられたプレゼンテーションのためのＭＰＤファイルを生成することができる。上記に議論されるように、ＭＰＤファイルは、メディアプレゼンテーションのピリオド、アダプテーションセット、リプレゼンテーション、およびセグメントを記述することができる。ＭＰＤ組み合わせアプリケーション１０７０は、生成された出力ストリームの特性に従ってＭＰＤを生成する。これらの特性は、リパッケージャアプリケーション１０６０によって実施される動作に従って変動する。ＭＰＤファイルは、典型的には、ｍｐｅｇ−ｄａｓｈストリーミングセッションを開始するために、最初に要求され、ストリーミングクライアントに提供される。
【００４９】
ＨＴＴＰ要求アプリケーション１０７５は、ＨＴＴＰ要求に対処し、該ＨＴＴＰ要求に従ってサーバメディアセグメントに対処する。ＨＴＴＰ要求アプリケーション１０７５は、ネットワークインターフェース１０４０を通してストリーミングクライアントに通信し得る。いくつかの実施形態では、ＨＴＴＰ要求アプリケーション１０７５は、ライブエンコーディングサーバとは別個のＨＴＴＰサーバにおいてホストされる。
【００５０】
不揮発性メモリは、オーディオデコーダアプリケーション１０８０と、オーディオエンコーダアプリケーション１０８５と、ビデオデコーダアプリケーション１０９０と、ビデオエンコーダアプリケーション１０９５とを含む。不揮発性メモリ１０３０は、単一ビデオデコーダアプリケーション１０９０および単一ビデオエンコーダアプリケーション１０９５のみを含むが、他の実施形態は、複数のビデオエンコーダおよびビデオデコーダアプリケーションを含み得る。さらに、いくつかの実施形態は、各異なる出力ストリームを生成するように、別個のリパッケージャ、デコーダ、およびエンコーダアプリケーションを有するために、出力ストリーム毎にアプリケーションのセットを利用し得る。
【００５１】
いくつかの実施形態では、ネットワークインターフェース１０４０は、プロセッサ１０１０、揮発性メモリ１０２０、および／または不揮発性メモリ１０３０と通信し得る。ライブエンコーディングサーバ１０００の不揮発性メモリ１０３０内に記憶されるアプリケーションの上記の議論は、ライブエンコーディングサーバ１０００をサポートするためのアプリケーションの一例示的セットを議論する。本発明の他の実施形態は、本発明を実装するために、必要に応じて、複数のサーバおよび／または場所にわたって分散される、以下に議論される機能を伴う複数のサーバを利用し得る。さらに、以下に議論されるアプリケーションは、本発明を実装するために、必要に応じて、１つまたは複数のアプリケーションに組み合わせられ、ソフトウェアモジュールとして実装され得る。例えば、以下に議論されるアプリケーションは、代替として、ライブエンコーディングサーバ１０００上に常駐する単一アプリケーションのモジュールとして実装され得る。さらに、単一アプリケーションが示されているが、他の実施形態は、類似する機能の専用である複数のアプリケーションを利用し得る。
【００５２】
上記に議論される種々のプロセスは、単一の個別サーバ上に実装されることができる。代替として、それらは、それぞれ、任意の数の物理的、仮想、またはクラウドコンピューティングデバイス上の共有および／または個別サーバとして実装されることができる。具体的には、本発明のいくつかの実施形態によるライブエンコーディングシステムは、別個のエンコーディングサーバ（単数または複数）およびＨＴＴＰサーバ（単数または複数）を含み得る。当業者は、種々の実装方法が本発明の実施形態のプロセスサーバを実装するために使用され得ることを認識する。
【００５３】
上記の説明は、本発明の多くの具体的実施形態を含むが、これらは、本発明の範囲に対する限定として解釈されるべきではなく、むしろ、その一実施形態の実施例として解釈されるべきである。故に、本発明の範囲は、図示される実施形態ではなく、添付される特許請求の範囲およびその均等物によって決定されるべきである。
【図１】
2019193312.tif 000003
【図２】
2019193312.tif 000004
【図３】
2019193312.tif 000005
【図４】
2019193312.tif 000006
【図５】
2019193312.tif 000007
【図６】
2019193312.tif 000008
【図７】
2019193312.tif 000009
【図８】
2019193312.tif 000010
【図９】
2019193312.tif 000011
【図１０】
2019193312.tif 000012
【外国語明細書】
2019193312000001.pdf