特許 7052070 メディアファイルのネットワーク再生方法、装置及び記憶媒体

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-04-01

(45)【発行日】2022-04-11

(54)【発明の名称】メディアファイルのネットワーク再生方法、装置及び記憶媒体

(51)【国際特許分類】

   H04N 21/438 20110101AFI20220404BHJP

   G06F 13/00 20060101ALI20220404BHJP

【ＦＩ】

H04N21/438

G06F13/00

【請求項の数】 14

(21)【出願番号】P 2020554341

(86)(22)【出願日】2018-08-31

(65)【公表番号】

(43)【公表日】2021-03-11

(86)【国際出願番号】 CN2018103443

(87)【国際公開番号】W WO2019227736

(87)【国際公開日】2019-12-05

【審査請求日】2020-06-24

(31)【優先権主張番号】201810531180.4

(32)【優先日】2018-05-29

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】520476341

【氏名又は名称】北京字節跳動網絡技術有限公司

【氏名又は名称原語表記】Ｂｅｉｊｉｎｇ Ｂｙｔｅｄａｎｃｅ Ｎｅｔｗｏｒｋ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ．

【住所又は居所原語表記】Ｒｏｏｍ Ｂ－００３５， ２／Ｆ， Ｎｏ．３ Ｂｕｉｌｄｉｎｇ， Ｎｏ．３０， Ｓｈｉｘｉｎｇ Ｒｏａｄ， Ｓｈｉｊｉｎｇｓｈａｎ Ｄｉｓｔｒｉｃｔ Ｂｅｉｊｉｎｇ １０００４１ Ｃｈｉｎａ

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】▲銀▼ 国徽

【審査官】大西 宏

(56)【参考文献】

【文献】特開２００６－３２３６７８（ＪＰ，Ａ）

【文献】特開２０１７－０９８７０６（ＪＰ，Ａ）

【文献】国際公開第２０１６／０６３７８０（ＷＯ，Ａ１）

【文献】米国特許出願公開第２０１３／０２９８１７１（ＵＳ，Ａ１）

【文献】中国特許出願公開第１０７６１３０２９（ＣＮ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｎ ７／１０

Ｈ０４Ｎ ７／１４ － ７／１７３

Ｈ０４Ｎ ７／２０ － ７／５６

Ｈ０４Ｎ ２１／００ －２１／８５８

Ｇ０６Ｆ １３／００

(57)【特許請求の範囲】

【請求項1】

メディアファイルのネットワーク再生方法であって、
非ストリーミングメディアパッケージフォーマットを採用するメディアファイルをウェブページで再生する、ウェブページに埋め込まれたプレイヤーによって、サーバからメディアファイルにおけるメディアデータを取得することと、
前記プレイヤーによって、前記メディアデータを含むセグメントメディアファイルを構築することと、
前記プレイヤーによって、前記セグメントメディアファイルをメディアソース拡張インターフェースに送信し、前記メディアソース拡張インターフェースを介して前記ウェブページのメディア要素を呼び出して再生を行うことと
を含み、
設定されたオフセット量及びサイズによって前記サーバに要求したメタデータから、完全なメディア情報が識別されていない場合、メタデータボックスのヘッド部から前記メタデータボックスのオフセット量及びサイズを算出することと、
前記サーバに前記メディアファイルにおける、マルチメディアファイルにおいて前記オフセット量から始まり、且つ、前記サイズに該当する前記メタデータを要求することと、
取得された前記メタデータから対応するメディア情報を識別して得ることと
をさらに含む、メディアファイルのネットワーク再生方法。

【請求項2】

前記プレイヤーによって、前記メディアデータを含むセグメントメディアファイルを構築することは、
取得されたメディアファイルにおけるメディアデータ、及び、前記メディアファイル中のメタデータに基づいて、セグメントメディアファイルレベルのメタデータを算出することと、
取得されたメディアファイルにおけるメディアデータ、及び前記セグメントメディアファイルレベルのメタデータを、セグメントメディアファイル容器にパッケージして、前記セグメントメディアファイルを得ることと
を含む請求項１に記載の方法。

【請求項3】

サーバからメディアファイルにおけるメディアデータを取得することは、
前記メディアファイルから識別されたメディア情報に基づいて、前記メディアファイルにおけるリアルタイム再生ポイントに続く２つのキーフレームを特定することと、
前記メディアファイルにおける前記２つのキーフレームの間のメディアデータを取得することを要求するためのネットワーク要求を、前記サーバに送信することと、
前記サーバから返された前記２つのキーフレームの間のメディアデータを受信することと
を含む請求項１に記載の方法。

【請求項4】

メディアファイルから識別されたメディア情報に基づいて、前記メディアファイルにおける、前記２つのキーフレームの間のビデオフレームのオフセット量及びサイズ、及び、前記メディアファイルにおける、前記ビデオフレームに合わせたオーディオフレームのオフセット量及びサイズを特定することと、
特定されたオフセット量及びサイズに基づいて、前記ネットワーク要求に持たされた目標区間のオフセット量及びサイズを特定して、前記サーバに前記目標区間に含まれている前記ビデオフレーム及び前記オーディオフレームを要求することと
をさらに含む請求項３に記載の方法。

【請求項5】

前記サーバから前記メディアファイルにおけるメディアデータを取得する前に、
設定されたオフセット量及びサイズに基づいて、前記サーバに前記メディアファイルにおける、マルチメディアファイルにおいて前記オフセット量から始まり、且つ前記サイズに該当するメタデータを要求することと、
前記サーバから返された前記メタデータから、要求されたメディアデータが前記メディアファイルでのオフセット量及びサイズを位置決めするためのメディア情報を識別することと
をさらに含む請求項１に記載の方法。

【請求項6】

前記メディアソース拡張インターフェースを介して前記ウェブページのメディア要素を呼び出して再生を行うことは、
前記メディアソース拡張インターフェースが、受信された前記セグメントメディアファイルを前記メディアソース拡張インターフェースにおけるメディアソースオブジェクトに追加することと、
前記メディアソースオブジェクトに対応する仮想アドレスを作成することと、
ブラウザのメディア要素に、前記メディア要素が前記メディアソースオブジェクトをデータ源として再生を行うために使われる前記仮想アドレスを伝送することと
を含む請求項１に記載の方法。

【請求項7】

ウェブページで非ストリーミングメディアパッケージフォーマットを採用したメディアファイルを再生する、前記ウェブページに埋め込まれたプレイヤーに設けられたメディアファイルのネットワーク再生装置であって、
サーバからメディアファイルにおけるメディアデータを取得するように配置された取得ユニットと、
前記メディアデータを含むセグメントメディアファイルを構築するように配置された構築ユニットと、
前記セグメントメディアファイルをメディアソース拡張インターフェースに送信し、前記メディアソース拡張インターフェースを介して前記ウェブページのメディア要素を呼び出して再生を行う再生ユニットと
を含み、
前記取得ユニットは、
設定されたオフセット量及びサイズによって前記サーバに要求したメタデータから、完全なメディア情報が識別されていない場合、メタデータボックスのヘッド部から前記メタデータボックスのオフセット量及びサイズを算出し、
前記サーバに前記メディアファイルにおける、マルチメディアファイルにおいて前記オフセット量から始まり、且つ、前記サイズに該当する前記メタデータを要求し、
取得された前記メタデータから対応するメディア情報を識別して得るようにさらに配置された、装置。

【請求項8】

前記構築ユニットは、
取得されたメディアファイルにおけるメディアデータ、及び前記メディアファイルにおけるメタデータに基づいて、セグメントメディアファイルレベルのメタデータを算出し、
取得されたメディアファイルにおけるメディアデータ、及び前記セグメントメディアファイルレベルのメタデータをセグメントメディアファイル容器にパッケージして、前記セグメントメディアファイルを得るように配置された
請求項７に記載の装置。

【請求項9】

前記取得ユニットは、
前記メディアファイルから識別されたメディア情報に基づいて、前記メディアファイルにおけるリアルタイム再生ポイントに続く２つのキーフレームを特定し、
前記メディアファイルにおける前記２つのキーフレームの間のメディアデータを取得することを要求するためのネットワーク要求を、前記サーバに送信し、
前記サーバから返された前記２つのキーフレームの間のメディアデータを受信するように配置された
請求項７に記載の装置。

【請求項10】

前記取得ユニットは、
メディアファイルから識別されたメディア情報に基づいて、前記メディアファイルにおける、前記２つのキーフレームの間のビデオフレームのオフセット量及びサイズ、及び、前記メディアファイルにおける、前記ビデオフレームに合わせたオーディオフレームのオフセット量及びサイズを特定し、
特定されたオフセット量及びサイズに基づいて、前記ネットワーク要求に持たされた目標区間のオフセット量及びサイズを特定して、前記サーバに前記目標区間に含まれている前記ビデオフレーム及び前記オーディオフレームを要求するように配置された
請求項９に記載の装置。

【請求項11】

要求ユニットをさらに含み、
前記要求ユニットは、設定されたオフセット量及びサイズに基づいて、前記サーバに前記メディアファイルにおける、マルチメディアファイルにおいて前記オフセット量から始まり、且つ前記サイズに該当するメタデータを要求し、
前記サーバから返された前記メタデータから、前記メディアファイルにおける、要求されたメディアデータのオフセット量及びサイズを位置決めするためのメディア情報を識別するように配置された
請求項７に記載の装置。

【請求項12】

前記メディアソース拡張インターフェースが、受信された前記セグメントメディアファイルを前記メディアソース拡張インターフェースにおけるメディアソースオブジェクトに追加し、
前記メディアソースオブジェクトに対応する仮想アドレスを作成し、
ブラウザのメディア要素に、前記メディア要素が前記メディアソースオブジェクトをデータ源として再生を行うために使われる前記仮想アドレスを伝送する
請求項７に記載の装置。

【請求項13】

メディアファイルのネットワーク再生装置であって、
実行可能な指令を記憶するように配置されたメモリと、
前記メモリに記憶された実行可能な指令を実行することで、請求項１～６のいずれか一項に記載のメディアファイルのネットワーク再生方法を実現するように配置されたプロセッサとを含む
ネットワーク再生装置。

【請求項14】

請求項１～６のいずれか一項に記載のメディアファイルのネットワーク再生方法を実行するための、実行可能な指令が記憶されたコンピュータで読み取り可能な記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本願は、出願番号が２０１８１０５３１１８０.４であり、出願日が２０１８年０５月２９日である中国特許出願に基づいて提出されたものとして、当該中国特許出願の優先権を主張し、当該中国特許出願のすべての内容は参照により本願に組み入れられる。

【0002】

本開示は、メディアファイルのネットワーク再生技術に関し、特に、メディアファイルのネットワーク再生方法、装置及び記憶媒体に関する。

【背景技術】

【0003】

ウェブページに埋め込まれたプレイヤーは、ウェブページのハイパーテキスト・マークアップ・ランゲージ（ＨＴＭＬ、Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）５メディア要素によって再生を行い、プレイヤーは、ウェブページでメディアファイルを再生するが、関連技術では、ストリーミングメディアファイル（例えば、ＨＴＴＰライブストリーミング（ＨＬＳ、ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ））に対する再生しかサポートできず、ネットワークでの非ストリーミングメディアパッケージフォーマットのメディアファイル（例えば、動画専門家集団（ＭＰＥＧ、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）-４ファイル）については、その技術自体がストリーミングメディアファイルのネットワーク再生をサポートため、プレイヤーはウェブページで非ストリーミングメディアパッケージフォーマットのメディアファイルを再生する際、メディアファイルをフォーマット変換し、ストレージサービスとコンテンツ配信ネットワーク（ＣＤＮ、Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）を配置する必要が生じ、メディアファイルを再生するリアルタイムコストが高くなるだけではなく、ネットワークシステムアーキテクチャの負荷も増加している。

【発明の概要】

【課題を解決するための手段】

【0004】

