JP2010028455A - データ構造、再生装置および方法、並びにプログラム - Google Patents

Abstract

【課題】BD-ROM規格によるPlayListに従ってストリーミングしている最中の再生停止という事態を回避するようにする。
【解決手段】PI（Play Item）#(k+1)(kは0乃至6の整数値)において、2Mbps（Angle-1）の「1000k.clpi」は、2Mbpsでエンコードされた「1000k.m2ts」を参照する。1Mbps（Angle-2）の「2000k.clpi」は、1Mbpsでエンコードされた「2000k.m2ts」を参照する。0.5Mbps（Angle-3）の「3000k.clpi」は、0.5Mbpsでエンコードされた「3000k.m2ts」を参照する。当初、2Mbpsでエンコードされた「1000k.m2ts」がダウンロードされる。その後、PI#4の前にネットワークの速度が低下したと判定された場合、ダウンロード対象が、ビットレートの低い「3000k.m2ts」に切り替えられる。本発明は、BD-ROM規格に準拠した再生装置に適用可能である。
【選択図】図６

Description

本発明は、データ構造、再生装置および方法、並びにプログラムに関し、特に、BD-ROM(Blu-ray Disc-Read Only Memory)規格によるPlayListに従ってストリーミングしている最中の再生停止という事態を回避できるようになった、データ構造、再生装置および方法、並びにプログラムに関する。

近年、記録再生装置から取り外し可能なディスク型記録媒体の規格として、Blu-ray Disc（ブルーレイディスク）の規格が提案されている。

Blu-ray Discの派生規格として、映画や音楽などのデータが予め記録された、再生専用の記録媒体を開発する動きが進んでいる。映画や音楽などのデータを記録するための再生専用の光ディスクとしては、既にDVD(Digital Versatile Disc)が広く普及している。これに対して、Blu-ray Discの規格に基づいた再生専用の光ディスクは、Blu-ray Discの大容量および高速な転送速度などを活かし、ハイビジョン映像を高画質なままで２時間以上収録できる。かかる点が、既存のDVDとは大きく異なり、優位な点である。

このような、Blu-ray Discにおける再生専用の記録媒体の規格は、BD-ROM(Blu-ray Disc-Read Only Memory)規格と一般的に称されている。

BD-ROM規格に規定されているVirtual Packageを用いることで、次のようなClip AV stream fileの再生手法が実現できる。即ち、ディスクに関連づけられた別のClip AV stream fileが、ネットワーク経由でダウンロードされて、ローカルストレージに記録される。ディスク上に記録されているClip AV stream fileとローカルストレージに記録されているClip AV stream fileとが関連付けられたPlayList等が、Virtual Packageとして作られる。このVirtual PackageにおけるPlayListに従って、各Clip AV stream fileが再生される（特許文献１参照）。このようなVirtual Packageの技術を用いることで、ダウンロードしながら再生すること、即ちいわゆるストリーミングも可能となる。以下、このような再生手法を、従来のストリーミング手法と称する。
特開２００５−１５９５８９号公報

しかしながら、従来のストリーミング手法では、Clip AV stream fileをダウンロードしながら再生しようとすると、その最中に、ネットワークの帯域が変動する場合がある。このような場合、再生対象のClip AV stream fileが、ダウンロード対象のClip AV streamに追い付いてしまうと、再生が停止するという事態が生じてしまう。

本発明は、このような状況に鑑みてなされたものであり、BD-ROM規格によるPlayListに従ってストリーミングしている最中の再生停止という事態を回避できるようにするものである。

本発明の一側面のデータ構造は、BD-ROM(Blu-ray Disc-Read Only Memory)規格で規定されているマルチアングルタイプのPlayItemであって、複数のアングルのClip AV stream fileの代わりに、同一の素材が複数のビットレートでそれぞれエンコードされた結果得られる、複数のビットレートのClip AV stream fileであって、ネットワークを介してダウンロードされる対象の複数のビットレートのClip AV stream fileを参照している前記PlayItemを１以上含むPlayListのデータ構造である。

本発明の一側面のデータ構造では、PlayListには、次のようなPlayItemが１以上含まれている。即ち、BD-ROM(Blu-ray Disc-Read Only Memory)規格で規定されているマルチアングルタイプのPlayItemにおいては、複数のアングルのClip AV stream fileの代わりに、同一の素材が複数のビットレートでそれぞれエンコードされた結果得られる、ネットワークを介してダウンロードされる対象の複数のビットレートのClip AV stream fileが参照されている。

本発明の一側面の再生装置は、BD-ROM(Blu-ray Disc-Read Only Memory)規格で規定されているマルチアングルタイプのPlayItemであって、複数のアングルのClip AV stream fileの代わりに、同一の素材が複数のビットレートでそれぞれエンコードされた結果得られる、ネットワークを介してダウンロードされる対象の複数のビットレートのClip AV stream fileを参照しているPlayItemを、１以上含むPlayListの再生を制御する再生制御手段を備え、前記再生制御手段は、前記ネットワークの速度を監視し、前記速度が一定以下になったと判定したとき、前記PlayItemのアングル切り替えの制御を利用して、ダウンロード対象のClip AV stream fileとして、これまでよりも低いビットレートのClip AV stream fileに切り替える。

前記再生制御手段の制御によりダウンロードされた前記Clip AV stream fileを蓄積する蓄積手段をさらに備え、前記再生制御手段は、前記格納手段における前記Clip AV stream fileの蓄積量に基づいて、前記ネットワークの速度が一定以下となったか否かを判定する。

前記再生制御手段は、前記速度が一定以下になったと判定したとき、次にダウンロードする対象のPlayItemについては、切り替え後のビットレートのClip AV stream fileに加えてさらに、切り替え前のビットレートのClip AV stream fileをダウンロードするように制御する。

