JP5628422B2 - トリックモードビデオ表現のためのビデオサンプルを信号伝達すること - Google Patents

トリックモードビデオ表現のためのビデオサンプルを信号伝達すること Download PDF

Info

Publication number
JP5628422B2
JP5628422B2 JP2013518668A JP2013518668A JP5628422B2 JP 5628422 B2 JP5628422 B2 JP 5628422B2 JP 2013518668 A JP2013518668 A JP 2013518668A JP 2013518668 A JP2013518668 A JP 2013518668A JP 5628422 B2 JP5628422 B2 JP 5628422B2
Authority
JP
Japan
Prior art keywords
frame
byte
byte range
fragments
request
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
JP2013518668A
Other languages
English (en)
Other versions
JP2013535866A (ja
Inventor
チェン、イン
カークゼウィックズ、マルタ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
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
Priority claimed from US12/908,593 external-priority patent/US9485546B2/en
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2013535866A publication Critical patent/JP2013535866A/ja
Application granted granted Critical
Publication of JP5628422B2 publication Critical patent/JP5628422B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/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/8451—Structuring of content, e.g. decomposing content into time segments using Advanced Video Coding [AVC]
    • 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/437—Interfacing the upstream path of the transmission network, e.g. for transmitting client requests to a VOD server
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • 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/64322—IP
    • 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • 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/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • 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/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Description

本開示は、符号化ビデオデータのトランスポートに関する。
デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップ又はデスクトップコンピュータ、デジタルカメラ、デジタル記録機器、デジタルメディアプレーヤ、ビデオゲーム機器、ビデオゲームコンソール、セルラー電話又は衛星無線電話、ビデオ遠隔会議機器などを含む、広範囲にわたる機器に組み込まれ得る。デジタルビデオ機器は、デジタルビデオ情報をより効率的に送信及び受信するために、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３又はＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ１０、Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）によって定義された規格、及びそのような規格の拡張に記載されているビデオ圧縮技法など、ビデオ圧縮技法を実装する。
ビデオ圧縮技法は、ビデオシーケンスに固有の冗長性を低減又は除去するために空間的予測及び／又は時間的予測を実行する。ブロックベースのビデオコーディングの場合、ビデオフレーム又はスライスがマクロブロックに区分され得る。各マクロブロックはさらに区分され得る。イントラ符号化（Ｉ）フレーム又はスライス中のマクロブロックは、隣接マクロブロックに関する空間的予測を使用して符号化される。インター符号化（Ｐ又はＢ）フレーム又はスライス中のマクロブロックは、同じフレーム又はスライス中の隣接マクロブロックに関する空間的予測、或いは他の参照フレームに関する時間的予測を使用し得る。
Ｈ．２６４／ＡＶＣに基づく新しいビデオコーディング規格を開発するための取り組みが行われている。１つのそのような規格は、Ｈ．２６４／ＡＶＣのスケーラブル拡張であるスケーラブルビデオコーディング（ＳＶＣ）規格である。別の規格は、Ｈ．２６４／ＡＶＣのマルチビュー拡張になったマルチビュービデオコーディング（ＭＶＣ）規格である。ＡＶＣ規格のバージョンは、ＡＶＣ仕様にＳＶＣとＭＶＣとを組み込んだ、http://wftp3.itu.int/av-arch/jvt-site/2009_01_Geneva/JVT-AD007.zipから入手可能な、JVT-AD007、「Editors' draft revision to ITU-T Rec. H.264 | ISO/IEC 14496-10 Advanced Video Coding - in preparation for ITU-T SG 16 AAP Consent (in integrated form)」、30th JVT meeting、Geneva、CH、Feb. 2009に記載されている。
本出願は、各々の内容全体が参照により本明細書に組み込まれる、２０１０年６月２９日に出願された米国仮出願第６１／３５９，７４８号、２０１０年７月２１日に出願された米国仮出願第６１／３６６，４３６号、及び２０１０年７月１３日に出願された米国仮出願第６１／３６３，８８４号の利益を主張する。
関連出願の相互参照
本特許出願は、以下の同時係属米国特許出願、すなわち、本明細書と同時に出願され、本出願の譲受人に譲渡され、その全体が参照により本明細書に明確に組み込まれる、弁理士整理番号第１０１６５７Ｕ２号を有する、Ｙｉｎｇ Ｃｈｅｎらによる「SIGNALING VIDEO SAMPLES FOR TRICK MODE VIDEO PRESENTATIONS」と題する米国特許出願第１２／９０５，５３７号に関する。
本開示は、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミングなどのストリーミングプロトコルを使用したメディアデータのトランスポートに関係する技法について説明する。特に、本開示の技法は、メディアコンテンツ中のランダムアクセスポイント（ＲＡＰ）の特性を信号伝達することを対象とする。ランダムアクセスポイントは概して、デコーダが、そのランダムアクセスポイントに時間的に先行する符号化ユニットなどの前のデータに関係なく、ビデオ表現を適切に復号し始め得るポイントに対応する。即ち、ランダムアクセスポイントは、独立した復号可能なユニット、例えば、ビデオデータのイントラ符号化フレーム又はスライスを備え得る。
ストリーミング（例えば、ＨＴＴＰストリーミング）は概して、発信源機器から宛先機器へのデータの転送に関与する。本開示の技法によれば、発信源機器は、瞬時復号リフレッシュ（ＩＤＲ：instantaneous decoding refresh）フレームに加えて、オープン復号リフレッシュ（ＯＤＲ：open decoding refresh）フレームの特性を信号伝達し得る。これらの特性を信号伝達することによって、宛先機器は、ＯＤＲフレームにおいて、ビデオデータのストリーム中に含まれているビデオ表現の再生を開始したいという要求を生成し得る。このようにして、宛先機器のユーザは、開始するか、又はビデオ表現の特定の時間ロケーションにジャンプするように要求し得、宛先機器は、要求された時間ロケーションに最も近いＩＤＲ又はＯＤＲピクチャを含んでいるビデオ表現の一部分のストリーミングを要求し得る。したがって、ＩＤＲピクチャにおけるビデオ表現の再生及び／又はストリーミングを開始することに限定されるのではなく、本開示の技法による宛先機器は、ＩＤＲ又はＯＤＲのいずれかにおいてストリームを開始し得、それにより、帯域幅消費を低減し、及び／又はより頻繁なランダムアクセスポイント及び／又はビデオスイッチングポイントを可能にして、ユーザの視聴経験(user’s viewing experience)を改善し得る。
本開示はまた、宛先機器がトリックモードでイントラ符号化ピクチャを検索し、提示することができるように、イントラ符号化ピクチャの特性を信号伝達するための技法を提供する。トリックモード（trick mode）は、概して、高速再生モード、例えば、早送り又は早戻しに対応する。そのようなモードでは、宛先機器は、ビデオ表現中の利用可能なフレームのサブセットのみを再生し得る。したがって、宛先機器は、トリックモードで再生されるべきフレームを検索するだけでよい。したがって、本開示の技法によれば、宛先機器は、信号伝達された特性に基づいてイントラ符号化フレームについての要求を生成し得、それにより、ネットワークストリーミングプロトコルを使用してメディアが転送されるとき、帯域幅消費を低減し、トリックモード再生を可能にし得る。
例えば、方法について本明細書で説明する。本方法は、クライアント機器においてサーバ機器から、メディアセグメンテーションのオープン復号リフレッシュ（ＯＤＲ）ランダムアクセスポイント（ＲＡＰ）フレームの指示を受信することであって、復号順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの少なくとも１つのフレームが正しく復号され得ず、表示順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの各フレームが、表示順序でＯＤＲ ＲＡＰより前のフレームのコンテンツに依拠することなしに、正しく復号され得る、受信することを含む。本方法は、クライアント機器が、示されたＯＤＲ ＲＡＰフレームを含んでいるメディアセグメンテーションで開始するメディアデータのストリームを検索する要求をサーバ機器に送ることをさらに含む。
別の例によれば、機器について本明細書で説明する。本機器は、サーバ機器から、メディアセグメンテーションのオープン復号リフレッシュ（ＯＤＲ）ランダムアクセスポイント（ＲＡＰ）フレームの指示を受信するための手段であって、復号順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの少なくとも１つのフレームが正しく復号され得ず、表示順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの各フレームが、表示順序でＯＤＲ ＲＡＰより前のフレームのコンテンツに依拠することなしに、正しく復号され得る、受信するための手段を含む。本機器は、示されたＯＤＲ ＲＡＰフレームで開始するメディアデータのストリームを検索する要求をサーバ機器に送るための手段をさらに含む。
別の例によれば、コンピュータ可読記憶媒体について本明細書で説明する。本記憶媒体は、実行されたとき、クライアントコンピューティング機器のプロセッサに、クライアント機器においてサーバ機器から、メディアセグメンテーションのオープン復号リフレッシュ（ＯＤＲ）ランダムアクセスポイント（ＲＡＰ）フレームの指示を受信することであって、復号順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの少なくとも１つのフレームが正しく復号され得ず、表示順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの各フレームが、表示順序でＯＤＲ ＲＡＰより前のフレームのコンテンツに依拠することなしに、正しく復号され得る、受信することを行わせる命令を含む。本命令は、クライアントコンピューティング機器に、クライアント機器が、示されたＯＤＲ ＲＡＰフレームを含んでいるメディアセグメンテーションで開始するメディアデータのストリームを検索する要求をサーバ機器に送ることをさらに行わせる。
別の例によれば、１つ以上のプロセッサを含む機器について本明細書で説明する。１つ以上のプロセッサは、メディアセグメンテーションのオープン復号リフレッシュ（ＯＤＲ）ランダムアクセスポイント（ＲＡＰ）フレームの指示を受信することであって、復号順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの少なくとも１つのフレームが正しく復号され得ず、表示順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの各フレームが、表示順序でＯＤＲ ＲＡＰより前のフレームのコンテンツに依拠することなしに、正しく復号され得る、受信することを行うように構成される。１つ以上のプロセッサは、示されたＯＤＲ ＲＡＰフレームを含んでいるメディアセグメンテーションで開始するメディアデータのストリームを検索する要求をサーバ機器に送ることを行うようにさらに構成される。
別の例によれば、方法について本明細書で説明する。本方法は、メディアセグメンテーションのオープン復号リフレッシュ（ＯＤＲ）ランダムアクセスポイント（ＲＡＰ）フレームを備える符号化ビデオフレームのシーケンスを受信することであって、復号順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの少なくとも１つのフレームが正しく復号され得ず、表示順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの各フレームが、表示順序でＯＤＲ ＲＡＰより前のフレームのコンテンツに依拠することなしに、正しく復号され得る、受信することを含む。本方法は、符号化ビデオフレームのシーケンス内のＯＤＲ ＲＡＰのロケーションの指示を生成することをさらに含む。本方法は、指示を出力することをさらに含む。
別の例によれば、機器について本明細書で説明する。本機器は、メディアセグメンテーションのオープン復号リフレッシュ（ＯＤＲ）ランダムアクセスポイント（ＲＡＰ）フレームを備える符号化ビデオフレームのシーケンスを受信するための手段であって、復号順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの少なくとも１つのフレームが正しく復号され得ず、表示順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの各フレームが、表示順序でＯＤＲ ＲＡＰより前のフレームのコンテンツに依拠することなしに、正しく復号され得る、受信するための手段を含む。本機器は、符号化ビデオフレームのシーケンス内のＯＤＲ ＲＡＰのロケーションの指示を生成するための手段をさらに含む。本機器は、指示を出力するための手段をさらに含む。
別の例によれば、コンピュータ可読記憶媒体について本明細書で説明する。本コンピュータ可読記憶媒体は、実行されたとき、発信源機器の１つ以上のプロセッサに、メディアセグメンテーションのオープン復号リフレッシュ（ＯＤＲ）ランダムアクセスポイント（ＲＡＰ）フレームを備える符号化ビデオフレームのシーケンスを受信することであって、復号順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの少なくとも１つのフレームが正しく復号され得ず、表示順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの各フレームが、表示順序でＯＤＲ ＲＡＰより前のフレームのコンテンツに依拠することなしに、正しく復号され得る、受信することを行わせる命令を含む。本命令は、発信源機器に、符号化ビデオフレームのシーケンス内のＯＤＲ ＲＡＰのロケーションの指示を生成することをさらに行わせる。本命令は、発信源機器に、指示を出力することをさらに行わせる。
別の例によれば、１つ以上のプロセッサを含む機器について本明細書で説明する。１つ以上のプロセッサは、メディアセグメンテーションのオープン復号リフレッシュ（ＯＤＲ）ランダムアクセスポイント（ＲＡＰ）フレームを備える符号化ビデオフレームのシーケンスを受信することであって、復号順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの少なくとも１つのフレームが正しく復号され得ず、表示順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの各フレームが、表示順序でＯＤＲ ＲＡＰより前のフレームのコンテンツに依拠することなしに、正しく復号され得る、受信することを行うように構成される。１つ以上のプロセッサは、符号化ビデオフレームのシーケンス内のＯＤＲ ＲＡＰのロケーションの指示を生成することを行うようにさらに構成される。１つ以上のプロセッサは、指示を出力することを行うようにさらに構成される。
別の例によれば、方法について本明細書で説明する。本方法は、クライアント機器においてサーバ機器から、第１の再生速度で表示されるように構成されたビデオプレゼンテーションを表すメディアセグメンテーション内の少なくとも１つのバイト範囲の指示を受信することであって、少なくとも１つのイントラ符号化フレーム（Ｉフレーム）が少なくとも１つのバイト範囲内で生じる、受信することを含む。本方法は、クライアント機器が、少なくとも１つのバイト範囲内のメディアデータを検索する要求をサーバ機器に送ることをさらに含む。本方法は、第１の再生速度よりも速い第２の再生速度で少なくとも１つのＩフレームを含むビデオ表現の高速バージョンを提示するために、少なくとも１つのバイト範囲内の検索されたメディアデータを使用することをさらに含む。
別の例によれば、機器について本明細書で説明する。本機器は、クライアント機器においてサーバ機器から、第１の再生速度で表示されるように構成されたビデオプレゼンテーションを表すメディアセグメンテーション内の少なくとも１つのバイト範囲の指示を受信するための手段であって、少なくとも１つのイントラ符号化フレーム（Ｉフレーム）が少なくとも１つのバイト範囲内で生じる、受信するための手段を含む。本機器は、クライアント機器が、少なくとも１つのバイト範囲内のメディアデータを検索する要求をサーバ機器に送るための手段をさらに含む。本機器は、第１の再生速度よりも速い第２の再生速度で少なくとも１つのＩフレームを含むビデオ表現の高速バージョンを提示するために、少なくとも１つのバイト範囲内の検索されたメディアデータを使用するための手段をさらに含む。
別の例によれば、コンピュータ可読記憶媒体について本明細書で説明する。本コンピュータ可読記憶媒体は、コンピューティング機器に、クライアント機器においてサーバ機器から、第１の再生速度で表示されるように構成されたビデオプレゼンテーションを表すメディアセグメンテーション内の少なくとも１つのバイト範囲の指示を受信することであって、少なくとも１つのイントラ符号化フレーム（Ｉフレーム）が少なくとも１つのバイト範囲内で生じる、受信することを行わせるように構成された命令を記憶する。本命令は、コンピューティング機器に、クライアント機器が、少なくとも１つのバイト範囲内のメディアデータを検索する要求をサーバ機器に送ることを行わせるようにさらに構成される。本命令は、コンピューティング機器に、第１の再生速度よりも速い第２の再生速度で少なくとも１つのＩフレームを含むビデオ表現の高速バージョンを提示するために、少なくとも１つのバイト範囲内の検索されたメディアデータを使用することを行わせるようにさらに構成される。
別の例によれば、機器について本明細書で説明する。本機器は少なくとも１つのプロセッサを含む。少なくとも１つのプロセッサは、第１の再生速度で表示されるように構成されたビデオプレゼンテーションを表すメディアセグメンテーション内の少なくとも１つのバイト範囲の指示を受信することであって、少なくとも１つのイントラ符号化フレーム（Ｉフレーム）が少なくとも１つのバイト範囲内で生じる、受信することを行うように構成される。少なくとも１つのプロセッサは、少なくとも１つのバイト範囲内のメディアデータを検索する要求をサーバ機器に送ることを行うようにさらに構成される。少なくとも１つのプロセッサは、第１の再生速度よりも高い第２の再生速度で少なくとも１つのＩフレームを含むビデオ表現の高速バージョンを提示するために少なくとも１つのバイト範囲内の検索されたメディアデータを使用することを行うようにさらに構成される。
別の例によれば、方法について本明細書で説明する。本方法は、少なくとも１つのインター符号化フレーム（Ｉフレーム）を備える符号化ビデオフレームのシーケンスを受信することを含む。本方法は、符号化ビデオフレームのシーケンス内のバイト範囲の指示を生成することであって、少なくとも１つのＩフレームが少なくとも１つのバイト範囲内で生じる、生成することをさらに含む。本方法は、符号化ビデオフレームのシーケンス内のバイト範囲の指示を出力することをさらに含む。
別の例によれば、機器について本明細書で説明する。本機器は、少なくとも１つのインター符号化フレーム（Ｉフレーム）を備える符号化ビデオフレームのシーケンスを受信するための手段を含む。本機器は、符号化ビデオフレームのシーケンス内のバイト範囲の指示を生成するための手段であって、少なくとも１つのＩフレームが少なくとも１つのバイト範囲内で生じる、生成するための手段をさらに含む。本機器は、符号化ビデオフレームのシーケンス内のバイト範囲の指示を出力するための手段をさらに含む。
別の例によれば、コンピュータ可読記憶媒体について本明細書で説明する。本コンピュータ可読記憶媒体は、コンピューティング機器に、少なくとも１つのＩフレームを備える符号化ビデオフレームのシーケンスを受信することを行わせるように構成された命令を記憶する。本命令は、コンピューティング機器に、バイト範囲の指示を生成することであって、少なくとも１つのＩフレームが少なくとも１つのバイト範囲内で生じる、生成することをさらに行わせる。本命令は、コンピューティング機器に、符号化ビデオフレームのシーケンス内のバイト範囲の指示を出力することをさらに行わせる。
別の例によれば、機器について本明細書で説明する。本機器は１つ以上のプロセッサを含む。１つ以上のプロセッサは、少なくとも１つのＩフレームを備える符号化ビデオフレームのシーケンスを受信することを行うように構成される。１つ以上のプロセッサは、符号化ビデオフレームのシーケンス内のバイト範囲の指示を生成するように構成され、少なくとも１つのＩフレームが少なくとも１つのバイト範囲内で生じる。１つ以上のプロセッサは、符号化ビデオフレームのシーケンス内のバイト範囲の指示を出力することを行うようにさらに構成される。
１つ以上の例の詳細を添付の図面及び以下の説明に記載する。他の特徴、目的、及び利点は、説明及び図面、並びに特許請求の範囲から明らかになるであろう。
オーディオ／ビデオ（Ａ／Ｖ）発信源機器がオーディオ及びビデオデータをＡ／Ｖ宛先機器にトランスポートする例示的なシステムを示すブロック図。 本開示の技法に一致するビデオフラグメントの一例を示す概念図。 本開示の技法に一致するビデオフラグメントの一例を示す概念図。 本開示の技法に一致するセグメンテーションファイルの一例を示すブロック図。 本開示の技法に一致するムービープレゼンテーションの一例を示すブロック図。 本開示の技法に一致するセグメントインデックスボックスの一例を示すブロック図。 本開示の技法に一致する、オープン復号リフレッシュ（ＯＤＲ）ランダムアクセスポイント（ＲＡＰ）の指示を受信するようにクライアント機器を動作させる方法の一例を示すフローチャート。 本開示の技法に一致する、ＯＤＲ ＲＡＰの指示を与えるように発信源機器を動作させる方法の一例を示すフローチャート。 本開示の技法に一致する、イントラ符号化フレーム（Ｉフレーム）のバイト範囲の指示を受信するようにクライアント機器を動作させる方法の一例を示すフローチャート。 本開示の技法に一致する、イントラ符号化フレーム（Ｉフレーム）のバイト範囲の指示を与えるように発信源機器を動作させる方法の一例を示すフローチャート図。 本開示の技法に一致する、それぞれのＨＴＴＰクライアント及びサーバ機器によって実行され得るステップの一例を示すフローチャート。 本開示の技法に一致する、それぞれのＨＴＴＰクライアント及びサーバ機器によって実行され得るステップの一例を示すフローチャート図。
本開示の技法は、概して、例えば、ハイパーテキスト転送プロトコル（ＨＴＴＰ）ストリーミングなどのストリーミングプロトコルを使用したビデオデータのトランスポートをサポートすることを対象とする。概して、本開示では、ＨＴＴＰへの言及は、ＨＴＴＰストリーミングへの言及を含み得る。
本開示では、ビデオ表現のランダムアクセスポイント（ＲＡＰ）の２つの特定のタイプに言及する。特に、本開示では、瞬時復号リフレッシュ（ＩＤＲ）ＲＡＰとオープン復号リフレッシュ（ＯＤＲ）ＲＡＰとについて説明する。ＩＤＲアクセスポイントは、クローズドＧＯＰの単独で復号可能なイントラフレームである。クローズドＧＯＰは、正しく復号可能であるべき、復号順序又はプレゼンテーション順序のいずれかでＧＯＰより前のフレームに依存するフレームを含まないビデオ表現のフレームのグループ化である。
オープンＧＯＰは、表示（出力）順序でＧＯＰの最初の単独で復号可能なフレーム（Ｉフレーム）に先行するが復号順序でＩフレームに続くピクチャが、正しく復号可能でないことがあるＧＯＰである。例えば、オープンＧＯＰは、オープンＧＯＰの外部の少なくとも１つのフレームのコンテンツに少なくとも部分的に依存する１つ以上のフレームを含み得る。オープンＧＯＰの幾つかの例では、オープンＧＯＰのＩフレームは、ビデオ表現の再生の開始のためのランダムアクセスポイントとして使用され得る。例えば、表示順序で最初のＩフレームに続くすべてのフレームが正しく復号され得る場合、ＩフレームはＲＡＰとして使用され得る。そのようなＲＡＰは、ＯＤＲ ＲＡＰと呼ばれることがある。
ビデオ表現のフレームは、１つ以上のＧＯＰ中に配置され得る。１つ以上のＧＯＰは、１つ以上のビデオフラグメント中に配置され得る。１つ以上のフラグメントは、１つ以上のセグメント中に配置され得る。幾つかの例では、複数のセグメントがビデオ表現を形成し得る。
ＨＴＴＰストリーミングサービスなどのストリーミングサービスは、クライアント機器が、サーバ機器から１つ以上のＧＯＰ、フラグメント、セグメント、又はビデオ表現全体を検索されたＨＴＴＰ要求を行うことを可能にし得る。サーバ機器は、メディアコンテンツの複数の表現を含み得る。一例では、そのような要求は、ＨＴＴＰ ＧＥＴ要求を含み得る。ＨＴＴＰ ＧＥＴ要求は、ビデオ表現（例えば、ＧＯＰ、フラグメント、セグメント又はビデオ表現レベルメディアファイル）の１つ以上のメディアセグメンテーションのユニフォームリソースロケータ(uniform resource locator)（ＵＲＬ）を指定することによって、サーバ機器に記憶されたコンテンツへのクライアント機器アクセスを与え得る。幾つかの例では、ＨＴＴＰ ＧＥＴ要求は、メディアファイル全体を要求する代わりに、メディアファイル内のバイト範囲を指定し得る。そのようなＨＴＴＰ ＧＥＴ要求は、部分ＧＥＴ要求と呼ばれることがある。本明細書で説明するように、「メディアセグメンテーション」という句は、フラグメントであれ、セグメントであれ、ビデオ表現レベルメディアセグメンテーションであれ、ＨＴＴＰ ＧＥＴ要求又は部分ＧＥＴ要求などのストリーミングプロトコル要求に従って検索可能であるファイルを指す。
幾つかの例では、本明細書で説明するメディアコンテンツの様々な形態は、１つ以上のメディアセグメンテーションの形態でサーバに記憶され得る。幾つかの例では、サーバ機器が、ＨＴＴＰストリーミングサービスを可能にするための情報を信号伝達することを行うように構成され得る。本開示の一態様によれば、サーバ機器は、ビデオ表現のメディアセグメンテーション（例えば、フラグメント、セグメント、表現固有のメディアセグメンテーション）のためのオープン復号リフレッシュ（ＯＤＲ）ランダムアクセスポイント（ＲＡＰ）を信号伝達し得る。本開示の技法によれば、クライアント機器が、ＯＤＲ ＲＡＰの信号伝達に基づいてメディアデータのストリーミングについての要求をサーバ機器に通信し得る。ビデオ表現のためのＯＤＲ ＲＡＰを信号伝達することによって、クライアント機器は、ビデオ表現のストリーミング、復号及び／又は再生の開始のためにビデオ表現のより多くの時間位置の中から選択し得る。
幾つかの例では、発信源機器は、フラグメント又はセグメント中にＩＤＲが含まれていない場合、メディアセグメンテーションがＯＤＲ ＲＡＰを含んでいるか否かを信号伝達し得る。従って、所望の時間ロケーションの近くでＩＤＲ ＲＡＰを含むメディアセグメンテーションが利用可能でない場合、ビデオ表現の再生は、ＯＤＲ ＲＡＰを含むメディアセグメンテーション（例えば、ビデオ表現のフラグメント又はセグメント、或いはビデオ表現全体）に関連する時間ロケーションにおいて開始し得る。
特に、発信源機器は、メディアセグメンテーションのＯＤＲ ＲＡＰに対するバイトオフセットを信号伝達し得る。メディアセグメンテーションは、ビデオフラグメントに固有のユニフォームリソースロケータ（ＵＲＬ）又はユニフォームリ発信源ネーム（ＵＲＮ）を使用して、単独でアドレス指定可能であり得る。一例では、ビデオフラグメント中のＯＤＲ ＲＡＰに対するバイトオフセットを信号伝達することによって、クライアント機器は、ＯＤＲ ＲＡＰにおいて開始しメディアセグメンテーションの終端において終了するバイト範囲を備えるＧＥＴ要求を構築し得る。
本開示の別の態様によれば、サーバ機器は、ビデオ表現の少なくとも１つのＩフレームについてのバイト範囲を信号伝達し得る。クライアント機器は、信号伝達されたバイト範囲に基づいて少なくとも１つのＩフレームを検索する要求をサーバ機器に通信し、その少なくとも１つのＩフレームを含むビデオコンテンツの高速バージョンを与えるために、検索されたＩフレームを使用し得る。ビデオコンテンツの高速バージョンは、早送り又は早戻しなど、ビデオプレゼンテーションのトリックモードをサポートし得る。ビデオプレゼンテーションの少なくとも１つのＩフレームについてのバイト範囲を直接信号伝達することによって、Ｉフレームが属する全ビデオ表現を要求することなしに、又は高速再生のために特に作成されたビデオ表現の代替バージョンを要求することなしに、高速バージョンが与えられ得る。さらに、これらの技法は、ストリーミングされ、復号され、及び／又は再生され得るデータの量を最小限に抑えながら、ビデオ表現の高速バージョンを与えることを可能にする。
本開示のこの態様によれば、サーバ機器は、メディアコンテンツを表す１つ以上のメディアセグメンテーション内の１つ以上のバイト範囲の指示を信号伝達し得る。少なくとも１つのイントラ符号化フレーム（Ｉフレーム）は、１つ以上の信号伝達されたバイト範囲の各々の内で生じ得る。クライアント機器は、１つ以上のバイト範囲の信号伝達された指示に基づいて、バイト範囲内のメディアデータ検索する要求（例えば、ＨＴＴＰ ＧＥＴ要求又は部分ＧＥＴ要求）を提示し得る。クライアント機器は、比較的高速でビデオプレゼンテーションを提示するために、少なくとも１つのイントラ符号化フレームだけ時間的に分離された１つ以上の信号伝達されたバイト範囲のうちの少なくとも１つの内で生じる２つ以上のＩフレームを連続的に提示し得る。そのような表現は、メディアコンテンツの高速バージョンと見なされ得る。
3rd Generation Partnership Project(3GPP)は、International Telecommunication Union(ITU)のInternational Mobile Telecommunications-2000プロジェクトの範囲内で広域的に適用可能な第３世代（３Ｇ）モバイル電話システム仕様を製作する電気通信団体のグループ間のコラボレーションである。３ＧＰＰ仕様は、evolved Global System for Mobile Communications（ＧＳＭ（登録商標））仕様に基づく。３ＧＰＰ規格化は、無線、コアネットワーク及びサービスアーキテクチャを包含する。幾つかの例では、本開示の技法について、３ＧＰＰプロトコル仕様に一致する例及び用語を使用して本明細書で説明する。これらの例及び用語は、例示のために与えられたものにすぎず、ビデオデータのストリーミングのための他のプロトコル仕様も企図され、本開示に一致する。
ＨＴＴＰストリーミングによる幾つかの例では、セグメンテーションファイルは、特定のプログラム（例えば、ムービー、テレビ番組、又は他のビデオプログラム）にそれぞれ対応する幾つかの異なる表現中に構成され得る。３ＧＰＰファイルは、それぞれプログラムのこれらの異なる表現及び／或いはプログラムのプレゼンテーションのセグメント又はフラグメントに対応し得る。
ビデオ表現（例えば、３ＧＰＰファイル）は、幾つかのムービーフラグメントで構成され得る。ムービーフラグメントは、それぞれビデオ表現の幾つかのフレーム、又はピクチャを含み得る。３ＧＰＰビデオ表現のフラグメントは、３ＧＰＰファイルのユニフォームリソースロケータ（ＵＲＬ）又はユニフォームリ発信源ネーム（ＵＲＮ）を参照し得るＨＴＴＰ ＧＥＴ要求又は部分ＧＥＴ要求を使用して、個々に検索可能であり得る。
ＨＴＴＰクライアントは、再生中に、例えば、ネットワーク条件が変わったとき、又はユーザ制御入力が検出されたとき、表現を変更し得る。例えば、大量の帯域幅が利用可能なときは、クライアントは比較的高い品質のプレゼンテーションの３ＧＰＰファイルを検索し得、より少ない量の帯域幅が利用可能なときは、クライアントは比較的低い品質のプレゼンテーションの３ＧＰＰファイルを検索し得る。同様に、ユーザが、ビデオ品質の所望の変更を示し得る。また、ユーザは、クライアントにビデオ表現の再生のために、休止するか、停止するか、シーク（seek）（例えば、早送り、巻戻し）するか、又は走査する（所望の開始点を示す）ように指示し得る。
ＨＴＴＰクライアントが、ストリーミングのために異なる表現又は表現の部分を選択することを可能にするために、ＨＴＴＰサーバが、１つ以上のムービープレゼンテーションのために利用可能な情報のサブセットを提供することは望ましいことがある。そのような情報はヘッダ情報と呼ばれることがある。ヘッダ情報は、プログラムに固有であり、プログラムの表現又は表現の一部分、或いは表現のムービーフラグメント又はセグメントに固有であり得る。
３ＧＰＰによる一例では、ヘッダ情報は、メディアプレゼンテーション記述（ＭＰＤ）ファイル中に含まれていることがある。ＭＰＤファイルは、例えば、ビットレート、フレームレート、解像度、インターレース又はプログレッシブ走査タイプ、符号化タイプ（例えば、ＭＰＥＧ−１、ＭＰＥＧ−２、Ｈ．２６３、ＭＰＥＧ−４／Ｈ．２６４又は他のビデオコーデック）、アクセスポイント、或いは他の特性など、ビデオデータの幾つかの表現の特性要素を信号伝達し得る。
ムービーフラグメントは、幾つかのピクチャグループ（ＧＯＰ）を含み得る。ＧＯＰは、復号及び／又は再生の開始のためのランダムアクセスポイント（ＲＡＰ）を含むことも、含まないこともある。
本開示は、ＨＴＴＰストリーミングアプリケーションのコンテキストにおけるＯＤＲアクセスポイントの信号伝達のための技法について説明する。本開示の技法は、１つ以上の利点を提供し得る。例えば、ＩＤＲアクセスポイントに加えてＯＤＲアクセスポイントを信号伝達することは、ＩＤＲアクセスポイントの信号伝達を可能にする既知の技法よりも、ＨＴＴＰストリーミングによるストリームを開始するための制御のより微細な精度（granularity）を与えることによって、走査又はシーク機能の改善を可能にし得る。本開示の技法はまた、より多くのアクセスポイントが与えられ、それによってＨＴＴＰストリーミングのための走査及び／又はシーク機能を改善し得るので、復号のためのハイレベルのフレーム間コンテンツ依存を含むより複雑なビデオプログラムをストリーミングするとき、利点を提供し得る。本開示の技法は、セグメンテーションファイルのヘッダ情報において１つ以上のＯＤＲアクセスポイントを信号伝達することによって、クライアント機器が、ＯＤＲアクセスポイント自体において開始するメディアデータのストリーム、又はＯＤＲアクセスポイントを含むオープンＧＯＰを要求し、それによって、セグメンテーションファイルによって表されるビデオのストリーミング／復号／再生のための開始点の選択におけるより微細なグラニュラリティを与え得るので、さらなる利点を提供し得る。これらの技法はまた、ビデオ表現の再生のためにストリーミングされるべきデータの量を低減することによって、従来の技法よりも有益であり得る。
幾つかの例では、本開示の技法は、セグメンテーションファイルのヘッダ情報におけるＯＤＲアクセスポイント及び／又は他の情報の信号伝達を可能にする。一例では、ＯＤＲアクセスポイントは、ムービー表現又はセグメントのセグメントインデックスボックス（ＳＩＤＸ）において信号伝達され得る。セグメンテーションファイルは、ＩＳＯベースメディアファイルフォーマット、或いは、例えば、スケーラブルビデオ符号化（ＳＶＣ）、アドバンストビデオ符号化（ＡＶＣ）、及び／又はマルチビュービデオ符号化（ＭＶＣ）などのＩＳＯベースメディアファイルフォーマットの拡張を含む他のタイプのセグメンテーションファイルに従ってフォーマットされ得る。本開示の技法は、走査及び／又はシーク機能に関係する他の情報の信号伝達をさらに可能にし得、それについては、以下でさらに詳細に説明する。
本開示の技法は、走査機能のために、１つ以上のイントラ符号化フレーム（Ｉフレーム）のバイト範囲についてのＨＴＴＰサーバ機器による信号伝達をさらに可能にする。例えば、宛先機器は、ビデオのプレゼンテーションのためのトリックモードとしても知られる、早送り又は早戻しのためにビデオ表現の高速バージョンを表示し得る。これらの技法によれば、クライアント機器は、Ｉフレームバイト範囲の信号伝達に基づいて、ビデオ表現の高速バージョンを提示するために必要でない他のフレームから独立した、ビデオ表現の信号伝達されたＩフレームのみを要求及び／又は復号し得る。例えば、クライアント機器は、信号伝達されたバイト範囲内で生じる１つ以上のＩフレームを（例えば、１つ以上のＨＴＴＰ部分ＧＥＴ要求によって）特に要求し得る。クライアント機器は、比較的高速でビデオコンテンツを提示するために、検索されたメディアデータの２つ以上のＩフレームを連続的に提示し得る。２つ以上のＩフレームは、少なくとも１つのインター符号化フレーム（例えば、Ｂフレーム又はＰフレーム）だけ時間的に分離され得る。信号伝達されたＩフレームのみを検索し、復号し、表示することによって、クライアント機器は、早送り又は早戻し動作のためにビデオ表現の高速バージョンをユーザに与え得る。幾つかの例では、信号伝達されたＩフレームは、ＩＤＲアクセスポイント及び／又はＯＤＲアクセスポイントを含み得る。
ビデオ表現のＩフレームのためのバイト範囲は、様々な符号化ユニット（例えば、メディアセグメンテーション）のヘッダ情報において信号伝達され得る。例えば、発信源機器は、（例えば、ＭＰＤファイル内の）ビデオレベル、表現レベル、セグメントレベル、フラグメントレベル、又はメディアプレゼンテーションのヘッダ情報の他のレベルにおいてＩフレームのバイト範囲を信号伝達し得る。これらの技法は、１つ以上の利点を提供し得る。例えば、宛先機器は、ビデオ表現の高速バージョンを作成、記憶、及び／又は送信することなしに、ＨＴＴＰストリーミングなどのストリーミングプロトコルのコンテキストにおいてビデオ表現の高速再生を実行し得る。さらに、クライアント機器が、信号伝達されたＩフレームに基づいて早送り再生及び早戻し再生のいずれか又は両方をユーザに提示し得るので、これらの技法は有利であり得る。
図１は、オーディオ／ビデオ（Ａ／Ｖ）発信源機器２０がオーディオ及びビデオデータをＡ／Ｖ宛先機器４０にトランスポートする例示的なシステム１０を示すブロック図である。Ａ／Ｖ発信源機器２０は「発信源ビデオ機器」と呼ばれることもある。図１のシステム１０は、ビデオ通信会議システム、サーバ／クライアントシステム、放送事業者／受信機システム、又はＡ／Ｖ発信源機器２０などの発信源機器からＡ／Ｖ宛先機器４０などの宛先機器にビデオデータが送られる任意の他のシステムに対応し得る。Ａ／Ｖ宛先機器４０は「宛先ビデオ機器」又は「クライアント機器」と呼ばれることもある。幾つかの例では、Ａ／Ｖ発信源機器２０及びＡ／Ｖ宛先機器４０は双方向情報交換を実行し得る。即ち、Ａ／Ｖ発信源機器２０及びＡ／Ｖ宛先機器４０は、オーディオ及びビデオデータの符号化と復号（及び、送信と受信）の両方が可能であり得る。幾つかの例では、オーディオエンコーダ２６は、ボコーダとも呼ばれるボイスエンコーダを備え得る。
Ａ／Ｖ発信源機器２０は、図１の例では、オーディオ発信源２２とビデオ発信源２４とを備える。オーディオ発信源２２は、例えば、オーディオエンコーダ２６によって符号化されるべき、収録されたオーディオデータを表す電気信号を生成するマイクロフォンを備え得る。代替的に、オーディオ発信源２２は、前に記録されたオーディオデータを記憶する記憶媒体、コンピュータシンセサイザなどのオーディオデータ生成器、又はオーディオデータの任意の他の発信源を備え得る。ビデオ発信源２４は、ビデオエンコーダ２８によって符号化されるべきビデオデータを生成するビデオカメラ、前に記録されたビデオデータで符号化された記憶媒体、ビデオデータ生成ユニット、又はビデオデータの任意の他の発信源を備え得る。
未加工オーディオ及びビデオデータは、アナログ又はデジタルデータを備え得る。アナログデータは、オーディオエンコーダ２６及び／又はビデオエンコーダ２８によって符号化される前にデジタル化され得る。オーディオ発信源２２は、通話参加者が話している間、通話参加者からオーディオデータを取得し得、同時に、ビデオ発信源２４は、通話参加者のビデオデータを取得し得る。他の例では、オーディオ発信源２２は、記憶されたオーディオデータを備えるコンピュータ可読記憶媒体を備え得、ビデオ発信源２４は、記憶されたビデオデータを備えるコンピュータ可読記憶媒体を備え得る。このようにして、本開示で説明する技法は、ライブ、ストリーミング、リアルタイムオーディオ及びビデオデータ、又はアーカイブされた、予め記録されたオーディオ及びビデオデータに適用され得る。
ビデオフレームに対応するオーディオフレームは、概して、ビデオフレーム内に含まれている、ビデオ発信源２４によって撮影されたビデオデータと同時にオーディオ発信源２２によって収録されたオーディオデータを含んでいるオーディオフレームである。例えば、通話参加者が概して話すことによってオーディオデータを生成する間、オーディオ発信源２２はオーディオデータを収録し、同時に、即ちオーディオ発信源２２がオーディオデータを収録している間、ビデオ発信源２４は通話参加者のビデオデータを撮影する。従って、オーディオフレームは、１つ以上の特定のビデオフレームに時間的に対応し得る。従って、ビデオフレームに対応するオーディオフレームは、概して、オーディオデータとビデオデータとが同時にキャプチャされる状況、及びオーディオフレームとビデオフレームとが、それぞれ、同時に取得されたオーディオデータとビデオデータとを備える状況に対応する。
幾つかの例では、オーディオエンコーダ２６は、符号化オーディオフレームのオーディオデータが記録された時間を表す、各符号化オーディオフレームにおけるタイムスタンプを符号化し得、同様に、ビデオエンコーダ２８は、符号化ビデオフレームのビデオデータが記録された時間を表す、各符号化ビデオフレームにおけるタイムスタンプを符号化し得る。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを備えるオーディオフレームと同じタイムスタンプを備えるビデオフレームとを備え得る。Ａ／Ｖ発信源機器２０は、オーディオエンコーダ２６及び／又はビデオエンコーダ２８がそこからタイムスタンプを生成し得るか、或いはオーディオ発信源２２及びビデオ発信源２４がオーディオ及びビデオデータをそれぞれタイムスタンプに関連付けるために使用し得る、内部クロックを含み得る。
幾つかの例では、オーディオ発信源２２は、オーディオデータが記録された時間に対応するデータをオーディオエンコーダ２６に送り得、ビデオ発信源２４は、ビデオデータが記録された時間に対応するデータをビデオエンコーダ２８に送り得る。幾つかの例では、オーディオエンコーダ２６は、必ずしもオーディオデータが記録された絶対時刻を示すことなしに、符号化オーディオデータの相対的時間順序を示すために、符号化オーディオデータ中のシーケンス識別子を符号化し得、同様に、ビデオエンコーダ２８も、符号化ビデオデータの相対的時間順序を示すためにシーケンス識別子を使用し得る。同様に、幾つかの例では、シーケンス識別子は、タイムスタンプにマッピングされるか、又は場合によってはタイムスタンプと相関し得る。
本開示の技法は、概して、符号化マルチメディア（例えば、オーディオ及びビデオ）データのトランスポートと、トランスポートされたマルチメディアデータの受信並びに後続の解釈及び復号とを対象とする。本開示の技法は、例えば、スケーラブルビデオ符号化(scalable video coding)（ＳＶＣ）、アドバンストビデオ符号化(advanced video coding)（ＡＶＣ）、ＩＳＯベースメディアファイルフォーマット、又はマルチビュービデオ符号化(Multiview Video Coding)（ＭＶＣ）データ、又は他のビデオデータなど、様々な規格及び拡張のビデオデータの配信に適用され得る。幾つかの例では、ビデオ発信源２４はシーンの複数のビューをビデオエンコーダ２８に提供できる。幾つかの例では、ビデオデータの複数のビューは、立体視又は自動立体視３次元ディスプレイなど、３次元ディスプレイによって使用されるべき３次元ビデオデータを生成するために有用であり得る。
Ａ／Ｖ発信源機器２０は、Ａ／Ｖ宛先機器４０に「サービス」を提供し得る。サービスは、概して、ＭＶＣデータの利用可能なビューのサブセットに対応し得る。例えば、マルチビュービデオデータは、０から７まで順序付けられた８つのビューについて利用可能であり得る。あるサービスは２つビューを有するステレオビデオに対応し得るが、別のサービスは４つのビューに対応し得、さらに別のサービスは８つのビューすべてに対応し得る。概して、サービスは、利用可能なビューの任意の組合せ（即ち、任意のサブセット）に対応する。サービスはまた、利用可能なビュー並びにオーディオデータの組合せに対応し得る。
各個のデータストリームは（オーディオかビデオかにかかわらず）エレメンタリストリームと呼ばれる。エレメンタリストリームは、デジタル的に符号化された（場合によっては圧縮された）プログラムの単一の構成要素である。例えば、プログラムの符号化ビデオ又はオーディオ部分はエレメンタリストリームであり得る。エレメンタリストリームは、それがプログラムストリーム又はトランスポートストリームに多重化される前に、パケット化エレメンタリストリーム（ＰＥＳ）に変換され得る。同じプログラム内では、１つのエレメンタリストリームに属するＰＥＳパケットを他のものから区別するためにストリームＩＤが使用される。エレメンタリストリームの基本データ単位はパケット化エレメンタリストリーム（ＰＥＳ）パケットである。従って、ＭＶＣビデオデータの各ビューはそれぞれのエレメンタリストリームに対応する。同様に、オーディオデータは１つ以上のそれぞれのエレメンタリストリームに対応する。
図１の例では、カプセル化ユニット３０は、ビデオエンコーダ２８からビデオデータを備えるエレメンタリストリームを受信し、オーディオエンコーダ２６からオーディオデータを備えるエレメンタリストリームを受信する。幾つかの例では、ビデオエンコーダ２８及びオーディオエンコーダ２６はそれぞれ、符号化データからＰＥＳパケットを形成するためのパケッタイザを含み得る。他の例では、ビデオエンコーダ２８及びオーディオエンコーダ２６はそれぞれ、符号化データからＰＥＳパケットを形成するためのパケッタイザ（packetizers）とインターフェースし得る。さらに他の例では、カプセル化ユニット３０は、符号化オーディオデータと符号化ビデオデータとからＰＥＳパケットを形成するためのパケッタイザを含み得る。
本開示で使用する「プログラム」は、オーディオデータとビデオデータとの組合せ、例えば、Ａ／Ｖ発信源機器２０のサービスによって配信されたオーディオエレメンタリストリームと利用可能なビューのサブセットとを備え得る。各ＰＥＳパケットは、ＰＥＳパケットが属するエレメンタリストリームを識別するstream_idを含む。カプセル化ユニット３０は、エレメンタリストリームを構成プログラムストリーム又はトランスポートストリームにアセンブルし得る。プログラムストリームとトランスポートストリームとは、異なるアプリケーションをターゲットにする２つの代替多重である。
概して、プログラムストリームは１つのプログラムのデータを含み、トランスポートストリームは１つ以上のプログラムのデータを含み得る。カプセル化ユニット３０は、提供されているサービス、ストリームがパスされる媒体、送られるべきプログラムの数、又は他の考慮事項に基づいて、プログラムストリーム又はトランスポートストリームのいずれか若しくは両方を符号化し得る。例えば、記憶媒体中のビデオデータが符号化されるべきであるときは、カプセル化ユニット３０はプログラムストリームを形成する可能性がより高くなり得、ビデオデータがネットワークを介してストリーミングされるか、ブロードキャストされるか、又はビデオテレフォニーの一部として送られるべきであるときは、カプセル化ユニット３０はトランスポートストリームを使用する可能性がより高くなり得る。
カプセル化ユニット３０は、オーディオエンコーダ２６とビデオエンコーダ２８とからプログラムのエレメンタリストリームのＰＥＳパケットを受信し、ＰＥＳパケットから対応するネットワークアブストラクションレイヤ（ＮＡＬ）ユニットを形成する。Ｈ．２６４／ＡＶＣ（Advanced Video Coding）の例では、符号化ビデオセグメントは、ビデオテレフォニー、ストレージ、ブロードキャスト、又はストリーミングなどのアプリケーションに対処する「ネットワークフレンドリー(network-friendly)」なビデオ表現を与えるＮＡＬユニットに編成される。ＮＡＬユニットは、ビデオ符号化レイヤ（ＶＣＬ）ＮＡＬユニットと非ＶＣＬ ＮＡＬユニットとにカテゴリー分類され得る。ＶＣＬユニットは、コア圧縮エンジンを含んでおり、ブロック、マクロブロック、及び／又はスライスレベルを備え得る。他のＮＡＬユニットは非ＶＣＬ ＮＡＬユニットである。
そのペイロード中にビデオデータを含むＮＡＬユニットは、様々な精度レベル（granularity levels）のビデオデータを備え得る。例えば、ＮＡＬユニットは、ビデオデータのブロック、マクロブロック、複数のマクロブロック、ビデオデータのスライス、又はビデオデータのフレーム全体を備え得る。
概して、アクセスユニットは、ビデオデータのフレームを表すための１つ以上のＮＡＬユニット及びそのフレームに対応するオーディオデータが利用可能なとき、そのようなオーディオデータを備え得る。アクセスユニットは、概して、１つの出力時間インスタンス(output time instance)にわたるすべてのＮＡＬユニット、例えば１つの時間インスタンスにわたるすべてのオーディオ及びビデオデータを含む。Ｈ．２６４／ＡＶＣに対応する例では、アクセスユニットは、１次符号化ピクチャとして提示され得る、１つの時間インスタンス中の符号化ピクチャを備え得る。従って、アクセスユニットは、共通の時間インスタンスのすべてのビデオフレーム、例えば、時間Ｘに対応するすべてのビュー構成要素を備え得る。
カプセル化ユニット３０は、ＮＡＬユニットを、ＩＳＯベースメディアファイルフォーマット又はそれの派生物（例えば、ＳＶＣ、ＡＶＣ、ＭＶＣ、又は３ＧＰＰ）に準拠するビデオファイルのトラックにアセンブルし、そのビデオファイルを出力インターフェース３２にパスし得る。出力インターフェース３２は、例えば、送信機、トランシーバ、例えば、オプティカルドライブ、磁気メディアドライブ（例えば、フロッピー（登録商標）ドライブ）など、コンピュータ可読媒体にデータを書き込むための機器、ユニバーサルシリアルバス（ＵＳＢ）ポート、ネットワークインターフェース、又は他の出力インターフェースを備え得る。出力インターフェース３２は、ＮＡＬユニット又はアクセスユニットを、例えば、送信信号又は搬送波などの一時媒体、或いは磁気メディア、光メディア、メモリ、又はフラッシュドライブなどのコンピュータ可読記憶媒体のコンピュータ可読媒体（例えば、チャネル３４）に出力する。
入力インターフェース３６はコンピュータ可読媒体（例えば、チャネル３４）からデータを検索する。入力インターフェース３６は、例えば、光学ドライブ、磁気媒体ドライブ、ＵＳＢポート、受信機、トランシーバ、又は他のコンピュータ可読媒体インターフェースを備え得る。入力インターフェース３６は、ＮＡＬユニット又はアクセスユニットをカプセル化解除ユニット(decapsulation unit)３８に与え得る。カプセル化解除ユニット３８は、トランスポートストリーム又はプログラムストリームを構成ＰＥＳストリームに多重分離し、符号化データを検索するためにＰＥＳストリームを逆パケット化し、例えば、ストリームのＰＥＳパケットヘッダによって示されるように、符号化データがオーディオ又はビデオストリームの一部であるかどうかに応じて、符号化データをオーディオデコーダ４６又はビデオデコーダ４８に送り得る。カプセル化解除ユニット３８は、初めに、受信したビデオファイル中に含まれるトラックのうちの１つを選択し、次いで、選択されたトラックのデータ及び選択されたトラックのエクトラクタ（extractors）によって参照される他のトラックのデータのみをビデオデコーダ４８にパスし、選択されたトラックのエクトラクタによって参照されない他のトラックのデータを廃棄し得る。オーディオデコーダ４６は、符号化オーディオデータを復号し、復号されたオーディオデータをオーディオ出力４２に送り、ビデオデコーダ４８は、符号化ビデオデータを復号し、ストリームの複数のビューを含み得る復号されたビデオデータをビデオ出力４４に送る。ビデオ出力４４は、シーンの複数のビュー、例えばシーンの各ビューを同時に提示する立体視又は自動立体視ディスプレイを使用するディスプレイを備え得る。
多くのビデオ符号化規格の場合と同様に、Ｈ．２６４／ＡＶＣは、誤りのないビットストリームのシンタックスと、セマンティクスと、復号プロセスとを定義し、そのいずれかは特定のプロファイル又はレベルに準拠する。Ｈ．２６４／ＡＶＣはエンコーダを指定しないが、エンコーダは、生成されたビットストリームがデコーダの規格に準拠することを保証することを課される。ビデオ符号化規格のコンテキストにおいて、「プロファイル」は、アルゴリズム、機能、又はそれらに適用するツール及び制約のサブセットに対応する。例えば、Ｈ．２６４規格によって定義される「プロファイル」は、Ｈ．２６４規格によって指定されたビットストリームシンタックス全体のサブセットである。「レベル」は、例えば、ピクチャの解像度、ビットレート、及びマクロブロック（ＭＢ）処理レートに関係するデコーダメモリ及び計算など、デコーダリ発信源消費の制限に対応する。
Ｈ．２６４規格は、例えば、与えられたプロファイルのシンタックスによって課される限界内で、復号されたピクチャの指定されたサイズなど、ビットストリーム中のシンタックス要素がとる値に応じて、エンコーダ及びデコーダのパフォーマンスの大きい変動を必要とする可能性が依然としてあることを認識している。Ｈ．２６４規格は、多くのアプリケーションにおいて、特定のプロファイル内でシンタックスのすべての仮定的使用を処理することが可能なデコーダを実装することが実際的でもなく、経済的でもないことをさらに認識している。従って、Ｈ．２６４規格は、ビットストリーム中のシンタックス要素の値に課せられた制約の指定されたセットとして「レベル」を定義している。これらの制約は、値に関する単純な限界であり得る。代替的に、これらの制約は、値の演算の組合せ（例えば、ピクチャの幅×ピクチャ高さ×毎秒復号されるピクチャの数）に関する制約の形態をとり得る。Ｈ．２６４規格は、個別の実装形態が、サポートされるプロファイルごとに異なるレベルをサポートし得ることをさらに規定している。
プロファイルに準拠するデコーダは、通常、プロファイル中で定義されたすべての機能をサポートする。例えば、符号化機能として、Ｂピクチャ符号化は、Ｈ．２６４／ＡＶＣのベースラインプロファイルではサポートされず、Ｈ．２６４／ＡＶＣの他のプロファイルではサポートされる。レベルに準拠するデコーダは、レベルにおいて定義された制限を超えてリ発信源を必要としない任意のビットストリームを復号することが可能である必要がある。プロファイル及びレベルの定義は、説明可能性のために役立ち得る。例えば、ビデオ送信中に、プロファイル定義とレベル定義のペアが全送信セッションについてネゴシエートされ、同意され得る。より詳細には、Ｈ．２６４／ＡＶＣでは、レベルは、例えば、処理する必要があるマクロブロックの数に関する制限と、復号されたピクチャバッファ（ＤＰＢ）サイズと、符号化ピクチャバッファ（ＣＰＢ）サイズと、垂直動きベクトル範囲と、２つの連続するＭＢごとの動きベクトルの最大数と、Ｂブロックが８×８ピクセル未満のサブマクロブロックパーティションを有することができるかどうかとを定義し得る。このようにして、デコーダは、デコーダがビットストリームを適切に復号することが可能であるかどうかを判断し得る。
パラメータセットは、概して、シーケンスパラメータセット（ＳＰＳ）中のシーケンスレイヤヘッダ情報とピクチャパラメータセット（ＰＰＳ）中のまれに変化するピクチャレイヤヘッダ情報とを含んでいる。パラメータセットがある場合、このまれに変化する情報をシーケンスごと又はピクチャごとに繰り返す必要はなく、従って符号化効率が改善され得る。さらに、パラメータセットの使用はヘッダ情報の帯域外送信を可能にし、誤り耐性を達成するための冗長送信の必要を回避し得る。帯域外送信では、他のＮＡＬユニットとは異なるチャネル上でパラメータセットＮＡＬユニットが送信され得る。
補足強調情報（ＳＥＩ：Supplemental Enhancement Information）メッセージは、ＶＣＬ ＮＡＬユニットから符号化ピクチャサンプルを復号するために必要でない情報を含んでいることがある。ＳＥＩメッセージは、上記で説明したように非ＶＣＬ ＮＡＬユニット中に含まれていることがある。幾つかの例では、ＳＥＩメッセージは、標準規格（例えば、Ｈ．２６４）の規範的部分であり、規格準拠デコーダの実装形態にとって必須でない。幾つかの例では、ＳＥＩメッセージは、復号、表示、誤り耐性、及び他の目的に関係するプロセスを支援し得る。幾つかの例では、ＳＥＩメッセージは、シーケンスレベル（例えば、複数の連続するピクチャ／フレーム）メッセージであり得る。他の例では、ＳＥＩメッセージは、ビデオデータの１つ以上のピクチャ／フレームに固有であり得る。
Ｈ．２６４／ＡＶＣ及び他のビデオ規格では、オープンＧＯＰの復号順序で第１のピクチャであるイントラ符号化ピクチャがあり得る。オープンＧＯＰは、出力順序で最初のイントラピクチャに先行するピクチャが正しく復号可能でないことがあるピクチャグループである。Ｈ．２６４／ＡＶＣデコーダは、オープンＧＯＰを開始するイントラピクチャを認識し、後続のピクチャを復号し始め得る。そのようなイントラピクチャは、回復点ＳＥＩに関連し得ることに留意されたい。幾つかの例では、本明細書では、オープンＧＯＰを開始するフレームをオープン復号リフレッシュ（ＯＤＲ）フレームと呼ぶ。クローズドＧＯＰは、すべてのピクチャが正しく復号され得るそのようなピクチャグループである。Ｈ．２６４／ＡＶＣでは、クローズドＧＯＰはＩＤＲアクセスユニットから開始し得る。
図２は、ピクチャグループ（ＧＯＰ）２１０を含むビデオフラグメント２０１の一例を示す概念図である。ＧＯＰは、ビデオシーケンスの（プレゼンテーション順序で）連続したフレームのグルーピングとして表され得る。ビデオフラグメントは、ＧＯＰ２１０と同様の任意の数のＧＯＰを含み得る。
図２の例は、ビデオフラグメント２０１の一部分を示す。ビデオフラグメントは複数のフレーム２２０Ａ〜２２０Ｋを含む。フラグメント２０１は、ＧＯＰ２１０などの１つ以上のピクチャグループ（ＧＯＰ）を備え得る。１つ以上のＧＯＰ２１０は、ビデオ表現のフレームのグルーピングとして表され得る。
図２１０に示すＧＯＰ２１０は、クローズドＧＯＰの例である。即ち、フレーム２２０Ｂ〜２２０Ｉの各々は、ＧＯＰ２１０の外部のフレーム、例えば、フレーム２２０Ａ、２２０Ｊ、及び２２０Ｋに関係なく復号され得る。図２に示すように、フレーム２２０Ａは（プレゼンテーション順序で）ＧＯＰ２１０のフレーム２２０Ｂ〜２２０Ｉに先行する。フレーム２２０Ｊ〜２２０Ｋは（プレゼンテーション順序で）ＧＯＰ２１０のフレーム２２０Ｂ〜２２０Ｉの後にある。フレーム２２０Ａ及び２２０Ｊ〜２２０Ｋは、フラグメント２０１の別のＧＯＰの部分であり得る。
フレーム２２０Ａ〜２２０Ｋのプレゼンテーション順序は、フレームの復号順序とは異なり得る。例えば、ＧＯＰは、Ｉフレーム、Ｂフレーム、又はＰフレームの任意の組合せを含み得る。イントラ符号化フレーム（Ｉフレーム）は、単独で復号可能であるそれらのフレームであり、これは、Ｉフレームを復号するために、デコーダが他のフレームのコンテンツに依拠する必要がないことを意味する。図２の例では、フレーム２２０Ａ及び２２０ＩはＩフレームの例である。Ｐフレームは、１つの方向における１つ以上のフレームに対するインター符号化であり得る。図２の例では、フレーム２２０Ｂ、２２０Ｃ、及び２２０ＥはＰフレームの例である。Ｂフレームは、２つの方向における１つ以上のフレームに対するインター符号化であり得る。図２の例では、フレーム２２０Ｄ、２２０Ｆ、２２０Ｇ、及び２２０Ｈは、Ｂフレームの例である。
上記で説明したように、図２の例によれば、フレーム２２０Ａ〜２２０Ｋの復号順序は、フレームのプレゼンテーション順序とは異なり得る。例えば、フレーム２２０Ｂ〜２２０Ｉを復号するとき、フレーム２２０Ｉ（Ｉフレーム）が最初に復号され得る。矢印２２２Ｅによって示されるように、フレーム２２０Ｅはフレーム２２０Ｉのコンテンツに依拠して、正しく復号される。従って、フレーム２２０Ｅは、フレーム２２０Ｉが復号された後に復号され得る。
矢印２２２Ｃによって示されるように、フレーム２２０Ｃは、フレーム２２０Ｅのコンテンツに依拠して、正しく復号され得る。矢印２２２Ｇによって示されるように、フレーム２２０Ｇは、フレーム２２０Ｅとフレーム２２０Ｉの両方のコンテンツに依拠して、正しく復号され得る。従って、幾つかの例では、フレーム２２０Ｃ及び２２０Ｇの復号は、フレーム２２０Ｉ及び２２０Ｅを復号した後に行われ得る。フレーム２２０Ｂ、２２０Ｄ、２２０Ｆ、及び２２０Ｈは、それぞれフレーム２２０Ｃ、２２０Ｅ、２２０Ｇ、及び２２０Ｉのうちの１つ以上のコンテンツに依拠しており、従って、フレーム２２０Ｃ、２２０Ｅ、２２０Ｇ、及び２２０Ｉが復号された後に復号され得る。
上記で説明したように、瞬時復号リフレッシュ（instantaneous decoding refresh）（ＩＤＲ）アクセスポイントは、クローズドＧＯＰ、例えば、図２中のＧＯＰ２１０のアクセスポイントとして表され得る。ＧＯＰの外部のフレームのコンテンツに依拠することなしに正しく復号可能であるフレームのみを含むＧＯＰは、クローズドＧＯＰ２１０と見なされ得る。
図２に、ＩＤＲアクセスポイントの２つの例を示す。図２の例に示すように、フレーム２２０Ａは、他のフレームのコンテンツに依拠せずに正しく復号可能であり、即ち、フレーム２２０Ａは、別のフレームに対する依拠を示す矢印を含まない。フレーム２２０Ａは、フレーム２２０Ａに先行するフレームがないので、それ自体がＧＯＰと見なされ得る。従って、フレーム２２０Ａは、（フレーム２２０Ａのみからなる）ＧＯＰの外部のフレームのコンテンツに依拠せずに正しく復号されるＧＯＰのアクセスポイントであるので、フレーム２２０ＡはＩＤＲアクセスポイントと見なされ得る。
また、フレーム２２０Ｉは、クローズドＧＯＰ２１０のＩＤＲアクセスポイントと見なされ得る。図２の例に示すように、フレーム２２０Ｉは、ＧＯＰ２１０の他のフレーム（例えば、フレーム２２０Ｂ〜２２０Ｈ）のコンテンツに依拠することなしに単独で復号可能であるＩフレームである。フレーム２２０Ｂ〜２２０Ｈの各々は、上記で説明したように、ＧＯＰ２１０内の他のフレームのコンテンツに依拠して正しく復号されるが、フレーム２２０Ｂ〜２２０Ｈのいずれも、ＧＯＰ２１０の外部のフレームのコンテンツに依拠しない。従って、ＧＯＰ２１０は、ＩＤＲアクセスポイント、即ち、フレーム２２０Ｉを含むクローズドＧＯＰと見なされ得る。
図３は、オープン復号リフレッシュ（ＯＤＲ）アクセスポイントを含むオープンＧＯＰ３１０を含むビデオフラグメント３０１の少なくとも一部分の一例を示す概念図である。図２の例と同様に、フレーム３２０ＡはＩフレームであり、ＩＤＲアクセスポイントである。また、図２の例と同様に、フレーム３２０Ｉは、ランダムアクセスポイントに対応するＩフレームである。しかしながら、表示順序でＩフレーム３２０Ｉより前のＧＯＰ３１０のフレームが正しく復号可能であるためにフレーム３２０Ａのコンテンツに依拠するという点で、図３の例は図２の例とは異なる。例えば、矢印によって示されるように、フレーム３２０Ｂ、３２０Ｃ、及び３２０Ｅの各々は、フレーム３２０Ａのコンテンツに直接依拠する。フレーム３２０Ｄ、及び３２０Ｆ〜３２０Ｈは、それぞれフレーム３２０Ｂ、３２０Ｃ、及び３２０Ｅのうちの１つ以上のコンテンツに少なくとも部分的に依拠して正しく復号されるように、それぞれフレーム３２０Ａのコンテンツに間接的に依拠する。しかしながら、また図３に示すように、表示順序でＩフレーム３２０Ｉに続くフレーム３２０Ｊ及び３２０Ｋは、Ｉフレーム３２０Ｉより前のフレームに対する依拠なしに正しく復号され得る。従って、Ｉフレーム３２０ＩはＯＤＲ ＲＡＰとして使用され得る。
本開示は、ストリーミングビデオのコンテキストにおけるランダムアクセス機能の改善のための技法を対象とする。本開示の技法は、ビデオプレゼンテーションのＨＴＴＰストリーミング、復号、及び／又は再生の開始のためのＯＤＲアクセスポイントと様々な他の情報との信号伝達を可能にする。
例えば、クライアント機器は、サーバ機器から、ビデオ表現の第１のＧＯＰのＯＤＲアクセスポイントの指示を受信し得る。第１のＧＯＰの少なくとも１つのフレームについての符号化情報は、復号順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの少なくとも１つのフレームが正しく復号され得ないことを示す。表示順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの各フレームは、表示順序でＯＤＲ ＲＡＰより前のフレームのコンテンツに依拠することなしに、正しく復号され得る。クライアント機器は、サーバ機器に、示されたＯＤＲ ＲＡＰで開始するメディアデータのストリームを検索する要求（例えば、ＧＥＴ要求又は部分ＧＥＴ要求）を送り得る。次いで、クライアント機器は、ＯＤＲ ＲＡＰにおいてメディアデータの復号／再生を開始し得る。
特に、発信源機器は、ビデオフラグメントのＯＤＲ ＲＡＰに対するバイトオフセットを信号伝達し得る。ビデオフラグメントは、ビデオフラグメントに固有のユニフォームリソースロケータ（ＵＲＬ）又はユニフォームリ発信源ネーム（ＵＲＮ）を使用して、単独でアドレス指定可能であり得る。一例では、ビデオフラグメント中のＯＤＲ ＲＡＰに対するバイトオフセットを信号伝達することによって、クライアント機器は、ＯＤＲ ＲＡＰにおいて開始しビデオフラグメントの終端において終了するバイト範囲を備える部分ＧＥＴ要求を構築し得る。
別の例として、サーバ機器は符号化ビデオフレームのシーケンスを受信し得る。符号化ビデオフレームのシーケンスのセグメンテーションファイルは、少なくとも１つのＯＤＲ ＲＡＰを含む。復号順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの少なくとも１つのフレームは、正しく復号され得ない。表示順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの各フレームは、表示順序でＯＤＲ ＲＡＰより前のフレームのコンテンツに依拠することなしに、正しく復号され得る。サーバ機器は、ＯＤＲ ＲＡＰのロケーションの指示を生成し得る。サーバ機器は、（例えば、ビデオファイルについてのヘッダ情報、プレゼンテーション、又はビデオプレゼンテーションのフラグメントにおいて）少なくとも１つの指示をクライアント機器に出力し得る。クライアントは、少なくとも１つの指示に基づいて、少なくとも１つの指示に基づいてビデオプレゼンテーションのセグメント又はセグメントの一部分のストリーミングを要求し得る。
別の例として、クライアント機器は、ビデオフラグメント又はプレゼンテーションの少なくとも１つのＩフレームのためのバイト範囲の少なくとも１つの指示を受信し得る。クライアント機器は、指示に基づいて、Ｉフレームを検索する要求をサーバ機器に送り得る。クライアント機器は、Ｉフレームを含むビデオプレゼンテーション又はフラグメントの高速バージョンを提示するために、少なくとも１つの検索されたＩフレームを使用し得る。Ｉフレームは、上記で説明したようにＩＤＲアクセスポイント又はＯＤＲアクセスポイントであることも、ＩＤＲアクセスポイント又はＯＤＲアクセスポイントでないことある。ビデオプレゼンテーションの高速バージョンは、クライアントが早送り又は早戻し動作についてのユーザ要求を受信したことに応答して提示され得る。
図４は、プログラム４３０の一例を示すブロック図である。プログラム４３０は、ビデオ（例えば、ムービー、テレビ番組、又は他の動画プレゼンテーション）のデジタル表現であり得る。プログラム４３０は、ＨＴＴＰストリーミングのためのサーバとして動作するように構成された１つ以上のコンピューティング機器上に記憶されるか、そのコンピューティング機器によってアクセス可能であり得る。図４の例によれば、プログラム４３０は、複数の表現４４０Ａ〜４４０Ｃとメディアプレゼンテーション記述（ＭＰＤ）４３２とを含む。複数の表現４４０Ａ〜４４０Ｃは複数のムービーフラグメント４４２を含み得る。複数のフラグメント４４２は、再生順序で構成され得、ビデオの様々な時間（即ち、時間的）部分を表し得る。
図４に示していないが、ムービー表現４４０Ａ〜４４０Ｃの１つ以上のフラグメント４４２は、１つ以上のムービーセグメント中に構成され得る。セグメントは、単一のＵＲＬに従って要求され得る連続ムービーフラグメントのセットを含み得る。例えば、セグメントは、ビデオ及びオーディオを含んでいることがある小さいファイルであり得る。別の例として、セグメントは１つのムービーフラグメントに対応し得、ムービーフラグメント自体は、単一のビデオトラックフラグメントと単一のオーディオトラックフラグメントとを含んでいることがある。さらに別の例として、セグメントは幾つかのムービーフラグメントに対応し得、そのうちのいずれかは、１つのビデオフラグメントと１つのオーディオフラグメントとを有し得、そのムービーフラグメントは復号時間において連続であり得る。図４に示していないが、ＨＴＴＰストリーミングによるビデオ再生の表現のための情報を信号伝達するための技法は、例えば、セグメンテーションファイル、例えば、ムービー表現、ムービーセグメント、ムービーフラグメントについてのヘッダ情報など、メディアプログラムについての任意のヘッダ情報に適用可能であり得る。
ＭＰＤ４３２は、プログラム４３０についてのヘッダ情報と見なされ得る。ＭＰＤ４３２は、１つ以上の表現４４０Ａ〜４４０Ｃを表す情報を含み得る。クライアント機器は、ストリーミング再生のための表現４４０Ａ〜４４０Ｃのうちの１つ以上の全部又は一部分を選択するために、ＭＰＤ４３２を検索し得る。また、表現４４０はフラグメントヘッダ４４３を含み得る。フラグメントヘッダ４４３は、表現４４０Ａ〜４４０Ｃの特定のフラグメント４４２に固有の情報を含み得る。ＭＰＤ４３２のように、フラグメントヘッダ４４３は、例えば、１つ以上の表現４４０Ａ〜４４０Ｃの１つ以上のフラグメント４４２の選択のために、ＨＴＴＰクライアント機器によってアクセス可能であり得る。
表現のフラグメント４４２は、ＩＤＲアクセスポイント又はＯＤＲアクセスポイントを含むことも、含まないこともある。幾つかの表現の場合、フラグメント４４２は、単一のＩＤＲアクセスポイントのみを含み得る。１つ以上のＩＤＲアクセスポイントは、プログラム４３０についてのヘッダ情報（例えば、図４のＭＰＤ４３２）において、又はプログラム４３０の１つ以上のフラグメント４４２についてのヘッダ情報４４３において信号伝達され得る。本開示の一態様は、ＭＰＤ４３２、フラグメントヘッダ４４３、又はプログラム４３０の他のヘッダ情報のうちの１つ又は複数において、ＯＤＲアクセスポイントを信号伝達することを対象とする。従って、ＨＴＴＰクライアントには、プログラム４３０のストリーミング、復号、及び／又は再生を開始するための増加した時間オプションが与えられ得る。
幾つかの例では、ムービーは２時間以上であり得る。ムービーを表すプログラム４３０又は表現は、全プレゼンテーションの比較的短い部分を表し得る複数の（再生時間順序で）時間的に構成されたムービーフラグメントを含み得る。例えば、各ムービーフラグメントは、数秒を表すか、又は数分の長さであり得る。ＨＴＴＰストリーミングによれば、クライアント機器は、ムービーの特定の時点においてセグメンテーションファイルの再生を要求し得る。そうするために、クライアント機器は、表現を与えるＧＥＴ要求又は部分ＧＥＴ要求をサーバにサブミットし得る。ＨＴＴＰ ＧＥＴ要求は、ＵＲＬ又はＵＲＮに関連するファイル全体を検索するために、特定のＵＲＬ又はＵＲＮを対象とする。ＨＴＴＰ部分ＧＥＴもＵＲＬ又はＵＲＮを対象とするが、検索すべきファイルのバイト範囲をさらに指定する。
本開示の技法によれば、ムービー表現４４０の幾つかのフラグメント４４２は、特定のフラグメントがＩＤＲアクセスポイントを含むかどうかを信号伝達するヘッダ情報を含み得る。場合によっては、ムービーフラグメントがムービーフラグメントの第１のフレームとしてＩＤＲのみを含む場合、クライアント機器は、ビデオフラグメントの始端、又は他の特定の時間ロケーションにおいて再生を開始することに制限され得る。幾つかのムービーフラグメントは、ＩＤＲアクセスポイントを含まないことがあり、１つ以上のＯＤＲアクセスポイントのみを含むことがある。幾つかの例では、クライアント機器は、ビデオフラグメント中の任意のポイントにおいて再生を開始することが可能でないことがある。
ビデオフラグメントは、ビデオデータの数秒、さらには数分を表し得る。従って、ＩＤＲアクセスポイントのみが信号伝達された場合、クライアントには、再生の開始のための限定されたオプションが与えられ得る。例えば、ユーザが再生を停止し、次いで、後続の閲覧中に特定の時間ロケーションから再生を再開するように要求した場合、例えば、ユーザは、プレゼンテーションの特定の時点に戻るためにビデオプレゼンテーションのすでに閲覧された部分を閲覧するように要求され得る。別の例として、クライアント機器は、（例えば、帯域幅条件が変化した場合など、クライアント機器がプログラムの代替表現を要求した場合）ユーザによって要求された時間ロケーション、又はクライアント機器によって開始された時間ロケーションにおいて開始する復号／再生のために必要とされるビデオプレゼンテーションのフレームよりも多くのビデオプレゼンテーションのフレームをダウンロードする必要があり得る。さらに、幾つかのビデオフラグメントはＩＤＲアクセスポイントを含まないことがある。
セグメンテーションファイル、ビデオ表現、又はビデオフラグメントについてのヘッダ情報においてＯＤＲアクセスポイントを信号伝達することによって、ＨＴＴＰビデオストリーミングのための走査及びシーク機能は改善され得る。例えば、ＨＴＴＰストリーミングのための既知の技法は、フラグメント内の少数のフラグメント及び／又は位置におけるストリーミング／復号／再生開始のみを可能にし得るが、本開示の技法は、再生のためのランダムアクセスポイントの数の増加を可能にする。本開示の技法はまた、復号のための大量のインターＧＯＰ依存を含むビデオ表現にとって有用であり得る。
本開示の他の態様は、ムービー表現の高速再生（例えば、早送り、巻戻し）のために、セグメンテーションファイル又はプレゼンテーションのＩフレームのバイト範囲の信号伝達を可能にする。これらの態様によれば、例えば、ビデオ表現のＩフレームのみ、又は利用可能なＩフレームのサブセットを表示することによって、高速でビデオ表現を表示するために、クライアント機器が、ムービー表現のＩフレームを要求し、受信し、及び／又は復号し得るように、ムービープレゼンテーションの１つ以上のＩフレームのバイト範囲がクライアント機器に信号伝達され得る。
本開示の技法は、ＩＳＯベースメディアファイルフォーマット、スケーラブルビデオ符号化（ＳＶＣ）ファイルフォーマット、Advanced Video Coding（ＡＶＣ）ファイルフォーマット、Third Generation Partnership Project（３ＧＰＰ）ファイルフォーマット、及び／又はマルチビュービデオ符号化（ＭＶＣ）ファイルフォーマットのいずれかに準拠するビデオファイルに適用され得る。ＩＳＯベースメディアファイルフォーマットは、メディアの交換、管理、編集、及びプレゼンテーションを可能にする、フレキシブルな、拡張可能なフォーマットの表現のための、時限メディア情報を含んでいるように設計される。ＩＳＯベースメディアファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１２：２００４）は、時間ベースメディアファイルのための一般的な構造を定義するＭＰＥＧ−４ Ｐａｒｔ１２において規定されている。それは、Ｈ．２６４／ＭＰＥＧ−４ＡＶＣビデオ圧縮のサポートを定義したＡＶＣファイルフォーマット（ＩＳＯ／ＩＥＣ１４４９６−１５）、３ＧＰＰファイルフォーマット、ＳＶＣファイルフォーマット、及びＭＶＣファイルフォーマットなどのファミリー中の他のファイルフォーマットに対する基準として使用される。３ＧＰＰファイルフォーマット及びＭＶＣファイルフォーマットはＡＶＣファイルフォーマットの拡張である。ＩＳＯベースメディアファイルフォーマットは、オーディオビジュアル表現などのメディアデータの時限シーケンスのためのタイミング、構造、及びメディア情報を含んでいる。ファイル構造はオブジェクト指向である。ファイルは、非常に単純に基本オブジェクトに分解され得、オブジェクトの構造はそれらのタイプから暗示される。
ＩＳＯベースメディアファイルフォーマットに準拠するファイルは、「ボックス」と呼ばれる一連のオブジェクトとして形成される。ＩＳＯベースメディアファイルフォーマットのデータはボックス中に含まれており、ファイル内に他のデータはない。これは、特定のファイルフォーマットによって必要とされる初期シグナチャを含む。「ボックス」は、一意のタイプ識別子と長さとによって定義されるオブジェクト指向ビルディングブロックである。一般に、プレゼンテーションは１つのファイル中に含まれ、メディアプレゼンテーションは独立型（self-contained）である。ムービーコンテナ（ムービーボックス）はメディアのメタデータを含んでおり、ビデオ及びオーディオフレームは、メディアデータコンテナ中に含まれており、他のファイル中にあり得る。
プレゼンテーション（動きシーケンス）は、幾つかのファイル中に含まれていることがある。タイミング及びフレーミング（位置及びサイズ）情報は、ＩＳＯベースメディアファイルフォーマットに準拠するファイル中に含まれ得るが、補助ファイルは本質的に任意のフォーマットを使用し得る。このプレゼンテーションは、プレゼンテーションを含んでいるシステムに対して「ローカル」であり得るか、或いはネットワーク又は他のストリーム配信機構を介して行われ得る。
ファイルは、論理構造と時間構造と物理構造とを有し得、これらの構造は結合される必要はない。ファイルの論理構造は、時間並列トラックのセットを含んでいるムービーであり得る。ファイルの時間構造は、トラックが時間的なサンプルのシーケンスを含んでおり、それらのシーケンスは、随意のエディットリストによってムービー全体のタイムラインにマッピングされるものであり得る。ファイルの物理構造は、メディアデータサンプル自体から、論理、時間、及び構造的分解のために必要とされるデータを分離し得る。この構造的情報は、ムービーボックス中に集められ、場合によってはムービーフラグメントボックスによって時間的に拡張され得る。ムービーボックスは、サンプルの論理関係及びタイミング関係をドキュメント化し得、また、サンプルが配置される場所へのポインタを含んでいることがある。それらのポインタは、例えば、ＵＲＬによって参照される同じファイル又は別のファイルへのものであり得る。
各メディアストリームは、そのメディアタイプ（オーディオ、ビデオなど）に専用のトラック中に含まれていることがあり、さらにサンプルエントリによってパラメータ表示され得る。サンプルエントリは、厳密なメディアタイプ（ストリームを復号するために必要とされるデコーダのタイプ）の「名前」と、必要とされるそのデコーダのパラメータ表示を含んでいることがある。名前はまた、４文字コード、例えば、「ｍｏｏｖ」、又は「ｔｒａｋ」の形態をとり得る。ＭＰＥＧ−４メディアについてだけでなく、このファイルフォーマットファミリーを使用する他の編成によって使用されるメディアタイプについても、定義済みのサンプルエントリフォーマットがある。
メタデータのサポートは、概して２つの形態をとる。第１に、時限メタデータが、適切なトラックに記憶され得、必要に応じて、それが表しているメディアデータと同期され得る。第２に、ムービー又は個々のトラックにアタッチされた非時限メタデータの全般的サポートがあり得る。構造的サポートは、全般的であり、メディアデータの場合のように、ファイル中の他の場所又は別のファイル中でのメタデータリ発信源の記憶を可能にする。さらに、これらのリ発信源は名前付きであり得、保護され得る。
上記で説明したように、ＩＳＯベースメディアファイルフォーマット拡張の一例は、ＡＶＣファイル構成である。ＡＶＣファイルフォーマットに従って作成されるセグメンテーションファイルは、シーケンスパラメータセット（ＳＰＳ）とピクチャパラメータセット（ＰＰＳ）とを含む、パラメータセットであるＮＡＬユニットを含み得る。パラメータセットは、１つ以上のビデオトラック中に含まれ得るビデオのエレメンタリストリームに関連し得る。幾つかの例では、パラメータセットは、ビデオのエレメンタリストリーム以外の別のトラック（パラメータセットトラック）中にあり得る。パラメータセットトラックは、ＳＰＳ及び／又はＰＰＳ ＮＡＬユニットであるサンプルを含んでいるパラメータセットエレメンタリストリームであり得る。ＳＰＳ及びＰＰＳ ＮＡＬユニットは、ＶＣＬ ＮＡＬユニットから符号化ピクチャサンプルを復号するために必要でない情報を含む１つ以上のＳＥＩメッセージを含み得る。ＳＥＩメッセージが、そのＳＥＩメッセージを使用するピクチャより前の復号時間をもつサンプル中にある限り、ＳＥＩメッセージを含むＮＡＬユニットのロケーションは制限されない。
また、上記で説明したように、ＩＳＯファイルフォーマット拡張の他の例は、ＳＶＣ及びＭＶＣファイルフォーマットを含む。また、ＳＶＣ及びＭＶＣは、上記で説明したＡＶＣファイルフォーマットの拡張と見なされ得る。ＳＶＣ及びＭＶＣフォーマットによれば、ビデオの複数のレイヤ／ビューは、単一のビデオトラック又は複数のビデオトラック中に含まれていることがある。ＳＶＣ及びＭＶＣファイルフォーマット仕様は、レイヤ／ビューが様々な編成で提示されるとき、動作点の構成を可能にするツールを規定し得る。
プログレッシブダウンロードは、ＨＴＴＰプロトコルを一般に使用する、サーバからクライアントへのデジタルメディアセグメンテーションの転送を表すために使用される用語である。コンピュータから開始されると、消費者は、ダウンロードが完了する前にメディアの再生を開始し得る。ストリーミングメディアとプログレッシブダウンロードとの間の相違は、デジタルメディアにアクセスしているエンドユーザ機器によってデジタルメディアデータが受信され、記憶される方法にある。プログレッシブダウンロード再生が可能であるメディアプレーヤは、そのままファイルのヘッダ中に配置されたメタデータと、ウェブサーバからダウンロードされたときのデジタルメディアセグメンテーションのローカルバッファとに依拠する。データの指定された量がローカル再生機器に利用可能なった時点で、メディアは再生し始める。この指定された量のバッファは、エンコーダ設定においてコンテンツの製作者によってファイルに埋め込まれ得、メディアプレーヤによって課せられる追加のバッファ設定によって補強され得る。
ビデオストリーミングのためにＨＴＴＰを使用することは幾つかの利点を有し、ＨＴＴＰに基づくビデオストリーミングサービスが普及しつつある。ＨＴＴＰストリーミングの幾つかの利点は、ネットワークを介してビデオデータをトランスポートするために新たな労力が必要とされないように、既存のインターネット構成要素及びプロトコルが使用され得ることを含む。他のトランスポートプロトコル、例えばＲＴＰペイロードフォーマットは、メディアフォーマット及び信号伝達コンテキストを認識するために、中間ネットワーク機器、例えば中間ボックスを必要とする。また、ＨＴＴＰストリーミングはクライアント主導型であり得、それにより、多くの制御問題を回避する。例えば、最適性能を取得するためのすべての特徴を活用するために、サーバは、まだ肯定応答されていないパケットのサイズとコンテンツとを追跡し得る。サーバはまた、ＲＤ最適切替え／シニング（thinning）決定を行うために、ファイル構造を分析し、クライアントバッファの状態を再構成し得る。さらに、ネゴシエートされたプロファイルに準拠した状態を保つために、ビットストリーム変動に関する制約が満たされ得る。ＨＴＴＰは、ＨＴＴＰ１．１が実装されたウェブサーバにおいて、新しいハードウェア又はソフトウェア実装形態を必要としないことがある。ＨＴＴＰストリーミングはまた、ＴＣＰフレンドリネスとファイアウォール横断とを実現し得る。本開示の技法は、例えば、ビットレート適応を行うことによって、帯域幅に関係する問題を克服するために、ビデオデータのＨＴＴＰストリーミングを改善し得る。
ＩＴＵ−ＴＨ．２６１、Ｈ．２６２、Ｈ．２６３、ＭＰＥＧ−１、ＭＰＥＧ−２及びＨ．２６４／ＭＰＥＧ−４ ｐａｒｔ１０などのビデオ圧縮規格は、時間冗長性を低減するために動き補償時間予測を利用する。エンコーダは、動きベクトルに従って現在の符号化ピクチャを予測するために、幾つかの前の（本明細書ではフレームとも呼ぶ）符号化ピクチャからの動き補償予測を使用する。典型的なビデオ符号化には３つの主要なピクチャタイプがある。それらは、イントラ符号化ピクチャ（「Ｉピクチャ」又は「Ｉフレーム」）と、予測ピクチャ（「Ｐピクチャ」又は「Ｐフレーム」）と、双方向予測ピクチャ（「Ｂピクチャ」又は「Ｂフレーム」）とである。Ｐピクチャのブロックは、１つの他のピクチャを参照してイントラ符号化され得るか、又は予測され得る。Ｂピクチャでは、ブロックは、１つ又は２つの参照ピクチャから予測され得るか、又はイントラ符号化され得る。これらの参照ピクチャは、時間順序で現在のピクチャの前又は後に位置し得る。
３ＧＰＰファイルフォーマット（３ＧＰＰ）は、ＩＳＯメディアベースファイルフォーマットの拡張の別の例である。３ＧＰＰは、３Ｇ ＵＭＴＳマルチメディアサービスのためにThird Generation Partnership Project（３ＧＰＰ）によって定義されたマルチメディアコンテナフォーマットである。それは、一般に３Ｇモバイルフォン及び他の３Ｇ対応機器上で使用されるが、幾つかの２Ｇ及び４Ｇフォン並びに様々な他の機器上でも再生され得る。３ＧＰＰファイルフォーマットはＩＳＯベースメディアファイルフォーマットに基づく。最新の３ＧＰは、３ＧＰＰ ＴＳ２６．２４４、「Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP)」において規定されている。３ＧＰＰファイルフォーマットは、ビデオストリームをＭＰＥＧ−４ Ｐａｒｔ２又はＨ．２６３又はＭＰＥＧ−４ Ｐａｒｔ１０（ＡＶＣ／Ｈ．２６４）として記憶する。３ＧＰＰは、ＩＳＯベースメディアファイルフォーマット（ＭＰＥＧ−４ Ｐａｒｔ１２）でのサンプルエントリ及びテンプレートフィールドの使用、並びにコーデックが参照する新しいボックスを定義することを規定しているので、３ＧＰＰは、ＩＳＯベースメディアファイルフォーマットでのＡＭＲ及びＨ．２６３コーデックの使用を可能にする。３ＧＰファイルにおけるＭＰＥＧ−４メディア固有情報の記憶のために、３ＧＰ仕様は、同じくＩＳＯベースメディアファイルフォーマットに基づくＭＰ４及びＡＶＣファイルフォーマットに言及している。ＭＰ４及びＡＶＣファイルフォーマット仕様には、ＩＳＯベースメディアファイルフォーマットのＭＰＥＧ−４コンテンツの使用が記載されている。
３ＧＰＰファイルフォーマットは、ＨＴＴＰストリーミングをサポートし得る。幾つかの例では、３ＧＰＰファイルフォーマットは、メディアプレゼンテーション記述ＭＰＤ（例えば、図４に示したＭＰＤ４３２）を含み得る。ＭＰＤは、異なる代替表現（例えば、異なる品質をもつビデオサービス）の記述を含み得、その記述は、例えば、コード、プロファイル及びレベル情報を含み得る。ＭＰＤは、ビデオデータを含む３ＧＰＰファイルの部分でないことがある。
図５は、ビデオプログラムのための表現５４０の一例（例えば、上記の図４に示した表現４４０Ａ〜４４０Ｃのうちの１つ）を示すブロック図である。図５の例は、３ＧＰＰファイルフォーマットによる表現５４０を示す。図５の表現５４０は、本開示の技法について説明するために与えられたものにすぎず、非限定的なものである。本開示の技法は、本明細書で明示的に言及するか否かにかかわらず、ビデオデータの任意のデジタル表現に適用され得る。
図５に示すように、表現５４０は、ムービーボックス（ｍｏｏｖ）５４４と、セグメントインデックスボックス（ｓｉｄｘ）５７０と、１つ以上のムービーフラグメント（ｍｏｏｆ）５４６とを含む。説明を簡単にするために、図５の例では、ただ１つのムービーフラグメント５４６が示されている。典型的なムービー表現５４０は、図４に示したように、複数のムービーフラグメント５４６を含み得る。
ムービーボックス５４４は、表現５４０に固有の様々な情報を含み得る。例えば、ムービーボックス５４４は、ムービー表現のストリーミングのための所望のビットレートなどの情報を示し得る。ムービーボックス５４４は、代わりに又は追加として、フラグメント５４６に固有の情報の１つ以上の指示を含み得る。例えば、ムービーボックス５４４は、表現中に含まれているフラグメント５４６の数、１つ以上のフラグメント５４６の開始及び／又は終了に対応する再生時間、及び／又は表現５４０のフラグメント５４６のためのビット範囲の１つ以上の指示を示す情報を含み得る。
表現５４０は、１つ以上のセグメントインデックスボックス５７０をさらに含み得る。セグメントインデックスボックス５７０は、表現５４０の１つ以上のフラグメント５４６に先行し得る。幾つかの例では、セグメントインデックスボックス５７０は、表現５４０の各フラグメント５４６に先行し得る（例えば、図４を参照）。他の例では、セグメントインデックスボックス５７０は、複数のフラグメントがムービーセグメント中に構成された場合、表現の各セグメントに先行し得る。
セグメントインデックスボックス５７０は、フラグメント５４６のためのランダムアクセス機能に関係する情報を信号伝達するように構成され得る。例えば、知られている実装形態によれば、セグメントインデックスボックス５７０は、フラグメント５４６のＩＤＲアクセスポイントを示し得る。セグメントインデックスボックス５７０は、ＩＤＲアクセスポイント（基準フラグメント）を含むフラグメントのバイトオフセット（基準オフセット）をさらに示し得る。セグメントインデックスボックス５７０は、基準フラグメント（基準デルタ時間）の第１のサンプルのタイミング情報をさらに示し得る。セグメントインデックスボックスは、現在のムービーフラグメント（例えば、セグメントインデックスボックス５７０の後のフラグメント）がランダムアクセスポイントを含むかどうか（contains RAP）をさらに示し得る。セグメントインデックスボックス５７０は、ムービーフラグメント５４６の第１のサンプルとムービーフラグメント５４６の第１のランダムアクセスポイントとの間のタイミング差をさらに示し得る。
以下の擬似コードは、幾つかの技法に従ってセグメントインデックスボックス５７０を実装するために使用され得るコードの一例である。以下の擬似コードでは、セグメントインデックスボックスデータ構造のために使用され得る幾つかの変数が記載されている。これらの変数は、概して、上記で説明した、同様に名前を付けられた変数に対応する。
Figure 0005628422
ムービー表現５４０のセグメントインデックスボックス５７０の幾つかの実装形態には、様々な短所があり得る。例えば、セグメントインデックスボックス５７０の幾つかの実装形態は、ビデオフラグメント５４６のためのＩＤＲアクセスポイントを信号伝達するように構成されるにすぎない。さらに、場合によっては、ムービーフラグメント５４６は、ＩＤＲランダムアクセスポイントであるフレームから開始し得る。これらの場合、セグメントインデックスボックス５７０の実装形態は、第１のフレームがＩＤＲアクセスポイントであることを信号伝達しない。代わりに、フラグメントの第１のサンプルと信号の第１のランダムアクセスポイントとの間の差のタイミング情報（例えば、基準デルタ時間）がさらに信号伝達される。これは、セグメントインデックスボックス５７０が、場合によっては必要とされない情報を通信し得るので望ましくないことがある。
セグメントインデックスボックス５７０の幾つかの実装形態は、ＩＤＲ ＲＡＰのための信号バイトオフセットが、ムービーフラグメントの開始（第１のフレーム）に対して提示されるのでさらに望ましくないことがある。従って、場合によっては、ＩＤＲ ＲＡＰがビデオフラグメント５４６の第１のフレームの後のある時間に生じるが、ＩＤＲ ＲＡＰに先行するサンプルは再生のために復号され得ない場合でも、フラグメント５４６のフレームのすべてがクライアント機器によってダウンロードされる必要があり得、従って、ネットワーク接続の有益な帯域幅を浪費する。
本開示は、ビデオプレゼンテーションのＯＤＲ ＲＡＰ、例えば、ビデオ表現のビデオフラグメント、及び／又はビデオ表現のための走査及び／又はシーク機能に関係する他の情報の信号伝達のための改善された技法を対象とする。本開示はさらに、ビデオフラグメント又はビデオ表現のＩフレームのバイト範囲を信号伝達することを対象とする。信号伝達されたバイト範囲は、早送り又は早戻し動作のためにビデオプレゼンテーションの高速バージョンを与えるために、１つ以上の信号伝達されたＩフレームを要求するためにクライアント機器によって使用され得る。
説明のために、本開示の技法は、それらが３ＧＰＰファイルフォーマットによるビデオ表現のセグメントインデックスボックス５７０に適用されるものとして説明する。本開示の技法が、再生のための動画のデジタル表現のための任意の他のフォーマットに適用可能であることを、当業者は認識されよう。さらに、本開示の技法について、セグメンテーションファイルの１つ以上のフラグメントに固有のヘッダ情報においてＯＤＲアクセスポイント、他の情報、及び／又はＩフレームのバイト範囲を信号伝達することに関して説明する。本明細書で説明するヘッダ情報が、ＯＤＲアクセスポイント、Ｉフレームバイト範囲、又は他の情報を、ムービー表現全体にとって概略的なＭＰＤファイル（セグメンテーションファイルレベル）、特定の表現に固有のヘッダ情報、又はムービー表現の特定のセグメントに固有のヘッダ情報においてなど、セグメンテーションファイルの他のレベルで信号伝達し得ることを当業者は認識されよう。
図６は、本開示の技法に一致するムービープレゼンテーション（例えば、図５に示すプレゼンテーション５４０）のセグメントインデックスボックス６７０によって信号伝達され得る様々な情報を示すブロック図である。セグメントインデックスボックス６７０は、１つ以上のセグメンテーションファイルに関係する情報を記憶するように構成されたデータ構造であり得る。幾つかの例では、セグメントインデックスボックス６７０は、図６に示す情報のサブセットを含み得るか、又は図６に示す情報のすべてを含み得る。本開示の技法に一致するセグメントインデックスボックス６７０を実装するために利用され得る擬似コードの一例を、以下に提示する。
Figure 0005628422
上記の擬似コードは、本開示の技法に一致するメディアセグメントのセグメントインデックスボックスデータ構造において、メディアのストリーミングに関係する情報を信号伝達するために使用され得る幾つかの変数を定義する。上記の変数は、概して、図６に関して以下に説明する、同様に名前を付けられた信号伝達に対応する。
一例では、上記の擬似コードからの値contains_RAPは、以下の意味論的定義に従って定義され得る。「contains_RAP：ムービーフラグメントへの参照であるとき、ID reference_track_idをもつトラックについてそのムービーフラグメント内のトラックフラグメントが少なくとも１つのランダムアクセスポイントを含んでいる場合、この値は２であり得、ID reference_track_idをもつトラックについてそのムービーフラグメント内のトラックフラグメントがランダムアクセスポイントとして第１のサンプルを含んでいる場合、この値は１であり得、その他の場合は、この値は０に設定される。セグメントインデックスへの参照であるとき、そのセグメントインデックス中の参照のいずれかでこの値が１又は２に設定されている場合のみ、この値は１又は２に設定され、その他の場合は０に設定されるものとする。」
以下の表１に、contains_RAPのための値と各値の意味論的含意との例示的なセットを与える。
Figure 0005628422
一例では、上記の擬似コードからの値RAP_typeは、以下の意味論的定義に従って定義され得る。「この値は、ムービーフラグメントの参照されたトラック中に含まれているランダムアクセスポイントのタイプを規定する。」
以下の表２に、contains_RAPのための値と各値の意味論的含意との例示的なセットを与える。
Figure 0005628422
一例では、図６に示すように、セグメントインデックスボックス６７０は、ビデオフラグメントがランダムアクセスポイントを含むか否かの少なくとも１つの指示である、contains RAP６０１を含む。contains RAP６０１は、ムービーフラグメントがＩＤＲアクセスポイント又はＯＤＲアクセスポイントのいずれかを含むのか、或いはその両方を含むのかを示し得る。contains RAP６０１は、ムービーフラグメントの第１のサンプルがランダムアクセスポイントであるかどうかをさらに示し得る。contains RAP６０１は、代わりに、ムービーフラグメントがランダムアクセスポイントを含まないことを信号伝達し得る。
特定の一例では、ムービーフラグメントが少なくとも１つのランダムアクセスポイントを含む場合、contains RAP６０１には値２が割り当てられ得る。ムービーフラグメントが、フラグメントの第１のサンプルである少なくとも１つのランダムアクセスポイントを含む場合、contains RAP６０１には値１が割り当てられ得る。ムービーフラグメントがランダムアクセスポイントを含まない場合、contains RAPには値０が割り当てられ得る。
また、図６の例に示すように、セグメントインデックスボックス６７０は、ランダムアクセスポイントタイプの少なくとも１つの指示である、ＲＡＰタイプ６０２を含み得る。ＲＡＰタイプ６０２は、ＩＤＲアクセスポイントが、ビデオフラグメント中に含まれている第１のランダムアクセスポイントであるかどうかを示し得る。ＲＡＰタイプ６０２は、ＯＤＲアクセスポイントがビデオフラグメントの第１のランダムアクセスポイントであるかどうかをさらに示し得る。ＲＡＰタイプ６０２は、ＯＤＲがビデオフラグメントの第１のランダムアクセスポイントであり、ビデオフラグメントがまたＯＤＲアクセスポイントの後にＩＤＲを含むことをさらに示し得る。ＯＤＲアクセスポイントの後のＩＤＲアクセスポイントは、遅いＩＤＲアクセスポイントと呼ばれることがある。
特定の一例では、ＩＤＲアクセスポイントが、ビデオフラグメント中に含まれている第１のランダムアクセスポイントである場合、ＲＡＰタイプ６０２には値００（０）が割り当てられ得る。この例によれば、ＯＤＲアクセスポイントがビデオフラグメントの第１のランダムアクセスポイントである場合、ＲＡＰタイプ６０２には値０１（１）が割り当てられ得る。また、この例によれば、ＯＤＲがビデオフラグメントの第１のランダムアクセスポイントであり、ビデオフラグメントがまたＯＤＲアクセスポイントの後にＩＤＲを含む場合、ＲＡＰタイプ６０２には値１０（２）が割り当てられ得る。
また、図６の例に示すように、セグメントインデックスボックス６７０は、ランダムアクセスポイントデータオフセットの少なくとも１つの指示である、ＲＡＰデータオフセットフラグ６０３を含み得る。ＲＡＰデータオフセットフラグ６０３は、ＲＡＰのバイトオフセットがさらに信号伝達されるべきかどうかを示し得る。例えば、ＲＡＰデータオフセットフラグ６０３は、ビデオフラグメントの第１のランダムアクセスポイントがフラグメントのトラックの第１のサンプルでないときを示し得る。特定の一例では、第１のＲＡＰがムービーフラグメントの参照されたトラックの第１のサンプルでないとき、ＲＡＰデータオフセットフラグ６０３には値１が割り当てられ得る。この例によれば、第１のＲＡＰがムービーフラグメントの参照されたトラックの第１のサンプルである場合、ＲＡＰデータオフセットフラグ６０３には値０が割り当てられ得る。一例では、ＲＡＰタイプ６０２に値２が割り当てられた（例えば、ビデオフラグメントが、フラグメントの第１のＲＡＰ後にＩＤＲを含む）とき、ＲＡＰデータオフセットフラグ６０３には値１のみが割り当てられ得る。
また、図６の例に示すように、セグメントインデックスボックス６７０は、ＯＤＲ ＲＡＰの分解時間（復号時間）とプレゼンテーション時間との間の差の少なくとも１つの指示である、デルタｄｔ ｐｔ６０４を含み得る。特定の一例では、デルタｄｔ ｐｔには、ＯＤＲ ＲＡＰの分解時間とプレゼンテーション時間との間のタイミング差の分、秒、クロックサイクルの数、又は他の指示を表す数値が割り当てられ得る。
また、図６の例に示すように、セグメントインデックスボックス６７０は、ＯＤＲ ＲＡＰより前のプレゼンテーション時間とＯＤＲ ＲＡＰ後の分解（復号）時間とをもつビデオフラグメント又はプレゼンテーションのサンプル（フレーム）の数の少なくとも１つの指示である、スキップサンプル数６０５を含み得る。特定の一例では、スキップサンプル数には、ＯＤＲ ＲＡＰより前のプレゼンテーション時間とＯＤＲ ＲＡＰ後の分解時間とをもつサンプルの数を表す数値が割り当てられ得る。
また、図６の例に示すように、セグメントインデックスボックス６７０は、ビデオフラグメントの第１のＩＤＲ ＲＡＰと第１のサンプルとの間の復号時間差の少なくとも１つの指示である、遅いＩＤＲ ＲＡＰデルタ時間６０６を含み得る。ＲＡＰタイプ６０２に値２を割り当てられた場合、遅いＩＤＲ ＲＡＰデルタ時間６０６には、ビデオフラグメントの第１のＩＤＲ ＲＡＰと第１のサンプルとの間の復号時間の差を示す数値（例えば、フレームの数、バイト範囲、クロックサイクルの数、又は復号時間差の他の指示）が割り当てられ得る。
また、図６の例に示すように、セグメントインデックスボックス６７０は、ムービーフラグメントの第１のバイトとムービーフラグメントの第１のサンプルの第１のバイトとのオフセットの少なくとも１つの指示である、ヘッドオフセット６０７を含み得る。ヘッドオフセット６０７は、ビデオフラグメントのヘッダ情報のバイト長を示し得る。特定の一例では、ヘッドオフセット６０７には、ビデオフラグメントの第１のバイトとビデオフラグメントの第１のフレームとの間のバイトオフセットを示す数値、例えば、ヘッダのバイト数又はヘッダのバイト範囲が割り当てられ得る。一例では、ムービーフラグメントが２つ以上のトラックを含む場合、ヘッドオフセット６０７には値０が割り当てられ得る。
また、図６の例に示すように、セグメントインデックスボックス６７０は、ランダムアクセスポイントの第１のバイトとムービーフラグメントの第１のバイトとの間のバイトオフセットの少なくとも１つの指示である、デルタオフセット６０８を含み得る。特定の一例では、デルタオフセット６０７には、ランダムアクセスポイントの第１のバイトとムービーフラグメントの第１のバイトとの間のバイトオフセットを示す数値、例えば、ランダムアクセスポイントの第１のバイトとムービーフラグメントの第１のバイトとの間のバイト数又はバイト範囲が割り当てられ得る。
また、図６の例に示すように、セグメントインデックスボックス６７０は、遅いＩＤＲ ＲＡＰの第１のバイトとムービーフラグメントの第１のバイトとの間のバイトオフセットの少なくとも１つの指示である、遅いＩＤＲデルタオフセット６０９を含み得る。特定の一例では、遅いＩＤＲデルタオフセット６０９には、遅いＩＤＲ ＲＡＰの第１のバイトとムービーフラグメントの第１のバイトとの間の差を示すバイト数、又はバイト範囲を示す数値が割り当てられ得る。
図６に示すヘッドオフセット６０７、デルタオフセット６０８、及び／又は遅いＩＤＲデルタオフセット６０９の実装形態は、ヘッドオフセット（例えば、ムービーフラグメント又はプレゼンテーションのヘッダ情報のバイト数）を信号伝達するためにより少ないビット（例えば、８ビット）が使用され得るので有利であり得る。従来の技法によれば、ムービーフラグメント中に追加情報（例えば、ボックス）がある場合、及び／又はムービーフラグメントが複数のトラックを含む場合を考慮するために、ビデオフラグメントのためのヘッドオフセットを信号伝達するために３２ビットが使用され得る。
また、図６の例に示すように、セグメントインデックスボックス６７０は、フラグメントの１つ以上のＩフレームのためのバイト範囲の少なくとも１つの指示である、Ｉフレームバイト範囲６１０をさらに又は代わりに含み得る。Ｉフレームバイト範囲６１０は、クライアント機器が、ビデオプレゼンテーションの高速バージョン（例えば、早送り、早戻し）を与えるために、Ｉフレームを選択的に要求し、受信し、及び／又は復号し得るように、Ｉフレームのバイト範囲をクライアント機器に示し得る。幾つかの例では、クライアント機器は、示されたＩフレーム又はフラグメントのみを受信し、及び／又は復号し得る。この例によれば、クライアント機器は、ビデオフラグメントのすべてのフレーム（例えば、Ｐフレーム又はＢフレーム）を要求し、受信し、及び／又は復号することなしに、ビデオプレゼンテーションの高速バージョンを提示し、それによって、ビデオフラグメントの高速バージョンを提示するために転送されるデータの量を低減し得る。
また、図６の例に示すように、セグメントインデックスボックス６７０は、ビデオフラグメントのＩフレームのための最大オフセットの少なくとも１つの指示である、Ｉフレーム最大オフセット６１１をさらに又は代わりに含み得る。Ｉフレーム最大オフセット６１１は、ビデオ表現の１つ以上のフラグメントについて、フラグメントが少なくとも１つのＩフレームを含む可能性があるフラグメントのバイト範囲を表し得る。一例では、クライアント機器は、Ｉフレーム最大オフセット６１１を受信し、Ｉフレーム最大オフセット６１１によって示されるビデオフラグメントの部分のみを要求し得る。この例によれば、クライアント機器は、要求されたバイト範囲のフレームを受信し、フラグメントを含むビデオ表現の高速バージョン（例えば、早送り、早戻し）を与えるために、要求されたバイト範囲の少なくともＩフレームを復号し得る。
図６に関して説明したセグメントインデックスボックス６７０中に含まれる様々な情報は、再生をストリーミングするためにメディアを取得するために、ＨＴＴＰクライアント機器によって利用され得る。例えば、ＨＴＴＰサーバ機器は、ムービープレゼンテーションのファームのための１つ以上のセグメントインデックスボックス６７０を、アクセスのためにクライアント機器にとって利用可能にし得る。クライアント機器は、セグメントインデックスボックス６７０の情報をレビューし、メディアのストリーミングについての要求を判断するためにその情報を使用し得る。例えば、クライアント機器は、セグメントインデックスボックス６７０の情報に基づいて、ストリーミング／復号／再生がビデオプレゼンテーション中のどの時間ロケーション（例えば、（１つ以上の）アクセスポイント）において開始し得るかを判断し得る。１つ以上のアクセスポイントを判断したことに応答して、クライアント機器は、データのストリーミングについてのＧＥＴ要求又は部分ＧＥＴ要求を開始し得る。ＧＥＴ要求又は部分ＧＥＴ要求は、フラグメント又はフラグメントの一部分をケーシングして、サーバ機器によって、復号／再生のためにクライアント機器に送信され得る。
本開示の技法は、動画プレゼンテーションのストリーミング、復号、及び／又は再生の開始のための改善された精度を可能にし得る。例えば、ビデオフラグメントについて１つ以上のＯＤＲアクセスポイントの識別情報を信号伝達することによって、クライアント機器は（例えば、上記で説明したピクチャレベルＳＥＩメッセージを介して）ＩＤＲアクセスポイントの信号伝達及び／又はフレームレベル信号伝達のみを可能にした従来の技法よりも表現中の多くの開始ポイントにアクセスし得る。ＯＤＲアクセスポイントのフレームレベル信号伝達は、クライアント機器が、ＯＤＲアクセスポイントのロケーションを判断するためにビデオプレゼンテーションのフラグメント全体を取得し、復号するように要求され得るので不利であり得る。従って、本開示の技法は、ビデオプレゼンテーションフレームの不要な転送及び／又は復号なしに、ビデオアプリケーションをストリーミングするためのアクセスポイントの選択のための改善されたグラニュラリティを可能にする。
さらに、本開示の技法は、異なる複雑さのクライアント機器が、ＩＤＲアクセスポイントとＯＤＲアクセスポイントの両方を含むビデオフラグメント中でＩＤＲアクセスポイント又はＯＤＲアクセスポイントを選定することを可能にし得る。例えば、セグメントインデックスボックス６７０のＲＡＰタイプフィールド６０２は、フラグメントがＩＤＲアクセスポイントとＯＤＲアクセスポイントの両方を含んでいるかどうかをクライアント機器に示し得る。クライアント機器が、ＯＤＲアクセスポイントにおいて開始して受信／復号／再生するように構成された場合、クライアント機器は、復号／再生の開始のためのＯＤＲアクセスポイントを選定し得る。しかしながら、クライアント機器がＩＤＲアクセスポイントからのみ復号／再生を開始するように構成された場合、クライアント機器はＯＤＲアクセスポイントをスキップし、ＩＤＲアクセスポイントにおいて開始し得る。
本開示の様々な技法は、復号及び／又は再生にとって不要なデータの送信の低減をさらに可能にし得る。例えば、ＯＤＲピクチャのプレゼンテーション時間と合成時間（composition time）との間のタイミング差を（例えば、図６の例のデルタｄｔ ｐｔ６０４を介して）信号伝達することによって、ＯＤＲピクチャより前のサンプルのストリーミング及び／又は復号がスキップされ得る。従って、クライアント機器は、これらのサンプルを受信／復号する必要がなく、従って、ビデオプレゼンテーションを再生するために消費される帯域幅及び／又は処理能力の量を低減する。
別の例として、ムービーフラグメントの様々な態様のバイトオフセット（例えば、ヘッドオフセット６０７、デルタオフセット６０８、及び／又は遅いＩＤＲデルタオフセット６０９）を信号伝達することは、ランダムアクセスポイントより前のサンプルに対応するデータ、又は復号のために必要とされない他のデータの送信がスキップされることを可能にし得る。
別の例として、ビデオフラグメントのＩフレームのためのバイト範囲（例えば、Ｉフレームバイト範囲６１０、Ｉフレーム最大オフセット６１１）を信号伝達することによって、クライアント機器は、それらの望ましいフレームのみにビデオプレゼンテーションの高速バージョンを与えるように要求し得る。本技法は、ビデオプレゼンテーションの高速再生（例えば、早送り、早戻し）のために特定の表現が作成される必要がないので、ビデオ表現の高速バージョンを与えるための他の技法と比較して有益であり得る。代わりに、高速表現を与えるために既存のプレゼンテーションのフレームが使用され得る。さらに、（例えば、送信され、受信され、復号される）ビデオ表現の高速バージョンを与えるために必要とされるデータの量が低減され得る。
本開示の技法に一致するランダムアクセスポイントに関係する情報を信号伝達するように構成されたセグメントインデックスボックスを実装するために利用され得る擬似コードの別の例を、以下に提示する。
Figure 0005628422
上記の擬似コード例によれば、RAP_first_sampleは、メディアセグメンテーションの第１のサンプルがＲＡＰであるかどうかを示し得る。例えば、RAP_first_sampleは、参照エントリの第１のサンプルがＲＡＰであることを示す値１を有し得る。RAP_first_sampleは、参照の第１のサンプルがＲＡＰでないことを示す値０を有し得る。RAP_typeは、メディアセグメンテーション中に含まれているＲＡＰのタイプを示し得る。例えば、RAP_typeは、メディアセグメンテーションがＩＤＲ ＲＡＰを含んでいることを示す値０を有し得る。RAP_typeは、メディアセグメンテーションがＯＤＲ ＲＡＰを含んでいることを示す値１を有し得る。Delta_PTは、プレゼンテーション順序でＯＤＲ ＲＡＰの後の第１のサンプルのプレゼンテーション（合成）時間と復号時間との間の時間差を示し得る。Number_skip_samplesは、メディアセグメンテーションの第１のＲＡＰであり得るＯＤＲ ＲＡＰより前のプレゼンテーション時間とＯＤＲ ＲＡＰの後の分解時間とをもつサンプルの数を示し得る。
図６に示していない別の例では、ムービー表現のＭＰＤファイルは、ＯＤＲ ＲＡＰ及び／又はＩＤＲ ＲＡＰに関係する情報を信号伝達するように構成され得る。例えば、ＭＰＤは、バイナリフラグ値を備え得るシンタックス要素ＲＡＰＡｓＯＤＲを含み得る。ＲＡＰＡｓＯＤＲ値は、幾つかのランダムアクセスポイントがＯＤＲであるか否かを示すために設定され得る。即ち、幾つかの例では、ＲＡＰＡｓＯＤＲ値は、ＭＰＤに対応するビデオシーケンス中の少なくとも１つのランダムアクセスポイントがＯＤＲフレームであることを示す値「真」に設定され得るが、すべてのランダムアクセスポイントがＩＤＲフレームであることを示す値「偽」に設定され得る。
図７は、概して、本開示の技法に一致するＨＴＴＰクライアント機器を動作させる方法の一例を示すフローチャート図である。本方法は、クライアント機器（例えば、図１に示すＡ／Ｖ宛先機器４０）においてサーバ機器（例えば、図１に示すＡ／Ｖ発信源機器２０）から、メディアセグメンテーション（例えば、図３に示すオープンＧＯＰ３１０）のオープン復号リフレッシュランダムアクセスポイント（例えば、図３に示すフレーム３２０Ｉ）の指示を受信することを含む（７０１）。少なくとも１つのフレームのための符号化情報は、復号順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの少なくとも１つのフレームが正しく復号され得ないことと、表示順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの各フレームが、表示順序でＯＤＲ ＲＡＰより前のフレームのコンテンツに依拠することなしに、正しく復号され得ることとを示す。本方法は、クライアント機器が、示されたＯＤＲ ＲＡＰで開始するメディアデータのストリームを検索する少なくとも１つの要求をサーバ機器に送ることをさらに含む（７０２）。
図８は、本開示の技法に一致するＨＴＴＰサーバ機器を動作させる方法の一例を示すフローチャート図である。本方法は、メディアセグメンテーションのオープン復号リフレッシュ（ＯＤＲ）ランダムアクセスポイント（ＲＡＰ）フレームを備える符号化ビデオフレームのシーケンスを受信することを含む（８０１）。復号順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの少なくとも１つのフレームが正しく復号され得ず、表示順序でＯＤＲ ＲＡＰフレームに続くメディアセグメンテーションの各フレームが、表示順序でＯＤＲ ＲＡＰより前のフレームのコンテンツに依拠することなしに、正しく復号され得る。本方法は、ＯＤＲ ＲＡＰのロケーションの指示を生成することをさらに含む（８０２）。本方法は、指示を出力することをさらに含む（８０３）。
図９は、ビデオ表現の高速バージョンを与えるようにＨＴＴＰクライアント機器を動作させる方法の一例を示すフローチャート図である。本方法は、ビデオフラグメントの少なくとも１つのインター符号化フレーム（Ｉフレーム）のためのバイト範囲の指示を受信することを含む（９０１）。本方法は、少なくとも１つのＩフレームを受信したいという要求をサーバ機器に送ることをさらに含む（９０２）。本方法は、少なくとも１つのＩフレームを含むビデオ表現の高速バージョンを提示するために少なくとも１つの受信したＩフレームを使用することをさらに含む（９０３）。
図１０は、インター符号化フレーム（Ｉフレーム）のバイト範囲の指示を与えるためにＨＴＴＰサーバ機器を動作させる方法の一例を示すフローチャート図である。本方法は、少なくとも１つのインター符号化フレーム（Ｉフレーム）を備える符号化ビデオフレームのシーケンスを受信することを含む（１００１）。本方法は、少なくとも１つのＩフレームのためのバイト範囲の指示を生成することをさらに含む（１００２）。本方法は、少なくとも１つのＩフレームのためのバイト範囲の指示を出力することをさらに含む（１００３）。本方法は、バイト範囲の指示に基づいて少なくとも１つのＩフレームを送信したいという要求、例えば、ＨＴＴＰ ＧＥＴ要求又は部分ＧＥＴ要求を受信することをさらに含み得る。クライアント機器は、少なくとも１つのＩフレームを要求し、ビデオプレゼンテーションの高速バージョンを与えるために少なくとも１つのＩフレームを使用し得る。
図１１は、本開示の技法に一致する、それぞれのＨＴＴＰクライアント及びサーバ機器によって実行され得るステップの一例を示すフローチャートである。図１１に示すフローチャートは、これらの技法による、それぞれのクライアント機器とサーバ機器とによって実行され得るステップの一例として例示のために与えられるにすぎない。本開示の技法は、図１１に示すステップよりも多い又は少ないステップを同じく又は代わりに利用し得るか、若しくは図示及び記載の順序以外の他の順序で図示のステップを実行し得る。
概して、図１１の方法について、図１の要素に関して説明する。例えば、サーバによって実行されるものとして示されるステップは、発信源機器２０によって実行され得るが、クライアントによって実行されるものとして示されるステップは、宛先機器４０によって実行され得る。しかしながら、これらの指示は、例として与えられたものにすぎないことを理解されたい。概して、図１１の方法は、サーバ機器とクライアント機器との任意のペアによって実行され得る。
初めに、図１１に示すように、発信源機器２０のカプセル化ユニット３０は符号化ビデオデータを受信する（１１０１）。発信源機器２０は、インターネットなどのネットワーク接続を介して符号化ビデオデータを受信し得る。発信源機器２０は、代わりに又は追加として、発信源機器２０の内部又は外部にある１つ以上のストレージ機器から符号化ビデオデータを受信し得る。データは前に符号化され得るか、又はビデオエンコーダ２８がオンザフライでデータを符号化し得る。さらに別の例として、発信源機器２０は、ビデオゲームを実行するときなど、例えば、コンピュータ生成ビデオ情報のコンテキストにおいてデータを生成し得、ビデオエンコーダ２８は、生成されたビデオデータを符号化し得る。次いで、カプセル化ユニット３０は、受信したビデオデータをビデオフラグメント中にカプセル化する（１１０２）。
さらに、カプセル化ユニット３０は、ビデオフラグメントの１つ以上のＩＤＲ ＲＡＰとＯＤＲ ＲＡＰとの１つ以上のロケーションを信号伝達する（１１０３）。例えば、カプセル化ユニット３０は、ＯＤＲ ＲＡＰを含むメディアセグメンテーション（例えば、ビデオフラグメント）の第１のフレームと、ＯＤＲ ＲＡＰに対応するフレームとの間のオフセットを信号伝達し得る。メディアセグメンテーションの第１のフレームがＯＤＲ ＲＡＰであるとき、カプセル化ユニット３０はフラグを設定するか、又は第１のフレームがＯＤＲ ＲＡＰであることを示す他の情報を提供し得る。カプセル化ユニット３０は、ＯＤＲ ＲＡＰより前のプレゼンテーション時間を有するサンプルの数（例えば、フレームの数）をさらに信号伝達し得る。同様に、カプセル化ユニット３０は、メディアセグメンテーションがＩＤＲとＯＤＲの両方を含むかどうかを信号伝達し得る。さらに別の例として、カプセル化ユニット３０は、ＯＤＲ ＲＡＰに対応するバイトオフセットを信号伝達し得る。
宛先機器４０は、その後、例えば、メディアセグメンテーションを含む表現のヘッダ情報についての要求をサブミットすることによって、ランダムアクセスポイント信号伝達情報を要求する（１１０４）。例えば、その要求は、上記で説明したメディアプレゼンテーション記述（ＭＰＤ）ファイルについての要求であり得る。別の例では、その要求は、１つ以上のセグメンテーションファイルのセグメントインデックスボックス（ＳＩＤＸ）についての要求であり得る。その要求に応答して、発信源機器２０は、ステップ１１０３において作成されたＩＤＲ ＲＡＰとＯＤＲ ＲＡＰとの信号伝達されたロケーションを送る（１１０５）。
次いで、宛先機器４０は信号情報を受信する（１１０６）。その後、この例では、宛先機器４０は、ビデオ表現内の時間ロケーションにスキップしたいという要求を受信する（１１０７）。例えば、宛先機器は、ユーザから、ビデオ再生のための特定の時間（時間的）ロケーションにジャンプするための指示を受信し得る。別の例では、例えば、宛先機器がストリーミングのための帯域幅の変化又は他の条件変化を検出した場合、宛先機器自体が、時間ロケーションへのスキップを開始し、帯域幅の検出された変化又は他の条件変化に応答して、ビデオプログラムの代替表現を受信したいという要求を開始し得る。
時間ロケーションにスキップしたいという要求に応答して、宛先機器４０は、その時間ロケーションに最も近いランダムアクセスポイントを判断する（１１０８）。即ち、宛先機器４０は、要求された時間ロケーションに最も近いＲＡＰを識別するためにＲＡＰ信号情報を使用し得る。このＲＡＰを選択した後に、宛先機器４０は、判断されたＲＡＰにおいて開始するデータのストリームを開始したいという要求を生成し得る。例えば、宛先機器４０は、例えば、そのＲＡＰがフラグメントの第１のフレームであるとき、そのＲＡＰを含むフラグメント全体を検索するＨＴＴＰ ＧＥＴ要求を生成し得る。別の例として、宛先機器４０は、メディアセグメンテーション内のＲＡＰの開始バイトロケーションを判断するために、信号伝達された情報を使用し得る。例えば、メディアセグメンテーションがＮバイトの長さであり、ＲＡＰについてのデータがバイトＸにおいて開始すると仮定し、ただし、０＜Ｘ＜Ｎである。宛先機器４０は、ファイルの終了を通してＲＡＰに対応するデータを検索するために、バイト範囲（Ｘ，Ｎ）を規定するメディアセグメンテーションについてのＨＴＴＰ部分ＧＥＴ要求を生成し得る。
その上、様々な宛先機器は、信号伝達された情報を別様に使用するように構成され得る。例えば、幾つかの宛先機器は、ＩＤＲ ＲＡＰとＯＤＲ ＲＡＰとの間で選択するのに十分に高性能であり得る。一方、幾つかの宛先機器は、ＩＤＲ ＲＡＰについての要求の生成のみをサポートするように構成され得る。ＩＤＲ ＲＡＰとＯＤＲ ＲＡＰの両方を信号伝達することによって、本開示の技法は、レガシー機器、又は通常ならばＯＤＲ ＲＡＰを利用する能力がない機器を隔離又は除外することなしに、ストリームの開始点の選択のより微細なグラニュラリティを実装する能力をもつより高性能の機器を提供する。
要求を生成した後に、宛先機器４０は、要求を発信源機器２０に送る（１１０９）。要求を受信した（１１１０）後に、発信源機器２０は、ストリームの形態の要求に基づいてビデオデータを宛先機器４０に送ることによって応答する（１１１１）。説明及び理解を簡単にするために連続的に図示しているが、宛先機器４０は、ビデオデータのストリーム全体を受信したいという複数のＨＴＴＰ ＧＥＴ要求及び／又は部分ＧＥＴ要求を生成し得ることを理解されたい。いずれの場合も、ビデオデータを受信した後に、カプセル化解除ユニット３８はビデオデータをカプセル化解除し、ビデオデコーダ４８はデータを復号し、ビデオ出力４４はビデオデータを表示する（１１１２）。
図１２は、本開示の技法に一致する、それぞれのＨＴＴＰクライアント及びサーバ機器によって実行され得るステップの一例を示すフローチャート図である。図１２に示すフローチャートは、これらの技法による、それぞれのクライアント機器とサーバ機器とによって実行され得るステップの一例として例示のために与えられるにすぎない。本開示の技法は、図１２に示すステップよりも多い又は少ないステップを同じく又は代わりに利用し得るか、或いは図示及び記載の順序以外の他の順序で図示のステップを実行し得る。
概して、図１２の方法について、図１の要素に関して説明する。例えば、サーバによって実行されるものとして示されるステップは、発信源機器２０によって実行され得るが、クライアントによって実行されるものとして示されるステップは、宛先機器４０によって実行され得る。しかしながら、これらの指示は、例として与えられたものにすぎないことを理解されたい。概して、図１２の方法は、サーバ機器とクライアント機器との任意のペアによって実行され得る。
初めに、図１２に示すように、発信源機器２０のカプセル化ユニット３０は符号化ビデオデータを受信する（１２０１）。発信源機器２０は、インターネットなどのネットワーク接続を使用して符号化ビデオデータを受信し得る。発信源機器２０は、代わりに又は追加として、サーバ機器の内部又は外部にある１つ以上のストレージ機器から符号化ビデオデータを受信し得る。データは前に符号化され得るか、又はビデオエンコーダ２８がオンザフライでデータを符号化し得る。さらに別の例として、発信源機器２０は、ビデオゲームを実行するときなど、例えば、コンピュータ生成ビデオ情報のコンテキストにおいてデータを生成し得、ビデオエンコーダ２８は、生成されたビデオデータを符号化し得る。次いで、カプセル化ユニット３０は、受信したビデオデータをビデオフラグメント中にカプセル化する（１２０２）。
さらに、カプセル化ユニット３０は、少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含む符号化ビデオデータ内の少なくとも１つのバイト範囲を信号伝達する（１２０３）。例えば、カプセル化ユニット３０は、１つ以上のＩフレーム自体のためのバイト範囲（例えば、Ｉフレームのバイト範囲）を信号伝達し得る。１つのそのような例では、カプセル化ユニット３０は、符号化ビデオプレゼンテーションの第１のバイトからのバイトオフセットを信号伝達することによって、Ｉフレームのための開始点を信号伝達し得る。この例によれば、カプセル化ユニット３０は、符号化ビデオプレゼンテーションの第１のバイトからのバイトオフセットを信号伝達することによって、又はＩフレームの開始点からのバイトオフセットを信号伝達することによって、Ｉフレームのための終了点をさらに信号伝達し得る。別の例では、カプセル化ユニット３０は、少なくとも１つのＩフレーム、並びに他のインター符号化フレーム（例えば、Ｂフレーム及びＰフレーム）を含む符号化ビデオデータのバイト範囲を信号伝達し得る。
宛先機器４０は、Ｉフレーム信号情報についての要求を発信源機器２０に送る（１２０４）。Ｉフレーム信号情報についての要求は、１つ以上のセグメンテーションファイルについての一部又は全部のヘッダ情報についての要求を含み得る。例えば、その要求は、上記で説明したメディアプレゼンテーション記述（ＭＰＤ）ファイルについての要求であり得る。別の例では、その要求は、１つ以上のセグメンテーションファイルのセグメントインデックスボックス（ＳＩＤＸ）についての要求であり得る。その要求に応答して、発信源機器２０は、ステップ１２０３からの少なくとも１つのＩフレームを含む、信号伝達された１つ以上のバイト範囲を送る（１２０５）。宛先機器４０はＩフレーム信号情報を受信する（１２０６）。宛先機器４０は、（例えば、ユーザから、又は１つ以上のソフトウェアプログラムから）ビデオプレゼンテーションの高速バージョン（例えば、ビデオプレゼンテーションの早送り、巻戻し、又は早戻しバージョン）を再生したいという要求を受信する（１２０７）。一例では、要求は、ビデオプレゼンテーションの高速バージョンを提示するためにビデオ表現の再生を変更するための、ユーザからの指示を含み得る。
宛先機器は、高速再生のためのＩフレームを判断する（１２０８）。例えば、発信源機器２０が、１つ以上のＩフレーム自体のためのバイト範囲（例えば、Ｉフレームのバイト範囲）を信号伝達することによって、ステップ１２０３において少なくとも１つのバイト範囲を信号伝達した場合、宛先機器４０は、バイト範囲が信号伝達された複数のＩフレームのうちのいずれが高速再生のために使用される（例えば、送信され、復号される）べきかを判断することによって、高速再生のための１つ以上のＩフレームを判断し得る。別の例では、発信源機器が、少なくとも１つのＩフレーム並びに他のインター符号化フレーム（例えば、Ｂフレーム及びＰフレーム）を含むバイト範囲を信号伝達した場合、宛先機器は、１つ以上の信号伝達されたバイト範囲から、高速再生のために使用され得るＩフレームを判断し得る。宛先機器４０は、ステップ１２０８において判断された１つ以上のＩフレームを含むメディアデータをストリーミングしたいという要求を発信源機器２０に送る（１２０９）。その要求は、セグメンテーションファイル（例えば、ムービーフラグメント、セグメント、及び／又は表現）と、その要求に応答してストリーミングされるべきそのセグメンテーションファイルの所望のバイト範囲とを識別する部分ＧＥＴ要求であり得る。
発信源機器２０は、メディアデータをストリーミングしたいという要求を受信する（１２１０）。その要求に応答して、発信源機器２０は、ストリーム要求に基づいてメディアデータをストリーミングする（１２１１）。宛先機器４０は、その要求に応答して、受信したビデオデータを復号し、ビデオ表現の高速（例えば、早送り、巻戻し、早戻し）バージョンとして、受信したビデオデータを表示する（１２１２）。幾つかの例では、発信源機器は、ビデオ表現の高速バージョンを与えるために使用するために、ステップ１２０８において判断されたメディアデータのみを復号し得る。一例では、宛先機器４０は、ステップ１２０１においてサーバによって受信された符号化メディアデータ中で少なくとも１つのインター符号化フレームだけ時間的に分離された、検索されたメディアデータの２つ以上のＩフレームを連続的に提示することによって、ビデオ表現の高速バージョンを提示し得る。
１つ以上の例では、説明した機能は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組合せで実装され得る。ソフトウェアで実装した場合、機能は、１つ以上の命令又はコードとしてコンピュータ可読媒体上に記憶されるか、或いはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、例えば、通信プロトコルに従ってある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含むデータ記憶媒体又は通信媒体など、有形媒体に対応するコンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は、概して、（１）非一時的である有形コンピュータ可読記憶媒体、或いは（２）信号又は搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明した技法の実装のための命令、コード及び／又はデータ構造を検索するために１つ以上のコンピュータ或いは１つ以上のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品はコンピュータ可読媒体を含み得る。
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ又は他の光ディスクストレージ、磁気ディスクストレージ、又は他の磁気ストレージ機器、フラッシュメモリ、或いは命令又はデータ構造の形態の所望のプログラムコードを記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の媒体を備えることができる。さらに、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。例えば、命令が、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、又は赤外線、無線、及びマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、又は他のリモート発信源から送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、又は赤外線、無線、及びマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。ただし、コンピュータ可読記憶媒体及びデータ記憶媒体は、接続、搬送波、信号、又は他の一時媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用するディスク（disk）及びディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザディスク（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピーディスク（disk）及びブルーレイ（登録商標）ディスク（disc）を含み、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲内に含めるべきである。
命令は、１つ以上の中央処理ユニット（ＣＰＵ）、デジタル信号プロセッサ（ＤＳＰ）などの１つ以上のプロセッサ、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、或いは他の等価な集積回路又はディスクリート論理回路によって実行され得る。従って、本明細書で使用する「プロセッサ」という用語は、前述の構造、又は本明細書で説明した技法の実装に好適な他の構造のいずれかを指し得る。さらに、幾つかの態様では、本明細書で説明した機能は、符号化及び復号のために構成された専用のハードウェア及び／又はソフトウェアモジュール内に提供され得、或いは複合コーデックに組み込まれ得る。また、本技法は、１つ以上の回路又は論理要素中に十分に実装され得る。
本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）又はＩＣのセット（例えば、チップセット）を含む、多種多様な機器又は装置において実施され得る。本開示では、開示する技法を実行するように構成された機器の機能的態様を強調するために様々な構成要素、モジュール、又はユニットについて説明したが、それらの構成要素、モジュール、又はユニットを、必ずしも異なるハードウェアユニットによって実現する必要はない。むしろ、上記で説明したように、様々なユニットが、好適なソフトウェア及び／又はファームウェアとともに、上記で説明したように１つ以上のプロセッサを含んで、コーデックハードウェアユニットにおいて組み合わせられるか、又は相互動作ハードウェアユニットの集合によって与えられ得る。
様々な例について説明した。これら及び他の例は以下の特許請求の範囲内に入る。
以下に本件出願当初の特許請求の範囲に記載された発明を付記する。
［１］ クライアント機器がサーバ機器から、第１の再生速度で表示されるように構成されたビデオプレゼンテーションを表すメディアセグメンテーション内の少なくとも１つのバイト範囲の指示を受信することと、前記クライアント機器が、前記少なくとも１つのバイト範囲内のメディアデータを検索する要求を前記サーバ機器に送ることと、前記第１の再生速度よりも速い第２の再生速度で前記少なくとも１つのＩフレームを含むビデオ表現の高速バージョンを提示するために、前記少なくとも１つのバイト範囲内の検索された前記メディアデータを使用することと、を備え、少なくとも１つのイントラコード化フレーム（Ｉフレーム）が前記少なくとも１つのバイト範囲内で生じる、方法。
［２］ メディアデータを検索する前記要求が、前記メディアセグメンテーション内の前記少なくとも１つのバイト範囲内で生じるＩフレームのみを検索する要求を備える、［１］に記載の方法。
［３］ 前記少なくとも１つのＩフレームを含むビデオプレゼンテーションの高速バージョンを提示するために前記少なくとも１つのバイト範囲内の検索された前記メディアデータを使用することは、検索された前記メディアデータの２つ以上のＩフレームを連続的に提示することを含み、前記２つ以上のＩフレームが少なくとも１つのインター符号化フレームだけ時間的に分離される、［１］に記載の方法。
［４］ 前記少なくとも１つのＩフレームを含むビデオプレゼンテーションの高速バージョンを提示するために前記少なくとも１つのバイト範囲内の検索された前記メディアデータを使用することが、前記ビデオプレゼンテーションの早送り又は早戻しバージョンを提示することを備える、［１］に記載の方法。
［５］ 前記少なくとも１つのバイト範囲の前記指示を受信することが、前記メディアセグメンテーションの第１のバイトから前記メディアセグメンテーションの第１のＩフレームの最後のバイトまでのバイト範囲の指示を受信することを備える、［１］に記載の方法。
［６］ 前記少なくとも１つのバイト範囲の前記指示を受信することが、最大バイトオフセットを受信することを含み、前記最大バイトオフセットは、複数のメディアセグメンテーションが少なくとも１つのＩフレームを含むバイト範囲を示す、［１］に記載の方法。
［７］ 前記要求が、前記メディアセグメンテーション内の前記少なくとも１つのバイト範囲によって示された前記ストリームを検索するためバイト範囲の指示を含むハイパーテキスト転送プロトコル（ＨＴＴＰ）Ｇｅｔ要求である、［１］に記載の方法。
［８］ クライアント機器にが、サーバ機器から、第１の再生速度で表示されるように構成されたビデオプレゼンテーションを表すメディアセグメンテーション内の少なくとも１つのバイト範囲の指示を受信するための手段と、前記クライアント機器が、前記少なくとも１つのバイト範囲内のメディアデータを検索する要求を前記サーバ機器に送るための手段と、前記第１の再生速度よりも速い第２の再生速度で前記少なくとも１つのＩフレームを含むビデオ表現の高速バージョンを提示するために、前記少なくとも１つのバイト範囲内の検索された前記メディアデータを使用するための手段と、を備え、少なくとも１つのイントラコード化フレーム（Ｉフレーム）が前記少なくとも１つのバイト範囲内で生じる、機器。
［９］ メディアデータを検索する前記要求が、前記メディアセグメンテーション内の前記少なくとも１つのバイト範囲内で生じるＩフレームのみを検索する要求を備える、［８］に記載の機器。
［１０］ ビデオプレゼンテーションの高速バージョンを提示するために前記少なくとも１つのバイト範囲内の検索された前記メディアデータを使用するための前記手段が、検索された前記メディアデータの２つ以上のＩフレームを連続的に提示し、前記２つ以上のＩフレームが少なくとも１つのインター符号化フレームだけ時間的に分離される、［８］に記載の機器。
［１１］ ビデオプレゼンテーションの高速バージョンを提示するために前記少なくとも１つのバイト範囲内の検索された前記メディアデータを使用するための前記手段が、前記ビデオプレゼンテーションの早送り又は早戻しバージョンを提示する、［８］に記載の機器。
［１２］ 前記少なくとも１つのバイト範囲の前記指示を受信するための前記手段が、前記メディアセグメンテーションの第１のバイトから前記メディアセグメンテーションの第１のＩフレームの最後のバイトまでのバイト範囲の指示を受信する、［８］に記載の機器。
［１３］ 前記少なくとも１つのバイト範囲の前記指示を受信するための前記手段が最大バイトオフセットを受信し、前記最大バイトオフセットは、複数のメディアセグメンテーションが少なくとも１つのＩフレームを含むバイト範囲を示す、［８］に記載の機器。
［１４］ 前記要求が、前記メディアセグメンテーション内の前記少なくとも１つのバイト範囲によって示された前記ストリームを検索するためバイト範囲の指示を含むハイパーテキスト転送プロトコル（ＨＴＴＰ）Ｇｅｔ要求である、［８］に記載の機器。
［１５］ コンピューティング機器に、クライアント機器がサーバ機器から、第１の再生速度で表示されるように構成されたビデオプレゼンテーションを表すメディアセグメンテーション内の少なくとも１つのバイト範囲の指示を受信することと、前記クライアント機器が、前記少なくとも１つのバイト範囲内のメディアデータを検索する要求を前記サーバ機器に送ることと、前記第１の再生速度よりも速い第２の再生速度で前記少なくとも１つのＩフレームを含むビデオ表現の高速バージョンを提示するために、前記少なくとも１つのバイト範囲内の検索された前記メディアデータを使用することと、を行わせるように構成された命令を記憶し、少なくとも１つのイントラコード化フレーム（Ｉフレーム）が前記少なくとも１つのバイト範囲内で生じる、コンピュータ可読記憶媒体。
［１６］ 前記命令が、前記コンピューティング機器に、前記メディアセグメンテーション内の前記少なくとも１つのバイト範囲内で生じるＩフレームのみを検索することを要求することを行わせる、［１４］に記載のコンピュータ可読記憶媒体。
［１７］ 前記命令が、前記コンピューティング機器に、検索された前記メディアデータの２つ以上のＩフレームを連続的に提示することによって、前記少なくとも１つのＩフレームを含むビデオプレゼンテーションの高速バージョンを提示することを行わせ、前記２つ以上のＩフレームが少なくとも１つのインター符号化フレームだけ時間的に分離される、［１４］に記載のコンピュータ可読記憶媒体。
［１８］ 前記命令が、前記コンピューティング機器に、前記ビデオプレゼンテーションの早送り又は早戻しバージョンを提示するために、前記少なくとも１つのバイト範囲内の検索された前記メディアデータを使用することを行わせる、［１４］に記載のコンピュータ可読記憶媒体。
［１９］ 前記少なくとも１つのバイト範囲の前記指示が、前記メディアセグメンテーションの第１のバイトから前記メディアセグメンテーションの第１のＩフレームの最後のバイトまでのバイト範囲の指示を備える、［１４］に記載のコンピュータ可読記憶媒体。
［２０］ 前記少なくとも１つのバイト範囲の前記指示が最大バイトオフセットを備え、前記最大バイトオフセットは、複数のメディアセグメンテーションが少なくとも１つのＩフレームを含むバイト範囲を示す、［１４］に記載のコンピュータ可読記憶媒体。
［２１］ 前記要求が、前記メディアセグメンテーション内の前記少なくとも１つのバイト範囲によって示された前記ストリームを検索するためバイト範囲の指示を含むハイパーテキスト転送プロトコル（ＨＴＴＰ）Ｇｅｔ要求である、［１４］に記載のコンピュータ可読記憶媒体。
［２２］ 第１の再生速度で表示されるように構成されたビデオプレゼンテーションを表すメディアセグメンテーション内の少なくとも１つのバイト範囲の指示を受信することと、前記少なくとも１つのバイト範囲内のメディアデータを検索する要求をサーバ機器に送ることと、前記第１の再生速度よりも速い第２の再生速度で前記少なくとも１つのＩフレームを含むビデオ表現の高速バージョンを提示するために、前記少なくとも１つのバイト範囲内の検索された前記メディアデータを使用することと、を行うように構成され、少なくとも１つのイントラコード化フレーム（Ｉフレーム）が前記少なくとも１つのバイト範囲内で生じる、少なくとも１つのプロセッサを備える、機器。
［２３］ メディアデータを検索する前記要求が、前記メディアセグメンテーション内の前記少なくとも１つのバイト範囲内で生じるＩフレームのみを検索するための要求を備える、［２２］に記載の機器。
［２４］ 前記少なくとも１つのプロセッサは、検索された前記メディアデータの２つ以上のＩフレームを連続的に提示することによって、前記少なくとも１つのＩフレームを含むビデオプレゼンテーションの高速バージョンを提示するために前記少なくとも１つの受信したＩフレームを使用するように構成され、前記２つ以上のＩフレームが少なくとも１つのインター符号化フレームだけ時間的に分離される、［２２］に記載の機器。
［２５］ 前記少なくとも１つのプロセッサが、前記ビデオ表現の早送り又は早戻しバージョンを提示するために前記少なくとも１つの受信したＩフレームを使用するように構成された、［２２］に記載の機器。
［２６］ 前記少なくとも１つのバイト範囲の前記指示が、前記メディアセグメンテーションの第１のバイトから前記メディアセグメンテーションの第１のＩフレームの最後のバイトまでのバイト範囲の指示を備える、［２２］に記載の機器。
［２７］ 前記少なくとも１つのバイト範囲の前記指示が最大バイトオフセットを備え、前記最大バイトオフセットは、複数のメディアセグメンテーションが少なくとも１つのＩフレームを含むバイト範囲を示す、［２２］に記載の機器。
［２８］ 前記要求が、前記メディアセグメンテーション内の前記少なくとも１つのバイト範囲によって示された前記ストリームを検索するためバイト範囲の指示を含むハイパーテキスト転送プロトコル（ＨＴＴＰ）Ｇｅｔ要求である、［２２］に記載の機器。
［２９］ 少なくとも１つのインター符号化フレーム（Ｉフレーム）を備える符号化ビデオフレームのシーケンスを受信することと、符号化ビデオフレームの前記シーケンス内のバイト範囲の指示を生成することと、符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示を出力することと、を備え、少なくとも１つのＩフレームが前記少なくとも１つのバイト範囲内で生じる、方法。
［３０］ 前記バイト範囲によって示された符号化ビデオフレームの前記シーケンスの一部分を検索する要求を受信することと、前記要求に応答して、前記バイト範囲によって示された符号化ビデオフレームの前記シーケンスの前記一部分を出力することとをさらに備える、［２９］に記載の方法。
［３１］ 前記要求が、符号化ビデオフレームの前記シーケンス内の前記バイト範囲のフレームを検索するため前記バイト範囲の指示を含むハイパーテキスト転送プロトコル（ＨＴＴＰ）ＧＥＴ要求を備える、［３０］に記載の方法。
［３２］ 符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示が、符号化ビデオフレームの前記シーケンスの１つ以上のＩフレームのみのバイト範囲を示す、［２９］に記載の方法。
［３３］ 前記バイト範囲によって示された符号化ビデオフレームの前記シーケンスの一部分を検索する要求を受信することと、前記要求に応答して、前記バイト範囲によって示された符号化ビデオフレームの前記シーケンスの前記１つ以上のＩフレームのみを出力することとをさらに備える、［３２］に記載の方法。
［３４］ 符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示が、前記メディアセグメンテーションの第１のバイトから前記メディアセグメンテーションの第１のＩフレームの最後のバイトまでのバイト範囲を備える、［２９］に記載の方法。
［３５］ 符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示が最大バイトオフセットを備え、前記最大バイトオフセットは、複数のメディアセグメンテーションが少なくとも１つのＩフレームを含むバイト範囲を示す、［２９］に記載の方法。
［３６］ 少なくとも１つのインター符号化フレーム（Ｉフレーム）を備える符号化ビデオフレームのシーケンスを受信するための手段と、符号化ビデオフレームの前記シーケンス内のバイト範囲の指示を生成するための手段と、符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示を出力するための手段と、を備え、少なくとも１つのＩフレームが前記少なくとも１つのバイト範囲内で生じる、機器。
［３７］ 前記バイト範囲によって示された符号化ビデオフレームの前記シーケンスの一部分を検索する要求を受信するための手段と、前記要求に応答して、前記バイト範囲によって示された符号化ビデオフレームの前記シーケンスの前記一部分を出力するための手段とをさらに備える、［３６］に記載の機器。
［３８］ 前記要求が、符号化ビデオフレームの前記シーケンス内の前記バイト範囲のフレームを検索するため前記バイト範囲の指示を含むハイパーテキスト転送プロトコル（ＨＴＴＰ）ＧＥＴ要求を備える、［３７］に記載の機器。
［３９］ 符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示が、符号化ビデオフレームの前記シーケンスの１つ以上のＩフレームのみのバイト範囲を示す、［３６］に記載の機器。
［４０］ 前記バイト範囲によって示された符号化ビデオフレームの前記シーケンスの一部分を検索する要求を受信するための手段と、前記要求に応答して、前記バイト範囲によって示された符号化ビデオフレームの前記シーケンスの前記１つ以上のＩフレームのみを出力するための手段とをさらに備える、［３９］に記載の機器。
［４１］ 符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示が、前記メディアセグメンテーションの第１のバイトから前記メディアセグメンテーションの第１のＩフレームの最後のバイトまでのバイト範囲を備える、［３９］に記載の機器。
［４２］ 符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示が最大バイトオフセットを備え、前記最大バイトオフセットは、複数のメディアセグメンテーションが少なくとも１つのＩフレームを含むバイト範囲を示す、［３９］に記載の機器。
［４３］ コンピューティング機器に、少なくとも１つのＩフレームを備える符号化ビデオフレームのシーケンスを受信することと、バイト範囲の指示を生成することと、符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示を出力することと、を行わせるように構成された命令を記憶し、少なくとも１つのＩフレームが前記少なくとも１つのバイト範囲内で生じる、コンピュータ可読記憶媒体。
［４４］ 符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示が、符号化ビデオフレームの前記シーケンスの１つ以上のＩフレームのみのバイト範囲を示す、［４３］に記載のコンピュータ可読記憶媒体。
［４５］ 符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示が、前記メディアセグメンテーションの第１のバイトから前記メディアセグメンテーションの第１のＩフレームの最後のバイトまでのバイト範囲を備える、［４３］に記載のコンピュータ可読記憶媒体。
［４６］ 符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示が最大バイトオフセットを備え、前記最大バイトオフセットは、複数のメディアセグメンテーションが少なくとも１つのＩフレームを含むバイト範囲を示す、［４３］に記載のコンピュータ可読記憶媒体。
［４７］ 少なくとも１つのＩフレームを備える符号化ビデオフレームのシーケンスを受信することと、符号化ビデオフレームの前記シーケンス内のバイト範囲の指示を生成することと、符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示を出力することと、を行うように構成され、少なくとも１つのＩフレームが前記少なくとも１つのバイト範囲内で生じる、１つ以上のプロセッサを備える機器。
［４８］ 符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示が、符号化ビデオフレームの前記シーケンスの１つ以上のＩフレームのみのバイト範囲を示す、［４７］に記載のコンピュータ可読記憶媒体。
［４９］ 符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示が、前記メディアセグメンテーションの第１のバイトから前記メディアセグメンテーションの第１のＩフレームの最後のバイトまでのバイト範囲を備える、［４７］に記載のコンピュータ可読記憶媒体。
［５０］ 符号化ビデオフレームの前記シーケンス内のバイト範囲の前記指示が最大バイトオフセットを備え、前記最大バイトオフセットは、複数のメディアセグメンテーションが少なくとも１つのＩフレームを含むバイト範囲を示す、［４７］に記載のコンピュータ可読記憶媒体。