これに鑑みて、本開示の実施例は、再生メディアファイルのリアルタイムコストを低減させ、ネットワークシステムアーキテクチャの負荷を軽減させることができるメディアファイルのネットワーク再生方法、装置及び記憶媒体を提供する。

【0005】

一方、本開示の実施例は、
ウェブページに埋め込まれたプレイヤーであって、前記ウェブページで非ストリーミングメディアパッケージフォーマットを採用するメディアファイルを再生するプレイヤーによって、サーバからメディアファイルにおけるメディアデータを取得することと、
前記プレイヤーによって、前記メディアデータを含むセグメントメディアファイルを構築することと、
前記プレイヤーによって前記セグメントメディアファイルを前記メディアソース拡張インターフェースに送信し、前記メディアソース拡張インターフェースを介して前記ウェブページのメディア要素を呼び出し、再生を行うこととを含む
メディアファイルのネットワーク再生方法を提供する。

【0006】

他方では、本開示の実施例は、
前記ウェブページで非ストリーミングメディアパッケージフォーマットを採用したメディアファイルを再生する、ウェブページに埋め込まれたプレイヤーに設けられたメディアファイルのネットワーク再生装置であって、
サーバからメディアファイルにおけるメディアデータを取得するように配置された取得ユニットと、
前記メディアデータを含むセグメントメディアファイルを構築するように配置された構築ユニットと、
前記セグメントメディアファイルを前記メディアソース拡張インターフェースに送信し、前記メディアソース拡張インターフェースを介して前記ウェブページのメディア要素を呼び出して再生を行う再生ユニットと、を含む
メディアファイルのネットワーク再生装置を提供する。

【0007】

さらに、他方では、本開示の実施例は、
実行可能な指令を記憶するように配置されたメモリと、
前記メモリに記憶された実行可能な指令を実行することで、上述のメディアファイルのネットワーク再生方法を実現するように配置されたプロセッサとを含む
メディアファイルのネットワーク再生装置。

【0008】

さらに、他方では、本開示の実施例は、実行されることで、上述のメディアファイルのネットワーク再生方法が実現される、実行可能な指令が記憶された記憶媒体を提供する。

【0009】

本開示の実施例によれば、以下のような技術効果を奏する。

【0010】

１）フロントエンドプレイヤーが非ストリーミングメディアパッケージフォーマットのメディアファイルをセグメントメディアファイルに変換することで、ストレージサービス及びＣＤＮを配置する必要がなくなり、非ストリーミングメディアパッケージフォーマットのメディアファイルを再生するリアルタイムコストを低減させ、ネットワークシステムアーキテクチャの負荷を低減させる。

【0011】

２）非ストリーミングメディアパッケージフォーマットのメディアファイルにおけるメディアデータを、セグメントメディアファイルに変換し、ウェブページのメディアソース拡張インターフェースを介して、ウェブページのメディア要素に送信して復号及び再生を行うことで、プレイヤーがその埋め込まれたウェブページによって非ストリーミングメディアフォーマットのメディアファイルを再生することを実現し、非ストリーミングメディアパッケージフォーマットファイルを完全にダウンロードしてからこそ単独で再生できる制限を克服する。

【0012】

３）パッケージして得られたセグメントメディアファイルは、取得されたメディアファイルの全部のメディアデータではなく、メディアファイルの一部のメディアデータに基づくため、変換遅延が小さくなり、予め記憶しておく必要がなくなり、当初のメディアファイル以外は、余分なストレージスペースを占有しないため、ストレージスペースの占有を格段に低減させる。

【0013】

４）ウェブページのメディア要素は、メディアファイルの真のアドレスに基づいてメディアデータを取得してから再生を行うのではなく、メディアソース拡張インターフェースを介してセグメントメディアファイルを取得してコード及び再生を行うことによって、メディアファイルの真のアドレスに対する保護を実現する。

【図面の簡単な説明】

【0014】

【図1】本開示の実施例による容器の一選択可能な構成模式図である。

【図2】本開示の実施例によるＭＰ４ファイルの一選択可能なパッケージ構成模式図である。

【図3】本開示の実施例によるメディアファイルにおけるメディアデータ容器にメディアデータが記憶される構成模式図である。

【図4】本開示の実施例によるＦＭＰ４ファイルの一選択可能なパッケージ構成模式図である。

【図5】本開示の実施例によるメディアファイルのネットワーク再生システムのアーキテクチャ模式図である。

【図6】本開示の実施例によるメディアファイルのネットワーク再生制御装置の一選択可能な構成模式図である。

【図7】本開示の実施例によるメディアファイルのネットワーク再生方法の一選択可能なプロセスフロー模式図である。

【図8】本開示の実施例のメディアファイルにおけるメディアデータを取得する一選択可能なプロセスフロー模式図である。

【図9】本開示の実施例のメディアファイルからメディア情報を識別する一選択可能なプロセスフロー模式図である。

【図10】本開示の実施例によるプレイヤーがウェブページのメディアソース拡張インターフェースを介してセグメントメディアファイルをウェブページのメディア要素に送信して復号及び再生を行うフロー模式図である。

【図11】本開示の実施例によるプレイヤーがウェブページのメディアソース拡張インターフェースを介してセグメントメディアファイルを再生する一選択可能な模式図である。

【図12】本開示の実施例によるＭＰ４ファイルをＦＭＰ４ファイルに変換し、メディアソース拡張インターフェースを介して再生する一模式図である。

【図13】本開示の実施例メディアファイルのネットワーク再生装置の一選択可能な構成部材の模式図である。

【発明を実施するための形態】

【0015】

以下、本開示の目的、技術形態、及び利点をより明確にするために、添付の図面を参照し本開示について更なる詳細な説明を行い、説明される実施例が本開示を制限すると理解してはならず、当業者が創造的な労働を必要とせずに得られた他の全ての実施例は、いずれも本開示の保護範囲に入る。

【0016】

別に定義されていない限り、本明細書で使われる全ての技術用語と科学用語は、本開示が属する技術分野の技術者が、一般的に理解する意味と同じである。本明細書で使われる用語は、単に具体的な実施例を説明するためであり、本開示を制限しようとするのではない。

【0017】

本開示について更なる詳細な説明をする前に、本開示の実施例に係る名詞や用語を説明し、本開示の実施例に係る名詞や用語は以下のような分析に適用される。

【0018】

１）メディアファイルは、容器（Ｂｏｘ、容器とも呼ぶ）の方式でコーディングするメディアデータ（例えば、オーディオデータとビデオデータとのうちの少なくとも一方）を記憶するファイルとして、それには、メディアデータを説明するデータであるメタデータが含まれており、メタデータには、メディアデータが正確に復号されることを確保するメディア情報が記載されている。

【0019】

例えば、ＭＰ４容器フォーマットパッケージマルチメディアデータのファイルは、ＭＰ４ファイルと呼ばれ、典型的には、ＭＰ４ファイルには、アドバンスドビデオコーディング（ＡＶＣ、Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ、即Ｈ.２６４）又はＭＰＥＧ-４（Ｐａｒｔ ２）規格でコーディングされたビデオデータと、アドバンスドオーディオコーディング（ＡＡＣ、Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ）規格でコーディングされたオーディオデータが記憶され、もちろん、ビデオ及びオーディオのような他のコーディング方式を除外するわけではない。

【0020】

２）容器（Ｂｏｘ）は、容器とも呼ばれ、一意のタイプ識別子と長さによって定義されるオブジェクト指向のアーティファクトであり、図１を参照すると、本開示の実施例による容器の一選択可能な構成模式図であり、容器ヘッド部（Ｂｏｘ Ｈｅａｄｅｒ）と容器データ（Ｂｏｘ Ｄａｔａ）とを含み、ここには、各種の情報を示すためのバイナリデータが充填されている。

【0021】

容器ヘッド部は、サイズ（ｓｉｚｅ）とタイプ（ｔｙｐｅ）を含み、サイズは容器が占めるストレージスペースの大きさ（本明細書では、容量又は長さとも呼ぶ）を説明し、タイプは容器のタイプを説明し、図２を参照すると、本開示の実施例によるＭＰ４ファイルの一選択可能なパッケージ構成模式図であり、ＭＰ４ファイルに係わる基本的な容器タイプはファイルタイプ容器（ｆｔｙｐ ｂｏｘ）、メタデータ容器（ｍｏｏｖ ｂｏｘ）、及びメディアデータ容器（ｍｄａｔ ｂｏｘ）を含む。

【0022】

容器データ部分は、具体的なデータを記憶することができ、この際の容器を「データ容器」と呼び、容器データ部分も他のタイプの容器をパッケージすることができ、この際の容器を「容器の容器」と呼ぶ。

【0023】

３）トラック（Ｔｒａｃｋ）は、メディアデータ容器で時間順に並べられた関連するサンプリング（Ｓａｍｐｌｅ）であり、メディアデータにとって、トラックは１つのビデオフレームシーケンス又は１つのオーディオフレームシーケンスを示し、ビデオフレームシーケンスと同期する字幕トラックを含むこともでき、同一トラックにおける１組の連続するサンプリングを、チャンク（Ｃｈｕｎｋ）と呼ぶ。

【0024】

４）ファイルタイプ容器は、メディアファイルにおいてファイルのサイズ（即ち、占有したバイトの長さ）とタイプを記憶するための容器であり、図２に示すように、ファイルタイプ容器に記憶されたバイナリデータは、規格のバイト長さに従って、容器のタイプとサイズを説明した。

【0025】

５）メタデータ容器は、メディアファイルにおいてメタデータ（即ち、メディアデータ容器に記憶されたマルチメディアデータを説明するデータ）を記憶するための容器であって、ＭＰ４ファイルにおけるメタデータ容器に記憶されたバイナリデータによって示さる情報をメディア情報と呼ぶ。

【0026】

図２に示すように、メタデータ容器のヘッド部は、バイナリデータで容器のタイプを「ｍｏｏｖ ｂｏｘ」として示し、容器データはＭＰ４ファイルの全体情報を記憶するためのｍｖｈｄ容器を一部パッケージし、ＭＰ４ファイルと独立しており、ＭＰ４ファイルの再生に関連し、時間長、作成時間や変更時間などを含む。

【0027】

メディアファイルのメディアデータ容器には、複数のトラックに対応するサブ容器、例えばオーディオトラック容器（ａｕｄｉｏ ｔｒａｃｋ ｂｏｘ）とビデオトラック容器（ｖｉｄｅｏ ｔｒａｃｋ ｂｏｘ）を含むことができ、オーディオトラック容器とビデオトラック容器とのサブ容器のいずれにも、対応するトラックのメディアデータの参照と説明が含まれており、必要なサブ容器は、トラックの特性と全体情報（例えば、時間長、幅と高さ）を説明するための容器（ｔｋｈｄ ｂｏｘと記す）と、トラックのメディア情報（例えば、メディアタイプとサンプリングの情報）を記録する容器（ｍｄｉａ ｂｏｘと記す）とを含む。

【0028】

ｍｄｉａ ｂｏｘにおいてパッケージされたサブ容器は、トラックの関連属性と内容を記録する容器（ｍｄｈｄ ｂｏｘと記す）と、メディアの再生過程情報を記録する容器（ｈｄｌｒ ｂｏｘと記す）と、トラックにおけるメディアデータを説明するメディア情報の容器（ｍｉｎｆ ｂｏｘと記す）とを含むことができ、ｍｉｎｆ ｂｏｘには如何にメディア情報を位置決めすることを分析するためのサブ容器（ｄｉｎｆ ｂｏｘと記す）と、トラックにおけるサンプリングの全ての時間情報（復号時間・表示時間）、位置情報やコーデック復号などの情報を記録するサブ容器（ｓｔｂｌ ｂｏｘと記す）とがさらにパッケージされている。

【0029】

図３を参照すると、本開示の実施例によるメディアファイルにおけるメディアデータ容器にメディアデータを記憶する構成模式図であり、ｓｔｂｌ ｂｏｘ容器からバイナリデータによって識別されたメディア情報で、サンプリングの時間、タイプ、サイズ、及びメディアデータ容器における位置を分析することができ、以下、ｓｔｂｌ ｂｏｘにおける各サブ容器を説明する。