前記再生制御手段は、さらに、ユーザによる前記アングル切り替えを禁止する。

本発明の一側面の再生方法およびプログラムは、上述した本発明の一側面の再生装置に対応する。

本発明の一側面の再生装置および方法並びにプログラムにおいては、BD-ROM(Blu-ray Disc-Read Only Memory)規格で規定されているマルチアングルタイプのPlayItemであって、複数のアングルのClip AV stream fileの代わりに、同一の素材が複数のビットレートでそれぞれエンコードされた結果得られる、複数のビットレートのClip AV stream fileであって、ネットワークを介してダウンロードされる対象の複数のビットレートのClip AV stream fileを参照しているPlayItemを、１以上含むPlayListの再生が次のようにして制御される。前記ネットワークの速度が監視され、前記速度が一定以下になったと判定されたとき、前記PlayItemのアングル切り替えの制御を利用して、ダウンロード対象のClip AV stream fileとして、これまでよりも低いビットレートのClip AV stream fileに切り替えられる。

本発明によれば、BD-ROM規格によるPlayListに従ってストリーミングしている最中の再生停止という事態が回避できるようになる。

はじめに、本発明の理解を容易なものとすべく、本発明の基になる従来の技術について幾つか説明する。

最初に、図１と図２を参照して、マルチアングルタイプのPlayListについて説明する。

図１の例では、マルチアングルタイプのPlayListは１個とされ、その中のPlayItemも１個とされている。また、マルチアングル再生の時間区間の中には、３つのアングルAngle#1，Angle#2，およびAngle#3があるとする。

PlayItemは、例えば、3つの情報を持つ。１つ目の情報は、マルチアングル再生で使用するAVストリームの参照先の情報（指示情報）である。例えば、図１の例の場合、Clip AV stream1，Clip AV stream2，Clip AV stream3を参照先とする指示情報が、１つ目の情報である。即ち、指示情報（ポインタ）とは、それらの参照先を指示する情報をいう。２つ目の情報は、マルチアングル再生の時間区間を表すところのイン点（IN_time）とアウト点（OUT_time）である。図１の例の場合、IN_time=T1とされ、OUT_time=T4とされている。３つ目の情報は、マルチアングル再生の時間区間の中で、アングル切り替え点を示すエントリーポイントの時刻であり、図１の例の場合、T2とT3である。

このように、マルチアングルタイプのPlayItemは、複数のClip AV streamと結びつけられている。よって、PlayItemが再生されているときに、ユーザ操作またはナビゲーション（後述するJava（登録商標）アプリケーション実行環境上で実行されるJava（登録商標）アプリケーション）により、再生対象のAVストリーム（図１の例では、Clip AV stream1，Clip AV stream2，Clip AV stream3のうちの何れか）の切り替えが可能になる。

それぞれのClip AV streamには、図２に示されるように、EP_mapを持つClip Information fileが対応づけられている。EP_mapは、Clip AV streamの中のアクセスポイントをタイムスタンプ(PTS: Presentation Time Stamp)で指定されたときに、Clip AV stream fileの中でストリームのデコードを開始すべきアドレス情報(SPN: Source packet Number)を見つけるために役立つ。

具体的には、ストリームデータA1，B1，およびC1の中のそれぞれのビデオストリームデータは、Sequence headerから始まるClosed GOPから開始する。それぞれの表示開始のタイムスタンプはT1で、同一であり、また、それぞれの表示期間も(T1-T2)で、同一である。なお、Closed GOPとは、１つの区間内（例えば、再生区間a1，b１，およびc1）で閉じているGOPであり、その区間内で完結するように符号化されている。勿論、各区間内で完結するように符号化されてさえいれば、すなわち、ある１つの区間（例えば、再生区間a1）とそれ以外の他の区間（例えば、再生区間b1）との間において、予測の関係がなければ、GOPでなくてもよい。

また、AVストリームデータA2，B2，およびC2についても、それぞれのビデオストリームデータは、Sequence headerから始まるClosed GOPから開始し、それぞれの表示開始のタイムスタンプはT2で同一あり、それぞれの表示期間も(T2-T3)で同一である。

さらに、AVストリームデータA3，B3，およびC3について、それぞれのビデオストリームデータは、Sequence headerから始まるClosed GOPから開始し、それぞれの表示開始のタイムスタンプはT3で同一であり、それぞれの表示期間も(T3-T4)で同一である。なお、AVストリームデータA1，B1，C1，A2，B2，C2，A3，B3，およびC3のすべてのビデオストリームデータにおいて、Closed GOPの最初に表示されるピクチャはＩピクチャである。

AVストリームデータA1，B1，およびC1の中のオーディオストリームデータは、それぞれ同一であり、また、AVストリームデータA2，B2，およびC2の中のオーディオストリームデータも、それぞれ同一であり、さらに、AVストリームデータA3，B3，およびC3の中のオーディオストリームデータも、それぞれ同一である。

AVストリームデータA1，B1，およびC1には、ビデオパケットとオーディオパケットが含まれるが、それぞれの先頭パケットは、ビデオパケットとされ、そのペイロードはSequence headerとGOPヘッダから始まるIピクチャで開始する。AVストリームデータA2，B2，およびC2のそれぞれの先頭パケットも、ビデオパケットであり、そのペイロードはSequence headerとGOPヘッダから始まるIピクチャで開始する。AVストリームデータA3，B3，およびC3のそれぞれの先頭パケットも、ビデオパケットであり、そのペイロードはSequence headerとGOPヘッダから始まるIピクチャで開始する。

なお、AVストリームデータA1，B1，およびC1のそれぞれは、PAT（Program Association Table），PMT（Program Map Table）から開始して、それに続く最初のエレメンタリストリームのパケットをビデオパケットとしても良い。

