Nothing Special   »   [go: up one dir, main page]

JP6415652B1 - 映像再生装置、映像記録装置および映像記録方法 - Google Patents

映像再生装置、映像記録装置および映像記録方法 Download PDF

Info

Publication number
JP6415652B1
JP6415652B1 JP2017138934A JP2017138934A JP6415652B1 JP 6415652 B1 JP6415652 B1 JP 6415652B1 JP 2017138934 A JP2017138934 A JP 2017138934A JP 2017138934 A JP2017138934 A JP 2017138934A JP 6415652 B1 JP6415652 B1 JP 6415652B1
Authority
JP
Japan
Prior art keywords
data
video
information
recording
time
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2017138934A
Other languages
English (en)
Other versions
JP2019022079A (ja
Inventor
孝介 八木
孝介 八木
島田 昌明
昌明 島田
伸夫 竹下
伸夫 竹下
智 岸上
智 岸上
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mitsubishi Electric Corp
Original Assignee
Mitsubishi Electric Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mitsubishi Electric Corp filed Critical Mitsubishi Electric Corp
Priority to JP2017138934A priority Critical patent/JP6415652B1/ja
Application granted granted Critical
Publication of JP6415652B1 publication Critical patent/JP6415652B1/ja
Publication of JP2019022079A publication Critical patent/JP2019022079A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Television Signal Processing For Recording (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)

Abstract

【課題】 MMT方式の番組を簡易な方式で記録できる映像記録方式を実現する。【解決手段】 映像記録再生装置(100)は、チューナー・復調部(11)、多重化解除部(21)、デコード部(31,32,33,34)及び記録再生制御部(41)を備える。チューナー・復調部(11)は、放送波(Ba)を受け取る。多重化解除部(21)は、放送波(Ba)の多重化ストリーム(Sm)の多重化を解除する。デコード部(31,32,33,34)は、多重化ストリーム(Sm)の多重化が解除された圧縮データを伸長する。記録再生制御部(41)は、デコード部(31,32,33,34)で伸長されたデータから記録するための映像データまたは制御情報を収集する。映像記録再生装置(100)は、MMT形式を用いた放送波(Ba)に含まれた映像データを記録する際に、パケットデータを結合した映像データとして記録する。【選択図】 図1

Description

本発明は映像記録再生装置に関する。
近年、映像圧縮技術または放送波の変調技術の進歩に伴い、各国で新しいテレビ放送方式の導入が検討されている。新しい方式によって、伝送効率が向上する。このため、これまでと同じ電波帯域を用いて、より高品質な映像を放送することが可能になる。また、これまでと同じ品質の映像を、より狭い電波帯域で放送することも可能である。新しい方式の導入に伴い、ネットワークとの連携が検討されている。また、受信機に蓄積されて動作するアプリケーションまたはコンテンツなども検討されている。
テレビ放送を録画する方式は、通常のテレビ放送方式と密接に関係している。新しいテレビ放送方式が採用された場合には、新しいテレビ放送方式の番組を、そのまま録画することはできない。そのため、テレビ放送方式が変更される際には、録画方式も新しい放送方式に対応した方式に変更する必要がある。
特に、可換型記録メディアを使用する場合には,他の再生装置との互換性も含めて考慮する必要がある。可換型記録メディアは、例えば、DVD(登録商標:Digital Versatile Disc)またはブルーレイディスク(登録商標:BLU−RAY DISC)などである。
現在採用されている録画方式では、新しいテレビ放送方式をそのまま記録することは困難である。このため、新しいテレビ放送方式に対応した録画方式が必要となっている。
例えば、特許文献1には、BDAV方式を用いたテレビ放送の記録方式、大容量になる記録データを分割記録する方法および大容量になる記録データにアクセスする方法が記載されている。また、圧縮された映像データと音声データとを、MPEG2TSに格納して記録する方法が記載されている。また、MPEG2TSで送信されたテレビ放送を受信して、MPEG2TSの形式で記録する方法が記載されている。
WO2006/030767(0021段〜0105段、図1〜図21)
高品質な8K映像の放送を録画したディスク再生する場合に、早送りなどの特殊再生を行うと、1コマ分の画像を表示するのに時間がかかってしまうという問題がある。
本発明は、これらの問題を鑑みて、特殊再生時の応答性を向上することを目的としている。
本発明に係る映像再生装置は、MMT方式を用いた放送ストリームを記録した記録データを再生し、前記記録データは、Iピクチャを含んで構成される映像情報と、前記Iピクチャの開始位置を示す第1のタイムテーブルと、前記Iピクチャを構成する複数のスライスセグメントの開始位置を示す第2のタイムテーブルと、前記映像情報を表示する画面の中で重要な情報が集中している部分の有無及び位置を示す優先スライス情報とを含み、前記優先スライス情報が示す前記部分の位置に基づいて、前記部分に表示させる前記スライスセグメントを早送り再生することを特徴とする。
本発明に係る映像再生装置は、画像の更新間隔を短くし、特殊再生時の応答性を向上できる。
実施の形態1に係る映像記録再生装置100の構成図である。 多重化解除手順を説明する図である。 データの論理構造を示した図である。 TLVパケットを結合して記録した場合の模式図である。 パケットの選択と時間の同期とを説明する概念図である。 MMTP方式でのMPUタイムスタンプ記述子を用いた同期方式を説明する図である。 タイムテーブルを作成する手順を示すフローチャートである。 フレーム単位の時刻で検索できるタイムテーブルを示す図である。 MMTP方式でのMPUタイムスタンプ記述子を用いた同期方式を説明する図である。 BMFFとしてストリームデータを記録した場合の説明図である。 実施の形態2に係るMMTP方式でのMPTによる多重化解除の説明図である。 タイムテーブルと映像データの関係の説明図である。 MMTP方式でのMPTデータ構造の例である。 映像を中心に考えた場合のアライメントの説明図である。 実施の形態3に係る映像ストリームの模式図である。 画像の分割を示した図である。 画像の分割を示した図である。 分割スライスセグメントに対応したタイムテーブルの図である。 タイムテーブルの各項目とデータ上との対応を示す図である。 早送り再生の説明図である。 変形例1に係る早送り再生の説明図である。 画像の更新の順番の説明図である。 画像の更新の順番の説明図である。 変形例2に係るタイムテーブルの図である。 早送り再生の説明図である。 タイムテーブル(TMSN)の説明図である。 シーン連続性番号の効果の説明図である。 シーン連続性番号を用いた表示画面更新のフローチャートである。 優先スライス情報の効果の説明図である。 優先スライス情報を用いた表示画面更新のフローチャートである。
テレビ放送の楽しみ方の1つとして、テレビ放送の番組を録画(記録)して、後日、再生して視聴することは、従来から行われてきた。録画の楽しみ方は、大きく分けて2種類ある。1つは、「タイムシフト」と呼ばれるものである。タイムシフトは、放送が行われている時間に番組を視聴することができない場合に、番組を録画しておき、後で番組を再生するものである。他は、「アーカイブ」と呼ばれるものである。アーカイブは、番組を録画して、保管しておくものである。そのため、録画した番組を、いつでも見ることができる。
タイムシフトを利用する場合には、番組を録画した後に、短期間で利用が終了する事が多い。一方、アーカイブを利用する場合には、番組を録画した後に、長期間保存して利用されることが多い。
テレビ放送以外にも、利用者自身が撮影した映像を記録することも行われている。家庭用ビデオカメラなどで撮影された映像データを、光ディスク又はハードディスク等に記録して保管する。
最近では、ネットワークなどで収集した映像を記録することもある。また、家庭での録画以外にも、美術館、博物館またはデジタル・サイネージにおいても、録画された映像が使用されている。「デジタル・サイネージ」とは、表示と通信とにデジタル技術を活用して、平面ディスプレイ又はプロジェクタなどによって、映像または情報を表示する広告媒体である。
映画などの市販コンテンツとしては、コンテンツを記録した読み出し専用のDVDまたはブルーレイディスクなどがある。最近では、パッケージ入りの光ディスクの他に、ネットワーク経由でダウンロードを行うコンテンツのサービスも増えている。
放送されたコンテンツを記録するフォーマットと、市販されているコンテンツの記録フォーマットとは、異なることがある。たとえば、ブルーレイディスクの場合には、2種類のフォーマットを規定している。第1に、BDAVは、放送されたコンテンツの記録用フォーマットである。BDAVは、放送波をそのまま記録することができる。第2に、BDMVは、市販されているコンテンツ向けのフォーマットである。BDMVは、高度な再生制御機能を持っている。また、AVCHDは、カメラ等で用いられるHDDまたはメモリーカードなどに映像を記録する場合に用いられている。AVCHDは、BDMVを基にして変更が加えられている。
テレビ放送では、従来方式の4倍の解像度を持つ4K映像に対応したウルトラハイビジョン方式の導入が予定されている。また、さらに高品質な8K映像の放送も検討されている。同様に、北米地域または欧州地域でも、それぞれ現在の放送方式を拡張する形で、新しいテレビ放送方式の導入が検討されている。
地域ごとに差異はあるが、従来のテレビ放送方式は、映像圧縮方式としてMPEG2またはAVC(h.264)を採用している。また、従来のテレビ放送方式は、多重化方式としてMPEG2TSを採用していた。MPEG2TSは、放送という単一の伝送路を前提としており、映像または音声などを放送局が1つにまとめて送る形となっている。MPEG2TSでは伝送単位として同期マーク付きの固定長パケット方式が採用されている。そのため、録画方式でもMPEG2TSを記録する方式が採用されることが多い。
一方、新しいテレビ放送方式では、映像圧縮方式としてMPEG2、AVCまたはHEVC(h.265)を取り入れる規格が多い。HEVC(High Efficiency Video Coding)は、同一の画質で比べた場合には、圧縮効率がMPEG2の4倍であり、AVCの2倍である。HEVCは、高画質化または狭帯域化を目指す新しいテレビ放送方式に必要な圧縮技術である。
また、新しいテレビ放送方式では、ネットワーク技術との整合性を重視している。そのため、新しいテレビ放送方式では、多重化方式として、MMT(MPEG Media Transport)の採用が検討されている。MMTは、複数の伝送路で情報を提供できる方式で、映像または音声などを別々に伝送し、受信機がそれらを選択して受信できる。また、MMTは、可変長パケットを採用している。また、受信状況に応じて、再生する映像ストリームを変更する方式も検討されている。
上述のように、現在採用されている録画方式では、新しいテレビ放送方式をそのまま記録することは困難である。このため、新しいテレビ放送方式に対応した録画方式が必要となっている。
ここで、新しく記録方式を作る場合には、いくつかのアプローチが考えられる。
第1に、新しい放送方式を完全に従来方式の映像に変換して記録する方法である。この場合には、記録方式の変更は必要なく、従来の再生装置との互換もとれる。しかし、高画質などの新しい方式のメリットを受けることはできない。
第2に、従来の録画方式をできるだけ踏襲して、テレビ放送の情報の中心となる映像と音声とを新しい方式に変換して記録する方法である。この場合には、映像と音声とに関しては、新しい方式のメリットを受けることができる。しかし、字幕またはデータ放送などを楽しむことはできない。
第3に、新しい放送方式の番組データをそのまま記録する方式である。ネットワークサービスなど外部に依存する部分を除けば、新しい方式のメリットの多くを利用することができる。
実施の形態1.
図1は、実施の形態1に係る映像記録再生装置100の構成図である。映像記録再生装置100は、以下において録画再生装置100としても説明する。映像記録再生装置100と録画再生装置100とは、同じ装置である。
録画再生装置100は、チューナー・復調部11と多重化解除部21および記録再生制御部41を備えている。なお、以下の実施の形態では、録画再生装置として説明するが、再生部分を含まない録画装置とすることができる。
録画再生装置100は、映像デコード部32、音声デコード部31、字幕デコード・レンダリング部33またはデータ放送・EPG処理部34を備える。なお、デコード部は、映像デコード部32、音声デコード部31、字幕デコード・レンダリング部33またはデータ放送・EPG処理部34を含む。
また、録画再生装置100は、内蔵記録装置51または光ディスクドライブ52を備えることができる。
また、録画再生装置100は、外部入力部12またはネットワーク部13を備えることができる。外部入力部12およびネットワーク部13は、外部からの信号入力を受け取る機能を有している。また、チューナー・復調部11も、外部からの信号入力を受け取る機能を有している。
<録画再生装置100の構成>
チューナー・復調部11は、放送波Baを受け取る。そして、チューナー・復調部11は、受け取った放送波Baを復調する。外部入力部12は、外部の装置Eiからデータを受け取る。外部の装置は、例えば、ビデオカメラなどの録画装置である。なお、「データ」は、映像データ、音声データ、字幕データ、データ放送のデータまたは制御情報などを含む。
ネットワーク部13は、ネットワークNeからデータを受け取る。ネットワークNeは、例えば、複数のコンピュータまたは電子機器などを繋いで、信号、データまたは情報をやりとりすることができるコンピュータネットワークまたは通信ネットワークである。
多重化解除部21は、多重化ストリームSmの多重化を解除する。つまり、多重化解除部21は、多重化ストリームSmから、各種のデータを分けて取り出す。
音声デコード部31は、圧縮された音声データを伸長する。音声デコード部31は、エレメンタリーストリームSeに含まれる圧縮された音声データを伸長する。
映像デコード部32は、圧縮された映像データを伸長する。映像デコード部32は、エレメンタリーストリームSeに含まれる圧縮された映像データを伸長する。
字幕デコード・レンダリング部33は、圧縮された字幕データを伸長する。字幕デコード・レンダリング部33は、エレメンタリーストリームSeに含まれる圧縮された字幕データを伸長する。
データ放送・EPG処理部34は、圧縮されたデータ放送のデータを伸長する。データ放送・EPG処理部34は、エレメンタリーストリームSeに含まれる圧縮されたデータ放送のデータを伸長する。
記録再生制御部41は、記録用の映像データ、音声データまたは制御情報などを収集する。記録再生制御部41は、収集したデータを記録用のデータフォーマットに変換する。
内蔵記録装置51は、録画再生装置100に備えられた記録装置である。内蔵記録装置51は、例えば、ハードディスクドライブ、揮発性メモリまたは不揮発性メモリ等である。
光ディスクドライブ52は、光ディスク53にデータを記録する。また、光ディスクドライブ52は、光ディスク53からデータを読み出す。光ディスク53は、例えば、ブルーレイディスクまたはDVDなどである。
<データを記録しない場合のデータ処理の流れ>
まず、放送番組を記録せずに、テレビに表示する場合の流れを説明する。つまり、放送波を一例として、放送波の受信から映像および音声の出力までについて説明する。テレビは、図1では、表示装置Ddおよび音響装置Esである。
外部からの入力信号としては、アンテナで受信された放送波Ba、ビデオカメラ(外部装置Ei)などからの映像信号、映像再生装置等からの映像信号またはネットワークNeからの映像データ等がある。利用者は、リモコン(リモート・コントローラー)または操作ボタンなどを用いて、入力部を選択する。入力部は、チューナー・復調部11、外部入力部12またはネットワーク部13等である。リモコンは、利用者が操作する遠隔操作機器のことである。
また、放送波Baの場合には、放送局または番組などが設定される。また、ネットワークNeの場合には、データ取得先またはデータへのアクセス情報などが設定される。なお、利用者の視聴したい映像サービスまたは利用者の記録したい映像サービスは、特定されているものとする。また、利用者の視聴したい映像サービスまたは利用者の記録したい映像サービスは、受信できる状態になっているものとする。
アンテナ等で受信した放送波Baは、チューナー・復調部11に入力される。チューナー・復調部11は、放送波Baの中から指定された放送局の電波を取り出す。そして、チューナー・復調部11は、規定された復調方式で、放送波Baを復調する。そして、チューナー・復調部11は、放送波Baからデジタルデータを取り出す。
ここで、取り出されたデジタルデータは、映像データ、音声データ、字幕データまたは制御情報などを多重化した多重化ストリームSmである。また、複数の番組を、まとめて1つの多重化ストリームSmに格納することもある。
なお、「ストリーム」とは、時間の流れを持ったデータまたは時間的な流れを持った形で伝送されるデータを表わす。例えば、ストリームは、映像データの場合は、映像ストリームであり、音声データの場合は、音声ストリームである。また、その他には、字幕ストリーム、多重化ストリーム、受信ストリーム、データストリームなどが挙げられる。
多重化ストリームSmは、チューナー・復調部11で取り出される。チューナー・復調部11で取り出された多重化ストリームSmは、多重化解除部21に送られる。多重化解除部21は、多重化ストリームSmから、各種のデータまたは各種の制御情報などを分けて取り出す。データは、例えば、番組を直接構成するデータである。データは、例えば、映像ストリーム、音声ストリームまたは字幕ストリームなどである。データは、例えば、多重化ストリームSmに格納されたデータ放送用のプログラムまたはデータである。
多重化を解除された各種のデータ(エレメンタリーストリームSe)は、圧縮されたデータである。
映像ストリームは、圧縮された映像データである。映像デコード部32は、圧縮された映像データを伸長する。伸長された映像データは、表示装置Ddなどから映像として出力される。表示装置Ddは、例えば、テレビなどである。
同様に、音声ストリームは、圧縮された音声データである。音声デコード部31は、圧縮された音声データを伸長する。伸長された音声データは、音響装置Esから音声として出力される。音響装置Esは、例えば、テレビなどである。
表示装置Ddまたは音響装置Esから出力される際に、映像データDiと音声データDsとは、バッファリングと同期とが行われる(図示せず)。これによって、映像と音声とにずれが生じない。映像データと音声データとの出力のタイミングは、制御情報またはシステムクロック等から指定されたタイミングまたは算出されたタイミングである。
字幕ストリームは、圧縮された字幕データである。字幕デコード・レンダリング部33は、圧縮された字幕データを伸長する。字幕デコード・レンダリング部33は、伸長された字幕データを解釈する。字幕デコード・レンダリング部33は、解釈された字幕データを映像化する。映像化された字幕データは、指定されたタイミングで映像データまたは音声データと合成される。合成された字幕データは、表示装置Ddなどから映像として出力される。
データ放送のストリームは、圧縮されたデータである。データ放送・EPG処理部34は、圧縮されたデータ放送のデータを伸長する。データ放送・EPG処理部34は、指定されたタイミングで、伸長された映像データと伸長された音声データとを合成する。合成された映像データおよび音声データは、テレビなどから映像および音声として出力される。
録画再生装置100は、このようにして受信した放送波Baを、同期の取れた映像および音声として出力する。
<データの記録>
次に、この映像データを記録することを考える。
記録再生制御部41は、前述の放送波Baの受信から映像の表示までの流れの中で、記録用の映像データ、音声データまたは制御情報などを収集する。収集されたデータは、記録用のデータフォーマットに変換される。記録用のデータフォーマットに変換されたデータは、内蔵記録装置51または光ディスクドライブ52を通じて光ディスク53等に記録される。
記録再生制御部41が映像データまたは音声データを取り出す位置は、様々な組み合わせが考えられる。しかし、説明を容易にするために、次の(A)から(C)の3つ経路に単純化して説明する。3つ経路は、(A)多重化ストリームSmの状態での取り出し、(B)多重化が解除されたエレメンタリーストリームSeの状態での取り出し及び(C)映像音声が伸長された状態(映像データDi)での取り出しである。
なお、以下においては、(A)と(B)とに関して説明する。
≪(A−1)多重化ストリームSmの状態でのデータの記録(1)≫
多重化ストリームの状態でのデータ取り出しとブルーレイディスク(光ディスク53)への記録とを考える。データは、図1中の(A)の経路を使って取り出される。
例えば、日本方式の従来の放送方式の場合には、チューナー・復調部11から取り出される多重化ストリームSmは、MPEG2TSの多重化ストリーム内にMPEG2形式で圧縮された映像信号が格納された形のデータである。
MPEG2TSの放送用ストリームは、192バイトサイズの固定長パケットを採用している。また、このパケットを受信順に結合することによって、記録フォーマット用のデータファイルを作成することができる。このようにして作成されたデータファイルをストリームファイルと呼ぶ。
実際に放送されているストリームには、複数の番組が多重化されている。その中から目的の番組を取り出す過程が必要となる。しかし、ここでは、その説明を省略する。
まず、ブルーレイディスクのBDAVフォーマットの場合を説明する。
ブルーレイディスクのBDAVフォーマットの場合には、ストリームファイルの他に、クリップファイル、プレイリストファイルまたはインフォファイルなどが必要である。クリップファイルは、ストリームファイル内のデータにアクセスするための詳細情報を記録したファイルである。プレイリストファイルは、時系列の情報を管理する。時系列の情報は、例えば、一つの番組の開始点、終了点または再生ストリームの切り替えなどの情報である。インフォファイルは、再生可能な番組リストなどディスク全体の情報を管理する。
これらの情報は、ストリーム内の管理情報、利用者の設定した予約情報またはチューナー・復調部11から得られる管理情報などから作成される。これらに関しては、例えば、特許文献1に詳しく書かれている。
次に、日本の新しい放送方式の場合を説明する。
これは、例えば、放送サービス高度化推進協会の「高度高帯域衛星デジタル放送 運用規定1.1版 NEXTVF TR−004」(2016年3月30日発行、第一部・第二編・第5章、2−31〜2−40ページ、図5−1)に記載されている。
この方式は、4Kおよび8Kの高解像度映像に対応している。また、この方式は、色域および輝度域拡大に対応している。この方式は、映像圧縮方式として、HEVCを採用している。また、この方式は、多重化方式として、MMTとTLVとを組み合わせて採用している。
MMTおよびTLVは、ネットワークで用いられているIPパケットとの整合性を考えて設計されている。TLVは、IPパケットの放送波を用いた伝送方式である。MMTは、IPパケットを用いて映像データを転送する方式およびそのデータ形式を規定している。IPパケットは、可変長パケットを採用している。このため、MMTおよびTLVも可変長パケットを採用している。
図2を用いてこの方式での多重化解除手順を説明する。図2は、多重化解除手順を説明する図である。
図2において、横方向は、データの受信の順番を示している。つまり、横軸Ha方向には、受信された順番にデータが並べられている。受信した順番に左から右に記載してある。また、縦軸Va方向は、データの処理の流れを示している。つまり、縦軸Va方向には、パケット解析によるデータの取り出しの順番が示されている。縦軸Vaの範囲では、多重化ストリームSmの多重化を解除している。縦軸Vaの範囲では、エレメンタリーストリームSeの多重化を解除している。
TLVパケットのデータは、放送波Baの復調によって得られる。TLVパケットは、放送に関する情報を含んでいる。放送に関する情報は、例えば、放送の識別子、チャンネル、放送局名、IPアドレス、ポート番号または使用する電波の情報などである。「使用する電波」とは、地上波、BS放送またはCS放送などである。「使用する電波の情報」とは、放送の形態、変調方式、周波数、偏向方向または旋回方向などである。
ペイロードは、データ伝送におけるデータ部分を指す。つまり、ペイロードは、伝送されるデータ全体のうち、伝送処理のための管理情報を除いたものにあたる。管理情報は、例えば、ヘッダまたはメタデータなどである。
また、TLV(Type−Length−Value)は、情報の種類、長さおよび値をまとめて表現するフォーマットである。UDP(User Datagram Protocol)は、IPの上位プロトコルのトランスポート層で動作するプロトコルである。UDPは、ネットワーク層のIPとセッション層以上のプロトコルの橋渡しをするかたちで動作する。MMTP(登録商標)は、マルチメディア多重化伝送プロトコルである。
チューナー・復調部11は、放送局の情報、IPアドレスの情報またはポート番号の情報をTLVパケットから取り出す。チューナー・復調部11は、IPアドレスの情報を用いて、必要なIPパケットを取り出す。次に、チューナー・復調部11は、ポート番号の情報を用いてUDPパケットを取り出す。
この時点で、チューナー・復調部11は、放送局から送られてきた放送波Baの多重化を解除している。そして、チューナー・復調部11は、UDPパケットのデータを取り出している。チューナー・復調部11は、UDPパケットからUDPヘッダを取り除く。そして、チューナー・復調部11は、UDPパケットからUDPペイロードを取り出す。これによって、チューナー・復調部11は、UDPパケットからMMTPパケットを取り出すことができる。
日本の新しい放送規格では、1つのMMTPパケットは、1つのUDP/IPパケットに格納されている。さらに、1つのUDP/IPパケットは、1つのTLVパケットに格納されている。そのため、制御用データを分離した後のMMTPを伝送しているパケットでは、MMTPパケットは、TLVパケットから単純にTLVヘッダ、IPヘッダおよびUDPヘッダを取り除くことによって取り出される。
MMTPパケットとして取り出された時点で、放送局から送られてきた放送波Baの多重化は解除されている。しかし、放送波Baは、複数の番組をまとめた一連のMMTPパケットとして多重化されていることもある。その場合には、目的の番組だけを取り出すために、まず、制御情報を取り出して、その制御情報の記載に従って、MMTPパケットを選択して取り出す。
MMTPパケットとして送られてくる制御信号の1つにPLT(Package List Table)がある。全ての情報が放送波で送信されてくる場合には、PLTの中の「MMT_general_location_info」によって指定された「packet_id」を参照する。この「packet_id」を用いて、MMTPパケットをフィルタリングする。これによって、目的とする番組の管理情報を含むMMTPパケットを選択することができる。「目的とする番組」とは、視聴する予定の番組である。
ネットワークから番組の管理情報を取得する場合には、「MMT_general_location_info」に記載されているIPアドレスおよびポート番号が指定される。または、「MMT_general_location_info」によって、URLによる番組の取得先が指定される。
次に、選択されたMMTPパケットからMPT(MMT_Package_Table)を含むデータを取り出す。MPTには、目的とする番組を構成する映像、音声または字幕などのアセットの組合せと取得先とが記述されている。それぞれのアセットの取得先は、「MMT_general_location_info」によって、「packet_id」またはネットワーク情報で示されている。ここで、ネットワーク情報は、IPアドレス、ポート番号またはURLである。
このようにして、PLTで示された制御データと、MPTで示された番組を構成するアセットとを、例えば、「packet_id」でフィルタリングする。これよって、目的とする番組のMMTPパケットを取り出すことができる。
TLVパケットからMMTPパケットまたはMMTPペイロードを取りだす過程で、1つのパケットに着目する。パケットヘッダは、取り除かれる。しかし、パケット内のデータは変化しない。ところが、実際には、制御情報と各段階でのパケットヘッダの内容とから、パケットの取捨選択と分類とが行われている。
[標準フォーマットを用いないで記録する場合]
番組を記録する方法の1つとして、例えば、受信した放送のパケットを、そのまま記録する方法を説明する。
図4は、TLVパケットを結合して記録した場合の模式図である。
図4に示す例では、TLVパケットの時点で、放送局から送られてきた多重化ストリームSmの多重化を解除している。番組のTLVパケットは、そのまま結合されている。結合されたTLVパケットは、ファイルを構成している。
図4中に、TLVパケットTP−0,TP−1,TP−2,TP−3を示している。「−0」などは、TLVパケットTPの受信の順番を表わしている。例えば、TLVパケットTP−0は、最初に受信したTLVパケットTPである。横軸Haは、受信の順番を表わしている。
最初に受信したTLVパケットTP−0の後ろには、TLVパケットTP−0の後に受信したTLVパケットTP−1,TP−2,TP−3が結合している。そして、結合されたTLVパケットTP−0,TP−1,TP−2,TP−3は記録される。TLVパケットTPは、可変長パケットを採用している。
データをパケット単位で受信するため、受信時点で、パケットの先頭は明確である。しかし、他のパケットと結合して、1つのファイルを作成した場合には、それぞれのパケットの先頭位置を判別する必要がある。
第1の方法は、記録する時点で、パケットの先頭位置のリストを、管理用ファイルAfとして作成する方法である。
これは、パケットを記録する時点では、パケットのファイル内での先頭位置が判明するためである。この場合には、パケット番号などと関連付けてパケットの先頭位置のリストを作成しても良い。
第2の方法は、ファイルの先頭からデータを読み込み、先頭のデータHmがあった場合には、TLVパケットTPの先頭と判断する。そして、TLVパケットTPが結合したデータを読み込む。
TLVパケットTPには、パケットの先頭を識別するために、最初の1バイトには、固定値「0x7F」が格納されている。そして、先頭バイトの後ろには、パケット種別を表す1バイトのデータが格納されている。そして、その後ろには、データ長を示す2バイトのデータが格納されている。
ここで、TLVパケットTPの先頭のデータHmは、固定値「0x7F」である。
固定値「0x7F」(先頭のデータHm)が読み込まれれば、直前に読み込まれたデータを、TLVパケットTPとして解釈して処理を行う。
固定値「0x7F」は、特別な値ではない。固定値「0x7F」は、データ中にも存在している。そのため、間違った位置から読み込む可能性がある。この場合でも、TLVパケットTPのデータとしての矛盾の有無を確認する。または、データ長のデータを読み込んだ後に、次のデータの先頭が毎回固定値「0x7F」になっているか否かを確認する。これらによって、正しいデータの区切りで、パケットを読み込むことができる。
この例では、TLVパケットを記録する方法を示した。しかし、他にも、UDP/IPパケットを記録する方法も採用できる。また、MMTPパケットを、そのまま記録する方法なども採用できる。
しかし、TLVパケットを選んだ理由は、TLVパケットの先頭に識別用の固定バイトが用意されていて、パケットの識別が比較的に容易だからである。
他のパケットを記録する方法では、識別のためのマークが挿入されていない場合がある。そこで、識別子を独自に挿入する手法も採用できる。また、UDP/IPパケットの場合には、例えば、IPアドレス情報を用いて識別のためのマークとする方法も採用できる。IPアドレス情報は、同じ番組中では変化しない。
≪(A−2)多重化ストリームSmの状態でのデータの記録(2)≫
MPTは、MMTPパケットに格納されて伝送される。MPTは、制御情報を含んでいる。多重化解除部21は、MPTに記載された情報に基づいて、パケットを振り分ける。MPTに記載された情報は、例えば、MMTPヘッダに含まれるパケットID情報である。これによって、多重化解除部21は、映像情報または音声情報などを個別に取り出すことができる。そして、多重化解除部21は、多重化ストリームSmの多重化を解除することができる。
MFUは、MMTPパケットに格納されている。複数のMFUが1つのMMTPパケットに格納されている場合がある。また、1つのMFUが1つのMMTPパケットに格納されている場合がある。そして、1つのMFUが複数のMMTPパケットに格納されている場合がある。
MMTPに含まれる映像データのMFUまたは音声データのMFUは、アクセスユニット(以下、AUと示す。)またはNALユニットと呼ばれる処理単位になっている。そして、NAL(Network Abstraction Layer)ユニットは、AUをさらに細かく分割したデータである。
MFUに直接映像データを格納する場合には、AUを格納する場合とNALユニットを格納する場合とが定義されている。しかし、日本の新しい放送方式では、NALユニットで格納する方式を採用している。そのため、以降の説明ではNALユニットとして格納されているものとして説明する。
図2では、NALユニットを直接MFUに格納した場合を示している。NALユニットには、映像データのみを含んだVCL−NALユニットと、映像データを含まず管理情報を格納した非VCL−NALユニットとがある(VCL:Video Coding Layer)。
非VCL−NALユニットは、NALヘッダを取り除くと、制御情報が得られる。
VCL−NALユニットは、NALヘッダを取り除くと、分割された映像データが取り出される。これらの分割された映像データを結合することによって、1フレーム分の圧縮された映像データとなる
通常、NALユニットは1フレーム分の管理情報と映像データとを含む複数のNALユニットを一式として扱い、AUと呼ばれている。多重化解除部21は、映像データの場合には、AUは、映像データを含んでいる。そして、多重化解除部21は、ES(エレメンタリーストリーム)を再構築することができる。
映像データのAUは、基本的には、1フレーム分の映像単位である。1フレーム分の映像単位は、ピクチャを表現する単位である。映像装置では、このピクチャを時系列的に順次切り替えながら表示することで動画として表示している。しかし、前後のフレームとの依存関係で、いくつかの種類がある。
1つは、Iピクチャと呼ばれるものである。Iピクチャは、このデータ単独で、1枚のピクチャを再現できる。
他には、PピクチャまたはBピクチャと呼ばれるものである。これらのデータは、他のピクチャに依存している。そのため、PピクチャおよびBピクチャは、単独では1枚のピクチャを再現できない。PピクチャおよびBピクチャは、他のピクチャを参照することによって、ピクチャを再現できる。Pピクチャは、1枚の他のピクチャを参照する。Bピクチャは、2枚の他のピクチャを参照する。
テレビ放送または映像記録再生装置などでは、番組の途中からの視聴できることが求められている。また、テレビ放送または映像記録再生装置などでは、ランダムアクセスできることが求められている。そのため、参照するピクチャが広範囲であると都合が悪い。
そこで、ある程度の時間またはフレーム枚数を一式として扱う。この一式のデータの中で、参照するピクチャが完結するように定められてある。
この一式のデータは、GOP(Group Of Pictures)と呼ばれている。GOPは、少なくとも1つのIピクチャを含んでいる。番組の途中から視聴する際には、取得したストリームデータが映像を再現できない不完全な位置から始まっている場合でも、次のGOPの始まりからは映像を再現して表示することができる。
例えば、日本の新しい放送方式は、2K放送では0.5秒を目途に、また、4K放送では1秒を目途に、GOPを作成するよう求めている。これによって、テレビの電源投入した際に、または、チャンネルを切り替えた際にも、1秒から2秒で、映像を表示できる。
なお、映像が画面の全体で入れ替わる場合には、切り替わりの前後でGOPを分けた方が、効率が良い。例えば、圧縮率または画像再生などの効率が向上する。画面の全体で入れ替わる場合には、例えば、シーンの切り替わりなどである。そのため、GOP長は、固定した値ではなく、柔軟に運用される。つまり、状況に応じて、GOP長は、変更される。
なお、通信またはネット配信では、日本の新しい放送方式よりも長い単位のGOPが使用されることもある。
記録された映像を再生する際には、表示したいフレームを含むGOPの先頭から映像にアクセスする。これによって、スムーズなランダムアクセスが可能になる。また、早送りなどの際には、GOPごとにIピクチャのみを表示することができる。GOPは、動画として再生できる映像データの一固まりの単位である。また、GOPは、再生が可能な位置を示す単位である。また、GOPは、ランダムアクセスが可能な位置を示す単位である。
放送波Baを受信する際には、PLT(Package List Table)を受信する。PLTは、MMTPパケットとして送られてくる制御信号の1つである。
全ての情報が放送波Baで送られてくる場合には、PLT内の「MMT_general_location_info」で指定された「packet_id」を参照する。そして、この「packet_id」でMMTPパケットをフィルタリングする。これによって、目的とする番組の管理情報を含むMMTPパケットを選択することができる。
ネットワークNeから番組の管理情報を取得する場合には、「MMT_general_location_info」に記載されているIPアドレスとポート番号とによって番組の取得先が指定される。または、「MMT_general_location_info」に記載されているURLによって番組の取得先が指定される。
次に、選択したMMTPパケットの中から、MPT(MMT_Package_Table)を含むデータを選択する。MPTには、番組を構成する映像、音声または字幕などのアセットの組合せと取得先とが記述されている。それぞれのアセットの取得先は、「MMT_general_location_info」に記載されている「packet_id」またはネットワーク情報に示されている。ネットワーク情報は、IPアドレスとポート番号とである。または、ネットワーク情報は、URLである。
また、それぞれの映像、音声または字幕などの時間で同期する必要のあるアセットに関しては、アセットごとにMPUタイムスタンプ記述子とMPU拡張タイムスタンプ記述子とが定義されている。
アセットなどの取得先としては、放送波Baに含まれて送られてくる場合と、ネットワークNeから取得する場合とが定められている。しかし、説明の簡略化のため、以降では放送波Baに含まれて送られてくる場合を一例として説明する。
新しい日本の放送方式では、映像データと音声データとに関しては、MFUに直接NALユニットを格納して送出する方式を採用している。また、新しい日本の放送方式では、「RAP_flag」の付加されたMMTPパケットから次の「RAP_flag」の付加されたMMTPパケットの直前までを、1つのデータの集まりとして取り扱われる。そして、その1つのデータの集まりは、MPUとして取り扱われる。「RAP_flag」は、ランダムアクセス可能なデータの開始点を示す。
これらは、MMTPパケットの「RAP_flag」の有無の調査によって、同一MPUに属していることを識別できる。または、これらは、MMTPパケットの「MPU_sequence_number」によって、同一MPUに属していることを識別できる。この用法でのMPUを、ここでは、仮に「ストリーム伝送単位MPU」と呼ぶ。
この「ストリーム伝送単位MPU」は、ランダムアクセス可能なデータを先頭としている。このため、映像の観点から考えると、GOP単位になっている。つまり、「ストリーム伝送単位MPU」は、MMTPの観点からは1GOPを構成するMMTPパケットの集まりと考えることができる。
前述のMPUタイムスタンプ記述子とMPU拡張タイムスタンプ記述子とは、この「ストリーム伝送単位MPU」に関連付けて、同期する時間の情報を与えている。
MPUタイムスタンプ記述子には、映像または音声などのMPUで、それぞれのMPUの中で最初に再生されるタイミングがNTP(Network Time Protocol)形式の時刻で示されている。NTPは、コンピュータに内蔵されているシステムクロックを、ネットワークを介して、コンピュータどうしの時刻を正しく同期させるためのプロトコルである。
MPU拡張タイムスタンプ記述子には、それぞれのMPUの中のAU(映像の場合はフレーム)ごとに、再生されるタイミングがMPU内での相対的な時間として記述されている。MPU内での相対的な時間は、AU内での先頭からの差分または直前のAUからの差分などである。「差分」とは、2つの値の差のことである。例えば、ここでは、2つの値は時刻である。
これらの記述によって、映像、音声または字幕などの組合せを指定することができる。そして、映像、音声または字幕などの時間的な同期を取りながら再生することができる。
テレビ放送では、PLTおよびMPTは、テレビの電源を入れた後に、短時間で番組を表示できるために、比較的に短い周期で再送されている。新しい日本の放送方式案の場合には、PLTおよびMPTは、100msごとに送られる。
これまで、TLVパケット、TCPパケットおよびMMTPパケットを結合したファイルを記録する方法を説明した。または、TLVパケット、UDPパケットおよびMMTPパケットを結合したファイルを記録する方法を説明した。
しかし、このままでは、再生時刻の情報またはランダムアクセス可能な位置を示す情報などが、ファイル内の各所に分散して記録される。これは、情報へのアクセスにとっては、適していない。また、同じ情報が何度も記録されるため冗長である。
この情報が分散して記録されることは、放送では、どの時点から番組の受信を開始しても、短時間で情報をそろえて、表示を開始する必要があるからである。このため、ストリーム中の各所に分散して情報を持たせている。また、放送では、記録およびランダムアクセスを考慮する必要がないためである。
記録した番組を視聴する際には、頭出し、シーンの検索または編集による映像間の接続などが行われる。そのためランダムアクセスが必要となる。そこで、ランダムアクセスに必要な情報を、情報の記録時または情報の記録後に、独自に作成する。
図5、図6および図7を用いて、ランダムアクセスのためのデータ生成について説明する。
ここでは、MMTPパケット結合したファイルとして映像または音声などを含む映像データを作成する例を説明する。しかし、TLVまたはUDP/IPパケットを使用する場合も同様である。
図5は、パケットの選択と時間の同期とを説明する概念図である。四角で表わしたものが、MMTPパケットである。
図5において、横方向は、データの受信の順番を示している。つまり、横軸Ha方向には、受信された順番にデータが並べられている。受信した順番に左から右に記載してある。
映像のMMTPパケットの「R」と記載されているパケットは、「RAP_flag」が設定されている。そして、GOPの先頭を含んでいる。
図5中において、MPTから引き出されている矢印は、このMPTのMPUタイムスタンプ記述子でそれぞれどのMPUの再生時刻を決めている関係を表している。
例えば、最初に現れるMPT−0は、映像アセットとして、「packet_ID」を指定する。図5では、一例として、MPT−0は、MPU−v0とMPU−v1との再生タイムスタンプを指定している。MPUは、複数のMMTPパケットで構成されている。
また、同じMPT−0は、音声アセットとして「packet_ID」を指定する。図5では、一例として、MPT−0は、MPU−a0とMPU−a1との再生タイムスタンプを指定している。なお、音声のMPUは、1つのMMTPパケットに1つとは限らない。また、音声のMPUは、映像のMPUと同頻度で出現するとも限らない。しかし、作図上、1つのMMTPパケットに1つの音声MPUとしている。また、映像のMPUの出現頻度と音声のMPUの出現頻度とを同程度として描画している。
図5中では、音声、映像および制御情報の3つの流れが書いてある。しかし、実際には、録画再生装置100は、1つのデータの流れとして混在した状態で受信している。
このような異なる種類の情報を、一つのデータとして混在させている状態を多重化されているという。多重化された状態から、「packet_ID」、各種のフラグまたは各種の識別子などを用いて、目的とするデータの流れ(ストリーム)を抽出して、分離することができる。「packet_ID」、各種のフラグまたは各種の識別子などは、それぞれのMMTPパケット付加されている。多重化されたデータから目的のデータを取り出すことを多重化の解除という。
対象とする番組の多重化されたデータの中から、MPTを含むMMTPパケットを抽出する。そして、MMTPパケットからMPTを取り出す。MPTには、番組を構成する各種アセットのリストとその取得方法とが格納されている。
例えば、映像の種類とそのデータを格納している「packet_ID」とを知ることができる。また、音声の種類とそのデータを格納している「packet_ID」とを知ることができる。これらの「packet_ID」で、受信したMMTPパケットを選択し、または、分類する。これらによって、番組を構成する映像データまたは音声データを個別に取出すことができる。つまり、多重化を解除できる。
コンテナフォーマットの目的の一つは、このように、異なるデータを一組にまとめて多重化して取り扱いやすくするものである。コンテナフォーマットは、例えば、MMTまたはMPEG2TSなどである。
図5では、受信したストリームデータをMPTストリーム、映像ストリームおよび音声ストリームの3つのストリームに分けている。
コンテナフォーマットのもう一つの目的は、タイミングを合わせてこれらのデータを再生することである。つまり、コンテナフォーマットのもう一つの目的は、これらのデータを同期して再生することである。
図5では、MPT−0を受信すると、この番組を構成する映像または音声などのアセット情報を得ることができる。さらに、これらのアセットごとにタイムスタンプ情報が記載されている。タイムスタンプ情報は、映像の表示または音声の再生などのタイミングを示す情報である。タイムスタンプ情報は、MPT内に記載されている。タイムスタンプ情報は、アセットごとの「ストリーム伝送単位MPU」の番号に対しての再生時刻である。
例えば、映像に対しては、MPT−0に、MPU−v0の最初のフレームの再生時刻およびMPU−v1の最初のフレームの再生時刻が記載されている。また、MPT−1に、MPU−v1およびMPU−v2のそれぞれの最初のフレームの再生時刻が記載されている。
音声に対しても、同様に、MPT−0に、MPU−a0の再生時刻およびMPU−a1の再生時刻が記載されている。また、MPT−1に、MPU−a1再生時刻およびMPU−a2の提示時刻が記載されている。
ここでは、説明のために、アセットごとに「ストリーム伝送単位MPU」の2つ分のタイムスタンプを持っているものとして説明した。しかし、実際には、さらに多くのタイムスタンプを持たせることもできる。
このようにして、MPUによって「ストリーム伝送単位MPU」の再生時刻を指定することができる。そして、映像と音声とを同期して再生することができる。ここでは説明しなかったが、字幕に関しても同様である。
これらの情報を記録する場合について、図6を用いて説明する。図6は、MMTP方式でのMPUタイムスタンプ記述子を用いた同期方式を説明する図である。図6には、アセットデーブル、タイムテーブルおよびデータファイルが記載されている。データファイルの上側は、データの先頭である。
データファイルには、番組を構成するMMTPパケットが順次記録される。単純に、MMTPパケットを受信順に記録した場合には、映像データ、音声データまたは制御情報等が混在した状態で記録される。ここでは、説明のために「ストリーム伝送単位MPU」ごとにまとめた形で記載している。
例えば、「MPT−0」は、MPTである。そして、受け取られた順番が付されている。「MPT−0」の順番は、「0」であるため、最初に受け取られたことを示している。
例えば、「MPU−v0」は、ビデオストリームとして選択されたMMTPパケットである。MMTPパケットは、MMTPパケットを複数まとめたMPUとして扱っている。そして、受け取られた順番が付されている。「MPU−v0」の順番は、「0」であるため、最初に受け取られたことを示している。
例えば、「MPU−a0」は、音声ストリームとして選択されたMMTPパケットである。音声のMPUは、1つのMMTPパケットに1つとは限らない。また、音声のMPUは、映像のMPUと同頻度で出現するとも限らない。しかし、説明を簡単にするため、音声のMPUが映像のMPUと同じ頻度で発生するとしている。また、音声のMPUは、1つのMMTPパケットに1つとしている。
データファイル中の「R」と記載されているパケットは、「RAP_flag」が設定されている。そして、GOPの先頭を含んでいる。そのため、このパケットからデータを読み始めることによって、効率よく映像を再生できる。
また、不完全なデータを破棄することが低減される。映像データは、GOPを構成している。このため、先頭のIピクチャ部分のデータを取り損ねると後続の何十枚かのピクチャは映像として再現できない。GOPの先頭のデータを取り損ねた場合には、読み取ったデータを破棄しながら、次のGOP先頭が来るのを待つ。このような、データの破棄を低減することができる。このようなデータの破棄は、頭出しまたはランダムアクセス時に、表示の遅延となる。このため、データの破棄の低減によって、スムーズな再生が可能になる。
前述の通り、このように記録したデータファイルは、ランダムアクセスを行うには適していない。
第1には、映像データは可変長データである。このため、目的とする映像を再生するためのデータがどこに存在するのかを特定することができない。第2には、「RAP_flag」が設定されているパケットを直接呼び出すことができない。
そこで、ランダムアクセス用の検索テーブルを用意する。
図6のアセットテーブルには、「packet_id」を格納しておく。「packet_id」を用いて、データファイル内のMMTPパケットから必要なアセットを取りだすことができる。
タイムテーブルには、「RAP_flag」を含むパケットのファイル内での記録位置を格納する。そして、このパケットを含む「ストリーム伝送単位MPU」の指定された再生時間を格納する。そして、これらの情報を再生時間の時系列順に並べておく。
アセットテーブルおよびタイムテーブルの内容は、例えば、MPTに記載されている情報と映像記録再生装置100に記録される際の情報とから作成することができる。
時刻を決めて再生を行う場合について説明する。
例えば、図6において、時刻「0:0:1.00」からの映像を表示する場合には、まず、タイムテーブルの時刻を検索する。そして、時刻が一致する欄からファイル上の位置である「25000000」を読み出す。
そこで、データファイルの位置「25000000」から、データを読み込む。そして、データの再生処理を行う。これによって、指定された位置から、データを再生することができる。
データファイルは、映像データ、音声データまたはその他のデータがパケット単位で混在した状態である。しかし、アセットテーブルまたはMPTを参照して、パケットの分類を行うことによって、映像データまたは音声データ等を分離して再生することが可能である。
再生を開始したい時刻と同一の時刻が、タイムテーブルに無い場合もある。この場合には、タイムテーブルに記載されている時刻から、再生を開始したい時刻に近いものを選び、そこからデータを再生する。
例えは、再生開始時刻として「0:0:1.70」が指定された場合には、タイムテーブルに記載されている「0:0:1.50」と「0:0:2.00」とのうち、指定された時刻に近い「0:0:1.50」を選ぶ。そして、データファイル上の位置「33000000」からデータを再生する。
データファイル上の位置は、例えば、ファイル先頭からのバイト単位での位置である。または、データファイル上の位置は、例えば、ブロック単位での位置である。または、データファイル上の位置は、例えば、セクタ単位での位置である。
特殊再生の場合について説明する。特殊再生は、例えば、早送りまたは巻き戻しなどである。例えば、早送りの場合には、タイムテーブルを順に読み出し、指定された位置からファイルを読み出す。そして、1フレーム分のデータを再生した時点で、次の時刻の位置に移る。これによって、早送りでデータを再生できる。
図7は、タイムテーブルを作成する手順を示すフローチャートである。
日本の放送方式では、MPTは100msごとに再送される。1GOPが0.5秒であれば、その間にMPTを5回受信する。1GOPは、一つの「ストリーム伝送単位MPU」である。
また、1つのMPTの1つのアセットにタイムスタンプを15個格納することが許されている。つまり、タイムスタンプは重複して送出されている。
ステップS7001において、ストリームデータを受信する際に、MMTPパケットを取り出す。そして、MMTPパケットがMPTを含む場合には、タイムスタンプ処理を実施する。
ステップS7002において、MMTPパケットからMPTを取り出す。そして、アセットごとの「ストリーム伝送単位MPU」のシーケンス番号とタイムスタンプ情報との組合せを取り出す。
ステップS7003において、タイムスタンプ情報の重複を取り除く。前述のように、タイムスタンプ情報は重複して送出されているためである。この時点で、「ストリーム伝送単位MPU」のシーケンス番号と再生時刻を示すタイムスタンプのリストとが得られる。
このフローチャートには含まれていないが、並行して映像データまたは音声データを含むMMTPパケットは、順次、データファイルとして内蔵記憶装置51または光ディスク53に記録される。そして、データファイル上の位置は記録時に判明する。
ステップS7004において、「RAP_flag」が設定されているMMTPパケットを記録する際に、このパケットのファイル上での位置と、このMMTPパケットが属する「ストリーム伝送単位MPU」のシーケンス番号とを取り出す。タイムスタンプのリストの中で、同じ「ストリーム伝送単位MPU」のシーケンス番号を持つタイムスタンプ情報に、ファイル上に記録した位置の情報を追加する。
ステップS7005において、これらの処理が終了したか否かを確認する。処理が終了していない場合には、「no」を選択して、ステップS7001に進む。処理が終了した場合には、「yes」を選択して、ステップS7006に進む。
ステップS7006において、内蔵記憶装置51または光ディスク53に作成したデータを書き込む。
このようにして、タイムテーブルを作成することができる。
ここでは、GOPごとに設定されているMPUタイムスタンプ記述子のタイムスタンプ情報を使って、ランダムアクセスを実現している。GOPは、「ストリーム伝送単位MPU」である。そのため、データの再生を開始できる位置は、GOP単位となる。つまり、0.5秒または1秒などの単位でしか再生位置を指定できない。例えば、時間指定による頭出し、早送りまたは巻き戻し等の場合には、この程度の精度で十分である。
しかし、内蔵記憶装置51または光ディスク53などに記録した後に、編集などを行う場合には、GOP単位での位置指定では不十分である。例えば、同一番組の別の位置どうしを組み合わせ連続して再生する場合、または、別の番組どうしを組み合わせ連続して再生する場合などである。このような組み合せによって、お気に入りシーン集などを作成することができる。
そこで、MPT内のMPU拡張タイムスタンプ記述子を利用する。
図8は、フレーム単位の時刻で検索できるタイムテーブルを示す図である。
図8に示したタイムテーブルは、通常のタイムテーブルを拡張して、フレーム単位の時刻で検索できるようにしたタイムテーブルである。図8に示すタイムテーブルは、再生時刻、ファイル上のデータの位置およびAU番号の情報を持つ。
AU番号は、同一の「ストリーム伝送単位MPU」に属するデータの中の何番目のAUであるかを示す。映像データの場合には、AUはピクチャに相当する。しかし、デコードの効率のために、GOP内でのAUの並びの順は、ピクチャの表示順とは必ずしも一致していない。
このタイムテーブルでは、再生時刻の順番で並べられている。このため、AU番号は、前後している。つまり、AU番号は、順番に並んでいない。
MPU拡張タイムスタンプ記述子には、それぞれの「ストリーム伝送単位MPU」内のAUに対して、最初に表示されるAUからの差分で再生時刻が与えられている。または、MPU拡張タイムスタンプ記述子には、それぞれの「ストリーム伝送単位MPU」内のAUに対して、再生時刻の間隔が与えられている。
そこで、MPUタイムスタンプ記述子の再生時刻と、MPU拡張タイムスタンプ記述子の差分時刻から各AUの再生時刻を算出することが出来る。または、MPUタイムスタンプ記述子の再生時刻と、MPU拡張タイムスタンプ記述子の再生時刻の間隔とから各AUの再生時刻を算出することが出来る。
なお、図8では、説明のために、一例として、100分の1秒単位で記載してある。
MPU拡張タイムスタンプ記述子の中では、タイムスケール(timescale)として、1秒を分割する数を定義している。そして、各AUの再生時刻は、このタイムスケールを用いて表記する。映像で使用されるフレームレートは、毎秒60枚または毎秒24枚である。そして、1フレームを秒の小数単位で表記しようとすると、割り切れず、誤差が発生する。このため、タイムスケールを用いる。そこで、タイムテーブルのフレーム単位での時刻欄に、このタイムスケールを用いた値を採用することもできる。
GOPの途中からデータの再生を開始したい場合でも、デコードは必ずGOPの先頭から行う。そのため、データの読み込み開始位置は、同一の「ストリーム伝送単位MPU」内では同一となる。
このタイムテーブルを使ってデータの再生する場合の一例を説明する。
時刻「00:00:01.04」を指定して検索した場合には、この時刻に相当するピクチャは存在しない。このため、直前のピクチャとなる「00:00:01.03」のピクチャから再生を行う。
タイムテーブルを参照すると、このピクチャは、ファイル上の位置「25000000」から始まる「ストリーム伝送単位MPU」のAU番号2のAUである。つまり、このピクチャのAUは、3番目のAUである。
そこで、ファイル上の位置「25000000」から読み出しを開始すると共に、デコードを開始する。1番目のAUのデコードが完了して、ピクチャのデータが作成される。この後に、この作成されたピクチャを表示しない。そして、差分情報しか持たない後続のAUのデコードを行う。そして、3番目のAUのデコードが完了した後に、この3番目のAUの映像から再生を開始する。このようにして、GOPの途中からデータ(映像)の再生を行うことができる。
この例では、詳細な情報を持つタイムテーブルを1つ用いて再生するようにした。しかし、例えば、前述の早送り再生の場合などでは、必ずしも効率の良い方法とはいえない。そこで、標準のタイムテーブルと詳細なタイムテーブルとの2段階で検索を行う方法を取ることもできる。
日本の新しい放送方式では、MPU拡張タイムスタンプ記述子は、AU間の再生間隔を指定している。その間隔は、60分の1秒または120分の1秒である。この間隔は可変である。しかし、番組内では同一フレームレートを用いている。そのため、詳細なタイムテーブルを用いずに、計算によって各フレームの再生時刻を求めることが出来る。
この場合には、図6に示した「ストリーム伝送単位MPU」ごとのタイムテーブルを利用して検索する。そして、再生を開始したい時刻を含む「ストリーム伝送単位MPU」を特定する。そして、この再生時刻と再生を開始したい時刻との差を求める。この時刻の差とフレームレートとから、この「ストリーム伝送単位MPU」内の表示順で、何枚目のピクチャであるのかを求めることが出来る。
指定された時刻にフレームがない場合には、表示の順番で指定時刻の直前のフレーム、または直後のフレームとする。つまり、指定時刻の直前のフレーム、または直後のフレームを採用する。
前述のように、AUの並び順とピクチャの再生時刻の順番とが異なる。しかし、「ストリーム伝送単位MPU」の先頭からデコードを開始する。そして、算出された再生の順番を持つピクチャのデコードが完了する。デコードが完了したピクチャから再生を開始する。これによって、ピクチャ単位の精度での頭出しを行うことが出来る。
ここで、説明したタイムテーブルを別ファイルとして作成して録画を行った場合には、番組内容を記録するデータファイルにタイムスタンプを記録する必要はない。
MPTは、タイムスタンプ以外の制御情報を含んでいる。例えば、MPTは、アセット情報などを含んでいる。タイムスタンプは、例えば、MPUタイムスタンプ記述子またはMPU拡張タイムスタンプ記述子などである。つまり、MPTは、MPUタイムスタンプ記述子またはMPU拡張タイムスタンプ記述子以外にも、アセット情報などのタイムスタンプ以外の制御情報を含んでいる。
しかし、これらの情報は、番組の途中で変更される性格のものではない。このため、別ファイルなどで1箇所に記録しておくことで、MPTそのものは記録を省略することが出来る。例えば、図6では、アセットテーブルとして管理情報(Packet_id)を保持している。
MPTが単独でMMTPパケットに格納されている場合には、データファイルにMMTPパケットを記録する際に、MPTを格納したMMTPパケットを記録する必要がなくなる。
MPTが他の管理情報と一緒にMMTPパケットに格納されている場合には、MPTを除いた管理情報でMMTPパケットを再構成する。そして、再構成されたMMTPパケットを記録することが出来る。
MPUタイムスタンプ記述子またはMPU拡張タイムスタンプ記述子は、放送時には重複度の高いデータである。このため、省略することが出来れば、記録するデータサイズを小さくすることが可能となる。
前述では、MPTを記録する必要はないとした。しかし、MPTを映像ストリームまたは音声ストリームなどのストリームを含むMMTPパケットと一緒に記録しておいた方が便利なこともある。
例えば、多重化解除部21とデコード部31,32,33,34とが一体となったLSIを用いてデコード処理を行う場合には、MPTを含んだデータを多重化解除部21に入力することで、多重化解除、デコードおよび同期処理を一括して行うことができる。
また、フレーム単位の頭出しを行う場合にも、「ストリーム伝送単位MPU」の前または先頭にMPTがあれば、このMPTを参照して、再生を開始する前に、フレーム単位での再生時刻を求めて頭出しを行うことが出来る。MPTは、「ストリーム伝送単位MPU」の先頭付近にあってもよい。
この場合にも、テレビ局から送信されてきたMPTの全てを記録する必要はない。MPTの一部だけを記録することで処理することも出来る。
図9は、MMTP方式でのMPUタイムスタンプ記述子を用いた同期方式を説明する図である。図9では、「ストリーム伝送単位MPU」の直前にMPTを格納している。タイムテーブルには、「ストリーム伝送単位MPU」の先頭の位置ではなく、このMPTの位置を示している。
従来のブルーレイディスクの記録方式では、これらのタイムテーブルに相当する情報としてクリップファイル内に「EP_map」を格納していた。しかし、「EP_map」は、固定長パケットとパケットごとのタイムスタンプを持つMPEG2TSを前提とした構造になっている。そのため、そのままではMMTのデータに適用できない。
そこで、前述のタイムテーブルを「EP_map」の代わりに使用する。これによって、MMTのデータをブルーレイディスクに記録した際に、データアクセスを容易にすることができる。
この例では、MMTPパケットを結合して記録する説明を行った。しかし、TLVパケット、IPパケットまたはUDPパケットのそれぞれの状態で、パケットを結合して記録することもできる。また、タイムテーブルを拡張して、アセットごとに記録することも可能である。つまり、映像データまたは音声データの読み出し開始位置を検索できるようにする。そして、MFUの羅列としてデータを結合して記録する。
[標準フォーマットを用いて記録する場合]
MMTでは、前述のように伝送フォーマットとは別に、蓄積フォーマットが規定されている。MMTの蓄積フォーマットでは、BMFF(ISO/IEC 14496−12 ISO Base Media File Format)形式をベースに、データを格納する。この場合には、データのレイアウトは、図3に示された論理構造をしている。図3は、データの論理構造を示した図である。
このデータの塊は、MPUと呼ばれている。このMPUは前述の「ストリーム伝送単位MPU」とは異なるものである。ここでは、仮に「番組蓄積用MPU」と呼ぶ。「番組蓄積用MPU」は、通常ファイルとして格納され、管理されている。
図3の論理構造を用いて「番組蓄積用MPU」の構造を説明する。
MPUメタデータは、ファイルの管理データ、アセット情報、各種パラメーターまたはヒント情報などを含んでいる。アセット情報は、映像データと音声データとの組み合わせなどを管理する情報である。各種パラメーターは、デコーダーの動作モード等を設定するためのパラメーターである。ヒント情報は、MPUファイルに格納されたMFUからMMTPパケットを再構成するための情報である。
ムービーフラグメントメタデータは、再生時間で区切られた映像データまたは音声データなどにアクセスするための情報である。また、ムービーフラグメントメタデータは、映像データまたは音声データなどを再生するための情報である。
実際の映像データおよび音声データは、MFUの羅列として格納されている。1つのムービーフラグメントメタデータとそれによって管理される一塊のMFUとは、まとめてムービーフラグメントと呼ばれている。一般的には、複数のムービーフラグメントで1つのコンテンツを構成している。ネットワークストリーミング等では、一般的には、1フラグメントは10秒から15秒で構成されている。
MPUメタデータおよびムービーフラグメントメタデータが放送波Ba等で送られてくる場合には、これらを利用してMPUを構成することができる。PLT、MPT、その他の制御情報またはMFUを取り出すまでの各種ヘッダ情報は、冗長になるため、記録する必要はない。
一方、新しい日本の放送方式案では、MPUメタデータおよびムービーフラグメントメタデータは、放送時に送出されない。そのため、PLT情報、MPT情報および各種のヘッダ情報を組み合わせて、独自にMPUメタデータ等を作成する。
光ディスク53への記録にも、上記の蓄積フォーマットを使用することを考える。光ディスク53では、物理的に連続して格納されたデータを比較的高速に読み出すことが可能である。しかし、光ディスク53上の直径方向に離れた位置にあるデータを読み出す場合には、ヘッドシークを伴うため、データを読み出しに時間を要する。つまり、光ディスク53では、前後して使用される可能性の高いデータを、連続した領域またはディスク53上の近い位置に配置した方が、効率よくデータを読み出すことが可能になる。
図3に示された論理構造そのままのデータ配置で、データを記録すると、MPUメタデータ、ムービーフラグメントメタデータおよびMFUが、物理的な配置として分散して格納される。MPUメタデータは、再生に必要なデータである。MFUは、映像データを格納している。このため、光ディスクの特性上、図3に示された論理構造のままのデータ配置は、不利なデータ配置となる。
多くのファイルシステムでは、蓄積されるデータの論理構造と物理配置とを別々に管理することができる。ブルーレイディスクで採用しているUDFも同様である。
そこで、論理構造は規格通りとして、物理配置では、MPUメタデータとムービーフラグメントデータとをまとめて記録する。
図3の物理配置に示したデータ構造は、光ディスク上の物理的なデータ配置として、管理情報をまとめて配置した例である。このようなデータ配置とすることで、MPUメタデータとムービーフラグメントメタデータとを一度に読み込むことが可能となる。
なお、「データ構造」は、ここでは、ファイルシステムよりも上位からみた構造を示している。例えば、論理的なデータ構造、ディレクトリまたは1つのファイル内でのデータの並びなどである。一方、「データ配置」は、ファイルシステムよりも下位から見た配置を示している。例えば、物理的なデータのレイアウトなどである。ファイル名とファイル名とで結び付けられたブロック、または、データのつながりを示すブロック同士のリンク情報などで構成されている。この場合には、ブロックは、ディスク上の物理的な位置と結びついて管理されているデータの集合である。ファイルシステムによっては、他の名称が用いられる事もある。
そして、図3の物理配置に示したデータ配置は、ヘッドシーク回数を減らす。そして、図3の物理配置に示したデータ配置は、再生を開始する際にかかる時間およびランダムアクセスの際にかかる時間を短くすることができる。
また、論理構造と物理配置とを分けて考えることはせずに、単純に管理情報のコピーを別ファイルにもたせることも考えられる。図3に示した追加クリップファイルは、そのような場合の一例である。この場合には、例えば、ランダムアクセスを容易にするための追加情報等を、ファイルに追加することも可能である。
これまで示した例では、フラグメントを用いたデータ構造の例で説明した。しかし、フラグメント単位での送出を想定しない場合には、ムービーフラグメントメタデータをもたないデータ構造での記録も可能である。
BMFFによるファイルフォーマットでは、管理情報とストリームデータとは、同一ファイルにまとめて記録されている。一方、従来のブルーレイディスクの記録方式では、管理情報とストリームデータとは、分けて管理されていた。
これは、管理情報をまとめて読み込み、再生するデータにあわせて機器を設定した後に、ストリームデータの再生を行うことが、光ディスクの機器に適しているためである。管理情報とストリーム情報とは、光ディスク上では、領域を分けて記録されている。また、管理データは光ディスクの損傷に備えて、光ディスク上に2重に記録して、バックアップデータとしているためでもある。このバックアップデータは、光ディスク上の離れた位置に記録されている。
BMFFにおける管理データは、ブルーレイディスクでは、主にクリップファイルで管理されている情報である。そこで、BMFFとして記録する際に、番組の管理データ部分をファイルシステム上の別ファイルから参照する。つまり、見かけ上、番組の管理データ部分を別のファイルとすることができる。
図10は、BMFFとしてストリームデータを記録した場合の説明図である。
図10に示したのは、BMFFとしてストリームデータを記録した場合の例である。
物理的な配置としては、管理データは、光ディスク53上の管理データ領域に記録される。ストリームデータ部分は、光ディスク53上のストリームデータ領域に記録される。
ストリームファイルとして、このデータにアクセスする際には、ファイルシステムが管理データ部分とストリームデータ部分とを関連付けて、論理的に1つのBMFFファイルとして見えるようにする。
一方、ブルーレイディスクの管理データであるクリップファイルとしてこのデータにアクセスする際には、BMFFファイルの管理データ部分のみをファイルとして見えるようにする。クリップファイルは、ブルーレイディスクの管理データである。
このような配置とすることによって、MMTの標準記録フォーマットとしてBMFF形式のファイルを作成することができる。また、ブルーレイディスクの管理方法とも整合性のあるデータ形式とすることができる。
このようにして、BMFFとして記録されたデータのヘッダ部分を、別のファイルとして参照できるようにすると、光ディスク53上でのデータ管理においても有利になる。また、管理データのバックアップデータの作成も容易になる。
例えば、PCなどで映像データを取り出す際には、BMFFファイルをコピーすれば管理情報とストリームデータとの両方を含むBMFFファイルとしてコピーできる。一方、光ディスク内の管理情報のバックアップを作成する際には、BMFFCLIPファイルからコピーを作成すれば、バックアップの必要な管理データ部分のみのデータがコピーできる。
また、管理データとストリームデータとを分けて保管している光ディスクのフォーマットに合わせて、BMFFの管理データ部分を光ディスク53の他の管理データを格納している領域に格納できる。このため、再生を準備する際のヘッドシーク量を減らすことが出来る。
≪(B)多重化が解除されたエレメンタリーストリームSeの状態でのデータの記録≫
前述の例では、受け取ったデータに対して、部分的に多重化を解除ながら、蓄積用フォーマットに変換する方法について説明した。受け取ったデータは、放送波Ba、外部装置EiまたはネットワークNeなどから受け取ったデータである。
しかし、多重化解除部21がハードウェアとして作られている場合などには、映像または音声などに分離されたES(Elementary stream)の状態で取り出して、記録することができる。なお、ESは、図1ではエレメンタリーストリームSeとして示されている。
ESは、圧縮された映像データのストリームまたは音声データのストリームである。ESは単位ごとに区切られるが、ここで「単位」は、処理する上で意味のある単位である。この単位は、例えば、映像データの場合にはピクチャあるいはNALである。また、この単位は、例えば、音声データの場合にはブロックである。
以下において、映像記録フォーマットは、ISO BMFFを例に取って説明する。
BMFFにおいて、多重化された状態でデータを記録する方式では、時間の流れを持ったデータを管理するデータをトラックと呼ぶ。
前述の多重化が解除されていない状態で記録する方式では、トラックは1つである。これは、例えば、映像データと音声データとが多重化された状態であるため、時間の流れを持ったデータは、多重化ストリームSmの1つである。多重化ストリームSmは、MFUの羅列として表現されている。
一方、エレメンタリーストリームSeの状態では、例えば、映像データと音声データとは分離されたESストリームデータとして存在する。そのため、映像データのトラックと音声データのトラックとを個別に作成する。映像データのトラックと音声データのトラックとは、データファイル上の管理データを格納する領域に記録される。そして、映像データと音声データとは、メディアデータを格納する領域に格納される。
それぞれのトラックは、再生時刻を示している。また、それぞれのトラックは、再生時刻に対応したメディアデータを格納する領域の位置を示している。メディアデータは、映像データまたは音声データなどである。
そして、映像データと音声データとは、時間的に同期を取った状態で関係付けがされる。また、字幕なども、同様に、表示タイミングを含めて関係付けがされている。
新しい日本の放送方式案では、MMTPパケットのMTP内に、番組内で使用される映像、音声または字幕などの組合せが示されている。また、MMTPパケットのMTP内に、映像、音声または字幕などの表示タイミングまたは再生タイミングが示されている。また、MMTPパケットのMTP内に、映像、音声または字幕などのデータの格納位置が示されている。
番組を構成する(データ放送の部品等)データファイルなどをMMTで送る場合には、1つのファイルを1つのMPUに格納する。このMPUを「データ要素MPU」と呼ぶ。そして、この1つの「データ要素MPU」を分割して、MFUとしてMMTPで送付する。この場合には、MPUヘッダまたはMPUメタデータも同時に送付される。
また、映像または音声などのストリームデータでは、オーバーヘッドを回避するために、データ要素MPUを使用しない。その代わりに、AUまたはNALを直接MFUに入れてMMTPで送付する。
しかし、新しい日本の放送方式案の時間管理では、ランダムアクセスフラグの単位でMPUを構成することになっている。時間の指定は、MPUに対して行う。このため、1つのGOPで0.5秒から1秒の単位であれば、時間指定の単位として問題はない。この場合には、MPUヘッダまたはMPUメタデータ等は送付されない。このランダムアクセスフラグを区切りとした一式のMMTPパケットの集合を、前述の通り、ここでは、仮に「ストリーム伝送単位MPU」と呼んでいる。
また、多重化されたデータを受信して、ファイルに記録する。このファイルに記録する際に用いられるデータ構造もMPUである。例えば、ファイルに記録する際に、番組全体で1つのMPUとすることができる。この用法でのMPUを、ここでは、仮に「番組蓄積用MPU」と呼ぶ。また、ストリーム伝送単位MPU単位で記録することもできる。この場合には、MPUのファイルの数が膨大になる。また、ストリーム伝送単位MPUを束ねてMPUに格納することもできる。このストリーム伝送単位MPUを束ねたMPUを、ここでは、仮に「番組蓄積用MPU」と呼ぶ。
日本の新しい放送方式の場合には、GOP単位で「ストリーム伝送単位MPU」を構成している。MPT内の「MPUタイムスタンプ記述子」によって、先頭のフレームの表示時刻が指定されている。ここでの時刻は、NTP時刻である。「拡張タイムスタンプ記述子」によって、GOP内の後続のフレームの表示時刻が指定されている。後続のフレームの表示時刻は、先頭のフレームの表示時刻からの差で示される。
多重化が解除されエレメンタリーストリームSeが取り出された状態ではMPTが取り除かれている。そのため、MPTとその他の制御情報とを組み合わせて、トラックなどの管理情報を作成して、記録する必要がある。トラックは、時間の流れを持ったデータの管理情報である。時間の流れを持ったデータは、例えば、映像データまたは音声データなどである。トラックは、データの種類、再生時刻または実際のデータの記録位置へのポインタなどを含んでいる。これらのデータは、前述のタイムテーブルの作成と同様の手順で作成することが出来る。
トラックでは、細かな時間単位でデータの取り出し位置を指定することが出来る。そのため、再生時間の順番またはデコード時間の順番に、映像データと音声データとを混在させて並べることが出来る。このような構造を取ることによって、同時に再生する必要のある映像データと音声データとを、ヘッドシークを抑えて取り出すことができる。
このようにして、MMTで送出された番組を、BMFF形式のファイルとして記録することが出来る。
実施の形態2.
実施の形態2では、MMTPパケットを順次記録する。MMTPパケットは、受信した放送を番組レベルで選別したものである。
1つの送信機から送信されるデータは、複数の放送局の複数の番組を多重化できるように作られている。そのため、ユーザーが特定の番組を視聴し、または録画する場合には、放送局のレベルでの分離と、番組のレベルでの分離とが必要となる。
ここでは、番組のレベルまでの分離が完了しており、録画の対象となる1つの番組を構成するMMTPが順次取り出されて、記録されているものとする。この状態は、部分的にデータの多重化が解除されている状態である。つまり、番組の単位までは多重化が解除されている。しかし、番組を構成する個々の映像、音声、字幕ストリームまたは制御データは多重化されている。
図11は、MMTP方式でのMPTによる多重化の解除を説明する説明図である。図12は、タイムテーブルと映像データの関係を説明する説明図である。図13は、MMTP方式でのMPTデータの構造の例を説明する図である。図14は、映像を中心に考えた場合のアライメントを説明する説明図である。
図11に示したMMTストリームは、番組を構成するMMTPパケット列の例である。このMMTストリームでは、例えば、映像、音声および字幕などが、それぞれ一本ずつ多重化されている。実際の放送では、複数の映像、音声および字幕などが多重化されることもある。
映像、音声および字幕などは、番組を構成する要素である。これらの番組を構成する要素をアセットと呼ぶ。MMTストリームは、MMTPパケットの単位で多重化されている。このため、MMTストリームには、サービスインフォメーションのパケットとアセットデータのパケットとが混在している。
サービスインフォメーションのパケットは、多重化ストリームのための制御信号である。サービスインフォメーションは、例えば、映像、音声または字幕を分離するための制御情報である。また、サービスインフォメーションは、映像、音声および字幕を同期して再生するための制御情報である。そして、サービスインフォメーションは、各アセットの名称を表示するための情報である。
アセットデータのパケットは、例えば、映像、音声および字幕のアセットを構成する。実施の形態2では、記録媒体の上にこれらのパケットを順次記録する。ここでは、簡単のため、ファイルとしてMMTストリームを構成するこれらのパケットを順次記録することとする。
図11に示すように、MMTストリームは、制御パケットSI(MPT)、映像パケットV、映像パケットV(RAP)、音声パケットAおよび字幕パケットTを含んでいる。制御パケットSI(MPT)は、でMPTの付いている制御パケットである。制御パケットSI(MPT)は、サービスインフォメーションの一種である。映像パケットV(RAP)は、RAPフラグの付いている映像パケットである。
実際には、制御パケットSIとして多くの種類のものが送信されている。しかし、ここでは、説明を容易にするために、MPTに注目して記載してある。MPTは、放送規格では約100ms間隔で定期的に送信することになっている。
MMTストリームを先頭から順次再生する場合には、MMTストリームを記録したファイルの先頭からデータを順次取り出す。そして、順次、MMTストリームを多重化解除部21に送り込むことで、データの再生を行うことができる。例えば、図1に示す多重化ストリームSmとして多重化解除部21に入力する。
多重化解除部21は、受け取ったデータを順次解析する。多重化解除部21は、MPTを含むデータパケットを受け取ると、MPTの記述にから多重化解除および映像を表示するタイミング等に用いる情報を取り出す。そして、多重化解除部21は、多重化解除部21およびデコード部31,32,33,34の設定を行う。
図13に、MPTに記述されているデータの一例を示す。図13に示すデータは、ARIB規格STD−B60に基づいている。例えば、MPTには、複数のアセットを取りだすための情報が記述されている。各アセットは、MMT内の識別情報によって、データを取得するための情報とデータを分離するための情報とを得る。MMT内の識別情報は、例えば、ロケーション情報(MMT_general_location_info())である。
また、図13では省略してあるが、コンポーネント記述子の情報から各アセットのストリームの詳細情報を得ることができる。この情報を基に、図11に示したように、多重化されている各種ストリームを分離して、再生する。
放送を記録する場合にも、図11のMMTストリームのデータは、ファイルに順次記録される。そして、MMTストリームのデータは、ファイルの先頭から順次取出されて再生される。この場合には、必ずしも、MMTパケットそのものである必要はない。MMTパケットの内部のデータが取り出された状態で記録されてもよい。また、逆に、IPパケットの状態またはTLVパケットの状態で記録されてもよい。
次に、ランダムアクセスを考える。ここでは、一例として、時刻指定ジャンプを説明する。しかし、チャプターサーチおよび早送り巻き戻しなどでも同様である。
図12を用いてランダムアクセスの動作について説明する。タイムテーブルTMは、番組上の時刻情報と、その時刻情報に対応する再生位置とを対応付けるデータである。再生位置は、ここでは、MMTストリームのデータを記録したファイルの先頭からのオフセットとして説明する。しかし、再生位置として、セクタアドレスまたはブロックアドレスなどが用いられることもある。
このタイムテーブルTMを用いて、時刻に対応した再生位置からデータを取り出して再生する。これによって、時刻指定ジャンプを行うことができる。つまり、時刻を指定した再生を行うことができる。
通常、映像データはGOP単位で構成されている。GOPは、例えば、0.5秒から1秒間程度の映像をまとめて圧縮したものである。GOPは、例えば、数十枚の画像を含んでいる。1つのGOPは、1枚から複数枚の完全な画像と、数十枚の差分画像とを含んでいる。GOPは、圧縮された差分画像を含んでいるため効率が良い。
また、表示される順番とデコードされる順番とは、必ずしも対応していない。そのため、GOPの途中から再生したい場合でも、必ずGOP先頭からデータをデコードする必要がある。そのため、MMTPパケットでは、GOPの先頭に、RAPフラグを付けることができる。RAPフラグは、ランダムアクセスが可能であることを示すフラグである。図12では、このRAPフラグの付いているパケットの位置を、GOPの先頭としてタイムテーブルに格納している。そして、これによって、ランダムアクセスを実現している。
1枚の画像データから完全な画像を再現できる画像データをIピクチャと呼ぶ。Iピクチャは、1つのGOP内に必ず1つ存在する。しかし、1つのGOP内に複数のIピクチャが存在することもある。Iピクチャのうち、他の画像との依存関係から、GOP内で最初にデコードされるIピクチャはIRAPと呼ばれている。このIピクチャから再生することで、後続の画像データを正しく表示できる。
MMTPパケットのRAPフラグは、IRAPの画像データの先頭パケットまたは制御パケットに付けられている。1つのIピクチャとの差分データで構成された画像データはPピクチャと呼ばれている。参照先のIピクチャと、Pピクチャの画像データとを合成することで、このPピクチャの画像を再現できる。複数の他の画像を参照して画像を再現できる画像データをBピクチャと呼ぶ。
映像データと同様に、音声データでも一つのかたまりのデータの先頭の概念が存在する。そして、音声データの先頭にRAPフラグが付けられている。しかし、説明を単純にするために、ここでは映像データのGOPの区切りで音声データパケットも区切る。
図12に示すランダムアクセスの動作を、図11に示すパケットレベルでの読み出しに対応して考えてみる。
タイムテーブルTMから再生位置の情報を取出す。そして、図11のMMTストリームの位置Pからパケットを取り出して再生を行う。位置Pは、最初の映像パケットV(RAP)の位置である。この時点では、MPT情報が取得できていない。そのため、映像、音声および字幕などアセット単位での分離を行うことができない。
順次読み出しが行われて位置Pで制御パケットSI(MPT)が読み出される。これによって、アセットを分離するためのパラメーターが取得される。つまり、映像、音声および字幕などを分離することができる。
この時、位置Pから位置Pまでのデータが分離できず、結果として読まれなかった場合には、GOPの先頭のデータが失われることになる。そして、このGOPをデコードすることができない。
位置P以降は、位置Pで既に取得済みのMPT情報があるためデコードが可能となる。位置Pは、位置Pの次のGOPの先頭である。そのため、本来、再生を開始したいGOPからではなく、次のGOPから再生されることがある。
同一の番組内でのチャプターサーチまたは早送り等の場合において、再生に使用していたMPTのアセット情報がジャンプ先のMPTのアセット情報と一致する場合には、ジャンプ先の先頭である位置Pから始まるGOPから再生することが可能である。しかし、コマーシャル(CM)または番組の変更などを挟んで番組を再生する場合には、ジャンプ前のMPTとジャンプ後のMPTとでアセットが同一である保証はない。または、録画済みの異なる番組を繋いだ編集がされている場合には、ジャンプ前のMPTとジャンプ後のMPTとでアセットが同一である保証はない。
また、アセットの変更が行われる場合には、放送規格案は、実際のデータが再生される0.5秒前からMPTを更新するように求めている。これは、例えば、アセットを分離するためのフィルタの設定などには時間がかかる。また、音声が切り替わる時のミュート処理などには時間がかかる。また、映像が切り替わる時のミュート処理などには時間がかかる。これらのために、実際のデータが切り替わる直前のタイミングでMPTを変更しても、フィルタの切り替え又はミュート等を行うための処理が間に合わない可能性があるためである。
これは、ランダムアクセスの時も同様である。ジャンプ先ですぐにMPTを取得することができても処理系の切り替えが間に合わず、最初のGOPを正しく表示できない可能性がある。または、データの切り替えに必要な時間を確保するために、表示を遅延させる必要がある。ここで、「処理系」とは、例えば、多重化解除部21およびデコード部31,32,33,34等である。
そこで、この実施の形態2では、図12に示したように、まず、MPTの情報をタイムテーブルTM内に格納する。そして、時刻を指定してジャンプをする時には、MPTの情報を多重化解除部21およびデコード部31,32,33,34に設定する。その後、再生を開始する位置のデータを読み出す。
このようにすることで、シークなどのデータの読み出しの準備と並行して、処理系(多重化解除部21およびデコード部31,32,33,34等)の切り替えを行うことがでる。そして、データの切り替えに必要な時間を短縮することができる。
この例では、MPTそのものをタイムテーブルTMに格納している。他の方法として、MPT内に記載されているアセットを分離するための情報と、GOPの表示開始の時刻とを、タイムテーブルTMに格納する。GOPの表示を開始する時刻をタイムテーブルTMの時刻として使用することもできる。このように、アセット情報を取出してタイムテーブルTMに格納する方法がある。
また、他の方法として、別のテーブルにMPTまたはアセット情報を記録する。そして、タイムテーブルTMには該当するMPT情報またはアセット情報への参照を持たせる方法がある。また、参照ではなく、同一の時刻で検索できる別のタイムテーブルを用意して、そちらにMPTまたはアセット情報を記録する方法がある。MPTには複数GOPの表示開始の時刻が格納されている。これらの一部またはすべてをタイムテーブルTMに格納しても良い。
同様に、HDRパラメーター等によってテレビの制御を変更する場合でも、バックライトの輝度の変更または液晶の駆動電圧の設定変更に時間がかかる場合がある。その場合には、HDRパラメーター等をタイムテーブルTMに格納する。これによって、事前にテレビの制御を行うことが可能となる。図12では、タイムテーブルTMのメタデータ領域が、これらのパラメーターを格納する領域の一例として示されている。
特殊再生を行う場合には、GOP内でIRAP画像(IRAPピクチャ)のみを再生して、他の画像を表示しない場合がある。特殊再生は、例えば、早送りまたは巻き戻し等である。IRAP画像は、デコードの順番で最初の画像である。また、IRAP画像は、データ配置の順番でもGOPの先頭に置かれる。つまり、IRAP画像は、GOPの先頭に位置している。また、IRAP画像は、他の画像に依存しない。このため、IRAP画像は、単独でデコード可能である。この場合には、IRAP画像の位置は、タイムテーブルTMから読み取れる。
しかし、効率よく読み飛ばすためには、IRAP画像の末尾がわかる方が便利である。そこで、IRAP画像のサイズまたはIRAP画像の末尾をタイムテーブルTMに格納する。これによって、効率よく特殊再生を行うことができる。図12では、タイムテーブルTMのIRAPサイズ欄がこのデータを格納する領域の一例として示されている。
映像を構成する画像データがスライスとして記録されている場合には、スライス単位でデータにアクセスできた方が良い場合がある。「スライス」とは、画像データがデコード可能な状態で分割されていることである。特殊再生用として考えた場合には、例えば、GOP内のIRAP画像の特定のスライスのみを再生して、他のスライスを表示しない方法がある。特殊再生は、例えば、早送りまたは巻き戻しなどである。
この場合には、GOPの先頭にあるIRAP画像のデータとスライスとの各々の位置およびサイズをタイムテーブルTMに格納するこれによって、効率よく特殊再生を行うこと可能となる。図12では図示していないが、例えば、タイムテーブルTMのIRAPサイズ欄を拡張して、このデータを格納することができる。
早送り、巻き戻しをなめらかに行うために、IRAP画像に加えて、GOPに含まれている非IRAPのIピクチャまたは非IRAPのPピクチャを表示することもある。この場合には、IピクチャおよびPピクチャの各々の開始位置、サイズまたは末尾の位置をタイムテーブルTMに格納する。これによって、効率よく特殊再生を行うことが可能となる。
図12では図示していないが、例えば、タイムテーブルTMのIRAPサイズ欄を拡張して、これらのデータを格納することができる。または、別途、Iピクチャ用またはPピクチャ用の位置、サイズまたは末尾の位置を示すテーブルを用意する。そして、タイムテーブルTMには、このテーブルへの参照を格納することもできる。
次に、HDDまたは光ディスク等のディスクデバイスに、この実施の形態2でのMMTストリームを格納することを考える。
多くのディスクフォーマットでは、固定サイズのデータブロックをアクセス単位としている。このアクセス単位は、セクタ、ブロック、クラスタまたはページ等と呼ばれている。ここでは、単に「ブロック」と呼ぶ。例えば、ブルーレイディスク規格では6144Byteをアラインドユニット(Aligned Unit)と呼び、1つの記録単位として取り扱う。また、ブルーレイディスク規格およびUDF規格では、1ブロック2048Byteが良く使われる。UDF(Universal Disk Format)は、光ディスク用のファイルシステムである。
ランダムアクセスを行う場合には、データの境界をこのブロックに合わせることで効率よくアクセスする事ができる。また、ディスクデバイスの構造だけでなく、例えば、暗号化の単位としてブロックサイズが決められることもある。この場合でも、アクセスの単位としてブロック境界に合わせてデータにアクセスできると効率が良い。このようなアクセス効率などを考慮してデータのサイズまたはデータを格納する位置を決めることをアライメントと呼ぶ。
トランスポートストリーム(TS)を記録する場合には、32個のTSパケットが接続されて、6144Byteのデータとなる。TSパケットは、192Byteである。これによって、UDFの3つのブロックに効率よく記録できる。UDFの1つのブロックは、2048Byteである。MMTPパケットは、可変長パケットである。このため、単純にパケットの数でブロックの境界に合わせることができない。
図12で示したように、ランダムアクセスを行う場合には、GOPの先頭へのアクセスを効率的に行うことが望ましい。しかし、GOP内のどの画像から再生する場合でも、GOPの先頭からデータを読み出す必要がある。そこで、GOP単位でブロックの境界に合わせて記録することを考える。
図14(A)に、GOPをデータアクセスの単位として、GOPの先頭がブロックサイズの整数倍になるようにしたMMTストリームを記録したファイルの一例を示す。
図14(A)は、MMTストリームを記録したファイルのデータの一部を示している。図14(A)の左側がファイル前方に、右側がファイル後方に対応している。MMTストリームのパケットは、例えば、図14(A)の左側から右側に向けて順次記録されている。図14(A)は記録されているデータの一部のみを記載している。実際には、このデータ構造が多数繰り返して記録されている。
図14(A)中の符号Bbはブロック境界を示している。また、「n1」、「n2」、「n3」、「n4」、「n5」および「nm」は整数を示している。「m」は正の整数である。「×」は乗算を示している。そのため、「ブロック×n」は、データがブロックサイズの整数倍になっている事を示している。
GOPの先頭がブロックの境界となるようにアライメントする場合には、GOPのデータサイズが必ずしもブロックサイズの整数倍とならない。このため、図14中のパディング(Pad)を用いる。「パディング」とは、データをアライメントするために、意図的に無効領域を作ることである。パディングにはいくつかの方式がある。例えば、1つとして、無効を示すデータを記録する方式である。また、他には、OSまたはファイルシステムが無効なデータ領域を管理する方式などがある。
図14(A)の例では、GOP単位でブロックにアライメントしている。このため、GOP単位でのランダムアクセスを効率よく行うことができる。なお、この例では、映像データについてのみ説明を行っている。しかし、実際には、図11に示すように、映像データ、音声データおよび字幕データなどが多重化され混在している。
そのため、映像データの区切り位置でストリームデータを分割した場合には、映像以外の音声データまたは字幕データに関しては、適切な区切り位置で分割されるとは限らない。そのため、ランダムアクセス時に音声または字幕が遅れて再生される可能性がある。通常、音声または字幕の再生が遅れても、映像とのずれが発生しなければ問題とならない。このため、ここでは、映像の区切り位置を基に、他のデータも一固まりのデータとして取り扱う。
図14(B)は、画像単位でアライメントしたMMTストリームを記録したファイルの一例を示す。図14(B)では、ピクチャ(AU)とパディングとの組み合わせがブロックの整数倍となっている。この場合には、画像単位でのアクセスが必要な時に効率が良い。
AUは、圧縮データの意味のある固まりの1種である。画像(ピクチャ)データの場合には、1枚分の画像である。つまり、AUは、IRAPピクチャ、Iピクチャ、PピクチャまたはBピクチャのいずれかになる。
この図14(B)では、画像の単位ですべてのアライメントを行った。しかし、ランダムアクセスの時に重要になるのはIRAPピクチャである。IRAPピクチャは、GOPの先頭に置かれる。そのため、IRAPピクチャとそれ以外のピクチャをまとめたものとの2つに分けてアライメントを行うこともできる。
図14(C)に、IRAPピクチャの先頭、Iピクチャの先頭およびPピクチャの先頭をブロック境界にアライメントを行った。図14(C)は、Iピクチャを「I」と示し、Pピクチャを「P」と示し、Bピクチャを「B」と示す。早送りまたは巻き戻しなどの場合に、IRAPピクチャだけではなく、IピクチャまたはPピクチャ等を利用する場合に効率が良い。この図14(C)では、IRAPピクチャの先頭、Pピクチャの先頭または非IRAPのIピクチャの先頭でアライメントを行っている。しかし、Pピクチャ先頭またはIピクチャ先頭でのアライメントを省略しても良い。
図14(D)に、スライス単位でアクセスすることを考えてアライメントを設定したMMTストリームを記録したファイルの一例を示す。映像がスライス構成となっている場合には、スライス単位でのアクセスを効率よく行うことができる。
図14(D)で、画像(ピクチャ)データの最初には、非VCLデータが記載されている。非VCLデータは、AUD、VPSまたはSPSなどのパラメーター類である。後続のスライス#1からスライス#4は、VCLデータである。VCLデータは、圧縮された画像データである。
スライス単位でデコードを行う際にも、非VCLデータは各々のスライスをデコードする際に必要となる。例えば、スライス#2をデコードする際には、非VCLデータとスライス#2のデータとを組み合わせてデコードする。そのため、ここでは非VCLデータと、スライス#1からスライス#4とでそれぞれアライメントを行っている。
実際には、非VCLデータは各スライスと比べて非常に小さいことが多い。また、スライス#1のデコードを行う前には、非VCLデータを必要とする。このことから、非VCLデータとスライス#1とをまとめてアライメントを行うことも考えられる。
スライス単位でのアライメントは、必ずしも全てのピクチャで行う必要はない。例えば、IRAPピクチャのみをスライス単位でのアライメントに用いることも考えられる。なぜなら、IRAPピクチャは、サイズの大きく、ランダムアクセスに用いられるからである。
MMTPパケット単位でアライメントする方法も考えられる。MMTPパケットは、規格によってデータ量が異なる。例えば、放送規格案でのMMTPパケットの最大値は、約1500Byteである。
例えば、2048Byteブロックを想定してアライメントを行った場合には、全データ量に占めるパディングの量が大きくなる。そして、記録効率が悪くなる。
一方、パケット単位でのアクセスは効率よく行える。つまり、MMTPパケット単位でのアライメントは、パケット単位でのデータ加工が必要となる場合などの一時的なデータの格納に適している。パケット単位でのデータ加工は、例えば、記録再生時または編集時などに行われる。
タイムテーブルTMおよびアライメントを用いることによって、時刻を指定したデータの再生を効率よく行うことができる。
ブルーレイディスクでは、この実施の形態2のタイムテーブルTMに相当する仕組みとして対応表(EPマップ、EP_map)を持っている。このEPマップは、再生位置をシステムクロックとTSパケットの位置とで示している。再生位置は、PTS(表示開始の時刻)とそのデータとを読み出すための位置である。
EPマップは、時刻を指定したジャンプ、ランダムアクセスまたはプレイリストによる再生などに用いられている。ランダムアクセスは、例えば、早送りまたは巻き戻しなどである。プレイリストは、ストリームの再生部分と再生順とを決めたリストである。
ブルーレイディスクのEPマップでは、時刻および再生位置のデータ形式がMMTの場合とは異なっている。しかし、時刻を指定して再生位置のデータを取得する仕組みはこの実施の形態2で説明したタイムテーブルTMを用いる場合と同じ考え方である。
タイムテーブルTMをEPマップと類似の構造とすることによって、これら再生の仕組みを大幅に変更することなく、ブルーレイディスクにMMT形式の放送を記録し再生することができる。
例えば、MMTの再生の時刻形式は、放送時の絶対時刻(世界時刻)である。一方、ブルーレイディスクのEPマップでは、内部クロックを用いた相対時刻である。そこで、タイムテーブルTMの時刻の表記を相対時刻の表記に換算する。または、絶対時刻と相対時刻との換算用のデータを別途持たせる。または、ブルーレイディスクで使用する再生の時刻情報を、絶対時刻の形式に変更する。
実施の形態3.
日本の新しい放送方式では、多重化方式およびエンコード方式が変更されている。また、日本の新しい放送方式では、伝送レートも引きあげられている。例えば、ARIB TR B−39によると、4K放送では35Mbpsの伝送レートが想定され、8K放送では100Mbpsの伝送レートが想定されている。
一方、現在市販されているBDXL(登録商標)のディスクでは、光ディスクの伝送レートは、140Mbps前後である。
そのため、8K放送を録画したディスクを再生する場合には、通常の再生では問題がなく、再生可能である。しかし、8K放送を録画したディスクで早送りなどの特殊再生を行うと、1コマ分の画像を表示するのに時間がかかってしまうという問題がある。
特開2000−125259には、記録媒体の記録領域を所定のデータサイズに分割し、記録時にストリームを解読して、Iピクチャであることを表すPCT(ピクチャタイプコード)を含むTSパケットを、セクタの先頭から記録すると共に、そのセクタの先頭アドレスを示すポインタを、記録媒体上に設けたテーブルに登録する。そして、この様に記録した記録媒体を用いた早送り、早戻し等の特殊再生動作は、ポインタテーブルからポインタアドレスを読み出し、そのポインタが示すセクタから一枚のIピクチャのみを再生し、その後次々とポインタが示すセクタを順次再生することが記載されている。
このように、早送りなど特殊再生を行う際には、Iピクチャのみを再生する方法が取られる事が多い。Iピクチャは、映像ストリームのランダムアクセスポイントにある。早送り速度に応じて、通常の早送り(FF、Fast Foward)では、全てのIピクチャを表示する。また、2倍速の早送り(FF×2)では、Iピクチャを1つ飛ばしで表示する。また、3倍速の早送り(FF×3)では、Iピクチャを2つ飛ばしで表示する。このようにして、早送り時の再生速度の調整を行う。
しかしながら、GOP内でのIピクチャの比率が大きい場合には、Iピクチャの読み出しに時間がかかり、画像(Iピクチャ)の更新間隔が長くなる。
実施の形態3に係る映像再生装置は、特殊再生の際に、Iピクチャの読み出し時間を短くし、画像(Iピクチャ)の更新間隔を短くすることができる。
従来の早送り再生では、再生可能なIピクチャのディスク上の位置をテーブルで管理している。そして、そのテーブルを用いて、順次、Iピクチャのデータを読み出している。
光ディスクでは、読み出し位置を変更する際には、ヘッドの移動に時間が必要である。このヘッドの移動時間をシークタイムと呼ぶ。
画面上での早送り画像の更新間隔は、次の式1ようになる。
更新間隔 = シークタイム+Iピクチャデータの読み出し時間+デコード時間 ・・・(1)
4K/8K放送では、従来の2K放送よりもIピクチャのサイズが大きい。そのため、Iピクチャのサイズが大きい場合には、Iピクチャの読み出しに時間がかかり、画像(Iピクチャ)の更新間隔が長くなる。
また、映像ストリームのデータレートとディスクからの最高読み出し速度との差が少ない場合にも、Iピクチャの読み出し時間が長くなり、画像の更新間隔が長くなる。例えば、100Mbpsの放送ストリームを最高読み出し速度140Mbpsの光ディスクから読み出す場合には、1.4倍の速度でしか読み出す事ができない。
このように、4K/8K映像を光ディスクに記録した場合には、特殊再生時の画像の更新間隔が従来よりも長くなる。その一方で、放送を記録した映像の再生時には、早送りなど特殊再生の操作が行われる事が多い。そして、利用者が目的のシーンを特定する際には、画像の更新間隔は短い方が望ましい。
画像の更新間隔が長い場合には、利用者が早送りを使ってシーンを検索する際に、目的のシーンを見つける事が難しくなってしまう。
この実施の形態3では、早送り再生などの特殊再生の際に、目的のシーンを見つける事が容易で、操作性の良い映像再生装置を提供する事を目的としている。
利用者の観点から早送り時の画像の更新間隔について整理する。例えば、本来の再生時間が100秒の映像を10秒で再生する早送りを考える。ここでは仮に10倍速早送りと呼ぶ。
通常、利用者は早送り中の映像を確認して、目的のシーンが現れた時点で早送り解除する。つまり、通常の再生速度に戻す。早送り再生の時には、表示される映像は間欠的な映像となる。しかし、表示されるシーンを利用者が認識するには、時間的な情報の欠落は少ない方が容易である。また、早送り操作が終了した後、早送りが解除されて通常再生に戻る位置のずれも少なくできる。
例えば、10倍速早送りに対して考える。早送り中の画像の更新間隔が1秒であれば、通常の再生時間の10秒に対して1コマ表示される。これに対して、早送り中の画像の更新間隔が0.5秒であれば、通常の再生時間の5秒に対して1コマが表示される。
早送り再生の際に、利用者が目的のシーンを見つけるためには、通常の再生時間当たりから抜き出されるコマ(画像)数が多い方が有利である。このように、早送り再生時に、多くの画像を表示することによって、操作性を向上させる事ができる。つまり、更新間隔を短くすることによって、操作性を向上させる事ができる。
4K/8K放送では、分割デコードを想定して、複数のスライスセグメントを持ったストリーム形式を規定している。
例えば、1つの画像を4分割する場合には、縦と横とに2分割(以下、田の字型ともよぶ。)して4分割の画像を作成する。または、1つの画像を縦方向に4分割(以下目の字型ともよぶ。)する。そして、それぞれのスライスセグメント単位で、独立してデコードできるようになっている。これは、2K用のデコーダーを4つ用いて4K映像のデコードを行い、4K用のデコーダーを4つ用いて8K映像のデコードを行えるようにするための配慮である。
これらの複数のスライスセグメントを持つ放送ストリームを光ディスクに記録した場合には、スライスセグメント単位でデータを読む出す事が出来れば、一部のスライスセグメントだけを再生することが可能である。
これを特殊再生時に使用すれば、更新される画像は通常の再生で表示されている画像の一部になる。しかし、式(1)の「Iピクチャデータの読み出し時間」を4分の1にすることができる。そして、特殊再生時の画像の更新間隔を短縮することができる。
図15は、実施の形態3に係る映像ストリームの模式図である。
多重化方式としてはTS方式およびMMT方式の両方が考えられる。しかし、図15では、固有のヘッダ情報などを省略している。また、パディング等も省略している。
放送の場合には、1つのGOPは約60フレーム(画像またはピクチャ)まで含む事ができる。そして、1つのGOPの中に、少なくとも1つのIピクチャを含む。特に、デコードの際に開始点となるIピクチャはIRAPピクチャ(IRAP画像)と呼ばれる。そして、データ順では、通常、IRAPピクチャはGOPの先頭に配置されている。
Iピクチャ(IRAPピクチャを含む)、BピクチャおよびPピクチャは、それぞれフレーム(画像またはピクチャ)を表す。
Iピクチャは、単独でデコード可能な独立した画像を示す。一方、BピクチャおよびPピクチャは、他の画像に依存している。BピクチャおよびPピクチャは、他の画像との差分データである。このため、BピクチャおよびPピクチャは、単独ではデコードすることができない。
GOPは、GOPの中で画像間の依存関係が完結している。つまり、GOP内のすべての画像は、デコード可能となるデータのセットを構成している。
1つの画像が複数のスライスセグメントで構成されている場合には、それぞれの画像はパラメータセットと複数のスライスセグメントとで構成されている。パラメータセットと1つのスライスセグメントとを組み合わせる事で、スライスセグメントはデコード可能な単位となる。図15では、IRAPピクチャのみスライスセグメントの構造で記載している。しかし、BピクチャおよびPピクチャも、同様の構造を取ることができる。
デコーダーを4つ用いて並列でデコードする場合には、スライスセグメントごとにデータを取り出す。そして、それぞれのデータにパラメータセットを追加する。その後、それぞれのデータを個々のデコーダーに与える事によって、1つの画像を分割された状態でデコードすることができる。画像を表示する際には、個別にデコードされた画像を結合し、1つの画像にして表示する。
図16には、縦横に4分割(田の字型)した例を示す。画像の左上には、スライス#1の画像が表示されている。画像の右上には、スライス#2の画像が表示されている。画像の左下には、スライス#3の画像が表示されている。画像の右下には、スライス#4の画像が表示されている。
図17には、縦方向に4分割(目の字型)した例を示す。画像の上から1番上には、スライス#1の画像が表示されている。画像の上から2番目には、スライス#2の画像が表示されている。画像の上から3番目には、スライス#3の画像が表示されている。画像の上から4番目には、スライス#4の画像が表示されている。
なお、分割されていない映像ストリームの場合には、1つのピクチャデータ内にスライスセグメントが1つだけ存在している。
このような分割されたスライスセグメント構造を持った映像ストリームでの特殊再生を考える。
前述の通り、操作性を向上させるためには、表示画像の更新間隔を短くする必要がある。従来では、Iピクチャ全体のデータを読み込み、Iピクチャ全体を表示していた。しかし、Iピクチャの第1スライスセグメント(スライスセグメント#1)のデータのみを読み込み、Iピクチャの第1スライスセグメント(スライスセグメント#1)のみを表示する事を考える。
図18は、分割スライスセグメントの単位での読み出しに対応したタイムテーブル(TMS)の一例である。図19は、タイムテーブル(TMS)の各項目とデータ上との対応を示している。映像ストリームを記録する際に、映像ストリームの解析を行う。そして、時刻情報またはデータ区切り位置の情報などを取出してタイムテーブル(TMS)を作成する。
なお、タイムテーブルとして符号TMと符号TMSとの2種類を用いている。分割スライスセグメントに対応したタイムテーブルを符号TMと区別して符号TMSを用いている。タイムテーブルは、映像ストリームと一緒に記録メディアに記録される。記録メディアは、例えば、光ディスクなどである。
タイムテーブル(TMS)の各項目について説明する。
「時刻」は、各時刻の行が示すGOPの表示時刻である。時刻は、システムクロック形式の時刻情報、ntp形式の時刻情報またはストリームの先頭からの差分時間などの形で記録されている。時間を指定して再生を開始する場合には、この時刻欄を検索し、指定時間の近傍のデータから再生を開始する。
なお、「時刻」は、ここではGOPの表示時刻とした。1つのGOPには、通常、複数の画像が含まれている。そして、それぞれの画像の表示時刻があるため、GOPには表示時刻が複数存在する。GOPの表示時刻としてタイムテーブルに記録する場合には、GOP内での表示の順番で先頭になる画像の表示時刻を使用することができる。または、デコードの順番で先頭になる画像の表示時刻を使用することができる。この場合には、先頭になる画像は、IRAPピクチャになる。
また、タイムテーブルに格納する「時刻」は、必ずしも、画像の表示時刻に一致する必要はない。例えば、画像の表示時刻そのものではなく、精度を落とした時刻情報または他のデータに対する時刻情報などを用いることができる。これらは、例えば、再生装置のシステムクロックの精度、データアクセスとの関係またはタイムテーブルに格納可能なデータ長などが考慮される。
「IRAP開始位置」は、IRAPピクチャの格納位置である。IRAPピクチャの格納位置は、GOPのランダムアクセスポイントとなる。IRAPピクチャの格納位置は、通常、GOPの開始位置と同一となる。「IRAP終了位置」は、IRAPピクチャ全体のデータ末尾を示す。IRAP開始位置からIRAP終了位置までのデータを読み出すことによって、IRAPピクチャをデコードできるデータがそろう。
「#2開始位置」は、2つ目のスライスセグメント(スライス#2)の開始位置を示す。また、「#2開始位置」は、1つ目のスライスセグメント(スライス#1)の終了位置を示す。「#3開始位置」は、3つ目のスライスセグメント(スライス#3)の開始位置を示す。また、「#3開始位置」は、2つ目のスライスセグメント(スライス#2)の終了位置を示す。「#4開始位置」は、4つ目のスライスセグメント(スライス#4)の開始位置を示す。また、「#4開始位置」は、3つ目のスライスセグメント(スライス#3)の終了位置を示す。「#4終了位置」は、4つ目のスライスセグメント(スライス#4)の終了位置を表す。通常、この位置はIRAPピクチャの終了位置と同じである。
「パラメータセット」には、IRAPピクチャのデータのパラメータセットが格納されている。パラメータセットには、例えば、AUD(Access Unit Delimiter)、VPS(Video Parameter Set)、SPS(Sequence Parameter Set)、PPS(Picture Parameter Set)、SEI(Supplemental Enhancement Information)またはEOS(End of Stream)などが含まれている。
図19に示したタイムテーブル(TMS)では、スライスセグメントの終了位置を格納している。例えば、IRAPピクチャの終了位置とスライス#4の終了位置とである。しかし、終了位置の代わりにデータサイズをテーブルに格納し利用する方法を取ることもできる。
開始位置および終了位置は、データの先頭からのバイト位置またはブロック位置などの形で記録されている。また、多重化方式にTSを採用している場合には、開始位置および終了位置は、TSパケットの位置などの形で記録されている。開始位置および終了位置は、データを読み出すのに必要な位置として記録されている。
セグメントのデータ位置を示す情報に関しては、GOPの先頭からの相対位置とすることができる。これによって、位置情報のデータサイズを小さくする事が出来る。
光ディスクでは、ある程度まとまったデータ単位でデータの読み込みを行う。このため、位置に関しては必ずしも厳密である必要はない。位置を示す単位を大きくして、位置情報のデータ量を削減することも可能である。
この例では、単一のタイムテーブルにスライスセグメントに関する情報も記録している。しかし、スライスセグメント情報を別のテーブルに格納することも可能である。この場合には、タイムスタンプ情報またはテーブル内でのエントリー位置などで、同一のGOPおよびIRAPピクチャに関する情報を取り出せるようにしておく。
パラメータセットを、さらに別テーブルに格納する方法も考えられる。なぜなら、パラメータセットは、位置情報に比べるとサイズが大きいからである。また、パラメータセットは、画像によってデータ長が変化するからである。
Iピクチャのスライスセグメント#1のみを用いて早送り再生を行う場合には、タイムテーブルで必要な情報は時刻、IRAP開始位置および#2開始位置である。この場合には、#2開始位置はスライスセグメント#1の終了位置として利用される。
図20を用いてスライスセグメント#1のみを用いた早送り再生の説明を行う。GOP(01)からGOP(06)までは、ストリームデータである。本来、ストリームデータは一続きのデータファイルである。しかし、説明を容易にするため、GOP単位で行を変えて表わしている。TMS(タイムテーブル)は、前述のタイムテーブルである。TMS(タイムテーブル)は、時刻情報と画像データの位置を対応付けている。
なお、IRAP開始位置と#1開始位置とは、同じ値としてタイムテーブル上で兼用している。必要な値は、スライス#1の開始位置と終了位置である。IRAP開始位置を#1開始位置とみなし、#2開始位置を#1終了位置とみなしている。
早送り再生の場合には、タイムテーブルのエントリーを順次読み出す。それぞれのGOPのIRAP開始位置と#2開始位置とから、このGOPのIピクチャの1つ目のスライスセグメントのデータを読み出す。そして、このデータをデコードし、画面に表示する。IRAP開始位置は、スライスセグメント#1の開始位置である。#2開始位置は、スライスセグメント#1の終了位置である。
これを繰り返す事によって、早送り再生を行うことができる。この場合には、Iピクチャを全て表示する場合に比べて、読み出しデータ量が4分の1になっている。このため、早送り再生時の画像の更新間隔を短くする事ができる。
この例の場合には、表示が更新されるのは画面の一部である。つまり、1つ目のスライスセグメントの位置の画像のみ表示される。縦横4分割(田の字型)の場合には、例えば、画像の左上の4分の1の領域である。縦方向4分割(目の字型)の場合には、画像の上部4分の1の領域である。他の部分は更新されないまま残る。または、他の部分は表示されない状態である。
利用者が早送り操作を行う場合には、目的のシーンを判別できればよい。そのため、画面全体が見える事よりも、更新間隔の短い方が操作性を考慮すると良い場合も多い。
また、同じ方法で、1つ目のスライスセグメントと2つ目のスライスセグメントの2つとを表示する。このようにすれば、画面の半分を表示して早送りを行うこともできる。
さらに、高速で早送り再生を行う場合には、表示するGOPを間引きして再生することができる。つまり、GOPを1つ飛ばし又は2つ飛ばし等で表示する。
早送り再生の操作では、リモコンの早送りボタンを複数回押す事で早送り速度を調整する事が出来るものが多い。従来のIピクチャ全体を表示する早送りと組み合わせて使う場合には、リモコンボタンを押す回数によって表示方式を選択することができる。
例えば、ボタンを1回押すと、全てのGOPのIピクチャの全体を表示して早送り再生を行う。ボタンを2回押すと、全てのGOPのIピクチャの一部のスライスセグメントのみを表示して早送り再生を行う。ボタンを3回押すと、GOPを1つ飛ばしして、Iピクチャの一部のスライスセグメントのみを表示して早送り再生を行う。ボタンを4回押すと、GOPを2つ飛ばしして、Iピクチャの一部のスライスセグメントのみを表示して早送り再生を行う。
放送ストリームが複数のスライスセグメントを持たない場合には、この方法を使うことができない。しかし、放送を記録する際に、再圧縮またはフォーマット変換を行うことも多い。その際に、複数のスライスセグメントを持つHEVC映像ストリームとして再構成する事も可能である。放送以外の外部入力の映像を記録する場合でも、同様に、複数のスライスセグメントを持つHEVC映像ストリームとして圧縮データを作成する事で、この方法による特殊再生を行う事ができる。
<変形例1>
これまでの説明では、早送りなど特殊再生時に画像の一部のみの更新でも良いとした。しかし、画像の全体が更新された方が目的のシーンを見つけやすいことも考えられる。そこで、読み出すデータは一部スライスセグメント分としながら、画像の全体を更新する方法を考える。
図21は、早送り再生の説明図である。この例では、タイムテーブル(TMS)の中の全てのスライスの位置情報を利用している。
早送り再生の場合には、タイムテーブルのエントリーを順次読み出す。最初のGOPのIRAP開始位置と#2開始位置とから、このGOPのIピクチャの1つ目のスライスセグメントのデータを読み出す。IRAP開始位置は、スライスセグメント#1の開始位置である。#2開始位置は、スライスセグメント#1の終了位置である。このデータをデコードして、画面のスライスセグメント#1の位置に表示する。図21では、画面のスライスセグメント#1の位置は、画面の左上である。
次のGOPの#2開始位置と#3開始位置とから、このGOPのIピクチャの2つ目のスライスセグメントのデータを読み出す。#2開始位置は、スライスセグメント#2の開始位置である。#3開始位置は、スライスセグメント#2の終了位置である。このデータをデコードして、画面のスライスセグメント#2の位置に表示する。
この時、スライスセグメント#2のデコードには、このピクチャのパラメータセット(PS)のデータが必要になる。パラメータセット(PS)は、ピクチャ先頭に配置されている。つまり、パラメータセット(PS)は、スライスセグメント#1の前に配置されている。このため、パラメータセット(PS)をスライスセグメント#1と同時に読み込む場合には、1度に読み込める。しかし、パラメータセット(PS)とスライスセグメント#2とを読み込む場合には、2回の読み込みが発生する。
光ディスクの読み出し動作では、読み出し位置の変更に時間がかかる。そのため、この時の読み込み動作としては次の3つの方法が考えられる
1つ目の方法は、パラメータセット(PS)とスライスセグメント#2との2回の読み込み動作を行う。2つ目の方法は、パラメータセット(PS)、スライスセグメント#1およびスライスセグメント#2を一度に読み込む。3つ目の方法は、パラメータセット(PS)とスライスセグメント#2のデータとを使用する。そして、タイムテーブルを作成する時に、Iピクチャのデコードに必要なパラメータセット(PS)のデータのコピーをタイムテーブルに格納する。
この説明では、3つ目の方法を説明している。つまり、タイムテーブル内にパラメータセット(PS)のデータのコピーが格納されているものとして説明している。この場合には、タイムテーブルに格納されていたパラメータセット(PS)のデータとスライスセグメント#2のデータとをデコーダーに入力して、デコードを行う。
次のGOPでは、同様にスライスセグメント#3のデータを取り出し、画面上のスライスセグメント#3の位置の画像を更新する。図21では、画面上のスライスセグメント#3の位置は、画面の左下である。
このように画像の更新のたびに、表示するスライスセグメントをずらしていく事によって、一回の更新では画像の一部の更新ではあっても、数回の画像の更新によって画面全体を更新することができる。画面の位置によって、異なる時刻の画像が表示される。スライスセグメントごとに、異なる時刻の画像が表示される。しかし、一部分の画像の表示に比べると、シーンの把握が容易になる。つまり、より操作性の良い特殊再生を実現することができる。
この説明では、1つのスライスセグメントで画像の更新を行った。しかし、1つのGOPで複数のスライスセグメントの画像を更新することができる。例えば、画像の半分ずつを交互に更新する事もできる。
上記の説明では、スライス番号の順にスライス#1、スライス#2、スライス#3、スライス#4の順番で画像の更新を行った。画像の更新は、必ずしもスライス番号の順である必要はない。再生時に任意の順番とすることができる。
図22に画像の更新の順番の例を示す。図22(1)は、スライス#1、スライス#2、スライス#3、スライス#4の順で画像を更新する例である。図22(2)は、スライス#1、スライス#2、スライス#4、スライス#3の順で画像を更新する例である。図22(2)は、時計回りで画像を更新している。図22(3)は、スライス#1、スライス#4、スライス#3、スライス#2の順で画像を更新する例である。図22(4)は、スライス#1、スライス#3、スライス#4、スライス#2の順で画像を更新する例である。図22(4)は、反時計回りで画像を更新している。
再生の時に表示するスライスセグメントを選択できる場合には、早送り再生時と巻き戻し再生時とで、画像を更新する順番を逆にすることもできる。例えば、早送りの場合には、図22(2)の時計回りとし、巻き戻しの場合には、図22(4)の反時計回りとする。このように、早送りと巻き戻しとで画像の更新の順番を逆にすることによって、早送りの操作と巻き戻しの操作とを繰り返した場合でも、現在の状態の把握が容易になり、操作性が向上する。
図23は、縦方向に4分割(目の字型)の場合の例である。この場合にも、画像の更新の順番を逆にすることで、早送りと巻き戻しとの把握が容易になる。例えば、早送りをスライス#1からスライス4に向けて更新する(図23(1))。そして、巻き戻しをスライス#4からスライス1に向けて更新する(図23(2))。
<変形例2>
前記の説明では、タイムテーブルに全てのスライスセグメントへの読み出し位置情報を格納していた。タイムテーブルのサイズを小さくするために、一部のスライスセグメントの読み出し位置情報だけを記録する方法も考えられる。
図24では、1つのスライスセグメントの読み出し位置情報を格納したタイムテーブル(TMS)を示している。
この例では、タイムテーブルの各時刻に対応するスライスセグメントの読み出し位置の情報を格納している。例えば、GOP(01)とGOP(05)とに対応する行には、スライスセグメント#1の読み出し位置情報が格納されている。図23では、例えば、GOP(01)の情報はタイムテーブルの1行目に記載されている。また、GOP(05)の情報はタイムテーブルの5行目に記載されている。
ストリームを記録する際に、記録するGOPを順次カウントする。そして、このGOPのカウント値を1つの画像中のスライスセグメント数で割った余り(剰余)を取る。図24では、1つの画像中のスライスセグメント数は4である。この値(剰余)に1を足した値をスライスセグメントの値とする。そして、そのスライスセグメントの位置をタイムテーブルに記録する。
この例では、各時刻のスライス開始位置とスライス終了位置とには情報が記載されている。スライスの順番は、スライス#1、スライス#2、スライス#3、スライス#4の順番である。なお、図24では記載を省略しているが、IRAP開始位置およびIRAP終了位置なども記録する。他の特殊再生または従来のIRAP画像全体の表示との互換のためである。
このタイムテーブルを用いて早送りなどの特殊再生を行う場合には、GOPを飛ばさずに早送りを行うと、画面全体が更新される。また、例えば、GOPを1つずつ飛ばして再生すると、スライス#1とスライス#3とが更新される。また、例えば、GOPを3つずつ飛ばしで再生すると、スライス#1が更新される。
早送りの倍速にかかわらず、画像の全体を更新するためには、タイムテーブルに読み出し位置情報を格納する際に、乱数または疑似乱数などを用いてスライスセグメントを選択することもできる。この場合には、画面上で更新されるスライスセグメントは不規則である。しかし、早送りの倍数などによらず、画像全体を更新することができる。
疑似乱数の生成手段としては、例えば、M系列を用いた線形帰還シフトレジスタなどが挙げられる。
M系列を用いた疑似乱数生成では、値数および回数を指定して、各値の出現確率が一様で指定回数の間に周期性の無いデータ列を生成することができる。値数は、例えば、1から4の4値である。回数は、例えば、1000回である。
例えば、これらの疑似乱数の生成手段を用いてタイムテーブルを作成すれば、タイムテーブルの中で同じパターンの繰り返しが発生しないように、スライスセグメントを選択することができる。これによって、早送りの倍速を変更した場合でも、特定のスライスセグメントだけが更新されることを防ぐことができる。必ずしも、タイムテーブルの全体で同じパターンの繰り返しを無くす必要はない。十分に長い周期で同じパターンを繰り返せば、実用上問題は無い。十分に長い周期は、例えば、1000行程度である。
タイムテーブル全体で周期性が発生しないように、この疑似乱数の回数を選択する。しかし、疑似乱数の周期性を長く設定すると演算量が多くなる。そして、乱数のデータ列として予め与える場合でも、データ量が多くなる。
早送りの操作または巻き戻しの操作の際には、主にスキップ量の少ない早送りまたは巻き戻しが利用される。例えば、GOPのスキップを行わないか、1から数十程度のGOPのスキップを行う。そのため、疑似乱数の周期を短く設定することができる。
一例として、1000行程度の周期性を持つタイムテーブルを挙げた。999のGOPをスキップした時に、一部の画像のみが更新されるという問題が発生する。しかし、999のGOPをスキップした時の早送り再生と巻き戻し再生とは、あまり利用されない。また、999のGOPをスキップする場合に代わって、1000のGOPをスキップすることを採用しても、利用者から見た早送りの倍速は、ほとんど変わらない。このため、容易に回避できる。
GOPの長さの平均を0.5秒とすると、2時間の映像は14400個のGOPで構成される。そして、1000行の周期性は、2時間の映像で15回程度発生することになる。周期性が問題になるのは、2時間映像を15コマで再生する早送りの時である。通常は、このような高速の早送りの操作は行われない。
この場合の疑似乱数列を事前に、計算済み乱数表として制御プログラムに与える場合の乱数表のサイズを見積もる。値数が4値で、回数が1000回の乱数列を、1つを2ビットで表現する。この場合には、全体で250バイトのサイズとなる。疑似乱数の周期性の長さは、操作性と装置実装との関係で設定することができる。
<変形例3>
これまでの例では、スライスセグメントの表示位置を変更する場合には、タイムテーブルにスライスセグメントの読み出し位置および終了位置を格納していた。また、必要な場合には、タイムテーブルにパラメータセット(PS)を格納していた。そのため、タイムテーブルのデータが大きくなる。また、パラメータセット(PS)とスライスセグメントとの2回の読み出しが発生する。
映像ストリームの記録の際に、スライスセグメントの順序を入れ替えることによって、これらの余分な作業を回避し、効率のよい特殊再生を行うことができる。
図25は、早送り再生の説明図である。図24と同様にGOP(01)からGOP(06)は、ストリームデータである。本来、一続きのデータファイルであるが、説明を容易にするために、GOP単位で行を変えて表わしている。
図25のストリームでは、それぞれのGOPの先頭にあるIRAPピクチャごとに、スライスセグメントの格納順を変更している。ここで、スライスセグメントの番号は、画面上の表示位置を示している。この表示位置に表示されるスライスセグメントの番号を、ストリームデータ上の番号として示している。
図25では、一例として、次のようにデータを配置している。GOP(01)には、IRAPピクチャの先頭にスライスセグメント#1を配置している。GOP(02)には、IRAPピクチャの先頭にスライスセグメント#2を配置している。GOP(03)には、IRAPピクチャの先頭にスライスセグメント#3を配置している。GOP(04)には、IRAPピクチャの先頭にスライスセグメント#4を配置している。GOP(05)には、IRAPピクチャの先頭にスライスセグメント#1を配置している。GOP(06)には、IRAPピクチャの先頭にスライスセグメント#2を配置している。
これまでの説明では、データ分割の観点から、単にスライスセグメントとして説明してきた。しかし、表示位置も含めた管理は、HEVC規格のスライスセグメントの他に、タイルも用いて実現されている。そのため、タイムテーブルのスライスセグメントの格納位置を入れ替える場合には、必要に応じて、各スライスセグメントのスライスヘッダ情報およびタイル情報などを修正して、整合性を取る必要がある。タイル情報は、パラメータセットに含まれている。
早送り再生時の手順は、図20を用いた説明と同一である。図20を用いた説明は、スライスセグメント#1のみの再生を行う場合である。ただし、図25の例では、先頭に置かれるスライスセグメントが入れ替えられている。このため、画像の更新がされるスライスセグメントが変化し、画面の全体が更新される。
単純な順序で先頭に配置されたスライスセグメントを選択する場合には、早送りの倍速によって一部のスライスセグメントの画像だけが更新される。そこで、前述の乱数または疑似乱数などを用いる方式で、先頭に配置するスライスセグメントを決定することができる。
このように、記録時のスライスセグメントの順番を入れ替える事によって、早送り及び巻き戻し等の特殊再生によるシーンサーチの操作性を向上する事が可能である。
これまで、スライスセグメントとして4分割を例にして説明をしてきた。これは、日本の4K/8K放送で採用されているためである。
実際には、放送の録画時または光ディスクへの記録時に、再圧縮またはフォーマット変換などを行うこともある。この場合には、4分割だけでなく、スライスセグメント分割の形式を自由に変更することができる。
例えば、1つの画像を3×3の9分割にすることもできる。この場合には、中心のセグメントのみを特殊再生で更新することも考えられる。なぜなら、中心のセグメントには重要な情報が含まれる可能性が高いからである。また、単純に2分割のスライスセグメントとすることができる。2つのセグメントを交互に更新することで特殊再生を行うこともできる。
また、光ディスクの例で説明したが、ハードディスクドライブ(HDD)またはSSD(solid state drive)など、他の記憶デバイスでも同様の効果が得られる。
ネットワークなど伝送帯域で制限があり、データ転送の遅延が大きい場合でも、特殊再生時のデータ転送量を抑制し、操作性を向上させることも可能である。
実施の形態4.
実施の形態4の課題は、実施の形態3の課題と同様である。つまり、実施の形態4は、8K放送を録画したディスクで早送りなどの特殊再生を行うと、1コマ分の画像を表示するのに時間がかかってしまうという課題に対応する。
例えば、特許公開公報の特開2006−245744(0016段〜0020段、図2)には、情報記録媒体に保存されたIピクチャのアドレスと、算出されたIピクチャの再生予定時刻を含むアクセスタイムテーブルを作成することが記載されている。そして、特殊再生時に、アクセスタイムテーブルの再生予定時間を参照して、Iピクチャの再生が行われる。もしIピクチャの復号に時間がかかれば再生予定時間に再生が行えなくなってしまう。
実施の形態3では、画像を構成する複数のスライスセグメントに分割する。そして、特殊再生時にはスライスセグメント単位で部分的に画面表示を更新する。これによって、画像(Iピクチャ)の更新間隔を短くし、特殊再生時の応答性を向上させている。
しかしながら、画面の一部の表示を更新する場合には、映像シーンの視認性が低下する場合がある。例えば、異なるシーンの画像が画面上に混在する場合である。
実施の形態4では、実施の形態3の方法を利用しつつ、表示されている映像シーンを把握しやすいように構成した。実施の形態4に係る映像再生装置は、特殊再生の際にスライスセグメント単位で画面表示の更新をする場合でも、映像シーンの視認性の低下を抑えることができる。
そのため、実施の形態4では、タイムテーブル(TMS)に「映像シーンの連続性」の情報を付与する。「映像シーンの連続性」の情報は、図26の「シーン連続性番号」である。また、タイムテーブル(TMS)に「画面表示更新すべき優先スライスセグメント」の情報を付与する。「画面表示更新すべき優先スライスセグメント」の情報は、図26の「優先スライス情報」である。
なお、実施の形態4では、縦方向4分割(目の字型)のスライスセグメントであった場合について説明を進めている。しかし、他の分割方法でも対応可能である。例えば、縦横4分割(田の字型)にスライスセグメントが構成されていても対応可能である。また、縦方向8分割のように更に細かくスライスセグメントが構成されていても対応可能である。ここで、分割方法を「行列」で説明すると、縦方向4分割(目の字型)は4行に分割することを表す。同様に、縦横4分割(田の字型)は2行2列に分割することを表す。
図26は、図18のタイムテーブル(TMS)に対して、「シーン連続性番号2601」および「優先スライス情報2602」を付与した新タイムテーブル(TMSN)である。その他の構成要素については、図18と同様のため説明を省略する。タイムテーブル(TMSN)の1行が1エントリーの情報である。各エントリーはランダムアクセス可能なIピクチャを指している。
シーン連続性番号2601は、「映像シーンの連続性」を示す指標となる情報である。そのため、シーン連続性番号2601は、数値情報でもよく、フラグなどの情報でもよい。実施の形態4では、シーン連続性番号2601に0から255までの数値が設定できるものとして説明する。この指標となる情報を作成する場合には、まず、各エントリーのIピクチャの画像毎にヒストグラムを作成する。ヒストグラムは画像中の各色のピクセル数を測定した色分布情報である。各画像のヒストグラムを比較することによって、容易に類似画像か否かを判別できる。
このような比較を用いて、前のエントリーと現在のエントリーとが類似画像か否かを判別する。類似画像であればシーン連続性番号2601を同じ値に設定する。類似画像でない場合には、前のエントリーのシーン連続性番号2601の値をインクリメントして値を設定する。つまり、シーン連続性番号2601の値を1増やす演算を行う。
本実施の形態4では、シーン連続性番号2601の値を0から255の範囲で値設定している。このため、最大値である255をインクリメントする場合には、巡回して0の値が設定されるものとする。なお、本実施例ではシーン連続性番号2601の値を0から255までの範囲としている。しかし、シーン連続性番号2601の値の範囲はこれより狭くてもよい。また、シーン連続性番号2601の値の範囲はこれより広くてもよい。
また、実施の形態4では、比較的簡単で処理負荷が少ないヒストグラムによる類似画像比較を行っている。しかし、画像内のオブジェクト形状、テクスチャまたは特徴量を用いて類似画像か否かを判別してもよい。
優先スライス情報2602は、映像シーン中に画面把握に重要な情報が画面のどの部分に集中しているかを示す。そのため、優先スライス情報2602は、特殊再生時にどのスライスセグメントを更新させるかを決定する際に用いられる。つまり、「画面表示更新すべき優先スライスセグメント」を示す情報である。
優先スライス情報は、画面中央が重要であることを示す1ビットのフラグ情報としてもよい。また、優先スライス情報は、画面を複数に分割して、分割画面毎に重要性を示す数値情報でもよい。
実施の形態4では、画面中央が重要であることを示す1ビットフラグを優先スライス情報2602として説明する。1つの画像を縦方向に4分割(目の字型)した場合を例とする。例えば、映画のように上下に黒帯が入るようなコンテンツの場合には、画面の最上部のスライスセグメント#1と画面の最下部のスライスセグメント#4は、黒帯を含む。そのため、スライスセグメント#1とスライスセグメント#4とは、ユーザーが画面認識するための有用な映像情報が少ない。また一般的な番組でもユーザーに提示したい情報を画面の中央部に配置することが多い。
このような番組の場合には、表示画像の更新を画面の中央部に制限した方が、ユーザーは映像シーンを認識しやすくなる。
実施の形態4では、図23に示す縦方向4分割(目の字型)のスライスセグメントの場合を例として説明する。また、タイムテーブル(TMSN)のエントリー毎に1ビットの優先スライス情報2602を持つものとして説明する。
例えば、優先スライス情報2602の値が「1b」である場合には、画面中央のスライスセグメントであるスライスセグメント#2とスライスセグメント#3とに限定して、順番に表示画面を更新する。一方、優先スライス情報2602の値が「0b」である場合には、表示画面の更新の制限を行わない。つまり、スライスセグメント#1からスライスセグメント#4までの全てを順番に更新する。なお、「1b」はビット値が「1」であることを表す。「0b」はビット値が「0」であることを表す。
優先スライス情報2602を生成する際には、スライスセグメント毎にヒストグラムを作成する。例えば、スライスセグメント#1とスライスセグメント#4とに黒色のピクセルが数多く含まれている場合には、上下に黒帯がある映画であると判定できる。その場合には、優先スライス情報2602に「1b」を設定する。
実施の形態4では、優先スライス情報2602として1ビット情報を持つものとして説明した。しかし、スライスセグメント毎に表示の更新の有無を設定する4ビット情報(4分割時)としても良い。または、優先スライス情報2602を2ビット情報としてもよい。この場合、例えば、「00」は優先スライスなし。「01」は縦方向の中央部分が優先スライス。「10」は横方向の中央部分が優先スライス。「11」は縦横の中央部分が優先スライス。
また、今回は縦方向4分割のスライスセグメントに対して中央部分のスライスセグメントが重要であることをフラグ情報として記録する例を示した。別の例として、横方向4分割のスライスセグメントに対して中央部分のスライスセグメントが重要であることをフラグ情報としてとして記録させても良い。さらに画面を縦3×横3(3行3列)の9つの部分にスライスセグメントを分割し場合には、画面の中央部分だけが重要であることをフラグ情報が示しても良い。また、タイムテーブル(TMSN)を構成しているエントリー毎に優先スライス情報2602を持つ例を示している。しかし、タイムテーブル(TMSN)の全体エントリーに対して1つの優先スライス情報2602で情報を保持しても良い。
図27は、特殊再生時の映像シーンを表した説明図である。特殊再生時の映像シーン(オリジナル画像)2700は、映像シーン#01〜映像シーン#05に順番に切り換わる。なお映像シーン#01から映像シーン#03までは類似の映像シーンである。映像シーン#01から映像シーン#03まででは、一例として、数字の「1」が右側に移動している。同様に、映像シーン#04〜映像シーン#05は類似の映像シーンである。映像シーン#04から映像シーン#05まででは、一例として、数字の「2」が右側に移動している。また、表示更新するスライスセグメントの位置を更新スライス箇所2710として、矢印で図示している。
シーンの連続性制御を行わない場合の映像シーンの表示例を映像シーン2701に示す。映像シーン#11は、映像シーン#01と同じである。映像シーン#12では、映像シーン#11に対して、スライスセグメント#2のみが映像シーン#02のスライスセグメント#2に切り換わっている。映像シーン#13では、映像シーン#12に対して、スライスセグメント#3のみが映像シーン#03のスライスセグメント#3に切り換わっている。映像シーン#14では、映像シーン#13に対して、スライスセグメント#4のみが映像シーン#04のスライスセグメント#4に切り換わっている。映像シーン#15では、映像シーン#14に対して、スライスセグメント#1のみが映像シーン#05のスライスセグメント#1に切り換わっている。
類似の映像シーンでなくなった映像シーン#14は、オリジナルの映像シーン#04とかなり異なる映像になる。類似の映像シーンでないとは、つまりシーンが連続でなくなったことである。同様に、映像シーン#15もオリジナルの映像シーン#05とかなり異なる映像になる。
また、映像シーン#14および映像シーン#15には、オリジナル画像の類似映像である映像シーン#01から#03までの画像と、全く別の映像シーン#04から#05のスライスセグメントが混在して表示されている。そのため、ユーザーは映像シーンの把握自体が困難となる。
シーンの連続性制御を行う場合の映像シーンの表示例を映像シーン2702に示す。映像シーン#21は、映像シーン#01と同じである。映像シーン#22では、映像シーン#21に対して、スライスセグメント#2のみが映像シーン#02のスライスセグメント#2に切り換わっている。つまり、映像シーン#22は、映像シーン#12と同じである。映像シーン#23では、映像シーン#22に対して、スライスセグメント#3のみが映像シーン#03のスライスセグメント#3に切り換わっている。つまり、映像シーン#23は、映像シーン#13と同じである。映像シーン#24では、スライスセグメント#1から#4までの全てが映像シーン#04に切り換わっている。つまり、映像シーン#24は、映像シーン#04と同じである。映像シーン#25では、映像シーン#24に対して、スライスセグメント#2のみが映像シーン#05のスライスセグメント#2に切り換わっている。
シーンの連続性制御を行う場合には、類似の映像シーンが切り換わった後の映像シーン#24では、全てのスライスセグメント#1〜#4に対して表示画面の更新を行う。このように構成することによって、ユーザーは、類似の映像シーンが切り換わっても画面を把握しやすくなる。
図28は、シーン連続性番号2601を用いた表示画面の更新を行うシーケンスを示すフローチャートである。
特殊再生が指示されると、まず、表示画面のエントリーのシーン連続性番号2601を読み込む。その後、Iピクチャの全てのスライスセグメントに対して表示画面を更新する(S2801)。
特殊再生の停止の指示の有無を確認する(S2802)。特殊再生の停止の指示があれば、特殊再生の処理を停止する(S2809)。この場合には、図28中の「yes」を選択する。特殊再生の停止の指示がない場合には、ステップS2803に移る。この場合には、図28中の「no」を選択する。
ステップS2803では、タイムテーブル(TMSN)から再生位置のエントリー情報の読み込みを行う(S2803)。その際、特殊再生の再生速度に応じて、エントリー情報の読み込み方法を決める。例えば、全てのエントリー情報を読み込むか、一部のエントリー情報を読み込むか等を決定する。一部のエントリー情報とは、再生速度に応じて、エントリーを1つおきに読み込んだり、2つおきに読み込んだりすることで、間引かれたエントリー情報を示す。
そして、エントリー情報のシーン連続性番号2601の読込みを行う。そして、読込んだシーン連続性番号2601と、1つ前の表示位置のシーン連続性番号2601とを比較する(S2804)。そして、映像シーンが同じか否かを判定する(S2805)。
ステップS2805で同じ映像シーンと判定した場合には、次の位置にあるスライスセグメントだけを読み出す。そして、読み出したスライスセグメント位置の表示の更新を行う(S2806)。
ステップS2805で異なる映像シーンと判定した場合には、特殊再生の再生速度が低速か否かを判定する(S2807)。例えば、特殊再生速度が10倍速以下を低速とする。同様に、特殊再生速度が10倍速を超える場合を高速とする。なお、高速と低速の境は10倍速に限定しない。
ステップS2807で特殊再生の再生速度が高速である場合には、映像シーンを飛ばす幅が大きくなる。この場合には、映像シーン連続性番号2601の値が異なる可能性が高くなる。このような場合には、表示更新の応答性を重視して、ステップS2806に移動する。そして、次スライス箇所の表示更新を行う。ステップS2806の処理の後は、ステップS2802に戻る。
ステップS2807で特殊再生の再生速度が低速である場合には、全てのスライスセグメントに対して表示を更新する(S2808)。特殊再生速度が低速である場合には、ユーザーは所望の映像シーンを探している可能性が高い。そのため、応答性よりも画面の把握を重視する。なお、ステップS2807の特殊再生の再生速度に基づいた処理を行わず、ステップS2808へ移動してもよい。ステップS2808の処理の後は、ステップS2802に戻る。
図29は、優先スライス情報2602を用いた映像シーケンスの表示例を示した説明図である。特殊再生時の映像シーン(オリジナル画像)2900は、映像シーン#A1〜映像シーン#A5に順番に切り換わる。なお、映像シーン#A1〜映像シーン#A3は類似の映像シーンである。映像シーン#A1から映像シーン#A3まででは、一例として、アルファベットの「A」が右側に移動している。同様に、映像シーン#A4から映像シーン#A5は類似の映像シーンである。映像シーン#A4から映像シーン#A5まででは、一例として、アルファベットの「B」が右側に移動している。また、図29に示す例で、映像シーン#A1から映像シーン#A5は、上下に黒帯が付与されている。なお、表示を更新するスライスセグメントの位置を更新スライス箇所2710として矢印で図示する。
優先スライス制御を行わない場合の画面の表示例を映像シーン2901に示す。映像シーン#B1は、映像シーン#A1と同じである。映像シーン#B2では、映像シーン#B1に対して、スライスセグメント#2のみが映像シーン#A2のスライスセグメント#2に切り換わっている。映像シーン#B3では、映像シーン#B2に対して、スライスセグメント#3のみが映像シーン#A3のスライスセグメント#3に切り換わっている。映像シーン#B4では、映像シーン#B3に対して、スライスセグメント#4のみが映像シーン#A4のスライスセグメント#4に切り換わっている。映像シーン#B5では、映像シーン#B4に対して、スライスセグメント#1のみが映像シーン#A5のスライスセグメント#1に切り換わっている。
類似の映像シーンでなくなった映像シーン#B4は、オリジナルの映像シーン#A4とかなり異なる映像になる。類似の映像シーンでないとは、つまりシーンが連続でなくなったことである。同様に、映像シーン#B5もオリジナルの映像シーン#A5とかなり異なる映像になる。
異なる映像になる理由として、映像シーン#B4および映像シーン#B5において、画面上下に存在する黒帯部分の表示領域の更新を行っていることが挙げられる。ユーザーが画面を把握するのは黒帯部分以外の表示領域である。このため、黒帯部分の更新だけでは、ユーザーは画面の更新を認識できない。その結果、映像シーン#B4および映像シーン#B5には、オリジナル画像である映像シーン#A4と映像シーン#A5の画面情報がほとんど表示されない。このため、ユーザーがオリジナルの画像を認識することは困難となる。
優先スライス制御を行う場合の画面表示の例を映像シーン2902に示す。映像シーン#C1は、映像シーン#A1と同じである。映像シーン#C2では、映像シーン#C1に対して、スライスセグメント#3のみが映像シーン#A2のスライスセグメント#3に切り換わっている。映像シーン#C3では、映像シーン#C2に対して、スライスセグメント#2のみが映像シーン#A3のスライスセグメント#2に切り換わっている。映像シーン#C4では、映像シーン#C3に対して、スライスセグメント#3のみが映像シーン#A4のスライスセグメント#3に切り換わっている。映像シーン#C5では、映像シーン#C4に対して、スライスセグメント#2のみが映像シーン#A5のスライスセグメント#2に切り換わっている。
この例では、画面の把握に不要なスライスセグメントの表示の更新を行わない。これによって、画面の更新頻度と画面の認識性とを両立した特殊再生の表示方式となる。この例の映像シーン#C5部分では、オリジナル画像である映像シーン#A5に近い画像が表示されている。
図30は、優先スライス情報2602を用いた表示画面の更新を行うシーケンスを示すフローチャートである。
特殊再生が指示されると、表示画面のエントリーの優先スライス情報2602を読み込む。
優先スライス情報2602が「0b」の場合には、全てのスライスセグメントに対して表示画面を更新する。一方、優先スライス情報2602が「1b」の場合には、画面の中央部分にあるスライスセグメント#2とスライスセグメント#3とに限定して表示画面を更新する(S3001)。
特殊再生の停止の指示があった場合には、特殊再生の処理を終了する(S3008)。この場合には、図30中の「yes」を選択する。特殊再生の停止の指示がない場合には、ステップS3003に移る。この場合には、図30中の「no」を選択する。
ステップS3003では、タイムテーブル(TMSN)から再生位置のエントリー情報の読込みを行う(S3003)。その際、特殊再生の再生速度に応じて、エントリー情報の読み込み方法を決める。例えば、全てのエントリー情報を読み込むか、一部のエントリー情報を読み込むか等を決定する。一部のエントリー情報とは、再生速度に応じて、エントリーを1つおきに読み込んだり、2つおきに読み込んだりすることで、間引かれたエントリー情報を示す。
そして、読込んだエントリー情報の優先スライス情報2602の設定値の有無によって、優先スライスによる表示領域の制限があるか否かを判定する(S3004)。
ステップS3004で優先スライス情報2602の値が「1b」であれば、スライスセグメント#1とスライスセグメント#4の画面の表示領域を黒塗りする(S3005)。
上述のように、例えば、優先スライス情報2602の値が「1b」である場合には、画面中央のスライスセグメントであるスライスセグメント#2とスライスセグメント#3とに限定して、順番に表示画面を更新する。一方、優先スライス情報2602の値が「0b」である場合には、スライスセグメント#1からスライスセグメント#4までの全てを順番に更新する。
実施の形態4では、優先スライス情報が設定されていれば画面の中央部に限定して表示更新を行う。このため、画面の最上部と最下部のスライスセグメントの表示領域を黒塗りする。なお、ステップS3005の画面の黒塗り処理を行わなくてもよい。この場合には、例えば、以前のスライスセグメントの画像がそのまま表示される。
そして、画面の中央部であるスライスセグメント#2とスライスセグメント#3とに限定して、順次、スライスセグメントの表示画面の更新を行う(S3006)。
一方、ステップS3004で優先スライス情報の値が「0b」であれば、全てのスライスセグメント中で、順次、スライスセグメントの表示画面の更新を行う(S3007)。つまり、この場合には、特に画面の表示制限はない。
実施の形態4のように構成することで、特殊再生時にスライスセグメント単位で画面表示の更新を実施する際でも、表示画面の更新の応答性に優れ、表示画面の映像シーンが把握しやすい映像記録再生装置が提供できる。
また、シーン連続性番号2601と優先スライス情報2602との両方を用いて特殊再生時の表示制御を行うこともできる。つまり、ステップS3006の処理時にシーケンスが連続でなければ、すべての優先スライスを更新すればよい。同様に、ステップS3007の処理時にシーケンスが連続でなければ、全てのスライスを更新すればよい。
なお、タイムテーブル(TM)とタイムテーブル(TMSN)とを同一のテーブル情報をとして記録してもよい。または、タイムテーブル(TM)とタイムテーブル(TMSN)とを別テーブルとして管理し、別ファイルとして記録してもよい。
別ファイルとして記録した場合には、タイムテーブル(TM)を構成しているエントリーとタイムテーブル(TMSN)とを同一のエントリー情報として関連付けて記録する。タイムテーブル(TM)が編集されるとタイムテーブル(TMSN)との情報のマッチングがとれなくなる。このため、タイムテーブル(TMSN)にタイムテーブル(TM)のハッシュ情報を記録しておき、再生前にタイムテーブル(TMSN)とタイムテーブル(TM)との関連付けが正常であるか否かを確認するよう構成しても良い。
優先スライス情報2602が、タイムテーブル(TMSN)に存在する例を示したが、タイムテーブル(TMSN)の外に保持してもよい。この場合、エントリー毎に優先スライスを設定できないため、関連するすべてのエントリーで同一の設定となる。
なお、以上のように本発明の実施の形態について説明したが、本発明はこれらの実施の形態に限るものではない。
以上の各実施の形態を基にして、以下に発明の内容を付記として記載する。
<付記>
<付記1>
放送波を受け取るチューナー・復調部と、
前記放送波の多重化ストリームの多重化を解除する多重化解除部と、
前記多重化ストリームの多重化が解除された圧縮データを伸長するデコード部と、
前記デコード部で伸長されたデータから記録するための映像データまたは制御情報を収集する記録再生制御部と
を備え、
MMT形式を用いた前記放送波に含まれた映像データを記録する際に、パケットデータを結合した映像データとして記録することを特徴とする映像記録再生装置。
<付記2>
収集された前記映像データを再生する時刻と、当該時刻の映像データが記録されている位置とを含むタイムテーブルを作成し、前記収集された映像データと共に記録する付記1に記載の映像記録再生装置。
<付記3>
放送波を受け取るチューナー・復調部と、
前記放送波の多重化ストリームの多重化を解除する多重化解除部と、
前記多重化ストリームの多重化が解除された圧縮データを伸長するデコード部と、
前記デコード部で伸長されたデータから記録するための映像データまたは制御情報を収集する記録再生制御部と
を備え、
MMT形式を用いた前記放送波に含まれた映像データを記録する際に、BMFF形式のファイルとして前記映像データを記録することを特徴とする映像記録再生装置。
<付記4>
前記映像データを光ディスクに記録する際に、前記BMFF形式のファイルの管理データ部分とストリームデータ部分とを前記光ディスク上の異なった位置に記録することを特長とする付記3に記載の映像記録再生装置。
<付記5>
前記タイムテーブルにアセット情報を記録する付記2に記載の映像記録再生装置。
<付記6>
前記タイムテーブルにHDRメタデータを記録する付記2に記載の映像記録再生装置。
<付記7>
前記タイムテーブルにGOP内で最初にデコードされるIRAPピクチャのデータサイズまたは終了位置を記録する付記2に記載の映像記録再生装置。
<付記8>
前記タイムテーブルにGOP内の複数の画像の位置を記録する付記2に記載の映像記録再生装置。
<付記9>
前記映像データは画像を構成するスライスセグメントの構造を持ち、
前記タイムテーブルに前記スライスセグメントの単位での位置を記録する付記2に記載の映像記録再生装置。
<付記10>
前記パケットデータを結合または記録する際に、前記映像データを区切り、
区切られた前記映像データの先頭を、当該映像データにアクセスする際に用いるブロックの区切り位置に置く付記1に記載の映像記録再生装置。
<付記11>
前記映像データを区切る単位はGOPの単位である付記10に記載の映像記録再生装置。
<付記12>
前記映像データを区切る単位はピクチャの単位である付記10に記載の映像記録再生装置。
<付記13>
前記映像データを区切る位置はIRAPピクチャ先頭、Iピクチャ先頭またはPピクチャ先頭である付記10に記載の映像記録再生装置。
<付記14>
前記映像データを区切る単位はスライスセグメントの単位である付記10に記載の映像記録再生装置。
<付記15>
前記映像データを記録する際に、管理データとしてIピクチャのスライスセグメントの単位で前記映像データの読み出し位置の情報を記録する付記14に記載の映像記録再生装置。
<付記16>
前記読み出し位置の情報は、前記スライスセグメントの読み出し位置の情報である付記15に記載の映像記録再生装置。
<付記17>
前記映像データを記録する際に、GOPごとに前記スライスセグメントを記録する順序を入れ替える付記15または16に記載の映像記録再生装置。
<付記18>
前記映像データを再生する際に、画像ごとに一部の前記スライスセグメントを表示する付記15から17のいずれか1つに記載の映像記録再生装置。
<付記19>
前記一部のスライスセグメントは、前記画像ごとに表示される位置が変更される付記18に記載の映像記録再生装置。
100 映像記録再生装置、 11 チューナー・復調部、 12 外部入力部、 13 ネットワーク部、 21 多重化解除部、 31 音声デコード部、 32 映像デコード部、 33 字幕デコード・レンダリング部、 34 データ放送・EPG処理部、 41 記録再生制御部、 51 内蔵記録装置、 52 光ディスクドライブ、 53 光ディスク、 Af 管理用ファイル、 Hm 先頭のデータ、 Ba 放送波、 Sm 多重化ストリーム、 Se エレメンタリーストリーム、 Ds 音声データ、 Di,Di 映像データ、 Dc 字幕データ、 Db データ放送のデータ、 Dd 表示装置、 Es 音響装置、 Ei 外部装置、 Ne ネットワーク、 Ha 横軸、 Va,Va 縦軸、 P1,P2,P3 位置、 Pad パディング、 SI(MPT) 制御パケット、 TP TLVパケット、 TM,TMS タイムテーブル、 V 映像パケット、 V(RAP) 映像パケット、 2601 シーン連続性番号、 2602 優先スライス情報 2700 映像シーン(オリジナル)、 2701 画面表示例(シーン連続性制御なし)、 2702 画面表示例(シーン連続性制御あり)、 2710 更新スライス箇所、 2900 映像シーン(オリジナル)、 2901 画面表示例(優先スライス制御なし)、 2902 画面表示例(優先スライス制御あり)。

Claims (3)

  1. MMT方式を用いた放送ストリームを記録した記録データを再生する映像再生装置であって、
    前記記録データは、Iピクチャを含んで構成される映像情報と、前記Iピクチャの開始位置を示す第1のタイムテーブルと、前記Iピクチャを構成する複数のスライスセグメントの開始位置を示す第2のタイムテーブルと、前記映像情報を表示する画面の中で重要な情報が集中している部分の有無及び位置を示す優先スライス情報とを含み、
    前記優先スライス情報が示す前記部分の位置に基づいて、前記部分に表示させる前記スライスセグメントを早送り再生することを特徴とする映像再生装置。
  2. MMT方式を用いた放送ストリームを記録媒体に記録する映像記録装置であって、
    Iピクチャを含んで構成される映像情報を含む前記放送ストリームを記録し、
    前記Iピクチャの開始位置を示す第1のタイムテーブルを生成及び記録し、
    前記Iピクチャを構成する複数のスライスセグメントの開始位置を示す第2のタイムテーブルを生成及び記録し、
    前記映像情報を表示する画面の中で重要な情報が集中している部分の有無及び位置を示す優先スライス情報を生成及び記録する
    ことを特徴とする映像記録装置。
  3. MMT方式を用いた放送ストリームを記録する映像記録方法であって、
    Iピクチャを含んで構成される映像情報を含む前記放送ストリームを記録し、
    前記Iピクチャの開始位置を示す第1のタイムテーブルを生成及び記録し、
    前記Iピクチャを構成する複数のスライスセグメントの開始位置を示す第2のタイムテーブルを生成及び記録し、
    前記映像情報を表示する画面の中で重要な情報が集中している部分の有無及び位置を示す優先スライス情報を生成及び記録する
    ことを特徴とする映像記録方法。
JP2017138934A 2017-07-18 2017-07-18 映像再生装置、映像記録装置および映像記録方法 Active JP6415652B1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2017138934A JP6415652B1 (ja) 2017-07-18 2017-07-18 映像再生装置、映像記録装置および映像記録方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017138934A JP6415652B1 (ja) 2017-07-18 2017-07-18 映像再生装置、映像記録装置および映像記録方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2018187083A Division JP6600059B2 (ja) 2018-10-02 2018-10-02 映像再生装置および映像記録装置

Publications (2)

Publication Number Publication Date
JP6415652B1 true JP6415652B1 (ja) 2018-10-31
JP2019022079A JP2019022079A (ja) 2019-02-07

Family

ID=64017126

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017138934A Active JP6415652B1 (ja) 2017-07-18 2017-07-18 映像再生装置、映像記録装置および映像記録方法

Country Status (1)

Country Link
JP (1) JP6415652B1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6744262B2 (ja) * 2017-08-22 2020-08-19 株式会社東芝 電子装置及び方法
KR20210124226A (ko) 2019-02-08 2021-10-14 에이지씨 가부시키가이샤 함불소 에테르 화합물, 함불소 에테르 조성물, 코팅액, 물품, 물품의 제조 방법, 및 함불소 화합물의 제조 방법

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004357205A (ja) * 2002-06-04 2004-12-16 Matsushita Electric Ind Co Ltd 画像データ伝送装置及び方法、画像データ再生装置及び方法
JP2007060678A (ja) * 2006-10-02 2007-03-08 Mitsubishi Electric Corp 映像情報記録方法、および映像情報記録媒体
JP2009111605A (ja) * 2007-10-29 2009-05-21 Canon Inc 動画像データ送信方法、通信装置、及びプログラム
WO2014002619A1 (ja) * 2012-06-25 2014-01-03 ソニー株式会社 画像復号装置、画像復号方法、画像符号化装置及び画像符号化方法
JP2014030187A (ja) * 2012-07-02 2014-02-13 Canon Inc メディアファイル生成方法、メディアファイル生成プログラム
JP2015005977A (ja) * 2013-06-18 2015-01-08 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカPanasonic Intellectual Property Corporation of America 送信方法および受信方法
JP2015537421A (ja) * 2012-10-04 2015-12-24 クゥアルコム・インコーポレイテッドQualcomm Incorporated ビデオデータのためのファイルフォーマット
JP2016048859A (ja) * 2014-08-27 2016-04-07 シャープ株式会社 ファイル生成装置、再生装置

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004357205A (ja) * 2002-06-04 2004-12-16 Matsushita Electric Ind Co Ltd 画像データ伝送装置及び方法、画像データ再生装置及び方法
JP2007060678A (ja) * 2006-10-02 2007-03-08 Mitsubishi Electric Corp 映像情報記録方法、および映像情報記録媒体
JP2009111605A (ja) * 2007-10-29 2009-05-21 Canon Inc 動画像データ送信方法、通信装置、及びプログラム
WO2014002619A1 (ja) * 2012-06-25 2014-01-03 ソニー株式会社 画像復号装置、画像復号方法、画像符号化装置及び画像符号化方法
JP2014030187A (ja) * 2012-07-02 2014-02-13 Canon Inc メディアファイル生成方法、メディアファイル生成プログラム
JP2015537421A (ja) * 2012-10-04 2015-12-24 クゥアルコム・インコーポレイテッドQualcomm Incorporated ビデオデータのためのファイルフォーマット
JP2015005977A (ja) * 2013-06-18 2015-01-08 パナソニック インテレクチュアル プロパティ コーポレーション オブアメリカPanasonic Intellectual Property Corporation of America 送信方法および受信方法
JP2016048859A (ja) * 2014-08-27 2016-04-07 シャープ株式会社 ファイル生成装置、再生装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
RICKARD SJOBERG,ET AL.: "AHG4:Enabling decoder parallelism with tiles", JOINT COLLABORATIVE TEAM ON VIDEO CODING(JCT-VC) OF ITU-T SG16 WP3 AND ISO/IEC JTC1/SC29/WG11 9TH ME, vol. JCTVC-I0233, JPN6017020811, 17 April 2012 (2012-04-17), US, pages P.1-P.14 *

Also Published As

Publication number Publication date
JP2019022079A (ja) 2019-02-07

Similar Documents

Publication Publication Date Title
CA2432170C (en) Method and apparatus for storing a stream of video data on a storage medium
JP6964436B2 (ja) 映像記録装置及び映像再生装置
CN109757117B (zh) 内容记录装置、内容编辑装置、内容再生装置、内容记录方法、内容编辑方法、以及内容再生方法
KR100770908B1 (ko) 디지털 방송 스트림의 변속 재생 장치 및 방법
US7778526B2 (en) System and method for maintaining DVD-subpicture streams upon conversion to higher compressed data format
JP6415652B1 (ja) 映像再生装置、映像記録装置および映像記録方法
JP6600059B2 (ja) 映像再生装置および映像記録装置
KR20030091396A (ko) 방송신호의 위치정보 기록방법와 방송신호의 위치정보기록이 가능한 방송신호 수신장치 및 송출장치
JP2005018925A (ja) 録画再生装置及び録画再生方法
KR101731829B1 (ko) 디지털 영상 수신기의 디지털 콘텐츠 처리 장치 및 방법
JP6991185B2 (ja) 映像再生装置および映像記録装置
RU2525482C2 (ru) Устройство воспроизведения, способ воспроизведения, устройство записи, способ записи, программа и структура данных
JP2015109131A (ja) ファイル生成方法、再生方法、ファイル生成装置、再生装置および記録媒体
JP6982829B2 (ja) 記録装置、記録方法および記録媒体
JP2022156728A (ja) 映像再生装置および映像記録媒体
JPH11312381A (ja) 記録装置および方法、再生装置および方法、記録再生装置および方法、記録媒体、並びに提供媒体
WO2015083354A1 (ja) ファイル生成方法、再生方法、ファイル生成装置、再生装置および記録媒体
WO2012123982A1 (ja) 記録装置/方法/媒体、再生装置/方法
JP4941128B2 (ja) 映像処理装置
JP2008277930A (ja) 動画記録再生装置
JP2008061061A (ja) 録画再生装置
WO2013031307A1 (ja) 記録装置/方法/媒体、再生装置/方法
JP5120322B2 (ja) データ信号記録装置およびデータ信号再生装置
JP5120479B2 (ja) データ信号記録装置およびデータ信号再生装置
JP2009017380A (ja) 録画再生制御回路

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180816

RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7421

Effective date: 20180822

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180904

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181002

R150 Certificate of patent or registration of utility model

Ref document number: 6415652

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250