【0030】

ｓｔｓｄ ｂｏｘは１つのサンプリング説明（ｓａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ）表を含み、異なるコーディング態様と記憶データのファイル数に基づいて、メディアファイルごとに、１つ又は複数の説明表を有することができ、説明表によって各サンプリングの説明情報を探し出し、説明情報はサンプリングの正確な復号を確保することができ、異なるメディアタイプは異なる説明情報を記憶し、例えば、ビデオメディアの場合、説明情報は図像の構造となる。

【0031】

ｓｔｔｓ ｂｏｘは、サンプリングの時間長情報を記憶し、表を提供することで時間（復号時間）とサンプリングのシーケンス番号とをマッピングし、ｓｔｔｘ ｂｏｘによって、メディアファイルにおけるどの時間のサンプリングも位置決めすることができ、ｓｔｔｓ ｂｏｘでは、さらに他の表を使ってサンプリングのサイズとポインターとをマッピングし、表における各項目は、同一時間のオフセット量で連続するサンプリングのシーケンス番号と、サンプリングのオフセット量とを提供し、これらのオフセット量をインクリメントさせることで、完全な１つの時間-サンプリングのマッピング表を構築することができ、算出式は、以下になる。

【0032】

ＤＴ(ｎ+１)=ＤＴ(ｎ)+ＳＴＴＳ(ｎ) （１）

【0033】

ここで、ＳＴＴＳ(ｎ)は、ｎ個目のサンプリングの時間長であり、ＤＴ(ｎ)はｎ個目のサンプリングの表示時間であり、サンプリングの配列は時間順で並べられており、このようにすれば、オフセット量は常に負数ではなく、ＤＴは一般的に０から始まり、ｉ個目のサンプリングの表示時間ＤＴ(ｉ)を一例とすると、算出式は、以下になる。

【0034】

ＤＴ(ｉ)=ＳＵＭ(ｆｏｒｊ=０ｔｏｉ-１ｏｆｄｅｌｔａ(ｊ)) （２）

【0035】

全てのオフセット量の総計は、トラックにけるメディアデータの時間長である。

【0036】

ｓｔｓｓ ｂｏｘは、メディアファイルにおけるキーフレームのシーケンス番号を記録した。

【0037】

ｓｔｓｃ ｂｏｘは、サンプリングとサンプリングを記憶するチャンクとのマッピング関係を記録し、表でサンプリングのシーケンス番号とチャンクのシーケンス番号との間の関係をマッピングし、表を調べることで、指定されたサンプリングを含むチャンクを探し出すことができる。

【0038】

ｓｔｃｏ ｂｏｘは、各チャンクのトラックにおける位置を定義し、位置は、メディアデータ容器における頭バイトからのオフセット量と前記頭バイトに対する長さ（即ち、サイズ）によって示す。

【0039】

ｓｔｓｚ ｂｏｘは、メディアファイルにおける各サンプリングのサイズ（即ち、大きさ）を記録した。

【0040】

６）メディアデータ容器は、メディアファイルにおいてマルチメディアデータを記憶するための容器であり、例えば、ＭＰ４ファイルにおけるメディアデータ容器の場合、図３に示すように、サンプリングはメディアデータ容器に記憶された単位であり、メディアファイルのチャンクに記憶されており、チャンクとサンプルとの長さはお互いに異なってもよい。

【0041】

７）セグメントメディアファイルは、メディアファイルの分割によって形成されたサブファイルであり、各セグメントメディアファイルは、単独で復号されることができる。

【0042】

ＭＰ４ファイルを例示とすると、ＭＰ４ファイルにおけるメディアデータは、キーフレームに基づいて分割され、分割されたメディアデータは対応するメタデータとによりセグメント化されたＭＰ４（Ｆｒａｇｍｅｎｔｅｄ ＭＰ４）ファイルをパッケージ形成し、各ＦＭＰ４ファイルにけるメタデータは、メディアデータが正確に復号されることを確保することができる。

【0043】

例えば、図２に示すようなＭＰ４ファイルを複数のＦＭＰ４ファイルに変換する際、本開示の実施例によるＦＭＰ４ファイルの一選択可能なパッケージ構成模式図である図４を参照すると、一つのＭＰ４ファイルは、複数のＦＭＰ４ファイルに変換されることができ、各ＦＭＰ４ファイルは、ｍｏｏｖ容器、ｍｏｏｆ容器、及びｍｄａｔ容器の基本的な３つの容器を含む。

【0044】

ｍｏｏｖ容器は、ＦＭＰ４ファイルの元となったＭＰ４ファイルにおける全部のメディアデータ、例えばＭＰ４ファイルの時間長、作成時間や変更時間などを説明するためのＭＰ４ファイルレベルのメタデータを含む。

【0045】

ｍｏｏｆ容器は、その存在するＦＭＰ４ファイルにパッケージされたメディアデータを説明するためのセグメント化されたレベルのメタデータを記憶し、ＦＭＰ４におけるメディアデータが復号されることを確保することができる。

【0046】

１つのｍｏｏｆ 容器と１つのｍｄａｔ容器はセグメント化されたＭＰ４ファイルの１つのセグメントを構成し、１つのセグメント化されたＭＰ４ファイルには、このような１つ又は複数のセグメントが含まれており、各セグメントにパッケージされたメタデータは、セグメントにパッケージされたメディアデータが単独で復号されることを確保することができる。

【0047】

８）メディアソース拡張（ＭＳＥ、ＭｅｄｉａＳｏｕｒｃｅＥｘｔｅｎｓｉｏｎｓ）インターフェースは、ウェブページで実現されるプレイヤー向けのインターフェースであり、ウェブページのローディングの間にブラウザのインタープリターによって分析され、フロントエンドプログラミング言語（例えばＪａｖａＳｃｒｉｐｔ）を実行することで実現され、プレイヤーにハイパーテキスト・マークアップ・ランゲージ（ＨＴＭＬ）のメディア要素（ＭｅｄｉａＥｌｅｍｅｎｔ）を呼び出す再生メディアストリーミングの機能を提供し、例えば、ビデオ要素<ｖｉｄｅｏ>とオーディオ要素<ａｕｄｉｏ>を使ってビデオ・オーディオの再生機能を実現する。

【0048】

９）ストリーミングメディアパッケージフォーマットは、メディアデータをストリーミングメディアのファイルにパッケージし、メディアファイルは完全にダウンロードされることを必要とせず、トランスコーディングを付加的に行う必要がなく、復号されて再生されることができ、即ち、ダウンロードしながら再生することを元々サポートするパッケージ技術である。典型的なストリーミングメディアパッケージフォーマットのファイルは、例えば、 ＨＴＴＰライブストリーミング（ＨＬＳ、ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ）技術に基づくＴＳメディアファイルの断片、ＦＬＶ（Ｆｌａｓｈ Ｖｉｄｅｏ）ファイルなどである。

【0049】

１０）非ストリーミングメディアパッケージフォーマットは、メディアデータをメディアファイルにパッケージし、且つ、メディアファイルを完全にダウンロードしてからこそ復号及び再生が可能になるパッケージ技術であり、典型的な非ストリーミングメディアパッケージフォーマットのファイルは、ＭＰ４ファイル、ウィンドウズ（登録商標）・メディア・ビデオ（ＷＭＶ、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ Ｖｉｄｅｏ）ファイル、アドバンストストリーミングフォーマット（ＡＳＦ、Ａｄｖａｎｃｅｄ Ｓｔｒｅａｍｉｎｇ Ｆｏｒｍａｔ）ファイルなどを含む。

【0050】

なお、ＭＰ４ファイルは、ストリーミングメディアファイルのネットワーク再生を元々サポートしないが、オンライン上でトランスコーディングされてプレイヤーへトランスコーディングされるメディアストリーミングを利用するか、又は、一部ダウンロードされたＭＰ４ファイルの不足部分に無効なバイナリデータ（例えば、ｆｔｙｐ容器とｍｏｏｖ容器とが完全にダウンロードされた場合、ｍｄａｔ容器の不足部分を無効なバイナリデーで代える）を充填することでも、ダウンロードしながら再生する技術效果を実現することができ、本明細書におけるこのような、ストリーミングメディアファイルのネットワーク再生を元々サポートしないファイルのパッケージフォーマットを、いずれも非ストリーミングメディアパッケージフォーマットと呼ぶ。

【0051】

以下、本開示の実施例を実現するプレイヤーが規定時間帯内のメディアデータを取得する手順を説明する。

【0052】

１本の映画又は１つのトラックを再生する際、プレイヤーは、データストリーミングを正確に分析することができ、一定の時間に対して対応するメディアデータを取得し、この部分のメディアデータが単独で復号されることを確保しなければならない。

【0053】

１．取得対象のメディアデータが対応する時間帯を特定し、時間帯は現在の再生ポイントに続くしばらくの時間であり、再生ポイントが対応する時間は、メディア時間座標システム（メディアファイルの再生開始時間を、時間原点とする）に対する時間の度合いである。

【0054】

２．ｓｔｔｓ ｂｏｘを検査することで、復号時間が規定時間帯に対応するサンプリングのシーケンス番号を特定する。

【0055】

オーディオフレームに対しては、ｓｔｔｓｂｏｘを検査することで、復号時間が規定時間帯に対応するオーディオフレームのシーケンス番号を特定する。

【0056】

ビデオフレームに対しては、圧縮アルゴリズムを使うため、規定時間帯内の初めてのフレームがキーフレームでなければ、時間順に従って規定時間帯の開始時間より前にキーフレームに遡る必要があり、規定時間帯内のフレームが復号されることを確保する。

【0057】

３．採用するシーケンス番号に基づいてｓｔｓｃ ｂｏｘを検索して、サンプリングを含むチャンクのシーケンス番号を特定する。

【0058】

４．ｓｔｃｏ ｂｏｘからチャンクのオフセット量を検索する。

【0059】

５．サンプリングのシーケンス番号に基づいてｓｔｓｚ ｂｏｘを検索して、サンプリングがチャンク内でのオフセット量とサンプリングのサイズを探し出す。

【0060】

次に、本開示の実施例を実現するキーフレームを検索する手順を説明する。

【0061】

１.規定時間内のサンプリングのシーケンス番号を特定する。

【0062】

２．ｓｔｓｓ ｂｏｘを検査してこのサンプリングの後のキーフレームを見つけ出す。

【0063】

３．ｓｔｓｃ ｂｏｘを検査してこのキーフレームに対応するチャンクを見つけ出す。

【0064】

４．ｓｔｃｏ ｂｏｘからチャンクのオフセット量を抽出する。

【0065】

５．ｓｔｓｚ ｂｏｘによって、キーフレームｓａｍｐｌｅがチャンク内でのオフセット量とキーフレームのサイズを探し出す。

【0066】

以下、まず本開示の実施例を実現するメディアファイルのネットワーク再生制御装置を説明する。メディアファイルのネットワーク再生制御装置は、プレイヤーのメディアファイルの再生用の再生ウィンドウを検出し、前記メディアファイルの再生進捗のリアルタイムで到達した再生ポイントに応答して、前記再生ウィンドウで再生されていないセグメントメディアファイルの識別子を表示し、ここで、前記メディアファイルには、複数のセグメントメディアファイルが対応されており、セグメントメディアファイルの識別子が選択されている状態にあることに応答して、前記プレイヤーによって、対応するセグメントメディアファイルをプリロードする。

【0067】

まず、本開示の実施例のメディア再生のローディング制御装置を説明する。本開示の実施例によるメディア再生のローディング制御装置は、スマートフォン、タブレット、ノートパソコンなどの様々な種類のユーザ端末として実施されることができる。以下、装置をユーザ端末として実施される際、ユーザ端末をカバーする例示的な応用例を説明する。

【0068】