また、Clip Information fileは、Clipの中のエントリーポイントのタイムスタンプと、Clip AV stream file中でストリームのデコードを開始すべきソースパケット番号との対応関係を記述したマップであるEP_mapを有する。なお、ソースパケット番号とは、Clip AV stream fileの中のソースパケットの順番に１ずつインクリメントする番号であり、ファイルの先頭のソースパケット番号がゼロとされる。

AVストリームデータA1，A2，およびA3のそれぞれの先頭のパケット番号をx1，x2，およびx3とし、AVストリームデータB1，B2，およびB3のそれぞれの先頭のパケット番号をy1，y2，およびy3とし、さらに、AVストリームデータC1，C2，およびC3のそれぞれの先頭のパケット番号をz1，z2，およびz3とすると、各ClipInformation1，2，3のEP_mapは図２に示される内容になる。

Clip AV stream1のClip Information1のEP_mapにおいて、それぞれ番号x1，x2，およびx3によって指されるソースパケットのペイロードは、タイムスタンプがT1,T2,およびT3の表示開始時刻を持つＩピクチャから開始する。

Clip AV stream2のClip Information２のEP_mapにおいて、それぞれ番号y1，y2，およびy3によって指されるソースパケットのペイロードは、タイムスタンプがT1,T2,およびT3の表示開始時刻を持つＩピクチャから開始する。

Clip AV stream3のClip Information３のEP_mapにおいて、それぞれ番号z1，z2，およびz3によって指されるソースパケットのペイロードは、タイムスタンプがT1,T2,およびT3の表示開始時刻を持つＩピクチャから開始する。

具体的には例えば、T2からT3の間でAngle#2が再生されている最中に、Angle#3への再生切り替えがなされたとする。この場合、再生装置はClip Information3のEP_mapを参照して、T3の時刻でClip AV stream3のSPN=z3からの再生、即ち、AVストリームデータC3の先頭のパケット（番号z3のパケット）からの再生を開始する。

次に、BD-ROM format Part3 (AV)で規定されているVirtual Packageについて説明する。

図３に示されるように、BD-ROM format Part3 (AV)では、Binding Unit Manifest fileを用いて、ディスク１１とローカルストレージ１２とを結びつけて、Virtual Package１３をつくる手法が定義されている。即ち、かかる手法とは、ディスク１１上に記録されているClip AV stream fileを再生する手法の一つである。このディスク１１に関連づけられた別のClip AV stream fileが、例えばネットワーク経由でダウンロードされて、ローカルストレージ１２に記録される。その後に、ディスク１１上に記録されているClip AV stream fileとローカルストレージ１２に記録されているClip AV stream fileとが関連付けられて、Virtual Package１３が作られる。このVirtual Package１３に基づいて各Clip AV stream fileが再生される。

具体的には、ディスク１１上には、図３に示されるディレクトリ構造が構築されているとする。

rootディレクトリは、所定の名称のディレクトリ、例えば、"BDMV"ディレクトリを含む。

"BDMV"ディレクトリには、「info.bdmv」の名前が設定されたファイルと、「MovieObjects.bdmv」の名前が設定されたファイルとが格納されている。

"BDMV"ディレクトリにはまた、「PLAYLIST」の名前が設定されたディレクトリ（PLAYLISTディレクトリ）、「CLIPINF」の名前が設定されたディレクトリ（CLIPINFディレクトリ）、「STREAM」の名前が設定されたディレクトリ（STREAMディレクトリ）等が設けられている。

PLAYLISTディレクトリには、PlayListファイルが格納される。各PlayListファイルは、図内に示されるように５桁の数字からなるファイル名に拡張子「.mpls」を付加した名称が命名される。

CLIPINFディレクトリには、Clip Informationファイル（図２参照）が格納される。各Clip Informationファイルには、図内に示されるように５桁の数字からなるファイル名に拡張子「.clpi」を付加した名称が命名される。

STREAMディレクトリには、Clip AV stream fileやサブストリームファイルが格納される。各ストリームファイルには、図内に示されるように５桁の数字からなるファイル名に拡張子「.m2ts」を付加した名称が命名される。

また、ローカルストレージ１２には、図３に示されるディレクトリ構造が構築されているとする。

rootディレクトリには「xxx-yyy」の名前が設定されたディレクトリ（xxx-yyyディレクトリ）等が格納されている。

xxx-yyyディレクトリには、ディスク１１に関連づけられた別のClip AV stream fileであって、例えばネットワーク経由でダウンロードされた別のClip AV stream fileが記録されたり、その再生に必要な各種情報が記録される。

xxx-yyyディレクトリには、「zzzzz.bumf」の名前が設定されたファイルが格納されている。このファイルが、上述したBD-ROM format Part3 (AV)で規定されているBinding Unit Manifest fileである。

また、xxx-yyyディレクトリには、「New Data」の名前が設定されたディレクトリ（NewDataディレクトリ）が格納されている。NewDataディレクトリには、ネットワーク等からダウンロードされた情報として、ファイルf1乃至f3が格納されている。ファイルf3とは、「04000.m2ts」という名前が設定されたファイルであって、ディスク１１と関連付けられた別のClip AV stream fileである。また、ファイルf1とは、「22222.mpls」という名前が設定されたファイルであって、ファイルf3についてのPlayListファイルである。ファイルf2とは、「04000.clpi」という名前が設定されたファイルであって、ファイルf3についてのClip Informationファイルである。

この場合、ディスク１１のディレクトリ構造に対して、ローカルストレージ１２上のNewDataディレクトリの各ファイルf1乃至f3が、対応するディレクトリ内に再配置されることで、Virtual Package１３が構築される。即ち、Virtual Package１３においては、ファイルf1はPLAYLISTディレクトリに、ファイルf2はCLIPINFディレクトリに、ファイルf3はSTREAMディレクトリに、それぞれ格納されることになる。