Claims (50)

  1. クライアント機器がサーバ機器から、１つ以上のフラグメントのフレームのための最大バイトオフセットの指示を受信することと、前記最大バイトオフセットは、前記フラグメントが少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含むフラグメントのバイト範囲を表す、
    前記クライアント機器が、前記指示に基づいて前記バイト範囲に対応する前記１つ以上のフラグメントのうちの少なくとも１つからメディアデータを検索する要求を前記サーバ機器に送ることと、
    第１の再生速度よりも速い第２の再生速度で少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含むビデオプレゼンテーションの高速バージョンを提示するために、前記バイト範囲内の検索された前記メディアデータを使用することと、
    を備え、前記１つ以上のフラグメントが、前記第１の再生速度で表示されるように構成された前記ビデオプレゼンテーションを表し、前記少なくとも１つのＩフレームが、前記１つ以上のフラグメントの各々における前記バイト範囲内で生じる、方法。
  2. メディアデータを検索する前記要求が、前記メディアセグメント内の前記バイト範囲内で生じるＩフレームのみを検索する要求を含む、請求項１に記載の方法。
  3. 前記少なくとも１つのＩフレームを含むビデオプレゼンテーションの高速バージョンを提示するために前記バイト範囲内の検索された前記メディアデータを使用することは、
    検索された前記メディアデータの２つ以上のＩフレームを連続的に提示することを含み、前記２つ以上のＩフレームが少なくとも１つのイントラ符号化フレームだけ時間的に分離される、請求項１に記載の方法。
  4. 前記少なくとも１つのＩフレームを含むビデオプレゼンテーションの高速バージョンを提示するために前記バイト範囲内の検索された前記メディアデータを使用することが、前記ビデオプレゼンテーションの早送りまたは巻戻しバージョンを提示することを備える、請求項１に記載の方法。
  5. 前記指示に基づいて前記複数のセグメントの各々から前記バイト範囲に対応するメディアデータを検索する要求を送ることをさらに備える、請求項１に記載の方法。
  6. 前記要求が、前記１つ以上のフラグメントの各々の第１のバイトと前記最大バイトオフセットとによって定義されたバイト範囲を指定する部分ＧＥＴ要求を備える、請求項５に記載の方法。
  7. 前記要求が、前記メディアセグメント内の前記バイト範囲によって示された前記ストリームを検索するため前記バイト範囲の指示を含むハイパーテキスト転送プロトコル（ＨＴＴＰ）Ｇｅｔ要求である、請求項１に記載の方法。
  8. クライアント機器が、サーバ機器から、１つ以上のフラグメントのフレームのための最大バイトオフセットの指示を受信するための手段と、前記最大バイトオフセットは、前記フラグメントが少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含むフラグメントのバイト範囲を表す、
    前記クライアント機器が、前記指示に基づいて前記バイト範囲に対応する前記１つ以上のフラグメントのうちの少なくとも１つからメディアデータを検索する要求を前記サーバ機器に送るための手段と、
    第１の再生速度よりも高い第２の再生速度で少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含むビデオプレゼンテーションの高速バージョンを提示するために前記バイト範囲内の検索された前記メディアデータを使用するための手段と、
    を備え、前記１つ以上のフラグメントが、前記第１の再生速度で表示されるように構成された前記ビデオプレゼンテーションを表し、前記少なくとも１つのＩフレームが、前記１つ以上のフラグメントの各々における前記バイト範囲内で生じる、機器。
  9. メディアデータを検索する前記要求が、前記メディアセグメント内の前記バイト範囲内で生じるＩフレームのみを検索する要求を備える、請求項８に記載の機器。
  10. ビデオプレゼンテーションの高速バージョンを提示するために前記バイト範囲内の検索された前記メディアデータを使用するための前記手段が、検索された前記メディアデータの２つ以上のＩフレームを連続的に提示し、前記２つ以上のＩフレームが少なくとも１つのイントラ符号化フレームだけ時間的に分離される、請求項８に記載の機器。
  11. ビデオプレゼンテーションの高速バージョンを提示するために前記バイト範囲内の検索された前記メディアデータを使用するための前記手段が、前記ビデオプレゼンテーションの早送りまたは早戻しバージョンを提示する、請求項８に記載の機器。
  12. 前記指示に基づいて前記複数のセグメントの各々から前記バイト範囲に対応するメディアデータを検索する要求を送るための手段をさらに備える、請求項８に記載の機器。
  13. 前記要求が、前記１つ以上のフラグメントの各々の第１のバイトと前記最大バイトオフセットとによって定義された前記バイト範囲を指定する部分ＧＥＴ要求を備える、請求項１２に記載の機器。
  14. 前記要求が、前記メディアセグメント内のバイト範囲によって示された前記ストリームを検索するため前記バイト範囲の指示を含むハイパーテキスト転送プロトコル（ＨＴＴＰ）Ｇｅｔ要求である、請求項８に記載の機器。
  15. コンピューティング機器に、
    クライアント機器がサーバ機器から、１つ以上のフラグメントのフレームのための最大バイトオフセットの指示を受信することと、前記最大バイトオフセットは、前記フラグメントが少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含むフラグメントのバイト範囲を表す、
    前記クライアント機器が、前記指示に基づいて前記バイト範囲に対応する前記１つ以上のフラグメントのうちの少なくとも１つからメディアデータを検索する要求を前記サーバ機器に送ることと、
    第１の再生速度よりも速い第２の再生速度で少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含むビデオプレゼンテーションの高速バージョンを提示するために、前記バイト範囲内の検索された前記メディアデータを使用することと、
    を行わせるように構成された命令を記憶し、前記１つ以上のフラグメントが、前記第１の再生速度で表示されるように構成された前記ビデオプレゼンテーションを表し、前記少なくとも１つのＩフレームが、前記１つ以上のフラグメントの各々における前記バイト範囲内で生じる、コンピュータ可読記憶媒体。
  16. 前記命令が、前記コンピューティング機器に、
    前記メディアセグメント内の前記バイト範囲内で生じるＩフレームのみを検索することを要求させる、請求項１５に記載のコンピュータ可読記憶媒体。
  17. 前記命令が、前記コンピューティング機器に、
    検索された前記メディアデータの２つ以上のＩフレームを連続的に提示することによって、前記少なくとも１つのＩフレームを含むビデオプレゼンテーションの高速バージョンを提示することを行わせ、前記２つ以上のＩフレームが少なくとも１つのイントラ符号化フレームだけ時間的に分離される、請求項１５に記載のコンピュータ可読記憶媒体。
  18. 前記命令が、前記コンピューティング機器に、
    前記ビデオプレゼンテーションの早送りまたは早戻しバージョンを提示するために、前記バイト範囲内の検索された前記メディアデータを使用させる、請求項１５に記載のコンピュータ可読記憶媒体。
  19. 前記コンピューティング機器に、前記指示に基づいて前記複数のセグメントの各々から前記バイト範囲に対応するメディアデータを検索する要求を送らせる命令をさらに備える、請求項１５に記載のコンピュータ可読記憶媒体。
  20. 前記要求が、前記１つ以上のフラグメントの各々の第１のバイトと前記最大バイトオフセットとによって定義されたバイト範囲を指定する部分ＧＥＴ要求を備える、請求項１９に記載のコンピュータ可読記憶媒体。
  21. 前記要求が、前記メディアセグメント内の前記バイト範囲によって示された前記ストリームを検索するため前記バイト範囲の指示を含むハイパーテキスト転送プロトコル（ＨＴＴＰ）Ｇｅｔ要求である、請求項１５に記載のコンピュータ可読記憶媒体。
  22. １つ以上のフラグメントのフレームのための最大バイトオフセットの指示を受信することと、前記最大バイトオフセットは、前記フラグメントが少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含むフラグメントのバイト範囲を表す、
    前記バイト範囲内のメディアデータを検索する要求をサーバ機器に送ることと、
    第１の再生速度よりも速い第２の再生速度で少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含む前記ビデオプレゼンテーションの高速バージョンを提示するために、前記バイト範囲内の検索された前記メディアデータを使用することと、
    を行うように構成され、前記フラグメントは前記第１の再生速度で表示されるように構成されたビデオプレゼンテーションを表し、前記少なくとも１つのＩフレームが前記バイト範囲内で生じる、少なくとも１つのプロセッサを備える、機器。
  23. メディアデータを検索する前記要求が、前記メディアセグメント内の前記バイト範囲内で生じるＩフレームのみを検索する要求を備える、請求項２２に記載の機器。
  24. 前記少なくとも１つのプロセッサは、検索された前記メディアデータの２つ以上のＩフレームを連続的に提示することによって、前記少なくとも１つのＩフレームを含むビデオプレゼンテーションの高速バージョンを提示するために前記少なくとも１つの受信したＩフレームを使用するように構成され、前記２つ以上のＩフレームが少なくとも１つのイントラ符号化フレームだけ時間的に分離される、請求項２２に記載の機器。
  25. 前記プロセッサが、前記ビデオプレゼンテーションの早送りまたは巻戻しバージョンを提示するために前記少なくとも１つの受信したＩフレームを使用するように構成された、請求項２２に記載の機器。
  26. 前記バイト範囲の前記指示が、前記メディアセグメントの第１のバイトから前記メディアセグメントの第１のＩフレームの最後のバイトまでのバイト範囲の指示を備える、請求項２２に記載の機器。
  27. 前記バイト範囲の前記指示が最大バイトオフセットを備え、前記最大バイトオフセットは、複数のメディアセグメントが少なくとも１つのＩフレームを含むバイト範囲を示す、請求項２２に記載の機器。
  28. 前記要求が、前記メディアセグメント内のバイト範囲によって示された前記ストリームを検索するため前記バイト範囲の指示を含むハイパーテキスト転送プロトコル（ＨＴＴＰ）Ｇｅｔ要求である、請求項２２に記載の機器。
  29. 複数のフラグメントの各々が、少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を備える符号化ビデオフレームのそれぞれのシーケンスを備える前記フラグメントを受信することと、
    前記複数のフラグメントのための最大バイトオフセットを決定するために、前記フラグメントの前記イントラ符号化フレームの最後のバイトに対するバイトオフセットの最大値を決定することと、前記最大バイトオフセットは、前記フラグメントが少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含むフラグメントのバイト範囲を表す、
    前記複数のフラグメント内のバイト範囲を定義する前記最大バイトオフセットの指示を生成することと、
    前記最大バイトオフセットの前記指示を出力することと、
    を備え、少なくとも１つのＩフレームが前記複数のフラグメントの各々における前記バイト範囲内で生じる、方法。
  30. 前記バイト範囲に対応する符号化ビデオフレームの前記シーケンスの一部分を検索する要求を受信することと、
    前記要求に応答して、前記バイト範囲に対応する符号化ビデオフレームの前記シーケンスの前記一部分を出力することと、
    をさらに備える、請求項２９に記載の方法。
  31. 前記要求が、符号化ビデオフレームの前記シーケンス内の前記バイト範囲のフレームを検索するため前記バイト範囲の指示を含むハイパーテキスト転送プロトコル（ＨＴＴＰ）ＧＥＴ要求を備える、請求項３０に記載の方法。
  32. 符号化ビデオフレームの前記シーケンス内の前記バイト範囲が、前記複数のフラグメントのうちの少なくとも１つにおける複数の符号化ビデオフレームの個別のシーケンスの１つ以上のＩフレームのみに対応する、請求項２９に記載の方法。
  33. 前記バイト範囲に対応する符号化ビデオフレームの前記シーケンスの一部分を検索する要求を受信することと、
    前記要求に応答して、前記複数のメディアフラグメントのうちの前記少なくとも１つの前記バイト範囲に対応する符号化ビデオフレームの前記シーケンスの前記１つ以上のＩフレームのみを出力することと、
    をさらに備える、請求項３２に記載の方法。
  34. 前記最大バイトオフセットの前記指示が、前記複数のフラグメントのうちの１つの符号化ビデオフレームの前記シーケンス内のバイト範囲の最後のバイトに対応し、前記バイト範囲が、前記複数のフラグメントのうちの前記１つの第１のバイトから前記複数のフラグメントのうちの前記１つの第１のＩフレームの最後のバイトまでのバイト範囲を備える、請求項２９に記載の方法。
  35. 前記複数のフラグメントの各々のための前記最大バイトオフセットによって定義された前記バイト範囲を指定する要求を受信することと、
    前記要求に応答して、前記複数のフラグメントの各々から前記最大バイトオフセットによって定義された前記バイト範囲のメディアデータを出力することと、
    をさらに備える、請求項２９に記載の方法。
  36. 複数のフラグメントを受信するための手段と、前記複数のフラグメントの各々が、少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を備える符号化ビデオフレームのそれぞれのシーケンスを備える、
    前記複数のフラグメントのための最大バイトオフセットを決定するために、前記複数のフラグメントの前記イントラ符号化フレームの最後のバイトに対するバイトオフセットの最大値を決定するための手段と、前記最大バイトオフセットは、前記フラグメントが少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含むフラグメントのバイト範囲を表す、
    前記複数のフラグメント内のバイト範囲を定義する前記最大バイトオフセットの指示を生成するための手段と、
    前記最大バイトオフセットの前記指示を出力するための手段と、
    を備え、少なくとも１つのＩフレームが前記複数のフラグメントの各々における前記バイト範囲内で生じる、機器。
  37. 前記バイト範囲に対応する符号化ビデオフレームの前記シーケンスの一部分を検索する要求を受信するための手段と、
    前記要求に応答して、前記バイト範囲に対応する符号化ビデオフレームの前記シーケンスの前記一部分を出力するための手段と、をさらに備える、請求項３６に記載の機器。
  38. 前記要求が、符号化ビデオフレームの前記シーケンス内の前記バイト範囲のフレームを検索するため前記バイト範囲の指示を含むハイパーテキスト転送プロトコル（ＨＴＴＰ）ＧＥＴ要求を備える、請求項３７に記載の機器。
  39. 符号化ビデオフレームの前記シーケンス内の前記バイト範囲が、前記複数のフラグメントのうちの少なくとも１つにおける複数の符号化ビデオフレームの個別のシーケンスの１つ以上のＩフレームのみに対応する、請求項３６に記載の機器。
  40. 前記バイト範囲に対応する符号化ビデオフレームの前記シーケンスの一部分を検索する要求を受信するための手段と、
    前記要求に応答して、前記複数のフラグメントのうちの前記少なくとも１つの前記バイト範囲に対応する符号化ビデオフレームの前記シーケンスの前記１つ以上のＩフレームのみを出力するための手段と、
    をさらに備える、請求項３９に記載の機器。
  41. 前記最大バイトオフセットの前記指示が、前記複数のフラグメントのうちの１つの符号化ビデオフレームの前記シーケンス内のバイト範囲の最後のバイトに対応し、前記バイト範囲が、前記複数のフラグメントのうちの前記１つの第１のバイトから前記複数のフラグメントのうちの前記１つの第１のＩフレームの最後のバイトまでのバイト範囲を備える、請求項３９に記載の機器。
  42. 前記複数のフラグメントの各々のための前記最大バイトオフセットによって定義された前記バイト範囲を指定する要求を受信するための手段と、
    前記要求に応答して、前記複数のフラグメントの各々から前記最大バイトオフセットによって定義された前記バイト範囲のメディアデータを出力するための手段と、
    をさらに備える、請求項３９に記載の機器。
  43. コンピューティング機器に、
    複数のフラグメントの各々が、少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を備える複数の符号化ビデオフレームの個別のシーケンスを備える前記複数のフラグメントを受信することと、
    前記複数のフラグメントのための最大バイトオフセットを決定するために、前記複数のフラグメントの前記イントラ符号化フレームの最後のバイトに対するバイトオフセットの最大値を決定することと、前記最大バイトオフセットは、前記フラグメントが少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含むフラグメントのバイト範囲を表す、
    前記複数のフラグメント内のバイト範囲を定義する前記最大バイトオフセットの指示を生成することと、
    前記最大バイトオフセットの前記指示を出力することと、
    を行わせるように構成された命令を記憶し、少なくとも１つのＩフレームが前記複数のフラグメントの各々における前記バイト範囲内で生じる、コンピュータ可読記憶媒体。
  44. 符号化ビデオフレームの前記シーケンス内の前記バイト範囲が、前記複数のフラグメントのうちの少なくとも１つにおける複数の符号化ビデオフレームの個別のシーケンスの１つ以上のＩフレームのみに対応する、請求項４３に記載のコンピュータ可読記憶媒体。
  45. 前記最大バイトオフセットの前記指示が、前記複数のフラグメントのうちの１つの符号化ビデオフレームの前記シーケンス内のバイト範囲の最後のバイトに対応し、前記バイト範囲が、前記複数のフラグメントのうちの前記１つの第１のバイトから前記複数のフラグメントのうちの前記１つの第１のＩフレームの最後のバイトまでのバイト範囲を備える、請求項４３に記載のコンピュータ可読記憶媒体。
  46. 前記コンピューティング機器に、
    前記複数のフラグメントの各々のための前記最大バイトオフセットによって定義された前記バイト範囲を指定する要求を受信することと、
    前記要求に応答して、前記複数のフラグメントの各々から前記最大バイトオフセットによって定義された前記バイト範囲のメディアデータを出力することと、
    を行わせる命令をさらに備える、請求項４３に記載のコンピュータ可読記憶媒体。
  47. 複数のフラグメントの各々が、少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を備える複数の符号化ビデオフレームの個別のシーケンスを備える前記複数のフラグメントを受信することと、
    前記複数のフラグメントのための最大バイトオフセットを決定するために、前記複数のフラグメントの前記イントラ符号化フレームの最後のバイトに対するバイトオフセットの最大値を決定することと、前記最大バイトオフセットは、前記フラグメントが少なくとも１つのイントラ符号化フレーム（Ｉフレーム）を含むフラグメントのバイト範囲を表す、
    前記複数のフラグメント内のバイト範囲を定義する前記最大バイトオフセットの指示を生成することと、
    前記最大バイトオフセットの前記指示を出力することと、
    を行うように構成され、少なくとも１つのＩフレームが前記複数のフラグメントの各々における前記バイト範囲内で生じる、１つ以上のプロセッサを備える機器。
  48. 符号化ビデオフレームの前記シーケンス内の前記バイト範囲が、前記複数のフラグメントのうちの少なくとも１つにおける複数の符号化ビデオフレームの個別のシーケンスの１つ以上のＩフレームのみに対応する、請求項４７に記載の機器。
  49. 前記最大バイトオフセットの前記指示が、前記複数のフラグメントのうちの１つの符号化ビデオフレームの前記シーケンス内のバイト範囲の最後のバイトに対応し、前記バイト範囲が、前記複数のフラグメントのうちの前記１つの第１のバイトから前記複数のフラグメントのうちの前記１つの第１のＩフレームの最後のバイトまでのバイト範囲を備える、請求項４７に記載の機器。
  50. 前記１つ以上のプロセッサが、前記複数のフラグメントの各々のための前記最大バイトオフセットによって定義された前記バイト範囲を指定する要求を受信することと、前記要求に応答して、前記複数のフラグメントの各々から前記最大バイトオフセットによって定義された前記バイト範囲のメディアデータを出力することとを行うように構成された、請求項４７に記載の機器。