本開示の実施例によるメディア再生のローディング制御システム１００の一選択可能なアーキテクチャ模式図である図５を参照すると、１つの例示的応用例を可能にするために、ユーザ端末１０（ユーザ端末１０-１とユーザ端末１０-２を例示的に示す）は、ネットワーク２０を介してサーバ３０に接続され、ネットワーク２０は、ＷＡＮやＬＡＮでもよいし、または両者の組み合わせでもよく、無線リンクでデータ転送を実現する。

【0069】

ユーザ端末１０は、プレイヤーが埋め込まれたウェブページによってメディアファイル再生を行い、グラフィカルインターフェース１１０（例示的に、グラフィカルインターフェース１１０-１とグラフィカルインターフェース１１０-２を示している）によって再生された内容を表示し、再生する過程において、ユーザ端末１０は、ウェブページに埋め込まれたプレイヤーによって、メディアファイルのメタデータ容器にパッケージされたメタデータを分析して、前記メディアファイルのメディアデータ容器にパッケージされたメディアデータを説明するためのメディア情報を得て、前記メディアファイルは、非ストリーミングメディアフォーマットを採用し、前記メディア情報表示の前記メディアデータの時間及び位置に基づいて、サーバ３０から前記メディアファイルのメディアデータ容器における一部のメディアデータを取得し、取得された一部のメディアデータと前記一部のメディアデータを説明するメタデータを、セグメントメディアファイルの容器構造に基づいてパッケージを行って、対応するセグメントメディアファイルを得て、前記ウェブページのメディアソース拡張インターフェースを介して、前記セグメントメディアファイルを前記ウェブページのメディア要素に送信して復号及び再生を行う。

【0070】

次に、本開示の実施例を実現するメディアファイルのネットワーク再生制御装置の構造を説明する。

【0071】

本開示の実施例によるメディアファイルのネットワーク再生装置６００の一選択可能な構成模式図である、図６を参照すると、図６に示すメディアファイルのネットワーク再生制御装置は、少なくとも１つのプロセッサ１５０、少なくとも１つの通信バス１６０、ユーザインターフェース１８０、少なくとも１つのネットワークインターフェース１７０、及びメモリ１９０を含む。メディアファイルのネットワーク再生制御装置６００における各部材は通信バス１６０を介して一緒にカップリングされている。なお、通信バス１６０は、これらの部材同士の接続通信を実現するためのものである。通信バス１６０は、データバス以外にも、電源バス、制御バス、及び状態信号バスをさらに含む。ただし、明確に説明するために、図６では各種のバスを、全部通信バス１６０として表記している。

【0072】

ここで、ユーザインターフェース１８０は、表示器、キーボード、マウス、トラックボール、クリックホイール、キー、ボタン、タッチパネル、またはタッチスクリーンなどを含むことができる。ネットワークインターフェース１７０は、標準の有線インターフェースを含むことができ、無線インターフェースは、ＷｉＦｉインターフェースであることができる。

【0073】

なお、メモリ１９０は、高速ＲＡＭメモリでも、不揮発性メモリ（Ｎｏｎ-Ｖｏｌａｔｉｌｅ Ｍｅｍｏｒｙ）でもよく、例えば、少なくとも一つの磁気ディスクメモリーであることができる。メモリ１９０は、物理的位置でプロセッサ１５０から遠隔された少なくとも１つの記憶システムであることもできる。

【0074】

本開示の実施例によるメディアファイルのネットワーク再生制御装置に適用される、メディアファイルのネットワーク再生制御方法は、プロセッサ１５０に適用するか、又はプロセッサ１５０によって実現されることができる。プロセッサ１５０は、信号処理機能を有する集積回路チップであることができる。実現する過程において、メディアファイルのネットワーク再生制御装置に適用されるメディアファイルのネットワーク再生制御方法における異なる操作は、プロセッサ１５０におけるハードウェア形式の集積論理回路またはソフトウェア形式の指令によって完成されることができる。上述のプロセッサ１５０は、汎用プロセッサ、ＤＳＰまたは他のプログラマブルロジックデバイス、個別ゲートまたはトランジスタロジック、個別ハードウェア部材などであることができる。ここで、プロセッサ１５０は、本開示の実施例がメディアファイルのネットワーク再生制御装置に適用されるメディアファイルのネットワーク再生制御方法、ステップやロジックブロック図を実現又は実行することができる。汎用プロセッサは、マイクロプロセッサ、又は、任意の通常のプロセッサなどであることができる。本開示の実施例によるメディアファイルのネットワーク再生制御装置に適用されるメディアファイルのネットワーク再生制御方法を結合すると、ハードウェア復号プロセッサにより実行して完成し、或いは復号プロセッサにおけるハードウェアとソフトウェアモジュールとの組み合わせにより実行して完成するように直接に体現することができる。

【0075】

例示として、ソフトウェアモジュールは、記憶媒体に位置することができ、記憶媒体は図６に示すメモリ１９０であることができ、プロセッサ１５０はメモリ１９０における実行可能な指令を読み取り、そのハードウェアと組み合わせて、本開示の実施例によるメディアファイルのネットワーク再生制御装置に適用されるメディアファイルのネットワーク再生制御方法の一選択可能なプロセスフローを完成し、図７に示すように、ステップＳ１０１を含む。

【0076】

ステップＳ１０１において、ウェブページに埋め込まれたプレイヤーによって、サーバからメディアファイルにおけるメディアデータを取得する。

【0077】

本開示の実施例において、ウェブページは、ブラウザのウェブページ、又は、ブラウザカーネルのＡＰＰが埋め込まれたウェブページであることができる。プレイヤーの態様は、ウェブページに埋め込まれたＨ５プレイヤーでも、専用のビデオ再生アプリケーション（ＡＰＰ、Ａｐｐｌｉｃａｔｉｏｎ）でもよい。

【0078】

いくつかの実施例において、メディアファイルにおけるメディアデータを取得する一選択可能なプロセスフローは、図８に示すように、ステップＳ１０１１、ステップＳ１０１２、及び、ステップＳ１０１３を含む。

【0079】

ステップＳ１０１１において、プレイヤーは、メディアファイルから識別されたメディア情報に基づいて、メディアファイルにおいてリアルタイム再生ポイントに続く２つのキーフレームを特定する。

【0080】

いくつかの実施例において、２つのキーフレームは、第１のキーフレームと第２のキーフレームを含み、第１のキーフレームと第２のキーフレームは、特定の時間粒度に基づいて特定されることができ、例えば、第１のキーフレームの復号時間と第２のキーフレームの復号時間の差分が時間粒度に該当する。第１のキーフレームと第２のキーフレームは、内容単位に基づいて特定されてもよく、例えば、第１のキーフレームと第２のキーフレームによって表れる内容は同じ主体、例えば、同じ人物、場面、場所、ストーリーの単位などに該当する。そして、第１のキーフレームと第２のキーフレームは、隣接する２つのキーフレームであってもよく、第１のキーフレームと第２のキーフレームとの間には他のキーフレームが存在する場合、即ち、第２のキーフレームは、第１のキーフレームの後ろで初めて現れるキーフレームでない場合、第１のキーフレームと第２のキーフレームとの間に他のキーフレームが存在する場合、第１のキーフレームと第２のキーフレームとの間のキーフレームの数は、ウェブページのキャッシュ性能とネットワーク性能などによって特定される。ここで、ウェブページのキャッシュ性能は、例えば、可用キャッシュのサイズであり、ウェブページの可用キャッシュのサイズと、第１のキーフレームと第２のキーフレームとの間のキーフレームとの数は正の相関にある。ネットワーク性能は、例えば、ネットワーク帯域幅であり、ネットワーク帯域幅と、第１のキーフレームと第２のキーフレームとの間のキーフレームの数は、正の相関にある。

【0081】

ステップＳ１０１２において、プレイヤーはネットワーク要求をサーバに送信する。

【0082】

ここで、ネットワーク要求は、メディアファイルにおける２つのキーフレーム同士のメディアデータの取得を要求するためのものである。

【0083】

２つのキーフレームが繋がれた再生ポイントは、連続してメディアファイルを再生する（即ち、ユーザの干渉なしに、自然的に再生する）手段で到達する再生時刻であることができ、例えば、３０分から始めて４０分まで再生する再生ポイントである。あるいは、ジャンプの手段（即ち、ユーザがカーソルで進捗バーをクリックしてページをジャンプさせること）でメディアファイルが到達した再生時刻に到達することもでき、例えば、元の再生ポイントは、再生進捗の２０%であり、ジャンプされた後の再生ポイントは再生進捗の３０%である。

【0084】

いくつかの実施例において、再生ポイントが連続してメディアファイルを再生する手段で到達した再生時刻である場合について、再生ポイントに対応するビデオフレームと規定時間帯の終了時間に対応するビデオフレームが通常フレーム、又は、キーフレームである状況に基づいて、２つのキーフレーム（第１のキーフレーム、及び、復号時間が第１のキーフレームより後の第２のキーフレームとする）を特定する手段を説明する。

【0085】

状況１）再生ポイントに対応するビデオフレームが通常フレームであり、プレイヤーが２つのキーフレームの間のメディアデータを基本的な再生ロード単位とするため、再生ポイントの後は、再生ポイントの後の一番目のキーフレーム（復号時間が再生ポイントのキーフレームのうち、再生ポイントから最も近いキーフレームより遅い）の前にあるメディアデータは、ロード済みのメディアデータであり、この部分のロード済みのメディアデータの重複取得を回避するために、規定時間帯の２つのキーフレームのおける第１のキーフレームを、メディアファイルにおける、復号時間が再生ポイントより後の一番目のキーフレームにする。

【0086】

状況２）再生ポイントに対応するビデオフレームがキーフレームであり、規定時間帯の２つのキーフレームにおける第１のキーフレームは、再生ポイントに対応するキーフレーム、即ち、規定時間帯の開始時間に合わせたキーフレームである。

【0087】

状況３）規定時間帯の終了時間に対応するビデオフレームが通常フレームである場合、プレイヤーが２つのキーフレームの間のメディアデータを基本的な再生ロード単位とするため、終了時間より前のキーフレームを規定時間帯の第２のキーフレームにすれば、このキーフレームと終了時間に対応するビデオフレームとの間のメディアデータの取得を漏れることになるため、行メディアファイルの再生の際、終了時間より前のキーフレームから終了時間に対応するビデオフレームまでの間のメディアデータは、再生することができず、フレームジャンプとなる。従って、規定時間帯の終了時間に対応するビデオフレームがフレームジャンプすることなく、正常に再生可能であることを確保するために、規定時間帯の２つのキーフレームにおける第２のキーフレームを、復号時間が規定時間帯の終了時間のキーフレームのうち、終了時間に最も近いキーフレームより遅くする。

【0088】

状況４）規定時間帯の終了時間に対応するビデオフレームがキーフレームであり、規定時間帯の２つのキーフレームにおける第２のキーフレームは、復号時間が規定時間帯の終了時間に合わせた第２のキーフレーム、即ち、規定時間帯の終了時間に合わせてキーフレームである。

【0089】

上記の状況１）、３）において、再生ポイントを跨ぐキーフレームを、規定時間帯のメディアデータの境界点とすることで、再生ポイントに対応するビデオフレームには、正確に復号するのに十分な情報が存在することを確保でき、復号データ（即ち、キーフレーム）の欠如によるフレームジャンプが現れることはない。

【0090】

上記の状況２）、４）において、再生ポイントがキーフレームで合わせられた状況について、合わせられたキーフレームを規定時間段のメディアデータの境界点とすることで、余分のデータを請求することを最大限に減少させて、接続及びトラフィックの占有によるウェブページでの非メディアファイルのネットワーク再生作業が遅延することを回避する。

【0091】

別の実施例において、再生ポイントがジャンプの手段で到達した再生時刻の場合について、再生ポイントに対応するビデオフレームと規定時間帯の終了時間に対応するビデオフレームが通常フレーム、又はキーフレームである状況に基づいて、２つのキーフレーム（第１のキーフレーム、及び、復号時間が第１のキーフレームより後の第２のキーフレームとする）を特定する手段を説明する。