このようなVirtual Package１３によるPlayListを再生する手法を採用することで、ストリーミングのようなアプリケーションを実現できる。即ち、かかる手法が、［背景技術］で説明した従来のストリーミング手法である。

例えば、ディスク１１に、図４に示されるようなPlayListファイルとClip Information fileとが記録されているとする。なお、図４において、「ディスク１１／ローカルストレージ１２」と記述されているのは、上述したVirtual Package１３を作ることができるので、PlayListファイルとClip Information fileとの記録場所は、ディスク１１でもローカルストレージ１２とのどちらでも構わないからである。このことは、後述する図５乃至図１０においても同様にあてはまることである。

ここで、ディスク１１には再生対象のClip AV stream fileが記録されていないとする。即ち、PlayListの再生が始まると、それぞれのPlayItemが参照するClip AV stream fileが、ローカルストレージ１２に順次ダウンロードされ、順次再生されていくとする。

なお、図４以降の図において、Clip AV stream fileが点線で示されていること、即ち、５桁の数字からなるファイル名に拡張子「.m2ts」を付加した名称のファイルが点線で示されていることは、その点線で示されたClip AV stream fileがまだダウンロードされていないことを意味する。

なお、以下、５桁の数字からなるファイル名に拡張子「.m2ts」を付加した名称のClip AV stream fileについては、単にその名称を用いて表現する。また、５桁の数字からなるファイル名に拡張子「.m2ts」を付加した名称のClip AV stream file全体をまとめて、m2tsファイルと適宜称する。

例えば、図５の例では、「10000.m2ts」乃至「10003.m2ts」はダウンロード済みであり、「10004.m2ts」乃至「10006.m2ts」はまだダウンロードされていないことを意味している。即ち、「10004.m2ts」が、次にダウンロードされるClip AV stream fileである。

以上、図４と図５を用いて、従来のストリーミング手法について説明した。

ところで、従来のストリーミング手法に従った再生をしている最中、即ち、図４や図５の例のようなPlayListを再生している最中、ネットワークの帯域が変動する場合がある。即ち、ネットワークの速度が低下する場合がある。このような場合、図５に示されるように、再生対象のClip AV stream fileが、ダウンロード対象のClip AV stream file（図５の例では、「10004.m2ts」）に追い付くと、再生停止という事態が生じてしまう。

そこで、本発明人は、このような事態が生じることを回避すべく、ダウンロード対象のClip AV stream fileのビットレートを動的に変更させる、という手法を発明した。以下、かかる手法を、ダウンロードストリームビットレート可変手法と称する。

ただし、ダウンロードストリームビットレート可変手法を実現するためには、次の前提事項を考慮する必要がある。

