(57)【要約】  本開示は、ISO Base media file formatのファイルの欠損データの修復の再開を適切に行うことができるようにする情報処理装置および情報処理方法に関する。設定部は、ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報を設定する。修復部は、設定部により設定された修復情報に基づいて、欠損データを修復する。本開示は、例えば、ISO Base media file formatなどのフォーマットの放送データのファイルを受信し、記録する受信装置等に適用することができる。
2017061299.tif 000002
【特許請求の範囲】
【請求項１】
ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報を設定する設定部と、
前記設定部により設定された前記修復情報に基づいて、前記欠損データを修復する修復部と
を備える情報処理装置。
【請求項２】
前記設定部は、前記ファイルのデータが配置されるボックスとは異なるボックスに前記修復情報を設定する
ように構成された
請求項１に記載の情報処理装置。
【請求項３】
前記設定部は、前記ファイルのデータが配置されるボックスに含まれる、前記欠損データの位置とサイズを表す欠損情報が配置されるボックスとは異なるボックスに前記修復情報を設定する
ように構成された
請求項１に記載の情報処理装置。
【請求項４】
前記設定部は、前記ファイルの前記欠損データの位置とサイズを表す欠損情報が配置されるボックスに前記修復情報を設定する
ように構成された
請求項１に記載の情報処理装置。
【請求項５】
前記設定部は、前記ファイルを管理する管理ファイルに前記修復情報を設定する
ように構成された
請求項１に記載の情報処理装置。
【請求項６】
前記管理ファイルは、カプセル化される
ように構成された
請求項５に記載の情報処理装置。
【請求項７】
前記ファイルを特定する欠損ファイル情報を、前記ファイルを管理する管理ファイルに設定するファイル生成部
をさらに備える
請求項１に記載の情報処理装置。
【請求項８】
前記管理ファイルは、カプセル化される
ように構成された
請求項７に記載の情報処理装置。
【請求項９】
前記設定部は、前記ファイルとは異なるファイルである修復情報ファイルに前記修復情報を設定する
ように構成された
請求項１に記載の情報処理装置。
【請求項１０】
前記設定部は、前記修復情報ファイルに前記ファイルを特定する欠損ファイル特定情報を設定する
ように構成された
請求項９に記載の情報処理装置。
【請求項１１】
前記修復情報ファイルを特定する情報を、前記ファイルを管理する管理ファイルに設定するファイル生成部
をさらに備える
請求項９に記載の情報処理装置。
【請求項１２】
前記修復情報ファイルは、Initialization Segmentファイルである
ように構成された
請求項９に記載の情報処理装置。
【請求項１３】
前記修復情報は、前記ファイルの全ての前記欠損データの修復の途中であることを示す情報である
ように構成された
請求項１に記載の情報処理装置。
【請求項１４】
前記修復情報は、前記ファイルの全ての前記欠損データの修復が完了したことを示す情報である
ように構成された
請求項１に記載の情報処理装置。
【請求項１５】
前記修復情報は、前記修復部により前記修復が行われた前記欠損データを示す情報である
ように構成された
請求項１に記載の情報処理装置。
【請求項１６】
前記修復情報は、各欠損データの前記修復が成功した状態、前記修復が失敗した状態、または前記修復が行われていない状態を示す情報である
ように構成された
請求項１に記載の情報処理装置。
【請求項１７】
前記修復情報は、前記修復部により前記修復が行われた前記欠損データを示す情報と、前記修復が行われた各欠損データの前記修復が成功したか、または、失敗したかを示す情報である
ように構成された
請求項１に記載の情報処理装置。
【請求項１８】
情報処理装置が、
ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報を設定する設定ステップと、
前記設定ステップの処理により設定された前記修復情報に基づいて、前記欠損データを修復する修復ステップと
を含む情報処理方法。
【請求項１９】
ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定された前記ファイルを再生する再生部
を備える情報処理装置。
【請求項２０】
情報処理装置が、
ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定された前記ファイルを再生する再生ステップ
を含む情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報処理装置および情報処理方法に関し、特に、ISO Base media file formatのファイルの欠損データの修復の再開を適切に行うことができるようにした情報処理装置および情報処理方法に関する。
【背景技術】
【０００２】
現在、MPEG（Moving Picture Experts Group phase）の会合において、UDP(User Datagram Protocol)や放送などのデータの欠損が起き得るプロトコルで伝送されたファイルデータを保存する手法として、Partial File Storageという手法が検討されている（例えば、非特許文献１参照）。Partial File Storageとは、ISO base media file format(ISO/IEC 14496-12)に準拠して、欠損が発生したファイルデータをカプセル化する手法である。
【先行技術文献】
【非特許文献】
【０００３】
【非特許文献１】INTERNATIONAL ORGANISATION FOR STANDARDISATION ORGANISATION INTERNATIONALE DE NORMALISATION ISO/IEC JTC1/SC29/WG11 CODING OF MOVING PICTURES AND AUDIO,ISO/IEC JTC1/SC29/WG11,MPEG2015/N15478,June 2015
【発明の概要】
【発明が解決しようとする課題】
【０００４】
Partial File Storageで保存されたファイルデータは、保存後に欠損データが修復されることがある。しかしながら、修復が途中で中断されると、ファイル修復装置は、再開時に中断時の修復に関する情報がわからないため、修復済みの欠損データを再度修復したり、修復に失敗した欠損データに対して何度も修復を行ったりしてしまう。【０００５】
本開示は、このような状況に鑑みてなされたものであり、ISO Base media file formatのファイルの欠損データの修復の再開を適切に行うことができるようにするものである。
【課題を解決するための手段】
【０００６】
本開示の第１の側面の情報処理装置は、ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報を設定する設定部と、前記設定部により設定された前記修復情報に基づいて、前記欠損データを修復する修復部とを備える情報処理装置である。【０００７】
本開示の第１の側面の情報処理方法は、本開示の第１の側面の情報処理装置に対応する。【０００８】
本開示の第１の側面においては、ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定され、設定された前記修復情報に基づいて、前記欠損データが修復される。【０００９】
本開示の第２の側面の情報処理装置は、ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定された前記ファイルを再生する再生部を備える情報処理装置である。【００１０】
本開示の第２の側面の情報処理方法は、本開示の第２の側面の情報処理装置に対応する。【００１１】
本開示の第２の側面においては、ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定された前記ファイルが再生される。【００１２】
なお、本開示の第１および第２の側面の情報処理装置は、コンピュータにプログラムを実行させることにより実現することができる。【００１３】
また、本開示の第１および第２の側面の情報処理装置を実現するために、コンピュータに実行させるプログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して、提供することができる。
【発明の効果】
【００１４】
本開示の第１の側面によれば、欠損データを修復することができる。また、本開示の第１の側面によれば、ISO Base media file formatのファイルの欠損データの修復の再開を適切に行うことができる。【００１５】
本開示の第２の側面によれば、ファイルを再生することができる。また、本開示の第２の側面によれば、欠損データの修復の再開を適切に行うことができるISO Base media file formatのファイルを再生することができる。【００１６】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００１７】
【図１】本開示を適用した情報処理システムの第１実施の形態の構成例を示すブロック図である。
【図２】欠損ありファイルの第１の構造例を示す図である。
【図３】欠損ありファイルの第２の構造例を示す図である。
【図４】図２および図３のPartial File Container Boxのシンタックスの例を示す図である。
【図５】図４のOriginal Source URL Boxのシンタックスとセマンティクスの例を示す図である。
【図６】図４のPartially Corrupted File Boxのシンタックスの例を示す図である。
【図７】図４のPartially Corrupted File Boxのセマンティクスの例を示す図である。
【図８】図１の受信装置のファイル生成処理を説明するフローチャートである。
【図９】図１の受信装置のファイル修復処理を説明するフローチャートである。
【図１０】図９の欠損データ修復処理の詳細を説明するフローチャートである。
【図１１】第２実施の形態におけるPartially Corrupted File Boxのシンタックスの例を示す図である。
【図１２】第２実施の形態におけるPartially Corrupted File Boxのセマンティクスの例を示す図である。
【図１３】第２実施の形態におけるファイル修復処理を説明するフローチャートである。
【図１４】第３実施の形態におけるPartially Corrupted File Boxのシンタックスの例を示す図である。
【図１５】第３実施の形態における欠損データ修復処理を説明するフローチャートである。
【図１６】第４実施の形態における欠損ありファイルの第１の構造例を示す図である。
【図１７】第４実施の形態における欠損ありファイルの第２の構造例を示す図である。
【図１８】図１７のPartial File Container Boxのシンタックスの例を示す図である。
【図１９】図１６および図１７のRecovery Status Boxのシンタックスの第１の例を示す図である。
【図２０】図１６および図１７のRecovery Status Boxのシンタックスの第２の例を示す図である。
【図２１】第５実施の形態におけるファイル生成部の処理を説明する図である。
【図２２】欠損ありファイル情報と修復情報が設定されたMPDファイルの第１の構成例を示す図である。
【図２３】file_nameとfile_recovered_status_flagのセマンティクスの例を示す図である。
【図２４】欠損ありファイル情報と修復情報が設定されたMPDファイルの第２の構成例を示す図である。
【図２５】第６実施の形態におけるファイル生成部の処理を説明する図である。
【図２６】File Recovery Status Boxのシンタックスの例を示す図である。
【図２７】Corrupted File Indexファイル情報が設定されたMPDファイルの構成例を示す図である。
【図２８】第７実施の形態におけるファイル生成部３２の処理を説明する図である。
【図２９】欠損ありInitialization Segmentファイルの構成例を示す図である。
【図３０】Segment Corrupted Information Boxのシンタックスの例を示す図である。
【図３１】本開示を適用した情報処理システムの第８実施の形態の構成例を示すブロック図である。
【図３２】本開示を適用した情報処理システムの第９実施の形態の構成例を示すブロック図である。
【図３３】コンピュータのハードウエアの構成例を示すブロック図である。
【発明を実施するための形態】
【００１８】
以下、および本開示を実施するための形態（以下、実施の形態という）について説明する。なお、説明は以下の順序で行う。
１．第１実施の形態：情報処理システム（図１乃至図１０）
２．第２実施の形態：情報処理システム（図１１乃至図１３）
３．第３実施の形態：情報処理システム（図１４および図１５）
４．第４実施の形態：情報処理システム（図１６乃至図２０）
５．第５実施の形態：情報処理システム（図２１乃至図２４）
６．第６実施の形態：情報処理システム（図２５乃至図２７）
７．第７実施の形態：情報処理システム（図２８乃至図３０）
８．第８実施の形態：情報処理システム（図３１）
９．第９実施の形態：情報処理システム（図３２）
１０．第１０実施の形態：コンピュータ（図３３）
【００１９】
＜第１実施の形態＞
（情報処理システムの第１実施の形態の構成例）
図１は、本開示を適用した情報処理システムの第１実施の形態の構成例を示すブロック図である。
【００２０】
図１の情報処理システム１０は、放送局１１、受信装置１２（情報処理装置）、およびHTTP（HyperText Transfer Protocol）サーバ１３により構成される。情報処理システム１０では、受信装置１２が、放送局１１から放送データのファイルを受信し、その放送データのファイルの欠損データをHTTPサーバ１３から取得したデータを用いて修復する。
【００２１】
具体的には、情報処理システム１０の放送局１１は、MPEG2方式などで符号化された放送データのISO Base media file formatなどのフォーマットに準拠したファイルを、図示せぬアンテナなどを介して受信装置１２に送信する。
【００２２】
受信装置１２は、放送受信部３１、ファイル生成部３２、設定部３３、記録部３４、修復部３５、およびHTTP受信部３６により構成される。
【００２３】
受信装置１２の放送受信部３１は、図示せぬアンテナなどを介して、放送局１１から送信されてくる放送データのファイルを受信し、ファイル生成部３２に供給する。
【００２４】
ファイル生成部３２は、放送受信部３１から供給される放送データのファイルに欠損データが存在するかどうかを判定する。放送データのファイルに欠損データが存在しないと判定された場合、ファイル生成部３２は、放送データからISO Base media file formatのファイル（以下、欠損なしファイルという）を生成する。
【００２５】
一方、放送データのファイルに欠損データが存在すると判定された場合、ファイル生成部３２は、Partial File Storageという手法で、放送データからISO Base media file formatに準拠したファイル（以下、欠損ありファイルという）を生成する。欠損ありファイルには、その欠損ありファイルの欠損データの修復の状態を示す修復情報のデフォルト値が、設定部３３により設定される。ファイル生成部３２は、欠損なしファイルと、修復情報のデフォルト値が設定された欠損ありファイルを、記録部３４に供給する。
【００２６】
設定部３３は、ファイル生成部３２により生成される欠損ありファイルに修復情報のデフォルト値を設定する。また、設定部３３は、修復部３５から供給される修復済みの欠損データの数を表す修復済み情報に基づいて、記録部３４に記録されている欠損ありファイルに設定された修復情報を更新する。
【００２７】
記録部３４は、ファイル生成部３２から供給される欠損なしファイルと欠損ありファイルを記録する。
【００２８】
修復部３５は、記録部３４に記録されている欠損ありファイルのうちの１つを修復対象ファイルとして選択する。修復部３５は、修復対象ファイルに含まれる修復情報に基づいて、所定の欠損データを修復対象データに決定する。
【００２９】
修復部３５は、修復対象ファイルの生成に用いられた放送データのファイルに対応する、欠損データが存在しない場合のファイル（以下、修復用ファイルという）のURL（Uniform Resource Locator）情報などの取得先情報を、修復対象ファイルから取得し、HTTP受信部３６に供給する。修復部３５は、取得先情報の供給に応じてHTTP受信部３６から供給される修復用ファイルを用いて欠損データを修復する。修復部３５は、修復済み情報を設定部３３に供給する。
【００３０】
HTTP受信部３６は、修復部３５から供給される取得先情報に基づいてHTTPサーバ１３と通信を行い、HTTPサーバ１３に保持されている修復用ファイルを取得する。HTTP受信部３６は、取得された修復用ファイルを修復部３５に供給する。
【００３１】
（欠損ありファイルの第１の構造例）
図２は、欠損ありファイルの第１の構造例を示す図である。
【００３２】
図２に示すように、欠損ありファイルは、ISO base media file formatのBox構造のPartial File Container Boxにより構成される。Partial File Container Boxでは、放送受信部３１により受信された欠損データが存在する放送データのファイルがカプセル化される。
【００３３】
具体的には、Partial File Container Boxは、Top Level Box Index Box, Original Source URL Box, Partially Corrupted File Box、およびfile_dataにより構成される最上位のBoxである。
【００３４】
Top Level Box Index Boxには、所定のレベルのBoxの位置を示す情報が記述される。Original Source URL Boxには、修復用ファイルの取得先情報としてURL情報が記述される。Partially Corrupted File Boxには、欠損データの位置とサイズを表す欠損情報、修復情報等が記述される。file_dataは、放送受信部３１により受信されたファイルの欠損データ(Corrupted data)の部分にダミーデータが配置された放送データである。従って、file_dataのサイズは、放送受信部３１により受信されるべきファイルのサイズと同一である。
【００３５】
（欠損ありファイルの第２の構造例）
図３は、欠損ありファイルの第２の構造例を示す図である。
【００３６】
図３の欠損ありファイルの構造は、file_dataを除いて、図２の構造と同一である。図３のfile_dataは、放送受信部３１により受信されたファイルの欠損データの部分にダミーデータを配置せず、欠損データの部分を詰めた放送データである。
【００３７】
（Partial File Container Boxのシンタックスの例）
図４は、図２および図３のPartial File Container Boxのシンタックス(syntax)の例を示す図である。
【００３８】
図４に示すように、Partial File Container BoxのTop Level Box Index BoxとOriginal Source URL Boxは、配置されてもされなくてもよいBox（Optional Box）である。Partially Corrupted File Boxは、必ず配置されるBox(mandatory Box)である。
【００３９】
（Original Source URL Boxのシンタックスとセマンティクスの例）
図５は、Original Source URL Boxのシンタックスとセマンティクス（semantics）の例を示す図である。具体的には、図５のＡは、Original Source URL Boxのシンタックスの例を示す図であり、図５のＢは、セマンティクスの例を示す図である。
【００４０】
図５に示すように、Original Source URL Boxには、file_dataに対応する修復用ファイルのURL情報（url）が記述される。図１のHTTP受信部３６は、このURL情報に基づいてHTTPサーバ１３から修復ファイルを取得する。
【００４１】
欠損ありファイルの構造が図２の構造である場合、修復部３５は、file_dataのダミーデータを、そのダミーデータに対応する修復用ファイルの欠損していない放送データに置換することにより、欠損データを修復する。一方、欠損ありファイルの構造が図３の構造である場合、修復部３５は、修復用ファイルのfile_dataに存在しない放送データをfile_dataに挿入することにより、欠損データを修復する。
【００４２】
（Partially Corrupted File Boxのシンタックスとセマンティクスの例）
図６は、Partially Corrupted File Boxのシンタックスの例を示す図であり、図７は、セマンティクスの例を示す図である。
【００４３】
図６に示すように、Partially Corrupted File Boxには、「version」と「flags」が記述される。図７に示すように、「version」は、このPartially Corrupted File Boxのバージョンを示す情報である。「flags」は、PCFB_BYTES_REMOVEDフラグ、All_Corrupted_Data_was_tried_to_recoverフラグ、およびNOW_recoveringフラグにより構成される。
【００４４】
PCFB_BYTES_REMOVEDフラグは、flagsの最下位ビットに値が設定される、file_dataにダミーデータを存在しないかどうかを示すフラグである。PCFB_BYTES_REMOVEDフラグは、file_dataにダミーデータが存在しないことを示す場合１であり、file_dataにダミーデータが存在する場合０である。即ち、欠損ありファイルの構造が図３の構造である場合、PCFB_BYTES_REMOVEDフラグは１に設定され、欠損ありファイルの構造が図２の構造である場合、PCFB_BYTES_REMOVEDフラグは０に設定される。
【００４５】
All_Corrupted_Data_was_tried_to_recoverフラグは、flagsの下から２ビット目に値が設定される、file_dataの全ての欠損データの修復が少なくとも１度完了したかどうかを示すフラグであり、修復情報の１つである。All_Corrupted_Data_was_tried_to_recoverフラグは、file_dataの全ての欠損データの修復が少なくとも１度完了したことを示す場合１であり、まだ完了していないことを示す場合０である。
【００４６】
NOW_recoveringフラグは、flagsの下から３ビット目に値が設定される、file_dataの全ての欠損データの修復が途中であるかどうかを示すフラグであり、修復情報の１つである。NOW_recoveringフラグは、file_dataの全ての欠損データの修復の途中であることを示す場合１であり、途中ではないことを示す場合０である。
【００４７】
以上により、file_dataの全ての欠損データの修復がまだ開始されていない場合、All_Corrupted_Data_was_tried_to_recoverフラグとNOW_recoveringフラグは０に設定される。また、file_dataの全ての欠損データの修復が開始されたが、まだ修復の途中である場合、All_Corrupted_Data_was_tried_to_recoverフラグは０に設定されるが、NOW_recoveringフラグは１に設定される。さらに、file_dataの全ての欠損データの修復が少なくとも１度完了した場合、All_Corrupted_Data_was_tried_to_recoverフラグは１に設定されるが、NOW_recoveringフラグは０に設定される。
【００４８】
図６に示すように、Partially Corrupted File Boxにはまた、entry_countとnum_of_recoveredが記述される。図７に示すように、entry_countは、file_dataの欠損データの数である。num_of_recoveredは修復が行われた欠損データの数を示す情報であり、修復情報の１つである。
【００４９】
従って、num_of_recoveredが０である場合、flagsのAll_Corrupted_Data_was_tried_to_recoverフラグとNOW_recoveringフラグは０である。また、num_of_recoveredが、０以外であり、かつ、entry_countより小さい場合、flagsのAll_Corrupted_Data_was_tried_to_recoverフラグは０であり、NOW_recoveringフラグは１である。さらに、num_of_recoveredがentry_countと同一である場合、flagsのAll_Corrupted_Data_was_tried_to_recoverフラグは１であり、NOW_recoveringフラグは０である。
【００５０】
図６に示すように、Partially Corrupted File Boxにはまた、file_dataの各欠損データに対してエントリが生成され、先頭のエントリから順に、各エントリのbyte_offsetとcorrupted_sizeが欠損情報として記述される。図７に示すように、byte_offsetは、欠損データの開始位置をfile_dataの先頭からのオフセット量で示すオフセット情報である。「version」が１である場合、オフセット情報のビット長は64bitであり、１ではない場合、32bitである。また、corrupted_sizeは、欠損データのサイズを示す情報である。
【００５１】
なお、修復は、先頭のエントリに対応する欠損データから順に行われる。従って、num_of_recoveredは、最後に修復が行われた欠損データに対応するエントリが先頭から何番目のエントリであるかを示す情報であるともいえる。
【００５２】
Partially Corrupted File Boxが、図６および図７で説明したように構成されることにより、修復部３５は、修復対象ファイルのflagsに基づいて、修復対象ファイルの修復が未実行であるか、途中であるか、または完了しているかを認識することができる。また、修復部３５は、修復対象ファイルの修復が途中で中断されている場合に、修復対象ファイルのentry_countに基づいて、中断位置から修復を再開することができる。
【００５３】
（受信装置の処理の説明）
図８は、図１の受信装置１２のファイル生成処理を説明するフローチャートである。このファイル生成処理は、放送局１１から放送データのファイルが送信されてきたとき、開始される。
【００５４】
図８のステップＳ１１において、受信装置１２の放送受信部３１は、図示せぬアンテナなどを介して、放送局１１から送信されてくる放送データのファイルを受信し、ファイル生成部３２に供給する。
【００５５】
ステップＳ１２において、ファイル生成部３２は、放送受信部３１から供給される放送データのファイルに欠損データが存在するかどうかを判定する。
【００５６】
ステップＳ１２で放送データのファイルに欠損データが存在すると判定された場合、ステップＳ１３において、ファイル生成部３２は、Partial File Storageという手法で、放送データから欠損ありファイルを生成する。
【００５７】
ステップＳ１４において、設定部３３は、修復情報のデフォルト値を、ファイル生成部３２により生成された欠損ありファイルのPartially Corrupted File Boxに設定する。なお、修復情報のデフォルト値は０である。
【００５８】
ステップＳ１５において、設定部３３は、修復情報のデフォルト値が設定された欠損ありファイルを記録部３４に供給し、記録させる。そして、処理は終了する。
【００５９】
一方、ステップＳ１２で放送データのファイルに欠損データが存在しないと判定された場合、ステップＳ１６において、ファイル生成部３２は、放送データから欠損なしファイルを生成する。
【００６０】
ステップＳ１７において、ファイル生成部３２は、欠損なしファイルを記録部３４に供給し、記録させる。そして、処理は終了する。
【００６１】
図９は、図１の受信装置１２のファイル修復処理を説明するフローチャートである。このファイル修復処理は、例えば、修復部３５が、記録部３４に記録されている欠損ありファイルのうちの１つを修復対象ファイルとして選択したとき開始される。
【００６２】
図９のステップＳ３１において、受信装置１２の修復部３５は、記録部３４に記録されている修復対象ファイルのPartial File Container Boxを読み出す。ステップＳ３２において、修復部３５は、ステップＳ３１で読み出されたPartial File Container BoxからPartially Corrupted File Boxを取得する。
【００６３】
ステップＳ３３において、修復部３５は、ステップＳ３２で取得されたPartially Corrupted File Boxからflagsを取得する。
【００６４】
ステップＳ３４において、修復部３５は、flagsに基づいて、All_Corrupted_Data_was_tried_to_recoverフラグが１に設定されているかどうか、即ちflagsの下から２ビット目に１が設定されているかどうかを判定する。
【００６５】
ステップＳ３４でAll_Corrupted_Data_was_tried_to_recoverフラグが１に設定されていると判定された場合、即ち修復対象ファイルの全ての欠損データの修復が少なくとも１度完了している場合、処理は終了する。
【００６６】
一方、ステップＳ３４で、All_Corrupted_Data_was_tried_to_recoverフラグが１に設定されていないと判定された場合、即ち修復対象ファイルの全ての欠損データの修復がまだ１度も完了していない場合、処理はステップＳ３５に進む。
【００６７】
ステップＳ３５において、修復部３５は、flagsに基づいて、NOW_recoveringフラグが１に設定されているかどうか、即ちflagsの下から３ビット目に１が設定されているかどうかを判定する。
【００６８】
ステップＳ３５でNOW_recoveringフラグが１に設定されていると判定された場合、即ち修復対象ファイルの全ての欠損データの修復が途中で中断されている場合、処理はステップＳ３６に進む。
【００６９】
ステップＳ３６において、修復部３５は、ステップＳ３２で取得されたPartially Corrupted File Boxからnum_of_recoveredを取得し、処理をステップＳ３７に進める。
【００７０】
一方、ステップＳ３５でNOW_recoveringフラグが１に設定されていないと判定された場合、即ち修復対象ファイルの全ての欠損データの修復がまだ開始されていない場合、修復部３５は、num_of_recoveredが０であると認識する。そして、処理はステップＳ３７に進む。
【００７１】
なお、図９の例では、ステップＳ３５でNOW_recoveringフラグが１に設定されていないと判定された場合、修復部３５は、num_of_recoveredが０であると認識するようにするが、Partially Corrupted File Boxからnum_of_recoveredとして０を取得するようにしてもよい。
【００７２】
ステップＳ３７において、修復部３５は、読み出されたPartial File Container BoxからOriginal Source URL Boxを取得する。
【００７３】
ステップＳ３８において、修復部３５は、修復対象ファイルの欠損データを順に修復する欠損データ修復処理を行う。この欠損データ修復処理の詳細は、後述する図１０を参照して説明する。
【００７４】
図１０は、図９のステップＳ３８の欠損データ修復処理の詳細を説明するフローチャートである。
【００７５】
図１０のステップＳ５１において、修復部３５は、カウント値ｉを、取得または認識されたnum_of_recoveredに１を加算した値に設定する。ステップＳ５２において、修復部３５は、カウント値ｉが、Partially Corrupted File Boxに含まれるentry_count以下であるかどうかを判定する。
【００７６】
ステップＳ５２でカウント値がentry_count以下であると判定された場合、即ち、修復対象ファイルの全ての欠損データの修復がまだ完了していない場合、修復部３５は、Partially Corrupted File Boxの先頭からｉ番目のエントリに対応する欠損データを修復対象データに決定する。
【００７７】
そして、ステップＳ５３において、修復部３５は、Original Source URL Boxに記述されるURL情報をHTTP受信部３６に供給することにより、HTTPサーバ１３に保持されている修復用ファイルのｉ番目のエントリに対応する放送データを修復用データとして、HTTP受信部３６を介して取得する。ステップＳ５４において、修復部３５は、Partially Corrupted File Boxに記述される先頭からｉ番目のエントリの欠損情報と修復用データとに基づいて、そのエントリに対応する修復対象データの修復を行う。そして、修復部３５は、カウント値ｉを修復済み情報として設定部３３に供給する。
【００７８】
ステップＳ５５において、修復部３５は、欠損データ修復処理を中止するかどうかを判定する。ステップＳ５５で欠損データ修復処理を中止しないと判定された場合、ステップＳ５６において、修復部３５は、カウント値を１だけインクリメントする。そして、処理はステップＳ５２に戻る。
【００７９】
一方、ステップＳ５５で欠損データ修復処理を中止すると判定された場合、処理はステップＳ５７に進む。ステップＳ５７において、設定部３３は、記録部３４に記録されている修復対象ファイルのNOW_recoveringフラグを１に設定（更新）し、処理をステップＳ５９に進める。
【００８０】
また、ステップＳ５２でカウント値がentry_countより大きいと判定された場合、即ち全ての欠損データの修復が完了した場合、処理はステップＳ５８に進む。ステップＳ５８において、設定部３３は、記録部３４に記録されている修復対象ファイルのAll_Corrupted_Data_was_tried_to_recoverフラグを１に設定し、NOW_recoveringフラグを０に設定する。そして、処理はステップＳ５９に進む。
【００８１】
ステップＳ５９において、設定部３３は、記録部３４に記録されている修復対象ファイルのnum_of_recoveredに、修復部３５から供給される修復済み情報が表すカウント値ｉを設定する。そして、処理は図９のステップＳ３８に戻り、処理は終了する。
【００８２】
以上のように、受信装置１２は、欠損ありファイルの修復情報を設定するので、欠損ありファイルの修復時に、その欠損ありファイルの修復の状態を容易に認識することができる。これにより、受信装置１２は、途中で修復が中断された欠損ありファイルの修復を再開する場合に修復済みのデータを再度修復したり、修復に失敗したデータに対して何度も修復を行ったりすることなく、中断位置から適切に修復を再開することができる。その結果、ファイルの修復処理の負荷が軽減される。
【００８３】
これに対して、修復情報が設定されない場合、受信装置は、修復と同時に、entry_countの更新や欠損情報の削除等の処理を行うことにより、修復の再開時に修復の中断時の状態を認識することができる。しかしながら、この処理は煩雑であり、また、処理の結果Partially Corrupted File Boxのサイズが変更されるため、Partially Corrupted File Box以降のデータの書き直し等が必要になる。従って、ファイルの修復処理の負荷が大きい。
【００８４】
＜第２実施の形態＞
（Partially Corrupted File Boxのシンタックスとセマンティクスの例）
本開示を適用した情報処理システムの第２実施の形態は、修復情報、および、修復済み情報の代わりに各欠損データの修復の成功または失敗を表す修復結果情報が修復部３５から設定部３３に供給される点を除いて、第１実施の形態と同一である。従って、以下では、図１の各部を情報処理システムの第２実施の形態の各部として用いて、修復情報および修復結果情報に関する処理についてのみ説明する。
【００８５】
図１１は、第２実施の形態におけるPartially Corrupted File Boxのシンタックスの例を示す図であり、図１２は、セマンティクスの例を示す図である。
【００８６】
図１１および図１２のPartially Corrupted File Boxの構成は、flagsがPCFB_BYTES_REMOVEDフラグのみから構成される点、num_of_recoveredが記述されない点、およびエントリごとにrecovered_flagが新たに記述される点が、図６および図７の構成と異なる。即ち、第２実施の形態における修復情報は、flagsとnum_of_recoveredではなく、recovered_flagである。
【００８７】
各エントリのrecovered_flagは、そのエントリに対応する欠損データの修復が成功した状態、修復が失敗した状態、または修復が行われていない状態を示すフラグであり、修復情報である。recovered_flagは、RecoveredフラグとFailed_to_recoverフラグにより構成される。
【００８８】
図１２に示すように、Recoveredフラグは、recovered_flagの最下位ビットに値が設定される、修復が成功した状態であるかどうかを示すフラグである。Recoveredフラグは、修復が成功した状態であることを示す場合１であり、修復が成功した状態ではないことを示す場合０である。
【００８９】
Failed_to_recoverフラグは、recovered_flagの下から２番目のビットに値が設定される、修復が失敗した状態であるかどうかを示すフラグである。Failed_to_recoverフラグは、修復が失敗した状態であることを示す場合１であり、修復が失敗した状態ではないことを示す場合０である。
【００９０】
従って、RecoveredフラグとFailed_to_recoverフラグが０である場合、修復が行われていない状態を示している。よって、修復情報のデフォルト値は０である。
【００９１】
Partially Corrupted File Boxが、図１１および図１２で説明したように構成されることにより、修復部３５は、修復対象ファイルの各エントリのrecovered_flagに基づいて、そのエントリに対応する欠損データの修復の実行の有無および成功の有無を認識することができる。
【００９２】
（受信装置の処理の説明）
第２実施の形態におけるファイル生成処理は、図８のファイル生成処理と同様であるので、説明は省略する。
【００９３】
図１３は、第２実施の形態における受信装置１２のファイル修復処理を説明するフローチャートである。
【００９４】
図１３のステップＳ７１およびＳ７２の処理は、図９のステップＳ３１およびＳ３２の処理と同様であるので、説明は省略する。ステップＳ７３の処理は、図９のステップＳ３７の処理と同様であるので、説明は省略する。
【００９５】
ステップＳ７４において、受信装置１２の修復部３５は、カウント値ｉを１に設定する。ステップＳ７５において、修復部３５は、ステップＳ７２で取得されたPartially Corrupted File Boxに記述される先頭からｉ番目のエントリのrecovered_flagを取得する。
【００９６】
ステップＳ７６において、修復部３５は、ステップＳ７５で取得されたrecovered_flagが０であるかどうか、即ちRecoveredフラグおよびFailed_to_recoverフラグが０であるかどうかを判定する。
【００９７】
ステップＳ７６でrecovered_flagが０であると判定された場合、即ちｉ番目のエントリに対応する欠損データに対してまだ修復が行われていない場合、修復部３５は、ｉ番目のエントリに対応する欠損データを修復対象データに決定する。
【００９８】
そして、ステップＳ７７において、修復部３５は、Original Source URL Boxに記述されるURL情報をHTTP受信部３６に供給することにより、HTTPサーバ１３に保持されている修復用ファイルのｉ番目のエントリに対応する放送データを修復用データとして、HTTP受信部３６を介して取得する。ステップＳ７８において、修復部３５は、ｉ番目のエントリの欠損情報と修復用データとに基づいて、そのエントリに対応する修復対象データの修復を行う。
【００９９】
ステップＳ７９において、修復部３５は、ステップＳ７８の修復が成功したかどうかを判定する。例えば、修復部３５は、Original Source URL Boxに記述されるURL情報に対応してHTTPサーバ１３に修復用ファイルが存在せず、ステップＳ７７において修復用ファイルの取得に失敗している場合、修復部３５は、修復が成功していないと判定する。
【０１００】
ステップＳ７９で修復が成功したと判定された場合、修復部３５は、ｉ番目のエントリに対応する修復対象データの修復の成功を表す修復結果情報を設定部３３に供給する。
【０１０１】
そして、ステップＳ８０において、設定部３３は、記録部３４に記録されている修復対象ファイルのｉ番目のエントリのRecoveredフラグを１に設定し、処理をステップＳ８２に進める。
【０１０２】
一方、ステップＳ７９で修復が成功していないと判定された場合、修復部３５は、ｉ番目のエントリに対応する修復対象データの修復の失敗を表す修復結果情報を設定部３３に供給する。
【０１０３】
そして、ステップＳ８１において、設定部３３は、記録部３４に記録されている修復対象ファイルのｉ番目のエントリのFailed_to_recoverフラグを１に設定し、処理をステップＳ８２に進める。
【０１０４】
また、ステップＳ７６でrecovered_flagが０ではないと判定された場合、即ちｉ番目のエントリに対応する欠損データに対して既に修復が行われている場合、処理はステップＳ８２に進む。
【０１０５】
ステップＳ８２において、修復部３５は、ファイル修復処理を中止するかどうかを判定する。ステップＳ８２でファイル修復処理を中止しないと判定された場合、処理はステップＳ８３に進む。ステップＳ８３において、設定部３３は、カウント値ｉを１だけインクリメントする。
【０１０６】
ステップＳ８４において、設定部３３は、カウント値ｉが、Partially Corrupted File Boxに記述されるentry_count以下であるかどうかを判定する。ステップＳ８４でカウント値ｉがentry_count以下であると判定された場合、処理はステップＳ７５に戻り、以降の処理が繰り返される。
【０１０７】
一方、ステップＳ８２でファイル修復処理を中止すると判定された場合、処理は終了する。また、ステップＳ８４でカウント値ｉがentry_countより大きいと判定された場合、即ち全ての欠損データの修復が行われた場合、処理は終了する。
【０１０８】
以上のように、第２実施の形態では、修復情報が、各欠損データの修復が成功した状態、失敗した状態、または行われていない状態を示す情報である。従って、受信装置１２は、各欠損データの修復の実行の有無だけでなく、その修復の成功の有無も認識することができる。
【０１０９】
＜第３実施の形態＞
（Partially Corrupted File Boxのシンタックスの例）
本開示を適用した情報処理システムの第３実施の形態は、第１実施の形態および第２実施の形態を組み合わせたものである。即ち、第３実施の形態では、修復情報が、flags，num_of_recovered、およびrecovered_flagであり、修復済み情報と修復結果情報が修復部３５から設定部３３に供給される。従って、以下では、図１の各部を情報処理システムの第３実施の形態の各部として用いて、修復情報、修復済み情報、および修復結果情報に関する処理についてのみ説明する。
【０１１０】
図１４は、第３実施の形態におけるPartially Corrupted File Boxのシンタックスの例を示す図である。
【０１１１】
図１４のPartially Corrupted File Boxの構成は、エントリごとにrecovered_flagが新たに記述される点が、図６の構成と異なる。
【０１１２】
（受信装置の処理の説明）
第３実施の形態におけるファイル生成処理は、図８のファイル生成処理と同様であるので、説明は省略する。また、第３実施の形態におけるファイル修復処理は、ステップＳ３８の欠損データ修復処理を除いて図９のファイル修復処理と同様であるので、以下では、欠損データ修復処理についてのみ説明する。
【０１１３】
図１５は、第３実施の形態における受信装置１２の欠損データ修復処理を説明するフローチャートである。
【０１１４】
図１５のステップＳ１００乃至Ｓ１０３の処理は、図１０のステップＳ５１乃至Ｓ５４の処理と同様であり、ステップＳ１０４乃至Ｓ１０６の処理は、図１３のステップＳ７９乃至Ｓ８１の処理と同様である。また、ステップＳ１０７乃至Ｓ１１１の処理は図１０のステップＳ５５乃至Ｓ５９の処理と同様である。
【０１１５】
＜第４実施の形態＞
（欠損ありファイルの第１の構造例）
本開示を適用した情報処理システムの第４実施の形態は、修復情報がPartially Corrupted File Boxとは異なる新たなBoxに設定される点を除いて、第３実施の形態と同一である。従って、以下では、図１の各部を情報処理システムの第４実施の形態の各部として用いて、欠損ありファイルの構造についてのみ説明する。
【０１１６】
図１６は、第４実施の形態における欠損ありファイルの第１の構造例を示す図である。
【０１１７】
図１６の欠損ありファイルの構造は、Partially Corrupted File Boxに修復情報が記述されない点、および、欠損ありファイルがPartial File Container Boxと修復情報が配置されるRecovery Status Boxの２つのBoxから構成される点が、図２の構造と異なっている。
【０１１８】
図１６のPartially Corrupted File Boxのシンタックスは、flagsがPCFB_BYTES_REMOVEDフラグのみからなる点、および、num_of_recoveredが配置されない点を除いて、図６のシンタックスと同一であるため、説明は省略する。
【０１１９】
Recovery Status Boxは、Partial File Container Boxと同一の階層のBoxである。
【０１２０】
（欠損ありファイルの第２の構造例）
図１７は、第４実施の形態における欠損ありファイルの第２の構造例を示す図である。
【０１２１】
図１７の欠損ありファイルの構造は、Recovery Status BoxがPartial File Container Box内に配置される点が、図１６の構造と異なっている。
【０１２２】
以上のように、第４実施の形態では、修復情報がPartially Corrupted File Boxとは異なるBoxに配置されるので、修復情報の設定を容易に行うことができる。
【０１２３】
なお、図示は省略するが、図１６および図１７の欠損ありファイルにおいて、図３の場合と同様に、file_dataにダミーデータが配置されないようにしてもよい。
【０１２４】
（Partial File Container Boxのシンタックスの例）
図１８は、図１７のPartial File Container Boxのシンタックスの例を示す図である。
【０１２５】
図１８のPartial File Container Boxのシンタックスは、Recovery Status Boxが新たに配置される点を除いて、図４のシンタックスと同一である。
【０１２６】
（Recovery Status Boxのシンタックスの第１の例）
図１９は、図１６および図１７のRecovery Status Boxのシンタックスの第１の例を示す図である。
【０１２７】
図１９のRecovery Status Boxには、flags,entry_count、およびnum_of_recoveredが記述される。また、Recovery Status Boxには、エントリごとにrecovered_flagが記述される。従って、Recovery Status Boxに記述されるrecovered_flagの数はentry_countである。
【０１２８】
（Recovery Status Boxのシンタックスの第２の例）
図２０は、図１６および図１７のRecovery Status Boxのシンタックスの第２の例を示す図である。
【０１２９】
図２０のRecovery Status Boxのシンタックスは、entry_countが記述されない点、および、file_dataの欠損データのうちの修復が行われた欠損データのrecovered_flagのみが配置される点が、図１９のシンタックスと異なる。
【０１３０】
図２０のRecovery Status Boxでは、file_dataの欠損データのうちの修復が行われた欠損データのrecovered_flagのみが配置されるので、recovered_flagの数は、entry_countではなく、num_of_recoveredである。従って、全ての欠損データの修復が完了していない場合、図２０のRecovery Status Boxのデータサイズは、recovered_flagの数がentry_countである図１９のRecovery Status Boxのデータサイズに比べて小さくなる。
【０１３１】
また、図２０の場合、recovered_flagのRecoveredフラグとFailed_to_recoverフラグのいずれかが、必ず１に設定される。即ち、recovered_flagは、修復が行われていない状態を示す０にはならない。
【０１３２】
なお、第４実施の形態では、第３実施の形態の修復情報がPartially Corrupted File Boxとは異なる新たなBoxに設定されたが、第１実施の形態または第２実施の形態の修復情報がPartially Corrupted File Boxとは異なる新たなBoxに設定されてもよい。
【０１３３】
＜第５実施の形態＞
（ファイル生成部の処理の説明）
本開示を適用した情報処理システムの第５実施の形態は、放送データのファイルがMPEG-DASHに準拠したファイルである場合に、ファイル生成部３２が、そのファイルのうちのMPD（Media Presentation Description）ファイルに、欠損ありファイルを特定する欠損ファイル情報を設定する点と、設定部３３が修復情報をMPDファイルにも設定する点とを除いて、第１実施の形態乃至第４実施の形態の構成と同一である。従って、以下では、図１の各部を情報処理システムの第５実施の形態の各部として用いて、MPDファイルに関する処理についてのみ説明する。
【０１３４】
図２１は、第５実施の形態におけるファイル生成部３２の処理を説明する図である。
【０１３５】
図２１に示すように、放送データのファイルがMPEG-DASHに準拠したファイルである場合、ファイルはセグメント化されており、１つのInitialization Segmentファイル、１以上（図２１の例ではｎ個）のMedia Segmentファイル、および図示せぬMPDファイルにより構成される。なお、以下では、Initialization SegmentファイルとMedia Segmentファイルを特に区別する必要がない場合、それらをまとめてSegmentファイルという。
【０１３６】
ファイル生成部３２は、放送受信部３１から供給されるSegmentファイルに欠損データが存在するかどうかを判定する。
【０１３７】
図２１に示すように、先頭からx番目のMedia Segmentファイル（Media Segment x）に欠損データが存在すると判定された場合、ファイル生成部３２は、そのMedia Segmentファイルの放送データから、欠損ありファイルを生成する。
【０１３８】
なお、図２１の例では、第１実施の形態乃至第３実施の形態と同様に欠損ありファイルが生成されるが、第４実施の形態と同様にRecovery Status Boxを含む欠損ありファイルが生成されるようにしてもよい。
【０１３９】
また、先頭からx番目のMedia Segmentファイル以外のSegmentファイルに欠損データが存在しないと判定された場合、ファイル生成部３２は、そのSegmentファイルをそのまま欠損なしファイルとする。ファイル生成部３２は、生成された欠損ありファイルと欠損なしファイルを記録部３４に供給し、記録させる。
【０１４０】
（MPDファイルの第１の構成例の説明）
図２２は、欠損ありファイル情報と修復情報が設定されたMPDファイルの第１の構成例を示す図である。
【０１４１】
MPDファイルは、Segmentファイルを管理するファイルであり、MPDファイルには、放送データの符号化情報（Configration情報）、画像のサイズ、音声の言語などの情報が階層化されて、XML形式で記述される。
【０１４２】
図２２のＡに示すように、MPDファイルにおける階層化は、ピリオド（Period）、アダプテーションセット（AdaptationSet）、リプレゼンテーション（Representation）等の要素を用いて行われる。
【０１４３】
MPDファイルでは、自分が管理するSegmentファイルに格納される放送データが所定の時間範囲で分割される。ピリオド要素は、分割された放送データごとに記述される。アダプテーションセット要素は、ピリオド要素に含まれ、そのピリオド要素に対応する放送データのリプレゼンテーション要素をグルーピングする。リプレゼンテーション要素は、放送データの種類（図２２のＡの例では、画像、音声）等によってグルーピングされる。リプレゼンテーション要素は、分割された放送データの取得先のURL情報等を有する。
【０１４４】
ファイル生成部３２が、放送受信部３１から図２２のＡのMPDファイルを取得し、Segmentファイルの少なくとも１つに欠損データが存在する場合、ファイル生成部３２は、図２２のＢに示す<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:2015”>を、図２２のＡのMPDファイルの（１）乃至（４）のいずれかの位置に設定する。
【０１４５】
<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:2015”>は、それを含む要素が含むリプレゼンテーション要素に対応するSegmentファイルの少なくとも１つが欠損ありファイルであることを示すEssentialPropertyである。
【０１４６】
例えば、図２２のＡの（１）または（２）の位置に<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:2015”>が設定される場合、それを含む要素が含むリプレゼンテーション要素に対応する、MPDファイルが管理する全てのSegmentファイル(video.mp4,audio.mp4)の少なくとも一方が欠損ありファイルである。また、図２２のＡの（３）または（４）の位置に<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:2015”>が設定される場合、それを含む要素が含むリプレゼンテーション要素に対応するSegmentファイル（video.mp4）が欠損ありファイルである。
【０１４７】
また、ファイル生成部３２と設定部３３は、図２２のＢに示す<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>を、図２２のＡのＭＰＤファイルの（１）乃至（４）のいずれかの位置に欠損ありファイルごとに設定する。
【０１４８】
具体的には、<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>は、それを含む要素が含むリプレゼンテーション要素に対応するSegmentファイルのうちの欠損ありファイルの修復情報と欠損ファイル情報を示すEssentialPropertyである。
【０１４９】
より詳細には、図２３に示すように、file_nameは、欠損ファイル情報としての欠損ありファイルのファイル名を示す情報である。また、file_recovered_status_flagは、欠損ありファイルの修復情報としてのAll_Corrupted_data_was_tired_to_recoverフラグとNOW_recoveringフラグにより構成される。
【０１５０】
ファイル生成部３２は、取得された図２２のＡのMPDファイルの（１）乃至（４）のいずれかの位置に、各欠損ありファイルの<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>を設定する。ファイル生成部３２は、各欠損ありファイルのfile_nameを、<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>のfile_nameとして設定する。
【０１５１】
なお、<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>を含むリプレゼンテーション要素に対応するSegmentファイルが１つである場合（図２２の例では（３）または（４）に<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>が設定された場合）、欠損ありファイルは一意に決まるため、file_nameは設定されなくてもよい。
【０１５２】
設定部３３は、各欠損ありファイルの<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>のfile_recovered_status_flagに、デフォルト値として０を設定する。また、設定部３３は、修復部３５から供給される修復済み情報に基づいて、記録部３４に記録されている欠損ありファイルに設定された修復情報だけでなく、MPDファイルに設定された修復情報も更新する。
【０１５３】
（MPDファイルの第２の構成例の説明）
図２４は、欠損ありファイル情報と修復情報が設定されたMPDファイルの第２の構成例を示す図である。
【０１５４】
図２４の例では、ファイル生成部３２は、放送受信部３１から供給されるSegmentファイルのうちの少なくとも１つに欠損データが存在する場合、図２４のＡに示すように、Partial File Storageという手法で、放送受信部３１から供給されるMPDファイルをカプセル化する。
【０１５５】
具体的には、ファイル生成部３２は、放送受信部３１から供給されるMPDファイルをOriginal MPD要素に格納し、そのOriginal MPD要素をEncapsulated MPD要素に格納する。従って、修復部３５は、MPDファイルにEncapsulated MPD要素が存在するかどうかによって、MPDファイルが管理するSegmentファイルの少なくとも１つが欠損ありファイルであるかどうかを認識することができる。
【０１５６】
ファイル生成部３２は、図２４のＡのMPDファイルの（１）の位置に、図２４のＢに示す<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:2015”>を設定する。<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:2015”>は、MPDファイルが管理するSegmentファイルの少なくとも１つが欠損ありファイルであることを示す。
【０１５７】
また、ファイル生成部３２と設定部３３は、図２４のＡのMPDファイルの（１）の位置に、図２４のＢに示す<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>を欠損ありファイルごとに設定する。
【０１５８】
具体的には、<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>は、MPDファイルが管理するsegmentファイルのうちの欠損ありファイルの修復情報と欠損ファイル情報を示す。
【０１５９】
ファイル生成部３２は、取得された図２４のＡのMPDファイルの（１）に、各欠損ありファイルの<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>を設定する。ファイル生成部３２は、各欠損ありファイルのfile_nameを、<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>のfile_nameとして設定する。
【０１６０】
設定部３３は、各欠損ありファイルの<PartialFile schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>のfile_recovered_status_flagに、デフォルト値として０を設定する。また、設定部３３は、修復部３５から供給される修復済み情報に基づいて、記録部３４に記録されている欠損ありファイルに設定された修復情報だけでなく、MPDファイルに設定された修復情報も更新する。
【０１６１】
以上のように、図２４の例では、MPDファイルがカプセル化されるので、修復に対応していない既存の再生装置は、MPDファイルを理解することができない。従って、このような再生装置において欠損ありファイルが再生されることを防止することができる。
【０１６２】
第５実施の形態では、MPDファイルに欠損ファイル情報と修復情報が設定される。従って、修復部３５は、MPDファイルを取得するだけで、記録部３４に記録されている修復が完了していない欠損ありファイルを認識することができる。従って、修復部３５は、修復が完了した欠損ありファイルを無駄に読み出すことなく、修復が完了していない欠損ありファイルの修復を行うことができる。
【０１６３】
また、記録部３４に記録されている欠損ありファイルを再生する再生装置は、MPDファイルを取得するだけで、修復が完了した欠損ありファイルを認識することができる。従って、再生装置は、修復が完了していない欠損ありファイルを無駄に読み出すことなく、修復が完了した欠損ありファイルを再生することができる。
【０１６４】
＜第６実施の形態＞
（ファイル生成部の処理の説明）
本開示を適用した情報処理システムの第６実施の形態は、放送データのファイルがMPEG-DASHに準拠したファイルである場合に、設定部３３が修復情報をCorrupted File Indexファイルに設定する点と、ファイル生成部３２が、MPDファイルに、欠損ファイル情報や修復情報ではなく、Corrupted File Indexファイルを特定するCorrupted File Indexファイル情報を設定する点とを除いて、第５実施の形態と同一である。従って、以下では、図１の各部を情報処理システムの第６実施の形態の各部として用いて、Corrupted File IndexファイルおよびMPDファイルに関する処理についてのみ説明する。
【０１６５】
図２５は、第６実施の形態におけるファイル生成部３２の処理を説明する図である。
【０１６６】
ファイル生成部３２は、第５実施の形態と同様に、放送受信部３１から供給されるSegmentファイルに欠損データが存在するかどうかを判定する。図２５に示すように、先頭からx番目とy番目のMedia Segmentファイル（Media Segment x, Media Segment y）に欠損データが存在すると判定された場合、ファイル生成部３２は、そのMedia Segmentファイルの放送データから、欠損ありファイルを生成する。
【０１６７】
なお、図２５の例では、図１７の構成の欠損ありファイルが生成されるが、第１実施の形態乃至第３実施の形態と同様に修復情報がPartially Corrupted File Boxに設定された欠損ありファイルが生成されるようにしてもよい。また、図１６に示したようにPartial File Container Boxとは異なるRecovery Status Boxに修復情報が設定された欠損ありファイルが生成されるようにしてもよい。
【０１６８】
また、先頭からx番目およびy番目のMedia Segmentファイル以外のSegmentファイルに欠損データが存在しないと判定された場合、ファイル生成部３２は、そのSegmentファイルをそのまま欠損なしファイルとする。ファイル生成部３２は、生成された欠損ありファイルと欠損なしファイルを記録部３４に供給し、記録させる。
【０１６９】
さらに、ファイル生成部３２は、放送データのファイルとは異なる新しいCorrupted File Indexファイルを生成する。設定部３３は、生成されたCorrupted File Indexファイルに、各欠損ありファイルの修復情報をFile Recovery Status Boxとして設定する。
【０１７０】
（File Recovery Status Boxのシンタックスの例）
図２６は、File Recovery Status Boxのシンタックスの例を示す図である。
【０１７１】
Corrupted File Indexファイルには、File Recovery Status Boxが欠損ありファイルごとに設けられる。図２６に示すように、File Recovery Status Boxには、file_name、file_recovered_status_flag、およびRecovery Status Boxが記述される。
【０１７２】
なお、File Recovery Status Boxには、Recovery Status Boxが配置されなくてもよい。File Recovery Status BoxにRecovery Status Boxが配置される場合には、欠損ありファイルにはRecovery Status Boxが配置されなくてもよい。
【０１７３】
（MPDファイルの構成例の説明）
図２７は、Corrupted File Indexファイル情報が設定されたMPDファイルの構成例を示す図である。
【０１７４】
ファイル生成部３２が、放送受信部３１から図２７のＡのMPDファイルを取得し、Segmentファイルの少なくとも１つに欠損データが存在する場合、ファイル生成部３２は、MPDファイルに、Corrupted File Indexファイルのファイル名を示す情報をCorrupted File Indexファイル情報として設定する。
【０１７５】
具体的には、ファイル生成部３２は、図２７のＢに示す<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:index:2015” value=“file_name”>を、図２７のＡの（１）の位置に設定する。
【０１７６】
<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:index:2015” value=“file_name”>は、MPDファイルが管理するSegmentファイルの少なくとも１つが欠損ありファイルであり、その欠損ありファイルの修復情報が設定されるCorrupted File Indexファイルのファイル名がfile_nameであることを示すEssentialPropertyである。
【０１７７】
なお、第６実施の形態におけるMPDファイルには、第５実施の形態と同様に<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>が記述されてもよい。また、第６実施の形態におけるMPDファイルは、第５実施の形態と同様にカプセル化されてもよい。
【０１７８】
＜第７実施の形態＞
（ファイル生成部の処理の説明）
本開示を適用した情報処理システムの第７実施の形態は、放送データのファイルがMPEG-DASHに準拠したファイルである場合に、修復情報が設定されるファイルが、Corrupted File Indexファイルではなく、Initialization Segmentファイルである点を除いて、第６実施の形態と同一である。従って、以下では、図１の各部を情報処理システムの第７実施の形態の各部として用いて、Initialization SegmentファイルおよびMPDファイルに関する処理についてのみ説明する。
【０１７９】
図２８は、第７実施の形態におけるファイル生成部３２の処理を説明する図である。
【０１８０】
ファイル生成部３２は、第６実施の形態と同様に、放送受信部３１から供給されるSegmentファイルに欠損データが存在するかどうかを判定する。図２８に示すように、先頭からx番目とy番目のMedia Segmentファイル（Media Segment x, Media Segment y）に欠損データが存在すると判定された場合、ファイル生成部３２は、そのMedia Segmentファイルの放送データから、欠損ありファイルを生成する。
【０１８１】
また、ファイル生成部３２は、Initialization Segmentファイルに欠損データが存在するかどうかによらず、Initialization Segmentファイルから、欠損ありファイルを生成する。設定部３３は、Initialization Segmentファイルから生成された欠損ありファイル（以下、欠損ありInitialization Segmentファイルという）に、全ての欠損ありファイルの修復情報をSegment Corrupted Information Boxとして設定する。ファイル生成部３２は、生成された欠損ありファイルと欠損なしファイルを記録部３４に供給し、記録させる。
【０１８２】
なお、図２８の例では、図１７の構成の欠損ありファイルが生成されるが、第１実施の形態乃至第３実施の形態と同様に修復情報がPartially Corrupted File Boxに設定された欠損ありファイルが生成されるようにしてもよい。また、図１６に示したようにPartial File Container Boxとは異なるRecovery Status Boxに修復情報が設定された欠損ありファイルが生成されるようにしてもよい。
【０１８３】
（欠損ありInitialization Segmentファイルの構成例）
図２９は、欠損ありInitialization Segmentファイルの構成例を示す図である。
【０１８４】
図２９の欠損ありInitialization Segmentファイルの構成は、Segment Corrupted Information Boxが配置される点を除いて、図１８の欠損ありファイルの構成と同一である。
【０１８５】
（Segment Corrupted Information Boxのシンタックスの例）
図３０は、図２９のSegment Corrupted Information Boxのシンタックスの例を示す図である。
【０１８６】
図３０に示すように、Segment Corrupted Information Boxは、欠損ありファイルごとにFile Recovery Status Boxが配置される。
【０１８７】
第７実施の形態におけるMPDファイルの構成は、図２７のＡの（１）の位置に<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:index:2015” value=“file_name”>ではなく、<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:index:initialization:2015”>が設定される点を除いて、図２７の構成と異なる。
【０１８８】
<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:index:initialization:2015”>は、MPDファイルが管理するSegmentファイルの少なくとも１つが欠損ありファイルであり、その欠損ありファイルの修復情報がInitialization Segmentファイルに設定されていることを示すEssentialPropertyである。
【０１８９】
なお、第７実施の形態におけるMPDファイルには、第５実施の形態と同様に<EssentialProperty schemeIdUri=“urn:mpeg:dash:corrupted:segment:2015” value=“file_recovered_status_flag,file_name”>が記述されてもよい。また、第７実施の形態におけるMPDファイルは、第５実施の形態と同様にカプセル化されてもよい。
【０１９０】
以上のように、第７実施の形態では、Media Segmentファイルの再生時に、Media Segmentファイルよりも前に再生されるInitialization Segmentファイルに修復情報が設定される。従って、再生装置は、Media Segmentファイルの再生前に、そのMedia Segmentファイルの修復情報を認識することができる。
【０１９１】
＜第８実施の形態＞
（情報処理システムの第８実施の形態の構成例）
図３１は、本開示を適用した情報処理システムの第８実施の形態の構成例を示すブロック図である。
【０１９２】
図３１に示す構成のうち、図１の構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。
【０１９３】
図３１の情報処理システム５０の構成は、受信装置１２の代わりにキャッシュプロキシ５１とプレーヤ５２が設けられる点が、図１の情報処理システム１０の構成と異なる。情報処理システム５０では、MPEG-DASHに準拠した放送データのファイルをキャッシュプロキシ５１が受信して保存し、プレーヤ５２が、キャッシュプロキシ５１に保存されているファイルを再生する。
【０１９４】
具体的には、情報処理システム５０のキャッシュプロキシ５１は、例えば、家庭用のホームサーバなどであり、受信装置１２とDASHサーバ６１等により構成される。受信装置１２は、放送局１１から送信されてくるMPEG-DASHに準拠した放送データのファイルを受信して記録し、そのファイルの欠損データを修復する。DASHサーバ６１は、受信装置１２の記録部３４に記録されている全ての欠損データの修復が完了している欠損ありファイルと欠損なしファイルを取得し、保存する。
【０１９５】
プレーヤ５２は、DASHクライアント７１等により構成される。DASHクライアント７１（再生部）は、DASHサーバ６１に保存されているMPDファイルを読み出す。DASHクライアント７１は、MPDファイルを参照して、必要なSegmentファイルをDASHサーバ６１から読み出し、そのSegmentファイルに基づいて取得された放送データの再生を行う。
【０１９６】
＜第９実施の形態＞
（情報処理システムの第９実施の形態の構成例）
図３２は、本開示を適用した情報処理システムの第９実施の形態の構成例を示すブロック図である。
【０１９７】
図３２に示す構成のうち、図１の構成と同じ構成には同じ符号を付してある。重複する説明については適宜省略する。
【０１９８】
図３２の情報処理システム１００の構成は、キャッシュプロキシ５１の代わりにキャッシュプロキシ１０１が設けられる点、および、プレーヤ５２の代わりにプレーヤ１０２が設けられる点が、図３１の情報処理システム５０の構成と異なる。情報処理システム１００では、プレーヤ１０２で修復が行われる。
【０１９９】
具体的には、情報処理システム１００のキャッシュプロキシ１０１は、例えば、家庭用のホームサーバなどであり、放送受信部３１、ファイル生成部３２、設定部１１１、およびDASHサーバ１１２により構成される。設定部１１１は、図１の設定部３３の処理のうちの、修復情報のデフォルト値を設定する処理を行う。DASHサーバ１１２は、ファイル生成部３２により生成された欠損なしファイルと、少なくとも一方に修復情報のデフォルト値が設定された欠損ありファイルおよびMPDファイルとを記録する。
【０２００】
プレーヤ１０２は、記録部３４、修復部３５、HTTP受信部３６、DASHクライアント１２１、および設定部１２２により構成される。
【０２０１】
DASHクライアント１２１（再生部）は、DASHサーバ１１２に記録されているMPDファイルを読み出す。DASHクライアント１２１は、MPDファイルを参照して、必要なSegmentファイルをDASHサーバ１１２から読み出し、記録部３４に記録する。DASHクライアント１２１は、記録部３４に記録されている全ての欠損データの修復が行われたSegmentファイルを読み出し、そのSegmentファイルに基づいて放送データを取得し、再生する。
【０２０２】
設定部１２２は、図１の設定部３３の処理のうちの、修復情報を更新する処理を行う。
【０２０３】
＜第１０実施の形態＞
（本開示を適用したコンピュータの説明）
上述した受信装置１２の一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
【０２０４】
図３３は、上述した受信装置１２の一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
【０２０５】
コンピュータ２００において、CPU（Central Processing Unit）２０１，ROM（Read Only Memory）２０２，RAM（Random Access Memory）２０３は、バス２０４により相互に接続されている。
【０２０６】
バス２０４には、さらに、入出力インタフェース２０５が接続されている。入出力インタフェース２０５には、入力部２０６、出力部２０７、記憶部２０８、通信部２０９、及びドライブ２１０が接続されている。
【０２０７】
入力部２０６は、キーボード、マウス、マイクロフォンなどよりなる。出力部２０７は、ディスプレイ、スピーカなどよりなる。記憶部２０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部２０９は、ネットワークインタフェースなどよりなる。ドライブ２１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア２１１を駆動する。
【０２０８】
以上のように構成されるコンピュータ２００では、CPU２０１が、例えば、記憶部２０８に記憶されているプログラムを、入出力インタフェース２０５及びバス２０４を介して、RAM２０３にロードして実行することにより、上述した一連の処理が行われる。
【０２０９】
コンピュータ２００（CPU２０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア２１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
【０２１０】
コンピュータ２００では、プログラムは、リムーバブルメディア２１１をドライブ２１０に装着することにより、入出力インタフェース２０５を介して、記憶部２０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部２０９で受信し、記憶部２０８にインストールすることができる。その他、プログラムは、ROM２０２や記憶部２０８に、あらかじめインストールしておくことができる。
【０２１１】
なお、コンピュータ２００が実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
【０２１２】
本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【０２１３】
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
【０２１４】
また、本開示の実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
【０２１５】
例えば、第５実施の形態において、MPDファイルにSegment Corrupted Information Boxと同様の記述が行われてもよい。
【０２１６】
また、本技術は、放送データを受信する装置だけでなく、LTE（Long Term Evolution）やWi-Fiなどに準拠してマルチキャストされるデータを受信する装置（例えば、携帯型端末など）に適用することもできる。
【０２１７】
なお、本開示は、以下のような構成もとることができる。
【０２１８】
（１）
ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報を設定する設定部と、
前記設定部により設定された前記修復情報に基づいて、前記欠損データを修復する修復部と
を備える情報処理装置。
（２）
前記設定部は、前記ファイルのデータが配置されるボックスとは異なるボックスに前記修復情報を設定する
ように構成された
前記（１）に記載の情報処理装置。
（３）
前記設定部は、前記ファイルのデータが配置されるボックスに含まれる、前記欠損データの位置とサイズを表す欠損情報が配置されるボックスとは異なるボックスに前記修復情報を設定する
ように構成された
前記（１）に記載の情報処理装置。
（４）
前記設定部は、前記ファイルの前記欠損データの位置とサイズを表す欠損情報が配置されるボックスに前記修復情報を設定する
ように構成された
前記（１）に記載の情報処理装置。
（５）
前記設定部は、前記ファイルを管理する管理ファイルに前記修復情報を設定する
ように構成された
前記（１）乃至（４）のいずれかに記載の情報処理装置。
（６）
前記管理ファイルはカプセル化される
ように構成された
前記（５）に記載の情報処理装置。
（７）
前記ファイルを特定する欠損ファイル情報を、前記ファイルを管理する管理ファイルに設定するファイル生成部
をさらに備える
前記（１）乃至（４）のいずれかに記載の情報処理装置。
（８）
前記管理ファイルは、カプセル化される
ように構成された
前記（７）に記載の情報処理装置。
（９）
前記設定部は、前記ファイルとは異なるファイルである修復情報ファイルに前記修復情報を設定する
ように構成された
前記（１）に記載の情報処理装置。
（１０）
前記設定部は、前記修復情報ファイルに前記ファイルを特定する欠損ファイル特定情報を設定する
ように構成された
前記（９）に記載の情報処理装置。
（１１）
前記修復情報ファイルを特定する情報を、前記ファイルを管理する管理ファイルに設定するファイル生成部
をさらに備える
前記（９）または（１０）に記載の情報処理装置。
（１２）
前記修復情報ファイルは、Initialization Segmentファイルである
ように構成された
前記（９）乃至（１１）のいずれかに記載の情報処理装置。
（１３）
前記修復情報は、前記ファイルの全ての前記欠損データの修復の途中であることを示す情報である
ように構成された
前記（１）乃至（１２）のいずれかに記載の情報処理装置。
（１４）
前記修復情報は、前記ファイルの全ての前記欠損データの修復が完了したことを示す情報である
ように構成された
前記（１）乃至（１３）のいずれかに記載の情報処理装置。
（１５）
前記修復情報は、前記修復部により前記修復が行われた前記欠損データを示す情報である
ように構成された
前記（１）乃至（１４）のいずれかに記載の情報処理装置。
（１６）
前記修復情報は、各欠損データの前記修復が成功した状態、前記修復が失敗した状態、または前記修復が行われていない状態を示す情報である
ように構成された
前記（１）乃至（１５）のいずれかに記載の情報処理装置。
（１７）
前記修復情報は、前記修復部により前記修復が行われた前記欠損データを示す情報と、前記修復が行われた各欠損データの前記修復が成功したか、または、失敗したかを示す情報である
ように構成された
前記（１）乃至（１４）のいずれかに記載の情報処理装置。
（１８）
情報処理装置が、
ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報を設定する設定ステップと、
前記設定ステップの処理により設定された前記修復情報に基づいて、前記欠損データを修復する修復ステップと
を含む情報処理方法。
（１９）
ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定された前記ファイルを再生する再生部
を備える情報処理装置。
（２０）
情報処理装置が、
ISO Base media file formatに準拠したファイルの欠損データの修復の状態を示す修復情報が設定された前記ファイルを再生する再生ステップ
を含む情報処理方法。
【符号の説明】
【０２１９】
１２  受信装置,  ３２  ファイル生成部,  ３３  設定部,  ３５  修復部,  ７１，１２１  DASHクライアント
【図１】
2017061299.tif 000003
【図２】
2017061299.tif 000004
【図３】
2017061299.tif 000005
【図４】
2017061299.tif 000006
【図５】
2017061299.tif 000007
【図６】
2017061299.tif 000008
【図７】
2017061299.tif 000009
【図８】
2017061299.tif 000010
【図９】
2017061299.tif 000011
【図１０】
2017061299.tif 000012
【図１１】
2017061299.tif 000013
【図１２】
2017061299.tif 000014
【図１３】
2017061299.tif 000015
【図１４】
2017061299.tif 000016
【図１５】
2017061299.tif 000017
【図１６】
2017061299.tif 000018
【図１７】
2017061299.tif 000019
【図１８】
2017061299.tif 000020
【図１９】
2017061299.tif 000021
【図２０】
2017061299.tif 000022
【図２１】
2017061299.tif 000023
【図２２】
2017061299.tif 000024
【図２３】
2017061299.tif 000025
【図２４】
2017061299.tif 000026
【図２５】
2017061299.tif 000027
【図２６】
2017061299.tif 000028
【図２７】
2017061299.tif 000029
【図２８】
2017061299.tif 000030
【図２９】
2017061299.tif 000031
【図３０】
2017061299.tif 000032
【図３１】
2017061299.tif 000033
【図３２】
2017061299.tif 000034
【図３３】
2017061299.tif 000035
【国際調査報告】
2017061299.tif 000036
2017061299.tif 000037