【0092】

状況１）再生ポイントに対応するビデオフレームが通常フレームであり、再生ポイントはジャンプで到達されたものであるため、再生ポイントの前の一番目のキーフレームと、再生ポイントとの間のメディアデータはロードされておらず、第１のキーフレームは、メディアファイルにおける、復号時間が再生ポイントより前の一番目のキーフレーム、即ち、メディアデータの時間（即ち、メディア情報によって示されるシーケンス番号とフレームの復号時間との対応関係）から検索された復号時間が規定時間帯の開始時間より早く、且つ、開始時間に最も近いキーフレームである。

【0093】

再生ポイントから再生ポイントの前のキーフレームまでの間のメディアデータを、付加的に請求することで、いずれの再生ポイントにジャンプしても正常に復号することを確保でき、再生ポイントが通常フレームに対応する場合の、復号不可能によるフレームジャンプが現れることを回避する。

【0094】

状況２）再生ポイントに対応するビデオフレームがキーフレームであり、第１のキーフレームは、再生ポイントに対応するキーフレーム、即ち、メディアデータの時間（即ち、メディア情報によって示されるシーケンス番号とフレームの復号時間との対応関係）から検索された復号時間が規定時間帯の開始時間に合わせたキーフレームである。

【0095】

状況３）規定時間帯の終了時間に対応するビデオフレームが通常フレームであり、第２のキーフレームは、復号時間が規定時間帯の終了時間より遅く、且つ、終了時間に最も近いキーフレームである。

【0096】

上記の状況１）、３）において、再生ポイントを跨ぐキーフレームを規定時間帯のメディアデータの境界点とすることで、再生ポイントに対応するビデオフレームには、正確に復号するのに十分な情報が存在することを確保でき、復号データ（即ち、キーフレーム）の欠如によるフレームジャンプが現れることはない。

【0097】

状況４）規定時間帯の終了時間に対応するビデオフレームがキーフレームであり、第２のキーフレームは、復号時間が規定時間帯の終了時間に合わせたキーフレームである。

【0098】

状況２）、４）において、再生ポイントを合わせたキーフレームで、取得対象のメディアデータを区画し、再生ポイントが正確に復号されることを前提にする場合、必要以上のメディアデータを取得することを最大限に減少させ、接続及びトラフィックの占有を低減し、ウェブページでの非メディアファイルのネットワーク再生作業のリアルタイム性を確保する。

【0099】

いくつかの実施例において、プレイヤーは以下のようにメディアデータの時間から規定時間帯に合わせたオーディオフレームを検索する。即ち、メディアデータの時間から復号時間が規定時間帯に従って分布されたオーディオフレームを検索、ビデオフレームを基準にすると、ビデオフレームで時間が同期するオーディオフレームを位置決めする。ここで、再生ポイントの時間に対応するオーディオフレームが存在する場合、最初のオーディオフレームの復号時間は規定時間帯の開始時間に合わせられ、再生ポイントの時間に対応するオーディオフレームが存在しない場合、最初のオーディオフレームの復号時間は規定時間帯の開始時間より早く、且つ開始時間に最も近く、最初のオーディオフレームの復号時間が最初のビデオフレーム（上記の第１のキーフレーム）の復号開始時間より遅くないことを確保する。規定時間帯の終了時間に対応するオーディオフレームが存在する場合、最後のオーディオフレームの復号時間が規定時間帯の終了時間に合わせられ、規定時間帯の終了時間に対応するオーディオフレームが存在しない場合、最後のオーディオフレームの復号時間が規定時間帯の終了時間より遅く、且つ終了時間に最も近く、最後のオーディオフレームの復号時間が最後のビデオフレーム（上記の第２のキーフレーム）の復号時間より早くないことを確保する。このように、メディアファイルにおけるビデオ、オーディオの時間長が一致しない問題を克服することができ、各フレームビデオが再生するたびに、同期のオーディオが再生することを確保し、画面はあるが音声がない現象が現れることはない。

【0100】

いくつかの実施例において、プレイヤーは、以下のようにメディアファイルのメディアデータ容器における対応する位置のメディアデータを取得する。即ち、プレイヤーは、規定時間帯の２つのキーフレームの間のビデオフレームの位置が対応するオフセット量及びサイズ、並びに、２つのキーフレームの間のビデオフレームに合わせたオーディオフレームの位置が対応するオフセット量及びサイズに基づいて、最小のオフセット量と最大のサイズからなる区間を特定し、メディアファイルのメディアデータ容器の対応する区間内のメディアデータを取得する。

【0101】

ここで、最小のオフセット量と最大のサイズからなる区間を説明する。２つのキーフレームにおける第１のキーフレームと第２のキーフレームとの間のビデオフレームがメディアファイルでのオフセット量及びサイズに基づいて、ビデオフレームがメタデータ容器での位置を位置決めし、ビデオフレームに合わせたオーディオフレームがメディアファイルでのオフセット量及びサイズに基づいて、オーディオフレームがメタデータ容器での位置を位置決めし、位置の上限と下限からなる区間を目標区間として取り、即ち、最小のオフセット量と最大のサイズからなる区間を目標区間として取る。ここで、位置の上限に対応するオフセット量及びサイズは、目標区間の上限に対応するオフセット量及びサイズであり、位置の下限に対応するオフセット量及びサイズは、目標区間の下限に対応するオフセット量及びサイズである。

【0102】

実際の応用において、目標区間は、目標解像度のメディアファイルのメディアデータ容器に記憶されたビデオフレームとオーディオフレームとの最小区間であり、例えば、第１のキーフレームと第２のキーフレームとの間のビデオフレームが目標解像度のメディアファイルでの位置のオフセット量は、対応区間が[ａ、ｂ]（アドレスは昇順）であり、且つ、オーディオフレームが目標解像度のメディアファイルでの位置のオフセット量は、対応区間が[ｃ、ｄ]（アドレスは昇順）であると、位置の上限と下限からなる区間は、[ｍｉｎ（ａ、ｃ）、ｍａｘ（ｂ、ｄ）]となる。

【0103】

なお、ウェブページに２つのキーフレームの間のメディアデータがキャッシュされている場合、メディアファイルから抽出された２つのキーフレーム時間のメディアデータを無視する。

【0104】

このように、プレイヤーは、目標区間のメディアデータを請求するように、目標区間のオフセット量及びサイズを持つネットワーク要求をサーバに送信し、サーバは、目標区間のオフセット量及びサイズに基づいてメディアファイルにおけるメディアデータを抽出してから目標区間のメディアデータを１回で返し、２回目の取得を行う必要はなく、プレイヤーの要求回数を低減し、処理効率を向上させる。

【0105】

ステップＳ１０１３は、プレイヤーでサーバから返された前記２つのキーフレームの間のメディアデータを受信する。

【0106】

いくつかの実施例において、プレイヤーは、サーバからメディアファイルにおけるメディアデータを取得する前に、メディアファイルからメディア情報を識別することを、さらに含む。図９に示すように、ステップＳ２０１とステップＳ２０１とを含む。

【0107】

ステップＳ２０１は、ウェブページに埋め込まれたプレイヤーによって、サーバからメディアファイルのメタデータ容器にパッケージされたメタデータを取得する。

【0108】

ここで、ウェブページに埋め込まれたプレイヤーは、ウェブページでメディアファイルを再生し、メディアファイルは非ストリーミングメディアフォーマット、例えば、ＭＰ４/ＭＫＶ/ＷＭＶ/ＡＳＦなどのパッケージフォーマットを利用する。

【0109】

いくつかの実施例において、プレイヤーは、以下のように、メディアファイルのメタデータ容器にパッケージされたメタデータを取得することができる。即ち、プレイヤーは、設定されたオフセット量及びサイズのネットワークを持つ要求をサーバに送信することによって、サーバから返されたメディアファイルにおける、ゼロバイトから始まり、且つ設定されたサイズに該当するバイナリデータを取得し、サーバから返されたバイナリデータからメタデータ容器におけるメタデータを識別する。

【0110】

ここで、設定されたサイズは、既に存在するメディアファイルのファイルタイプ容器とメタデータ容器のサイズを統計することによって得られてもよく、設定されたサイズが、設定比例（例えば、全部）のメディアファイルのファイルタイプ容器及びメタデータ容器のサイズの加算値をカバーできるようにし、メディアファイルのパッケージ構造が順にパッケージされたファイルタイプ容器、メタデータ容器、及びメディアデータ容器である場合、一回の要求で完全なメタデータ容器にパッケージされたメタデータを得ることをでき、ネットワークの転送中の接続の占有を節約し、接続の占有によってウェブページでの非メディアファイルのネットワーク再生業務が接続を利用できず応答遅延が発生することを回避する。

【0111】

メディアファイルがＭＰ４ファイルであることを例にすると、プレイヤーが取得したメタデータ容器にパッケージされたメタデータは、ＭＰ４ファイル中のｍｏｏｖ ｂｏｘにパッケージされたバイナリデータとなり、ＭＰ４ファイルのパッケージ構造が順にパッケージされたｆｙｔｐ ｂｏｘ、ｍｏｏｖ ｂｏｘ、及びｍｄａｔ ｂｏｘである場合、設定されたサイズは、既に存在するＭＰ４ファイルのｆｔｙｐ ｂｏｘ、及びｍｏｏｖ ｂｏｘのサイズを統計することによって得られてもよく、設定されたサイズが、設定比例（例えば、全部）のＭＰ４ファイルのｆｔｙｐ ｂｏｘ、及びｍｏｏｖ ｂｏｘのバイナリデータの加算値をカバーできるように、多数の場合では、一回をすれば、サーバにｍｏｏｖ ｂｏｘに含まれる完全なバイナリデータを要求できる。

【0112】

いくつかの実施例において、プレイヤーが設定されたオフセット量及びサイズによって、サーバに要求して得られたバイナリデータのうち、ゼロバイトから始まる一部のバイナリデータはファイルタイプ容器に対応するものであり、プレイヤーは、容器ヘッド部を読み取ることでファイルタイプ容器のサイズを取得し、第２の容器のヘッド部を読み取ることで次の容器のタイプ及びサイズを取得する。第２の容器のタイプがメタデータ容器であり、且つ返されたバイナリデータのサイズがファイルタイプ容器のサイズとメタデータ容器のサイズとの加算値より小さくない場合は、設定されたオフセット量及びサイズによってサーバに要求して得られたバイナリデータには、メタデータ容器にパッケージされたメタデータが含まれていることを示す。第２の容器のタイプがメタデータ容器であり、且つ返されたバイナリデータのサイズがファイルタイプ容器のサイズとメタデータ容器のサイズの加算値より小さい場合は、設定されたオフセット量及びサイズによってサーバに要求して得られたバイナリデータには、メタデータ容器にパッケージされたメタデータが含まれていないことを示す。プレイヤーは、設定されたオフセット量及びサイズによってサーバに要求して得られたバイナリデータには、完全なメタデータ容器におけるメタデータが含まれていない場合、プレイヤーは、サーバから返されたバイナリデータから容器のサイズを読み取り、メタデータ容器のヘッド部からメタデータ容器のオフセット量及びサイズを算出し、算出されたオフセット量及びサイズをネットワーク要求に持たせることで、サーバにメタデータを要求し、サーバが要求に従って、メディアファイルで算出されたオフセット量からのバイナリデータの読み取りを開始し、且つ、読み取られたバイナリデータは算出されたサイズに該当し、プレイヤーにデータが返るようにしなければならない。

【0113】

例を挙げると、プレイヤーはサーバから返されたバイナリデータから容器のサイズを読み取り、メタデータ容器のヘッド部からメタデータ容器のオフセット量及びサイズを算出し、以下の状況１）と状況２）の２つの状況に係わる。

【0114】