即ち、PlayListの再生前に、そのPlayListが参照するClip Information filesが予め全て揃っている必要がある、という前提事項が存在する。これは、EP_mapを予め再生装置のメモリにストアできるようにするために生じる前提事項である。この前提事項は、PlayListの再生前に、予め決められたEP_mapによって、Clip AV stream file(m2tsファイル）のタイムスタンプ-アドレスの対応関係が固定される、という前提事項であると把握することもできる。

従って、このような前提事項の下では、従来のストリーミング手法に従ったPlayList、即ち、図４や図５の例のようなPlayListを採用した場合、再生が一旦開始されると、ダウンロード対象のClip AV stream fileのビットレートを変えることができなくなる。予め決められたEP_mapのタイムスタンプ-アドレスの関係は、ビットレートが下げられたClip AV stream fileに対しては適用できないからである。即ち、ダウンロード対象のClip AV stream fileのビットレートを変えると、正常な再生ができなくなるからである。

以上まとめると、前提事項の下では、従来のストリーミング手法に従ったPlayList、即ち、図４や図５の例のようなPlayListを採用した場合、ダウンロードストリームビットレート可変手法を実現することができない。

そこで、本発明人は、ダウンロードストリームビットレート可変手法を実現可能な次のようなストリーミング手法（以下、本発明のストリーミング手法と称する）を発明した。

即ち、本発明のストリーミング手法では、PlayListには、マルチアングルタイプの構造を利用した１以上のPlayItemが含まれている。ただし、マルチアングルという概念ではなく、マルチビットレートという概念を採用する。即ち、従来のマルチアングルという概念の下では、PlayItemは、様々なアングルのClip AV stream fileを参照していた。これに対して、マルチビットレートという概念の下では、PlayItemは、様々なビットレートのClip AV stream fileを参照する。ここで、様々なビットレートのClip AV stream fileとは、同一のビデオ素材を異なるビットレート(画質)でそれぞれエンコードした結果得られるファイルを意味する。即ち、従来では、アングル選択という概念が採用されていたのに対して、本発明のストリーミング手法では、ビットレート選択という概念が採用される。

具体的には例えば、本発明のストリーミング手法では、図６に示されるようなPlayListによる再生が可能である。

図６において、PI（Play Item）#(k+1)(kは0乃至6の整数値)で再生されるClip AV stream fileのビデオ素材自体は、図４と図５の従来のストリーミング手法で採用されたビデオ素材と同一であるとする。また、図４と図５の従来のストリーミング手法では、ビットレートが2Mbpsで固定されていたとする。この場合、図６のPI#（k+1）において、2Mbps（Angle-1）の「1000k.clpi」は、「1000k.m2ts」（このファイル自体は図６には、k=0乃至3のみが図示されている）を参照している。「1000k.m2ts」とは、図４と図５の例と同一のビデオ素材を同一ビットレート(=2Mbps)でエンコードした結果得られるClip AV stream fileである。

また、図６のPI#（k+1）において1Mbps（Angle-2）の「2000k.clpi」は、「2000k.m2ts」（このファイル自体は図６には図示せず）を参照している。よって、「2000k.m2ts」とは、「1000k.m2ts」とは同一のビデオ素材を、「1000k.m2ts」とは異なるビットレート（=1Mbps）でエンコードした結果得られるClip AV stream fileである。

同様に、図６のPI#（k+1）において0.5Mbps（Angle-3）の「3000k.clpi」は、「3000k.m2ts」（このファイル自体は図６には、k=3乃至6のみが図示されている）を参照している。よって、「3000k.m2ts」とは、「1000k.m2ts」とは同一のビデオ素材を、「1000k.m2ts」や「2000k.m2ts」とは異なるビットレート（=1Mbps）でエンコードした結果得られるClip AV stream fileである。

このように、本発明のストリーミング手法で採用されるPlayItemでは、図６のPI#（k+1）のように、従来のマルチアングルタイプの構造が採用されている。ただし、本発明のストリーミング手法で採用されるPlayItemは、図６のPI#（k+1）のように、従来のような様々なアングルのClip AV stream fileを参照するのではなく、様々なビットレートのClip AV stream fileを参照する。以下、このような、本発明のストリーミング手法で採用されるPlayItemを、従来のものと明確に区別すべく、以下、本発明のマルチビットレート構造のPlayItemと称する。

従来のマルチアングルタイプの構造のPlayItemでは、再生対象のアングルの切り替えが可能であった。本発明のマルチビットレート構造のPlayItemでは、この「アングルの切り替え」を利用することで、再生対象のビットレートの切り替えが可能になる。

再生対象のビットレートの切り替え制御は、再生装置側のJava（登録商標）アプリケーション実行環境（後述する図１１参照）上で実行されるJava（登録商標）アプリケーションによって行われるとする。即ち、Java（登録商標）アプリケーションは、ダウンロード済のClip AV stream fileのバッファ量（ローカルストレージ１２のバッファ量）を監視する等により、ネットワークの帯域（速度）を監視する。そして、Java（登録商標）アプリケーションは、ネットワークの帯域が一定以下に狭くなった（速度が一定以下になった）と判定した場合、ダウンロード対象を、ビットレートの低いClip AV stream fileに切り替える。

ただし、Java（登録商標）アプリケーションによるビットレートの切り替えの指令（従来のアングル切り替えの指令であって、図６のselectAngle（）に相当）の発行タイミングと、再生装置による実際のビットレートの切り替え動作（従来のアングル切り替え動作に相当）のタイミングとは同時ではない。即ち、後者のタイミングの方が遅延する。そこで、ビットレートを切り替える付近のAV steam file再生区間では、切り替え前のビットレート（従来の元アングルに相当）と、切り替え後のビットレート（従来の行き先のアングルに相当）とのClip AV stream fileのダウンロードのオーバラップが必要になる。例えば、図６の例では、PI#4が、ビットレートを切り替える付近のAV steam file再生区間に該当する。このため、2Mbpsの「10003.m2ts」と0.5Mbpsの「30003.m2ts」とがダウンロードされ、再生装置のローカルストレージ１２に蓄積される。

なお、従来のマルチアングルタイプの構造のPlayItemでは、ユーザによる「アングルの切り替え」の操作が許可されていたのに対して、本発明のマルチビットレート構造のPlayItemでは、ユーザによるビットレートの切り替えの操作（ユーザからみたら「アングルの切り替え」の操作）は禁止する。上述の如く、本発明のストリーミング手法の趣旨は、ネットワークの帯域が狭まると、再生対象のClip AV stream fileがダウンロード対象のClip AV stream fileに追い付いてしまい再生停止してしまう、という事態が生ずることを回避することである。よって、ユーザによる「ビットレートの切り替え」の操作を許可すると、ネットワークの帯域とは無関係にビットレートが可変され、この趣旨が没却してしまうからである。

さらに、以下、図７乃至図１０を参照して、本発明のストリーミング手法の詳細例について説明する。

図７は、本発明のストリーミング手法によるPLayListの再生開始前の状態を示している。

PlayListを再生する前には、図７に示されるように、そのPlayListファイルと、そのPlayListが参照するClip Information filesが全て予め揃っていることが前提となる。

また、このPlayListの再生コントロールを行うJava（登録商標）アプリケーションが、ディスク１１、または、ローカルストレージ１２に存在することが前提となる。Java（登録商標）アプリケーションは、再生装置のCPU（Central Processing Unit）により実行される。即ち、Java（登録商標）アプリケーションを実行しているCPUが、Java（登録商標）アプリケーション実行環境である。

PlayItemの構造としては、本発明のマルチビットレート構造が採用されている。即ち、PlayItemは、様々なビットレートのClip AV stream fileを参照している。様々なビットレートのClip AV stream fileとは、上述の如く、同一のビデオ素材を様々なビットレート(画質)でそれぞれエンコードした結果得られるファイルである。従来でいう「Angle-1」が参照するClip AV stream fileが、2MbpsのClip AV stream fileである。従来でいう「Angle-2」が参照するClip AV stream fileが、1MbpsのClip AV stream fileである。
従来でいう「Angle-3」のClipが、0.5MbpsのClip AV stream fileである。

また、PlayListファイルには、ユーザによるビットレート切り替えの操作（従来でいう「アングル切り替え」の操作）を禁止する指定がなされている。

Java（登録商標）アプリケーションは、このPlayListの再生に先立ち、ネットワークの速度を調べる。Java（登録商標）アプリケーションは、所定の手法により、ネットワークの速度に基づいて、ダウンロード対象のClip AV stream fileのビットレートを決定する。即ち、Java（登録商標）アプリケーションは、再生前にネットワーク速度を調べて、どのビットレート(=アングル)のClip AV stream fileを再生するのかを決定する。

なお、ネットワークの速度に比べて、Clip AV streams fileのビットレートは十分に小さいことが前提となる。この前提は、ストリームの再生速度（再生データの消費量）よりも、ローカルストレージ１２へのデータの蓄積量（ダウンロード速度）を十分に早くできるようにすることを目的とする前提である。

例えば、ネットワークの速度に比べて半分の速度以下のビットレートのうち、選択可能な最高のビットレートが、初期状態のビットレートとして選択されるとする。例えば、ネットワークの速度が4Mbps以上の場合、図７乃至図１０の例では、2Mbps（Angle-1）が、初期状態のビットレートとして決定される。

図８は、本発明のストリーミング手法によるPLayListの再生直後の状態を示している。

Java（登録商標）アプリケーションは、最初のClip AV stream fileとして、PI#1の2Mbpsの「10000.m2ts」をダウンロードする。

なお、Java（登録商標）アプリケーションは、少なくとも、最初のClip AV stream file のダウンロードが終了するまでは、PlayListの再生を開始しないとする。本実施の形態では例えば、最初のClip AV stream file(図８の例では「10000.m2ts」)のダウンロードが終わると、PlayListの再生が開始される。

Java（登録商標）アプリケーションは、ネットワークの速度を監視し、ネットワークの速度が一定以上である場合、初期状態のビットレートのClip AV stream fileを順次ダウンロードしていく。

即ち、図８の例では、PI#1の2Mbpsの「10000.m2ts」がダウンロードされると、次に、PI#2の2Mbpsの「10001.m2ts」がダウンロードされる。その後、PI#3の2Mbpsの「10002.m2ts」、PI#4の2Mbpsの「10003.m2ts」がその順番で順次ダウンロードされていく。

ここで、ネットワークの速度がClip AV stream fileのビットレートのＮ倍の場合、ネットワークを介してダウンロードされたClip AV stream fileのローカルストレージ１２への蓄積速度は、Clip AV stream fileの再生速度のＮ倍になる。よって、最初のClip AV stream fileの再生が終了したときには、ローカルストレージ１２には、次以降に再生されるべきＮ個分のClip AV stream fileが蓄積されていることが期待される。

例えば、N＝４とすると、図８の例では、ネットワークの速度が8Mbps（=2Mbps×４）となり、最初のClip AV stream fileであるPI#1の「10000.m2ts」の再生速度が2Mbpsとなる。この場合、「10000.m2ts」の再生の終了時点では、8Mbpsでネットワークを介して伝送されてくるN＝４個のClip AV stream fileがダウンロードされているはずである。即ち、PI#2の2Mbpsの「10001.m2ts」、PI#3の2Mbpsの「10002.m2ts」、PI#4の2Mbpsの「10003.m2ts」、およびPI#5の2Mbpsの「10004.m2ts」の計４個のClip AV stream fileがローカルストレージ１２に蓄積されているはずである。

そこで、PI#(k+1)のClip AV stream fileの再生が終了した時点で、次以降に再生されるPI#(k+2)乃至PI#(K+1+N)のClip AV stream fileが少なくともローカルストレージ１２に溜まっている状態を、定常状態と定義する。即ち、ローカルストレージ１２に少なくともＮ個のClip AV stream fileが溜まっている状態が、定常状態となる。

例えばN=４の場合、PI#(k+1)のClip AV stream fileの再生が終了した時点で、少なくともPI#(k+2)乃至PI#(K+5)のClip AV stream fileがローカルストレージ１２に少なくとも溜まっている状態が、定常状態である。即ち、N＝４個以上のClip AV stream fileがローカルストレージ１２に少なくとも溜まっている状態が、定常状態である。

具体的には例えば、k=0の場合、PI#1の「10000.m2ts」の再生の終了時点で、PI#2の2Mbpsの「10001.m2ts」、PI#3の2Mbpsの「10002.m2ts」、PI#4の2Mbpsの「10003.m2ts」、およびPI#5の2Mbpsの「10004.m2ts」の計４個のClip AV stream fileがローカルストレージ１２に少なくとも蓄積されている状態が、定常状態である。

このような定常状態は、ネットワークの速度が維持されている限り、維持されるはずである。しかしながら、ネットワークの速度が低下すると、定常状態の維持が困難になる。

そこで、例えば、Java（登録商標）アプリケーションは、ローカルストレージ１２に蓄積されているClip AV stream fileの個数（以下、蓄積個数と称する）と、閾値（例えばN/2）とを比較することで、ネットワークの速度の低下の有無を判定することができる。即ち、蓄積個数が閾値を超えている場合、ネットワークの速度が低下していないと判定される。これに対して、蓄積個数が閾値以下の場合、ネットワークの速度が低下していると判定される。

そして、Java（登録商標）アプリケーションは、ネットワークの速度が低下したと判定した場合、次にダウンロードすべきClip AV stream fileを、現在よりもビットレートの低いClip AV stream fileに切り替える。なお、切り替え手法自体は特に限定されない。

具体的には例えば、N＝４として、閾値＝（N/2）＝２とする。この場合、PI#1の「10000.m2ts」の再生の終了時点で、PI#2の2Mbpsの「10001.m2ts」、PI#3の2Mbpsの「10002.m2ts」、およびPI#4の2Mbpsの「10003.m2ts」の計３個（＞閾値２）のClip AV stream fileがローカルストレージ１２に少なくとも蓄積されているとする。この場合、蓄積個数３＞閾値２となるので、ネットワークの速度が低下していないと判定される。よって、ビットレートの切り替えが行われず、次にPI#5の2Mbpsの「10004.m2ts」がダウンロードされる。

これに対して、例えば図９に示されるように、PI#1の「10000.m2ts」の再生の終了時点で、PI#2の2Mbpsの「10001.m2ts」とPI#3の2Mbpsの「10002.m2ts」との計２個（＝閾値２）のClip AV stream fileがローカルストレージ１２に蓄積されているとする。この場合、蓄積個数２＝閾値２となるので、ネットワークの速度が低下していると判定される。よって、図１０に示されるように、Java（登録商標）アプリケーションは、次のダウンロード対象のPI#4のClip AV stream fileを、ビットレートの低いものとするように、ビットレートの切り替え（＝従来でいう「アングルの切り替え」）の制御を行う。例えば図１０の例では、0.5Mbpsのビットレート(=Angle-3)のClip AV stream fileがダウンロードされるように切り変えられる。

その結果、図１０の例では、それ以降、PI#4の0.5Mbpsの「30003.m2ts」，PI#5の0.5Mbpsの「30004.m2ts」，PI#6の0.5Mbpsの「30005.m2ts」，PI#7の0.5Mbpsの「30006.m2ts」がその順番で順次ダウンロードされることになる。

ただし、上述の如く、Java（登録商標）アプリケーションによるビットレートの切り替えの指令（従来のアングル切り替えの指令であって、図１０のselectAngle（）に相当）の発行タイミングと、再生装置による実際のビットレートの切り替え動作（従来のアングル切り替え動作に相当）のタイミングとは同時ではない。即ち、後者のタイミングの方が遅延する。そこで、ビットレートを切り替える付近のPI#4では、切り替え後の0.5Mbpsの「30003.m2ts」とともに、切り替え前の2Mbpsの「10003.m2ts」がオーバラップしてダウンロードされ、再生装置のローカルストレージ１２に蓄積される。

なお、Java（登録商標）アプリケーションは、その後も、ネットワークの速度（ローカルストレージ１２の蓄積量等）を監視する。

例えば、さらにネットワークの速度が低下して、再生がダウンロードに追いついてしまった場合、一時的に再生が停止する。

逆に例えば、ネットワークの速度が上昇したと判定した場合、次にダウンロードすべきClip AV stream fileが、現在よりもビットレートの高いものに切り替えられる。

なお、切り替え手法自体は特に限定されない。ただし、安全を考えて、現在よりも１段階上のビットレートに切り替えると好適である。この場合、例えば図１０の例では、0.5Mbps（Angle-3）から1Mbps（Angle-2）に切り替えられることになる。なお、この場合も、ビットレートを切り替える付近のAV steam file再生区間では、切り替え前のビットレート（従来の元アングルに相当）と、切り替え後のビットレート（従来の行き先のアングルに相当）とのClip AV stream fileのダウンロードのオーバラップがなされてもよい。

以上、図６乃至図１０を参照して、本発明のストリーミング手法について説明した。かかる本発明のストリーミング手法に従った再生が可能な再生装置の構成例が図１１に示されている。即ち、図１１は、本発明が適用される再生装置の一実施の形態の構成例を示している。

図１１の例の再生装置２１は、ディスクドライブ４１、ローカルストレージ１２、ネットワークインタフェース４２、メモリ４５、Java（登録商標）アプリケーション実行環境４４、およびAVデコーダ４６を含むように構成されている。

ディスクドライブ４１、ローカルストレージ１２、ネットワークインタフェース４２、メモリ４５、およびJava（登録商標）アプリケーション実行環境４４は、バス４３により相互に接続されている。AVデコーダ４６は、バス４３とJava（登録商標）アプリケーション実行環境４４とに接続されている。

順不動に説明すると、PlayListを再生する前には、そのPlayListファイルとそのPlayListが参照するClip Information filesがディスク１１またはローカルストレージ１２に全て揃っている。また、このPlayListの再生を制御するJava（登録商標）アプリケーションが、ディスク１１またはローカルストレージ１２に存在する。これらのPlayList file, Clip Information file、およびJava（登録商標）アプリケーションは、メモリ４５にストアされる。

Java（登録商標）アプリケーション実行環境４４で実行されるJava（登録商標）アプリケーションは、PlayListの再生に先立ち、ネットワークインタフェース４２を制御して、ネットワーク３３の速度を調査する。Java（登録商標）アプリケーションは、その調査結果に基づいて、初期状態として、どのビットレート(=アングル)を再生するのかを決定する。

Java（登録商標）アプリケーションは、ネットワークインタフェース４２を制御して、ネットワーク３３を介在するサーバ２２との通信を行う。即ち、サーバ２２は、ダウンロード対象の様々なビットレートのClip AV stream fileを格納している。そこで、Java（登録商標）アプリケーションは、初期状態として決定されたビットレートのClip AV stream fileをサーバ２２からダウンロードして、ローカルストレージ１２にストアする。

Java（登録商標）アプリケーションは、ローカルストレージ１２の蓄積量を調査することで、ネットワーク速度の低下の有無を判定する。

Java（登録商標）アプリケーションは、ネットワーク速度が低下したと判定した場合、従来でいう「アングルの切り替え制御」を実行することで、ダウンロード対象のClip AV stream fileをビットレートを下げたものに切り替える。即ち、Java（登録商標）アプリケーションは、サーバ２２に対してダウンロードの切り替えを通知する。その通知を受けたサーバ２２は、ビットレートの低いClip AV stream fileを送信する。Java（登録商標）アプリケーションは、ビットレートの低いClip AV stream fileをダウンロードして、ローカルストレージ１２にストアする。

なお、ネットワーク速度が上昇したと判定した場合にも、Java（登録商標）アプリケーションは、ネットワーク速度が低下したと判定した場合と基本的に同様の動作を行うことで、ビットレートの高いClip AV stream fileをダウンロードして、ローカルストレージ１２にストアすることができる。

この間、Java（登録商標）アプリケーションは、AVデコーダ４６を制御して、PlayListの再生を行う。即ち、AVデコーダ４６は、PlayListに従って、次に再生すべきClip AV stream fileをローカルストレージ１２から読み出し、デコード処理を施す。これにより、映像信号と音声信号とが得られ、外部のモニタ等に出力される。

ところで、上述した一連の処理は、ハードウエアにより実行させることもできるが、ソフトウエアにより実行させることができる。

一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば図１１の再生装置２１の他汎用のパーソナルコンピュータなどに、ネットワークや記録媒体からインストールされる。

このようなプログラムを含む記録媒体は、図１１に示されるように、装置本体とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク（フロッピディスクを含む）、光ディスク（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)，ブルーレイディスク等の図１１のディスク１１を含む）、光磁気ディスク（ＭＤ（Mini-Disk）を含む）、もしくは半導体メモリなどよりなるリムーバブルメディア（パッケージメディア）により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される、プログラムが記録されているローカルストレージ１２やメモリ４５、パーソナルコンピュータ等に含まれるハードディスクなどで構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