JP2013518668A 2010-06-29 2011-06-29 トリックモードビデオ表現のためのビデオサンプルを信号伝達すること Active JP5628422B2 (ja)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US35974810P 2010-06-29 2010-06-29
US61/359,758 2010-06-29
US36388410P 2010-07-13 2010-07-13
US61/363,884 2010-07-13
US36643610P 2010-07-21 2010-07-21
US61/366,436 2010-07-21
US12/908,593 2010-10-20
US12/908,593 US9485546B2 (en) 2010-06-29 2010-10-20 Signaling video samples for trick mode video representations
PCT/US2011/042447 WO2012003237A1 (en) 2010-06-29 2011-06-29 Signaling video samples for trick mode video representations

Publications (2)

Publication Number Publication Date
JP2013535866A JP2013535866A (ja) 2013-09-12
JP5628422B2 true JP5628422B2 (ja) 2014-11-19

Family

ID=44543758

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013518668A Active JP5628422B2 (ja) 2010-06-29 2011-06-29 トリックモードビデオ表現のためのビデオサンプルを信号伝達すること

Country Status (5)

Country Link
EP (1) EP2589222B1 (ja)
JP (1) JP5628422B2 (ja)
KR (1) KR101421390B1 (ja)
CN (1) CN103081488B (ja)
WO (1) WO2012003237A1 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6021385B2 (ja) * 2012-03-30 2016-11-09 エヌ・ティ・ティ・コミュニケーションズ株式会社 ストリーミングメディア再生装置、ストリーミングメディア再生方法、及びプログラム
US20150067744A1 (en) * 2013-08-27 2015-03-05 Home Box Office, Inc. Providing responsive video previews during rewind and fast forward
CN103957471B (zh) * 2014-05-05 2017-07-14 华为技术有限公司 网络视频播放的方法和装置
KR101600469B1 (ko) * 2014-07-16 2016-03-07 김재경 스트리밍 서비스를 위한 클라이언트 및 서버의 동작 방법
US9538137B2 (en) 2015-04-09 2017-01-03 Microsoft Technology Licensing, Llc Mitigating loss in inter-operability scenarios for digital video
US10924820B2 (en) * 2015-08-07 2021-02-16 Mediatek Inc. Method and apparatus of bitstream random access and synchronization for multimedia applications
US9893877B2 (en) * 2016-01-15 2018-02-13 Analog Devices Global Circuits, systems, and methods for synchronization of sampling and sample rate setting
US10623755B2 (en) * 2016-05-23 2020-04-14 Qualcomm Incorporated End of sequence and end of bitstream NAL units in separate file tracks
CN111859159A (zh) * 2020-08-05 2020-10-30 上海连尚网络科技有限公司 信息推送、视频处理方法和设备
US20220103883A1 (en) * 2020-09-30 2022-03-31 Synamedia Limited Broadcast In-Home Streaming

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060037057A1 (en) * 2004-05-24 2006-02-16 Sharp Laboratories Of America, Inc. Method and system of enabling trick play modes using HTTP GET
US20070157267A1 (en) * 2005-12-30 2007-07-05 Intel Corporation Techniques to improve time seek operations
EP4213033A1 (en) * 2007-01-05 2023-07-19 DivX, LLC Video distribution system including progressive playback
US20080168516A1 (en) * 2007-01-08 2008-07-10 Christopher Lance Flick Facilitating Random Access In Streaming Content
EP2046044B1 (en) * 2007-10-01 2017-01-18 Cabot Communications Ltd A method and apparatus for streaming digital media content and a communication system
US7979570B2 (en) * 2008-05-12 2011-07-12 Swarmcast, Inc. Live media delivery over a packet-based computer network
KR101019634B1 (ko) * 2008-09-04 2011-03-07 에스케이 텔레콤주식회사 미디어 전송 시스템 및 방법
US9538142B2 (en) * 2009-02-04 2017-01-03 Google Inc. Server-side support for seamless rewind and playback of video streaming