状況１）残されたバイナリデータ（即ち、返されたバイナリデータのうち、ファイルタイプ容器のバイナリデータ以外のデータ）から読み取られた容器のタイプがメタデータ容器であり、且つ残されたバイナリデータのサイズがメタデータ容器のサイズより小さい場合、メタデータ容器のサイズと残されたバイナリデータのサイズとの差分を、２回目要求する新たなサイズとして算出し、最初に要求したオフセット量及びサイズの加算値を新たなオフセット量として、サーバにバイナリデータを２回目要求する。

【0115】

状況２）残されたバイナリデータから読み取られた容器のタイプがメディアデータ容器である場合、メディアデータ容器のサイズとファイルタイプ容器のサイズとの加算値を、２回目要求する新オフセット量として算出し、設定されたサイズ（メタデータ容器のサイズの経験値をカバーできるものであってもよい）でサーバにバイナリデータを２回目要求する。

【0116】

メディアファイルがＭＰ４ファイルであることを例にすると、プレイヤーが設定されたオフセット量及びサイズによよってサーバに要求して得られたバイナリデータには、完全なｍｏｏｖ ｂｏｘのバイナリデータが含まれておらず、この際、プレイヤーは、サーバから返されたバイナリデータから容器のタイプ及びサイズを読み取って、ｍｏｏｖ ｂｏｘがＭＰ４ファイルでのオフセット量及びサイズを特定する必要がある。

【0117】

ＭＰ４ファイルのバイナリデータは、始まりのバイトは常にｆｔｙｐ ｂｏｘに対応し、返されたバイナリデータからｆｙｔｐ ｂｏｘのバイナリデータを識別し、ｆｔｙｐｂｏｘ のヘッド部からその長さを分かることができ、残されたバイナリデータから、ヘッド部の規格長さに従って、次のｂｏｘのバイナリデータを読み取り、ヘッド部で示される容器タイプによると、以下の複数の状況を含む。

【0118】

１）残されたバイナリデータ（即ち、返されたバイナリデータのうち、ｆｙｔｐ ｂｏｘのバイナリデータ以外のデータ）から読み取られた容器のタイプがｍｏｏｖ ｂｏｘであり、且つ残されたバイナリデータのサイズがｍｏｏｖ ｂｏｘのサイズより小さくない場合、特定されたオフセット量及びサイズに基づいて、サーバから、ＭＰ４ファイルのうちｍｏｏｖ ｂｏｘがＭＰ４ファイルでのオフセット量から始まり、且つ、ｍｏｏｖ ｂｏｘがＭＰ４ファイルでのサイズに該当するｍｏｏｖデータを取得する。

【0119】

２）残されたバイナリデータから読み取られた容器のタイプがｍｏｏｖ ｂｏｘであり、且つ、バイナリデータのサイズがｍｏｏｖ ｂｏｘのサイズより小さい場合、ｍｏｏｖ ｂｏｘのサイズと残されたバイナリデータのサイズとの差分を、２回目要求する新たなサイズとして算出し、最初に要求するオフセット量及びサイズの加算値を２回目要求する新たなオフセット量とし、サーバにバイナリデータを２回目要求する。

【0120】

３)残されたバイナリデータから読み取られた容器のタイプがｍｄａｔ ｂｏｘである場合、ｍｄａｔ ｂｏｘのサイズとｆｔｙｐ ｂｏｘサイズとの加算値を、２回目要求する新オフセット量として算出し、設定されたサイズでサーバにバイナリデータを２回目要求する。

【0121】

このように、メディアファイルがどのようなパッケージ構造であっても、即ち、メディアファイルにおけるファイルタイプ容器、メタデータ容器、メディアデータ容器のパッケージ順がどのようであっても、プレイヤーが最大で２回要求すれば、サーバからメタデータ容器におけるメタデータを得ることを確保でき、メタデータの取得効率を向上させる。

【0122】

例を挙げると、ＭＰ４ファイルの場合、サーバから返されたバイナリデータがＭＰ４ファイルのパッケージ規格によると、ゼロバイトから始まる一部分のバイナリデータはｆｔｙｐ ｂｏｘに対応するものであり、一方、ｂｏｘのヘッド部のパッケージ規格によると、ｆｔｙｐ ｂｏｘのヘッド部からｆｔｙｐ ｂｏｘのサイズ（即ち、長さ）、及び完全なＭＰ４ファイルのサイズを読み取ることができる。ｆｔｙｐ ｂｏｘのサイズをａ（単位はバイトである）に仮定すると、ａ+１から続く容器のヘッド部の情報を読み取り、続く容器のタイプ及びサイズを取得し、読み取られたｆｔｙｐ ｂｏｘに続くのはｍｏｏｖ ｂｏｘであり、且つ残されたバイナリデータのサイズ（設定されたサイズ-ｆｔｙｐ ｂｏｘのサイズ）がｍｏｏｖ ｂｏｘのサイズより多きい場合は、ｍｏｏｖ ｂｏｘ の完全なバイナリデータを取り戻したことを示し、ｍｏｏｖ ｂｏｘのオフセット量及びサイズに基づいて、残されたバイナリデータからｍｏｏｖ ｂｏｘにおけるメタデータを抽出することができる。

【0123】

ステップＳ２０２は、プレイヤーが取得されたメタデータを分析することで、メディアファイルのメディアデータ容器にパッケージされたメディアデータを説明するためのメディア情報を得る。

【0124】

ここで、前記メディア情報は要求されたメディアデータが前記メディアファイルでのオフセット量及びサイズを位置決めするためのものである。

【0125】

いくつかの実施例において、プレイヤーは、サーバからメタデータ容器にパッケージされたメタデータを取得した後、メタデータ容器におけるサブ容器のネスト構造を分析し、サブ容器のネスト構造に基づいて各サブ容器におけるバイナリデータを読み取り、読み取られたバイナリデータから各サブ容器によって表れるメディアデータのメディア情報を分析する。実際の応用において、メディア情報は、メディアファイルにおけるビデオフレーム及び/又はオーディオフレームのオフセット量、サイズ、復号時間などの情報を含むことができる。

【0126】

メディアファイルがＭＰ４ファイルであることを例にすると、メタデータ容器はｍｏｏｖ ｂｏｘとなり、図２を参照すると、ｍｏｏｖ ｂｏｘにはｍｖｈｄ ｂｏｘとｔｒａｃｋ ｂｏｘがパッケージされていることを分かり、ここで、ｍｖｈｄ ｂｏｘのバイナリデータを分析することで、ＭＰ４ファイルの作成時間、変更時間、時間度合い標尺、再生可能時間長、デフォルトボリュームなどの情報を得ることができる。ｍｏｏｖ ｂｏｘには、複数のｔｒａｃｋ ｂｏｘが含まれており、各メディアトラックに特有の説明情報を記録し、例えば、ビデオトラックのｖｉｄｅｏ ｔｒａｃｋ ｂｏｘ、ｖｉｄｅｏ ｔｒａｃｋ ｂｏｘにおいて複数層ネストされた複数のサブ容器の場合、ｖｉｄｅｏ ｔｒａｃｋ ｂｏｘのネスト構造に基づいて、対応するバイナリデータを分析することでＭＰ４ファイルのビデオフレーム情報、及び対応する画面情報を得る。

【0127】

１つの実施例において、プレイヤーは、以下のように取得されたメタデータを分析することでメディア情報を得ることができる。即ち、メタデータ容器バイナリデータのうち容器ヘッド部の規格長さに対応するバイナリデータを順に分析して、前記メタデータ容器におけるサブ容器の容器タイプ、及び、前記サブ容器の容器データの長さを取得し、前記サブ容器の容器タイプに対応するタイプである分析器を呼び出し、分析されていないデータのうち前記容器データの長さに対応するバイナリデータを順に分析し、前記容器データによって表れるメディア情報を得る。

【0128】

ここで、プレイヤーは、タデータ容器に複数のサブ容器がネストされた状況について、毎回読み取られたバイナリデータのオフセット量は、いずれも識別済みのサブ容器長さの加算値であり、読み取られたバイナリデータの長さは容器ヘッド部の規格長さに該当し、現在処理中のサブ容器のタイプと長さを分析できる。

【0129】

例えば、最初に読み取る際、メタデータ容器のバイナリデータのゼロバイトから、バイナリデータの読み取りを開始し、且つ、読み取られたバイナリデータの長さは容器ヘッド部の規格長さに該当し、１番目のサブ容器のタイプと長さを分析でき、２回目の読み取りを行う際、最初に読み取られたサブ容器の長さをオフセット量として、バイナリデータの読み取りを開始し、且つ読み取られたバイナリデータの長さは容器ヘッド部の規格長さに該当し、２番目のサブ容器のタイプと長さを分析できる。

【0130】

以上のようにバイナリデータを読み取れば、余計の読み取りによる返却も、足りない読み取りによる２回目の読み取りも、現れることはなく、分析の効率と正確率とが確保される。

【0131】

１つの実施例において、容器はバイナリデータを直接パッケージするか、それとも、容器がさらにパッケージされているかを示すために、メタデータ容器におけるネストの典型的な容器タイプを、予め標記する。例えば、図２に示されるｍｖｈｄ ｂｏｘ、ａｕｄｉｏ ｔｒａｃｋ ｂｏｘ、及びｖｉｄｅｏ ｔｒａｃｋ ｂｏｘなどに容器がさらにパッケージされていることを標記し、図２に示されるｓｔｔｓ ｂｏｘ、ｓｔｓｄ ｂｏｘなどにはバイナリデータが直接パッケージされていることを標記する。

【0132】

バイナリデータを直接パッケージすると標記された容器タイプの場合、容器タイプと一対一に対応する分析器であって、バイナリデータに基づいて示されるメディア情報を分析するための分析器を設ける。分析されたサブ容器の容器タイプを予め標記された容器タイプに比べると、以下の２つの状況に係わる。

【0133】

状況１）比べることによって前記サブ容器の容器タイプが、バイナリデータを直接パッケージすると予め標記されていると特定された場合、前記サブ容器の容器タイプに対応する分析器を呼び出し、前記分析器によって前記サブ容器における容器データを分析し、前記容器データによって表れるメディア情報を得る。

【0134】

状況２)比べることによって前記サブ容器の容器タイプが、容器を続けてパッケージすることに使われると予め標記されていると特定された場合、前記メディアファイルにおける容器ヘッド部の規格長さに基づいて、前記サブ容器にパッケージされた容器の容器タイプが、バイナリデータを直接パッケージすることに使われると予め標記されるたことが分析されるまで、前記サブ容器に対応するバイナリデータを回帰分析し、サブ容器にパッケージされた容器の容器タイプに対応する分析器を呼び出し、バイナリデータをバイトの１つずつで分析し、分析されたバイナリデータの長さと前記サブ容器にパッケージされた容器の容器データの長さが対応して、前記サブ容器にパッケージされた容器の容器データによって表れるメディア情報を得る。

【0135】

１つの実施例において、メタデータ容器の分析中でメディア情報を記録する手段を説明する。メタデータ容器のバイナリデータにおける容器ヘッド部の規格長さに対応するバイナリデータを順に分析して、前記メタデータ容器におけるサブ容器の容器タイプを得る場合、サブ容器とその属する容器との間のネスト関係、及び、サブ容器とそれがパッケージされた容器とのネスト関係に基づいて、オブジェクトを構築し、サブ容器の容器タイプがバイナリデータを直接パッケージすると予め標記された場合、対応する前記サブ容器によって構築されたオブジェクトには、メディア情報が含まれた配列が記憶され、記憶されたメディア情報は前記サブ容器の容器データによって表れる。

【0136】

例えば、図２において、分析中のサブ容器のタイプがｓｔｔｓ ｂｏｘである場合、ｓｔｔｓ ｂｏｘがバイナリデータを直接パッケージすると予め標記されているため、対応するｓｔｔｓ ｂｏｘによって構築されたオブジェクトにはメディア情報が含まれた配列が記憶され、ここでのメディア情報は、ｓｔｔｓ ｂｏｘの容器データによって表れる時間長情報である。