また、本明細書において、システムとは、複数の処理装置や処理部により構成される装置全体を表すものである。

なお、本発明の再生装置は、普通のディスプレイも含めてディスプレイの方式を識別した上で、出力映像信号を切り替えることも可能である。

従来のマルチアングルタイプのPlayItemを説明する図である。 従来のマルチアングルタイプのPlayItemを説明する図である。 Virtual Packageについて説明する図である。 従来のストリーミング手法を説明する図である。 従来のストリーミング手法を説明する図である。 本発明のストリーミング手法の概要を説明する図である。 本発明のストリーミング手法の詳細を説明する図である。 本発明のストリーミング手法の概要を説明する図である。 本発明のストリーミング手法の概要を説明する図である。 本発明のストリーミング手法の概要を説明する図である。 本発明のストリーミング手法に従った再生が可能な再生装置、即ち、本発明が適用される再生装置の構成例を示すブロック図である。

符号の説明

１１ ディスク， １２ ローカルストレージ， １３ Virtual Package, ２１ 再生装置， ２２ サーバ， ３３ ネットワーク， ４１ ディスクドライブ， ４２ ネットワークインタフェース， ４３ バス， ４４ Java（登録商標）アプリケーション実行環境， ４５ メモリ， ４６ AVデコーダ

Claims (7)