Also Published As

Publication number Publication date
JP2013535866A (ja) 2013-09-12
EP2589222A1 (en) 2013-05-08
EP2589222B1 (en) 2021-02-24
WO2012003237A1 (en) 2012-01-05
CN103081488A (zh) 2013-05-01
KR101421390B1 (ko) 2014-07-18
KR20130050958A (ko) 2013-05-16
CN103081488B (zh) 2017-02-15

Similar Documents

Publication Publication Date Title
JP5596228B2 (ja) ビデオデータをストリーミングするためのランダムアクセスポイントに信号伝達すること
JP6345827B2 (ja) ビデオデータをストリーミングするためのシーケンスデータセットを提供すること
JP5770345B2 (ja) ビデオデータをストリーミングするためのビデオ切替え
JP6392115B2 (ja) ビデオ構成要素を多重化するためのデータを信号伝達すること
JP5628422B2 (ja) トリックモードビデオ表現のためのビデオサンプルを信号伝達すること
CN109155876B (zh) 一种检索视频数据的方法、装置、设备及可读存储媒体
WO2013036450A1 (en) Network streaming of coded video data
CN109076264B (zh) 样本条目和随机存取
KR101436267B1 (ko) 비디오 구성요소들을 멀티플렉싱하기 위한 데이터의 시그널링

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130531

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130531

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140114

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140414

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140507

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140807

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20141001

R150 Certificate of patent or registration of utility model

Ref document number: 5628422

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

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