【0137】

１つの実施例において、メタデータ容器の分析中で、それとサブ容器との間のネスト関係を記録する手段を説明する。メタデータ容器のバイナリデータにおける容器ヘッド部の規格長さに対応するバイナリデータを順に分析して、前記メタデータ容器のおけるサブ容器の容器タイプを得る場合、容器タイプがバイナリデータを直接パッケージすると予め標記されていれば、呼び出された前記分析器に分析されたサブ容器を記録する。記録されたサブ容器の実例をサブ容器属性に設定し、前記サブ容器属性は、前記サブ容器が属する容器に含まれ、前記サブ容器とその属する容器との間のネスト関係を説明するためのものである。

【0138】

例えば、図２において、分析中のサブ容器のタイプがｓｔｓｄ ｂｏｘである場合、ｓｔｓｄ ｂｏｘがバイナリデータを直接パッケージすると予め標記されているため、対応するｓｔｓｄ ｂｏｘに対応する分析器にｓｔｓｄ ｂｏｘが記録され、ｓｔｓｄ ｂｏｘの実例をｓｔｂｌ ｂｏｘのサブ容器属性に設定し、以下同様にし、最後には、ｓｔｓｄ ｂｏｘ のサブ容器属性にｓｔｓｄ ｂｏｘ、ｓｔｔｓ ｂｏｘ、ｓｔｓｃ ｂｏｘなどの複数のｓｔｂｌ ｂｏｘにネストされたサブ容器が記録されることになる。

【0139】

１つの実施例において、比べることによって前記サブ容器の容器タイプが予め標記されているか、又は、バイナリデータを直接パッケージすると予め標記されているが対応するタイプの分析器が呼び出されていないと特定された場合、サブ容器に対応するバイナリデータを無視し、前記サブ容器の長さに基づいて、前記バイナリデータにおける次のサブ容器に対応する部分にジャンプして続けて分析する。

【0140】

実際には、メディアファイルにはカスタム容器タイプが現れ、ジャンプの手段によるとメタデータ容器の全体の分析の進捗を影響することはなく、それとともに、分析器を設ける手段によると、メタデータ容器の容器タイプが変動する際、対応するタイプの分析器の増加、削除、変更で、一番新しいメタデータ容器の適合分析を迅速に実現し、アップグレードが柔軟で迅速な特徴を有する。

【0141】

いくつかの実施例において、設定されたオフセット量及びサイズに基づいて前記サーバに要求したメタデータから、完全なメディア情報が識別されていない場合、メタデータ容器のヘッド部から前記メタデータ容器のオフセット量及びサイズを算出し、前記サーバに前記メディアファイルにおける前記メタデータを要求し、要求されたメタデータは、前記マルチメディアファイルで前記オフセット量から始まり、且つ前記サイズに該当する。

【0142】

ステップＳ１０２は、プレイヤーによってメディアデータを含むセグメントメディアファイルを構築する。

【0143】

いくつかの実施例において、プレイヤーは、取得されたメディアファイルにおけるメディアデータ、及びメディアファイルにおけるメタデータに基づいて、セグメントメディアファイルレベルのメタデータを算出する。取得されたメディアファイルにおけるメディアデータ、及びセグメントメディアファイルレベルのメタデータを、セグメントメディアファイル容器にパッケージして、セグメントメディアファイルを得る。

【0144】

いくつかの実施例において、セグメントメディアファイルのタイプと適合性を示すデータを、セグメントメディアファイルのファイルタイプ容器に充填する。例えば、図４に示すようなパッケージ構造のＦＭＰ４ファイルをパッケージ形成することを例にすると、ＦＭＰ４ファイルのファイルタイプ容器、即ちｆｔｙｐ ｂｏｘ のヘッド部に容器のタイプと長さ（ｆｔｙｐ ｂｏｘの全体の長さを示す）を充填し、ｆｔｙｐ ｂｏｘのデータ部分にファイルタイプがＦＭＰ４であること及び適合プロトコルを示すデータ（バイナリデータ）を生成させ充填する。

【0145】

セグメントメディアファイルのファイルレベルを示すメタデータを、セグメントメディアファイルのメタデータ容器に充填する。

【0146】

１つの実施例において、セグメントメディアファイルパッケージ構造への充填対象のメディアデータに基づき、且つ、セグメント化されたメディアファイルにおけるメタデータ容器のネスト構造に基づいて、ネスト構造を充填するのに必要な、メディアデータを説明するメタデータを算出する。

【0147】

また図４を例にすると、ＦＭＰ４ファイルのファイルレベルを示すメタデータを算出し、ＦＭＰ４のメタデータ容器（即ち、ｍｏｏｖ ｂｏｘ）に充填し、ｍｏｏｖ ｂｏｘにはｍｖｈｄ、ｔｒａｃｋ、及びビデオ拡張（ｍｖｅｘ、ｍｏｖｉｅ ｅｘｔｅｎｄ）の３つの容器がネストされている。

【0148】

ここで、ｍｖｈｄ容器にパッケージされたメタデータは、セグメントメディアファイルの再生に関連するメディア情報を表すためのものであり、位置、時間長、作成時間や変更時間などを含む。ｔｒａｃｋ容器にネストされているサブ容器は、メディアデータにおける対応するトラックの引用と説明を表し、例えば、ｔｒａｃｋ容器にはトラックの特性と全体情報（例えば、時間長、幅と高さ）を説明する容器（ｔｋｈｄ ｂｏｘと記す）がネストされており、トラックのメディア情報（例えばメディアタイプとサンプリングの情報）の容器（ｍｄｉａ ｂｏｘと記す）を記録する。

【0149】

１つの実施例において、セグメントメディアファイルには１つ又は複数のセグメント（ｆｒａｇｍｅｎｔ）がパッケージされることができ、充填対象のメディアデータの場合、セグメントメディアファイルの１つ又はセグメント化されたメディアデータ容器（即ち、ｍｄａｔ ｂｏｘ）に充填されることができ、各セグメントにはセグメント化されたレベルのメタデータ容器（ｍｏｏｆ ｂｏｘと記す）がパッケージされており、ここで、充填されるメタデータは、セグメントに充填されるメディアデータを説明して、セグメント化されたが単独で復号されることを可能にする。

【0150】

図４とともに、充填対象のメディアデータをＦＭＰ４ファイルのパッケージ構造の２つのセグメントに充填することを例にすると、各セグメント化されたメディアデータに充填され、対応するセグメント化されたセグメント化されたレベルのメタデータ容器（即ち、ｍｏｏｆ ｂｏｘ）に充填されるべきのメタデータを算出し、それに応じて、ｍｏｏｆ ｂｏｘにネストされたサブ容器に充填され、ここでのｍｏｏｆ ｂｏｘのヘッド部をｍｏｏｆ ｂｏｘと呼び、ここでの充填されたバイナリデータは、容器のタイプが「ｍｏｏｆ ｂｏｘ」及びｍｏｏｆ ｂｏｘの長さであることを表す。

【0151】

上記のデータを対応する容器に充填する１つの実施例において、充填操作を実行する際、呼び出しクラスの書き込み操作機能は、前記サブ容器のメモリバッファーがバイナリデータの書き込みと合併を完成させ、また、前記クラスの実例に戻って、戻された実例は前記サブ容器及びネスト関係を有するサブ容器を合併する。

【0152】

データを充填する１つの示例として、パッケージ機能を実現するためのクラスＭＰ４を構築し、セグメントメディアファイルにおける各サブ容器をクラスＳｔｒｅａｍにパッケージする静的方法を挙げる。ここで、バイナリデータ操作機能の実現するためのクラスＳｔｒｅａｍを構築し、各クラスＳｔｒｅａｍには、充填対象のバイナリデータを保存するために、１つのメモリバッファーが提供されている。Ｓｔｒｅａｍによる静的方法で、充填対象のマルチバイト１０進数データをバイナリデータに変換し、クラスＳｔｒｅａｍの実例による書き込み操作機能によって、メモリバッファーにおいてサブ容器への充填対象であるバイナリデータの合併及び充填を完成し、Ｓｔｒｅａｍによる静的方法が１つの新たなＳｔｒｅａｍ実例に戻り、現在のサブ容器と他のネスト関係を有するサブ容器の合併を実現する。

【0153】

ステップＳ１０３は、プレイヤーによってセグメントメディアファイルを前記メディアソース拡張インターフェースに送信し、メディアソース拡張インターフェースを介して前記ウェブページのメディア要素を呼び出して再生を行う。

【0154】

いくつかの実施例において、本開示の実施例によるプレイヤーがウェブページのメディアソース拡張インターフェースを介してセグメントメディアファイルをウェブページのメディア要素に送信して復号及び再生を行うフロー模式図である図１０を参照し、図１０とともにステップを説明する。

【0155】

ステップＳ４０１において、プレイヤーは、セグメントメディアファイルをメディアソース拡張インターフェースにおけるメディアソースオブジェクトに追加する。

【0156】

本開示の実施例によるプレイヤーがウェブページのメディアソース拡張インターフェースを介してセグメントメディアファイルを再生する一選択可能な模式図である図１１を参照すると、プレイヤーがウェブページでの再生ウィンドウ（プレイヤーが再生ウィンドウに対応する）からメディアファイルの再生イベントを受信する場合、プレイヤーは、ＭｅｄｉａＳｏｕｒｃｅ方法を実行することでメディアソース（Ｍｅｄｉａ Ｓｏｕｒｃｅ）オブジェクトを作成し、メディアソース拡張インターフェースにパッケージされたａｄｄＳｏｕｒｃｅＢｕｆｆｅｒ方法を実行することでＭｅｄｉａＳｏｕｒｃｅオブジェクトのキャッシュ、即ち、ソースキャッシュ（ＳｏｕｒｃｅＢｕｆｆｅｒ）オブジェクトを作成し、１つのＭｅｄｉａＳｏｕｒｃｅオブジェクトは１つ又は複数のＳｏｕｒｃｅＢｕｆｆｅｒオブジェクトを有し、各ＳｏｕｒｃｅＢｕｆｆｅｒオブジェクトは、ウェブページでの１つの再生ウィンドウに対応して、ウィンドウでの再生対象のセグメントメディアファイルを受信するために使われることができる。

【0157】

メディアファイルの再生過程において、プレイヤーにおける分析器（Ｐａｒｓｅｒ）は新たに取得されたメディアデータを分析し、引き続き新たなセグメントメディアファイルを構築し、ＳｏｕｒｃｅＢｕｆｆｅｒオブジェクトのａｐｐｅｎｄＢｕｆｆｅｒ方法を実行することで、セグメントメディアファイルを同一のＳｏｕｒｃｅＢｕｆｆｅｒオブジェクトのＳｏｕｒｃｅＢｕｆｆｅｒオブジェクトに追加する。

【0158】

ステップＳ４０２において、プレイヤーは、メディアソース拡張インターフェースを呼び出してメディアソースオブジェクトに対応する仮想アドレスを作成する。

【0159】

例えば、プレイヤーは、メディアソース拡張インターフェースにパッケージされたｃｒｅａｔｅＯｂｊｅｃｔＵＲＬ方法を実行することで、メディアソースオブジェクトに対応する仮想アドレス、即ち仮想ＵＲＬを作成し、仮想アドレスには、Ｂｌｏｂタイプのセグメントメディアファイルがパッケージされている。

【0160】

なお、プレイヤーは、ＭｅｄｉａＳｏｕｒｃｅオブジェクトを仮想ＵＲＬのソース（ｓｒｃ）属性に設定し、即ち、仮想ＵＲＬをウェブページにおけるメディア要素、例えばｖｉｄｅｏ・ａｕｄｉｏ要素に紐付け、この過程を、メディアソースオブジェクトウェブページ中のメディア要素に関連付けるとも呼ぶ。

【0161】