1. BD-ROM(Blu-ray Disc-Read Only Memory)規格で規定されているマルチアングルタイプのPlayItemであって、
   複数のアングルのClip AV stream fileの代わりに、同一の素材が複数のビットレートでそれぞれエンコードされた結果得られる、ネットワークを介してダウンロードされる対象の複数のビットレートのClip AV stream fileを参照している前記PlayItemを
   １以上含むPlayListの
   データ構造。
2. BD-ROM(Blu-ray Disc-Read Only Memory)規格で規定されているマルチアングルタイプのPlayItemであって、複数のアングルのClip AV stream fileの代わりに、同一の素材が複数のビットレートでそれぞれエンコードされた結果得られる、ネットワークを介してダウンロードされる対象の複数のビットレートのClip AV stream fileを参照しているPlayItemを、１以上含むPlayListの再生を制御する再生制御手段を備え、
   前記再生制御手段は、
   前記ネットワークの速度を監視し、前記速度が一定以下になったと判定したとき、前記PlayItemのアングル切り替えの制御を利用して、ダウンロード対象のClip AV stream fileとして、これまでよりも低いビットレートのClip AV stream fileに切り替える
   再生装置。
3. 前記再生制御手段の制御によりダウンロードされた前記Clip AV stream fileを蓄積する蓄積手段をさらに備え、
   前記再生制御手段は、前記格納手段における前記Clip AV stream fileの蓄積量に基づいて、前記ネットワークの速度が一定以下となったか否かを判定する
   請求項２に記載の再生装置。
