JP6285608B2 - ネットワークを介して交換されたファイルのためのエラー処理 - Google Patents

ネットワークを介して交換されたファイルのためのエラー処理 Download PDF

Info

Publication number
JP6285608B2
JP6285608B2 JP2017500032A JP2017500032A JP6285608B2 JP 6285608 B2 JP6285608 B2 JP 6285608B2 JP 2017500032 A JP2017500032 A JP 2017500032A JP 2017500032 A JP2017500032 A JP 2017500032A JP 6285608 B2 JP6285608 B2 JP 6285608B2
Authority
JP
Japan
Prior art keywords
file
data
video
media
information
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
JP2017500032A
Other languages
English (en)
Other versions
JP2017528022A (ja
Inventor
ゴードン・ケント・ウォーカー
ナガラジュ・ナイク
トーマス・ストックハマー
Original Assignee
クアルコム，インコーポレイテッド
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 クアルコム，インコーポレイテッド filed Critical クアルコム，インコーポレイテッド
Publication of JP2017528022A publication Critical patent/JP2017528022A/ja
Application granted granted Critical
Publication of JP6285608B2 publication Critical patent/JP6285608B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/4425—Monitoring of client processing errors or hardware failure
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0787—Storage of error reports, e.g. persistent data storage, storage using memory protection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/764—Media network packet handling at the destination 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/454—Content or additional data filtering, e.g. blocking advertisements
    • H04N21/4545—Input to filtering algorithms, e.g. filtering a region of the image
    • H04N21/45457—Input to filtering algorithms, e.g. filtering a region of the image applied to a time segment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/482—End-user interface for program selection
    • H04N21/4825—End-user interface for program selection using a list of items to be played back in a given order, e.g. playlists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H04N19/89—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving methods or arrangements for detection of transmission errors at the decoder
    • H04N19/895—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving methods or arrangements for detection of transmission errors at the decoder in combination with error concealment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383—Accessing a communication channel

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Human Computer Interaction (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本出願は、その内容全体が参照により本明細書に組み込まれる、2014年7月9日に出願した米国仮出願第62/022,539号の利益を主張するものである。
本開示は、コード化メディアデータの記憶および移送に関する。
デジタルビデオ機能は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル録音デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラーまたは衛星無線電話、ビデオ遠隔会議デバイスなどを含む、広範囲なデバイスに組み込まれ得る。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送受信するために、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4、Part 10、アドバンスドビデオコーディング(AVC)、H.265/高効率ビデオコーディング、および、そのような規格の拡張に記載されているものなどの、ビデオ圧縮技法を実装する。
ビデオ圧縮技法は、ビデオシーケンスに内在する冗長性を低減または除去するために、空間的予測および/または時間的予測を実行する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスがブロックに区分され得る。各ブロックはさらに区分され得る。イントラコード化(I)フレームまたはスライスにおけるブロックは、近接ブロックに関する空間的予測を使用して符号化される。インターコード化(PまたはB)フレームまたはスライスにおけるブロックは、同じフレームもしくはスライスにおける近接ブロックに関する空間的予測または他の参照フレームに関する時間的予測を使用し得る。
ビデオデータが符号化された後、ビデオデータは、伝送または記憶のためにパケット化され得る。ビデオデータは、ISO/IEC 14496-12:2012(E)で定義されている国際標準化機構(ISO)ベースメディアファイルフォーマット、およびISO BMFFとしても知られるその拡張などの、様々な規格のいずれかに準拠するビデオファイルに組み込まれ得る。
R. Fieldingらによる、RFC2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月 Pailaら、「FLUTE-File Delivery over Unidirectional Transport」、Internet Engineering Task Force(IETF)、RFC6726、2012年11月 INTERNATIONAL STANDARD ISO/IEC 23009-1 Second edition 2014-05-01 Information Technology-Dynamic Adaptive Streaming Over HTTP (DASH) Part 1: Media Presentation Description and Segment Formats ISO/IEC 14496-12:2012(E)、INTERNATIONAL STANDARD ISO/IEC 14496-12 Fourth edition 2012-07-15 Corrected version 2012-09-15、Information Technology-Coding of Audio-Visual Objects Part 12: ISO Base Media File Format
全体的には、本開示は、ネットワークを介して配信されるファイルまたは他のデータ、たとえば、ブロードキャストプロトコルを介して(ブロードキャストネットワークを介して)またはリアルタイムトランスポートプロトコル(RTP)を介して配信されるメディアファイル内の潜在的なエラーを処理することに関する技法を説明する。具体的には、ファイル配信プロトコルユニットは、ファイルの一部が、エラー、たとえば、ファイルのネットワーク伝送の間に導入されたエラーを含む疑いがあることを決定し得る。ファイル配信プロトコルユニットは、エラーを含むことが疑われるファイルの部分を示すデータをアプリケーションに提供し得る。たとえば、ファイル配信プロトコルユニットは、疑わしい部分の位置を画定するために、ファイル自体にマーカを挿入し得、または、ファイル配信プロトコルユニットは、疑わしい部分に対応するバイト範囲をシグナリングし得る。逆に、インターフェースは、エラーのないことがわかっているファイルの範囲/領域を記述し得る。
さらに、ファイルは、ファイルの他の部分に影響を与えることなく、ドロップ(すなわち、除去)され得るファイルの部分をシグナリングするデータを含み得、またはそれが付随し得る。たとえば、ビデオデータについて、ファイルの他の部分に影響を与えることなくドロップされ得るファイルの部分は、フレームと、復号中に参照のための参照フレームを使用し得る0以上のフレームとを含む部分であり得る。より具体的には、参照のために使用されない単一のフレームを含む1つまたは複数のドロップ可能な部分と、参照のための特定の参照フレームを使用するフレームならびに参照フレーム自体のグループとが存在し得る。したがって、メディアアプリケーションは、ビデオデコーダが誤ったデータを復号しようとするのを避けるために、ファイルの疑わしい部分をカバーするフレームのグループ(ドロップ可能な部分)のうちの1つまたは複数を決定し、フレームのこれらのグループをドロップし得る。このように、本開示は、疑わしいデータまたは既知の有効なデータを含むファイルの堅牢で層が透明(layer transparent)な処理に関するインターフェース設計およびファイル構造の特定の態様を説明する。
一例では、メディアデータを受信する方法は、メディアデータを含むファイルを受信するステップと、ファイルの一部が潜在的に誤りであることを決定するステップと、ファイルが潜在的に誤りである部分を含むことを示すデータを形成するステップと、ファイルのメディアデータのためのターゲットアプリケーションに利用可能な場所にファイルおよびデータを記憶するステップとを含む。
別の例では、メディアデータのための情報をシグナリングする方法は、メディアデータを含むファイルを取得するステップと、メディアデータの他の部分の正確な復号を妨げることなくファイルから除去され得るメディアデータの少なくとも1つの部分を決定するステップと、決定された部分を識別する情報をシグナリングするステップとを含む。
別の例では、メディアデータを処理する方法は、メディアデータを含むファイルを受信するステップと、メディアデータの他の部分の正確な復号を妨げることなくファイルから除去され得るファイルの1つまたは複数の除去可能な部分を示す情報の第1のセットを受信するステップと、潜在的に誤りであるファイルの疑わしい部分を示す情報の第2のセットを受信するステップと、疑わしい部分と完全に重複する除去可能な部分のうちの1つまたは複数を決定するステップと、決定された1つまたは複数の除去可能な部分をファイルから除去するステップとを含む。
別の例では、メディアデータを処理する方法は、メディアデータを含む第1のファイルを受信するステップと、第1のファイルの別の対応する部分がファイル内に存在しないときに再生され得る第1のファイルの1つまたは複数の再生可能な部分を示す情報の第1のセットを受信するステップと、潜在的に誤りである第1のファイルの疑わしい部分を示す情報の第2のセットを受信するステップと、疑わしい部分と重複せず、疑わしい部分が第1のファイル内に存在しないときに再生され得る第1のファイルの再生可能な部分のうちの1つまたは複数を決定するステップと、決定された再生可能な部分を含み、疑わしい部分を含まない第2のファイルを出力するステップとを含む。
別の例では、メディアデータを処理するためのデバイスは、メディアデータを含むファイルを受信し、ファイルの一部が潜在的に誤りであることを決定し、ファイルが潜在的に誤りである部分を含むことを示すエラー表示データを形成し、ファイルのメディアデータのためのターゲットアプリケーションに利用可能な場所にファイルおよびエラー表示データを記憶するように構成された1つまたは複数のプロセッサを含む。
別の例では、メディアデータを処理するためのデバイスは、メディアデータを含むファイルを受信し、メディアデータの他の部分の正確な復号を妨げることなくファイルから除去され得るファイルの1つまたは複数の除去可能な部分を示す情報の第1のセットを受信し、潜在的に誤りであるファイルの疑わしい部分を示す情報の第2のセットを受信し、疑わしい部分と完全に重複する除去可能な部分のうちの1つまたは複数を決定し、決定された1つまたは複数の除去可能な部分をファイルから除去するように構成された1つまたは複数のプロセッサを含む。
別の例では、メディアデータを受信するためのデバイスは、メディアデータを含むファイルを受信するための手段と、ファイルの一部が潜在的に誤りであることを決定するための手段と、ファイルが潜在的に誤りである部分を含むことを示すデータを形成するための手段と、メディアアプリケーションにファイルおよびデータを転送するための手段とを含む。
別の例では、メディアデータのための情報をシグナリングするためのデバイスは、メディアデータを含むファイルを取得するための手段と、メディアデータの他の部分の正確な復号を妨げることなくファイルから除去され得るメディアデータの少なくとも1つの部分を決定するための手段と、決定された部分を識別する情報をシグナリングするための手段とを含む。
別の例では、メディアデータを処理するためのデバイスは、メディアデータを含むファイルを受信するための手段と、メディアデータの他の部分の正確な復号を妨げることなくファイルから除去され得るファイルの1つまたは複数の除去可能な部分を示す情報の第1のセットを受信するための手段と、潜在的に誤りであるファイルの疑わしい部分を示す情報の第2のセットを受信するための手段と、疑わしい部分と完全に重複する除去可能な部分のうちの1つまたは複数を決定するための手段と、決定された1つまたは複数の除去可能な部分をファイルから除去するための手段とを含む。
別の例では、メディアデータを処理するためのデバイスは、メディアデータを含む第1のファイルを受信するための手段と、第1のファイルの別の対応する部分がファイル内に存在しないときに再生され得る第1のファイルの1つまたは複数の再生可能な部分を示す情報の第1のセットを受信するための手段と、潜在的に誤りである第1のファイルの疑わしい部分を示す情報の第2のセットを受信するための手段と、疑わしい部分と重複せず、疑わしい部分が第1のファイル内に存在しないときに再生され得る第1のファイルの再生可能な部分のうちの1つまたは複数を決定するための手段と、決定された再生可能な部分を含み、疑わしい部分を含まない第2のファイルを出力するための手段とを含む。
別の例では、メディアデータを処理する方法は、ファイル配信プロトコルに従ってファイルの複数のチャンク(chunk)の配信を取得するステップと、ファイルのためのターゲットアプリケーションにアクセス可能な場所にチャンクを記憶するステップとを備える。
別の例では、メディアデータを処理するためのデバイスは、ファイル配信プロトコルに従ってファイルの複数のチャンクの配信を取得するための手段と、ファイルのためのターゲットアプリケーションにアクセス可能な場所にチャンクを記憶するための手段とを含む。
1つまたは複数の例の詳細は、添付図面および以下の説明に記載されている。他の特徴、目的、および利点は、説明、図面、および特許請求の範囲から明らかになるであろう。
ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを示すブロック図である。 例示的なマルチメディアコンテンツの要素を示す概念図である。 表現のセグメントに対応し得る例示的なビデオファイルの要素を示すブロック図である。 インターネットプロトコル(IP)スタックのデータを処理するためのユニットの例示的なセットを示す概念図である。 本開示の技法のための例示的なユースケースを示す概念図である。 本開示の技法のためのさらなる例示的なユースケースを示す概念図である。 本開示の技法を実行するための例示的な方法を示すフローチャートである。 様々なタイプのアプリケーションのためのファイルのチャンクベースの配信の様々な例を示す概念図である。 本開示の技法による別の例示的な方法を示すフローチャートである。
全体的には、本開示は、ネットワークを介して受信されるファイル、たとえば、ブロードキャストプロトコルを介して受信されるメディアファイル内の潜在的なエラーを処理することに関する技法を説明する。具体的には、ファイル配信プロトコルユニットは、ファイルの一部が、エラーを含む疑いがある、または実際にエラーを含むことを決定し得る。ファイル配信プロトコルユニットは、エラーを含むことが疑われるファイルの部分を示すデータをアプリケーション(たとえば、DASHクライアントなどのメディアプレーヤアプリケーション)に提供し得る。たとえば、ファイル配信プロトコルユニットは、疑わしい部分の位置を画定するために、ファイル自体にマーカを挿入し得、または、ファイル配信プロトコルユニットは、たとえば、セグメントインデックス(sidx)ボックスにおいて、疑わしい部分に対応するバイト範囲をシグナリングし得る。別の例として、ファイル配信プロトコルユニットは、ファイルの潜在的に誤りである部分(たとえば、バイト範囲)を示すデータをシグナリングし得る。本明細書で使用される場合、「潜在的に誤りである」部分は、誤りである可能性を有する部分、実際に誤りである部分、または両方を含む。
さらに、ファイルは、ファイルの他の部分の成功した利用に影響を与えることなくドロップ(すなわち、除去)され得るファイルの部分をシグナリングするデータを含み得、またはそれが付随し得る。たとえば、ビデオデータについて、ファイルの他の部分に影響を与えることなくドロップされ得るファイルの部分は、参照フレームと、復号中に参照のための参照フレームを使用し得る0以上のフレームとを含む部分であり得る。より具体的には、参照のために使用されない単一のフレームを含む1つまたは複数のドロップ可能な部分と、参照のための特定の参照フレームを使用するフレームならびに参照フレーム自体のグループとが存在し得る。したがって、メディアアプリケーション(または、他のターゲットアプリケーション)は、ビデオデコーダが誤ったデータを復号しようとするのを避けるために、ファイルの疑わしい部分をカバーするたとえばビデオフレームのグループ(ドロップ可能な部分)のうちの1つまたは複数を決定し、フレームのこれらのグループをドロップし得る。
本開示の技法は、ISOベースメディアファイルフォーマット、スケーラブルビデオコーディング(SVC)ファイルフォーマット、アドバンスドビデオコーディング(AVC)ファイルフォーマット、第3世代パートナーシッププロジェクト(3GPP)ファイルフォーマット、および/またはマルチビュービデオコーディング(MVC)ファイルフォーマット、または他の同様のファイルフォーマットなどの、様々なファイルタイプのいずれかに従ってカプセル化されたビデオデータに準拠するビデオファイルに適用され得る。
HTTPストリーミングにおいて、頻繁に使用される動作には、HEAD、GETおよび部分GETがある。HEAD動作は、所与のユニフォームリソースロケータ(URL)またはユニフォームリソース名(URN)と関連付けられたファイルのヘッダを取り出し、この場合、URLまたはURNと関連付けられたペイロードを取り出すことはない。GET動作は、所与のURLまたはURNと関連付けられたファイル全体を取り出す。部分GET動作は、入力パラメータとしてバイト範囲を受信し、ファイルのバイトの連続数を取得し、ここで、バイトの数は、受信したバイト範囲に対応する。したがって、部分GET動作は1つまたは複数の個々の動画フラグメントを取得できるので、動画フラグメントはHTTPストリーミングのために提供され得る。動画フラグメントにおいて、異なるトラックのいくつかのトラックフラグメントが存在し得る。HTTPストリーミングでは、メディアプレゼンテーションは、クライアントにアクセス可能なデータの構造化された集合体であり得る。クライアントは、メディアデータ情報を要求およびダウンロードして、ユーザにストリーミングサービスを提示することができる。
HTTPストリーミングを使用して3GPPデータをストリーミングする例では、マルチメディアコンテンツのビデオおよび/またはオーディオデータのための複数の表現が存在し得る。以下で説明するように、異なる表現は、異なるコーディング特性(たとえば、ビデオコーディング規格の異なるプロファイルまたはレベル)、異なるコーディング規格またはコーディング規格の拡張(マルチビューおよび/またはスケーラブル拡張など)、または異なるビットレートに対応し得る。そのような表現のマニフェストは、メディアプレゼンテーション記述(MPD:Media Presentation Description)データ構造において定義され得る。メディアプレゼンテーションは、HTTPストリーミングクライアントデバイスにアクセス可能なデータの構造化された集合体に対応し得る。HTTPストリーミングクライアントデバイスは、メディアデータ情報を要求およびダウンロードして、クライアントデバイスのユーザにストリーミングサービスを提示することができる。メディアプレゼンテーションは、MPDの更新を含み得るMPDデータ構造で記述され得る。
メディアプレゼンテーションは、1つまたは複数の期間のシーケンスを含み得る。期間は、MPDにおいてPeriod要素によって定義され得る。各期間は、MPDにおいて属性startを有し得る。MPDは、期間ごとにstart属性とavailableStartTime属性とを含み得る。ライブのサービスの場合、期間のstart属性とMPD属性availableStartTimeとの合計が、UTCフォーマットによる期間の利用可能時間、特に、対応する期間における各表現の第1のメディアセグメントを指定し得る。オンデマンドサービスの場合、第1の期間のstart属性は0であり得る。任意の他の期間では、start属性は、対応する期間の開始時間と第1の期間の開始時間との間の時間オフセットを指定し得る。各期間は、次の期間の開始まで、または最後の期間の場合にはメディアプレゼンテーションの終了まで及び得る。期間開始時間は、正確であり得る。期間開始時間は、すべての先行期間のメディアの再生から生じる実際のタイミングを反映することができる。
各期間は、同じメディアコンテンツのための1つまたは複数の表現(Representation)を含み得る。表現は、オーディオデータまたはビデオデータの、多数の符号化バージョンの選択肢の1つであり得る。表現は、符号化タイプによって、たとえば、ビデオデータのためのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのためのビットレート、言語、および/またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツの特定の期間に対応し、特定の方法において符号化された、符号化されたオーディオまたはビデオデータのセクションを指すために使用され得る。
特定の期間の表現は、表現が属する適応セットを示すMPD内の属性によって示されるグループに割り当てられ得る。同じ適応セット内の表現は、一般に互いの代替と考えられ得、すなわち、クライアントデバイスは、たとえば、帯域幅適応を実行するために、これらの表現間で動的かつシームレスに切り替えることができる。たとえば、ある特定の期間のビデオデータの各表現は、同じ適応セットに割り当てられ得るので、表現のうちのいずれもが、対応する期間のマルチメディアコンテンツの、ビデオデータまたはオーディオデータなど、メディアデータを提示するように復号するために、選択され得る。1期間内のメディアコンテンツは、存在する場合は、グループ0からの1つの表現によって表され得、または、いくつかの例では、各非ゼログループからの多くても1つの表現の組合せによって表され得る。ある期間の各表現のタイミングデータは、期間の開始時間に対して表され得る。
表現は、1つまたは複数のセグメントを含み得る。各表現は、初期化セグメントを含み得、または、表現の各セグメントは、自己初期化し得る。存在するとき、初期化セグメントは、表現にアクセスするための初期化情報を含み得る。一般に、初期化セグメントは、メディアデータを含まない。セグメントは、ユニフォームリソースロケータ(URL)、ユニフォームリソース名(URN)、またはユニフォームリソース識別子(URI)などの識別子によって一意的に参照され得る。MPDは、各セグメントのための識別子を提供し得る。いくつかの例では、MPDはまた、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る、range属性の形式で、バイト範囲を提供することができる。
図1は、ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステム10を示すブロック図である。各例では、システム10は、コンテンツ準備デバイス20と、サーバデバイス60と、クライアントデバイス40とを含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含み得るネットワーク74によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60はまた、ネットワーク74もしくは別のネットワークに結合され得、または、直接通信可能に結合され得る。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを含み得る。
コンテンツ準備デバイス20は、図1の例では、オーディオソース22とビデオソース24とを備える。オーディオソース22は、たとえば、オーディオエンコーダ26によって符号化されるべきキャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを含んでもよい。あるいは、オーディオソース22は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを含んでもよい。ビデオソース24は、ビデオエンコーダ28によって符号化されるべきビデオデータを生成するビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを含んでもよい。コンテンツ準備デバイス20は、すべての例でサーバデバイス60に必ずしも通信可能に結合されるわけではなく、サーバデバイス60によって読み取られる別個の媒体にマルチメディアコンテンツを記憶し得る。
生のオーディオデータおよび生のビデオデータは、アナログデータまたはデジタルデータを備え得る。アナログデータは、オーディオエンコーダ26および/またはビデオエンコーダ28によって符号化される前にデジタル化されてもよい。オーディオソース22は、話している参加者から、その参加者が話している間にオーディオデータを取得する場合があり、ビデオソース24は、話している参加者のビデオデータを同時に取得する場合がある。他の例では、オーディオソース22は、記憶されたオーディオデータを備えるコンピュータ可読記憶媒体を備え得、ビデオソース24は、記憶されたビデオデータを備えるコンピュータ可読記憶媒体を備え得る。このように、本開示で説明される技術は、ライブ、ストリーミング、リアルタイムオーディオデータ、およびリアルタイムビデオデータに適用され得、または、アーカイブされた事前に記録されたオーディオデータ、およびアーカイブされた事前に記録されたオーディオデータに適用され得る。
ビデオフレームに対応するオーディオフレームは、一般に、ビデオフレーム内に含まれるビデオソース24によってキャプチャされた(または、生成された)ビデオデータと同時にオーディオソース22によってキャプチャされた(または、生成された)オーディオデータを含むオーディオフレームである。たとえば、話している参加者が一般に話すことによってオーディオデータを生成している間、オーディオソース22はオーディオデータをキャプチャし、ビデオソース24は同時に、すなわち、オーディオソース22がオーディオデータをキャプチャしている間に、話している参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応し得る。したがって、ビデオフレームに対応するオーディオフレームは一般に、オーディオデータおよびビデオデータが同時にキャプチャされた状況に対応し、その状況に対して、オーディオフレームおよびビデオフレームがそれぞれ、同時にキャプチャされたオーディオデータおよびビデオデータを含む。
いくつかの例では、オーディオエンコーダ26は、符号化オーディオフレームのためのオーディオデータが記録された時間を表すタイムスタンプを各符号化オーディオフレームにおいて符号化し得、同様に、ビデオエンコーダ28は、符号化ビデオフレームのためのビデオデータが記録された時間を表すタイムスタンプを各符号化ビデオフレームにおいて符号化し得る。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを含むオーディオフレームおよび同じタイムスタンプを含むビデオフレームを含み得る。コンテンツ準備デバイス20は、オーディオエンコーダ26および/またはビデオエンコーダ28がタイムスタンプを再生し得る内部クロック、または、オーディオソース22およびビデオソース24が、オーディオデータおよびビデオデータを、それぞれ、タイムスタンプと関連付けるために使用し得る内部クロックを含み得る。
いくつかの例では、オーディオソース22は、オーディオデータが記録された時間に対応するデータをオーディオエンコーダ26に送り得、ビデオソース24は、ビデオデータが記録された時間に対応するデータをビデオエンコーダ28に送り得る。いくつかの例では、オーディオエンコーダ26は、符号化オーディオデータにおいて、符号化オーディオデータの相対的な時間順序を示すために、オーディオデータが記録された絶対的な時間を必ずしも示すとは限らないが、シーケンス識別子を符号化することができ、同様に、ビデオエンコーダ28も、符号化ビデオデータの相対的な時間順序を示すためにシーケンス識別子を使用することができる。同様に、いくつかの例では、シーケンス識別子がタイムスタンプとともにマップされるか、あるいはタイムスタンプと相関することがある。
オーディオエンコーダ26は、一般に、符号化オーディオデータのストリームを生成し、ビデオエンコーダ28は、符号化ビデオデータのストリームを生成する。データの個別の各ストリーム(オーディオかビデオかにかかわらず)は、エレメンタリストリームと呼ばれることがある。エレメンタリストリームは、表現の単一のデジタル的にコーディングされた(場合によっては圧縮された)成分である。たとえば、表現のコード化ビデオ部分およびコード化オーディオ部分は、エレメンタリストリームであり得る。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリストリーム(PES:packetized elementary stream)に変換され得る。同じ表現内で、ストリームIDが、あるエレメンタリストリームに属するPESパケットを他のエレメンタリストリームに属するPESパケットと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム(PES)パケットである。したがって、コード化ビデオデータは一般に、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。
図1の例では、コンテンツ準備デバイス20のカプセル化ユニット30は、ビデオエンコーダ28からコード化ビデオデータを備えるエレメンタリストリームを受信し、オーディオエンコーダ26からコード化オーディオデータを備えるエレメンタリストリームを受信する。いくつかの例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのパケッタイザを含み得る。他の例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのそれぞれのパケッタイザとインターフェースをとる場合がある。さらに他の例では、カプセル化ユニット30は、符号化オーディオデータおよび符号化ビデオデータからPESパケットを形成するためのパケッタイザを含み得る。
ビデオエンコーダ28は、様々なビットレートにおいて、ピクセル解像度、フレームレート、様々なコーディング規格への適合性、様々なコーディング規格のための様々なプロファイルおよび/もしくはプロファイルのレベルへの適合性、(たとえば、2次元再生もしくは3次元再生のための)1つもしくは複数のビューを有する表現、または他のそのような特徴などの、様々な特性を有するマルチメディアコンテンツの異なる表現を生成するために、様々な方法でマルチメディアコンテンツのビデオデータを符号化し得る。本開示で使用される表現は、オーディオデータ、ビデオデータ、(たとえば、クローズドキャプションのための)テキストデータ、または他のそのようなデータを備え得る。この表現は、オーディオエレメンタリストリームまたはビデオエレメンタリストリームなどのエレメンタリストリームを含み得る。各PESパケットは、PESパケットが属するエレメンタリストリームを特定するstream_idを含んでもよい。カプセル化ユニット30は、様々な表現のビデオファイル(たとえば、セグメント)へとエレメンタリストリームを組み立てる役割を担う。
カプセル化ユニット30は、オーディオエンコーダ26およびビデオエンコーダ28から表現のエレメンタリストリームのためのPESパケットを受信し、PESパケットから対応するネットワーク抽象化層(NAL)を形成する。H.264/AVC(Advanced Video Coding)の例では、コード化ビデオセグメントはNALユニットへと編成され、NALユニットは、ビデオ電話、記憶、ブロードキャスト、またはストリーミングのような、「ネットワークフレンドリ」なビデオ表現のアドレッシング適用(addressing application)を実現する。NALユニットは、ビデオコーディング層(VCL)NALユニットおよび非VCL NALユニットに分類されてもよい。VCLユニットは、コア圧縮エンジンを格納してよく、ブロックおよび/またはスライスレベルのデータを含んでよい。他のNALユニットは、非VCL NALユニットであり得る。いくつかの例では、通常は主コード化ピクチャとして提示される、1つの時間インスタンス内のコード化ピクチャは、1つまたは複数のNALユニットを含み得るアクセスユニット内に含まれ得る。
非VCL NALユニットは、とりわけ、パラメータセットNALユニットとSEI NALユニットとを含み得る。パラメータセットは、(シーケンスパラメータセット(SPS)内の)シーケンスレベルのヘッダ情報と、まれに変化する(ピクチャパラメータセット(PPS)内の)ピクチャレベルのヘッダ情報とを含み得る。パラメータセット(たとえば、PPSおよびSPS)があれば、この頻繁には変化しない情報は、各シーケンスまたはピクチャに対して繰り返される必要がなく、したがって、コーディング効率が向上し得る。さらに、パラメータセットの使用が、重要なヘッダ情報の帯域外送信を可能にでき、エラーの復元のための冗長な送信の必要がなくなる。帯域外送信の例では、パラメータセットNALユニットは、SEI NALユニットなどの他のNALユニットとは異なるチャネル上で送信され得る。
補足強化情報(SEI)は、VCL NALユニットからコード化ピクチャサンプルを復号するために必要ではないが、復号、表示、誤り耐性、および他の目的に関連するプロセスを支援し得る情報を含み得る。SEIメッセージは、非VCL NALユニットに包含され得る。SEIメッセージは、いくつかの標準仕様の規範的部分であり、したがって、規格に準拠するデコーダの実装において常に必須であるとは限らない。SEIメッセージは、シーケンスレベルSEIメッセージまたはピクチャレベルSEIメッセージであり得る。SVCの例におけるスケーラビリティ情報SEIメッセージ、およびMVCにおけるビュースケーラビリティ情報SEIなどの、いくつかのシーケンスレベルの情報がSEIメッセージ内に含まれ得る。これらの例示的なSEIメッセージは、たとえば、動作点の抽出および動作点の特性に関する情報を伝達し得る。加えて、カプセル化ユニット30は、表現の特性を記述するメディアプレゼンテーション記述子(MPD)などのマニフェストファイルを形成し得る。カプセル化ユニット30は、拡張可能マークアップ言語(XML)に従ってMPDをフォーマットすることができる。
カプセル化ユニット30は、マルチメディアコンテンツの1つまたは複数の表現のためのデータを、マニフェストファイル(たとえば、MPD)とともに出力インターフェース32に提供し得る。出力インターフェース32は、ユニバーサルシリアルバス(USB)インターフェース、CDライタもしくはバーナもしくはDVDライタもしくはバーナ、磁気記憶媒体もしくはフラッシュ記憶媒体へのインターフェース、または、メディアデータを記憶するもしくは送信するための他のインターフェースなどの、ネットワークインターフェース、または記憶媒体に書き込むためのインターフェースを備え得る。カプセル化ユニット30は、マルチメディアコンテンツの表現の各々のデータを出力インターフェース32に提供し得、出力インターフェース32は、ネットワーク送信媒体または記憶媒体を介してサーバデバイス60にデータを送り得る。図1の例では、サーバデバイス60は、それぞれのマニフェストファイル66と1つまたは複数の表現68A〜68N(表現68)とをそれぞれが含む様々なマルチメディアコンテンツ64を記憶する記憶媒体62を含む。いくつかの例では、出力インターフェース32はネットワーク74にデータを直接送ることもできる。
いくつかの例では、表現68は、適応セットに分離され得る。すなわち、表現68の様々なサブセットは、表現とともに表示されるべきテキストの言語または他の特性、復号され、たとえば、スピーカによって復号され提示されるべきオーディオデータ、適応セット内の表現のためのシーンのカメラ角度または現実世界のカメラ視野、特定の視聴者のためのコンテンツの適合性を記述するレーティング情報、などを識別し得る、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントのためのファイルフォーマット、テキストタイプ情報などの特性のそれぞれの共通セットを含み得る。
マニフェストファイル66は、特定の適応セットならびに適応セットのための共通特性に対応する表現68のサブセットを示すデータを含み得る。マニフェストファイル66はまた、適応セットの個々の表現のための、ビットレートのような個々の特性を表すデータを含んでもよい。このようにして、適応セットは、簡略化されたネットワーク帯域幅の適応を行ってもよい。適応セット内の表現は、マニフェストファイル66の適応セット要素の子要素を使用して示され得る。
サーバデバイス60は、要求処理ユニット70とネットワークインターフェース72とを含む。いくつかの例では、サーバデバイス60は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス60の特徴のいずれかまたはすべては、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスなどの、コンテンツ配信ネットワークの他のデバイス上に実装され得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ64のデータをキャッシュし、サーバデバイス60の構成要素に実質的に準拠する構成要素を含み得る。一般に、ネットワークインターフェース72は、ネットワーク74を介して送受信するように構成される。
要求処理ユニット70は、記憶媒体62のデータのための、クライアントデバイス40などのクライアントデバイスからネットワーク要求を受信するように構成される。たとえば、要求処理ユニット70は、R. Fieldingらによる、RFC2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月に説明されているようにハイパーテキスト転送プロトコル(HTTP)バージョン1.1を実装し得る。すなわち、要求処理ユニット70は、HTTP GET命令または部分GET要求を受信し、その要求に応じてマルチメディアコンテンツ64のデータを提供するように構成され得る。要求は、たとえば、セグメントのURLを使用して、表現68のうちの1つのセグメントを指定してもよい。いくつかの例では、要求はまた、セグメントの1つまたは複数のバイト範囲を指定することができ、したがって、部分GET要求を含む。要求処理ユニット70はさらに、表現68のうちの1つのセグメントのヘッダデータを提供するために、HTTP HEAD要求に対応するように構成されてもよい。いずれの場合でも、要求処理ユニット70は、要求されたデータをクライアントデバイス40のような要求側デバイスに提供するために、要求を処理するように構成されてもよい。
加えて、または代替的には、要求処理ユニット70は、eMBMSなどのブロードキャストプロトコルまたはマルチキャストプロトコルを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス20は、DASHセグメントおよび/またはサブセグメントを、説明したのと実質的に同じ方法で作成することができるが、サーバデバイス60は、これらのセグメントまたはサブセグメントをeMBMSまたは別のブロードキャストもしくはマルチキャストのネットワークトランスポートプロトコルを使用して配信することができる。たとえば、要求処理ユニット70は、クライアントデバイス40からマルチキャストグループ参加要求を受信するように構成され得る。すなわち、サーバデバイス60は、特定のマルチメディアコンテンツ(たとえば、ライブイベントのブロードキャスト)に関連付けられたマルチキャストグループに関連付けられたインターネットプロトコル(IP)アドレスを、クライアントデバイス40を含むクライアントデバイスに広告し得る。次にクライアントデバイス40は、マルチキャストグループに参加することを求める要求を提出することができる。この要求は、ルータがマルチキャストグループに関連付けられたIPアドレス宛のトラフィックをクライアントデバイス40などの加入クライアントデバイスに向けるように、ネットワーク74中、たとえば、ネットワーク74を構成するルータに伝播され得る。
図1の例に示すように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応し得るマニフェストファイル66を含む。マニフェストファイル66は、異なる代替表現68(たとえば、異なる品質を有するビデオサービス)の記述を含み得、記述は、たとえば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現68の他の記述的特性を含み得る。クライアントデバイス40は、表現68のセグメントにアクセスする方法を決定するために、メディアプレゼンテーションのMPDを取り出し得る。
具体的には、取出しユニット52は、ビデオデコーダ48の復号能力とビデオ出力44のレンダリング能力とを決定するために、クライアントデバイス40の構成データ(図示せず)を取り出し得る。構成データはまた、クライアントデバイス40のユーザによって選択される言語の選好、クライアントデバイス40のユーザによって設定される深さの選好に対応する1つもしくは複数のカメラ視野、および/または、クライアントデバイス40のユーザによって選択されるレーティングの選好のいずれかまたはすべてを含み得る。取出しユニット52は、たとえば、HTTP GET要求および部分GET要求を提出するように構成されたウェブブラウザまたはメディアクライアントを含み得る。取出しユニット52は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行されるソフトウェア命令に対応し得る。いくつかの例では、取出しユニット52に関して説明した機能のすべてまたは一部は、ハードウェア、または、ハードウェア、ソフトウェア、および/もしくはファームウェアの組合せにおいて実装され得、ここで、必要なハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
取出しユニット52は、クライアントデバイス40の復号能力およびレンダリング能力を、マニフェストファイル66の情報によって示される表現68の特性と比較し得る。取出しユニット52は、表現68の特性を決定するために、マニフェストファイル66の少なくとも一部を最初に取り出し得る。たとえば、取出しユニット52は、1つまたは複数の適応セットの特性を記述する、マニフェストファイル66の一部分を要求する場合がある。取出しユニット52は、クライアントデバイス40のコーディング能力およびレンダリング能力によって満たされ得る特性を有する表現68のサブセット(たとえば、適応セット)を選択することができる。取出しユニット52は、次いで、適応セット内の表現のためのビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、ネットワーク帯域幅によって満たされ得るビットレートを有する表現のうちの1つからセグメントを取り出し得る。
一般に、より高いビットレートの表現は、より高い品質のビデオ再生をもたらし得、より低いビットレートの表現は、利用可能なネットワーク帯域幅が減少したとき、十分な品質のビデオ再生を提供し得る。したがって、利用可能なネットワーク帯域幅が比較的高いときには、取出しユニット52は、ビットレートが比較的高い表現からデータを取り出すことができ、利用可能なネットワーク帯域幅が低いときには、取出しユニット52は、ビットレートが比較的低い表現からデータを取り出すことができる。このように、クライアントデバイス40は、ネットワーク74の変化するネットワーク帯域幅の利用可能性にも適応しながら、ネットワーク74を介してマルチメディアデータをストリーミングし得る。
加えて、または代替的には、取出しユニット52は、eMBMSまたはIPマルチキャストなどのブロードキャストネットワークプロトコルまたはマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。そのような例では、取出しユニット52は、特定のメディアコンテンツと関連付けられたマルチキャストネットワークグループに参加することを求める要求を提出することができる。取出しユニット52は、マルチキャストグループに参加した後、サーバデバイス60またはコンテンツ準備デバイス20にさらなる要求を出すことなしに、マルチキャストグループのデータを受信することができる。取出しユニット52は、たとえば、再生を停止するために、または、チャネルを異なるマルチキャストグループに変更するために、マルチキャストグループのデータがもはや必要とされないとき、マルチキャストグループを離れる要求を出すことができる。
ネットワークインターフェース54は、選択された表現のセグメントのデータを受信し、取出しユニット52に提供することができ、取出しユニット52は、カプセル化解除ユニット50にセグメントを提供し得る。カプセル化解除ユニット50は、ビデオファイルの要素を構成PESストリームにカプセル化解除し、符号化データを取り出すためにPESストリームをデパケット化し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームまたはビデオストリームのいずれの一部であるのかに応じて、オーディオデコーダ46またはビデオデコーダ48のいずれかに符号化データを送り得る。オーディオデコーダ46は、符号化オーディオデータを復号し、復号されたオーディオデータをオーディオ出力42に送り、ビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号されたビデオデータをビデオ出力44に送る。
ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、およびカプセル化解除ユニット50は、各々、適用できる場合は、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別の論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなど、様々な適切な処理回路のいずれかとして実装され得る。ビデオエンコーダ28およびビデオデコーダ48の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、これらのいずれもが、結合されたビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。同様に、オーディオエンコーダ26およびオーディオデコーダ46の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、これらのいずれもが、結合されたコーデックの一部として統合され得る。ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、および/またはカプセル化解除ユニット50を含む装置は、集積回路、マイクロプロセッサ、および/または、セルラー電話などのワイヤレス通信デバイスを備え得る。
クライアントデバイス40、サーバデバイス60、および/またはコンテンツ準備デバイス20は、本開示の技法に従って動作するように構成され得る。例のため、本開示は、クライアントデバイス40およびサーバデバイス60に関するこれらの技術を説明する。しかしながら、コンテンツ準備デバイス20は、サーバデバイス60の代わりに(または、加えて)これらの技法を実行するように構成され得ることを理解されたい。
カプセル化ユニット30は、NALユニットが属するプログラムを識別するヘッダ、ならびに、ペイロード、たとえば、オーディオデータ、ビデオデータ、または、NALユニットが対応するトランスポートストリームもしくはプログラムストリームを記述するデータを備えるNALユニットを形成し得る。たとえば、H.264/AVCにおいて、NALユニットは、1バイトのヘッダおよび可変サイズのペイロードを含む。そのペイロード内にビデオデータを含むNALユニットは、ビデオデータの様々な粒度(granularity)レベルを備え得る。たとえば、NALユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータの全ピクチャを含み得る。カプセル化ユニット30は、ビデオエンコーダ28からの符号化ビデオデータをエレメンタリストリームのPESパケットの形で受信することができる。カプセル化ユニット30は、各エレメンタリストリームを対応するプログラムと関連付けることができる。
カプセル化ユニット30はまた、複数のNALユニットからアクセスユニットを組み立てることができる。一般に、アクセスユニットは、ビデオデータのフレームを表すため、ならびに、そのようなオーディオデータが利用可能なとき、フレームに対応するオーディオデータを表すための1つまたは複数のNALユニットを備え得る。アクセスユニットは、一般に、1つの出力時間インスタンスに対するすべてのNALユニット、たとえば1つの時間インスタンスに対するすべてのオーディオデータおよびビデオデータを含む。たとえば、各ビューが毎秒20フレーム(fps)のフレームレートを有する場合、各時間インスタンスは、0.05秒の時間間隔に対応し得る。この時間間隔の間、同じアクセスユニット(同じ時間インスタンス)のすべてのビューに対する特定のフレームは、同時にレンダリングされ得る。一例では、アクセスユニットは、主コード化ピクチャとして提示され得る、1つの時間インスタンス内のコード化ピクチャを備え得る。
したがって、アクセスユニットは、共通の時間インスタンスのすべてのオーディオフレームおよびビデオフレーム、たとえば時刻Xに対応するすべてのビューを含むことができる。本開示はまた、特定のビューの符号化ピクチャを「ビューコンポーネント(view component)」と呼ぶ。すなわち、ビューコンポーネントは、特定の時刻における特定のビューに対する符号化ピクチャ(またはフレーム)を含むことができる。したがって、アクセスユニットは、共通の時間インスタンスのすべてのビューコンポーネントを含むものとして定義され得る。アクセスユニットの復号順序は、必ずしも出力または表示の順序と同じである必要はない。
メディアプレゼンテーションは、異なる代替表現(たとえば、異なる品質を有するビデオサービス)の記述を含み得るメディアプレゼンテーション記述(MPD)を含み得、記述は、たとえば、コーデック情報、プロファイル値、およびレベル値を含み得る。MPDは、マニフェストファイル66など、マニフェストファイルの一例である。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、様々なプレゼンテーションの動画フラグメントにどのようにアクセスするかを決定することができる。動画フラグメントは、ビデオファイルの動画フラグメントボックス(ムーフボックス(moof box))内に配置され得る。
(たとえば、MPDを備え得る)マニフェストファイル66は、表現68のセグメントの利用可能性を広告し得る。すなわち、MPDは、表現68のうちの1つの第1のセグメントが利用可能になる壁時計時間を示す情報、ならびに表現68内のセグメントの持続時間を示す情報を含み得る。このようにして、クライアントデバイス40の取出しユニット52は、開始時間ならびに特定のセグメントに先行するセグメントの持続時間に基づいて、各セグメントが利用可能になるときを決定することができる。
本開示の技法によれば、カプセル化ユニット30は、ファイルの残りの部分に悪影響を与えることなくドロップされ得るメディアファイルの部分(すなわち、ドロップ可能な部分)を表すデータを生成し得る。たとえば、以下で図5に関してより詳細に論じるように、ファイルのドロップ可能な部分は、参照のために使用されない各フレーム、または、参照のために使用され得るフレームならびに参照のためのフレームを使用し得るすべてのフレームを含むフレームのグループを含み得る。いくつかの例では、ドロップ可能な部分のセットは、セットが、特定の時間層における(すなわち、Nの時間識別子(ID)を有する)第1のフレームと、参照のための第1のフレームを使用し得るより大きい時間層における(すなわち、Nよりも大きい時間IDを有する)すべての他のフレームとを有する各部分を含むように定義され得る。
カプセル化ユニット30は、ファイルのバイト範囲を使用してドロップ可能な部分をシグナリングし得る。すなわち、各ドロップ可能な部分について、カプセル化ユニット30は、ドロップ可能な部分の最初のバイトおよび最後のバイトに対応する開始バイトおよび終了バイトをシグナリングし得る。カプセル化ユニット30は、ファイルのデータ構造内のドロップ可能な部分、たとえば、セグメントインデックス(sidx)ボックスをシグナリングし得る。さらに、カプセル化ユニット30は、ファイルのビデオコーディング層(VCL)データの外部にあるデータ構造内のドロップ可能な部分をシグナリングし得、ここで、VCLデータは、NALユニット、アクセスユニットなどの符号化ビデオデータを含む。このように、メディアアプリケーション(または、他のターゲットアプリケーション)は、VCLデータ自体に直接アクセスすることなく、ドロップ可能な部分を識別することができる。
カプセル化ユニット30が、受信されたデータに基づいてNALユニットおよび/またはアクセスユニットをビデオファイルに組み立てた後、カプセル化ユニット30は、出力のための出力インターフェース32にビデオファイルを渡す。いくつかの例では、カプセル化ユニット30は、ビデオファイルを直接クライアントデバイス40に送るのではなく、ビデオファイルをローカルに記憶することができ、または、ビデオファイルを、出力インターフェース32を介してリモートサーバに送ることができる。出力インターフェース32は、たとえば、送信機、トランシーバ、たとえばオプティカルドライブ、磁気媒体ドライブ(たとえば、フロッピードライブ)などのコンピュータ可読媒体にデータを書き込むためのデバイス、ユニバーサルシリアルバス(USB)ポート、ネットワークインターフェース、または他の出力インターフェースを含み得る。出力インターフェース32は、たとえば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体など、コンピュータ可読媒体34にビデオファイルを出力する。
ネットワークインターフェース54は、ネットワーク74を介してNALユニットまたはアクセスユニットを受信し、NALユニットまたはアクセスユニットを取出しユニット52を介してカプセル化解除ユニット50に提供する。カプセル化解除ユニット50は、ビデオファイルの要素を構成PESストリームにカプセル化解除し、符号化データを取り出すためにPESストリームをデパケット化し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームまたはビデオストリームのいずれの一部であるのかに応じて、オーディオデコーダ46またはビデオデコーダ48のいずれかに符号化データを送り得る。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送り、一方でビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号したビデオデータをビデオ出力44に送る。
本開示の技法によれば、ネットワークインターフェース54、取出しユニット52、および/またはカプセル化解除ユニット50は、受信されたファイル(1つもしくは複数のアクセスユニットおよび/または1つもしくは複数のNALユニットを含む)が疑わしい部分、すなわち、エラーを含む可能性がある部分、または実際にエラーを含む部分を有するかどうかを決定し得る。たとえば、ネットワークインターフェース54は、巡回冗長検査(CRC)を使用してエラーの潜在的な存在を決定し得る。別の例として、ネットワークインターフェース54は、アプリケーション層前方誤り訂正(AL-FEC)プロトコルを使用してエラーの潜在的な存在を決定し得る。ファイルの一部が潜在的に誤りであることを決定することに応答して、ネットワークインターフェース54は、たとえば、その部分のためのバイト範囲をシグナリングすることによって、および/またはファイル自体にマーカを挿入することによって、その部分を識別し得る。マーカは、疑わしい部分の開始および疑わしい部分の終了を示す固有のビットパターン、バイト値、バイトパターンなどであり得る。加えて、ネットワークインターフェース54は、たとえば、ファイルのためのファイル名を変更する(たとえば、クライアントデバイス40の動作環境のための不正なファイル名にファイル名を変更する)ことによって、および/またはファイルのためのURLもしくはURIを変更することによって、疑わしい部分を含むものとしてファイルを識別し得る。
取出しユニット52および/またはカプセル化解除ユニット50に対応し得るメディアプレーヤは、ファイル、ならびにファイルの疑わしい部分の指標を受信し得る。メディアプレーヤは、次いで、疑わしい部分をカバーする除去可能な部分のうちの1つまたは複数を識別するためにドロップ可能(本明細書では「除去可能」とも呼ばれる)な部分を使用し得、識別された1つまたは複数の除去可能な部分をドロップし得る。
このように、クライアントデバイス40は、メディアデータを取り出すためのデバイスの一例を示し、このデバイスは、メディアデータを含むファイルを取り出し、ファイルの一部が潜在的に誤りであることを決定し、ファイルが潜在的に誤りである部分を含むことを示すデータを形成し、(同様にデバイスによって実行される)ターゲットアプリケーションに利用可能な場所にファイルおよびデータを記憶するように構成される。
加えて、クライアントデバイス40はまた、メディアデータを処理するためのデバイスの一例を表し、このデバイスは、メディアデータを含むファイルを受信し、メディアデータの他の部分の正確な復号を妨げることなくファイルから除去され得るファイルの1つまたは複数の除去可能な部分を示す情報の第1のセットを受信し、潜在的に誤りであるファイルの疑わしい部分を示す情報の第2のセットを受信し、疑わしい部分と完全に重複する除去可能な部分のうちの1つまたは複数を決定し、決定された1つまたは複数の除去可能な部分をファイルから除去するように構成された1つまたは複数のプロセッサを含む。
さらに、コンテンツ準備デバイス20は、メディアデータのための情報をシグナリングするためのデバイスの一例を表し、このデバイスは、メディアデータを含むファイルを取得し、メディアデータの他の部分の正確な復号を妨げることなくファイルから除去され得るメディアデータの少なくとも一部を決定し、決定された部分を識別する情報をシグナリングするように構成された1つまたは複数のプロセッサを備える。
図2は、例示的なマルチメディアコンテンツ102の要素を示す概念図である。マルチメディアコンテンツ102は、マルチメディアコンテンツ64(図1)、または記憶媒体62に記憶された別のマルチメディアコンテンツに対応し得る。図2の例では、マルチメディアコンテンツ102は、メディアプレゼンテーション記述(MPD)104と複数の表現110〜120とを含む。表現110は、オプションのヘッダデータ112とセグメント114A〜114N(セグメント114)とを含み、表現120は、オプションのヘッダデータ122とセグメント124A〜124N(セグメント124)とを含む。文字Nが、便宜的に、表現110、120の各々の最後の動画フラグメントを指定するために使用される。いくつかの例では、表現110と表現120との間で異なる数の動画フラグメントが存在し得る。
MPD104は、表現110〜120とは別個のデータ構造を備え得る。MPD104は、図1のマニフェストファイル66に対応し得る。同様に、表現110〜120は、図1の表現68に対応し得る。一般に、MPD104は、コーディングおよびレンダリングの特性、適応セット、MPD104が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を取り出すための情報(たとえば、再生中のメディアコンテンツへの、ターゲットを定めた広告の挿入)のような、表現110〜120の特性を一般に表す、データを含み得る。
ヘッダデータ112は、存在するとき、セグメント114の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の現在の位置、セグメント114のうちのどれがランダムアクセスポイントを含むのか、セグメント114内のランダムアクセスポイントへのバイトオフセット、セグメント114のユニフォームリソースロケータ(URL)、またはセグメント114の他の態様を記述し得る。ヘッダデータ122は、存在する場合、セグメント124の同様の特性を表すことができる。加えて、または代替的には、そのような特性は、MPD104内に完全に含まれ得る。
セグメント114、124は、ビデオデータのフレームまたはスライスを各々が含み得る1つまたは複数のコード化ビデオサンプルを含む。セグメント114のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅の要件を有し得る。MPD104のデータは、図2の例には示されていないが、そのような特性は、MPD104のデータによって記述され得る。MPD104は、本開示で説明されるシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって記述されるような特性を含み得る。
セグメント114、124の各々は、固有のユニフォームリソースロケータ(URL)に関連付けられ得る。したがって、セグメント114、124の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント114または124を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント114または124の特定のバイト範囲を取り出すことができる。
本開示の技法によれば、セグメント114、124は、本明細書ではドロップ可能な部分とも呼ばれる1つまたは複数の除去可能な部分を含み得る。さらに、セグメント114、124のデータ、MPD104、ヘッダデータ112、122、または他のデータは、セグメント114、124の除去可能な部分を識別し得る。たとえば、セグメント114、124は、除去可能な部分を識別するそれぞれのsidxボックスを含み得る。別の例として、拡張可能マークアップ言語(XML)データは、除去可能な部分を識別し得る。
図3は、図2のセグメント114、124のうちの1つなどの表現のセグメントに対応し得る例示的なビデオファイル150の要素を示すブロック図である。セグメント114、124の各々は、図3の例で示されるデータの構成に実質的に準拠するデータを含み得る。ビデオファイル150は、セグメントをカプセル化すると言われ得る。上記で説明したように、ISOベースのメディアファイルフォーマットおよびその拡張によるビデオファイルは、「ボックス」と呼ばれる一連のオブジェクトにおいてデータを記憶する。図3の例では、ビデオファイル150は、ファイルタイプ(FTYP)ボックス152と、動画(MOOV)ボックス154と、セグメントインデックス(sidx)ボックス162と動画フラグメント(MOOF)ボックス164と、動画フラグメントランダムアクセス(MFRA)ボックス166とを含む。図3は、ビデオファイルの例を表すが、他のメディアファイルは、ISOベースのメディアファイルフォーマットおよびその拡張に従ってビデオファイル150のデータと同様に構成される他のタイプのメディアデータ(たとえば、オーディオデータ、タイムドテキストデータなど)を含み得る。
ファイルタイプ(FTYP)ボックス152は、一般に、ビデオファイル150のファイルタイプを記述する。ファイルタイプボックス152は、ビデオファイル150の最良の使用法を表す仕様を特定するデータを含んでもよい。ファイルタイプボックス152は、代替的には、MOOVボックス154、動画フラグメントボックス164、および/またはMFRAボックス166の前に配置され得る。
いくつかの例では、ビデオファイル150などのセグメントは、FTYPボックス152の前にMPD更新ボックス(図示せず)を含み得る。MPD更新ボックスは、ビデオファイル150を含む表現に対応するMPDが更新されるべきであることを示す情報を、MPDを更新するための情報とともに含み得る。たとえば、MPD更新ボックスは、MPDを更新するために使用されるリソースのURIまたはURLを提供することができる。別の例として、MPD更新ボックスは、MPDを更新するためのデータを含み得る。いくつかの例では、MPD更新ボックスは、ビデオファイル150のセグメントタイプ(STYP)ボックス(図示せず)の直後にくることがあり、このSTYPボックスは、ビデオファイル150のセグメントタイプを定義し得る。以下でより詳細に論じる図7は、MPD更新ボックスに関する追加の情報を提供する。
MOOVボックス154は、図3の例では、動画ヘッダ(MVHD)ボックス156と、トラック(TRAK)ボックス158と、1つまたは複数の動画延長(MVEX)ボックス160とを含む。一般に、MVHDボックス156は、ビデオファイル150の一般的な特性を表してもよい。たとえば、MVHDボックス156は、ビデオファイル150がいつ最初に作成されたかを表すデータ、ビデオファイル150がいつ最後に修正されたかを表すデータ、ビデオファイル150のタイムスケールを表すデータ、ビデオファイル150の再生の長さを表すデータ、または、ビデオファイル150を全般的に表す他のデータを含んでもよい。
TRAKボックス158は、ビデオファイル150のトラックのためのデータを含み得る。TRAKボックス158は、TRAKボックス158に対応するトラックの特性を表す、トラックヘッダ(TKHD)ボックスを含んでもよい。いくつかの例では、TRAKボックス158は、コード化ビデオピクチャを含み得るが、他の例では、トラックのコード化ビデオピクチャは、TRAKボックス158のデータおよび/またはsidxボックス162のデータによって参照され得る動画フラグメント164内に含まれ得る。
いくつかの例では、ビデオファイル150は、2つ以上のトラックを含み得る。したがって、MOOVボックス154は、ビデオファイル150中のトラックの数と等しい数のTRAKボックスを含み得る。TRAKボックス158は、ビデオファイル150の対応するトラックの特性を表す場合がある。たとえば、TRAKボックス158は、対応するトラックの時間情報および/または空間情報を表す場合がある。MOOVボックス154のTRAKボックス158と同様のTRAKボックスは、カプセル化ユニット30(図1)がビデオファイル150のようなビデオファイル中にパラメータセットトラックを含める場合、パラメータセットトラックの特性を表してもよい。カプセル化ユニット30は、パラメータセットトラックを表すTRAKボックス内で、パラメータセットトラックにシーケンスレベルSEIメッセージが存在することをシグナリングしてもよい。
MVEXボックス160は、たとえば、もしあれば、MOOVボックス154内に含まれるビデオデータに加えて、ビデオファイル150が動画フラグメント164を含むことをシグナリングするために、対応する動画フラグメント164の特性を記述し得る。ストリーミングビデオデータの文脈では、コード化ビデオピクチャがMOOVボックス154の中ではなく動画フラグメント164の中に含まれる場合がある。したがって、すべてのコード化ビデオサンプルがMOOVボックス154の中ではなく動画フラグメント164の中に含まれる場合がある。
MOOVボックス154は、ビデオファイル150内の動画フラグメント164の数に等しい数のMVEXボックス160を含み得る。MVEXボックス160の各々は、動画フラグメント164のうちの対応する1つに関する特性を表してもよい。たとえば、各MVEXボックスは、動画フラグメント164のうちの対応する1つに関する時間長を表す動画延長ヘッダ(MEHD)ボックスを含んでもよい。
上述のように、カプセル化ユニット30は、実際のコード化ビデオデータを含まないビデオサンプル内にシーケンスデータセットを記憶し得る。ビデオサンプルは、一般にアクセスユニットに対応してもよく、アクセスユニットは、特定の時間インスタンスにおけるコード化ピクチャの表現である。AVCの文脈では、アクセスユニットと、SEIメッセージのような他の関連する非VCL NALユニットとのすべてのピクセルを構築するための情報を格納する、1つまたは複数のVCL NALユニットを、コード化ピクチャは含む。したがって、カプセル化ユニット30は、シーケンスレベルSEIメッセージを含み得るシーケンスデータセットを、動画フラグメント164のうちの1つの中に含めてもよい。カプセル化ユニット30はさらに、シーケンスデータセットおよび/またはシーケンスレベルSEIメッセージの存在を、動画フラグメント164のうちの1つに対応するMVEXボックス160のうちの1つの中で、動画フラグメント164のうちの1つの中に存在するものとして、シグナリングしてもよい。
sidxボックス162は、ビデオファイル150のオプションの要素である。すなわち、3GPPファイルフォーマットまたは他のそのようなファイルフォーマットに準拠するビデオファイルは、必ずしもsidxボックス162を含む必要はない。3GPPファイルフォーマットの例によれば、sidxボックスは、セグメント(たとえば、ビデオファイル150内に含まれるセグメント)のサブセグメントを識別するために使用され得る。3GPPファイルフォーマットは、「メディアデータボックスに対応する1つまたは複数の連続する動画フラグメントボックスの自己完結型(self-contained)セットであって、動画フラグメントボックスによって参照されるデータを含むメディアデータボックスが、その動画フラグメントボックスに続き、同じトラックについての情報を含む次の動画フラグメントボックスに先立つ」としてサブセグメントを定義する。3GPPファイルフォーマットはまた、sidxボックスが、「ボックスによって文書化された(サブ)セグメントのサブセグメントへの一連の参照を含む。参照されるサブセグメントは、提示時間において連続する。同様に、セグメントインデックスボックスによって参照されるバイトは、セグメント内で常に連続する。参照されるサイズは、参照されるマテリアルにおけるバイトの数のカウントを与える。」ことを示す。
sidxボックス162は、一般に、ビデオファイル150内に含まれるセグメントの1つまたは複数のサブセグメントを表す情報を提供する。たとえば、そのような情報は、サブセグメントが開始および/または終了する再生時間、サブセグメントに関するバイトオフセット、サブセグメントがストリームアクセスポイント(SAP)を含む(たとえば、それによって開始する)かどうか、SAPのタイプ(たとえば、SAPが、瞬時デコーダリフレッシュ(IDR)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、ブロークンリンクアクセス(BLA)ピクチャなどのいずれであるか)、サブセグメント内の(再生時間および/またはバイトオフセットに関する)SAPの位置、などを含み得る。
本開示の教示によれば、sidxボックス162は、ビデオファイル150の他の領域に影響を与えることなくドロップされ得るビデオファイル150のデータ領域を定義するデータを含み得る。たとえば、sidxボックス162は、ビデオファイル150の残りの部分をデコードするビデオデコーダ48(図1)などのビデオデコーダの能力を損なうことなくビデオファイル150から独立して除去され得るビデオファイル150の1つまたは複数のバイト範囲を定義し得る。バイト範囲は、動画フラグメント164のそれぞれのサブセットに対応するビデオファイル150の部分を識別する。
動画フラグメント164は、1つまたは複数の符号化ビデオピクチャを含み得る。いくつかの例では、動画フラグメント164は、1つまたは複数のピクチャグループ(GOP)を含んでもよく、GOPの各々は、多数のコード化ビデオピクチャ、たとえばフレームまたはピクチャを含んでもよい。加えて、上述したように、動画フラグメント164は、いくつかの例ではシーケンスデータセットを含んでもよい。動画フラグメント164の各々は、動画フラグメントヘッダボックス(MFHD、図3には示されない)を含み得る。MFHDボックスは、動画フラグメントのシーケンス番号などの、対応する動画フラグメントの特性を記述し得る。動画フラグメント164は、ビデオファイル150の中で、シーケンス番号の順番に含まれてもよい。
MFRAボックス166は、ビデオファイル150の動画フラグメント164内のランダムアクセスポイントを記述し得る。これは、ビデオファイル150によってカプセル化されたセグメント内の特定の時間的位置(すなわち、再生時間)の探索(seek)を実行するなど、トリックモードを実行することを支援し得る。MFRAボックス166は、いくつかの例では、一般に任意選択であり、ビデオファイル中に含まれる必要はない。同様に、クライアントデバイス40のようなクライアントデバイスは、ビデオファイル150のビデオデータを正確に復号し表示するために、MFRAボックス166を必ずしも参照する必要はない。MFRAボックス166は、ビデオファイル150のトラックの数と等しい数のトラックフラグメントランダムアクセス(TFRA)ボックス(図示せず)を含んでもよく、またはいくつかの例では、ビデオファイル150のメディアトラック(たとえば、ノンヒントトラック)の数と等しい数のTFRAボックスを含んでもよい。
いくつかの例では、動画フラグメント164は、IDRピクチャなどの1つまたは複数のストリームアクセスポイント(SAP)を含み得る。同様に、MFRAボックス166は、SPAのビデオファイル150内の位置の指標を提供し得る。したがって、ビデオファイル150の時間的サブシーケンスは、ビデオファイル150のSAPから形成され得る。時間的サブシーケンスはまた、SAPに従属するPフレームおよび/またはBフレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適切に復号されるように、セグメント内に配置され得る。たとえば、データの階層的配置において、他のデータのための予測に使用されるデータはまた、時間的サブシーケンス内に含まれ得る。
さらに、データは、単一のバイト範囲が時間的サブシーケンスのために使用される特定のセグメントのすべてのデータを取り出す部分GET要求内で指定され得るように、連続的なサブシーケンス内に配置され得る。クライアントデバイス40などのクライアントデバイスは、IDRピクチャおよび/またはODRピクチャに対応する動画フラグメント(または、動画フラグメント164の一部)のバイト範囲を決定することによって、ビデオファイル150の時間的サブシーケンスを抽出し得る。以下でより詳細に論じるように、ビデオファイル150などのビデオファイルは、サブフラグメントインデックスボックスおよび/またはサブトラックフラグメントボックスを含み得、そのいずれかまたは両方は、ビデオファイル150の時間的サブシーケンスを抽出するためのデータを含み得る。
このように、sidxボックス162は、1つまたは複数のSAPの位置と、たとえば、動画フラグメント164に対応するビデオファイル150のデータ内の1つまたは複数のドロップ可能な領域の位置とを記述し得る。メディアプレーヤの構文解析ロジックは、疑わしいデータの範囲によって影響を受けたすべての範囲、または疑わしいデータをカプセル化する最小数のドロップ可能な範囲を破棄し得る。
sidxボックス162は、簡潔または冗長であり得る。すなわち、sidxボックス162は、すべてのドロップ可能なフレームを記述し得、または、ファイルフォーマッタが記述することを選択したものはなんでも記述し得る。たとえば、様々な数(たとえば、3、7、および23)のフレームのフレーム範囲のみを記述するデータは、有用であり得る。フレーム範囲のみを記述するデータは、1フレームの解像度でドロップ可能なデータを除去することになるが、単一のエラーシーケンスは、常に少なくとも3フレームにわたって十分に大きくてもよい。詳細と利益との間になんらかの潜在的バランスが存在する。
加えて、セグメントインデックス(ssix)が存在することがあり、ssixは、データを復号可能なレベルにする。サブセグメントインデックスは、サンプルグループを定義する補助データである。
sidxボックス162内のドロップ可能な範囲の順序付けは、メディアプレーヤのパーサがドロップ可能な領域を順番に使用し得るようなものであり得る。たとえば、ドロップ可能な領域は、最小のスパン(すなわち、影響を受ける最小のフレーム数)から最大のスパンまで識別され得る。パーサは、この順序付きリストのために図7に関して論じたものなどの方法を使用し得る。代替的には、リストは、図7の方法を適用するために、任意の順序で配信され得、クライアントデバイス上でソートされ得る。すなわち、配信順序は、最小から最大までである必要はない。これは、単なる便宜である。
図4は、インターネットプロトコル(IP)スタックによるユニットの例示的なセットを示す概念図である。この例では、ユニットのセットは、物理層ユニット180と、ユーザデータグラムプロトコル(UDP)IPスタックユニット182と、AL-FECユニット184と、ファイル配信プロトコルユニット186と、ダイナミックアダプティブストリーミングオーバーHTTP(DASH)クライアント188と、ISO BMFF/MMT(MPEGメディアトランスポート)ユニット190と、TBDファイルハンドラユニット192とコーデックデコーダ194とを含む。図4のユニットは、一般に、図1のクライアントデバイス40の要素に対応し得る。たとえば、物理層ユニット180、UDP IPスタックユニット182、AL-FECユニット184、およびファイル配信プロトコルユニット186は、ネットワークインターフェース54に対応し得、DASHクライアント188、ISO BMFF/MMTユニット190、およびTBDファイルハンドラユニット192は、取出しユニット52および/またはカプセル化解除ユニット50に対応し得、コーデックデコーダ194は、ビデオデコーダ48に対応し得る。
本明細書の技法は、ファイルデリバリーオーバーユニディレクショナルトランスポート(FLUTE)プロトコル、または拡張または将来のプロトコルとして他のファイル配信プロトコルに適用され得る。FLUTEは、tools.ietf.org/html/rfc6726で利用可能な、Pailaら、「FLUTE-File Delivery over Unidirectional Transport」、Internet Engineering Task Force(IETF)、RFC6726、2012年11月、に記載されている。すなわち、ファイル配信プロトコルユニット186は、FLUTEまたは他のそのようなプロトコルを実装し得る。たとえば、ファイル配信プロトコル186は、リアルタイムオブジェクトデリバリーオーバーユニディレクショナルトランスポート(ROUTE)プロトコルを実装し得る。一般に、ROUTEは、特に、アシンクロナスレイヤードコーディング(ALC)、レイヤードコーディングトランスポート(LCT)、および他の周知のインターネット標準を使用してIPマルチキャストネットワークを介してファイルを配信するためのプロトコルである。ROUTEは、一般に、追加の機能でFLUTEの拡張および機能的置換を提供する。
本開示は、ファイル配信プロトコルユニット186とファイルハンドラユニット192との間のインターフェースが、損失したデータまたは損傷したデータを含むファイル、すなわち、誤ったファイル(すなわち、疑わしいデータを有するファイル)がIPスタックを通過することを可能にし得る可能性があることを認識する。この誤ったまたは疑わしいファイルインターフェースは、ファイル配信プロトコルユニット186とファイルハンドラユニット192との間の破線によって示されているが、正しい/共通インターフェースは、実線で示されている。誤ったファイルをサポートするインターフェースは、オプションの違反とレイヤリング違反の両方がないことが望ましいおよび/またはことによると必要とされる。ソースファイルの元のサイズ、または少なくとも論理構造、および順序は保存されると仮定する。配信プロトコルは、典型的には、これらの側面を保証する。これらの側面が保持されない場合、ファイルエラー管理方法は、適切に機能しない可能性がある。
受信機が完全に統合された方法で構築されている場合、受信機は、デコーダまでの下位層における損失を処理するために独自のインターフェースを使用し得る。しかしながら、そのような統合された受信機は、典型的には、設計および実装のモジュール性のために一般的ではない。レイヤにわたって明確に定義されたAPIおよびプロトコルインターフェースは、堅牢で、相互運用可能で、拡張可能なシステムにとって重要である。
レイヤリング違反のない設計を達成するために、ファイル配信プロトコルユニット186とファイルハンドラユニット192との間のインターフェースは、エラー処理を実行するかどうかにかかわらず、動作するためにファイルタイプを決定する必要はない。さらに、ファイルハンドラは、もしあれば、エラーを有するファイルを、誤ったファイルタイプ内に含まれるデータだけから正確に構文解析することができるべきである。
DASHは、INTERNATIONAL STANDARD ISO/IEC 23009-1 Second edition 2014-05-01 Information Technology-Dynamic Adaptive Streaming Over HTTP (DASH) Part 1: Media Presentation Description and Segment Formatsで説明されている。DASHなどのファイル配信ストリーミングフォーマットの場合、ファイルハンドラのエラー管理メカニズムはまた、ファイルハンドラの上のターゲットコーデックとは独立しているべきである(ここで、コーデックは、たとえば、H.264/AVC、H.265/HEVC、または他のビデオコーディング標準もしくはその拡張に対応し得る)。3GPP DASHの場合には、ファイルタイプは、ISO/IEC 14496-12:2012(E)、INTERNATIONAL STANDARD ISO/IEC 14496-12 Fourth edition 2012-07-15 Corrected version 2012-09-15、Information Technology-Coding of Audio-Visual Objects Part 12: ISO Base Media File Formatに記載のように、もっぱらISO BMFFであり得る。
誤ったまたは損傷ファイルインターフェースは、疑わしい領域を記述するバイト範囲または他の同様な手段で実装され得る。ファイル配信プロトコルは、ファイルタイプのどのような知識もなしに、任意のファイルタイプのファイルの消去された領域の部分またはそうでなければ疑わしい領域の部分を記述し得る。加えてまたは代替において、インターフェースは、それが受信するすべての情報を提供する。これは、いろいろな情報の中でも、
・部分的に受信されたオブジェクトのファイルタイプ
・URLまたはURIなどの一意的識別子
・部分的に受信されたオブジェクトの公称サイズ
・すべての受信されたデータ、およびオブジェクト/ファイル内のデータの位置
を提供し得る。
インターフェースは、後続の層が、これが実際に疑わしいファイルの変形であることを決定することを可能にする体系的かつ明白な方法で、ファイル名の一般的な変更を提供し得、または、ユニフォームリソースロケータ(URL)もしくはユニフォームリソース識別子(URI)にアクセスし得る。たとえば、ファイル配信プロトコルユニット186は、「Text.doc」を「Text.doc.err」と改名し得る。後者は、Microsoft Windowsなどのオペレーティング環境における無効なファイルタイプである。エラーに気づかないファイルハンドラは、無効なファイルタイプを単に無視することになる。加えて、または代替的には、インターネットメディアタイプなどの他のファイルタイプのシグナリングが使用され得る。部分的に受信されたデータについて、新しいインターネットメディアタイプが定義され得る。
ファイル配信プロトコルユニット186からファイルハンドラへのインターフェースは、ファイル全体のいくつかの論理的サブセットを表すファイルの一部を渡すことをサポートすることができ、具体的な断片化の正確な理由は、ファイル配信プロトコルに対して不明瞭であるが、実際の断片化の存在は、ファイルパッケージャおよびファイルハンドラによって理解される。そのような機能の活動は、ラベル付けを介して伝達され得る。このラベル付けは、疑わしいものとしてファイルを体系的に命名すること(すなわち、オペレーティング環境にとって違法であり得る名前にファイルを再命名すること)ことと同様であり得る。これらの方法は、付加的であり得、すなわち、ファイルは、チャンクとしてマークされ得、チャンクは、疑わしいものとしてラベル付けされ得る。ファイル配信プロトコルは、配信におけるチャンキングなどの機能の存在の識別方法を含み得る。疑わしいものを識別するための方法の定義は、ネットワーク側におけるファイル配信プロトコルパッケージャに提供される定義態様内に含まれ得、または、単一の事前定義された方法が使用され得る。ターゲットアプリケーションは、方法が明らかになるかどうかを知るために、1つまたは2つのチャンクを調べ得る。
特定の方法、たとえば、chunk1、chunk2、またはchunk3は、チャンクのラベル付けに組み込まれ得る。ファイル配信メカニズムは、必ずしもその方法を理解しているというわけではない。ラベルは、ネットワーク側のソースアプリケーションとデバイス側のデバイスアプリケーションとの間の通信として機能し得る。アプリケーションがチャンクの取得を停止すると、デバイス側のファイルハンドラは、それらのポスティングを停止し得る。ファイル全体がポストされ得るので、ファイル全体でしか動作しないアプリケーションとの下位互換性は、維持される。これらの技法の追加の詳細は、以下で図8に関して説明される。継続するチャンクポスティングに影響を与えるアプリケーション消費の使用は、オプションであり、出力メモリ空間を節約し得る。
使用されないこのタイプのストリーミングメディアファイルインターフェースのための目的が存在し、たとえば、メディアセグメントファイルは、いわゆるメモリリークを防ぐために、いくらかの時間経過後に、別な方法でファイルプロトコル出力バッファから除去されない場合、除去される。この目的はまた、無効なエラーマーク付きファイルに拡張され得る。
上記で説明したように、3GPP DASHのファイルタイプは、ISO BMFFとして知られるISO/IEC 14496-12:2012によって現在説明されている。レイヤリングの独立性の目的を満たすために、ファイルハンドラは、ターゲットコーデックから独立した方法で、含まれるメディアを構文解析することができるべきである。これは、ファイルフォーマットが実際のコーデックタイプに敏感でない処理を可能にする一般的な方法でコーデック構文を記述するという目的をもたらす。これは、ファイルハンドラ、コーデック、および/または任意の他の層の置換を必要とすることなく、ファイルハンドリング層が置換されることを可能にし得る。
この用途に適したいくつかの方法が存在し、これらは、記述的であるように、または誤ったもしくは疑わしいデータの置換であるように緩やかに定義され得る。前者のカテゴリでは、ファイルの「疑わしい領域」は、たとえば、ファイル配信プロトコルユニット186によって、インターフェースにおいて列挙される。バイト範囲、たとえば「range=1876-23456」と記述するいくつかの方法が存在する。「置換」方法は、いわゆるエスケープシーケンスを利用し得る。欠落したソースデータの位置は、置換コードによって示され得る。
SAPは、同調させた後、または切替え(たとえば、表現間の切替え)時に、メディアセグメントの再生を開始することに関連する。SAPは、ファイルハンドラがSAP以降から復号および提示プロセスを開示することができるように、関連する位置、提示時間、およびタイプを有する。これを使用して、典型的には、SAP以降からの情報は、少なくともSAPからの正確な提示のために使用され得る。
SAPは、異なる手段によってシグナリングされ得る。1つの方法は、各セグメントがタイプ1またはタイプ2のSAPで開始するというシグナリングを提供することであり、すなわち、セグメント内の復号順序の最初のサンプルは、任意の他のデータとは独立して再生され得る。他のSAPシグナリングが提供され得る。
DASHの文脈では、ISO BMFF仕様は、セグメントインデックス(sidx)として知られるディレクトリ構造を含む。とりわけ、この構造は、一般的なストリームアクセスポイント(SAP)の位置およびタイプを記述する。この文脈における「一般的」は、どのような特定のコーデックに固有のものでもないことを意味する。このディレクトリ構造は、ドロップ可能(または除去可能)な領域を定義するのに適している。
基本的な概念は、ドロップ可能な領域である。現在のSAP位置の記述は、プレーヤ(コーデック)がクリーンに開始され得るファイル内の点の位置を与える。これらの追加は、ドロップ可能な領域を指定することになる。「領域」という用語の使用は、特定の方法ではなく、記述的な用語として意図される。
本開示は、例として、SAPの位置を示すセグメントインデックスの存在を説明する。しかしながら、セグメントインデックスの代わりに、SAPはまた、startsWithSAPを示すMPDなどの他の手段によって、またはプロファイルシグナリングによって決定され得る。
図5は、本開示の技法の例示的な使用例を示す概念図である。図5は、フレームの特定のグルーピングがドロップ可能であるビデオフレームへのいわゆる階層型Bタイプの階層コーデック参照を示す。図の下部にある数字の最初の行は、表示順序(時には、出力順序と呼ばれる)である。数字の一番下の行は、デコード順序とも呼ばれる配信順序である。数字は、フレームの相対的なまたは実際のピクチャオーダカウント(POC)値を表し得る。
フレーム参照のこの特定の構造について、数字の第2の行におけるイタリック体の数字(1、3、5、7、9、11、13、15、17、19、21、および23)は、個別にドロップされ得るフレームを表す。これらのフレーム(一般に、これらは、コーディング階層のレイヤ3におけるBフレームであるので、「B3」とラベル付けされている)の輪郭も破線であり、これらのフレームが個別にドロップされ得ることを表す。他のフレームは、参照のためにこれらのフレームを使用しないので、これらのフレームは、個別にドロップされ得る。
図5はまた、3フレームのグループにおいてドロップされ得る3フレームのいくつかのグループ(グループ{2,1,3}、{6,5,7}、{10,9,11}、{14,13,15}、{18,17,19}、および{22,21,23})を示す。これらのグループは、数の第2の行内のそれぞれのボックスによって囲まれている。言い換えれば、図5の階層に示すように、フレーム1および3は、フレーム2に依存し得る(すなわち、フレーム2に関連すると予測される)ので、フレーム2がドロップされる場合、フレーム1および3もドロップされる。加えて、図5は、7フレームのグループにおいてドロップされ得る7フレームのいくつかのグループ(グループ{4,2,1,3,6,5,7}、{12,10,9,11,14,13,15}、および{20,18,17,19,22,21,23})を示す。言い換えれば、フレーム2、1、3、6、5、および/または7のうちのいずれかまたはすべては、フレーム4に直接または間接的に依存するので、フレーム4がドロップされる場合、フレーム2、1、3、6、5、および7もドロップされる。
さらに、図5は、グループとしてドロップされ得るフレームのグループ{8,4,2,1,3,6,5,7,16,12,10,9,11,14,13,15,20,18,17,19,22,21,23}を示す。フレーム24は、このボックス内に含まれているが、フレーム24は、後続のセグメントの一部を形成するので、このグループがドロップされても、フレーム24自体は、実際にはドロップされないことが理解されるべきである。フレーム24の断片が疑わしい場合、後続のセグメントは、完全にドロップされることになる。これは、フレーム1〜23を含むセグメントについての疑わしいデータを含むフレーム0と機能的に同等である。したがって、図5は、数の第2の行内のフレーム24を表すために明るいグレーのテキストを使用する。フレーム24は、デコーダの順序で隣接する(decoder-order-adjacent)フレームではドロップされないが、フレーム8および/または16のいずれかまたは両方にエラーがある場合、フレーム20〜23は、フレーム8および/または16に依存する可能性がある(すなわち、フレーム8および/または16から直接または間接的に予測され得る)ので、フレーム20〜23は、ドロップされることになる。フレーム24が疑わしい場合、示されていないフレーム20、22、および23においてフレーム24への参照がないという場合を除いて、提示順序における7つの先行フレームは、ドロップされなければならない。
図6は、本開示の技法のさらなる例示的な使用例を示す概念図である。具体的には、図6は、部分200〜212の様々な例、ならびに、そのような疑わしい領域が生じるとき、本開示の技法に従ってどのデータがドロップされることになるのかの表示を示す。図6は、図5の配信されたフレームシーケンスに重畳されたエラーパターンを示す。図6は、時間におけるフレームを示し、すなわち、再生は、しばしば、時間において線形である。フレームのデータサイズは、必ずしも一定ではない。したがって、タイムスパンにおいて描かれたエラー(疑わしい部分)は、必ずしも線形のデータサイズではない。黒い両矢印のスパンは、単にデータ内の影響される時間範囲を示すことが意図される。
一例では、部分的なファイル再生のための許容可能な条件は、(それぞれの黒い矢印によって示される)対応する疑わしい部分がドロップ可能なデータの外にはならないことである。上記で論じたように、フレーム24は、次のセグメント内に存在し、結果としてグレーで示されているので、フレーム24は、特別な場合である。このファイル内の損失は、フレーム24に影響しないことになる。
本開示の技法の例として、疑わしい領域200〜212の各々の結果としてドロップされるデータは、以下で説明される。
部分200が(フレーム0、8、および4のデータを含む)疑わしいものとしてマークされている場合、ファイル全体がドロップされる。すなわち、フレーム0は、非ドロップ可能領域内に含まれ、したがって、メディアセグメント(ISO BMFFファイル)全体がドロップされる。
部分202が疑わしいものとしてマークされている場合、疑わしい領域は、2つの3フレームグループ{2,1,3}および{6,5,7}に影響を与える。したがって、これらの2つのグループは、この例ではドロップされる。部分202は、実際にはフレーム7に接触しないが、(フレーム7は、フレーム6に依存し得る/フレーム6から予測され得るので)フレーム7は、除去可能なグループ{6,5,7}内にあり、したがって、フレーム7も、この例ではドロップされる。
部分204が疑わしいものとしてマークされている場合、疑わしい領域は、フレーム5、7、16、12、および10に影響を与える。この例では、フレーム5〜23(すなわち、フレーム5、7、16、12、10、9、11、14、13、15、20、18、17、19、22、21、および23)は、結果としてドロップされる。
部分206が疑わしいものとしてマークされている場合、疑わしい領域は、グループ{14,13,15}に影響を与え、したがって、フレームのこのグループは、この例ではドロップされる。
部分208が疑わしいものとしてマークされている場合、疑わしい領域は、フレーム20に影響を与え、これは、7フレームグループ{20,18,17,19,22,21,23}がこの例ではドロップされることを意味する。
部分210が疑わしいものとしてマークされている場合、疑わしい領域は、フレーム17および19に影響を与える。これらのフレームは、図6中のイタリック体のテキストによって示されているように、個別にドロップ可能である。したがって、フレーム17および19は、この例ではドロップされる。
部分212が疑わしいものとしてマークされている場合、疑わしい領域は、3フレームグループ{22,21,23}に影響を与える。このフレームのグループは、ドロップ可能なグループであるので、フレーム22、21、および23は、この例ではブロックされる。
代替的な例として、ドロップ可能な領域を定義するのではなく、再生可能な領域をシグナリングするデータが提供され得る。すなわち、再生可能な領域が定義され得る。そのような再生可能な領域は、セグメント全体がドロップされる動作とは対照的に、依然として再生され得るデータを示す。現在のSAP位置の記述は、プレーヤ(コーデック)がクリーンに開始され得るファイル内の点の位置を与える。これらの追加は、再生可能な領域を指定することになる。基本的な概念は、1つのグループのすべてのデータが受信される限り、データは、再生され得るということである。
この例では、部分200が疑わしい場合、疑わしい領域は、フレーム0に影響を与えるので、メディアセグメントは、再生可能ではない。
領域202が疑わしい場合、フレーム0、8、4、および16〜23(すなわち、フレーム0、8、4、16、12、10、9、11、14、13、15、20、18、17、19、22、21、および23)は、再生可能であり、そのようにマークされる。
領域204が疑わしい場合、フレーム0〜6(すなわち、フレーム0、8、4、2、1、3、6)は、再生可能であり、そのようにマークされる。
領域206が疑わしい場合、フレーム0〜11(すなわち、フレーム0、8、4、2、1、3、6、5、7、16、12、10、9、および11)ならびに24〜23(すなわち、フレーム24、20、18、17、19、22、21、および23)は、再生可能であり、そのようにマークされる。
領域208が疑わしい場合、フレーム0〜24(すなわち、フレーム0、8、4、2、1、3、6、5、7、16、12、10、9、11、14、13、15、および24)は、再生可能であり、そのようにマークされる。
領域210が疑わしい場合、フレーム0〜18(すなわち、フレーム0、8、4、2、1、3、6、5、7、16、12、10、9、11、14、13、15、24、20、18)、および22〜23(すなわち、フレーム22、21、23)は、再生可能であり、そのようにマークされる。
領域212が疑わしい場合、フレーム0〜19(すなわち、フレーム0、8、4、2、1、3、6、5、7、16、12、10、9、11、14、13、15、24、20、18、17、および19)は、再生可能であり、そのようにマークされる。
図7は、本開示の技法を実行するための例示的な方法を示すフローチャートである。図7の方法は、クライアントデバイス40(図1)の取出しユニット52および/またはカプセル化解除ユニット50によって実行され得る。別の例として、図7の例は、クライアントデバイス40のプロセッサによって実行されるメディアプレーヤアプリケーションによって実行され得る。例のため、図7の方法は、取出しユニット52に関して説明される。
最初に、取出しユニット52は、メディアデータを含むファイルを受信する(220)。ファイルは、ビデオファイル150(図3)に準拠し得る。たとえば、ファイルは、たとえば、バイト範囲を使用して識別される、ドロップ可能(除去可能)な部分を示すsidxボックスを含み得る。ファイルはまた、疑わしい部分を含むものとしてマークされ得る。たとえば、ファイルは、ファイル名の後に続く「.err」を含むように、上記で論じたように名前を変更され得る。別の例として、ファイルのためのURLまたはURIが変更され得る。ファイルのためのデータはまた、たとえば、ファイルのバイト範囲を使用して、ファイルの疑わしい部分を識別し得る。
取出しユニット52は、ドロップ可能(除去可能)な領域の最小から最大に順序付けられたリストから、次の(たとえば、第1の)ドロップ可能なバイト領域を選択し得る(222)。上記で論じたように、このリストは、ファイルのsidxボックスによって提供され得る。代替的には、リストは、たとえば、ファイルのヘッダ内の、またはファイルのための副情報として、XMLデータの形態で提供され得る。図5の例に関して、第1の選択された範囲(最小の範囲)は、単一のフレーム、たとえば、フレーム1に対応する。
取出しユニット52は、次いで、この選択されたドロップ可能な範囲が疑わしいデータのいずれかを取り込むかどうかを決定する(224)。選択された範囲が疑わしいデータを取り込む場合(224の「YES」分岐)、取出しユニット52は、ドロップされるべきものとしてドロップ可能な部分にマークし得(226)、次いで、任意のマークされていない疑わしいデータが残っているかどうかを決定し得る(228)。
マークされていない疑わしいデータが残っている場合(228の「YES」分岐)、または選択された範囲がどのような疑わしいデータも取り込まない場合(224の「NO」分岐)、取出しユニット52は、任意のより多くの範囲が残っているどうかを決定する(230)。より多くの範囲が残っている場合(230の「YES」分岐)、取出しユニット52は、利用可能な範囲から次の範囲を選択し、マーキングループを再び反復する。他方では、より多くの範囲が残っていない場合(230の「NO」分岐)、取出しユニット52は、ファイルをドロップする(236)。
マークされていない疑わしいデータが残っていない場合(228の「NO」分岐)、すなわち、選択された範囲が疑わしい部分全体をカバーしている場合、取出しユニット52は、マークされたデータを削除し(232)、クリーンにされたファイルを出力する(234)。
このようにして、図7の方法は、メディアデータを含むファイルを受信するステップと、メディアデータの他の部分の正確なデコードを妨げることなくファイルから除去され得るファイルの1つまたは複数の除去可能な部分を示す情報の第1のセットを受信するステップと、潜在的に誤りであるファイルの疑わしい部分を示す情報の第2のセットを受信するステップと、疑わしい部分と完全に重複する除去可能な部分のうちの1つまたは複数を決定するステップと、決定された1つまたは複数の除去可能な部分をファイルから除去するステップとを含む方法の一例を示す。
内部エラー耐性機能を含むコーデックが存在する。ファイルハンドラが、たとえば、それより上のコーデックがこれらの機能をサポートし、サポートがオプションではないMIMEタイプからの、対応するデコーダがそのようなエラー耐性機能をサポートすることを示す情報で構成される場合、ファイルフォーマットは、エラー耐性のある領域のオプションの記述を組み込み得る。おそらくsidx内にXMLで実装されるこの種類の記述的ディレクトリ構造が与えられると、ハンドラは、いくつかの疑わしいデータを渡すことを選択する可能性がある。
たとえば、sidxボックス内に含まれる、既存のSAPロケーションは、ISO BMFFから疑わしいデータを削除するためのレイヤリングクリーン(layering clean)な方法を作成するのに適している。しかしながら、本開示の技法は、ISO BMFFファイルに限定されない。むしろ、ISO BMFFは、そのような一般的な方法を可能にするための適切なディレクトリ構造をたまたま有する。本明細書で説明される方法は、ファイルタイプに関して一般的であり、特定の例としてISO BMFFを論じる。
図8は、様々なタイプのアプリケーションのためのファイルのチャンクベースの配信の様々な例を示す概念図である。特に、上記で論じたように、ファイル配信インターフェースは、ファイルのチャンクの配信、ならびに、チャンクから再構築されたファイル全体の配信を提供し得る。チャンクおよびファイルは、エラーを含むものとしてラベル付けされてもされなくてもよい。図8は、様々なアプリケーションが受け入れることができるファイルのタイプおよびファイルチャンクのタイプを示す。イタリック体のテキストは、ファイルインターフェースが許可するファイルタイプを表し、非イタリック体のテキストは、アプリケーションが有効であると認識する(すなわち、アプリケーションが受け入れる)ファイルを表す。
第1の例250では、アプリケーションは、完全に組み立てられ、エラーのないファイルのみを受け入れる。これらのアプリケーションは、従来のアプリケーションとして記述され得る。言い換えれば、ファイルが有効なファイル名以外のなにかでマークされている場合、アプリケーションは、そのファイルを受け入れないことになる。
第2の例252では、アプリケーションは、エラーを含むファイル、たとえば、上記で論じた技法に従ってファイル名の拡張子として「.err」でマークされたファイルを認識し、処理するように構成される。たとえば、そのようなファイルが、他の部分の成功した処理(たとえば、復号)を妨げることなくドロップされ得る除去可能な部分と、疑わしい部分を示す情報とを含む場合、例252におけるアプリケーションは、たとえば、図7の方法に関して、上記で論じたように、除去可能な部分のうちの1つまたは複数をドロップし得る。
第3の例254として、ファイルは、チャンクにおいて配信され得る。すなわち、チャンクは、DASHクライアントなどのターゲットアプリケーションに利用可能にされ得る。ターゲットアプリケーションがチャンクを認識し、解釈することができる場合、ターゲットアプリケーションは、ファイルがチャンクから再構成されるのを待つのではなく、ファイルのチャンクを取り出し、処理し得る。いくつかの例では、チャンクは、ターゲットアプリケーションにアクセス可能な場所に提供され得、すべてのチャンクが受信された後、ファイルは、再構成され、アプリケーションに利用可能にされ得る。チャンクは、本開示の他の技法に従って、疑わしい部分を含むものとしてラベル付けされ得る。チャンクは、ファイル命名方式、たとえば、チャンクのファイル名に対する拡張子「.chunk」を使用して、チャンクとして識別され得る。たとえば、チャンクの実際の命名は、生成アプリケーションと受信アプリケーションとの間の取り決めであり得る。たとえば、ファイルは、xyz.fileであり得るが、ポストされるチャンク名は、xyz.file.method1.0、xyz.file.method1.1、xyz.file.method1.2などであり得る。この命名方式は、アプリケーション/ユニット間の対話のために予め構成され得る。配信プロトコルは、ファイル名を解釈する必要はない。代わりに、配信プロトコルユニットは、「method1.n」などをこれらのチャンクに追加するように構成され得る。チャンクの位置は、送信ファイルハンドラに指示され得るが、ファイルハンドラは、特定のチャンク方法、たとえば、method1を解釈する必要はない。
図9は、本開示の技法による別の例示的な方法を示すフローチャートである。図9の例示的な方法は、2つの別個のユニット、ミドルウェアユニット(たとえば、図4のファイル配信プロトコルユニット186)およびDASHクライアント(たとえば、DASHクライアント188)によって実行される。しかしながら、本開示の他のユニットもしくはデバイス、または同様のデバイスもしくはユニットが、図9の方法の様々な要素を実行するように構成され得ることが理解されるべきである。たとえば、図4のISO BMFF/MMTユニット190またはファイルハンドラユニット192は、DASHクライアントに起因するこの例示的な方法の要素を実行し得る。
この例では、最初に、ミドルウェアユニットは、メディアファイルを受信する(300)。メディアファイルは、メディアファイルのセグメントインデックス(SIDX)ボックス内、またはファイルの他のヘッダデータ内などに、その除去可能な部分を表すデータを含み得る。図9には示されていないが、ミドルウェアはまた、受信されたメディアファイルを含む複数のメディアファイルを記述するメタデータを含むマニフェストファイルを受信し得る。いくつかの例では、マニフェストファイルは、ファイルの除去可能な部分を示し得る。除去可能なファイルの部分は、たとえば、図5および図6の例に関して説明したように、ファイルの残りの部分の復号可能性に影響を与えることなく除去され得る部分であり得る。
ミドルウェアユニットは、次いで、潜在的なエラーについてメディアファイルをチェックする(302)。たとえば、ミドルウェアユニットは、パケットのうちの1つまたは複数がエラーを含むかどうかを決定するために、メディアファイルに関連付けられたパケットのCRCビットを使用し得る。加えて、または代替的に、ミドルウェアユニットは、メディアファイルが潜在的に誤ったデータを含むかどうかを決定するために、パケットおよび/またはメディアファイルに、アプリケーション層前方誤り訂正(AL-FEC)プロトコルを適用し得る。
メディアファイルが潜在的に誤ったデータを含むことを決定することに応答して、ミドルウェアユニットは、メディアファイルの潜在的に誤った部分を示すデータを形成する(304)。たとえば、ミドルウェアユニットは、メディアファイルの誤った部分の開始および終了を示すマーカをファイル内に挿入し得る。加えて、または代替的に、ミドルウェアユニットは、潜在的に誤ったデータのバイト範囲などの、潜在的に誤ったデータの位置を識別するデータを生成し得る。いずれにしても、ミドルウェアユニットは、次いで、DASHクライアントのための、メディアファイルと、メディアファイルの潜在的に誤った部分を識別するデータとを提供する(306)。たとえば、ミドルウェアユニットは、たとえば、DASHクライアントからのGET要求および部分的GET要求に応答するプロキシサーバとして動作して、メディアファイルをDASHクライアントが取り出すために利用可能にし得る。さらに、ミドルウェアユニットは、たとえば、マニフェストファイル内で、メディアファイルが利用可能であることを広告し得る。
DASHクライアントは、その後、メディアファイル、ならびに識別データ、すなわち、メディアファイルの潜在的に誤った部分を識別するデータを取り出し得る(308)。DASHクライアントは、たとえば、メディアファイルのためのマニフェストファイルから、またはメディアファイルのヘッダデータ(たとえば、SIDXボックス)から、メディアファイルの除去可能な部分を決定する(310)。さらに、ミドルウェアユニットからの識別データを使用して、DASHクライアントは、メディアファイルの誤った部分をカバーする除去可能な部分を除去する(312)。すなわち、DASHクライアントは、メディアファイルの誤った部分が完全に除去されるように、できる限り除去可能なデータの最小の部分を除去し得る。このようにして、DASHクライアントは、受信されたメディアファイルの残りの部分(すなわち、除去されておらず、誤っているものとしてシグナリングされなかった部分)のみを含む修正されたメディアファイルを生成する。DASHクライアントは、次いで、デコーダ、たとえば、ビデオデコーダ48(図1)などのビデオデコーダ、またはオーディオデコーダ46(図1)などのオーディオデコーダに残りの部分(すなわち、修正されたメディアファイル)を送る。
このようにして、図9の方法は、メディアデータを含むファイルを受信するステップと、ファイルの一部が潜在的に誤りであることを決定するステップと、ファイルが潜在的に誤りである部分を含むことを示すエラー表示データを形成するステップと、ファイルのメディアデータのためのターゲットアプリケーションに利用可能な場所にファイルおよびエラー表示データを記憶するステップとを含む方法の一例を表す。
同様に、図9の方法は、メディアデータを含むファイルを取得するステップと、メディアデータの他の部分の正確な復号を妨げることなくファイルから除去され得るメディアデータの少なくとも1つの部分を決定するステップと、決定された部分を識別する情報をシグナリングするステップとを含む方法の一例を表す。
さらに、図9の方法は、メディアデータを含むファイルを受信するステップと、メディアデータの他の部分の正確な復号を妨げることなくファイルから除去され得るファイルの1つまたは複数の除去可能な部分を示す情報の第1のセットを受信するステップと、潜在的に誤りであるファイルの疑わしい部分を示す情報の第2のセットを受信するステップと、疑わしい部分と完全に重複する除去可能な部分のうちの1つまたは複数を決定するステップと、決定された1つまたは複数の除去可能な部分をファイルから除去するステップとを含む方法の一例を表す。
1つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せにおいて実装され得る。ソフトウェアにおいて実装される場合、機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶され得、またはコンピュータ可読媒体を介して送信され得、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応するコンピュータ可読記憶媒体、または、たとえば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含むことがある。このようにして、コンピュータ可読媒体は、概して、(1)非一時的な有形コンピュータ可読記憶媒体、または(2)信号もしくは搬送波などの通信媒体に対応する場合がある。データ記憶媒体は、本開示で説明した技法を実装するための命令、コード、および/またはデータ構造を取り出すために1つまたは複数のコンピュータまたは1つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であってよい。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
例として、限定はしないが、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROM、もしくは他の光ディスクストレージ、磁気ディスクストレージ、もしくは他の磁気記憶デバイス、フラッシュメモリ、または、命令もしくはデータ構造の形態で所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を備え得る。また、任意の接続は、適切にコンピュータ可読媒体と呼ばれる。たとえば、命令がウェブサイト、サーバ、または他の遠隔リソースから、同軸ケーブル、光ファイバケーブル、より対線、デジタル加入者線(DSL)、または、赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバケーブル、より対線、DSL、または、赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義内に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに非一時的な有形記憶媒体を指すことを理解されたい。本明細書で使用されるディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザディスク、光ディスク、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク、およびBlu-ray（登録商標）ディスクを含み、ここで、ディスク(disk)は、通常、データを磁気的に再生するが、ディスク(disc)は、データをレーザで光学的に再生する。上記の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価の集積されたもしくは個別の論理回路などの、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または本明細書で説明される技法の実装に適した任意の他の構造のいずれかを指す場合がある。さらに、いくつかの態様では、本明細書で説明される機能は、符号化および復号のために構成された専用のハードウェアモジュールおよび/またはソフトウェアモジュール内に与えられてよく、あるいは複合コーデックに組み込まれてよい。また、技法は、1つまたは複数の回路または論理要素において完全に実装されてもよい。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、またはICのセット(たとえば、チップセット)を含む、幅広い種類のデバイスまたは装置において実装され得る。様々な構成要素、モジュール、またはユニットは、本開示において、開示された技法を実行するように構成されたデバイスの機能的態様を強調するように説明されているが、必ずしも異なるハードウェアユニットによる実現を必要としない。むしろ、上記で説明したように、様々なユニットは、コーデックハードウェアユニット内で組み合わされ得、または、適切なソフトウェアおよび/もしくはファームウェアとともに、上記で説明した1つもしくは複数のプロセッサを含む相互運用ハードウェアユニットの集合によって提供され得る。
様々な例が説明されている。これらの例および他の例は以下の特許請求の範囲内に入る。
10 システム
20 コンテンツ準備デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
40 クライアントデバイス
42 オーディオ出力
44 ビデオ出力
46 オーディオデコーダ
48 ビデオデコーダ
50 カプセル化解除ユニット
52 取出しユニット
54 ネットワークインターフェース
60 サーバデバイス
62 記憶媒体
64 マルチメディアコンテンツ
66 マニフェストファイル
68 表現
68A〜68N 表現
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
102 マルチメディアコンテンツ
104 メディアプレゼンテーション記述(MPD)
110 表現
112 ヘッダデータ
114 セグメント
114A〜114N セグメント
120 表現
122 ヘッダデータ
124A〜124N セグメント
150 ビデオファイル
152 ファイルタイプ(FTYP)ボックス
154 動画(MOOV)ボックス
156 動画ヘッダ(MVHD)ボックス
158 トラック(TRAK)ボックス
160 動画延長(MVEX)ボックス
162 セグメントインデックス(sidx)ボックス
164 動画フラグメント(MOOF)ボックス
166 動画フラグメントランダムアクセス(MFRA)ボックス
180 物理層ユニット
182 ユーザデータグラムプロトコル(UDP)IPスタックユニット
184 AL-FECユニット
186 ファイル配信プロトコルユニット
188 ダイナミックアダプティブストリーミングオーバーHTTP(DASH)クライアント
190 ISO BMFF/MMT(MPEGメディアトランスポート)ユニット
192 TBDファイルハンドラユニット
194 コーデックデコーダ
200〜212 部分

Claims (29)

  1. メディアデータを受信する方法であって、回路内で実装されたファイル配信プロトコルユニットによって、
    ファイル配信プロトコルに従って、メディアデータを含むファイルを受信するステップであって、前記ファイルが、国際標準化機構(ISO)ベースメディアファイルフォーマットまたはISOベースメディアファイルフォーマットの拡張に準拠し、前記ファイルが、ネットワーク層パケットヘッダ情報を除外する、ステップと、
    前記ファイルを受信した後、前記ファイルの一部が潜在的に誤りであることを決定するステップと、
    前記ファイルの前記一部が潜在的に誤りであることを決定することに応答して、前記ファイルが前記潜在的に誤りである部分を含むことを示すエラー表示データを形成するステップと、
    前記ファイルの前記メディアデータのためのターゲットアプリケーションに利用可能な場所に前記ファイルと、前記ファイルの他の部分のメディアデータの正確な復号を妨げることなく前記ファイルから除去され得る前記ファイルの1つまたは複数の除去可能な部分を示す情報のセットと、前記エラー表示データとを記憶するステップと
    を備える、方法。
  2. 前記エラー表示データを形成するステップが、前記潜在的に誤りである部分を識別するデータを形成するステップを備える、請求項1に記載の方法。
  3. 前記エラー表示データを形成するステップが、前記潜在的に誤りである部分に対応するバイト範囲を識別するデータを形成するステップを備える、請求項2に記載の方法。
  4. 前記エラー表示データを形成するステップが、前記ファイル内で、前記潜在的に誤りである部分の先頭に第1のマーカを挿入し、前記ファイル内で、前記潜在的に誤りである部分の終端に第2のマーカを挿入するステップを備える、請求項2に記載の方法。
  5. 前記エラー表示データを形成するステップが、前記ファイルが前記潜在的に誤りである部分を含むことを示すように前記ファイルを改名するステップを備える、請求項1に記載の方法。
  6. 前記ファイルを改名するステップが、前記ターゲットアプリケーションが実行されるオペレーティング環境にとって不正である前記ファイルのファイル名に対するファイル名拡張子を加えるステップを備える、請求項5に記載の方法。
  7. 前記ファイルを改名するステップが、前記ファイルのためのユニフォームリソースロケータ(URL)またはユニフォームリソース識別子(URI)を修正するステップを備える、請求項5に記載の方法。
  8. 前記エラー表示データを形成するステップが、前記ファイルのための特定のインターネットメディアタイプを提供するステップを備える、請求項1に記載の方法。
  9. 前記ターゲットアプリケーションが、ダイナミックアダプティブストリーミングオーバーHTTP(DASH)アプリケーションを備える、請求項1に記載の方法。
  10. 前記ターゲットアプリケーションが、対応するコーデックのための前記ファイルのハイレベルシンタックス(HLS)データを処理するように構成された、請求項1に記載の方法。
  11. 前記ファイルを受信するステップが、ファイルデリバリーオーバーユニディレクショナルトランスポート(FLUTE)プロトコルまたはリアルタイムオブジェクトデリバリーオーバーユニディレクショナルトランスポート(ROUTE)プロトコルのうちの1つを使用してファイルを受信するステップを備える、請求項1に記載の方法。
  12. 前記ターゲットアプリケーションがファイルの疑わしい部分の除去をサポートすることを示す前記ターゲットアプリケーションからの情報を受信するステップをさらに備える、請求項1に記載の方法。
  13. 前記情報を受信するステップが、HTTP拡張ヘッダ、前記ファイルのデータに対する要求内の引数、または前記ファイルのデータに対するHTTP要求の一部のうちの少なくとも1つとして前記情報を受信するステップを備える、請求項12に記載の方法。
  14. 回路内で実装されたプロセッサによりメディアデータを処理する方法であって、
    メディアデータを含むファイルを受信するステップであって、前記ファイルが、国際標準化機構(ISO)ベースメディアファイルフォーマットまたはISOベースメディアファイルフォーマットの拡張に準拠し、前記ファイルが、ネットワーク層パケットヘッダ情報を除外する、ステップと、
    前記メディアデータの他の部分の正確な復号を妨げることなく前記ファイルから除去され得る前記ファイルの1つまたは複数の除去可能な部分を示す情報の第1のセットを受信するステップと、
    前記ファイルの潜在的に誤りである疑わしい部分を示す情報の第2のセットを受信するステップと、
    前記疑わしい部分と完全に重複する前記除去可能な部分のうちの1つまたは複数を決定するステップと、
    前記決定された1つまたは複数の除去可能な部分を前記ファイルから除去するステップと
    を備える、方法。
  15. 前記ファイルが前記疑わしい部分を含むことを示す情報の第3のセットを受信するステップをさらに備え、前記除去可能な部分のうちの前記1つまたは複数を決定するステップが、前記情報の第3のセットに基づいて前記除去可能な部分のうちの前記1つまたは複数を決定するステップを備える、請求項14に記載の方法。
  16. 前記情報の第3のセットが、オペレーティング環境にとって不正である前記ファイルのファイル名に対するファイル名拡張子、前記ファイルのための修正されたユニフォームリソースロケータ(URL)または修正されたユニフォームリソース識別子(URI)のうちの少なくとも1つを備える、請求項15に記載の方法。
  17. 前記情報の第1のセットが、前記ファイルのセグメントインデックス(SIDX)ボックス、拡張可能マークアップ言語(XML)データ、前記部分に対応する前記ファイルのバイト範囲、または前記ファイルのビデオコーディング層(VCL)データの外部の情報のうちの少なくとも1つを備える、請求項14に記載の方法。
  18. 前記情報の第2のセットが、
    前記疑わしい部分に対応する前記ファイルのバイト範囲、または、
    前記疑わしい部分の先頭における前記ファイル内の第1のマーカおよび前記疑わしい部分の終端における前記ファイル内の第2のマーカ
    のうちの少なくとも1つを備える、請求項14に記載の方法。
  19. 前記ファイルの残りの部分をデコーダに送るステップをさらに備える、請求項14に記載の方法。
  20. メディアデータを処理するためのデバイスであって、
    ファイル配信プロトコルに従って、メディアデータを含むファイルを受信することであって、前記ファイルが、国際標準化機構(ISO)ベースメディアファイルフォーマットまたはISOベースメディアファイルフォーマットの拡張に準拠し、前記ファイルが、ネットワーク層パケットヘッダ情報を除外する、受信することと、
    前記ファイルを受信した後、前記ファイルの一部が潜在的に誤りであることを決定することと、
    前記ファイルの前記一部が潜在的に誤りであることを決定することに応答して、前記ファイルが前記潜在的に誤りである部分を含むことを示すエラー表示データを形成することと、
    前記ファイルの前記メディアデータのためのターゲットアプリケーションに利用可能な場所に前記ファイルと、前記ファイルの他の部分のメディアデータの正確な復号を妨げることなく前記ファイルから除去され得る前記ファイルの1つまたは複数の除去可能な部分を示す情報のセットと、前記エラー表示データとを記憶することと
    を行うように構成された回路内で実装された1つまたは複数のプロセッサを備える、デバイス。
  21. 前記1つまたは複数のプロセッサが、前記潜在的に誤りである部分を識別するように前記エラー表示データを形成するように構成された、請求項20に記載のデバイス。
  22. 前記エラー表示データを形成するために、前記1つまたは複数のプロセッサが、前記ファイルが前記潜在的に誤りである部分を含むことを示すように前記ファイルを改名するように構成された、請求項20に記載のデバイス。
  23. 前記エラー表示データを形成するために、前記1つまたは複数のプロセッサが、前記ファイルのための特定のインターネットメディアタイプを提供するように構成された、請求項20に記載のデバイス。
  24. 前記ターゲットアプリケーションが、ダイナミックアダプティブストリーミングオーバーHTTP(DASH)アプリケーションを備える、請求項20に記載のデバイス。
  25. メディアデータを処理するためのデバイスであって、
    メディアデータを含むファイルを受信することであって、前記ファイルが、国際標準化機構(ISO)ベースメディアファイルフォーマットまたはISOベースメディアファイルフォーマットの拡張に準拠し、前記ファイルが、ネットワーク層パケットヘッダ情報を除外する、ことと、
    前記メディアデータの他の部分の正確な復号を妨げることなく前記ファイルから除去され得る前記ファイルの1つまたは複数の除去可能な部分を示す情報の第1のセットを受信することと、
    潜在的に誤りである前記ファイルの疑わしい部分を示す情報の第2のセットを受信することと、
    前記疑わしい部分と完全に重複する前記除去可能な部分のうちの1つまたは複数を決定することと、
    前記決定された1つまたは複数の除去可能な部分を前記ファイルから除去することと
    を行うように構成された1つまたは複数のプロセッサを備える、デバイス。
  26. 前記1つまたは複数のプロセッサが、前記ファイルが前記疑わしい部分を含むことを示す情報の第3のセットを受信するようにさらに構成され、前記1つまたは複数のプロセッサが、前記情報の第3のセットに基づいて前記除去可能な部分のうちの前記1つまたは複数を決定するように構成され、前記情報の第3のセットが、オペレーティング環境にとって不正である前記ファイルのファイル名に対するファイル名拡張子、前記ファイルのための修正されたユニフォームリソースロケータ(URL)または前記ファイルのための修正されたユニフォームリソース識別子(URI)のうちの少なくとも1つを備える、請求項25に記載のデバイス。
  27. 前記情報の第1のセットが、前記ファイルのセグメントインデックス(SIDX)ボックス、拡張可能マークアップ言語(XML)データ、前記部分に対応する前記ファイルのバイト範囲、または前記ファイルのビデオコーディング層(VCL)データの外部の情報のうちの少なくとも1つを備える、請求項25に記載のデバイス。
  28. 前記情報の第2のセットが、前記疑わしい部分に対応する前記ファイルのバイト範囲、または、前記疑わしい部分の先頭における前記ファイル内の第1のマーカおよび前記疑わしい部分の終端における前記ファイル内の第2のマーカのうちの少なくとも1つを備える、請求項25に記載のデバイス。
  29. デコーダをさらに備え、前記1つまたは複数のプロセッサが、前記ファイルの残りの部分を前記デコーダに送るように構成された、請求項25に記載のデバイス。
JP2017500032A 2014-07-09 2015-07-08 ネットワークを介して交換されたファイルのためのエラー処理 Active JP6285608B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201462022539P 2014-07-09 2014-07-09
US62/022,539 2014-07-09
US14/793,398 2015-07-07
US14/793,398 US9645878B2 (en) 2014-07-09 2015-07-07 Error handling for files exchanged over a network
PCT/US2015/039577 WO2016007645A1 (en) 2014-07-09 2015-07-08 Error handling for files exchanged over a network

Publications (2)

Publication Number Publication Date
JP2017528022A JP2017528022A (ja) 2017-09-21
JP6285608B2 true JP6285608B2 (ja) 2018-02-28

Family

ID=53674357

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017500032A Active JP6285608B2 (ja) 2014-07-09 2015-07-08 ネットワークを介して交換されたファイルのためのエラー処理

Country Status (7)

Country Link
US (1) US9645878B2 (ja)
EP (1) EP3167621B1 (ja)
JP (1) JP6285608B2 (ja)
KR (1) KR101857089B1 (ja)
CN (1) CN106576097B (ja)
BR (1) BR112017000062A2 (ja)
WO (1) WO2016007645A1 (ja)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101783618B1 (ko) 2014-08-22 2017-10-10 엘지전자 주식회사 방송 신호 송신 방법, 방송 신호 송신 장치, 방송 신호 수신 방법 및 방송 신호 수신 장치
WO2016072725A1 (ko) 2014-11-04 2016-05-12 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US9407968B2 (en) * 2014-12-22 2016-08-02 Verizon Patent And Licensing Inc. Multicast and unicast adaptive bitrate services
KR101801595B1 (ko) 2015-01-21 2017-11-27 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
JP6617632B2 (ja) 2016-03-24 2019-12-11 ティアック株式会社 オーディオ・ビデオ信号処理装置及びプログラム
JP6658181B2 (ja) * 2016-03-24 2020-03-04 ティアック株式会社 オーディオ装置及びオーディオシステム
JP6672934B2 (ja) 2016-03-24 2020-03-25 ティアック株式会社 オーディオ信号処理装置及びプログラム
TWI599218B (zh) * 2016-07-29 2017-09-11 元智大學 即時影音傳輸系統
US10412412B1 (en) * 2016-09-30 2019-09-10 Amazon Technologies, Inc. Using reference-only decoding of non-viewed sections of a projected video
US10553029B1 (en) 2016-09-30 2020-02-04 Amazon Technologies, Inc. Using reference-only decoding of non-viewed sections of a projected video
US10609356B1 (en) 2017-01-23 2020-03-31 Amazon Technologies, Inc. Using a temporal enhancement layer to encode and decode stereoscopic video content
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
CN107360191B (zh) * 2017-08-28 2021-02-02 腾讯科技（深圳）有限公司 一种文件获取方法、装置及存储设备
US10887385B2 (en) * 2017-09-20 2021-01-05 Akamai Technologies, Inc. Marker based reporting system for hybrid content delivery network and peer to peer network
GB201721847D0 (en) * 2017-12-22 2018-02-07 Telecom Paris Tech Priority map for media files
CN110971564B (zh) * 2018-09-28 2021-03-30 华为技术有限公司 传输媒体数据的方法、客户端和服务器

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10191356A (ja) 1996-12-27 1998-07-21 Oki Electric Ind Co Ltd 画像符号化装置
KR100926017B1 (ko) * 2005-05-13 2009-11-11 퀄컴 인코포레이티드 대역외 디렉토리 정보를 이용한 에러 복원의 개선
CN101218798A (zh) * 2005-05-13 2008-07-09 高通股份有限公司 使用频带外的目录信息改进抗错性
EP1940167A4 (en) * 2005-09-20 2009-04-08 Pioneer Corp DIGITAL BROADCAST RECEIVER
JP2007318545A (ja) * 2006-05-26 2007-12-06 Canon Inc データ送信装置、データ受信装置、データ送信方法及びデータ受信方法
PL2195952T3 (pl) * 2007-09-19 2011-08-31 Fraunhofer Ges Forschung Urządzenie i sposób do zapisywania i odczytywania pliku zawierającego kontener danych multimedialnych i kontener metadanych
FR2929787B1 (fr) * 2008-04-04 2010-12-17 Canon Kk Procede et dispositif de traitement d'un flux de donnees
JP2011010091A (ja) * 2009-06-26 2011-01-13 Toshiba Corp 出力情報制御装置および出力情報制御方法
JP2012235349A (ja) * 2011-05-02 2012-11-29 Olympus Corp ファイル記録方法、ファイル再生方法、撮像装置、および再生装置
WO2013020709A1 (en) * 2011-08-10 2013-02-14 Telefonaktiebolaget L M Ericsson (Publ) Media stream handling
CN102929733B (zh) 2012-10-18 2015-02-11 北京奇虎科技有限公司 一种错误文件处理方法、装置和客户端设备

Also Published As

Publication number Publication date
EP3167621B1 (en) 2021-04-21
JP2017528022A (ja) 2017-09-21
KR101857089B1 (ko) 2018-05-11
US9645878B2 (en) 2017-05-09
CN106576097A (zh) 2017-04-19
CN106576097B (zh) 2018-12-21
WO2016007645A1 (en) 2016-01-14
EP3167621A1 (en) 2017-05-17
US20160011923A1 (en) 2016-01-14
KR20170031104A (ko) 2017-03-20
BR112017000062A2 (pt) 2017-11-07

Similar Documents

Publication Publication Date Title
JP6285608B2 (ja) ネットワークを介して交換されたファイルのためのエラー処理
US11924526B2 (en) Segment types as delimiters and addressable resource identifiers
KR102454839B1 (ko) 미디어 스트리밍을 위한 세그먼트 청크들의 취출 및 액세스
JP5937275B2 (ja) ネットワークストリーミングのための失われたメディアデータの置換
CN111837403B (zh) 处理用于以流传送媒体数据的交互性事件
KR102303582B1 (ko) 웹 콘텐츠에 대한 파일 트랙들을 사용하여 미디어 데이터를 프로세싱
JP6254291B2 (ja) Ｄａｓｈのロバストなライブ動作
CN112154672B (zh) 一种检索媒体数据的方法、设备及可读存储介质
JP6903688B2 (ja) サンプルエントリーおよびランダムアクセス
US11321516B2 (en) Processing dynamic web content of an ISO BMFF web resource track
KR20190039724A (ko) 미디어 데이터 스트리밍을 위한 sei 트랙들의 시스템 레벨 시그널링
KR20190010568A (ko) 샘플 엔트리들 및 랜덤 액세스

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170801

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170801

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20170801

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20171225

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: 20180105

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20171227

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180201

R150 Certificate of patent or registration of utility model

Ref document number: 6285608

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