ステップＳ４０３において、プレイヤーは、ウェブページのメディア要素に仮想アドレスを伝送し、仮想アドレスはメディア要素がメディアソースオブジェクトをデータ源として再生するために使われる。

【0162】

例えば、プレイヤーには、メディア要素を呼び出して仮想ＵＲＬを再生するステートメント、例えば、<ａｕｄｉｏ>仮想ＵＲＬが含まれている。ブラウザがウェブページに埋め込まれたプレイヤーにおける対応するステートメントを分析すると、ブラウザのメディア要素に仮想ＵＲＬを紐付けるＳｏｕｒｃｅＢｕｆｆｅｒオブジェクトからセグメントメディアファイルを読ませて、復号及び再生を行わせる。

【0163】

以下、プレイヤーがＭＰ４ファイルをＦＭＰ４ファイルに変換し、メディアソース拡張インターフェースを介してウェブページで再生する過程を説明する。

【0164】

本開示の実施例によるＭＰ４ファイルがＦＭＰ４ファイル変換しメディアソース拡張インターフェースを介して再生する１つの模式図である図１２を参照すると、プレイヤーはメディアファイルの真のアドレス（ｈｔｔｐ://ｗｗｗ.ｔｏｕｔｉａｏ.ｃｏｍ/ａ/ｂ.ｍｐ４）に基づいて、サーバにＭＰ４ファイルにおける一部のメディアデータ、例えば、復号時間再生ポイントに続く規定時間帯にあるデータを取得することを要求する。

【0165】

プレイヤーは取得されたメディアデータに基づいてＦＭＰ４ファイルを構築し、その後、ＭｅｄｉａＳｏｕｒｃｅオブジェクトに対応するＳｏｕｒｃｅＢｕｆｆｅｒオブジェクトに添加し、仮想ＵＲＬがＭｅｄｉａＳｏｕｒｃｅオブジェクトに紐付けられているため、プレイヤーがａｕｄｉｏ・ｖｉｄｅｏ要素を呼び出しコードが実行される場合、ａｕｄｉｏ・ｖｉｄｅｏ要素はＭｅｄｉａＳｏｕｒｃｅオブジェクトのＳｏｕｒｃｅＢｕｆｆｅｒオブジェクトから、引き続き添加された新たなＦＭＰ４ファイルを読み取って復号し、メディアファイルの連続再生を実現する。

【0166】

本開示の実施例において、メディアソースオブジェクトに添加されたセグメントメディアファイルは、現在再生中のセグメントメディアファイルとなる。例えば、現在セグメントメディアファイル１を再生し、それに続くセグメントメディアファイル２、３がすでに構築されていれば、構築されたセグメントメディアファイル２、３はＭＳＥのＳｏｕｒｃｅ Ｂｕｆｆｅｒに追加されプリロードされることになり、それに応じて、プレイヤーによって取得されたメディアデータに対応する２つのキーフレームのうちの第１のキーフレームは、セグメントメディアファイル１の後に現れた１番目のキーフレームとなる。

【0167】

プレイヤーがウェブページのメディア要素に伝送する仮想アドレスの場合、プレイヤーには、メディア要素を呼び出して仮想ＵＲＬを再生するステートメント、例えば、<ａｕｄｉｏ>仮想ＵＲＬが含まれている。ウェブページがウェブページに埋め込まれたプレイヤーにおける対応するステートメントを分析すると、ウェブページのメディア要素を仮想ＵＲＬに紐付けられたＳｏｕｒｃｅＢｕｆｆｅｒオブジェクトからセグメントメディアファイルを読ませて、復号及び再生を行わせる。

【0168】

以下、プレイヤーがＭＰ４ファイルをＦＭＰ４ファイルに変換しメディアソース拡張インターフェースを介してウェブページで再生する過程を説明する。

【0169】

本開示の実施例において、ウェブページのメディア要素は、メディアファイルの真のアドレスに基づいてメディアデータの取得を行うのではなく、仮想ＵＲＬに基づいてメディアソースオブジェクトの取得を行い、メディアファイルを再生するため、メディアファイルの真のアドレスに対する保護を実現する。

【0170】

次に、メディアファイルのネットワーク再生装置に対する説明を続ける。メディアファイルのネットワーク再生装置のハードウェア実施、又は、ソフトウェア実施の例示として、メディアファイルのネットワーク再生装置を、一連の信号/情報/データの層にカップリング関係が存在するモジュールとして提供し、以下図１３とともに説明する。本開示の実施例のメディアファイルのネットワーク再生装置の一選択可能な構成模式図である図１３を参照すると、メディアファイルのネットワーク再生装置を実現するために含まれた一連のユニットが示されているが、メディアファイルのネットワーク再生装置のユニット構造は図１３の図示のみに限定されるのではなく、例えば、ここでのユニットを、実現する異なる機能によって、さらに分割するか、又は合併することができる。図１３を参照すると、メディアファイルのネットワーク再生装置５００は、
サーバからメディアファイルにおけるメディアデータを取得するための取得ユニット５０１と、
前記メディアデータを含むセグメントメディアファイルを構築するための構築ユニット５０２と、
前記セグメントメディアファイルを前記メディアソース拡張インターフェースに送信し、前記メディアソース拡張インターフェースを介して前記ウェブページのメディア要素を呼び出して再生を行うための再生ユニット５０３と
を含み、
ここで、前記プレイヤーは、前記ウェブページで非ストリーミングメディアパッケージフォーマットを採用したメディアファイルを再生する。

【0171】

いくつかの実施例において、前記構築ユニット５０２は、取得されたメディアファイルにおけるメディアデータ、及び前記メディアファイルにおけるメタデータに基づいて、セグメントメディアファイルレベルのメタデータを算出するためのものである。

【0172】

取得されたメディアファイルにおけるメディアデータ、及び前記セグメントメディアファイルレベルのメタデータをセグメントメディアファイル容器にパッケージし、前記セグメントメディアファイルを得る。

【0173】

いくつかの実施例において、前記取得ユニット５０１は、
前記メディアファイルで識別されたメディア情報に基づいて、前記メディアファイルにおけるリアルタイム再生ポイントに続く２つのキーフレームを特定し、
前記メディアファイルにおける前記２つのキーフレーの間のメディアデータを取得するためのネットワーク要求を前記サーバに送信し、
前記サーバから返された前記２つのキーフレームの間のメディアデータを受信するためのものである。

【0174】

いくつかの実施例において、前記取得ユニット５０１は、
メディアファイルから識別されたメディア情報に基づいて、前記２つのキーフレームの間のビデオフレームが前記メディアファイルでのオフセット量及びサイズ、及び、前記ビデオフレームに合わせたオーディオフレームが前記メディアファイルでのオフセット量及びサイズを特定し、
特定されたオフセット量及びサイズに基づいて、前記ネットワーク要求に持たされる目標区間のオフセット量及びサイズを特定し、前記サーバに前記目標区間に含まれている前記ビデオフレームと前記オーディオフレームを送信するためのものである。

【0175】

いくつかの実施例において、前記装置は、要求ユニット５０４をさらに含む。

【0176】

要求ユニット５０４は、
設定されたオフセット量及びサイズに基づいて、前記サーバに前記メディアファイルにおける、前記マルチメディアファイルにおいて前記オフセット量から始まり、且つ、前記サイズに該当するメタデータを要求し、
前記サーバから返された前記メタデータからメディア情報を識別するためのものであり、
前記メディア情報は、要求されたメディアデータが前記メディアファイルでのオフセット量及びサイズを位置決めするためのものである。

【0177】

いくつかの実施例において、前記取得ユニット５０１は、
設定されたオフセット量及びサイズによって、前記サーバに要求したメタデータから完全なメディア情報が識別されていない場合、メタデータ容器のヘッド部から前記メタデータ容器のオフセット量及びサイズを算出し、
前記サーバに前記メディアファイルにおける、前記マルチメディアファイルにおいて前記オフセット量から始まり、且つ前記サイズに該当する前記メタデータを要求し、
取得された前記メタデータから対応するメディア情報を識別して得るためのものでもある。

【0178】

いくつかの実施例において、前記メディアソース拡張インターフェースが、受信された前記セグメントメディアファイルを、前記メディアソース拡張インターフェースにおけるメディアソースオブジェクトに追加し、
前記メディアソースオブジェクトに対応する仮想アドレスを作成し、
前記ブラウザのメディア要素に、前記メディア要素が前記メディアソースオブジェクトをデータ源として再生を行うために使われる前記仮想アドレスを伝送する。

【0179】

上記をまとめると、本開示の上記実施例によれば、以下の有益な效果を有する。

【0180】

１、フロントエンドプレイヤーが非ストリーミングメディアパッケージフォーマットのメディアファイルをセグメントメディアファイルに変換することで、ストレージサービス及びＣＤＮを配置する必要がなくなり、非ストリーミングメディアパッケージフォーマットのメディアファイルを再生するリアルタイムコストを低減させ、ネットワークシステムアーキテクチャの負荷を低減させる。

【0181】

２、メディアファイルの規定時間帯を再生する必要がある場合、非ストリーミングメディアフォーマットのメディアファイルから規定時間のメディアデータを抽出するだけでよく、単独で復号可能なセグメントメディアファイルにパッケージすればよく、このようにすれば、非ストリーミングメディアフォーマットファイルが完全にダウンロードされてからこそ単独で再生できる制限を克服し、再生リアルタイム性が優れる一方、規定時間帯のみに対してセグメントメディアファイルを構築すればよく、完全なメディアファイルをストリーミングメディアフォーマットに予め変換するのではないため、変換遅延が小さくなり、予め記憶する必要もなく、当初のメディアファイル以外は余分なストレージスペースを占有せず、ストレージスペースの占有を格段に低減させる。

【0182】

３、プレイヤーは、非ストリーミングメディアフォーマットのメディアファイルにおけるメディアデータをセグメントメディアファイルに変換し、ウェブページのメディアソース拡張インターフェースを介して、ウェブページのメディア要素に送信し、復号及び再生を行うことで、プレイヤーがその埋め込まれたウェブページによって非ストリーミングメディアフォーマットのメディアファイルを再生することを実現し、非ストリーミングメディアパッケージフォーマットファイルが完全にダウンロードされてからこそ単独で再生できる制限を克服する。

【0183】

４、プレイヤーによって取得されたのはメディアファイルのキーフレーム同士の間の一部のメディアデータであることによって、メディアファイルを再生中、メディアデータのロードに対する制御を実現する。

【0184】

５、パッケージして得られたセグメントメディアファイルは、取得されたメディアファイルの全部のメディアデータではなく、メディアファイルの一部のメディアデータに基づくため、変換遅延が小さくなり、予め記憶しておく必要がなくなり、当初のメディアファイル以外は、余分なストレージスペースを占有しないため、ストレージスペースへの占有を格段に低減させる。さらに、ユーザが見る途中で、解像度が切り替える場合でも、黒い画面や動画が止まってしまうことがなくなり、解像度の切り替えのリアルタイム性能を向上させる。

【0185】

６、ウェブページのメディア要素は、メディアファイルの真のアドレスに基づいてメディアデータを取得及び再生するのではなく、仮想のアドレスに基づいて、セグメントメディアファイルを復号及び再生するため、ＭＰ４ファイルの真のアドレスに対する保護を実現する。

【0186】

以上は、本開示の具体的な実施形態に過ぎず、本開示の保護範囲はこれらに限定されず、当分野をよく分かる技術者であれば、本開示に開示された技術範囲内で簡単に想到できる変化や置き換えは、全て本開示の保護範囲内に含まれる。従って、本開示の保護範囲は添付の請求項の保護範囲を基準とすべきである。

【符号の説明】

【0187】

20 ネットワーク
30 サーバ
150 プロセッサ
170 ネットワークインターフェース
180 ユーザインターフェース
190 メモリ
500 メディアファイルのネットワーク再生装置
501 取得ユニット
502 構築ユニット
503 再生ユニット
504 要求ユニット
600 メディアファイルのネットワーク再生装置

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】