4. 前記再生制御手段は、前記速度が一定以下になったと判定したとき、次にダウンロードする対象のPlayItemについては、切り替え後のビットレートのClip AV stream fileに加えてさらに、切り替え前のビットレートのClip AV stream fileをダウンロードするように制御する
   請求項２に記載の再生装置。
5. 前記再生制御手段は、さらに、ユーザによる前記アングル切り替えを禁止する
   請求項２に記載の再生装置。
6. BD-ROM(Blu-ray Disc-Read Only Memory)規格で規定されているマルチアングルタイプのPlayItemであって、複数のアングルのClip AV stream fileの代わりに、同一の素材が複数のビットレートでそれぞれエンコードされた結果得られる、ネットワークを介してダウンロードされる対象の複数のビットレートのClip AV stream fileを参照しているPlayItemを、１以上含むPlayListの再生を制御する再生装置が、
   前記ネットワークの速度を監視し、前記速度が一定以下になったと判定したとき、前記PlayItemのアングル切り替えの制御を利用して、ダウンロード対象のClip AV stream fileとして、これまでよりも低いビットレートのClip AV stream fileに切り替える
   ステップを含む再生方法。
7. BD-ROM(Blu-ray Disc-Read Only Memory)規格で規定されているマルチアングルタイプのPlayItemであって、複数のアングルのClip AV stream fileの代わりに、同一の素材が複数のビットレートでそれぞれエンコードされた結果得られる、ネットワークを介してダウンロードされる対象の複数のビットレートのClip AV stream fileを参照しているPlayItemを、１以上含むPlayListの再生を制御するコンピュータが、
   前記ネットワークの速度を監視し、前記速度が一定以下になったと判定したとき、前記PlayItemのアングル切り替えの制御を利用して、ダウンロード対象のClip AV stream fileとして、これまでよりも低いビットレートのClip AV stream fileに切り替える
   ステップを含む制御処理を実行するプログラム。

Images