IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ベイジン バイトダンス ネットワーク テクノロジー カンパニー リミテッドの特許一覧

特許7181308メディア再生のローディング制御方法、装置及び記憶媒体
<>
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図1
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図2
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図3
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図4
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図5
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図6
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図7
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図8
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図9
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図10
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図11
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図12
  • 特許-メディア再生のローディング制御方法、装置及び記憶媒体 図13
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-11-21
(45)【発行日】2022-11-30
(54)【発明の名称】メディア再生のローディング制御方法、装置及び記憶媒体
(51)【国際特許分類】
   H04N 21/438 20110101AFI20221122BHJP
   H04N 21/442 20110101ALI20221122BHJP
   G06F 13/00 20060101ALI20221122BHJP
【FI】
H04N21/438
H04N21/442
G06F13/00
【請求項の数】 20
(21)【出願番号】P 2020554342
(86)(22)【出願日】2018-08-31
(65)【公表番号】
(43)【公表日】2021-02-25
(86)【国際出願番号】 CN2018103485
(87)【国際公開番号】W WO2019227742
(87)【国際公開日】2019-12-05
【審査請求日】2020-06-24
(31)【優先権主張番号】201810530557.4
(32)【優先日】2018-05-29
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】520476341
【氏名又は名称】北京字節跳動網絡技術有限公司
【氏名又は名称原語表記】Beijing Bytedance Network Technology Co., Ltd.
【住所又は居所原語表記】Room B-0035, 2/F, No.3 Building, No.30, Shixing Road, Shijingshan District Beijing 100041 China
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(72)【発明者】
【氏名】▲銀▼ 国徽
【審査官】長谷川 素直
(56)【参考文献】
【文献】特表2017-524280(JP,A)
【文献】特開2017-041774(JP,A)
【文献】特開2016-026427(JP,A)
【文献】国際公開第2016/063780(WO,A1)
(58)【調査した分野】(Int.Cl.,DB名)
H04N 21/00-21/858
G06F 13/00
(57)【特許請求の範囲】
【請求項1】
メディア再生のローディング制御方法であって、
ウェブページに埋め込まれたプレーヤの再生過程において、前記プレーヤがプレロードしたメディアデータに対応する時間長を検出するステップと、
前記プレロードしたメディアデータに対応する時間長が固定時間長より小さい場合、プレロードしたメディアデータが前記固定時間長を満たすようなメディアデータを取得するステップと
ディアソース拡張インターフェースは、メディアソース対象を作成するステップと、
前記メディアデータをメディアソース拡張インターフェースにおけるメディアソース対象に追加するステップと、
メディアソース拡張インターフェースを呼び出して、前記メディアソース対象に対応する仮想アドレスを作成するステップと、
前記プレーヤは、前記メディアソース対象をデータソースとして再生するための仮想アドレスと関連付けるステップとを、備える方法。
【請求項2】
前記ウェブページのネットワークパラメータに適応した時間長を固定時間長と確定するステップを、さらに備える、
請求項1に記載の方法。
【請求項3】
前記ウェブページのネットワークパラメータに適応した時間長を固定時間長と確定するステップは、
メディアデータ伝送のダウンリンクネットワークの帯域幅と、プレロードしたメディアデータの量との正の相関関係に基づいて、前記プレーヤがプレロード可能なメディアデータの量を確定するステップと、
前記プレロード可能なメディアデータの量の再生時間長を前記固定時間長と確定するステップとを、さらに備える、
請求項2に記載の方法。
【請求項4】
前記ウェブページの特徴パラメータに適応した時間長を前記固定時間長と確定するステップを、さらに備える、
請求項1に記載の方法。
【請求項5】
前記ウェブページの特徴パラメータに適応した時間長を固定時間長と確定するステップは、
前記ウェブページにおける再生ウィンドウの数を取得するステップと、
再生ウィンドウの数と前記固定時間長の負の相関関係に基づいて、前記固定時間長を確定するステップとを、備える、
請求項4に記載の方法。
【請求項6】
前記プレロードしたメディアデータが、前記固定時間長を満たすようなメディアデータを取得するステップは、
メディアファイルにおいて第1キーフレームを定位して、前記第1キーフレームの復号時刻は、前記プレロードしたメディアデータの再生終了時刻より遅れないようにするステップと、
前記メディアファイルにおいて第2キーフレームを定位して、前記第2キーフレームの復号時刻と、プレロードしたメディアデータの再生開始時刻との差が、前記固定時間長であるようにするステップと、
前記メディアファイルから、前記第1キーフレームと第2キーフレームとの間のメディアデータを抽出するステップとを、備える、
請求項1に記載の方法。
【請求項7】
前記メディアファイルから、前記第1キーフレームと第2キーフレームとの間のメディアデータを抽出するステップは、
メディアファイルにおける、前記第1キーフレームと第2キーフレームとの間のビデオフレームのオフセット量とサイズ、及びメディアファイルにおける、前記ビデオフレームに合わせたオーディオフレームのオフセット量とサイズに基づいて、対象区間のオフセット量とサイズを確定するステップを備え、
前記対象区間は、前記ビデオフレームと前記オーディオフレームを含め、
前記対象区間のオフセット量とサイズに基づいて、前記メディアファイルのメディアデータ容器から、対応するメディアデータを抽出する、
請求項6に記載の方法。
【請求項8】
再生するメディアファイルが、MPEG-4ファイルフォーマットを用いる場合、前記固定時間長を満たすメディアデータに基づいて、セグメントメディアファイルを構築するステップと、
メディアソース拡張インターフェースを介して、前記セグメントメディアファイルを前記プレーヤに送信するステップとを、さらに備える、
請求項1から7のいずれか一項に記載の方法。
【請求項9】
前記ウェブページにおいて、プレロードしたメディアデータに対応するセグメント、及びプレロードしていないメディアデータに対応するセグメントを差別化表示するステップを、さらに備える、
請求項1から7のいずれか一項に記載の方法。
【請求項10】
メディア再生のローディング制御装置であって、
ウェブページに埋め込まれたプレーヤの再生過程において、前記プレーヤがプレロードしたメディアデータに対応する時間長を検出するように配置された検出部と、
前記プレロードしたメディアデータに対応する時間長が固定時間長より小さい場合、プレロードしたメディアデータが前記固定時間長を満たすようなメディアデータを取得するように配置された取得部と、
前記メディアデータをメディアソース拡張インターフェース内のメディアソース対象に追加するように配置される送信部と、を備え、
前記プレーヤは、前記メディアソース拡張インターフェースを呼び出して、前記メディアソース対象に対応する仮想アドレスを作成し、
前記プレーヤは、メディアソース対象をデータソースとして再生するための仮想アドレスと関連付ける装置。
【請求項11】
前記ウェブページのネットワークパラメータに適応した時間長を前記固定時間長と確定するように配置された第1確定部、をさらに備える、
請求項10に記載の装置。
【請求項12】
前記第1確定部は、さらに、メディアデータの伝送のダウンリンクネットワークの帯域幅と、プレロードしたメディアデータの量との正の相関関係に基づいて、前記プレーヤがプレロード可能なメディアデータの量を確定するように配置され、
前記プレロード可能なメディアデータの量の再生時間長を前記固定時間長と確定する、
請求項11に記載の装置。
【請求項13】
前記ウェブページの特徴パラメータに適応した時間長を前記固定時間長と確定するように配置された第2確定部を、さらに備える、
請求項10に記載の装置。
【請求項14】
前記第2確定部は、さらに、前記ウェブページにおける再生ウィンドウの数を取得するように配置され、
再生ウィンドウの数と前記固定時間長との負の相関関係に基づいて、前記固定時間長を確定する、
請求項13に記載の装置。
【請求項15】
前記取得部は、さらに、メディアファイルにおいて第1キーフレームを定位するように配置され、その中、前記第1キーフレームの復号時刻は、前記プレロードしたメディアデータの再生終了時刻より遅れなく、
前記メディアファイルにおいて第2キーフレームを定位するように配置され、その中、前記第2キーフレームの復号時刻と、プレロードしたメディアデータの再生開始時刻との差は、前記固定時間長であり、
前記メディアファイルから、前記第1キーフレームと前記第2キーフレームとの間のメディアデータを抽出する、
請求項10に記載の装置。
【請求項16】
前記取得部は、メディアファイルにおける、前記第1キーフレームと前記第2キーフレームとの間のビデオフレームのオフセット量とサイズ、及び前記メディアファイルにおける、前記ビデオフレームに合わせたオーディオフレームのオフセット量とサイズに基づいて、対象区間のオフセット量とサイズを確定するようにさらに配置され、
前記対象区間は、前記ビデオフレームと前記オーディオフレームを含め、
前記対象区間のオフセット量とサイズに基づいて、前記メディアファイルのメディアデータ容器から対応するメディアデータを抽出する、
請求項15に記載の装置。
【請求項17】
前記送信部は、再生するメディアファイルが、MPEG-4ファイルフォーマットを用いる場合、前記固定時間長を満たすメディアデータに基づいてセグメントメディアファイルを構築するようにさらに配置され、
メディアソース拡張インターフェースを介して、前記セグメントメディアファイルを前記プレーヤに送信する、
請求項10から16のいずれか一項に記載の装置。
【請求項18】
前記ウェブページにおいて、プレロードしたメディアデータに対応するセグメント、及びプレロードしていないメディアデータに対応するセグメントを差別化表示するように配置された表示部を、さらに備える、
請求項10から16のいずれか一項に記載の装置。
【請求項19】
メディア再生のローディング制御装置であって、
実行可能な指令を記憶するように配置されたメモリと、
メモリに記憶されている実行可能な指令を実行する際に、請求項1から9のいずれか一項に記載のメディア再生のローディング制御方法を実現するように配置されたプロセッサとを、備える、メディア再生のローディング制御装置。
【請求項20】
記憶媒体であって、
実行可能な指令を記憶し、
前記実行可能な指令が実行される際、請求項1から9のいずれか一項に記載のメディア再生のローディング制御方法を実現するために用いられる、記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の交差引用
本出願は、2018年05月29日付で出願された中国特許出願(出願番号201810530557.4)に基づくものであり、当該中国特許出願の優先権を主張し、その内容の全てをここに参照として取り込む。
【0002】
本開示は、メディア再生技術に関し、特にメディア再生のローディング制御方法、装置及び記憶媒体に関する。
【背景技術】
【0003】
ウェブページを介してメディアファイルを再生する際、ウェブページは、現在の再生箇所から終了時刻までの全てのメディアデータをロードするまで、現在の再生箇所に基づいて、後続のメディアデータをプレロードする。再生箇所を切り換える度に、ウェブページは現在の再生箇所から終了箇所までの全てのメディアデータをロードし直す。メディアデータを繰り返し請求してロードする必要である一方、ユーザはロードしたメディアデータを見ない可能性がある(例えば、ユーザが不連続に見るとき)。これによって、プレロードしたメディアデータが流量及び帯域幅を必要なく消費するとともに、ネットワークを占用したことでウェブページにおける他のサービスに遅延が生じる。
【発明の概要】
【課題を解決するための手段】
【0004】
こうした状況に鑑みて、本開示の実施例は、メディア再生のローディング制御方法、装置及び記憶媒体を提供し、プレロードしたメディアデータの制御を実現でき、プレロードしたメディアデータに対応する時間長を固定時間長にすることができる。
【0005】
本開示の実施例の技術は、以下のように実現している:
第一、本開示の実施例は、メディア再生のローディング制御方法を提供して、
ウェブページに埋め込まれたプレーヤの再生過程において、前記プレーヤがプレロードしたメディアデータに対応する時間長を検出するステップと、
前記プレロードしたメディアデータに対応する時間長が固定時間長より小さい場合、プレロードしたメディアデータが、前記固定時間長を満せるようなメディアデータを取得するステップと、
メディアソース拡張インターフェースを介して、取得した前記メディアデータを前記プレーヤが埋め込まれた前記ウェブページのメディア要素に送信してプレロードするステップと、を備える。
【0006】
第二、本開示の実施例は、メディア再生のローディング制御装置を提供して、
ウェブページに埋め込まれたプレーヤの再生過程において、前記プレーヤがプレロードしたメディアデータに対応する時間長を検出するように配置された検出部と、
前記プレロードしたメディアデータに対応する時間長が固定時間長より小さい場合、プレロードしたメディアデータが、前記固定時間長を満せるようなメディアデータを取得するように配置された取得部と、
メディアソース拡張インターフェースを介して、取得した前記メディアデータを前記ウェブページのメディア要素に送信してプレロードするように配置された送信部と、を備える。
【0007】
第三、本開示の実施例は、メディア再生のローディング制御装置を提供して、
実行可能な指令を記憶するように配置されたメモリと、
前記実行可能な指令を実行する際、本開示実施例のメディア再生のローディング制御方法を実現するように配置されたプロセッサと、を備える。そのうち、実行可能な指令は、インストールパッケージ、プログラム、コード、プラグイン、ライブラリー(動的/静的ライブラリー)であってよい。
【0008】
第四、本開示の実施例は、記憶媒体を提供して、実行可能な指令が記憶されている。前記実行可能な指令がプロセッサによって実行される際、本開示の実施例のメディア再生のローディング制御方法を実現する。
【0009】
本開示の実施例を適用すれば、以下のような効果を有する。
プレーヤの再生過程において、プレロードしたメディアデータに対する制御を実現し、プレロードしたメディアデータに対応する時間長を固定時間長とし、プレロードしたメディアデータが現在再生箇所から終了時刻までの全てのメディアデータであることによる流量及び帯域幅の必要ではない消費を回避できるとともに、ネットワークを占用したことによって生じたウェブページにおける他のサービスの遅延を緩和できる。
【図面の簡単な説明】
【0010】
図1】本開示の実施例に係る容器のある選択可能な構造の模式図である。
図2】本開示の実施例に係るMP4ファイルのある選択可能なパッケージ構造の模式図である。
図3】本開示の実施例に係るメディアファイルにおけるメディアデータ容器がメディアデータを記憶する構造の模式図である。
図4】本開示の実施例に係るセグメントMP4ファイルのある選択可能なパッケージ構造の模式図である。
図5】本開示の実施例に係るメディア再生のローディング制御システムの概略構成図である。
図6】本開示の実施例に係るメディア再生のローディング制御装置のハードウェアによる構造の模式図である。
図7】本開示の実施例に係るメディア再生のローディング制御方法の流れの模式図一である。
図8】本開示の実施例に係るセグメントメディアファイルをパッケージする流れの模式図である。
図9】本開示の実施例に係るプレーヤがウェブページのメディアソース拡張インターフェースを介して、セグメントメディアファイルを再生する模式図である。
図10】本開示の実施例に係るMP4ファイルをFMP4ファイルに変換して、メディアソース拡張インターフェースを介して再生する模式図である。
図11】本開示の実施例に係るプレロードしたメディアデータに対応するセグメント及びプレロードしていないメディアデータに対応するセグメントを差別化表示する模式図である。
図12】本開示の実施例に係るメディア再生のローディング制御方法の流れの模式図二である。
図13】本開示の実施例に係るメディア再生のローディング制御装置の構成の模式図である。
【発明を実施するための形態】
【0011】
以下では、図面及び実施例を結び付けて、本開示についてさらに詳しく説明する。なお、提供した実施形態は本開示を解釈するためのものであり、本開示を限定するものではない。また、以下において提供した実施例は本開示を実施するための一部の実施例であり、本開示を実施する全ての実施例を提供したわけではない。衝突しない場合には、本開示の実施例が記載した技術は、任意に組合せた方式で実施可能であることを理解されるところである。
【0012】
なお、本開示の実施例では、用語「備える」、「含める」或いはそのさまざまな変形は、非排他的な包含を含むことが意図され、一連の要素を備える方法又は装置は、明記した要素を備えるだけでなく、明記していない他の要素も備え、或いは、実施方法又は装置が固有する要素もさらに備える。さらなる制限なない場合、文言「1つの……を備える」によって限定される要素は、当該要素を備える方法又は装置において他の関連要素が存在することを排除するものではない(例えば、方法におけるステップ又は装置における部、例えば、部は一部の回路、一部のプロセッサ、一部のプログラム或いはソフトウェア等であってもよい)。
【0013】
例えば、本開示の実施例に係るメディア再生のローディング制御方法は、一連のステップを含めるが、本開示の実施例に係るメディア再生のローディング制御方法は、記載したステップに限られるものではない。同様に、本開示の実施例に係るメディア再生のローディング制御装置は、一連の部を備えるが、本開示の実施例に係る装置は明記された部を備えるものに限られず、関連情報を取得し、或いは情報に基づいて処理を実行する際に設置する必要である部をさらに備えてもよい。
【0014】
本開示についてさらに詳しく説明する前に、本開示の実施例に係る名詞及び用語を説明する。本開示の実施例に係る名詞及び用語は、以下の解釈を適用する。
【0015】
(1)メディアファイルは、容器(Box、又はボックスと呼ばれる)の方式で符号化するメディアデータ(例えば、オーディオデータ及びビデオデータの少なくとも1種類)を記憶するファイルである。中には、メタデータ、即ち、メディアデータを記述するデータをさらに含める。メタデータには、メディアデータが正確に復号化されることを確保するメディア情報が載置されている。
【0016】
例えば、MP4容器フォーマットを用いてメディアデータをパッケージしたファイルはMP4ファイルと呼ばれる。典型的に、MP4ファイルには、AVC(Advanced Video Coding、即ち、H.264)或いはMPEG-4(Part2)の規格で符号化したビデオデータ、及びAAC(Advanced Audio Coding)の規格で符号化したオーディオデータが記憶されている。もちろん、ビデオデータ及びオーディオデータのその他の符号化方式を排除しない。
【0017】
(2)容器(Box)、又はボックスと呼ばれ、唯一のタイプ識別子及び長さで定義されたオブジェクト指向構成要素である。図1を参照する。図1は、本開示の実施例に係る容器のある選択可能な構造の模式図であり、容器ヘッダ(Box Headr)と容器データ(Box Data)を備え、中には様々な情報を表すためのバイナリデータがパッディングされている。
【0018】
容器ヘッダは、サイズ(size)とタイプ(type)を備え、サイズは容器が占用した記憶空間の大きさを明示し(本開示では、容量、又は長さとも呼ばれる)、タイプは容器の種類を明示する。図2を参照する。図2は、本開示の実施例に係るMP4ファイルのある選択可能なパッケージ構造の模式図である。MP4ファイルに係る基本の容器タイプは、ファイルタイプ容器(ftyp box)と、メタデータ容器(moov box)と、メディアデータ容器(mdat box)を含める。
【0019】
容器データ部分は、具体的なデータを記憶でき、この場合、容器は「データ容器」と呼ばれる。容器データ部分は、その他の種類の容器をさらにパッケージすることができ、この場合、容器は「容器の容器」と呼ばれる。
【0020】
(3)トラック(Track)は、メディアデータ容器において時間順でソートされた関連するサンプル(Sample)である。メディアデータに対して、トラックは、1つのビデオフレームシーケンス又は1つのオーディオフレームシーケンスを示し、ビデオフレームシーケンスに同期する字幕のトラックをさらに含めてもよい。同一トラックにおける1組の連続するサンプルは、チャンク(Chunk)と呼ばれる。
【0021】
(4)ファイルタイプ容器は、メディアファイルにおいてファイルのサイズ(即ち、占用したバイトの長さ)及びタイプを記憶するための容器である。図2のように、ファイルタイプ容器を「ftyp box」とし、その中に記憶されたバイナリデータは、規定されたバイト長さでファイルの容器のタイプ及びサイズを記述する。
【0022】
(5)メタデータ容器は、メディアデータにおいてメタデータを記憶する(即ち、メディアデータ容器に記憶されたメディアデータを記述するデータ)容器である。MP4ファイルにおけるメタデータ容器に記憶されたバイナリデータが示す情報は、メディア情報と呼ばれる。
【0023】
図2のように、メタデータ容器のヘッダは、バイナリデータを用いて容器のタイプを「moov box」と示す。容器データ部分は、MP4ファイルの全般的な情報を記憶するためのmvhd容器をパッケージして、MP4ファイルに独立すると共に、MP4ファイルの再生に関連して、時間長と、作成時刻及び修正時刻などを含める。
【0024】
メディアファイルのメディデータ容器は、複数のトラックに対応するサブ容器を備えてもよい、例えば、オーディオトラック容器(audio track box)やビデオトラック容器(video track box)である。オーディオトラック容器及びビデオトラック容器のいずれのサブ容器にも、対応するトラックのメディアデータの引用と記述を含める。必要なサブ容器は、トラックの特徴及び全般的な情報(例えば、時間長、幅と高さ)を記述する容器(tkhd boxとする)、トラックのメディア情報(例えば、メディアタイプとサンプルの情報)を記録する容器(mdia boxとする)を含める。
【0025】
mdia boxにパッケージされたサブ容器について、トラックの関連属性と内容を記録する容器(mdhd boxとする)と、メディアの再生過程の情報を記録する容器(hdlr boxとする)と、トラックにおけるメディアデータのメディア情報を記述する容器(minf boxとする)とを含めてもよい。minf boxには、さらに、メディア情報をどのように定位することを解釈するためのサブ容器(dinf boxとする)と、トラックにおけるサンプルの全ての時間情報(復号化時刻/表示時刻)、位置情報及び符号化/復号化などの情報を記録するためのサブ容器(stbl boxとする)とをパッケージした。
【0026】
図3を参照する。図3は、本開示の実施例に係るメディアファイルにおけるメディアデータ容器に記憶されるメディアデータの構造の模式図である。stbl box容器からバイナリデータによって識別されたメディア情報を用いて、サンプルの時間、タイプ、サイズ及びメディアデータ容器における位置を解釈できる。次に、stbl boxにおける各サブ容器について説明する。
【0027】
stsd boxには、サンプル説明(sample description)テーブルが含められ、異なる符号化方式と記憶されたデータのファイル数に基づいて、各メディアファイルには1つ又は複数の説明テーブルを有してもよく、説明テーブルを通じて各サンプルの説明情報を見つけることができる。説明情報は、サンプルが正確に復号化されることを保障できる。メディアのタイプによって記憶された説明情報も違い、例えば、ビデオメディアの場合では、説明情報は画像の構造である。
【0028】
stts boxには、サンプルの時間長情報が記憶されていると共に、テーブルを提供して時間(復号化時刻)とサンプルの番号をマッピングする。stts boxによって、メディアファイルにおける何れの時間のサンプルを定位することができる。stts boxでは、さらに、他のテーブルを用いてサンプルのサイズとポインタをマッピングし、テーブルの各項目が、同じ時間オフセットにおいて連続するサンプルの番号とサンプルのオフセットを提供し、これらのオフセットを累増することで、完全な時間-サンプルのマッピングテーブルを作成することができる。計算式は以下になる:
【0029】
DT(n+1)=DT(n)+STTS(n) (1)
【0030】
ここで、STTS(n)は圧縮されていないSTTSの第n項目の情報であり、DTは第n個目のサンプルの表示時間である。サンプルの配列は、時間順で配列されており、このようにすることで、オフセットは常に非負値である。DTは、一般的に0から始まり、DTの計算式は以下になる:
【0031】
DT(i)=SUM
(for j=0 to i-1 of delta(j)) (2)
【0032】
全てのオフセットの合計は、トラックにおけるメディアデータの時間長である。
【0033】
stss boxは、メディアファイルにおけるキーフレームの番号を記録する。
【0034】
stsc boxは、サンプルとサンプルを記憶するチャンクのマッピング関係を記録し、テーブルによってサンプルの番号とチャンクの番号との関係をマッピングして、テーブルを調べることによって指定のサンプルが含められるチャンクを見つけることができる。
【0035】
stco boxは、各チャンクのトラックの位置を定義する。この位置は、メディアデータ容器の開始バイトのオフセットと、前記開始バイトに対する長さ(即ち、サイズ)を用いて示される。
【0036】
stsz boxは、メディアファイルにおける各サンプルのサイズ(即ち、大きさ)を記録する。
【0037】
(6)メディアデータ容器は、メディアファイルにおいてメディアデータを記憶するための容器である。例えば、MP4ファイルにおけるメディアデータ容器は、図3のように、サンプルがメディアデータ容器に記憶された単位であり、メディアファイルのチャンクに記憶され、チャンクとサンプルの長さは互いに異なってもよい。
【0038】
(7)セグメントメディアファイルは、メディアファイルが分割されて形成されたサブファイルであり、各セグメントメディアファイルは単独に復号化することができる。
【0039】
MP4ファイルを例として、MP4ファイルにおけるメディアファイルをキーフレームによって分割して、分割したメディアファイルと対応するメタデータをパッケージしてセグメントMP4(Fragmented MP4)ファイルを形成する。各FMP4ファイルのメタデータは、メディアデータが正確に復号化されることを保障することができる。
【0040】
例えば、図2のようなMP4ファイルを複数のFMP4ファイルに変換する場合、図4を参照する。図4は、本開示の実施例に係るセグメントMP4(FMP4)ファイルのある選択可能なパッケージ構造の模式図である。1つのMP4ファイルは、複数のFMP4ファイルに変換でき、各FMP4ファイルには、moov容器と、moof容器と、mdat容器との3つの基本な容器を備える。
【0041】
moov容器は、MP4ファイルレベルのメタデータを含め、FMP4ファイルの由来するMP4ファイルの全てのメディアデータを記述するために用いられる。例えば、MP4ファイルの時間長と、作成時刻及び修正時刻などである。
【0042】
moof容器は、FMP4ファイルにパッケージされたメディアデータを記述するためのセグメントレベルのメタデータを記憶し、FMP4ファイルにおけるメディアデータが復号化されることを保障する。
【0043】
1つのmoof容器と1つのmdat容器でセグメントMP4ファイルの1つのセグメントを構成する。1つのセグメントMP4ファイルには、このようなセグメントを1つ又は複数含めてもよい。各セグメントにパッケージされたメタデータは、セグメントにパッケージされたメディアデータが単独に復号化されることを保障する。
【0044】
(8)メディアソース拡張(MSE,Media Source Extensions)インターフェースは、ウェブページにおいて実現されるプレーヤに向けるインターフェースである。ウェブページにおいてローディングする期間内に、ウェブページのインタプリタによって解釈され、フロントエンドプログラミング言語(例えば、JavaScript)を実行して実現されて、プレーヤに対してハイパーテキストマークアップ言語(HTML)及びメディア要素(Media Element)を呼び出して、メディアストリームを再生する機能を提供する。例えば、ビデオ要素<video>及びオーディオ要素<audio>を用いて、ビデオ/オーディオの再生機能を実現する。
【0045】
(9)ストリーミングメディアフォーマットは、メディアデータをストリーミングメディアのファイルにパッケージして、メディアファイルを完全にダウンロードする必要がなく、別途のトランスコードも必要がなくて、そのまま復号化して再生できる。即ち、オリジナルにダウンロードしながら再生することをサポートするパッケージ技術である。典型的なストリーミングメディアフォーマットのファイルは、例えば、HTTPライブストリーミング(HLS,HTTP Live Streaming)技術に基づくTSメディアファイルセグメント、FLV(Flash Video)ファイルなどである。
【0046】
(10)非ストリーミングメディアフォーマットは、メディアデータをメディアファイルにパッケージし、メディアファイルを完全にダウンロードしてから復号化され再生できるパッケージ技術である。典型的な非ストリーミングメディアフォーマットのファイルは、MP4ファイル、MKV(MKV file format)ファイル、WMV(Windows Media Video)ファイル、ASF(Advanced Streaming Format)ファイル等を含める。
【0047】
なお、MP4ファイルは、オリジナルにストリーミング再生をサポートしないが、オンライントランスコードした後、プレーヤに向けてトランスコードしたメディアストリーム、又は部分的にダウンロードしたMP4ファイルの欠損部分に無効のバイナリデータをパッディングすること(例えば、fytp容器とmoov容器を完全的にダウンロードした場合、mdat容器の欠損部分の代わりに無効のバイナリデータをパッディングすること)で、ダウンロードしながら再生する技術的効果を実現することができる。このようなオリジナルにストリーミング再生をサポートしないファイルのパッケージフォーマットはいずれも非ストリーミングメディアフォーマットと呼ばれる。
【0048】
まず、本開示の実施例に係るメディア再生のローディング制御装置について説明する。本開示に係るメディア再生のローディング制御装置は、スマートフォン、タブレットコンピュータ、ノートパソコンなどの各種類のユーザ端末として実現できる。次に、装置をユーザ端末として実現する場合、ユーザ端末を含める例示的な応用について説明する。
【0049】
図5を参照する。図5は、本開示の実施例に係るメディア再生のローディング制御システム100のある選択可能な結構の模式図であり、本開示の技術を実現するために例示的な応用である。ユーザ端末(例示的にユーザ端末10-1及びユーザ端末10-2を示した)は、ネットワーク20を通じてサーバ30に接続する。ネットワーク20は広域ネットワーク、或いはローカルエリアネットワークであってよく、又は、両者の組み合わせであってもよく、無線リンクを用いてデータ伝送を実現する。
【0050】
ユーザ端末10は、プレーヤが埋め込まれたウェブページを介して、メディアファイルを再生し、グラフィカルインタフェース110(例示的にグラフィカルインタフェース110-1及びグラフィカルインタフェース110-2を示した)に介して、再生されているコンテンツを表示する。再生の過程において、ユーザ端末10は、前記プレーヤがプレロードしたメディアデータに対応する時間長を検出する。前記プレロードしたメディアデータに対応する時間長が固定時間長より小さい場合、サーバ30からプレロードしたメディアデータが固定時間長を満せるようなメディアデータを取得して、メディアソース拡張インターフェースを介して、取得した前記メディアデータをウェブページのメディア要素に送信してプレロードする。
【0051】
続いて、本開示の実施形態に係るメディア再生のローディング制御装置について説明する。メディア再生のローディング制御装置は、ハードウェア、ソフトウェア、或いはソフトウェアとハードウェアの組み合わせの方式として提供できる。
【0052】
次に、メディア再生のローディング制御装置の、ソフトウェアとハードウェアの組み合わせによる実施について説明する。図6を参照する。図6は、本開示の実施例に係るメディア再生のローディング制御装置のある選択可能な構造の模式図である。以下では、本開示の実施例に係るメディア再生のローディング制御装置のハードウェア結構について詳しく説明する。図6では、メディア再生のローディング制御装置について、全ての構造ではなく、例示的な構造だけを示している。必要に応じて、図6の示す部分の構造又は全ての構造を実現することができる。
【0053】
本開示の実施例に係るメディア再生のローディング制御装置600は、少なくとも1つのプロセッサ601と、メモリ602と、ユーザインターフェース603と、少なくとも1つネットワークインターフェース604と、を備える。メディア再生のローディング制御装置600における各構成要素は、バスシステム605によって接続されている。理解されるように、バスシステム605は、これらの部品の間の接続通信を実現するために用いられる。バスシステム605はデータバスを除き、電源バス、制御バス及び状態信号バスを含める。ただし、説明を明確にするため、図6において各種のバスにバスシステム605と図示する。
【0054】
そのうち、ユーザインターフェース603は、ディスプレ、キーボード、マウス、トラックボール、クリックホイール、キー、ボタン、タッチパネル或いはタッチスクリーンなど、を備えてもよい。
【0055】
理解されるように、メモリ602は、揮発性メモリ又は不揮発性メモリであってよく、揮発性メモリと不揮発性メモリの両方を備えてもよい。
【0056】
本開示の実施例に係るメモリ602は、メディア再生のローディング制御装置600の操作をサポートするために、各タイプのデータを記憶するために用いられる。このようなデータの例示として、メディア再生のローディング制御装置600において操作するための如何なる実行可能な指令であり、例えば、実行可能な指令6021でああり、本開示の実施形態に係るメディア再生のローディング制御方法を実現するプログラムは実行可能な指令6021に含められてもよい。
【0057】
本開示の実施例が開示したメディア再生のローディング制御方法は、プロセッサ601に適用することができ、又は、プロセッサ601によって実現される。プロセッサ601は、集積回路チップであってよく、信号を処理する機能を有する。実現の過程において、メディア再生のローディング制御方法の各ステップは、プロセッサ601におけるハードウェアの集積倫理回路、又はソフトウェア形式の指令によって完成できる。前記プロセッサ601は、汎用プロセッサ、デジタル信号プロセッサ(DSP、Digital Signal Processor)、或いは他のプログラマブル論理デバイス、ディスクリートゲート又はトランジスタ倫理デバイス、ディスクリートハードウェア部品であってもよい。プロセッサ601は、本開示の実施例が開示した各方法、ステップ及び倫理ブロック図を実現、又は実行できる。汎用のロセッサは、マイクロプロセッサ又は如何なる従来のプロセッサなどであってもよい。本開示の実施例が開示した方法のステップと結び付けて、直接的にハードウェア復号プロセッサによって実行完了、又は、復号プロセッサにおけるハードウェアとソフトウェアモジュールの組み合わせによって実行完了する。ソフトウェアモジュールは、記憶媒体に位置されてよい。前記記憶媒体は、メモリ602に位置される。プロセッサ601は、メモリ602に記憶された情報を読み出して、ハードウェアと組み合わせて本開示の実施例に係るメディア再生のローディング制御方法のステップを完了する。
【0058】
次に、メディア再生のローディング制御装置のハードウェアのみによる実現について説明する。本開示の実施例に係るメディア再生のローディング制御装置は、1つ又は複数のアプリケーション専用集積回路(ASIC,Application Specific Integrated Circuit)、デジタル信号処理(DSP,Digital Signal Processing)、プログラマブル論理デバイス(PLD,Programmable Logic Device)、複合プログラマブル論理デバイス(CPLD,Complex Programmable Logic Device)、フィールドプログラマブルゲートアレイ(FPGA,Field-Programmable Gate Array)、或いはその他の電子部品によって実現されることが可能であり、本開示の実施例に係るメディア再生のローディング制御方法を実現するために用いられる。
【0059】
次に、メディア再生のローディング制御装置のソフトウェアのみによる実現について説明する。本開示の実施形態に係るメディア再生のローディング制御装置は、アプリケーション又はプラグイン、或いは両者を組み合わせた方式を用いて実現することができる。
【0060】
例として、アプリケーションはメディア再生のローディング制御を行うために専用のクライアントであってよく、メディア再生のローディング制御機能を選択可能な機能とし、対応のプラクインをインストールすることによって実現されるクライアントであってもよい。
【0061】
例として、プラグインは、アプリケーションの機能アップデートパッケージとして実現可能であり、特定のアプリケーションにメディア再生のローディング制御機能を追加する。メディア再生のウェブページにおける要素であってもよい。フロントエンド言語を用いて実現し、ウェブページによって直接に解釈して実行され、ウェブページにおいてメディア再生のローディング制御機能を実現する。
【0062】
続いて、メディア再生のローディング制御方法の例示的な実施場面について説明する。
【0063】
メディア再生のローディング制御のある実施の形態として、インタプリタのウェブページに埋め込まれたプレーヤによって実現可能である。プレーヤが、インタプリタのウェブページにおいてメディアファイルを再生する。インタプリタのウェブページを介して再生する過程において、プレロードしたメディアデータに対応する時間長が固定時間長より小さいと検出した場合、プレーヤは、サーバからプレロードしたメディアデータが固定時間長を満たせるようなメディアデータを取得する。そして、プレーヤが、メディアソース拡張インターフェースを介して、取得したメディアデータをインタプリタのメディア要素(ビデオ要素及び/或いはオーディオ要素)に送信して、メディアデータをプレロードする。
【0064】
メディア再生のローディング制御のある実施の形態として、APPのウェブページに埋め込まれたプレーヤによって実現されてもよい。前記APPにインタプリタのカーネルが埋め込まれ、プレーヤは、APPがインタプリタのカーネルを呼び出してロードしたウェブページにおいて、メディアファイルを再生する。インタプリタのカーネルが埋め込まれたWeChat(チャットアプリ)のクライアントを例として、ユーザは、WeChatのクライアントに埋め込まれたインタプリタのカーネルによってメディアファイルの再生ページをロード可能である。プレーヤが、プレロードしたメディアデータに対応する時間長が固定時間長いかであると検出した場合、サーバからプレロードしたメディアデータが固定時間長を満たせるようなメディアデータを取得する。そして、メディアソース拡張インターフェースを介して、取得したメディアデータをWeChatのクライアントのメディア要素(ビデオ要素及び/或いはオーディオ要素)に送信して、メディアデータをプレロードする。
【0065】
プレーヤがメディアファイルを再生する過程において、固定時間長はプレーヤのリアルタイムの再生箇所を接続するために用いられて、メディアファイルの連続再生を実現する。再生箇所について、メディアファイルを連続再生する(即ち、ユーザが干渉を加えていない状態で自然再生する)方式で到達した再生時刻であってよく、例えば、30分目から40分目まで再生した再生箇所である。ジャンプ方式(即ち、ユーザがカーソルでプログレスバーをクリックしてページのジャンプを実現する)で到達した再生時刻であってもよく、例えば、元の再生箇所が再生進捗の20%であり、ジャンプ後の再生箇所が再生進捗の30%であり、プレロードしたメディアファイル、即ち、再生箇所以降ロードしたメディアデータである。
【0066】
続いて、プレーヤがウェブページに埋め込まれ、ウェブページがプレーヤのJS(JavaScript)コードを解析、実行することによってプレーヤを実現し、プレーヤがウェブページのメディア要素を使用してメディアファイルを再生することを例として、本開示の実施例に係るメディア再生のローディング制御方法について説明する。
【0067】
図7は、本開示の実施例に係るメディア再生のローディング制御方法のある選択可能なフローチャート模式図である。図7を参照して、本開示の実施例に係るメディア再生のローディング制御方法は、ステップ201からステップ203を含め、以下、それぞれについて説明する。
【0068】
ステップ201:プレーヤがウェブページを介して再生する過程において、プレーヤがプレロードしたメディアデータに対応する時間長を検出する。
【0069】
ある実施例では、以下の方式でプレロードされたメディアデータに対応する時間長を取得することができる。
【0070】
メディアファイルのリアルタイムの再生箇所に対応する時刻、及びロードしたメディアデータに対応する再生終了時刻を取得し、再生終了時刻と再生箇所に対応する時刻との差を計算して、プレロードしたメディアデータに対応する時間長とする。
【0071】
そのうち、以下のような方式でメディアファイルのリアルタイムの再生箇所に対応する時刻を取得することができる。メディアファイルの再生開始時刻を時間原点として、メディア時間座標系の時間メトリックに対して、リアルタイムの再生箇所に対応するメディアファイルのビデオフレームに対応する時刻を取得して、取得したビデオフレームの時刻を再生箇所に対応する時間とする。
【0072】
以下のような方式で、ロードしたメディアデータに対応する再生終了時刻を取得することができる。現在プレロードしたメディアデータの最後のビデオフレームに対応する時刻を取得して、取得した最後のビデオフレームに対応する時間を現在プレロードしたメディアデータに対応する再生終了時刻とする。
【0073】
ステップ202:プレロードしたメディアデータに対応する時間長が固定時間長より小さい場合、プレロードしたメディアデータが固定時間長を満たせるようなメディアデータを取得する。
【0074】
固定時間長について説明する。ある実施例では、予め固定時間長を設定してもよい。
【0075】
例示的に、プレーヤにおいて固定時間長を設定可能な機能を提供して、プレーヤの設定情報からプレーヤに設定された固定時間長を取得することができる。或いは、ウェブページ側(サービス側)が固定時間長の設定を行い、プレーヤがウェブページの設定情報からウェブページ側に設定された固定時間長を取得することができる。実際に実施する際、固定時間長は、一回設定すれば有効であり、或いは特定の時間内で有効であり、或いは特定のメディアファイル(例えば、特定のタイプ)に対して有効であり、或いは登録ユーザの設定によって有効である。
【0076】
ある実施例では、固定時間長はプレーヤの自動適応によって得られる。
【0077】
例示的に、プレーヤは、ウェブページのネットワークパラメータに適応した時間長を固定時間長と確定する。
【0078】
データ伝送を行うダウンリンクネットワークの帯域幅をネットワークパラメータの例として、固定時間長の適応について説明する。固定時間長が長ければ、固定時間長に対応するメディアデータの量が多くなり、再生箇所の更新後にサーバに要求するメディアデータ量も多くなり、占用するダウンリンクネットワークの帯域幅も広くなる。即ち、固定時間長の長さとダウンリンクネットワークの帯域幅とは、正の相関関係がある。そこで、ネットワークの伝送性能を保障するために、プレーヤは、現在のダウンリンクネットワークの帯域幅、及び固定時間長の長さとダウンリンクネットワークの正の相関関係に基づいて、固定時間長の長さを適切に設定することができる。
【0079】
データ伝送を行う伝送流量をネットワークパラメータの例として、固定時間長の適応について説明する。固定時間長が長ければ、固定時間長に対応するメディアデータの量が多くなり、再生箇所のさら新後に、プレーヤがサーバから取得要求するメディアデータの流量も大きくなる。そこで、ネットワークの伝送性能を保障するために、現在行われているメディアデータ伝送の伝送流量が大きければ、固定時間長を短く設定する必要がある。即ち、伝送流量と固定時間長の長さとは、負の相関関係がある。プレーヤは、現在行われているデータ伝送の伝送流量、及び伝送流量と固定時間長の長さとの負の相関関係に基づいて、固定時間長の長さを確定することができる。
【0080】
例示的に、プレーヤは、ウェブページの特徴パラメータに適応する時間長を固定時間長と確定する。
【0081】
ウェブページにおける再生ウィンドウの数を特徴パラメータの例として、固定時間長の適応について説明する。ウェブページにおける再生ウィンドウの数が多ければ、ウェブページとサーバのデータ交換回数が多くて、ネットワークの負荷も大きくなる。そこで、ネットワークの性能を保障するために、ウェブページにおける再生ウィンドウの数が多い場合、固定時間長の長さを短く設定する必要がある。即ち、再生ウィンドウの数と固定時間長の長さとは、負の相関関係がある。プレーヤは、現在のウェブページにおける再生ウィンドウの数、及び再生ウィンドウの数と固定時間長の長さとの負の相関関係に基づいて、固定時間長の長さを確定することができる。
【0082】
特徴パラメータが、ウェブページにおける再生ウィンドウの数である場合、さらに再生ウィンドウの再生状態に基づいて、固定時間長の適切な設定を行うことができる。例えば、現在、再生状態(即ち、メディア再生のローディング制御を実行中)にある再生ウィンドウの数を取得し、再生状態にある再生ウィンドウの数と固定時間長との負の相関関係に基づいて、固定時間長の長さを確定する。
【0083】
続いて、メディアデータの取得について説明する。実際の応用において、メディアデータは、ビデオフレームとオーディオフレームを備えてよい。1部の映画又は1トラックを再生する際、プレーヤは、データストリームを正確に解析し、一定の時間に対して対応するメディアデータを取得すると共に、前記メディアデータが独立に復号されることを確保する。ある実施例では、以下のような方式でプレロードしたメディアデータが固定時間長を満たせるようなメディアデータを取得することができる。
【0084】
メディアファイルにおいて、第1キーフレームを定位して、第1キーフレームの復号時刻は、現在プレロードしたメディアデータの再生終了時刻に遅れない。メディアファイルにおいて、第2キーフレームを定位し、第2キーフレームの復号時刻とプレロードしたメディアデータの再生開始時刻との差は、固定時間長である。メディアファイルから第1キーフレームと第2キーフレームのとの間メディアデータを抽出する。即ち、固定時間長のメディアデータは、キーフレームを単位として分割されたものである。
【0085】
続いて、第1キーフレーム及び第2キーフレームを定位することについて説明する。MP4ファイルをメディアファイルの例として、プレーヤは、MP4ファイルから識別したメディア情報(ビデオ/オーディオフレームのオフセット、サイズ、復号時刻などの情報)に基づいて、第1キーフレーム及び第2キーフレームを定位することができる。プレーヤが現在プレロードしたメディアデータの最後のビデオフレームは、通常フレームである又はキーフレームである2つの場合がある。以下では、この2つの場合について、それぞれ第1キーフレームの定位を説明する。
【0086】
現在プレロードしたビデオデータの最後のビデオフレームがキーフレームである場合に対して、復号データ(即ち、キーフレーム)の欠落によってフレームスキップが生じることを回避するために、第1キーフレームの復号時刻は、プレロードしたビデオデータの再生終了時刻に遅れない。現在プレロードしたビデオデータの最後のビデオフレームがキーフレームであれば、最後の1つのビデオフレームを第1キーフレームとする。このように、余分なデータの請求を最大限に減少し、リンクと流量を占用したことによってウェブページにおける非メディア再生サービスが遅延することを回避する。
【0087】
現在プレロードしたビデオテータの最後のビデオフレームが通常フレームである場合に対して、復号データ(即ち、キーフレーム)の欠落によってフレームスキップが生じることを回避するために、第1キーフレームの復号時刻は、プレロードしたビデオデータの再生終了時刻に遅れない。従って、前記通常フレームの前の最初のキーフレーム(即ち、通常フレームの前にある通常フレームに一番近いキーフレーム)を第1キーフレームとする、即ち、現在プレロードされたビデオデータの最後のキーフレームを第1キーフレームとする。このようにすることで、現在プレロードしたビデオデータの最後のビデオフレームが、正確に復号するための十分な情報を有することを保障することができる。復号データ(即ち、キーフレーム)の欠落でフレームスキップが生じることはない。
【0088】
続いて、第2キーフレームの定位について説明する。ある実施例では、プレーヤは以下のような方式で、MP4ファイルにおいて第2キーフレームを定位することができる。プレロードしたメディアデータの再生開始時刻を確定する。固定時間長のメディアデータは、キーフレームを単位として分割されたものであるので、再生開始時刻は、即ち、最初のキーフレームに対応する復号時刻である。MP4ファイルにおける復号時刻と再生開始時刻との差を固定時間長とするキーフレームを第2キーフレームとする。MP4ファイルにおける復号時刻と再生開始時刻との差を固定時間長とするビデオフレームが通常フレームであれば、フレームスキップが生じることを回避するために、前記通常フレームの後の最初のキーフレームを第2キーフレームとする。
【0089】
続いて、プレーヤが、メディアファイルからメディア情報を識別することについて説明する。ある実施例では、プレーヤは、以下のような方式でメディアファイルからメディア情報を識別することができる。設定したオフセット量とサイズに基づいて、サーバに対して設定したオフセット量とサイズに対応するメディアファイルにおけるデータを要求して(即ち、固定サイズのデータを要求して)、サーバから返信されたデータからメタデータ容器におけるメタデータを識別する。識別したメタデータを解析して、メディアファイルを記述するためのメディアデータ容器にパッケージされたメディアデータのメディア情報を得る。
【0090】
そのうち、設定されたサイズは現存のメディアファイルのファイルタイプ容器とメタデータ容器のサイズに基づいて、統計して得たものであってよい。設定したサイズが、設定比率(例えば、全部)のメディアファイルのファイルタイプ容器とメタデータ容器のサイズの合計をカバーできるようにして、メディアファイルのパッケージ構造がファイルタイプ容器、メタデータ容器及びメディアデータ容器を順次にパッケージしたものである場合、一回の要求でメタデータ容器にパッケージされた完全なメディアデータを得られることを確保する。ネット伝送時のリンクに対する占用状況を節約し、さらにリンクを占用したことによって、ウェブページにおける非メディア再生サービスがリンクを使用できないことで応答遅延することを回避した。
【0091】
MP4ファイルをメディアファイルの例として、プレーヤが取得したメタデータ容器にパッケージされたメディアデータは、即ち、MP4ファイルにおけるmoov boxにパッケージされたバイナリデータである。MP4ファイルのパッケージ構造は、fytp box、moov box及びmdat boxを順次にパッケージしたものである場合、サイズの設定は、既存のMP4ファイルのfytp boxとmoov boxのサイズに基づいて、統計して得たものであってよい。設定したサイズが、設定比率(例えば、全部)のMP4ファイルのfytp boxとmoov boxのバイナリデータの合計をカバーできるようにして、多くの場合において、一回でサーバから完全なバイナリデータを含めるmoov boxを要求して得られることを確保する。
【0092】
ある実施例では、プレーヤが、設定したオフセット量とサイズによってサーバから要求したバイナリデータにおいて、ゼロバイトからのあるバイナリデータは、ファイルタイプ容器に対応する。プレーヤが、容器ヘッダを読み出すことでファイルタイプ容器のサイズを得て、2番目の容器ヘッダを読み出すことで次の容器のタイプ及びサイズを得る。2番目の容器のタイプがメタデータ容器であって、返信されたバイナリデータのサイズがファイルタイプ容器のサイズ及びメタデータ容器のサイズの合計以上である場合、設定したオフセット量とサイズによってサーバから要求したバイナリデータには、メタデータ容器にパッケージされたメタデータを含めることを示す。2番目の容器のタイプが、メタデータ容器であって、返信されたバイナリデータのサイズがファイルタイプ容器のサイズ及びメタデータ容器のサイズの合計以下である場合、設定したオフセット量とサイズによってサーバから要求したバイナリデータには、メタデータ容器にパッケージされたメタデータを含めていないことを示す。設定したオフセット量とサイズによってサーバから要求したバイナリデータには、メタデータ容器にパッケージされたメタデータを含めていない場合、プレーヤは、サーバから返信されたバイナリデータから容器のサイズを読み出して、メタデータ容器のヘーダに基づいてメタデータ容器のオフセット量とサイズを計算する必要がある。サーバに対してメタデータを要求するために、計算して得たオフセット量とサイズをネットワーク要求に携帯させる。サーバが要求に応じて、メディアファイルから計算して得たオフセットによってバイナリデータを読み出して、読み出したバイナリデータが計算したサイズに合致する場合に、データをプレーヤへ返信する。
【0093】
例を挙げて説明する。プレーヤは、サーバから返信されたバイナリデータから容器のサイズを読み出して、メタデータ容器のヘッダに基づいて、メタデータ容器のオフセット量とサイズを計算する。以下の2つの場合に関する。
【0094】
状況1)残りのバイナリデータ(即ち、返信されたバイナリデータからファイルタイプ容器のバイナリデータを除いたデータ)から読み出した容器のタイプがメタデータであって、残りのバイナリデータのサイズがメタデータ容器のサイズ以下である場合、初回要求したオフセット量とサイズの合計を新しいオフセットとして、サーバに対して2回目のバイナリデータの要求を行う。
【0095】
状況2)残りのバイナリデータから読み出した容器のタイプがメディアデータ容器である場合、メディアデータ容器のサイズとファイルタイプ容器のサイズとの合計を計算して新しいオフセットとして、サーバに対して2回目のバイナリデータの要求を行う。
【0096】
MP4ファイルをメディアファイルの例とする。プレーヤが、設定したオフセット量とサイズによってサーバから請求したバイナリデータには、完全なmoov boxのバイナリデータを含めていない場合、プレーヤは、サーバから返信されたバイナリデータから容器のタイプとサイズを読み出して、moov box がMP4ファイルにおけるオフセット量とサイズを確定する必要がある。
【0097】
MP4ファイルのバイナリデータでは、開始のバイトはいつもftyp boxに対応する。返信されたバイナリデータからftyp boxのバイナリデータを識別して、ftyp boxのヘッダに基づいて長さを得ることができることで、残りのバイナリデータから、ヘッダの規定の長さに基づいて、次のboxのバイナリデータを読み出す。ヘッダが示す容器のタイプに基づいて、以下のいくつかの状況がある。
【0098】
1)残りのバイナリデータ(即ち、返信されたバイナリデータからftyp boxのバイナリデータを除いたデータ)から読み出した容器のタイプがmoov boxであって、残りのバイナリデータのサイズがmoov boxのサイズ以上である場合、確定したシフトとサイズに基づいて、サーバからMP4ファイルにおけるmoov boxのオフセットを始まりとして、且つmoov boxがMP4ファイルにおけるサイズに合致するMP4ファイルの中のmoovデータを取得する。
【0099】
2)残りのバイナリデータから読み出した容器のタイプがmoov boxであって、残りのバイナリデータのサイズはmoov boxのサイズ以下である場合、moov boxのサイズと残りのバイナリデータのサイズとの差を計算して2回目の請求の新なサイズとし、初回の請求のオフセット量とサイズの合計を2回目の請求の新たなオフセットとして、サーバに対して2回目のバイナリデータの要求を行う。
【0100】
3)残りのバイナリデータから読み出した容器のタイプがmdat boxである場合、mdat boxのサイズとftyp boxのサイズの合計を計算して2回目の請求の新たなオフセットとして、設定したサイズでサーバに対して2回目のバイナリデータの要求を行う。
【0101】
このように、メディアファイルがどのようなパッケージ構造であっても、即ち、メディアファイルにおいてファイルタイプ容器、メタデータ容器及びメディアデータ容器のパッケージ順番がどのようであっても、プレーヤが最大2回の要求でサーバからメタデータ容器におけるメタデータを取得できることを保障することができ、メタデータの取得効率を向上させる。
【0102】
例を挙げて説明する。MP4ファイルに対して、サーバから返信されたバイナリデータは、MP4ファイルのパッケージ規則によって、ゼロバイトからの1つのバイナリデータはftyp boxに対応する。一方、boxのヘッダのパッケージ規則によって、ftyp boxのヘッダからftyp boxのサイズ(即ち、長さ)及び完全なMP4ファイルのサイズを読み出すことができる。仮に、ftyp boxのサイズをa(単位はバイト)とすると、a+1から後続の容器のヘッダ情報を読み出して、後続の容器のタイプとサイズを取得する。読み出して取得したftyp boxの後続がmoov boxであって、残りのバイナリデータのサイズ(設定サイズ- ftyp boxのサイズ)がmoov boxのサイズ以上であれば、moov boxの完全なバイナリデータを取得したことを示す。moov boxのオフセット量とサイズに基づいて、残りのバイナリデータからmoov boxにおけるメタデータを取得することができる。
【0103】
プレーヤは、サーバからメタデータ容器にパッケージされたメタデータを取得した後、メタデータ容器におけるサブ容器のネスト構造を解析して、サブ容器のネスト構造に基づいて、各サブ容器におけるバイナリデータを読み出す。読み出したバイナリデータから、各サブ容器の特徴であるメディアデータのメディア情報を解析する。実際の応用では、メディア情報、はメディアファイルにおけるビデオフレーム及び/或いはオーディオフレームのオフセット、サイズ、復号時刻などの情報を含めてもよい。
【0104】
MP4ファイルをメディアファイルの例とする。メタデータ容器は、即ち、moov boxである。図2を参照して分かるように、moov boxにはmvhd boxとtrack boxがパッケージされている。そのうち、mvhd boxのバイナリデータを解析することで、MP4ファイルの作成時刻、修正時刻、時間計測スケール、再生可能時間長、デフォルト音量などの情報を得られる。moov boxには複数のtrack boxを含め、各メディアトラック特有の記述情報を記録している。例えば、ビデオトラックvideo track boxに関して、video track boxには複数のサブ容器が複層に埋め込まれて、video track boxのネスト構造に基づいて対応するバイナリデータを解析して、MP4ファイルのビデオフレーム情報と、対応する画像情報を得られる。
【0105】
ある実施例では、プレーヤは、以下のような方式で取得したメタデータを解析し、メディア情報を得られる。順次に、メタデータ容器バイナリデータにおける、容器ヘッダの規定長さに対応するバイナリデータを解析して、前記メタデータ容器におけるサブ容器の容器タイプと、前記サブ容器の容器データの長さを得る。前記サブ容器の容器タイプに対応するタイプの解析器を呼び出して、解析していないデータにおける前記容器データの長さに対応するバイナリデータを順次に解析して、前記容器データが示すメディア情報を得る。
【0106】
そのうち、プレーヤが、メタデータ容器に複数のサブ容器が埋め込まれた状況に対して、毎回読み出したバイナリデータのオフセットが、識別したサブ容器の長さの合計である。読み出したバイナリデータの長さは、容器ヘッダの所定長さに合致して、現在処理しているサブ容器のタイプと長さを解析することができる。
【0107】
例えば、初回の読み出しの際に、メタデータ容器のバイナリデータのゼロバイトからバイナリデータを読み出して、読み出したバイナリデータの長さが容器ヘッダの規定長さに合致することによって、最初のサブ容器のタイプと長さを解析することができる。2回目の読み出しの際に、初回に読み出したサブ容器の長さをオフセットとして、バイナリデータを読み出し始めて、読み出したバイナリデータの長さが容器ヘッダの規定長さに合致することによって、2番目のサブ容器のタイプと長さを解析することができる。
【0108】
このような方式で読み出したバイナリデータは、必要以上に多く読み出して返却されることがなく、読み出したデータが足りず2回目の読み出しを行うこともなく、解析の効率及び正確率が保障される。
【0109】
ある実施例では、メタデータ容器に埋め込まれた典型的な容器タイプを事前ラベル付けして、容器が直接にバイナリデータをパッケージするものであるか、又はさらに容器をパッケージしたものであるかを示すために用いられる。例えば、図2に示すmvhd boxと、audio track box及びvideo track boxなどに対して、さらに容器をパッケージしたとラベル付けて、図2に示すstts boxとstsd boxなどに対して、直接にバイナリデータをパッケージしたとラベル付けする。
【0110】
直接にバイナリデータをパッケージしたとラベル付けした容器タイプに対して、容器タイプにそれぞれ対応する解析器を設置する。解析器は、バイナリデータに基づいて、示すメディア情報を解析するために用いられる。解析したサブ容器の容器タイプを事前ラベル付けされた容器タイプと比べ、以下の2つの場合がある。
【0111】
場合1)比較によって、前記サブ容器の容器タイプが事前ラベル付けされたと確定し、かつ直接にバイナリデータをパッケージするために用いられると事前ラベル付けされた場合、前記サブ容器の容器タイプに対応する解析器を呼び出し、前記解析器によって前記サブ容器における容器データを解析して、前記容器データが示すメディア情報を得る。
【0112】
場合2)比較によって、前記サブ容器の容器タイプが事前ラベル付けされたと確定し、且つ継続に容器をパッケージするために用いられると事前ラベル付けされた場合、前記メディアファイルにおける容器ヘッダの規定長さに基づき、前記サブ容器に対応するバイナリデータを再帰的に解析して、前記サブ容器にパッケージされた容器の容器タイプが事前ラベル付けされて、直接にバイナリデータをパッケージするために用いられると事前ラベル付けされるまで解析したら、サブ容器にパッケージされた容器の容器タイプに対応する解析器を呼び出して、1バイト毎にバイナリデータを解析する。解析したバイナリデータの長さを前記サブ容器にパッケージされた容器の容器データの長さに対応させることで、前記サブ容器にパッケージされた容器の容器データが示すメディア情報を得る。
【0113】
ある実施例では、メタデータ容器の解析過程におけるメディア情報の記録方式について説明する。メタデータ容器のバイナリデータにおける容器ヘッダの規定長さに対応するバイナリデータを順次に解析して、前記メタデータ容器におけるサブ容器の容器タイプを得たときに、サブ容器と帰属する容器とのネスト関係、及びサブ容器とパッケージされた容器のネスト関係に基づいて対象を作成し、サブ容器の容器タイプが直接にバイナリデータをパッケージするために用いられると事前ラベル付けされた場合、前記サブ容器に対応して作成した対象にはメディア情報を含む配列が記憶され、記憶されたメディア情報は前記サブ容器の容器データによって示される。
【0114】
例えば、図2では、解析したサブ容器のタイプがstts boxであるとき、stts boxは直接にバイナリデータをパッケージすると事前ラベル付けされたため、stts boxに対応して作成した対象にはメディアデータを含む配列が記憶される。なお、メディアデータはstts boxの容器データが示す時間長情報である。
【0115】
ある実施例では、メタデータ容器の解析過程におけるサブ容器の間のネスト関係の方式について説明する。メタデータ容器のバイナリデータにおける容器ヘッダの規定長さに対応するバイナリデータを順次に解析して、前記メタデータ容器におけるサブ容器の容器タイプを得たときに、容器の容器タイプが直接にバイナリデータをパッケージすると事前ラベル付けされた場合、呼び出された前記解析器に解析したサブ容器を記憶する。記憶したサブ容器の実例をサブ容器の属性に設定する。前記サブ容器の属性は、サブ容器と帰属する容器とのネスト関係を記述するための、前記サブ容器が帰属する容器を含める。
【0116】
例えば、図2では、解析したサブ容器のタイプがstsd boxであるとき、stsd boxは直接にバイナリデータをパッケージすると事前ラベル付けされたため、stsd boxに対応する解析器にstsd boxを記憶し、stsd boxの実例をstbl boxのサブ容器の属性に設定する。このように、最終的にstsd boxのサブ容器属性には、stsd box、stts box、stsc boxなどの複数のstbl boxに埋め込まれたサブ容器が記憶される。
【0117】
ある実施例では、比較によって、前記サブ容器の容器タイプが事前ラベル付けされていなく、又は、直接にバイナリデータをパッケージすると事前ラベル付けされたが対応するタイプの解析器を呼び出さなかったと確定した場合、サブ容器に対応するバイナリデータの解析を無視し、前記サブ容器の長さに基づいて、前記バイナリデータにおいて次のサブ容器に対応する部分へジャンプして解析を継続する。
【0118】
実際の応用では、メディアファイルにカスタム容器タイプが現れ、ジャンプ方式を用いてはメタデータ容器の全体的な解析の進捗に影響を与えることはない。また、解析器を設置する方式で、メタデータ容器の容器タイプが変動した場合、対応するタイプの解析器を追加、削除及び変更することによって、最新のメタデータ容器に対する交換解析を速やかに実現でき、バージョンアップが柔軟且つ迅速の特徴を有する。
【0119】
前記メディア情報の識別に関する説明に基づいて、続いて、プレーヤが識別したメディア情報によって第1キーフレームと第2キーフレームとの間のメディアデータを取得することについて説明する。プレーヤが、第1キーフレームと第2キーフレームを定位した後に、ある実施例では、以下のような方式でメディアファイルから第1キーフレームと第2キーフレームとの間のメディアデータを抽出することができる。メディアファイルにおける、第1キーフレームと第2キーフレームとの間のビデオフレームのオフセット量とサイズ、及びメディアファイルにおける、ビデオフレームと合わせたオーディオフレームのオフセット量とサイズに基づいて、対象区間のオフセット量とサイズを確定する。そのうち、対象区間は、前記ビデオフレームとオーディオフレームを含む。確定したオフセット量とサイズに基づいて、前記ビデオフレームとオーディオフレームを含む対象区間(最少オフセットと最大サイズからなる区間)のオフセット量とサイズを確定する。対象区間のオフセット量とサイズに基づいて、メディアファイルのメディアデータ容器から対応するメディアデータを抽出する。
【0120】
ここで、本開示の実施例に係るオーディオフレームとビデオフレームの整列方式について説明する。ビデオフレームを基準とし、メディアデータの開始時刻と時間長に基づいて、ビデオフレームにおいて時刻が同期するオーディオフレームを定位して、メディアデータにおいて最初のオーディオフレームの復号開始時刻がビデオフレームの復号開始時刻に遅れなく、最後のオーディオフレームの復号時刻がビデオフレームの復号終了時刻より早くないことを保障する。このように、メディアファイル(例えば、ビデオ)を再生する際に、画面が表示されるが音が出ないことを回避でき、過度に取り戻したオーディオフレームは、後続の対応するビデオフレームを再生する際の復号に使用可能である。
【0121】
対象区間のオフセット量とサイズを確定することについて説明する。2つのキーフレームのうち、第1キーフレームと第2キーフレームとの間のビデオフレームの、メディアファイルにおけるオフセット量とサイズに基づいて、ビデオフレームがメタデータ容器における位置を定位する。ビデオフレームと合わせたオーディオフレームの、メディアファイルにおけるオフセット量とサイズに基づいて、オーディオフレームがメタデータ容器における位置を定位して、位置の上限と下限からなる区間を対象区間とする。即ち、最小オフセットと最大サイズからなる区間である。そのうち、位置の上限に対応するオフセット量とサイズは、対象区間の上限に対応するオフセット量とサイズであり、位置の下限に対応するオフセット量とサイズは、対象区間の下限に対応するオフセット量とサイズである。実際の応用では、対象区間は目標解像度のメディアファイルのメディアデータ容器に記憶されたビデオフレームとオーディオフレームの最小区間である。例えば、第1キーフレームと第2キーフレームとの間のビデオフレームが、目標解像度のメディアファイルにおける位置のオフセットに対応する空間は[a,b](アドレスが昇順)であり、オーディオフレームが目標解像度のメディアファイルにおける位置のオフセットに対応する空間は[c,d](アドレスが昇順)である。そこで、位置の上限と下限で構成される空間は、即ち、[min(a,c),max(b,d)]である。このように、プレーヤが、対象区間のオフセット量とサイズを携帯するネットワーク要求をサーバに送信して、対象区間のメディアデータを要求する。サーバは、対象区間のオフセット量とサイズに基づいて、メディアファイルにおけるメディアデータを抽出した後に、一括で対象区間のメディアデータを返信する。2回目の取得が必要なく、プレーヤの請求回数を減らし、処理の効率を向上させる。
【0122】
ステップ203:メディアソース拡張インターフェースを介して、取得したメディアデータをプレーヤが埋め込まれたウェブページのメディア要素に送信してプレロードする。
【0123】
ある実施例では、再生するメディアファイルが、ストリーミング再生をサポートするストリーミングメディアフォーマットのファイルである場合、以下のような方式で、取得したメディアデータをプレーヤが埋め込まれたウェブページのメディア要素に送信してプレロードすることを実現できる。
【0124】
取得したメディアデータをメディアソース拡張(MSE,Media Source Extensions)インターフェースにおけるメディアソース(Media Source)対象に追加する。MSEを呼び出してメディアソース対象に対応する仮想アドレスを作成する。メディア要素(ビデオ要素、オーディオ要素)に仮想アドレスを伝達する。仮想アドレスは、メディア要素がメディアソース対象をデータソースとしてプレロードするために用いられる。
【0125】
ある実施例では、プレーヤが再生するメディアファイルは非ストリーミングメディアフォーマット、例えば、MP4/ MKV / WMV/ ASFなどのパッケージフォーマットを使用する。プレーヤは、取得した固定時間長を満たすメディアデータをセグメントメディアファイルに構築する必要がある。そして、セグメントメディアファイルをMSEにおけるメディアソース対象に追加し、MSEを呼び出してメディアソース対象に対応する仮想アドレスを作成する。メディア要素(ビデオ要素、オーディオ要素)に仮想アドレスを伝達する。仮想アドレスは、メディア要素がメディアソース対象をデータソースとしてプレロードするために用いられる。
【0126】
ここで、プレーヤが取得した、プレロードしたメディアデータが固定時間長を満たせるメディアデータに基づいて、セグメントメディアファイルを構築することについて説明する。ある実施例では、プレーヤは以下のような方式でセグメントメディアファイルを構築することができる。プレーヤは、識別したメディア情報に基づいて、セグメントメディアファイルレベルのメタデータを計算し、計算したメタデータ及び取得したメディアデータをセグメントメディアファイルのパッケージフォーマットに基づいてパッディングして、対応するセグメントメディアファイルを得る。
【0127】
本開示のある実施例では、図8を参照する。図8は、本開示の例に係るセグメントメディアファイルをパッケージする選択可能な流れの模式図であり、図8に示すステップを結び付けて説明する。
【0128】
ステップ301、セグメントメディアファイルのタイプと互換性を示すデータを、セグメントメディアファイルのファイルタイプ容器にパッディングする。
【0129】
例えば、図4のようなパッケージ構造のFMP4ファイルをパッケージして形成することを例として、FMP4ファイルのファイルタイプ容器、即ち、ftyp boxのヘッダに容器のタイプと長さ(ftyp boxの全体の長さを示す)をパッディングして、ftyp boxのデータ部分にファイルタイプがFMP4である及び交換プロトコルを示すデータ(バイナリデータ)をパッディングする。
【0130】
ステップ302、セグメントメディアファイルのファイルレベルを示すメタデータを、セグメントメディアファイルのメタデータ容器にパッディングする。
【0131】
ある実施例では、セグメントメディアファイルのパッケージ構造へパッディング待ちのメディアデータ、セグメントメディアファイルにおけるメタデータ容器のネスト構造に基づいて、ネスト構造をパッディングするために必要のメディアデータを記述するメタデータを計算する。
【0132】
また、図4を例として、FMP4ファイルのファイルレベルを示すメタデータを計算して、FMP4のメタデータ容器(即ち、moov box)にパッディングする。moov boxには、mvhdと、trackと、ビデオ拡張(mvex、movie extend)の3つの容器が埋め込まれている。
【0133】
そのうち、mvhd容器にパッケージされたメタデータは、セグメントメディアファイルの再生に関するメディア情報を示すために用いられて、位置、時間長、作成時刻及び修正時刻などを含む。track容器に埋め込まれたサブ容器は、メディアデータにおいて対応するトラックの引用と記述を示す。例えば、track容器には、トラックの特徴と全体情報(例えば、時間長、幅と長さ)を記述する容器(tkhd boxとする)と、トラックのメディア情報(例えば、メディアタイプとサンプル情報)の容器(mdia boxとする)が埋め込まれている。
【0134】
ステップ303、抽出したメディアデータ、及びメディアデータを記述するメタデータを、セグメントメディアファイルのセグメント容器におけるメディアデータ容器、及びセグメントレベルのメタデータ容器に対応してパッディングする。
【0135】
ある実施例では、セグメントメディアファイルには、1つ又は複数のセグメント(fragment)をパッケージ可能である。パッディング待ちのメディアデータに対して、セグメントメディアファイルの1つ又は複数のメディアデータ容器(即ち、mdat box)にパッディング可能であり、各セグメントにセグメントレベルのメタデータ容器(moof boxとする)がパッケージされており、中にパッディングされたメタデータはセグメントにパッディングされたメディアデータを記述するために用いられ、セグメントを単独で復号できるようにする。
【0136】
図4を結び付けて、パッディング待ちのメディアデータをFMP4ファイルのパッケージ構造の2つのセグメントにパッディングすることを例として、各セグメントメディアファイルにパッディングする。対応するセグメントのセグメントレベルのメタデータ容器(即ち、moof box)にパッディングする必要のメタデータを計算して、moof boxに埋め込まれたサブ容器に対応してパッディングする。そのうち、moof boxのヘッダではmoof boxと呼ばれ、その中にパッディングしたバイナリデータは、容器のタイプが「moof box」であり、及びmoof boxの長さを示すために用いられる。
【0137】
ステップ301からステップ303までに、データを対応する容器にパッディングする実施例では、パッディング操作を実行する際、クラスの書き込み操作機能を呼び出して前記サブ容器のメモリバッファでバイナリデータの書き込み及び統合を完了して、さらに前記クラスの実例を返信する。返信した実例は、前記サブ容器とネスト関係を有するサブ容器との統合に用いられる。
【0138】
パッディングデータの一例として、パッケージ機能を実現するためのクラスMP4を作成して、セグメントメディアファイルにおける各サブ容器をクラスストリームにパッケージする静的方法である。バイナリデータの操作機能を実現するためのクラスストリームを作成して、各クラスストリームにはパッディング待ちのバイナリデータを記憶するためにメモリバッファが提供される。ストリームに係る静的方法によって、パッディング待ちのマルチバイトデジマルデータをバイナリデータに変換する。クラスストリームの実例に係る書き込み操作機能によって、メモリバッファにおいてサブ容器へパッディング待ちのバイナリデータの合併及びパッディングを完了する。ストリームに係る静的方法の新たなストリームを返信する実例によれば、現在のサブ容器と、その他のネスト関係を有するサブ容器との合併を実現することができる。
【0139】
図9を参照する。図9は、本開示の実施例に係るプレーヤが、ウェブページのメディアソース拡張インターフェースを介して、セグメントメディアファイルをメディア要素に送信してプレロードする選択可能な模式図である。プレーヤが、ウェブページにおいて再生ウィンドウ(プレーヤに対応する再生ウィンドウ)によってメディアファイルの再生イベントを受信したとき、MSEがメディアソース方法を実行してメディアソース(Media Source)対象を作成する。メディアソース拡張インターフェースにパッケージされた追加ソースバッファ(add Source Buffer)方法でメディアソース対象のバッファを作成し、即ち、ソースバッファ(Source Buffer)対象である。各ソースバッファ対象はウェブページにおける1つの再生ウィンドウに対応するために用いられ、ウィンドウにおける再生するセグメントメディアファイルを受信するために用いられる。メディアファイルの再生中において、プレーヤにおける解析器(Parser)は、新しく取得したメディアファイルを解析することによって、絶えずに新たなセグメントメディアファイルを構築し続ける。ソースバッファ対象の追加ソースバッファ方法を実行することで、セグメントメディアファイルを同一メディアソース対象のソースバッファ対象に追加して、メディアファイルにおけるメディアデータのプレロードを実現する。
【0140】
プレーヤが構築したセグメントメディアファイルを、メディアソース拡張インターフェースにおけるメディアソース対象に追加した後、メディアソース拡張インターフェースを呼び出してメディアソース対象に対応する仮想アドレスを作成する。仮想アドレスは、メディア要素がメディアソース対象をデータソースとしてロード及び再生するために用いられる。例えば、プレーヤが、メディアソース拡張インターフェースにパッケージされた目標URLを作成する(create Object URL)方法を実行して、メディアソース対象に対応する仮想アドレス、即ち、仮想ユニフォームリソースロケータ(URL、Uniform Resource Locator)を作成して、中にはBlobタイプのセグメントメディアファイルがパッケージされている。なお、プレーヤが、メディアソース対象を仮想URLのソース(src)属性と設定して、即ち、仮想URLをウェブページにおけるメディア要素と、例えば、video(ビデオ)/audio(オーディオ)要素とバンディングする。この過程は、メディアソース対象をウェブページにおけるメディア要素と関連を付けると呼ばれる。
【0141】
図10は、本開示の実施例に係るプレーヤが、メディアソース拡張インターフェースを介して、セグメントメディアファイルをメディア要素に送信するフローチャート模式図である。図10を参照して、プレーヤは、メディアファイルのリアルアドレス(図では、http://www.toutiao.com/a/b.mp4)に基づいて、固定時間長を満たすメディアデータを取得してから、取得したメディアデータに基づいてセグメントメディアファイルを構築する。即ち、セグメントMP4ファイルフォーマットのメディアデータに変換する。そして、セグメントメディアファイルをMSEのメディアソース対象(例えば、クラスファイル対象(Blob)の方式で実現)に追加する。MSEがメディアソース対象に対応する仮想URLを作成して、ビデオ要素に前記仮想URLを伝達して、ビデオ要素が対応するメディアソース対象を取得するようにして、上述の固定時間長を満たすメディアデータのプレロードを実現する。
【0142】
ある実施例では、プレロードしたメディアデータの表示に対して、ウェブページにおけるメディアデータに対応する再生ウィンドウにおいて、差別化表示を用いてプレロードしたメディアデータに対応するセグメント、及びプレロードしていないメディアデータに対応するセグメントを表示することができる。例えば、異なるカラーを用いてプレロードしたメディアデータに対応するセグメント、及びプレロードしていないメディアデータに対応するセグメントを表示する。図11は、本開示の実施例に係るプレロードしたメディアデータに対応するセグメント、及びプレロードしていないメディアデータに対応するセグメントを差別化表示する模式図である。図11では、太さが異なるセグメント指示バーを用いて、再生したメディアデータ、プレロードしたメディアデータ、及びプレロードしていないメディアデータを区別した。図11における符号21が示すのは、現在の再生ウィンドウにおいて再生したメディアデータのセグメントであり、符号22が示すのは、現在の再生ウィンドウにおいてプレロードしたメディアデータであり、符号23が示すのは、現在の再生ウィンドウにおいてプレロードしていないメディアデータである。そのうち、プレロードしたメディアデータに対応する時間長は、固定時間長であるので、即ち、現在の再生ウィンドウにおいて、符号22が示すセグメントの長さは常に一定である。このように、ユーザがメディアファイルを閲覧しようとする場合、手動で再生箇所を切替えしてメディアファイルを閲覧するとき、プレーヤが現在の再生箇所に基づいて再生していない全てのメディアデータをプレロードせずに、固定的に一部のメディアデータをプレロードするので、ユーザの視聴体験を保障すると共に、ユーザの流量消費を低減する。
【0143】
続いて、プレーヤがウェブページに埋め込まれ、プレーヤがウェブページのHTML5メディア要素を用いてMP4ファイルを再生することを例として、本開示の実施例に係るメディア再生のローディング制御方法について説明する。図12に本開示の実施例に係るメディア再生のローディング制御方法のある選択可能なフローチャート模式図が示されている。図12を参照して、本開示の実施例に係るメディア再生のローディング制御方法は、以下のステップを備える。
【0144】
ステップ401:プレーヤが設定したオフセット量とサイズに基づいて、サーバに対して固定サイズのMP4ファイルにおけるデータを要求する。
【0145】
プレーヤは、設定したオフセット量とサイズを携帯するデータ要求をサーバに送信することで、MP4ファイルにおけるゼロバイトから、且つ設定サイズに合致するバイナリデータを取得する。ある実施例では、メディアファイルが用いられた容器パッケージ構造には、順次にパッケージされたファイルタイプ容器と、メタデータ容器及びメディアデータ容器を備える。MP4ファイルに対して、パッケージ構造は、順次にパッケージされたfytp boxと、moov box及びmdat boxを備えることが好ましい。設定サイズは、既存MP4ファイルのfytp boxとmoov boxのサイズによって統計して得たものであってもよい。一次でサーバから完全なmoov boxバイナリデータを要求できることを確保するために、設定サイズが設定比率(例えば、全部)のMP4ファイルのfytp boxとmoov boxの合計をカバーできるようにする。
【0146】
ステップ402:プレーヤが、サーバから返信されたデータを受信して、サーバから返信されたデータからMP4ファイルのメディア情報を識別する。
【0147】
MP4ファイルのメディア情報は、MP4ファイルにおけるビデオ/オーディオフレームのオフセット、サイズ、復号時間等の情報を含む。
【0148】
ある実施例では、プレーヤが、以下のような方式でMP4ファイルのメディア情報の識別を実現することができる。サーバから返信されたデータから、fytp boxのバイナリデータを識別して、残りのバイナリデータから容器のタイプとサイズを読み出す。読み出した容器のタイプがmoov boxであって、残りのバイナリデータのサイズがmoov boxサイズ以上である場合、残りのバイナリデータからメディア情報を解析する。また、サーバから返信されたバイナリデータに関して、最初の1つのバイナリデータは必ずfytp boxに対応するものであり、fytp boxのパッケージ規則に基づいて、fytp boxのサイズ(即ち、長さ)及び完全なMP4ファイルのサイズを読み出すことができる。例えば、fytp boxのサイズがa(単位はバイト)であれば、a+1から後続の容器のヘッダ情報を読み出して、容器のタイプとサイズを取得する。もしmoov boxであって、(設定サイズ- fytp boxのサイズ)moov boxのサイズより大きければ、moov boxの完全なバイナリデータを取り戻したことを示し、パッケージ構造に基づいてバイナリデータを解析して、メディア情報を還元することができる。
【0149】
ある実施例では、サーバから返信されたバイナリデータが完全なmoovデータを含めない場合、取得したバイナリデータから容器のサイズを読み出して、MP4ファイルにおけるmoov boxのオフセット量とサイズを確定する。確定したオフセット量とサイズに基づいて、残りのバイナリデータから読み出した容器のタイプがmoov boxであって、残りのバイナリデータのサイズがmoov boxのサイズ以上である場合、サーバから、MP4ファイルにおける、moov boxのMP4ファイルにおけるオフセットで始めて、moov boxのMP4ファイルにおけるサイズに合致するmoovデータを取得する。残りのバイナリデータから読み出した容器のタイプがmoov boxであって、残りのバイナリデータのサイズがmoov boxのサイズ以下である場合、moov boxのサイズと残りのバイナリデータのサイズとの差を計算して、2回目の要求の新たなサイズとし、初回要求のオフセット量とサイズの合計を新たオフセットとして、サーバに対して2回目のバイナリデータの要求を行う。
【0150】
実際の応用では、MP4ファイルのパッケージ構造が、順次にパッケージされたfytp boxと、mdat boxと、moov boxである場合がある。残りのバイナリデータから読み出さした容器のタイプがmdat boxである場合、mdat boxのサイズとmoov boxのサイズとの合計を計算して、2回目の要求の新たなオフセットとして、設定したサイズでサーバに対して2回目のバイナリデータの要求を行う。
【0151】
ステップ403:プレーヤがウェブページを介してMP4ファイルを再生する過程において、メディア情報に基づいてプレロードしたメディアデータに対応する時間長を検出する。
【0152】
なお、メディアデータは、ビデオフレーム及びオーディオフレームを含める。
【0153】
ある実施例では、以下のような方式でプレロードしたメディアデータに対応する時間長を取得することができる。
【0154】
メディアファイルのリアルタイムの再生箇所に対応する時刻、及びロードしたメディアデータに対応する再生終了時刻を取得して、再生終了時刻と再生箇所に対応する時刻との差を計算して、プレロードしたメディアデータに対応する時間長とする。
【0155】
ステップ404:プレロードしたメディアデータに対応する時間長が固定時間長より小さい場合、メディア情報に基づいて、サーバに対してプレロードしたメディアデータが固定時間長を満たせるようなメディアデータを要求する。
【0156】
ある実施例では、固定時間長は、サービス側(異なるビデオプラットフォーム)によって設定される属性を有する。サービス側が、ユーザ体験を重要視すれば、比較的に長い固定時間長を設定することができる。サービス側が、ユーザの流量消費を低減することを重要視すれば、比較的に短い固定時間長を設定することができる。
【0157】
ある実施例では、固定時間長のメディアデータは、キーフレームを単位として分割している。以下のような方式で、プレロードしたメディアデータが固定時間長を満たせるメディアデータを取得することができる。
【0158】
識別して得られたメディア情報に基づいて、MP4ファイルにおいて第1キーフレームを定位する。第1キーフレームの復号時刻は、プレロードしたメディアデータの再生終了時刻より遅れない。MP4ファイルにおいて第2キーフレームを定位する。第2キーフレームの復号時刻と、プレロードしたメディアデータの再生開始時刻との差を、固定時間長とする。MP4ファイルから、第1キーフレームと第2キーフレームとの間のメディアデータを抽出する。
【0159】
ステップ405:取得したメディアデータに基づいて、セグメントメディアファイルを構築する。
【0160】
ある実施例では、以下のような方式でセグメントメディアファイルを構築することができる。
【0161】
識別して得られたメディア情報に基づいて、取得したメディアデータを記述するメタデータを確定する。確定したメタデータ及び取得したメディアデータをセグメントメディアファイルの容器構造によってパッケージして、対応するセグメントメディアファイルを得る。
【0162】
ステップ406:構築したセグメントメディアファイルをMSEにおけるメディアソース対象に追加する。
【0163】
ステップ407:ウェブページのメディア要素に仮想アドレスを伝達する。
【0164】
仮想アドレスは、ビデオ要素がメディアソース対象をメディアソースとしてプレロードするために用いられる。
【0165】
ステップ408:ウェブページの再生ウィンドウにおいて、プレロードしたメディアデータに対応するセグメント、及びプレロードしていないメディアデータに対応するセグメントを差別化表示する。
【0166】
本開示の上述の実施例を応用すれば、以下の効果を有する。
【0167】
1、プレーヤがプレロードしたメディアデータは常に固定時間長であり、メディアデータのローディング制御を実現して、流量の大量消費及びリンクの不必要な占用を回避することができる。
【0168】
2、プレーヤが、非ストリームメディアフォーマットのメディアファイルにおけるメディアデータを、セグメントメディアファイルに変換すると共に、ウェブページのメディアソース拡張インターフェースを介して、ウェブページのメディア要素に送信して復号再生することができる。プレーヤが埋め込まれたウェブページを介して、非ストリームメディアフォーマットのメディアファイルを再生することを実現して、非ストリームメディアパッケージフォーマットのファイルを完全的にダウンロードした後に独立に再生できる制限を克服した。
【0169】
3、ウェブページのビデオ要素とオーディオ要素が仮想アドレスに基づくことで、MP4ファイルのリアルアドレスの保護を実現した。
【0170】
4、プレロードしたメディアデータに対応するセグメント、及びプレロードしていないメディアデータに対応するセグメントを差別化表示することで、MP4ファイルの再生過程において異なる段階のメディアデータ表示の提示を実現した。
【0171】
続いて、メディア再生のローディング制御装置について説明する。実際に実施する際、メディア再生のローディング制御装置は、ソフトウェアによる実施方式を用いることができる。メディア再生のローディング制御装置のソフトウェアの実施例として、図13は、本開示に係るメディア再生のローディング制御装置の構成を示す模式図である。図13を参照して、メディア再生のローディング制御装置900は、
ウェブページに埋め込まれたプレーヤの再生過程において、前記プレーヤがプレロードしたメディアデータに対応する時間長を検出するように配置された検出部91と、
前記プレロードしたメディアデータに対応する時間長が固定時間長より小さい場合、サーバからプレロードしたメディアデータが前記固定時間長を満たすようなメディアデータを取得するように配置された取得部92と、
メディアソース拡張インターフェースを介して、取得した前記メディアデータを前記ウェブページのメディア要素に送信してプレロードするように配置された送信部93と、を備える装置である。
【0172】
ある実施例では、メディア再生のローディング制御装置は、
前記ウェブページのネットワークパラメータに適応した時間長を前記固定時間長と確定するように配置された第1確定部をさらに備えてもよい。
【0173】
ある実施例では、前記第1確定部は、さらに、メディアデータの伝送のダウンリンクネットワークの帯域幅とプレロードしたメディアデータの量との正の相関関係に基づいて、前記プレーヤがプレロード可能なメディアデータの量を確定するように配置され、
前記プレロード可能なメディアデータの量の再生時間長を前記固定時間長と確定する。
【0174】
ある実施例では、
前記ウェブページの特徴パラメータに適応した時間長を前記固定時間長と確定するように配置された第2確定部をさらに備える。
【0175】
ある実施例では、前記第2確定部は、さらに前記ウェブページにおける再生ウィンドウの数を取得するように配置され、
再生ウィンドウの数と前記固定時間長との負の相関関係に基づいて、前記固定時間長を確定する。
【0176】
ある実施例では、前記取得部は、さらに、メディアファイルにおいて第1キーフレームを定位するように配置され、前記第1キーフレームの復号時刻は、前記プレロードしたメディアデータの再生終了時刻より遅れなく、
前記メディアファイルにおいて第2キーフレームを定位するように配置され、前記第2キーフレームの復号時刻とプレロードしたメディアデータの再生開始時刻との差は、前記固定時間長であり、
前記メディアファイルから、前記第1キーフレームと前記第2キーフレームとの間のメディアデータを抽出する。
【0177】
ある実施例では、前記取得部は、さらに、前記第1キーフレームと前記第2キーフレームとの間のビデオフレームが、メディアファイルにおけるオフセット量とサイズ、及び前記ビデオフレームに合わせたオーディオフレームが、前記メディアファイルにおけるオフセット量とサイズに基づいて、対象区間のオフセット量とサイズを確定するように配置され、
前記対象区間は、前記ビデオフレームと前記オーディオフレームを含め、
前記対象区間のオフセット量とサイズに基づいて、前記メディアファイルのメディアデータ容器から対応するメディアデータを抽出する。
【0178】
ある実施例では、前記送信部は、さらに前記メディアデータをメディアソース拡張インターフェース内のメディアソース対象に追加するように配置され、
前記メディアソース対象の仮想アドレスを作成し、
前記メディア要素に仮想アドレスを伝達して、前記仮想アドレスは、前記メディア要素がメディアソース対象をデータソースとして再生するために用いられる。
【0179】
ある実施例では、前記送信部は、さらに、再生するメディアファイルがMPEG-4ファイルフォーマットを用いる場合に、前記固定時間長を満たすメディアデータに基づいて、セグメントメディアファイルを構築するように配置され、
メディアソース拡張インターフェースを介して、前記セグメントメディアファイルを前記メディア要素に送信する。
【0180】
ある実施例では、
前記ウェブページの再生ウィンドウにおいて、プレロードしたメディアデータに対応するセグメント、及びプレロードしていないメディアデータに対応するセグメントを差別化表示するように配置された表示部を、さらに備える。
【0181】
本開示の実施例は、読み取り可能な記憶媒体をさらに提供しており、記憶媒体は、モバイル記憶装置、ランダムアクセスメモリ(RAM,Random Access Memory)、読み出し専用メモリ(ROM,Read-Only Memory)、磁気ディスク或いは光ディスクなど、様々なプログラムコードを記憶可能な媒体を含めてもよい。前記読み取り可能な記憶媒体には、実行可能な指令が記憶され、
前記実行可能な指令は、プロセッサによって実行される際に、前記メディア再生のローディング制御方法を実現するために用いられる。
【0182】
以上のように、本開示の具体的な実施の形態に過ぎず、本開示の技術的範囲はこれに限られない。当業者が、本開示の技術的範囲において、容易に想到できる変換又は入れ替えは、いずれも本開示の技術的範囲に含まれる。そこで、本開示の技術的範囲は、請求の範囲に記述された範囲を基準にするべきである。
【符号の説明】
【0183】
20 ネットワーク
30 サーバ
600 メディア再生のローディング制御装置
601 プロセッサ
602 メモリ
603 ユーザインターフェース
604 ネットワークインターフェース
6021 実行可能な指令
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13