JP2017522767A - ビデオビットストリームにおけるランダムアクセス - Google Patents

ビデオビットストリームにおけるランダムアクセス Download PDF

Info

Publication number
JP2017522767A
JP2017522767A JP2016568609A JP2016568609A JP2017522767A JP 2017522767 A JP2017522767 A JP 2017522767A JP 2016568609 A JP2016568609 A JP 2016568609A JP 2016568609 A JP2016568609 A JP 2016568609A JP 2017522767 A JP2017522767 A JP 2017522767A
Authority
JP
Japan
Prior art keywords
picture
drap
irap
random access
rap
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.)
Pending
Application number
JP2016568609A
Other languages
English (en)
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 JP2017522767A publication Critical patent/JP2017522767A/ja
Pending legal-status Critical Current

Links

Classifications

    • 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/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • 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/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/107—Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
    • 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/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/132—Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • 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/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/164—Feedback from the receiver or from the transmission channel
    • 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/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • 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/30—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H04N19/31—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability in the temporal domain
    • 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/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • 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/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/58—Motion compensation with long-term prediction, i.e. the reference frame for a current frame not being the temporally closest one
    • 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/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
    • 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/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H04N21/6379—Control signals issued by the client directed to the server or network components directed to server directed to encoder, e.g. for requesting a lower encoding rate
    • 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
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103—Selection of coding mode or of prediction mode
    • H04N19/114—Adapting the group of pictures [GOP] structure, e.g. number of B-frames between two anchor frames

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本実施形態は、ビデオビットストリームにおいて、ランダムアクセスオペレーションのために使用することができるがIRAPピクチャと比較して低いビットコストでの符号化の形式で表すことが可能な新しいタイプのランダムアクセスポイントを導入する。ランダムアクセスポイントは、該DRAPピクチャに対する独占的な参照ピクチャとしてIRAPピクチャを用いて符号化または復号化される依存性ランダムポイント（DRAP）ピクチャである。DRAPピクチャは、参照のために使用される可能性があり、ビデオビットストリームにおいてランダムアクセスポイントを構成するトレーリングピクチャとして符号化される。【選択図】図16

Description

本実施形態は、一般的にはビデオプロセッシングに関し、特に、ビデオビットストリームにおけるランダムアクセスオペレーションに関する。
インターネット、ブロードキャストネットワーク、およびモバイルネットワークを介して送信されるビデオデータの量は、年々増加している。この傾向は、 Netflix,、Hulu、およびYouTube（登録商標）等のover-the-top（OTT）サービスの利用、並びに、高品質のビデオおよびよりフレキシブルなTV観覧方法および他のビデオサービスに対する要求の増加により押し上げられている。
ビデオに対する増加するビットレートの要求を維持するために、有効なビデオ圧縮を有することが重要である。近年、MPEGと協力するJCT-VCは、その前身のAVC/H.264と比較して、同じ品質に対して半分のビットレートを効率的にカットする、高効率ビデオ符号化（HEVC（high efficiency video coding））バージョン1を開発した。
H.265とも参照されるHEVCは、ブロックベースのビデオ符号化であり、時間的および空間的な予想を両方利用する。空間的な予想は、現在のピクチャ内からのイントラ（I）予想を用いて達成される。イントラ符号化されたブロックを構成するピクチャは、I-ピクチャと参照される。時間的な予想は、ブロックレベルにおいて、ユニプレディクティブ予想とも参照されるインター予想（P）、または、バイプレディクティブ予想とも参照される双方向インター予想（B）を用いて達成される。インター予想において、予想は、単一の先に復号化されたピクチャから実施される。双方向予想において、予想は、同じ先に復号化されたピクチャまたは2つの異なる先に復号化されたピクチャのいずれかを参照し得る2つの予想の組み合わせから実施される。先に復号化されたピクチャは、現在のピクチャの前に復号化され、表示時間（出力時間）において現在のピクチャの前または後に現れ得る。少なくとも一つのインター符号化ブロックを含むが、双方向符号化インターブロックを含まないピクチャは、P-ピクチャと参照される。少なくとも一つの双方向インターブロックを構成するピクチャは、B-ピクチャとして参照される。P-ピクチャとB-ピクチャは、イントラ符号化されたブロックも含み得る。典型的なブロックに対しては、イントラ符号化は、バイプレディクティブ符号化より一般的にコストがかかるインター符号化に比べて、一般的にビットコストがかなりかかる。
瞬間復号更新（instantaneous decoding refresh（IDR））ピクチャは、次のピクチャがIDRピクチャの前にピクチャを参照しないI-ピクチャである。クリーンランダムアクセス（clean random access（CRA））ピクチャは、I-ピクチャであり、ランダムアクセススキップリーディング（RASL）ピクチャに、復号化の順序でCRAピクチャに続き、出力の順序でディスプレイにおけるDRAピクチャに先行するピクチャを参照することを許容する。CRAピクチャで復号化を開始する場合、CRAピクチャがランダムアクセスのために使用される場合に、RASLピクチャは、予想に対して利用可能とならなくてもよいCRAピクチャに先行するピクチャから予想されることが許容されるので、RASLピクチャは、外されなければならない。ブロークンリンクアクセス（Broken link access （BLA））ピクチャは、ビットストリームにおいて、接続（splicing）ポイントを示すために使用されるI-ピクチャである。ビットストリーム接続オペレーションは、最初のビットストリームにおけるCRAピクチャのピクチャタイプをBLAピクチャに変更し、他のビットストリームにおける好適な位置においてストリームを連結することにより実施することができる。
イントラランダムアクセスポイント（（intra random access point）IRAP）ピクチャは、IDR、CRA、またはBLAピクチャのいずれかであり得る。全てのIRAPピクチャは、復号化および出力の順序の両方においてIRAPに続くピクチャは、復号化の順序においてIRAPピクチャの前のあらゆるピクチャを参照しないことを保証する。ビットストリームの最初のピクチャは、IRAPピクチャである必要があるが、ビットストリームに渡って多くの他のIRAPピクチャが存在し得る。IRAPピクチャは、例えば、TVを観るときや一つのTVチャネルから別のチャネルに切り替えるときに、ビデオストリームへアクセスするための可能性を提供する。IRAPピクチャはまた、例えばビデオプレーヤーのコントロールバーを用いてプレイ位置を動かすことにより、ビデオクリップを探すため、および、およびダイナミックストリーミングサービスにも使用され得る。更に、IRAPピクチャは、ビットストリームにおけるエラーまたは損失が存在する場合に、ビデオのリフレッシュ（更新）を提供し、それによりビデオビットストリームのエラー耐性が向上する。
デジタルTVは、一般的にブロードキャスティングサービスと参照される地上波、衛星およびケーブルの3つの形態、および、一般的にマルチキャストサービスと参照されるインターネットプロトコルテレビ（IPTV）の1つの形態が存在する。これらのサービスの全てにおいて、受信器は1つのTVチャネルのビデオビットストリームを受信し、それは復号化され、復号化されたビデオはエンドユーザに表示される。受信器がさらに、チャネル／プログラムを後に観覧する能力を有するユーザに供給するために受信された、1つ以上の追加的なチャネルのビデオビットストリームを受信できることは一般的である。
アダプティブストリーミングサービスにおいて、受信器に受信されるビットレートは、ネットワークの能力に適合するように調整される。ハイパーテキストプロトコル（HTTP）（DACH）、HTTPライブストリーミング（HLS）およびスムース（smooth）ストリーミングを介したダイナミックな適応的ストリーミングサービスにおいて、ユーザクライアントは、サーバから提供された異なる表現のセットから、典型的に10秒のビデオを表現するチャンクまたはセグメントに渡るビットレートを選択する。
ビデオ会議サービスおよびビデオ電話サービスにおいて、ユーザクライアント間の2方向通信が存在する。復号化されたピクチャにおけるパケット損失または破損を示すフィードバックメッセージを使用することが可能である。参照ピクチャ選択表示（Reference Picture Selection Indication（RPSI））は、受信器に対して、一つ以上の最近に送信されたピクチャは復号化されていない可能性があることから、古いピクチャが参照のために使用されるべきであることを示すことを可能にするフィードバックメッセージである。参照として、先のIRAPピクチャ等の正しく受信され復号化された古いピクチャを使用することにより、符号器は、新しいイントラピクチャを送信する必要がなくなる。しかしながら、RPSI等のフィードバックメッセージを送信した後、受信器は、いつ送信側がそのメッセージを認識し、参照のための選択された参照ピクチャのみを使用したかを把握できない。
ブロードキャストサービスおよびマルチキャストサービスにおいて、できるだけ短いチャネル切り替え時間を維持することが望まれている。しかしながら、別のチャネルに切り替えるために、当該別のチャネルのビデオビットストリームにおけるランダムアクセスポイント（random access point（RAP））が存在する必要がある。しかしながら、RAPとしてIRAPピクチャを使用することにより、ビデオビットストリームを符号化することがよりコスト高になり、結果として、イントラピクチャを必要としないビデオビットストリームと比較して実質的にビットレートを増加させる。
アダプティブストリーミングでは、一つの表現から別の表現に切り替えるために、ユーザクライアントが切り替えるために選択した表現におけるアクセスポイントが存在する必要がある。これは、今日ではIRAPピクチャを伴って実現化される。IRAPピクチャはまた、ユーザが、ビデオストリームにおいて異なる位置にジャンプするために使用する際に使用される。これらのIRAPピクチャは、IRAPピクチャを含まないビデオビットストリームと比較して、実質的にビットレートを増加させる。
一般的には、効率的なビデオ処理を提供することを目的とする。
特に、ビデオビットストリームにおける効率的なランダムアクセスオペレーションを可能とすることを目的とする。
これらの目的および他の目的は、以下に開示する実施形態により達成される。
実施形態の観点は、ビデオビットストリームにおいてランダムアクセスオペレーションを実行するための方法に関する。方法は、依存性ランダムアクセスポイント（dependent random access point（DRAP））ピクチャを取得することを含む。DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリング（trailing）ピクチャとして符号化される。方法はまた、ビデオビットストリームのイントラランダムアクセスポイント（IRAP）ピクチャを取得することを含む。方法は更に、IRAPピクチャを復号化することと、IRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャを復号化することを含む。方法は追加的に、復号化されたDRAPピクチャにおいてランダムアクセスオペレーションを実行することを含む。
実施形態の関連する観点は、DRAPピクチャを取得するために構成されたユーザクライアントを定義する。DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化される。ユーザクライアントは、ビデオビットストリームのIRAPピクチャを取得するように構成される。ユーザクライアントは更に、IRAPピクチャを復号化することと、IRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャを復号化するように構成される。ユーザクライアントは追加的に、復号化されたDRAPピクチャにおいてランダムアクセスオペレーションを実行するように構成される。
実施形態の別の関連する観点は、DRAPピクチャとIRAPピクチャを取得するためにピクチャ供給器を有するユーザクライアントを定義する。DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化される。ユーザクライアントは更に、IRAPピクチャを復号化し、IRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャを復号化するための復号器を有する。ユーザクライアントはさらに、復号化されたDRAPピクチャにおいてランダムアクセスオペレーションを実行するためのランダムアクセス部を有する。
実施形態の別の観点は、ユーザクライアントへの通信チャネル上で少なくとも1つのIRAPピクチャを含むビデオビットストリームを送信することを含むビデオ通信方法を定義する。方法は、ユーザクライアントからのフィードバックチャネル上でフィードバックメッセージを受信することを含む。フィードバックメッセージは、ユーザクライアントにおいて破損または損失したピクチャに対応するビデオビットストリーム内の位置を示す。方法は更に、フィードバックメッセージに基づいて、ビデオビットストリームにおける先のIRAPピクチャとDRAPピクチャに対する独占的な参照ピクチャとして用いてDRAPピクチャを符号化することを含む。DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化される。方法は追加的に、ユーザクライアントへDRAPピクチャを送信することを含む。
実施形態の関連する観点は、ユーザクライアントへの通信チャネル上で少なくとも1つのIRAPピクチャを含むビデオビットストリームを送信するように構成されたビデオ通信サーバを定義する。ビデオ通信サーバは、ユーザクライアントからのフィードバックチャネル上でフィードバックメッセージを受信するようにも構成される。フィードバックメッセージは、ユーザクライアントにおいて破損または損失したピクチャに対応するビデオビットストリーム内の位置を示す。ビデオ通信サーバは更に、フィードバックメッセージに基づいて、ビデオビットストリームにおける先のIRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして用いてDRAPピクチャを符号化するように構成される。DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化される。ビデオ通信サーバは追加的に、ユーザクライアントへDRAPピクチャを送信するように構成される。
実施形態の別の観点は、ユーザクライアントへの通信チャネル上で少なくとも1つのIRAPピクチャを含むビデオビットストリームを送信する送信器を有するビデオ通信システムを定義する。ビデオ通信サーバは、ユーザクライアントからのフィードバックチャネル上でフィードバックメッセージを受信するための受信器も含む。フィードバックメッセージは、ユーザクライアントにおいて破損または損失したピクチャに対応するビデオビットストリーム内の位置を示す。ビデオ通信サーバは更に、フィードバックメッセージに基づいて、ビデオビットストリームにおける先のIRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして用いてDRAPピクチャを符号化するための符号器を有する。DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化される。送信器は、ユーザクライアントへDRAPピクチャを送信するためのものでもある。
実施形態の別の観点は、ピクチャのビデオストリームをビデオビットストリームに符号化するための方法に関する。方法は、ビデオストリームにおいてn番目毎のピクチャをRAPピクチャとして符号化し、ビデオストリームにおいて他のピクチャを非RAPピクチャとして符号化することを含む。n番目毎のピクチャの符号化は、m番目毎のRAPピクチャをIRAPピクチャとして符号化し、他のRAPピクチャを、復号化の順序に従って各最も近接して先行するIRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャとして符号化することにより、n番目毎のピクチャを符号化することを含む。各DRAPピクチャは、トレーリングピクチャとして符号化され、ビデオビットストリームにおけるランダムアクセスポイントを構成する。
実施形態のさらに別の観点は、ピクチャのビデオストリームをビデオビットストリームに符号化するための方法に関する。方法は、ビデオストリームにおいてn番目毎のピクチャをRAPピクチャとして符号化し、ビデオストリームにおいて他のピクチャを非RAPピクチャとして符号化することを含む。n番目毎のピクチャを符号化することは、少なくともRAPピクチャのサブセットに対して、IRAPピクチャとして、またはDRAPピクチャとしてRAPピクチャを符号化することの間のビットコスト差に基づいて、RAPピクチャがIRAPピクチャとして符号化されるかDRAPピクチャとして符号化されるかを決定（判定）することにより、n番目毎のピクチャを符号化することを含む。DRAPピクチャは、復号化の順序に従って、各最も近接して先行するIRAPピクチャを、DRAPピクチャに対する独占的な参照ピクチャとして用いて符号化される。DRAPピクチャは、トレーリングピクチャとして符号化され、ビデオビットストリームにおけるランダムアクセスポイントを構成する。
実施形態の関連する観点は、ピクチャのビデオストリームをビデオビットストリームに符号化するための符号器を定義する。符号器はビデオストリームにおいてn番目毎のピクチャをRAPピクチャとして符号化し、ビデオストリームにおいて他のピクチャを非RAPピクチャとして符号化するように構成される。符号器はまた、m番目毎のRAPピクチャをIRAPピクチャとして符号化し、他のRAPピクチャを、復号化の順序に従って各最も近接して先行するIRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャとして符号化することにより、n番目毎のピクチャを符号化するように構成される。各DRAPピクチャは、トレーリングピクチャとして符号化され、ビデオビットストリームにおけるランダムアクセスポイントを構成する。
実施形態の別の関連する観点は、ピクチャのビデオストリームをビデオビットストリームに符号化するための符号器を定義する。符号器はビデオストリームにおいてn番目毎のピクチャをRAPピクチャとして符号化し、ビデオストリームにおいて他のピクチャを非RAPピクチャとして符号化するように構成される。符号器はまた、少なくともRAPピクチャのサブセットに対して、IRAPピクチャとして、またはDRAPピクチャとしてRAPピクチャを符号化することの間のビットコスト差に基づいて、RAPピクチャがIRAPピクチャとして符号化されるかDRAPピクチャとして符号化されるかを決定（判定）することにより、n番目毎のピクチャを符号化するように構成される。DRAPピクチャは、復号化の順序に従って、各最も近接して先行するIRAPピクチャを、DRAPピクチャに対する独占的な参照ピクチャとして用いて符号器により符号化される。DRAPピクチャは、トレーリングピクチャとして符号化され、ビデオビットストリームにおけるランダムアクセスポイントを構成する。
実施形態のさらに別の観点は、命令を含むコンピュータプログラムに関する。当該命令は、プロセッサにより実行された場合に、当該プロセッサに、参照として使用される可能性がありビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化されるDRAPピクチャを取得させる。プロセッサにはまた、ビデオビットストリームのIRAPピクチャを取得させる。プロセッサには更に、IRAPピクチャを復号化させ、IRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャを復号化させる。プロセッサには追加的に、復号化されたDRAPピクチャにおいてランダムアクセスオペレーションを実行させる。
実施形態のさらなる観点は、命令を含むコンピュータプログラムに関する。当該命令は、プロセッサにより実行された場合に、当該プロセッサに、ユーザクライアントへの通信チャネル上で少なくとも1つのIRAPピクチャを含むビデオビットストリームを送信させる。プロセッサにはまた、ユーザクライアントからのフィードバックチャネル上でフィードバックメッセージを受信させる。フィードバックメッセージは、ユーザクライアントにおいて破損または損失したピクチャに対応するビデオビットストリーム内の位置を示す。プロセッサには更に、フィードバックメッセージに基づいて、ビデオビットストリームにおける先のIRAPピクチャとDRAPピクチャに対する独占的な参照ピクチャとして用いてDRAPピクチャを符号化させる。DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化される。プロセッサには追加的に、ユーザクライアントへDRAPピクチャを送信させる。
実施形態の更なる別の観点は、命令を含むコンピュータプログラムに関する。当該命令は、プロセッサにより実行された場合に、当該プロセッサにn番目毎のピクチャをRAPピクチャとして符号化させ、ビデオストリームにおいて他のピクチャを非RAPピクチャとして符号化させる。プロセッサにはまた、m番目毎のRAPピクチャをIRAPピクチャとして符号化させ、他のRAPピクチャを、復号化の順序に従って各最も近接して先行するIRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャとして符号化させることにより、n番目毎のピクチャを符号化させる。各DRAPピクチャは、トレーリングピクチャとして符号化され、ビデオビットストリームにおけるランダムアクセスポイントを構成する。
実施形態の更なる別の観点は、命令を含むコンピュータプログラムに関する。当該命令は、プロセッサにより実行された場合に、当該プロセッサにn番目毎のピクチャをRAPピクチャとして符号化させ、ビデオストリームにおいて他のピクチャを非RAPピクチャとして符号化させる。プロセッサにはまた、少なくともRAPピクチャのサブセットに対して、IRAPピクチャとして、またはDRAPピクチャとしてRAPピクチャを符号化することの間のビットコスト差に基づいて、RAPピクチャがIRAPピクチャとして符号化されるかDRAPピクチャとして符号化されるかを決定（判定）することにより、n番目毎のピクチャを符号化させる。DRAPピクチャは、復号化の順序に従って、各最も近接して先行するIRAPピクチャを、DRAPピクチャに対する独占的な参照ピクチャとして用いる符号器により符号化される。DRAPピクチャは、トレーリングピクチャとして符号化され、ビデオストリームにおけるランダムアクセスポイントを構成する。
実施形態の関連する観点は、上記の実施形態に従うコンピュータプログラムを有するキャリアを定義する。キャリアは、電子信号、光学信号、電磁気信号、磁気信号、電気信号、無線信号、マイクロ波信号、またはコンピュータ読み取り可能な記憶媒体のうちのいずれかである。
本実施形態は、ランダムアクセスオペレーションを実行するために使用されるビデオビットストリームにおける新しいタイプのRAPピクチャを提供する。そのようなRAPピクチャは、先のIRAPピクチャを独占的な参照ピクチャとして使用して符号化および復号化することを暗示するDRAPピクチャである。結果として、DRAPピクチャは、IRAPピクチャと比較して顕著に低いビットコストにおいて表されるが、それでも、ビデオビットストリームにおいてRAPを構成し、それにより、ビデオビットストリーム内でランダムアクセスオペレーションを実行するために使用することができる。
実施形態は、その目的と利点を伴い、付属の図面と共に以下の説明を参照して最も良く理解され得る。
図1は、実施形態に従うランダムアクセスオペレーションを実行するための方法を示すフローチャートである。 図2は、図1における取得ステップの実施形態を示すフローチャートである。 図3は、図1における取得ステップの別の実施形態を示すフローチャートである。 図4は、図1に示す方法の、追加的、オプション的なステップを示すフローチャートである。 図5は、図1における取得ステップの更なる実施形態を示すフローチャートである。 図6は、図1における取得ステップの更なる別の実施形態を示すフローチャートである。 図7は、実施形態に従うビデオ通信方法を示すフローチャートである。 図8は、図7に示す方法の、追加的、オプション的なステップを示すフローチャートである。 図9は、実施形態に従うビデオストリームを符号化するための方法を示すフローチャートである。 図10は、図9における符号化ステップの実施形態を示すフローチャートである。 図11は、図9における符号化ステップの別の実施形態を示すフローチャートである。 図12は、現在のHEVC規格を用いたランダムアクセス構成を伴うビデオビットストリームを概略的に示す。 図13は、DRAPピクチャを用いたランダムアクセス構成を伴うビデオビットストリームを概略的に示す。 図14は、従来のIRAPアプローチを用いたスクリーンコンテンツの例を示す。 図15は、DRAPピクチャを用いたチャネル切り替えの例をを示す。 図16は、アダプティブストリーミングに対する実施可能なシナリオを表すシグナリング図である。 図17は、ライブストリーミングと会話のサービスに対する実施可能なシナリオを表すシグナリング図である。 図18は、実施形態に従う符号器と復号器の概略図である。 図19は、実施形態に従うユーザクライアントの概略ブロック図である。 図20は、別の実施形態に従うユーザクライアントの概略ブロック図である。 図21は、更なる実施形態に従うユーザクライアントの概略ブロック図である。 図22は、実施形態に従うビデオ通信サーバの概略ブロック図である。 図23は、別の実施形態に従うビデオ通信サーバの概略ブロック図である。 図24は、更なる実施形態に従うビデオ通信サーバの概略ブロック図である。 図25は、実施形態に従う符号器の概略ブロック図である。 図26は、実施形態に従うコンピュータプログラム実装を概略的に示す。
図面を通して、同様または対応する要素に対しては、同じ参照番号が用いられる。
本実施形態は、一般的にはビデオプロセッシングに関し、特に、ビデオビットストリームにおけるランダムアクセスオペレーションに関する。
実施形態では、ビデオ符号化および復号化内で、ランダムアクセスポイント（RAP）に関して新しいコンセプトが導入される。実施形態のRAPピクチャは、ビデオストリームにおいて従来RAPとして使用されているIRAPピクチャとは異なる。IRAPピクチャは、独立して復号化可能である。すなわち、あらゆる参照ピクチャを使用しない。実施形態のRAPは、依存性ランダムアクセスポイント（DRAP（dependent random access point））ピクチャの形式の依存性のRAPである。従って、実施形態のDRAPピクチャは、独立して復号化可能ではない。すなわち、DRAPピクチャは、少なくとも1つの参照ピクチャを使用するが、まだビデオビットストリーム内でRAPを構成する。DRAPピクチャは、符号化され、IRAPピクチャと比較して顕著に少ないビットを用いて表すことが可能である。従って、実施形態のDRAPピクチャは、ビデオビットストリームの全体のビットコストを削減するために使用され得る。または、全体のビットコストを増加させずにビデオビットストリームにおけるRAPの全体の数を増加させるために用いられ得る。
DRAPピクチャは、どの参照ピクチャが使用できるかについてDRAPピクチャはかなり制限されているという点で、他の非IRAPピクチャとは異なる。これらの制約により、DRAPピクチャはランダムアクセスオペレーションに対して使用することが可能となる。ランダムアクセスオペレーションは、ビデオビットストリームの最初から復号化が開始されない場合である。代わりに、ランダムアクセスポイントとして識別されるポイントにおけるビットストリーム内のいくつかの位置において復号化が開始される。ランダムアクセスオペレーションの例は、ブロードキャストされたTVストリームにチューニングすること、すなわち、TVを観ることを開始すること、または、あるTVチャネルを別のチャネルに切り替える場合を含む。
結果として、実施形態のDRAPピクチャは、ビデオビットストリームに導入することが可能であり、ランダムアクセスオペレーションを実行するためではあるが、ランダムアクセスを可能にするために、IRAPピクチャを用いるより、ビットの数に関してより少ないコストで使用される。
図1は、実施形態に従う、ビデオビットストリームにおけるランダムアクセスオペレーションを実行するため方法を示すフローチャートである。方法は、DRAPピクチャを取得することを含むステップS1で開始する。DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャ（trailing picture）として符号化される。次のステップS2は、ビデオビットストリームのIRAPピクチャを取得することを含む。IRAPはステップS3で復号化され、DRAPピクチャは、IRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してステップS4で復号化される。次のステップS5は、復号化されたDRAPピクチャにおいてランダムアクセスオペレーションを実行することを含む。
ステップS1からS3は、ステップS3の前にステップS2が実施される限りどのような順序で実施されてもよい。例えば、ステップS1とS2は、あらゆる順序で連続に（ステップS2の前にステップS1またはステップS1の前にステップS2）、または、少なくとも部分的に並列に実行され得る。相応的に、ステップS1はステップS3の前またはそれに続いて、または、少なくとも部分的に、ステップS3と並列的に実行され得る。
ステップS3で復号化されるIRAPピクチャは、ステップS4でDAPピクチャを復号化する際に参照ピクチャとして使用され、それにより、復号化の順序に従ってビデオビットストリームにおいて先行するIRAPピクチャである。IRAPピクチャは、独立して、すなわち、参照ピクチャなしで、復号化される。
ステップS4で復号化されるDRAPピクチャは、IRAPピクチャと明確に対照的に、少なくとも1つの参照ピクチャを有する。この少なくとも1つの参照ピクチャは、ステップS3で復号化されたようなIRAPピクチャであることが好ましい。
実施形態では、ステップS4は、DRAPピクチャを、ビデオビットストリームにおいて、復号化の順序に従って最も近く先行するIRAPピクチャのみを、DRAPピクチャに対する独占的な参照ピクチャとして使用して復号化することを含む。本実施形態では、DRAPピクチャは、復号化の順序に従ってビデオビットストリームにおいて最も近く先行するIRAPピクチャのみを参照することができ、ステップS4においてDRAPピクチャのブロックを復号化する際に参照ピクチャとしてこの特定のIRAPピクチャのみを使用することができる。
DRAPピクチャは、最も近く先行するIRAPピクチャに対する単一の参照の表示を有する時間的予想ピクチャとして符号化され得る。これは、DRAPピクチャは、P-ピクチャと見なされることを意味するが、P-ピクチャはRAPを構成することができないのに対し、ビデオビットストリームにおいてRAPを含むという重要な違いがある。別の例では、DRAPピクチャはB-ピクチャと見なされ得る。そのようなケースでは、それは、最も近く先行するIRAPピクチャに対する一つだけの参照の代わりに、同じ最も近く先行するIRAPに対する2つの参照を使用するブロックを含み得る。
DRAPピクチャは、P-ピクチャ等の時間的予想ピクチャであり、先のRAPピクチャを参照することで十分であり得る。先のRAPピクチャは、実施形態では、ビデオビットストリームにおいてより早いピクチャの符号化された表現に対応するピクチャであり得る。また、先のRAPピクチャは、出力されないが、ビデオビットストリームにおけるピクチャに対する参照を構成するのみの、例えばシーンの背景を表す、ピクチャであり得る。
DRAPピクチャは、参照として使用され得るトレーリングピクチャとして符号化される。トレーリングピクチャは、出力の順序で、関連付けられたRAPピクチャに続くピクチャである。関連付けられたRAPピクチャは、復号化の順序で最も近く先行するRAPピクチャである。HEVCでは、DRAPピクチャは、いわゆるTRAIL_Rピクチャである。TRAIL_Rは、参照として使用され得るトレーリングピクチャとして定義される。したがって、ビデオビットストリームにおいて復号化の順序でDRAPピクチャに続くピクチャは、復号化の間、DRAPピクチャを参照し、参照ピクチャとしてDRAPピクチャを使用し得る。
したがって、トレーリングピクチャは、IRAPピクチャとしてマークされず、IRAPピクチャへのリーディングピクチャではない。それは、復号化の順序でIRAPピクチャに続き、したがって、それは、IRAPピクチャのトレーリングピクチャである。HEVC規格では、トレーリングピクチャはまた、出力の順序でIRAPピクチャに続く。
TRAIL_Rピクチャはまた、HEVCでは、1のネットワークアブストラクションレイヤ（NAL）タイプ値により示される。したがって、実施形態では、DRAPピクチャは、DRAPピクチャの符号化されたビデオデータを含むNALユニットのNALユニットヘッダにおいて、1のNALタイプ値を含む。
特定の実施形態では、DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームの一番低いレイヤに属するトレーリングピクチャとして符号化される。したがって、本実施形態では、DRAPピクチャは、0に等しい時間的識別子パラメータの値（temporal idまたはTemporalId）を有する0のtemporal idは、DRAPピクチャが一番低いレイヤに属し、ビデオビットストリームにおける他のピクチャによりそれらのtemporal idに関係なく、参照として使用されることができることを意味する。
DRAPピクチャは、種々の実施形態に従って、ビデオビットストリームにおけるDRAPピクチャとしてシグナリングされ得る。
実施形態において、DRAPピクチャは、ピクチャタイプ識別子に基づいたDRAPピクチャとして識別されるDRAPピクチャに関連付けられた、ビデオビットストリームのNALユニットヘッダに含まれる。
したがって、実施形態では、少なくとも一つのNALユニットタイプの値が、DRAPピクチャをシグナリングするために充てられる。これは、DRAPピクチャの符号化されたビデオデータを運ぶNALユニットが、DRAPピクチャに充てられた値に設定されたそのNALユニットヘッダにおけるNALユニットタイプパラメータの値を有することを意味する。非限定的な例として、NALユニットタイプ＝24が、DRAPピクチャをシグナリングするために使用され得る。
別の実施形態では、図1のステップS1は、DRAPピクチャに関連付けられた補助的強化情報（supplemental enhancement information（SEI））メッセージに基づいたDRAPピクチャとしてDRAPピクチャを識別することを含む。方法はそして、図1におけるステップS2へ続く。
例では、SEIメッセージは、ピクチャはDRAPピクチャであることを示す、関連付けられたピクチャと共に送信され、それによりビデオビットストリームにおいてRAPとして使用されることができる。したがって、ビデオビットストリームにおけるSEIメッセージの設置により、どのピクチャにSEIメッセージが属するかが示される。
もしDRAPピクチャがSEIメッセージを用いてシグナリングされた場合、上記の実施形態において説明したようにビデオビットストリームにおける特定のピクチャタイプとしてDRAPピクチャをシグナリングする必要はない。
したがって、説明的なものであるが非限定的な例としての以下のdependent_rap_indicationとして示される新しいタイプのSEIメッセージが、ビデオビットストリームにおけるどのピクチャがDRAPピクチャであるかをシグナリングするために使用される。
実施形態では、SERIメッセージは空（empty）であり得る。そして、復号器、ネットワークエレメント、またはビデオビットストリームに対して動作するあらゆるエンティティに、SEIメッセージに関連付けられたピクチャはDRAPピクチャであることを示すために使用される。
SEIメッセージは以下の形式をとり得る。
他の実施形態では、SEIメッセージは空ではなく、以下にさらに説明する追加的な情報を含み得る。
SEIメッセージの別のバージョンは、以下のように構成され得る。
依存性RAPインジケーションSEIメッセージ（dependent RAP indication SEI message）は、依存性RAPインジケーションSEIメッセージに関連付けられたピクチャおよび、出力の順序でそれに続くピクチャを正しく復号化するために、ビデオビットストリームのどの部分が符号化されるのに必要かを決定する際に復号器を支援する。
依存性RAPインジケーションSEIメッセージに関連付けられたピクチャは、DRAPピクチャとして参照される。DRAPピクチャは、参照のためのその関連付けられたIRAPピクチャを使用し得るが、参照のためのあらゆる他のピクチャは使用しないだろう。
DRAPピクチャにおいてランダムアクセスを実行する場合、出力の順序でDRAPピクチャに先行する全てのピクチャに対して、pic_output_flagの値は0に等しいと推測されるべきである。出力の順序でDRAPピクチャに先行する復号化されたピクチャは、復号化ピクチャバッファにおいて利用可能ではないピクチャに対する参照を含み得る.
出力の順序でDRAPピクチャに続くピクチャは、出力の順序または復号化の順序でDRAPピクチャに先行するあらゆるピクチャを参照として使用しないだろう。例外として、他のその後のDRAPピクチャは、関連付けられたIRAPピクチャを参照として使用し得る。
broken_link_flag は、依存性RAPインジケーションSEIメッセージの場所においてNALユニットストリームにおける破損したリンク（broken link）の存在または不存在を示し、以下のように更なるセマンティクスに関連付けられる。
‐もしbroken_link_flagが1に等しい場合、先のIRAPアクセスユニットの位置における復号化プロセスが開始することにより提供されたピクチャは、依存性RAPインジケーションに関連付けられたアクセスユニットに先行する復号化されたピクチャが表示されるべきではない広さに、望まない視覚的なアーチファクトを有し得る。
‐それ以外の場合（broken_link_flagが0に等しい）、視覚的なアーチファクトのあらゆる潜在的な存在に関する表示は与えられない。
SEIメッセージの別のバージョンは、以下のように構成され得る。
この例では、図1のステップS1は、DRAPピクチャに関連付けられたSEIメッセージに少なくとも部分的に基づいて、ビデオビットストリームにおけるDRAPピクチャを識別することを含む。方法はまた、SEIメッセージから参照ピクチャデルタ識別子を受信することを含む。方法は更に、参照ピクチャデルタ識別子が0より大きい場合に、DRAPピクチャのピクチャオーダーカウント（POC）と参照ピクチャデルタ識別子に基づいて、IRAPピクチャのPOC値を算出することを含む。本実施形態では、図1のステップS2は、参照ピクチャデルタ識別子が0より大きい場合に、算出されたPOC値に基づいてIRAPピクチャを識別すること、および、参照ピクチャデルタ識別子が0に等しい場合にビデオビットストリームにおいて最も近く先行するIRAPピクチャとしてのIRAPピクチャを識別することを含む。
特定の実施形態では、方法はまた、参照ピクチャデルタ識別子の値を調査することを含む。もし当該値が0と異なる場合、DRAPピクチャに対する参照ピクチャとして使用されるIRAPピクチャのPOC値が算出され、好ましくは、POC(IRAP) = POC(DRAP) − (reference_irap_picture_poc_delta_idc_minus1 + 1)と等しくなる。IRAPピクチャはそして、算出されたPOC値に基づいて識別される。
しかしながら、当該調査により参照ピクチャデルタ識別子が0に等しいと結論付けられた場合、IRAPピクチャは、ビデオビットストリームにおける最も近く先行するIRAPピクチャとして識別される。したがって、この場合では、POC値を計算することは必要ではない。
これらの例では、IRAPピクチャのPOC値は、常にDRAPピクチャのPOC値より低くなり得る。なぜならば、復号化および出力の順序において、IRAPピクチャはDRAPピクチャに先行するからである。これは、参照ピクチャデルタ識別子が0に等しいまたは正の整数となり得ることを意味する。
SEIメッセージは、パラメータ参照ピクチャデルタ識別子、または、上記に示したような、破損リンクフラグ（broken link flag）と共に参照ピクチャデルタ識別子のみを含むことが可能である。
依存性RAPインジケーションSEIメッセージ（dependent RAP indication SEI message）は、依存性RAPインジケーションSEIメッセージに関連付けられたピクチャおよび、出力の順序でそれに続くピクチャを正しく復号化するために、ビデオビットストリームのどの部分が符号化されるのに必要かを決定する際に復号器を支援する。
依存性RAPインジケーションSEIメッセージに関連付けられたピクチャは、DRAPピクチャとして参照される。DRAPピクチャは、参照のためのその関連付けられたIRAPピクチャを使用し得るが、参照のためのあらゆる他のピクチャは使用しないだろう。
DRAPピクチャにおいてランダムアクセスを実行する場合、出力の順序でDRAPピクチャに先行する全てのピクチャに対して、pic_output_flagの値は0に等しいと推測されるべきである。出力の順序でDRAPピクチャに先行する復号化されたピクチャは、復号化ピクチャバッファにおいて利用可能ではないピクチャに対する参照を含み得る。
出力の順序でDRAPピクチャに続くピクチャは、出力の順序または復号化の順序でDRAPピクチャに先行するあらゆるピクチャを参照として使用しないだろう。例外として、他のその後のDRAPピクチャは、関連付けられたIRAPピクチャを参照として使用し得る。
もし存在すれば、broken_link_flagは上記のSEIの例におけるように定義される。
referenced_irap_picture_poc_delta_idc_minus1 は、DRAPピクチャのPOCと、DRAPピクチャにより参照されるIRAPピクチャのPOCマイナス（−）1との間の差を示す。
実施形態の更なるバージョンでは、SEIメッセージは、以下のように構成され得る。
これらのバージョンは上記のものと類似しているが、このケースでは、referenced_irap_picture_poc_delta_idcの値が0より大きい場合、IRAPピクチャのPOC値は、POC(IRAP) = POC(DRAP) − reference_irap_picture_poc_delta_idcと算出される。
依存性RAPインジケーションSEIメッセージ（dependent RAP indication SEI message）は、依存性RAPインジケーションSEIメッセージに関連付けられたピクチャおよび、出力の順序でそれに続くピクチャを正しく復号化するために、ビデオビットストリームのどの部分が符号化されるのに必要かを決定する際に復号器を支援する。
依存性RAPインジケーションSEIメッセージに関連付けられたピクチャは、DRAPピクチャとして参照される。DRAPピクチャは、参照のためのその関連付けられたIRAPピクチャを使用し得るが、参照のためのあらゆる他のピクチャは使用しないだろう。
DRAPピクチャにおいてランダムアクセスを実行する場合、出力の順序でDRAPピクチャに先行する全てのピクチャに対して、pic_output_flagの値は0に等しいと推測されるべきである。出力の順序でDRAPピクチャに先行する復号化されたピクチャは、復号化ピクチャバッファにおいて利用可能ではないピクチャに対する参照を含み得る。
出力の順序でDRAPピクチャに続くピクチャは、出力の順序または復号化の順序でDRAPピクチャに先行するあらゆるピクチャを参照として使用しないだろう。例外として、他のその後のDRAPピクチャは、関連付けられたIRAPピクチャを参照として使用し得る。
もし存在すれば、broken_link_flagは上記のSEIの例におけるように定義される。
referenced_irap_picture_poc_delta_idcは、0より大きい場合は、DRAPピクチャのPOCと、DRAPピクチャにより参照されるIRAPピクチャのPOCとの差を示す。eferenced_irap_picture_poc_delta_idcが0に等しい場合、DRAPは、参照のために先のIRAPピクチャを使用している。
わかるように、IRAPピクチャへの参照は、2つの異なる手法、delta idc を用いた明示的な参照により、または、先のIRAPピクチャが参照として使用されることを述べることのいずれかにより、特定することが可能である。常に明示的な参照を常に使わない理由は、どのようにしてもシステムレイヤでIRAPと潜在的にDRAPピクチャがシグナリングされるいくつかのシステムアプリケーションに対して、POC値を取得することが煩わしいこととなり得ることである。さらに、参照を明示的にシグナリングしないことにより、数ビットがセーブされる。
SEIメッセージの更に他のバージョンは、以下のように構成され得る。
依存性RAPインジケーションSEIメッセージ（dependent RAP indication SEI message）は、依存性RAPインジケーションSEIメッセージに関連付けられたピクチャおよび、出力の順序でそれに続くピクチャを正しく復号化するために、ビデオビットストリームのどの部分が符号化されるのに必要かを決定する際に復号器を支援する。
依存性RAPインジケーションSEIメッセージに関連付けられたピクチャは、DRAPピクチャとして参照される。DRAPピクチャは、参照のためのその関連付けられたIRAPピクチャを使用し得るが、参照のためのあらゆる他のピクチャは使用しないだろう。
DRAPピクチャにおいてランダムアクセスを実行する場合、出力の順序でDRAPピクチャに先行する全てのピクチャに対して、pic_output_flagの値は0に等しいと推測されるべきである。出力の順序でDRAPピクチャに先行する復号化されたピクチャは、復号化ピクチャバッファにおいて利用可能ではないピクチャに対する参照を含み得る。
出力の順序でDRAPピクチャに続くピクチャは、出力の順序または復号化の順序でDRAPピクチャに先行するあらゆるピクチャを参照として使用しないだろう。例外として、他のその後のDRAPピクチャは、関連付けられたIRAPピクチャを参照として使用し得る。
もし存在すれば、broken_link_flagは上記のSEIの例におけるように定義される。
referenced_irap_picture_poc_lsbは、DRAPピクチャにより参照されるIRAPピクチャのPOC最下位ビット（lsb）を特定する。
IRAPピクチャのPOC値は、その後、パラメータreferenced_rap_picture_poc_lsbに基づいて算出され、それにより、DRAPピクチャに対する参照ピクチャとして使用されるIRAPピクチャの識別を許容する。
パラメータreferenced_rap_picture_poc_lsbに基づいてIRAPピクチャのPOC値をどのように算出するかについてのさらなる情報は、ITU-T H.265シリーズH：Audiovisual and multimedia systems, Infra structure of audiovisual services - Coding of moving video, High efficiency video codingの、セクション8.3.2 Decoding process for reference picture setにおいて見ることができる。
SEIメッセージの更に他のバージョンは、以下のように構成され得る。
依存性RAPインジケーションSEIメッセージ（dependent RAP indication SEI message）は、依存性RAPインジケーションSEIメッセージに関連付けられたピクチャおよび、出力の順序でそれに続くピクチャを正しく復号化するために、ビデオビットストリームのどの部分が符号化されるのに必要かを決定する際に復号器を支援する。
依存性RAPインジケーションSEIメッセージに関連付けられたピクチャは、DRAPピクチャとして参照される。DRAPピクチャは、参照のためのその関連付けられたIRAPピクチャを使用し得るが、参照のためのあらゆる他のピクチャは使用しないだろう。
DRAPピクチャにおいてランダムアクセスを実行する場合、出力の順序でDRAPピクチャに先行する全てのピクチャに対して、pic_output_flagの値は0に等しいと推測されるべきである。出力の順序でDRAPピクチャに先行する復号化されたピクチャは、復号化ピクチャバッファにおいて利用可能ではないピクチャに対する参照を含み得る。
出力の順序でDRAPピクチャに続くピクチャは、出力の順序または復号化の順序でDRAPピクチャに先行するあらゆるピクチャを参照として使用しないだろう。例外として、他のその後のDRAPピクチャは、関連付けられたIRAPピクチャを参照として使用し得る。
もし存在すれば、broken_link_flagは上記のSEIの例におけるように定義される。
implicitly_reference_previous_irap_picture_flagは、先のIRAPピクチャが、以下に従って、依存性RAPインジケーションSEIメッセージに関連付けられたDRAPピクチャにより参照されるかどうかを示す。
‐implicitly_reference_previous_irap_picture_flagが1に等しい場合、DRAPピクチャは、依存性RAPインジケーションSEIメッセージにおいてIRAPピクチャを明示的に参照せずに、先のIRAPピクチャを参照している。
‐それ以外で、implicitly_reference_previous_irap_picture_flagが0に等しい場合、DRAPピクチャにより参照されるIRAPピクチャに対する参照インジケータが、依存性RAPインジケーションSEIメッセージにおいて明示的にシグナリングされる。
referenced_irap_picture_poc_delta_idcは、上記のSEIの例におけるように定義される。
暗黙的に参照する先のIRAPピクチャフラグを使用するこの例示的な実施形態は、代替的に、referenced_irap_picture_poc_delta_idcに代えて、パラメータreferenced_irap_picture_poc_delta_idc_minus1またはreferenced_irap_picture_poc_lsbと共に使用され得る。
実施形態において、図1のステップS2は、DRAPピクチャの参照ピクチャセット（reference picture set（RPS））に存在するIRAPピクチャの識別子に基づいて、復号化ピクチャバッファ（DPB）におけるIRAPピクチャを識別することを含む。
したがって、本実施形態では、IRAPピクチャの識別子は、好ましくは、DRAPピクチャのRPSから引き出される（retrieved）。DRAPピクチャのRPSは、ショートタームの参照ピクチャまたはロングタームの参照ピクチャとしてIRAPピクチャをシグナリングし得る。
方法はその後、ステップS3に続き、RPSから引き出された識別子により識別されたIRAPピクチャは復号化され、それにより、DRAPピクチャに対する参照ピクチャとして使用される。DRAPピクチャはその後、ステップS4で、独占的な参照ピクチャとしてステップS3で復号化されたIRAPピクチャと共に復号化される。
他の実施形態では、IRAPピクチャは復号化され、DPBに保存される。そして、DRAPピクチャのRPSは、IRAPピクチャの識別子を引き出すために、パース（parse）される（解析される）。この識別子はそれにより、既に復号化されたIRAPピクチャは、ショートタームの参照ピクチャまたはロングタームの参照ピクチャとしてDPBに保存され続け、DRAPピクチャのブロックを復号化する際に参照ピクチャとして使用されるべきであることをシグナリングする。従って、この場合、ステップS2とS3は、ステップS1とS4の前に実行される。
したがって、本実施形態では、IRAPピクチャは、独占的な参照ピクチャであり、DRAPピクチャのRPSにおいてシグナリングされる。IRAPピクチャは、復号化されたIRAPピクチャがどれくらい長くDPBに保存され続けるべきかに依存して、いわゆるショートタームの参照ピクチャまたはロングタームの参照ピクチャとしてシグナリングされ得る。
HEVCおよびRPSを用いる他のビデオ符号化規格では、参照ピクチャとしてピクチャを用いることは、いわゆるRPSのCurr lists、すなわち、RefPicSetStCurrBefore、RefPicSetStCurrAfter、またはRefPicSetLtCurrにおける識別子を有することに対応する。これは、DRAPピクチャは、好ましくは、そのRPSのCurr listsにおけるIRAPピクチャの識別子のみを有することを意味する。DRAPピクチャを復号化する際に、参照ピクチャとして使用することができない他の先のピクチャの識別子は、まだRPS、DRAPピクチャのRPSのFoll lists、すなわち、PocStFollまたはPocLtFollに存在し得る。
ステップS4において復号化されたDRAPピクチャは、上述したように、ビデオストリームにおけるRAPを構成する。したがって、DRAPピクチャは、ビデオビットストリームにおいてRAPとして使用することができ、ビデオビットストリームにおけるランダムアクセスオペレーションを実行するために使用することが可能である。すなわち、DRAPピクチャにおいてランダムアクセスオペレーションを実行することが可能である。なお、ステップS3で復号化されたIRAPピクチャは、ビデオビットストリームにおけるRAPでもある。しかしながら、IRAPピクチャにより提供されるRAPは、独立性のRAPであり、IRAPピクチャがビデオビットストリームにおけるあらゆる他のピクチャを参照せずに復号化することが可能であることを暗示する。これは、DRAPピクチャにより供給されるRAPとは明確に異なり、依存性のRAPは、DRAPピクチャがビデオビットストリームにおいて先のIRAPピクチャを参照し、それにより、独占的な参照ピクチャとしてそのような先のIRAPピクチャを用いて復号化されることを暗示する。
DRAPピクチャは、ビデオビットストリームにおいて、ランダムアクセスポイントを構成する。これは、ランダムアクセスオペレーションが、DRAPピクチャに対応するビデオビットストリームにおける位置において実行され得ることを意味する。しかしながら、DRAPピクチャは依存性のRAPピクチャである。DRAPピクチャは、DRAPピクチャに対する独占的な参照ピクチャとしてIRAPピクチャを伴って復号化される。これは、ランダムアクセスオペレーションを実行するために、IRAPピクチャも復号化される必要があることを意味する。しかしながら、IRAPピクチャと現在のピクチャとの間のあらゆる他のピクチャは、ランダムアクセスオペレーションを実行するために復号化される必要はない。従って、特定の実施形態では、IRAPピクチャと共にDRAPピクチャは、ビデオビットストリームにおいてランダムアクセスポイントを構成する。
図4は、種々の実施形態に従う方法の、追加的、オプション的なステップを示すフローチャートである。実施形態において、方法は、図1のステップS5から続く。次のステップS30は、出力の順序および符号化の順序において、DRAPピクチャに続くビデオビットストリームの少なくとも一つの非RAPピクチャを復号化することを含む。少なくとも一つの非RAPピクチャは、参照ピクチャとして、ビデオビットストリームで復号化の順序におけるDRAPピクチャに先行するあらゆる非RAPピクチャを使用しない。
したがって、DRAPピクチャに続く非RAPピクチャは、DRAPピクチャに対する参照として使用されるIRAPピクチャを潜在的に除いて、復号化の順序において、DRAPピクチャに先行するあらゆるピクチャを参照しない。これは、復号化の順序においてDRAPピクチャに先行する非RAPピクチャは、出力の順序および復号化の順序においてDRAPピクチャに続くあらゆる非RAPピクチャに対する参照ピクチャとして使用されないことを意味する。
したがって、DRAPピクチャに渡る予想は禁止される。DRAPピクチャに続く非RAPピクチャは、DRAPピクチャに先行するあらゆる非RAPピクチャ、または、DRAPピクチャに関連付けられたIRAPピクチャに先行するあらゆるピクチャを予想のために用いてはならない。DRAPピクチャに関連付けられるIRAPピクチャは、復号化の順序において、最も近く先行するIRAPピクチャである。
特定の実施形態において、出力の順序および復号化の順序においてDRAPピクチャに続くピクチャは、参照ピクチャとしてDRAPピクチャに関連付けられたIRAPピクチャを使用し得ることを除いて、参照ピクチャとして、復号化の順序でDRAPピクチャに先行するあらゆるピクチャを使用しない。
別の特定の実施形態において、出力の順序および復号化の順序においてDRAPピクチャに続くピクチャは、参照ピクチャとして続くDRAPピクチャがIRAPピクチャを使用し得ることを除いて、参照ピクチャとして、復号化の順序でDRAPピクチャに先行するあらゆるピクチャを使用しない。
更なる特定の実施形態では、出力の順序および復号化の順序でDRAPピクチャに続くピクチャは、さらに、復号化の順序で、DRAPピクチャに関連付けられた、すなわち、DRAPピクチャを復号化する際に参照として使用されるIRAPピクチャに先行するあらゆるRAPピクチャを使用しない。
DRAPピクチャに渡る予想におけるこの制約により、ビデオビットストリームにおけるRAPとしてのDRAPピクチャの効率的な使用が可能となる。もし予想がDRAPピクチャに渡って許容される場合、復号化の順序でDRAPピクチャに先行するあらゆる参照ピクチャはDPBにおいて利用可能でないので、DRAPピクチャがランダムアクセスオペレーションにおいてRAPとして使用された場合、復号化および出力の順序でDRAPピクチャに先行する非RAPピクチャは、正しく復号化されない可能性がある。
続く2つのステップS32とS33は、出力の実施形態に関連する。ステップS32は、復号化されたDRAPピクチャを出力することを含む。続くステップS33は、非RAPピクチャを出力することを含む。
ステップS32とS33で出力されたピクチャは、復号化の順序と異なり得る出力の順序に従って出力される。ランダムアクセスオペレーションでは、復号化はIRAPピクチャを伴って開始し（S3）、ランダムアクセスオペレーションのためにRAPを構成するDRAPピクチャ（S4）に続く。復号化は、次の非RAPピクチャ（S30）に続く。ランダムアクセスオペレーションに続いて出力される最初のピクチャは、好ましくは、出力の順序でDRAPピクチャ（S32）、そして、非RAPピクチャ（S33）である。
したがって、本実施形態では、DRAPピクチャに対する参照ピクチャとして使用されるIRAPピクチャは、好ましくは出力されない。HEVCでは、出力されるべきではないことを示すために、IRAPピクチャの出力フラグを0に設定することによりシグナリングされ得る。また、復号器は、DRAPピクチャに先行するピクチャの出力フラグの値が0であると推測し得る。これにより、DRAPピクチャにおけるランダムアクセスオペレーションを行う際に、そのような先行するピクチャが出力されることが防げる。ピクチャの出力を抑える他の手段は、非HEVCビデオに対して使用され得る。
したがって、特定の実施形態では、方法は、図1のステップS1から続き、次のステップS31は、IRAPピクチャに関連付けられた出力フラグを受信することを含む。出力フラグは、IRAPピクチャが出力されるべきでないことを示す。
ステップS32とS33におけるピクチャの出力は、典型的には、表示に対する出力をj含む。しかしながら、出力は他に、表示以外の他の目的に対する出力を意味し得る。非限定的な例は、例えば監視アプリケーション等において、コード変換のための出力、保存のための出力、ビデオ解析のための出力を含む。
ここで、ランダムアクセスオペレーションの例と、実施形態のDRAPピクチャの使用の種々の例を以下に示す。
最初の例は、非限定的であるが、アダプティブストリーミングに適し、従来、アダプティブビットレートストリーミングとも呼ばれる。アダプティブストリーミングは、ほとんどHTTPに基づき、インターネット等の広く分散したHTTPネットワークを介して動作するように設計されている。一般的に、アダプティブストリーミングは、帯域とユーザクライアントの中央処理ユニット（CPU）の容量をリアルタイムで取得し、それに従ってビデオビットストリームの品質を調整することを含む。より具体的には、アダプティブストリーミングは、HTTPを介するビデオストリーミングの方法を参照し、ビデオコンテンツは、複数のビットレートで復号化され、異なるビットレートのビデオストリーミングのそれぞれは、従来では典型的にセグメントまたはチャンクと呼ばれる小さい複数秒のパートに分割される。ストリーミングセッションが開始すると、ユーザクライアントは、一番低いビットレートのビデオストリーミングを普通は要求する。ユーザクライアントが、ダウンロードされたセグメントのビットレートより高いダウンロードスピードを見つけると、次により高いビットレートのセグメントを要求するだろう。その後、クライアントが、セグメントに対するビットレートより低いセグメントに対するダウンロードスピードを見つけて、ゆえにネットワークスループットが劣化する場合、より低いビットレートのセグメントを要求するだろう。セグメントのサイズは、特定の実装に依存して変化することができるが、それらは典型的には、2秒から10秒の間である。
アダプティブストリーミングは、現在はDASHの形態で利用可能であり、これは、非限定的なれ例であるが説明として、MPEG-DASH,、HLS、Microsoft Smooth Streaming,、Adobe Dynamic Streaming for Flash,、AuayStreams Adaptive Streaming、upLynkによるhigh definition (HD) Adaptive Streamingとしても参照される。
図2は、図1におけるステップS1とS2の実施形態を示すフローチャートである。方法はステップS10で開始し、ビデオビットストリームの符号化されたビデオデータのセグメントをダウンロードすることを含む。セグメントは、IRAPピクチャから開始し、少なくとも一つのDRAPピクチャを含む。次のステップS11は、前方ジャンプまたは早送りの要求に基づいて、セグメントにおいてDRAPピクチャを識別することを含む。方法はそして、図1におけるステップS3へ続く。
それにより、図2に示す実施形態は、ランダムアクセスオペレーションの例として、符号化されたビデオデータのセグメント内で、前方ジャンプまたは早送りのトリックプレイに対して適している。
本実施形態では、ビデオビットストリーム符号化されたビデオデータは、好ましくは、セグメントまたはチャンクに区分けまたは分割され、例えば、ビデオデータの2秒から10秒の間を含み得る。そのようなセグメントのそれぞれは、典型的にはそれぞれのIRAPピクチャの形態で、好ましくはRAPで開始する。セグメントは、好ましくは、典型的にはDRAPピクチャの形態で少なくとも一つの追加的なRAPを含む。例えば、セグメントが全体で10秒を有する場合、DRAPピクチャは、各0.5秒、各秒、または各2秒に現れ得る。
セグメントにおける少なくとも一つのDRAPピクチャは、前方ジャンプ（jump forward）または早送り（fast forward）オペレーションを行うことができるRAPを構成する。前方ジャンプは、典型的には、ビデオビットストリーム内の現在の再生またはプレイアウト位置から、現在の再生位置に続く別の再生位置へ移動することを含む。この場合、再生は、あらゆる中間のビデオデータを再生またはプレイアウトせずに新しい位置に「ジャンプ」する。早送りは、一般の再生またはプレイアウトよりも早いスピードでビデオストリームを通して先に移動することである。
前方ジャンプのシナリオでは、ユーザは典型的には、リモコン、マウス、キーボード、タッチ反応スクリーンまたはユーザクライアントに接続される他の入力デバイスを用いて、ビデオストリーム内で所望の早送り位置を選択する。前方ジャンプ要求は、所望の早送り位置を示してまたは表して生成される。所望の早送りの位置に関連づけられるセグメント内のRAPが識別される。関連付けられたRAPがIRAPピクチャである場合、このIRAPピクチャは復号化され、ビデオビットストリームにおける復号化の順序および出力の順序でIRAPピクチャに続くピクチャの復号化と出力に続いて、表示のために出力される。関連付けられたRAPがDRAPピクチャである場合、DRAPピクチャに対する独占的な参照ピクチャであるIRAPピクチャは、既に復号化された形式が提供されていない限り、復号化される。DRAPピクチャは、独占的な参照ピクチャとしてIRAPピクチャを伴って復号化される。復号化されたDRAPピクチャは、復号化に続いて出力され、ビデオビットストリームにおいて復号化の順序または出力の順序でDRAPピクチャに続くピクチャの出力であり得る。特定の実施形態では、DRAPピクチャに対する参照ピクチャとして使用されるIRAPピクチャは、好ましくは表示のために出力されない。したがって、DRAPピクチャは、前方ジャンプ要求に続く最初のピクチャとして出力され、ここで、RAIPピクチャは単に参照ピクチャとして使用され、ジャンプ早送り要求の受信に続いて表示のために出力されない。
所望の早送り位置に関連づけられたRAPは、好ましくは、所望の早送り位置に時間的に最も近いRAPピクチャである。特定の実施形態では、関連付けられたRAPは、好ましくは、時間的に最も近いRAPピクチャであるが、所望の早送り位置に先行し、または所望の早送り位置において発生する。特定の実施形態において、ユーザは、所望のジャンプ早送り位置からあらゆるビデオコンテンツの表示を見逃さないだろう。
早送りのシナリオでは、ユーザは、典型的には、ユーザクライアントの、またはユーザクライアントに接続された入力デバイスを用いて、早送りオペレーションを選択する。早送り要求が生成されると、ビデオビットストリームのビデオデータの早送り出力がなされる。そのような早送りオペレーションは、セグメントのRAPピクチャを復号化して出力することにより実装され得る。例えば、セグメントの開始に存在するIRAPピクチャは、復号化されて出力され、続いて、セグメントの第1のDRAPピクチャが復号化されて出力され、それは、参照ピクチャとしてIRAPピクチャを用いて復号化され、順に続いて、セグメントの第2のDRAPピクチャが復号化されて出力され、それは参照ピクチャとしてIRAPピクチャを用いて復号化され、ということがセグメントの最後に到達するまで、当該手順がビデオビットストリームの後続のセグメントに続く。
早送りのこの説明的な例では、RAPピクチャのみが復号化されて表示のために出力される。すなわち、IRAPおよびDRAPピクチャであり、ここで、ビデオビットストリームのセグメントに存在する非RAPピクチャは復号化されず出力されない。
DRAPピクチャとしてピクチャを符号化することは、IRAPピクチャとしてピクチャを符号化することと比較して、著しく少ないビットを必要とする。したがって、これらの実施形態により、ビデオビットストリームに対して低いビットコストであるが、トリックプレイとランダムアクセスオペレーションの説明的な例として、効率的な前方ジャンプおよび早送りが可能となる。また、より多くのRAPがビデオビットストリームに含まれ得る。すなわち、セグメント内の全てまたは少なくとも多勢のRAPとしてDRAPピクチャを用いることによりRAP間の距離を短くすることができる。そのようなケースでは、セグメントの開始におけるRAPのみが、IRAPピクチャとなる必要がある。
図3は、図1におけるステップS1とS2の別の実施形態を示すフローチャートである。方法はステップS20で開始し、ビデオビットストリームの符号化されたビデオデータのセグメントの第1の部分をダウンロードすることを含む。セグメントの第1の部分は、IRAPピクチャを含み、セグメントは前方ジャンプ要求または表現切り替え要求に基づいて識別される。続くステップS21は、前方ジャンプ要求または表現切り替え要求に基づいて識別されたDRAPピクチャで開始するセグメントの第2の部分をダウンロードすることを含む。方法はそして、図1におけるステップS3へ続く。
この場合、前方ジャンプ要求により表される所望の早送り位置を含むセグメントは、現在のセグメントではなく、ダウンロードする必要はない。しかしながら、完全なセグメントをダウンロードすることの代わりに、本実施形態は、好ましくは、IRAPピクチャに対応するセグメントの第1の部分、および、前方ジャンプ要求に関連付けられた、すなわちそれに基づいて識別されたDRAPピクチャで開始するセグメントの第2の部分をダウンロードすることで十分である。
セグメントの第1の部分におけるIRAPピクチャは復号化され、セグメントの第2の部分の開始でDRAPピクチャを復号化する際に、参照ピクチャとして使用される。DRAPピクチャは、好ましくは表示のために出力され、復号化と表示のための出力は、セグメントの第2の部分の以降のピクチャに続く。好ましい実施形態では、セグメントの第1の部分のIRAPピクチャは、表示のために出力されないが、DRAPピクチャを復号化する際に参照ピクチャとして、オプション的にはセグメントの第2の部分における以降のピクチャを復号化する際の参照ピクチャとして使用されるに過ぎない。
別の実施形態では、第1のセグメントのIRAPピクチャと、DRAPピクチャから前方ジャンプ要求により表される所望の早送り位置までのピクチャは、復号化されるが表示のために出力されない。表示のために出力される第1のピクチャは、出力の順序で一連のピクチャに続く所望の早送り位置におけるピクチャである。
DRAPピクチャ、および、それによる第2のセグメントの開始は、好ましくは、先に説明した、すなわち、最も近いDRAPピクチャまたは所望の早送り位置に先行する最も近いDRAPピクチャとして、前方ジャンプ要求に基づいて識別される。
DRAPピクチャの利用により、前方ジャンプオペレーションを実行する際に完全なセグメントをダウンロードする必要性が低減し、IRAPピクチャと用いる場合と比較して、より低いビットコストであるが、さらにRAPを構成する。したがって、DRAPピクチャは、前方ジャンプオペレーションを実行するために掛かる時間を減らすことができる。
先に説明したアダプティブストリーミングは、ビデオデータの異なる表現間を切り替えることができる。ここで、異なる表現は、異なるビットレートにおいて符号化されたビデオデータを伝達する。表現の切り替えは、現在の表現の現在のセグメント、すなわち、現在のビットレートにおけるビデオビットストリームから、新しい表現の新しいセグメント、すなわち、新しいビットレートにおけるビデオビットストリームに切り替えることを含む。
したがって、ターゲットの表現またはビデオビットストリームを示す表現切り替え要求を受信したことを受けて、新しい表現のセグメントの第1の部分がステップS20でダウンロードされ、ステップS21でセグメントの第2の部分のダウンロードが続く。セグメントの第1の部分は、IRAPピクチャを含み、第2の部分は、好ましくは、表現の切り替えが要求された時点に関連付けられるDRAPピクチャで開始する。したがって、DRAPピクチャは好ましくは、表現の切り替えの時点に関連する最も近い、すなわち、最も近く先行するまたは最も近く後続する、DRAPピクチャである。
［例示的な実施形態１］
第1の例示的な実施形態は、例えば、Dynamic Adaptive Streaming over HTTP（DASH）を介するアダプティブストリーミングに関する。
今日、DASHのセグメントは、トリックプレイを可能にするために、各秒にIRAPピクチャを有する、約10秒の長さを有する。
そのようなセグメントの品質は、DRAPピクチャが典型的に同じ品質のためにIRAPピクチャよりも低いいビットレートを必要とするため、DRAPピクチャの利用を通じて向上し得る。本実施形態を伴い、セグメントにおける最初のものではないIRAPピクチャは、DRAPピクチャに置き換えられる。
実施形態の第1のユースケースでは、クライアントは、全体のセグメントをダウンロードし、セグメント内で、例えば早送りまたは前方ジャンプのトリックプレイを実施する。前方ジャンプは、セグメントを開始するIRAPピクチャを表示せずに、そしてユーザにより選択された位置に対応するDRAPピクチャ復号化することにより、容易に実現化される。早送りは、IRAPピクチャ、その後セグメントにおけるDRAPピクチャを復号化することにより実現化される。
第2のユースケースでは、ユーザは既にダウンロードされていないセグメントへジャンプする。選択された位置でプレイアウトを開始するために、クライアントは、IRAPピクチャに対応するセグメントの第1の部分だけをダウンロードし、その後DRAPからの部分をダウンロードする必要がある。
第3のユースケースでは、表現の切り替えが、セグメント内で、すなわちセグメントの境界ではなく、実行される。切り替えを実行するために、クライアントは、IRAPピクチャに対応して切り替えている表現におけるセグメントの第1の部分だけをダウンロードし、その後DRAPからの部分をダウンロードする必要がある。
以下のステップは、図16のシグナリング図に示される。
ユーザクライアント100は、以下の順序付けされたステップにより第2または第3のユースケースを利用し得る。
1）ランダムアクセスは、ユーザの要求または他の手段により開始する。
2）ユーザクライアント100は、ビデオビットストリームにおける位置のためにサーバ200に要求を送信する。ユーザクライアント100は、利用可能なランダムアクセスポイントを把握し、その中から一つを選択し得る。
3）ユーザクライアント100は、IRAPピクチャ、DRAPピクチャ、復号化の順序でDRAPピクチャに続く符号化されたピクチャと、および可能性としてビデオパラメータセット（VPS）、シーケンスパラメータセット（SPS）、ピクチャパラメータセット（PPS）、等のパラメータセット等の他のデータを受信する。ユーザクライアント100は、データを復号化し、復号化されたピクチャを出力する。IRAPピクチャは出力されなくてもよい。
サーバ200は、以下の順序付けされたステップにより第2または第3のユースケースを利用し得る。
1）サーバ200は、ビデオビットストリームにおける位置のための要求を受信する。位置は、DRAPピクチャを用いたランダムアクセスポイントであり得る。
2） サーバ200は、DRAPピクチャに関連付けられたIRAPピクチャ、RRAPピクチャ、およびDRAPピクチャに続くピクチャデータ、および、可能性としてVPS、SPS、PPS等のパラメータセット等の他のデータを送信する。サーバ200は、受信機に、IRAPピクチャはユーザクライアント100により出力または表示されるべきではないことをシグナリングし得る。サーバ200は、IRAPデータに対してoutput_flagを0に設定することにより、HEVCのビットストリームに対してこれを実現化できる。
第2の例は、非限定的であるが、地上波、衛星、およびケーブルサービス等のブロードキャスティングサービスに適している。そのようなブロードサービスにおいて、受信器はTVチャネル等の1つのチャネルのビデオビットストリームを受信し、それは復号化され、復号化されたビデオはエンドユーザに表示される。受信器が追加的に、1つ以上の追加的なチャネルのビデオビットストリームを受信することも一般的である。
図5は、ブロードキャストサービスに適する実施形態を示すフローチャートである。方法はステップS40で開始し、現在のチャネルを表す現在のビデオビットストリームを受信して復号化することを含む。別のチャネルを表すビデオビットストリームは、ステップS41で受信される。ステップS41で受信されたビデオビットストリームの最も最近のAPピクチャ、または最も最近のIRAPピクチャの復号化されたバージョンが、ステップS42でメモリに保存される。
続くステップS43とS44は、図1のステップS1とS2の実施形態を表す。ステップS43は、別のチャネルを識別するチャネル切り替え要求に基づいて、メモリから、最も最近のIRAPピクチャの復号化されたバージョンの最も最近のIRAPピクチャを引き出す。次のステップS44は、チャネル切り替え要求を受けてビデオビットストリームないの次のDRAPピクチャとしてDRAPピクチャを受信することを含む。
方法はそして図3のステップS3へ続き、最も最近のIRAPピクチャが復号化される。もし最も最近のIRAPピクチャが復号化されたバージョンで保存されている場合、メモリにおける最も最近のIRAPピクチャを保存することに関連して既に実施されているので、このステップS3は、省略され得る。DRAPピクチャはそして独占的な参照ピクチャとして最も最近のIRAPピクチャの復号化されたバージョンを用いて、復号化される。
ステップS40からS42は、好ましくは、ユーザが現在のチャネルを観ている限り、すなわち、図5の線L1に概略的に示されるチャネル切り替え前まで、実行される。これは、ユーザクライアントが、現在のビデオビットストリームを受信することに加えて、少なくとも一つの他のチャネルの符号化されたビデオデータを運ぶ少なくとも一つの他のビデオビットストリームにおいて受信することを意味する。ステップS42はそして、好ましくは、最も最近のIRAPピクチャ、または、各そのような他のビデオビットストリームの符号化されたバージョンを一時的に保存することを含む。これは、ビデオビットストリームごとに保存される1つ以上のIRAPピクチャを維持することはできるが、単一のIRAPピクチャのみが、各他のビデオビットストリームに対して保存する必要があることを意味する。新しいIRAPピクチャが少なくとも他のビデオビットストリームから受信されると、それは、少なくとも一つの他のビデオビットストリームのためにメモリに保存されるIRAPピクチャと置き換え得る。
ユーザが現在のチャネル以外の別のチャネルを観ようとする場合、彼／彼女は、所望のチャネルを示すチャネル切り替え要求を生成するために、ユーザクライアントの入力デバイスまたはユーザクライアントに接続された入力デバイスを用いる。チャネル切り替え要求により示されたチャネルおよびビデオビットストリームに対する、最も最近のIRAPピクチャ、またはその復号化されたバージョンは、メモリから引き出される。チャネル切り替えは、所望のビデオビットストリームに対して受信される最初または次のDRAPピクチャにおいて影響され得る。メモリから引き出されたIRAPピクチャは、復号化された形式で保存されていない限り、復号化され、受信したDRAPピクチャを復号化する際に参照ピクチャとして使用される。DRAPピクチャは、そして表示のために出力され、ビデオビットストリームにおいて復号化の順序または出力の順序に従ってDRAPピクチャに続く復号化されたピクチャの出力が続く。特定の実施形態では、IRAPピクチャは、DRAPピクチャを復号化する際に、オプション的にはビデオビットストリームにおける以降のピクチャを復号化する際に、参照ピクチャとして使用されるので十分である。したがって、IRAPピクチャは、好ましくは、表示のために出力されない。
実施形態のDRAPピクチャにより、効率的なチャネル切り替えが可能となる。なぜならば、他のビデオビットストリームおよびチャネルのIRAPピクチャのみを、メモリに保存する必要があるからである。チャネルの切り替えは、チャネル切り替え要求を受けて、ビデオビットストリームにおける最初のDRAPピクチャに対応する時点で発生する。ビデオビットストリームのDRAPピクチャおよび以降のピクチャは、復号化されることが保証される。なぜならば、DRAPピクチャに対する独占的な参照として使用される最も最近のIRAPピクチャは既に利用可能であるからである。
いくつかのシナリオにおいて、受信機は、帯域の制約に起因して、または、不十分なスループットまたは受信器の処理能力に起因して、ある時間において全ての利用可能なチャネルに対する最も最近のIRAPピクチャを受信して保存することができない。可能な解決策は、現在観覧されているチャネルに加えて、ユーザが切り替えそうなチャネルに対する最も最近のIRAPピクチャを受信して保存することである。これは、ユーザが良く観覧するチャネル、および／またはチャネルリストにおける現在観覧されているチャネルの直接的に後および前のチャネルを含む。例えば、ユーザがチャネルリストにおけるチャネル5を観覧している場合、チャネル4、6、7、および8が同時に受信され、これらのピクチャに対する最も最近のIRAPピクチャが保存され得る。
さらに、DRAPピクチャは、IRAPピクチャと比較してより低いコストであるが、有効なRAPを構成するので、より多くのRAPが、ビットコストにおいて増加なく、またはほんの程度の増加で、ビットストリームにおい提供され得る。これは、ユーザがチャネル切り替えを要求してから、チャネル切り替えが次のRAPにおいて影響されるまでの時間が、DRAPピクチャをIRAPピクチャに対する補完として用いることにより、著しく低減され得ることを意味する。
［例示的な実施形態2］
第2の例示的な実施形態は、ブロードキャストサービスに関する。ブロードキャストサービスでは、IRAPピクチャは、合理的なチャネル切り替え時間を可能にするために、典型的には、頻繁な周期、例えば一秒に一度、送信される。より頻繁にIRAPピクチャを有することは、チャネル切り替え時間をさらに低減するために望ましいことである。しかし、IRAPピクチャは、利用可能なビットレートの多くの部分を消費し、全体の品質を低減させることから、これは実現可能ではない。
エンドユーザは、チャネルを観覧していると想定する。チャネル切り替えの遅延の問題を解決する一つの手法は、現在のチャネル以外のチャネルからデータを受信して保存する、追加的なチューナーを有することである。しかしながら、いくつかの他のチャネルから全てのデータをバッファリングすることは、受信機および／またはバッファ容量の制限から、実現可能でないかもしれない。
当該問題は、DRAPピクチャを利用することで解決され得る。そして、他のチャネルからIRAPピクチャだけをバッファリングする必要があり、チャネル切り替えは、ユーザがチャネル切り替えを選択した後に発生する最初のDRAPピクチャにおいて実行され得る。DRAPピクチャは、全体の品質に顕著な影響を与えずに、IRAPピクチャよりもより頻繁に、例えば、160ms毎に、送信されることができる。
一つの実施形態では、各チャネルに対して、復号化の順序で最も最近のIRAPピクチャだけが保存される。一つの実施形態では、圧縮されたIRAPピクチャが保存され、チャネル切り替えまたはランダムアクセスが、ユーザまたな他の手段によりトリガされた場合に、IRAPピクチャおよびDRAPピクチャの復号化が行われる。別の実施形態では、DRAPピクチャデータだけは、ランダムアクセスで復号化される必要があるように、IRAPピクチャは、チャネル切り替えまたはランダムアクセスがトリガされる前に復号化される。
DRAPピクチャを用いたチャネル切り替えの例を図15に示す。図15における濃い灰色のピクチャは、IRAPピクチャであり、中間の灰色のピクチャはDRAPピクチャであり、白いピクチャは、他の時間的予想ピクチャ、すなわち、非RAP P-ピクチャおよび／またはB-ピクチャである。ユーザはチャネルAを観覧している。追加的なチューナーは、チャネルB、C、Dに対する最新のIRAPピクチャを受信してバッファリングする。ピクチャ位置45において、ユーザは矢印Bを参照するように、チャネルBに切り替えている。チャネルBチューナーは、復号器がバッファリングされたIRAPピクチャからの援助を受けて、チャネルBの復号化を開始することができる前に、次のDRAPピクチャのための4秒待機する。ピクチャ位置67において、ユーザは、矢印Cのように、チャネルCを観覧している。復号器は、チャネルCの復号化を開始することができる前に、次のDRAPピクチャのために6秒待機する。最新のIRAPピクチャは、DRAPピクチャを復号化するために使用される。ビデオビットストリームがあらゆるDRAPピクチャを含まない場合、復号器は、チャネル切り替えの後、復号化の前に、次のピクチャを待つ必要がある。以下の例では、復号器は、チャネルAとBで切り替える場合、20ピクチャ待つ必要があり、チャネルBとCで切り替える場合に、30ピクチャ待つ必要がある。
第3の例は、これらに制限されないが、ライブストリーミング、サーバ制御のストリーミング、会話サービスに適している。これらのタイプのさービスでは、ユーザクライアントとビデオビットストリームを供給するサーバとの間のフィードバックチャネルが存在する。これｈら、非限定的な例として、リアルタイムトランスポートプロトコル（RTP）制御プロトコル（RTCP）フィードバックチャネルを伴うRTPに基づき得る。RTPは、IPネットワークを介して音声とビデオを伝達するためのネットワークプロトコルである。RTPは、電話、ビデオ会議アプリケーション、テレビサービス、およびウェブベースのプッシュ・ツー・トークの特性等のストリーミングサービスを含む、通信およびエンターテイメントサービスに広く利用される。RTPは、RTCPと併せて使用される。RTPがマルチメディアストリームを伝達する間、RTCPは、伝送の統計とサービスの品質（QoS）を監視するために使用され、複数のストリームの同期を支援する。
会話サービスは、大規模なビデオ会議を含む、テレビ会議を含む。
図6は、ライブストリーミング、サーバ制御のストリーミング、および会話サービスに適する方法の追加的なステップを示す実施形態を示す。方法は、ステップS50で開始し、これは図1のステップS1の実施形態であある。ステップS50は、通信チャネル上でIRAPピクチャを含むビデオビットストリームを受信することを含む。IRAPピクチャはその後、図1のステップS3で復号化される。続くステップS51とS52は、図1のステップS2の実施形態を表す。ステップS51は、ビデオビットストリームにおける破損または損失の検出を受けて、フィードバックチャネル上でフィードバックメッセージを送信することを含む。フィードバックメッセージは、破損または損失したピクチャに対応するビデオビットストリーム内の位置を示す。次のステップS52は、フィードバックメッセージに基づいて生成されたDRAPピクチャを受信することを含む。方法はそして、図1のステップS4に続き、DRAPピクチャは、独占的な参照ピクチャとしてステップS3で復号化されたIRAPピクチャを用いて復号化される。
本実施形態では、ビデオビットストリームの符号化されたビデオデータは、通信チャネルを介して送信される。ユーザクライアントはそして、ビデオビットストリームにおける破損または損失したピクチャを検出し、コンパイルして、フィードバックチャネル上でフィードバックメッセージを送信する。例として、通信チャネルは、RTPを利用し、フィードバックチャネルは、RTCPを利用することができる。それにより、DRAPピクチャは生成され、独占的な参照ピクチャとして、IRAPピクチャを用いて符号化される。IRAPピクチャは、好ましくは、ビデオビットストリームにおける破損または損失のピクチャの位置の前の、ビットストリームにおける最も最近のIRAPピクチャである。この位置は、フィードバックメッセージにおいて示され、それにより、サーバは、DRAPピクチャを生成してフィードバックチャネルを介して送信することが許容される。
ユーザクライアントは従って、先に受信して復号化されたIRAPピクチャを用いて復号化された、受信したDRAPピクチャの位置から開始するビットストリームにおいて、ビデオデータの正しい復号化を出力を再開することができる。DRAPピクチャに続いて符号化されたピクチャは、好ましくは通信チャネルを介して受信され、これらのピクチャは、復号化され、ビデオ表示のために出力が再開される。
したがって、実施形態のDRAPピクチャは、ビデオビットストリームにおける破損または損失したピクチャに対処する効果的なツールとして使用することができ、それにより、そのような破損または損失のピクチャに続くランダムアクセスオペレーションが可能となる。
［例示的な実施形態3］
3番目の例示的な実施形態は、フィードバックチャネルが存在するライブストリーミングおよび会話サービスに関する。例えばこれは、RTCPフィードバックチャネルを伴ってRTPに基づき得る。フィードバックチャネルは、復号化のプロセスにおけるピクチャの損失またはあらゆるタイプの問題を報告するために使用され得る。典型的には、一対一のアプリケーションにおいて使用されるが、一対多数のシナリオにおいても使用され得る。一つの特定の例は、2方向のテレビ電話またはビデオ会議である。
クライアント復号器から送信されるフィードバックメッセージに対する、符号器からの典型的な従来の応答は、ビデオが破損したことを示し、ビデオをリフレッシュするためにIRAPピクチャを送信するためである。
本実施形態では、符号器はその代わりに、復号機において破損または損失し得るより新しいピクチャに代えて、予想のためにより古く先に受信したピクチャを用いてフィードバックメッセージに応答する。符号器は、復号器に対して、特定のピクチャは、ピクチャがロングタームのピクチャであることを示すことにより、復号化ピクチャバッファ（DPB）に維持されるべきであることをシグナリングし得る。より古いピクチャがIRAPピクチャである場合、符号器は、フィードバックメッセージを受信した後に、次のピクチャをDRAPピクチャとして符号化できる。復号器は、符号器に対するフィードバックメッセージにおいて、いつからビデオが破損したかを示す。符号器はそして、DRAPピクチャを符号化するためにIRAPピクチャを使用することができるかを把握する。
IRAPピクチャを要求することと比較して、DRAPピクチャを要求することの利点は、DRAPピクチャは、より良い圧縮効率性を有することである。
大規模なビデオ会議、すなわち、一対多数のビデオ会議では、会議サーバは、従来の技術に従うと、新しい参加者が会議に参加する毎に、送信者からコスト高のIRAPピクチャを要求する必要がある。しかしながら、実施形態のDRAPピクチャを用いることにより、そのような問題は解決する。新しい参加者がビデオ会議に参加する場合、会議サーバは、フィードバックチャネルを利用する等、ユニキャストで、先のIRAPピクチャをその参加者に送信する。会議サーバはその後、それに応じて、送信者からコスト高ではないDRAPピクチャを要求し得る。次のDRAPピクチャがビデオビットストリームに発生すると、新しい参加者は、ビデオ会議に参加することができる。この場合、参加者は、DRAPピクチャを復号化する際に、参照ピクチャとしてユニキャストの受信により会議サーバから受信したIRAPピクチャを用いる。
別のユースケースは、サーバ制御のストリーミングである。この例では、ユーザクライアントは、例えばリアルタイムストリーミングプロトコル（RTSP）における範囲の数を有するPLAY要求を用いることにより、サーバから伝達されるビデオビットストリームにおける特定の位置を要求する。サーバは、先のIRAPピクチャを、要求された範囲の開始に対応するDRAPピクチャに連結することにより、伝達されるビデオビットストリームを急いで構成し得る。
例えば、ユーザクライアントは、ビデオビットストリームにおける37sにおける位置での開始を要求し得る。サーバは、所望の開始位置に関連づけられたDRAPピクチャを識別する。サーバはそして、ビデオビットストリームの開始（位置0s）に対応するような、最も先のIRAPピクチャを、識別したDRAPピクチャと連結することにより、ビデオビットストリームをコンパイルし得る。
図17は、ユーザクライアント100への非RAPピクチャが続くIRAPピクチャを送信するサーバ200を示すシグナリング図を示す。非RAPピクチャは送信において損失する。ユーザクライアント100は、順に次のピクチャを受信する際に、ピクチャが損失していることを検出する。ユーザクライアント100はそして、サーバ200からDRAPピクチャを要求するフィードバックメッセージを送信し、どの受信したIRAPピクチャに依存すべきかを示す。サーバ200は、DRAPピクチャを符号化し、それをユーザクライアント100に送信し、ビデオビットストリームの非RAPピクチャが続く。
DRAPピクチャを受信した復号器は、DRAPピクチャに先行するデータを無視し得る。例えば、データは、破損した復号化されたピクチャとなる可能性があるので、復号器のプレ復号化バッファに存在し得る。
DRAPピクチャが上述したSEIメッセージのうちの一つを用いて示された場合、符号器は、復号化の順序でDRAPピクチャに先行するピクチャに問題があり得ることを強調するための1に等しい破損リンクフラグを設定することができる。
図7は、実施形態に従うビデオ通信方法を示すフローチャートである。方法は、ステップS60において、ユーザクライアントへ、通信チャネル上で少なくとも1つのIRAPピクチャを含むビデオビットストリームを送信することを含む。次のステップS61は、ユーザクライアントから、フィードバックチャネル上でフィードバックメッセージを受信することを含む。フィードバックメッセージは、ユーザクライアントにおいて破損または損失したピクチャに対応するビデオビットストリーム内の位置を示す。続くステップS62は、フィードバックメッセージに基づいて、DRAPピクチャに対する独占的な参照ピクチャとしてビデオビットストリームにおける前の（先の）IRAPピクチャを用いて、DRAPピクチャを符号化することを含む。DRAPピクチャは、ステップS62において、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化される。DRAPピクチャはそして、ステップS63においてユーザクライアントへ送信される。
上述し図7に示したビデオ通信方法は、好ましくは、図17に示し、また上述したような、サーバが一つ以上のユーザクライアントと通信を行うことにより実行される動作に対応する。したがって、ビデオ通信方法は、特に、ライブストリーミング、サーバ制御のストリーミング、および2方向ビデオ電話およびビデオ会議等の会話システムに適している。通信チャネルは、好ましくは、ビデオビットストリームを送信する為に、ネットワークプロトコルとしてRTPを用いる。ここで、RTCPは、フィードバックチャネルｔフィードバックメッセージの送信をサポートするために使用され得る。
特定の実施形態では、DRAPピクチャは、ステップS63において、通信チャネルを用いてユーザクライアントへ送信される。別の実施形態では、DRAPピクチャは、ステップS63において、フィードバックチャネルを用いてユーザクライアントへ送信される。
実施形態では、フィードバックメッセージは、例えば、破損または損失のピクチャのPOC値を示すことにより、破損または損失のピクチャを示す。ステップS62ではそして、POC値に基づいて識別または選択されたピクチャを、DRAPピクチャとして符号化することを含む。
実施形態では、サーバは、どのタイプのRAPピクチャを符号化し、フィードバックメッセージに応答してユーザクライアントに送信するかを選択するために、フィードバックメッセージに含まれる情報を用いる。したがって、サーバは、IRAPピクチャを用いるか、DRAPピクチャを用いるかの間で選択する。RAPピクチャタイプの検出は、好ましくは、フィードバックメッセージに含まれる情報と、破損または損失のピクチャに対応する時点におけるDPBのバッファ状態に基づく。この時点は、フィードバックメッセージに含まれる情報に基づいて、順に決定される。したがって、サーバは、ユーザクライアントが、そのDPBにすくなくとも一つ復号化されたIRAPピクチャを有するかを判定するためにその情報を用いる。ここで、そのような復号化されたIRAPピクチャはDRAPピクチャに対するピクチャとして使用され得る。したがって、ユーザクライアントのDPBが少なくとも一つの復号化されたIRAPピクチャを保存する場合、サーバは、好ましくは、最も最近のIRAPピクチャを選択し、一つ以上のIRAPピクチャがDPBにある場合、ステップS62においてDRAPピクチャを符号化する際に、それを参照ピクチャとして用いる。
しかしながら、サーバが、ユーザクライアントのDPBは、参照ピクチャとして使用され得る、保存されているIRAPピクチャを有さないと結論付けた場合、サーバは、IRAPピクチャを符号化し、それをユーザクライアントに送信する必要がある。したがって、この場合、ビットコストは、ピクチャが代わりにDRAPピクチャとして符号化される場合と比較して大きくなり得る。
特定の実施形態では、サーバは、破損または損失のピクチャが一旦検出されると、ユーザクライアントのDPBに保存されているIRAPピクチャを有する機会を増やすために、ロングタームのピクチャとして、全てまたは少なくともいくつかのIRAPピクチャを、ビデオビットストリームにおいてシグナリングし得る。
サーバにおける符号器は、ユーザクライアントにおける復号器と同様に、DPBへアクセスする。したがって、復号器におけるDPBのバッファ状態は、符号器におけるDPBのバッファ状態を模倣または反映しているので、符号器は、各時点において、復号器におけるDPBのバッファ状態を完全に把握している。
図8は、図7のビデオ通信方法の、追加的、オプション的なステップを示すフローチャートである。方法は、図7におけるステップS63から続く。次のステップS70は、出力の順序または復号化の順序でDRAPピクチャに続く少なくとも一つの非RAPピクチャをユーザクライアントに送信することを含む。少なくとも一つの非RAPピクチャは、参照ピクチャとして、ビデオビットストリームで復号化の順序におけるDRAPピクチャに先行するあらゆる非RAPピクチャを使用しない。
図9は、ピクチャのビデオストリームをビデオビットストリームに符号化するための方法を示すフローチャートである。方法は、ステップS80において、ビデオストリームにおけるn番目毎のピクチャをRAPピクチャとして符号化し、ビデオストリームにおける他のピクチャを非RAPピクチャとして符号化することを含む。
図10は、図9におけるステップS80の実施形態を示すフローチャートである。本実施形態は、ステップS81を含み、m番目毎のRAPピクチャをIRAPピクチャとして符号化し、他のRAPピクチャを、復号化の順序に従って各最も近接して先行するIRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャとして符号化することを含む。各DRAPピクチャは、ステップS81において、トレーリングピクチャとして符号化され、ビデオストリームにおけるランダムアクセスポイントを構成する。
したがって、本実施形態では、ビデオビットストリーム内のRAPの頻度は、パラメータnにより定義され、IRAPピクチャに関連するDRAPピクチャの頻度または割合は、パラメータmにより定義される。それにより、ステップS81の符号化の結果は、RAPピクチャとしてn番目毎のピクチャを有するビデオビットストリームであり、m番目毎のRAPピクチャはIRAPピクチャであり、残りのRAPピクチャはDRAPピクチャである。ビデオビットストリームにおける残りのピクチャは、非RAPピクチャ、すなわち、非RAP P-またはB-ピクチャである。
図11は、図9におけるステップS80の別の実施形態を示すフローチャートである。本実施形態はステップS82で開始し、少なくともRAPピクチャのサブセットに対して、IRAPピクチャとして、またはDRAPピクチャとしてRAPピクチャを符号化することの間のビットコスト差に基づいて、RAPピクチャがIRAPピクチャとして符号化されるかDRAPピクチャとして符号化されるかを決定（判定）することを含む。DRAPピクチャは、復号化の順序に従って、各最も近接して先行するIRAPピクチャを、DRAPピクチャに対する独占的な参照ピクチャとして用いて符号化される。DRAPピクチャは、トレーリングピクチャとして符号化され、ビデオストリームにおけるランダムアクセスポイントを構成する。
実施形態では、DRAPピクチャとしてRAPピクチャを符号化することに対する推定ビットコストが、IRAPピクチャとしてRAPピクチャを符号化することに対する推定ビットコストから閾値を引いたものより低い場合、方法は、ステップS83でDRAPピクチャとしてRAPピクチャを符号化し、それ以外は、ステップS84でIRAPピクチャとしてRAPピクチャを符号化することを含む。
したがって、実施形態では、DRAPピクチャとしてRAPピクチャを符号化することに対する推定ビットコスト（ビットコスト（DRAP））は、IRAPピクチャとしてRAPピクチャを符号化することに対する推定ビットコスト（ビットコスト（IRAP））と閾値（T）の差と、ステップS82で比較される。ビットコスト（DRAP）＜（ビットコスト（IRAP）−T）の場合、方法はステップS83へ続き、RAPピクチャはDRAPピクチャとして符号化される。しかしながら、ビットコスト（DRAP）≧（ビットコスト（IRAP）−T）の場合、方法はステップS84へ続き、RAPピクチャはIRAPピクチャとして符号化される。
これは、もしIRAPピクチャとしてRAPピクチャを符号化するビットコストが、DRAPピクチャとしてRAPピクチャを符号化するビットコストと実質的に等しい場合、または、TプラスDRAPピクチャとしてRAPピクチャを符号化するビットコストより大きくない場合、RAPは、IRAPピクチャとして符号化され、それ以外はDRAPピクチャとして符号化されることを意味する。
閾値Tは、好ましくは、IRAPピクチャは他のピクチャと独立したランダムアクセスを供するので、IRAPピクチャがDRAPピクチャに対して好まれるように、正の数である。Tは、ビデオビットストリームの、求まれた、または、測定されたビットレートに基づき得る。Tはまた、ビットコスト（DRAP）および／またはビットコスト（IRAP）に基づき得る。例えば、Tは、ビットコスト（DRAP）／ビットコスト（IRAP）＜1−cである場合にDRAPピクチャが選択され、それ以外の場合にIRAPピクチャが選択されるように、c×ビットコスト（IRAP）と等しいものであり得る。0から1の間のcの値、例えば0.25が、IRAPピクチャを選択するのに好ましい。
特定の実施形態では、方法はまた、DRAPピクチャとしてのRAPピクチャの符号化が、最大の距離より大きい、ビデオビットストリームにおける連続するIRAPピクチャ間の距離を導かない場合にのみ、ステップS82において、RAPピクチャはIRAPピクチャとして符号化されるか、DRAPピクチャとして符号化されるかの判定を行い、それ以外ではIRAPピクチャとしてRAPピクチャを符号化することを含む。
本実施形態では、非限定的な例であるが、説明として10s毎または60s毎のような、ビデオビットストリームにおける2つの連続するIRAPピクチャ間の最大の距離が存在する。DRAPとしてのRAPピクチャの符号化により、IRAP間の距離がこの最大の距離より大きくなる場合は、RAPピクチャは、ビットコストのあらゆる比較を必要とせず、IRAPピクチャとして符号化される。
［例示的な実施形態4］
4番目の例示的な実施形態は、先の例示的な実施形態で説明したあらゆるサービスに関する。
符号器は、ビデオシーケンスまたはストリームを符号化し、ランダムアクセスポイントに対して、IRAPピクチャまたはDRAPピクチャのいずれを用いるかを選択的に選ぶ一つのユースケースでは、ランダムアクセスの頻度は固定であり、IRAPピクチャに関連するDRAPピクチャの頻度も固定である。符号器は、ランダムアクセスポイントピクチャとして、n番目毎のピクチャを符号化する。他のピクチャは、非ランダムアクセスポイントピクチャとして符号化される。ランダムアクセスポイントピクチャ間では、符号器は、m番目毎のピクチャをIRAPピクチャとして符号化する。他のランダムアクセスポイントピクチャは、DRAPピクチャとして符号化され、オプション的に、最も先行する符号化されたIRAPピクチャを参照する。
2番目のユースケースでは、IRAPピクチャまたはDRAPピクチャとして特定の候補のランダムアクセスポイントピクチャを符号化することの間のビットコスト差を推定することにより、ランダムアクセスポイントピクチャがIRAPピクチャまたはDRAPピクチャとして符号化されるべきかについての決定がなされる。もしDRAPピクチャに対する推定ビットコストが、IRAPピクチャとしてピクチャを符号化することに対する推定ビットコストからTを引いたものより低い場合に、ピクチャがDRAPピクチャとして符号化されるように、当該決定を行うように、閾値Tが使用される。それ以外は、ピクチャはIRAPピクチャとして符号化される。
擬似コードでは、
となり、ここでTは、IRAPピクチャが好まれるような正の数であり得る。
出力のビットストリームにおけるIRAPピクチャ間の最大の距離が存在するように、この2番目のユースケースは、1番目のユースケースを組み合わされ得る。これは、DRAPとしての現在のピクチャの符号化の選択により、最大の距離より大きいIRAP距離が導かれない場合のみ、擬似コードを呼び出すことにより実現化され得る。もしそのような場合は、現在のピクチャは、DRAPピクチャとしてのピクチャの符号化を考慮せずに、IRAPピクチャとして符号化される。
実施形態の提案される解決策は、スクリーンコンテンツ符号化、並びに、一般的なコンテンツ符号化において、ほとんど同じランダムアクセスおよびIRAPピクチャのエラー耐性特性を維持しながら、IRAPピクチャで費やされる多くのビット数を削減すること目的とする。これは、ここでは、依存性ランダムアクセスポイント（DRAP）ピクチャと呼ぶ、新しいピクチャタイプ、を導入することによりなされる。DRAPピクチャは、P-ピクチャ等の時間的予想ピクチャであり、先のRAPピクチャを（およびいくつかの実施形態では他のDRAPピクチャも）参照することで十分であり得る。先のRAPピクチャは、ビデオシーケンスにおいてより早いピクチャの符号化された表現に対応するピクチャであり得る。また、先のRAPピクチャは、出力されないが、例えばシーンの背景を表すビデオシーケンスにおけるピクチャに対する良い参照を構成するのみのピクチャであり得る。
ランダムアクセスは、参照されるIRAPピクチャ（および関連すれば参照されるDRAPピクチャ）はDRAPピクチャの復号化の前に復号化されなければならないという制約を伴い、DRAPピクチャに対して供される。DRAPピクチャは、例えば、ビデオに渡る早送りに対してかなり有益である。同時に、ランダムアクセスに対するビットレートオーバーヘッドが最小に維持される。
別の制約は、DRAPピクチャに渡る予想が禁止されなければならないことである。DRAPピクチャに続く非RAPピクチャは、予想のために、DRAPピクチャに先行するあらゆる非RAPピクチャを使用してはならない。この制約の一つの代替的な説明は、復号化および出力の両方の順序でDRAPピクチャに続く非RAPピクチャは、復号化の順序でDRAPピクチャに先行するあらゆる非RAPピクチャを参照として用いないということである。
HEVC並びにAVC/H.264では、補助的強化情報（supplemental enhancement information（SEI））メッセージが存在し、これはリカバリポイントSEIと呼ばれる。リカバリポイントSEIメッセージは、復号器がランダムアクセスを開始した後に、または、符号器がビデオビットストリームにおける破損したリンクを示した後に、復号化処理がいつ表示に対して容認されるピクチャを提供するかを決定する際に、復号器を支援する。復号化処理がリカバリポイントSEIメッセージに関連付けられた復号化の順序で、ピクチャに対して開始された場合、このSEIメッセージにおいて特定された出力の順序におけるリカバリポイントにおける、またはそれに続く、全ての復号化されたピクチャは、コンテンツにおいて正しいか、略正しいかが示される。リカバリポイントSEIメッセージは、DRAPピクチャの機能性を実現化するために使用されることはできない。もしリカバリポイントSEIメッセージが、IRAPピクチャと共に送信された場合、復号化の順序においてそれに続く全てのピクチャは、DRAPピクチャまで復号化されなければならず、それは望ましくない。そして、リカバリポイントSEIメッセージは、DRAPピクチャと共に送信されることはできない。なぜならば、復号化の順序においてリカバリポイントSEIメッセージに先行する全てへの依存を示すことができないからである。
DRAPピクチャの表示は、DRAPピクチャの前の符号化されたビデオにおける既知の問題についての表示と組み合わせることが可能である。この表示セットを伴うDRAPピクチャに出くわした受信器は、データは誤りがあることが示されるので、DRAPに先行する全てを破棄することができる。
IRAPピクチャは、ランダムアクセスおよび符号化されたビデオに対するエラー耐性を供するために、周期的な手法で共通に使用される。一般的なビデオコンテンツに対しては、IRAPピクチャは、ビットレートに関して、P-ピクチャとして符号化するより3-5倍程度のコストがかかり、B-ピクチャとして符号化するより5-10倍程度のコストがかかる。0.5から1秒ごとにIRAPピクチャを挿入することはかなりのビットのコストとなる。
かなり静的なコンテンツを頻繁に有するビデオサービスは、スクリーン共有と監視ビデオを含む。スクリーン共有は、例えば、人々の間のライブコミュニケーションとして使用され得る。または、サーバのような他のコンピュータをモニタするために設定される。全てのこれらのサービスに対して、ビデオマテリアルを記録し保存することに、しばしば関心がもたれる。保存されたビデオマテリアルは、好ましくは、ランダムアクセスオペレーションを用いて簡単に検索されるべきである。同時に、帯域幅の使用を制限し、記憶スペースを確保するために、最小にビデオビットレートを維持することに関心がもたれる。
スクリーン共有とスクリーンモニタリング等の特定のスクリーンコンテンツサービスは、人気が高まっている。スクリーンコンテンツは、一般的なビデオコーディングの符号化よりも、ビデオコーティングに対して他の要求を行う。スクリーンコンテンツは、典型的には、鋭いエッジのウィンドウ、グラフィックスとテキスト、特徴のある色を含み、長い時間間隔に対して更新されないビデオピクチャのエリアを有する傾向にある。
HEVCバージョン1の開発に当たり、スクリーンコンテンツの符号化の特別な特徴は、明示的には示されていない。ゆえに、JCT-VCは、明確にスクリーンコンテンツコーディングをターゲットとするHEVCの拡張に従事している。
実施形態のDRAPピクチャは、ビットストリームの全体のビットコストを削減するために、いくつかのIRAPピクチャと置き換えることができる。また、ランダムアクセスポイントは、同じビットレートが与えられてより頻繁に置き換えることができる。DRAPピクチャ上のランダムアクセスは、まず先行するIRAPピクチャを復号化し、その後DRAPピクチャを復号化することによりなされる。
本発明の一つの実施形態において、イントラブロックまたはスキップブロックのみが、エラー耐性を向上させるために、DRAPピクチャに対して許容される。
特定の実施形態では、DRAPピクチャは、DRAPピクチャに対する独占的な参照ピクチャとしてIRAPピクチャを使用してスキップブロックとして、またはイントラブロックとして、DRAPピクチャのブロックを復号化することにより復号化される。
スキップブロックは、独占的な参照ピクチャとしてIRAPピクチャを用いて、スキップモードに従ってブロックを符号化することを示す。これは、スキップブロックに対するサンプル値または画素値が、あらゆる動き補償なしに、参照ピクチャにおいて並置されたブロックからコピーされることを意味する。DRAPピクチャのブロックに対するスキップモードおよびイントラモードの組み合わせにより、DRAPピクチャの符号化および復号化の効率的な手法となる。
したがって、変化していない、または、最も近く先行するIRAPピクチャに関連していくらかの定義された最小の差以上変化していないDRAPピクチャのこれらのブロックは、好ましくは、スキップブロックとして符号化および復号化される。ここで、変化している、または、参照ピクチャに関連して、定義される最小の参照以上に変化しているDRAPピクチャのブロックは、イントラブロックとして符号化および復号化される。
別の実施形態では、IRAPピクチャに並置されたブロックが別のIRAPピクチャに並置されたブロックと定義された閾値以上異ならない場合、DRAPピクチャのブロックはDRAPピクチャに対する独占的な参照ピクチャとしてIRAPピクチャを用いてスキップブロックとして符号化され、それ以外はイントラブロックとして符号化される。別のIRAPピクチャは、復号化の順序に従って、ビデオストリームにおいてIRAPピクチャに先行し、好ましくは、IRAPピクチャの符号化の前に符号化される、最も近く先行するIRAPピクチャである。特定の実施形態では、DRAPピクチャのブロックは、IRAPピクチャにおいて並置されたブロックが、別のIRAPピクチャ、および、復号化の順序に従って別のIRAPピクチャとIRAPピクチャとの間に存在する中間のピクチャにおいて並置されたブロックと一致または所定の閾値より変化しない場合に、DRAPピクチャに対する独占的な参照ピクチャとしててのIRAPピクチャを用いてスキップブロックとして符号化され、それ以外の場合は、イントラブロックとして符号化される。
イントラモードに従ったブロックの復号化、すなわち、イントラブロックの復号化は、、ITU-T H.265シリーズH：Audiovisual and multimedia systems, Infra structure of audiovisual services - Coding of moving video, High efficiency video codingの、セクション8.4 Decoding process for coding units coded in intra prediction modeに規定されるように実行されることが好ましい。インターモードに従ったブロックの復号化、すなわち、インターブロックの復号化は、ITU-T H.265シリーズH：Audiovisual and multimedia systems, Infra structure of audiovisual services - Coding of moving video, High efficiency video codingの、セクション8.5 Decoding process for coding units coded in inter prediction modeに規定されるように実行されることが好ましい。スキップブロック、すなわち、スキップフラグが1に等しい値を有するブロックの復号化は、特に、ITU-T H.265シリーズH：Audiovisual and multimedia systems, Infra structure of audiovisual services - Coding of moving video, High efficiency video codingの、8.5.4.1 Generalに記載されている。
HEVCでは、スキップモードは、残りのデータがスキップされる特例を伴う新しいマージモードと同様である。マージモードは、4つの空間の候補、一つの時間的候補、およびゼロの動きの候補から、動きのパラメータを選択する。したがって、スキップされたブロックは、好ましくは、選択されたゼロの動きの候補を伴い、HEVCにおけるスキップモードにしたがって復号化される。
第一の観点によれば、ビデオビットストリームを符号化するための方法が提供される。方法において、IRAPピクチャは符号化され、IRAPピクチャに依存するのみのインターピクチャは符号化される。ここで、インターピクチャは、依存性ランダムアクセスポイント（DRAP）ピクチャとして参照される。
第二の観点によれば、ビデオビットストリームを復号化するための方法が提供される。方法において、イントラランダムアクセスポイント（IRAP）ピクチャは復号化され、IRAPピクチャに依存するのみのインターピクチャは復号化される。ここで、インターピクチャは、依存性ランダムアクセスポイント（DRAP）ピクチャとして参照され、DRAPピクチャはランダムアクセスオペレーションを実行するために使用される。
図18に示すように、第三の観点によれば、ビデオビットストリームを符号化するための符号器30が提供される。符号器30は、
IRAPピクチャを符号化し、
IRAPピクチャに依存するのみのインターピクチャを符号化するように適合された処理手段を有し、
ここで、インターピクチャは、依存性ランダムアクセスポイント（DRAP）ピクチャとして参照される。
第四の観点によれば、ビデオビットストリームを復号化するための復号器10が提供される。復号器10は、
イントラランダムアクセスポイント（IRAP）ピクチャを復号化し、
IRAPピクチャに依存するのみのインターピクチャを復号化するように適合された処理手段を有し、ここで、インターピクチャは、依存性ランダムアクセスポイント（DRAP）ピクチャとして参照され、DRAPピクチャはランダムアクセスオペレーションを実行するために使用される。
符号器30と復号器10のそれぞれにおいて、処理手段は、プロセッサとメモリを有し、当該メモリは、当該プロセッサにより実行された場合に、ここに説明した方法を実行するように構成された命令を含む。
符号器30は、例えばSEIメッセージにより例示される制御情報と共に、符号化されたビットストリームを送信するための出力部を有し、復号器10は、ビデオビットストリームと制御情報を受信するための入力部を有する。
符号器30と復号器10はそれぞれ、ユーザ端末またはネットワークノードのようなデバイスに設置され得る。ユーザ端末は、例えば、ビデオカメラ、携帯電話またはタブレットであり得る。
例示的な実施形態は、いくつかの手法において与えられる命令に対して提供し得ることを理解すべきである。
実施形態の利点は、ランダムアクセス構成ビットストリームにおいて、全てのRAPをIRAPピクチャとして符号化する代わりに、ランダムアクセスポイント（RAP）のいくつかをDRAPピクチャとして符号化することにより、多くの帯域が確保され、またはより高い全体の品質のために取引され得ることである。
DRAPピクチャにより、マルチチューナーのシナリオにおいて、ビットレートを実質的に増加させずに、また、複数の異なるストリームを全体に保存する必要なしに、短いチャネル切り替え時間を提供することが可能となる。
DRAPピクチャにより、アダプティブストリーミングのシナリオにおいて、表現を変更し、ビデオにおける異なる位置にジャンプするため能力を低減させずに、ビデオビットストリームのサイズを小さくすることが可能となる。
DRAPピクチャが、DRAPピクチャの前の符号化されたビデオにおける既知の問題についての表示が結合されている場合、受信器は、どのピクチャ以降でビデオは当該問題から解放されるかを確認することができる。
図12は、8番目のピクチャ毎の周期的なIDRピクチャを有する、HEVCに対するランダムアクセス構成を示す。典型的に、ブロードキャストされるコンテンツに対して、IRAPは、約0.5 - 2秒ごとに挿入される。30Hzのシーケンスに対して、これは、約15から60毎のピクチャは、IRAPピクチャであることを意味する。濃い灰色のピクチャはIDPピクチャであり、白いピクチャはP-ピクチャまたはB-ピクチャである。
スクリーンコンテンツ、または、ビデオが長い時間アップデートされない他の一般的なコンテンツに対する従来のランダムアクセスアプローチは、図14のようなものに見える。単純化した例において、IRAPピクチャは、3番目のピクチャごとに挿入される。説明の目的のために、ブロックはまた、より通常な解像度でHEVCで符号化されたビデオに対するものよりも、かなり大きい。この例では、P-ピクチャは、先のピクチャを参照する。全てのIRAPピクチャに対して、ピクチャにおける各ブロックをイントラ符号化することにより、ビデオは瞬間的にリフレッシュされる。イントラブロックは濃い灰色でマークされ、灰色のインターブロック（これらのいくつかはまたイントラブロックであり得る）と白いブロックはスキップブロックである。
本発明において、新しいRAPピクチャのタイプが導入され、それはDRAPとして参照される。DRAPピクチャにおけるブロックは、先のIRAPピクチャを参照するのみである。他のピクチャへの参照は許容されない。発明の一つの観点では、いくつかのRAPはIRAPピクチャの代わりにDRAPピクチャとして符号化される。予想パターンを図13に示す。濃い灰色のピクチャはIDPピクチャであり、中間の灰色のピクチャはDRAPピクチャであり、白いピクチャはP-ピクチャまたはB-ピクチャである。DRAPピクチャは、IDRピクチャを参照するのみである。
DRAPピクチャを復号化するために、先の参照されたIRAPピクチャは復号化される必要がある。イントラ符号化を用いてDRAPピクチャにおける全てのブロックが符号化されないことにより、多くのビットレートをセーブすることができる。さらに、先のIRAP（IDR、CRA、およびBLA）ピクチャを参照しなければならないことのみにより、あるレベルのランダムアクセスを達成することができる。本発明では、DRAPピクチャの制約が、SEIメッセージを用いてシグナリングされ得る。もしDRAPピクチャがSEIメッセージを用いてシグナリングされた場合、ビットストリームにおける特定のピクチャタイプとしてDRAPピクチャをシグナリングする必要はない。
本実施形態は、HEVC復号化および符号化、すなわち、HEVCの仕様または規格に従う復号化、およびビデオデータのHEVCの仕様または規格に準拠するビデオビットストリームへの符号化、に関連した使用に特に適している。HEVCの仕様または規格は、HEVCバージョン1および後続のバージョンを含むあらゆるバージョンのHEVCの仕様、および、スクリーンコンテンツの拡張、マルチビューの拡張およびスケーラブルな拡張を含む。
当業者であれば、HEVCは、実施形態を説明するための基本として使用されるが、実施形態は、AVC/H.264, H.263、MPEG-4、VP8およびVP9を含む時間予想符号化を用いた他のビデオ符号化規格にも等しく良好に機能することを理解するだろう。
ここで説明するIRAPピクチャは、イントラランダムアクセスポイントピクチャ、すなわち、ランダムアクセスポイントを構成し、それによりランダムアクセスポイントとして使用することができ、また、空間予想すなわちイントラ予想を用いて符号化および復号化され、それによりイントラ符号化されたブロックのみを含むピクチャ、を構成する。先に説明したように、HEVCの仕様によれば、IRAPピクチャは、IDRピクチャ、CRAピクチャ、またはBLAピクチャの形式であり得る。上述したような他のビデオ符号化の規格において、他の特定のピクチャタイプ名は、キーピクチャまたはキーフレーム等の、イントラランダムアクセスポイントピクチャを定義するために使用され得る。しかしながら、そのような他の特定のピクチャタイプはまた、そのような他のビデオ符号化の規格に対しては、それらが構成する限り使用される表現IRAPピクチャに含まれるとみなされ、それにより、ランダムアクセスポイントとして使用され、また、空間またはイントラ予想だけを用いて符号化および復号化される。ビデオコーディングにおいて、ビデオストリームのピクチャは、ときにフレームと参照される。
実施形態の別の観点は、ユーザクライアントに関する。ユーザクライアントは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化されるDRAPピクチャを取得するように構成される。ユーザクライアントはまた、ビットストリームのIRAPピクチャを取得するように構成される。ユーザクライアントは更に、IRAPピクチャを復号化するように構成される。ユーザクライアントは追加的に、IRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャを復号化するように構成される。ユーザクライアントはまた、復号化されたDRAPピクチャにおいてランダムアクセスオペレーションを実行するように構成される。
実施形態では、ユーザクライアントは、ビデオビットストリームにおいて、復号化の順序に従って最も近く先行するIRAPピクチャのみを、DRAPピクチャに対する独占的な参照ピクチャとして使用して、DRAPピクチャを復号化するように構成される。
実施形態では、ユーザクライアントは、出力の順序および符号化の順序において、DRAPピクチャに続くビデオビットストリームの少なくとも一つの非RAPピクチャを復号化するように構成される。少なくとも一つの非RAPピクチャは、参照ピクチャとして、ビデオビットストリームで復号化の順序におけるDRAPピクチャに先行するあらゆる非RAPピクチャを使用しない。
実施形態において、ユーザクライアントは、復号化されたDRAPピクチャを出力するように構成される。ユーザクライアントはまた、好ましくは、少なくとも一つの復号化された非RAPピクチャを復号化するように構成される。
特定の実施形態では、ユーザクライアントは、IRAPピクチャは出力されるべきではないことを示す、IRAPピクチャに関連付けられた出力フラグを受信するように構成される。したって、この特定の実施形態では、DRAPピクチャと続く非RAPピクチャは、例えば表示のための出力として、出力され、IRAPピクチャは出力されない。
実施形態では、ユーザクライアントは、DRAPピクチャに関連付けられたSEIメッセージに少なくとも部分的に基づいて、ビデオビットストリームにおけるDRAPピクチャを識別するように構成される。
実施形態において、ユーザクライアントは、DRAPピクチャのRPSに存在するIRAPピクチャの識別子に基づいて、DPBにおけるIRAPピクチャを識別するように構成される。
実施形態では、ユーザクライアントは、ビデオビットストリームの符号化されたビデオデータのセグメントをダウンロードするように構成される。セグメントは、IRAPピクチャで開始し、少なくとも一つのDRAPピクチャを含む。ユーザクライアントはまた、前方ジャンプまたは早送りの要求に基づいて、セグメントにおいてDRAPピクチャを識別するように構成される。
実施形態では、ユーザクライアントは、ビデオビットストリームの符号化されたビデオデータのセグメントの第1の部分をダウンロードするように構成される。セグメントの第1の部分は、IRAPピクチャを含み、セグメントは前方ジャンプ要求または表現切り替え要求に基づいて識別される。ユーザクライアントはまた、前方ジャンプ要求または表現切り替え要求に基づいて識別されたDRAPピクチャで開始するセグメントの第2の部分をダウンロードするように構成される。
実施形態では、ユーザクライアントは、現在のチャネルを表現する現在のビデオビットストリームを受信して復号化するように構成される。ユーザクライアントはまた、別のチャネルを表すビデオビットストリームを受信するように構成される。ユーザクライアントはさらに、メモリに、ビデオビットストリームの最も最近のIRAPピクチャまたは、最も最近のIRAPピクチャの復号化されたバージョンを、一時的に保存するように構成される。ユーザクライアントは、追加的に、別のチャネルを識別するチャネル切り替え要求に基づいて、メモリから、最も最近のIRAPピクチャの復号化されたバージョンの最も最近のIRAPピクチャを引き出すように構成される。ユーザクライアントはまた、チャネル切り替え要求を受けてビデオビットストリーム内の次のDRAPピクチャとしてDRAPピクチャを受信するように構成される。
実施形態では、ユーザクライアントは、通信チャネル上で、IRAPピクチャを含むビデオビットストリームを受信して復号化するように構成される。ユーザクライアントはまた、ビデオビットストリームにおける破損または損失の検出を受けて、フィードバックチャネル上でフィードバックメッセージを送信するように構成される。フィードバックメッセージは、破損または損失したピクチャに対応するビデオビットストリーム内の位置を示す。ユーザクライアントはさらに、フィードバックメッセージに基づいて生成されたDRAPピクチャを受信するように構成される。
ここに説明する方法および装置は、あらゆる手法において組み合わされ、再構成され得ることが理解されるだろう。
例えば、実施形態は、ハードウェアにおいて、または適切な処理回路による実行に対して、ソフトウェアにおいて実装され得る。または、それらの組み合わせでもあり得る。
ここに説明するステップ、機能、手順、モジュール、および／またはブロックは、あらゆる従来の技術、例えば、汎用の電子回路または特定用途の回路の両方を含む、離散または集積回路の技術、を用いて、ハードウェアに実装され得る。
特定の例は、一つ以上の適切に構成されたデジタル信号プロセッサおよび他の既知の電子回路、例えば、特別な機能を実行するために相互接続された離散ロジックゲート、または特定用途向け集積回路（ASICs）、を含む。
図19は、実施形態に従うユーザクライアント110の特定のハードウェア実装を示す。ユーザクライアント110は、DRAPピクチャとIRAPピクチャを取得するように構成された供給器111を有する。ユーザクライアント110はまた、IRAPピクチャを復号化し、IRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャを復号化するための復号器112を有する。ユーザクライアント110はさらに、DRAPピクチャにおいてランダムアクセスオペレーションを実行するように構成されたランダムアクセス部113を有する。
復号器112は、好ましくは、復号化ピクチャバッファ（DPB）を有する、または接続され、それは復号器112により生成された復号化されたピクチャを一時的に保存するように構成される。復号化されたピクチャは、好ましくは、ビデオビットストリームにおける後続のピクチャを復号化する際に参照ピクチャとして使用されるためにDPBに保存され、および／または、出力の順序に従ってピクチャが出力されるべきまで、DPBに保存される。
ピクチャ供給器111は、好ましくは、復号器112で復号化されるピクチャを転送するために、復号器112に接続される。それに応じて、復号器112は、DRAPピクチャをランダムアクセス部113へ転送するためにランダムアクセス部に接続され、ここで、DRAPピクチャは、ランダムアクセスオペレーションを実行するために使用される。
また、少なくともいくつかのステップにおいて、ここに説明する機能、手順、モジュール、および／またはブロックは、一つ以上のプロセッサまたは処理ユニット等の適切な処理回路による実行のためのコンピュータプログラム等のソフトウェアに実装され得る。
処理回路の例は、限定されないが、一つ以上のマイクロプロセッサ、一つ以上のデジタル信号プロセッサ（DSPs）、一つ以上の中央処理ユニット（CPUs）、ビデオ加速（acceleration）ハードウェア、および／または一つ以上のフィールド・プログラマブル・ゲート・アレイ(FPGA)または一つ以上のプログラマブル・ロジック・コントローラ（PLC）等の好適なプログラマブル論理回路を含む。
提案される技術が実装されるあらゆる従来の装置またはユニットの一般的な処理機能を再利用することが可能であることも理解されるべきである。例えば、現存のソフトウェアと再プログラミングすることにより、または、新しいソフトウェア構成を追加することにより、現存のソフトウェアを再利用することが可能であり得る。
特定の例では、ユーザクライアント120（図20参照）は、プロセッサ121と、プロセッサ121により実行可能な命令を含むメモリ122を有する。プロセッサ121は、DRAPピクチャとIRAPピクチャを取得するように動作する。プロセッサ121はまた、IRAPピクチャを復号化し、DRAPピクチャに対する独占的な参照ピクチャとしてIRAPピクチャを用いてDRAPピクチャを復号化するように動作する。プロセッサ121はさらに、DRAPピクチャにおいてランダムアクセスオペレーションを実行するように動作する。
実施形態において、ユーザクライアント120はまた、ビデオビットストリームを受信し、復号化されたピクチャを出力するように構成された入力／出力（I/O）部123を有する。I/O部123は、送受信器、受信器、および送信器として、または入力ポートと出力ポートとして、実装され得る。
ユーザクライアント120のメモリ122は、好ましくは、復号化されたピクチャを保存しアクセスするために、プロセッサ121により使用されるDPBを有する。
特定の実施形態では、プロセッサ121は、上記に説明したオペレーションを実行するために、メモリ122に保存された命令を実行する際に動作する。よって、プロセッサ121は、規定のソフトウェアの実行を可能とするために、メモリ122に相互接続される。
図26は、プロセッサ410と、付随するメモリ420と、通信回路430を有するユーザ装置（UE）400の例を示す概略的なブロック図である。
この特定の例では、ここに説明するステップ、機能、手順、モジュール、および／またはブロックの少なくともいくつかがコンピュータプログラム440に実装され、それは、一つ以上のプロセッサ410を含む処理回路による実行のためにメモリ420に対してロードされる。プロセッサ410とメモリ420は、規定のソフトウェアの実行を可能にするために、それぞれ相互接続される。通信回路430も、ビデオビットストリームおよび復号化されたピクチャの入力および／または出力を可能にするために、それぞれ、プロセッサ410および／またはメモリ420に相互接続される。
ユーザ装置400は、ビデオビットストリームを受信して処理することができるあらゆるデバイスまたは装置であり得る。例えば、ユーザ装置400は、ラップトップ、スマートフォン、タブレット、セットトップボックス等の、固定的か可搬的のいずれかのコンピュータであり得る。
「プロセッサ」という用語は、特定の処理を実行するためのプログラムコードまたはコンピュータプログラムの命令を実行、判定、またはタスクを演算することが可能なあらゆるシステムまたは装置として、一般的な意味で解釈される。
したがって、一つ以上のプロセッサを含む処理回路は、コンピュータプログラムを実行する際に、説明するような良く定義された処理タスクを実行するように構成される。
処理回路は、上記に説明したステップ、機能、手順、および／またはブロックを実行するために専用である必要はなく、他のタスクを実行可能であってもよい。
実施形態において、コンピュータプログラム440は、プロセッサ410により実行された場合に、プロセッサ410に、参照として使用される可能性があり、ビデオビットストリームでランダムアクセスポイントを構成するトレーリングピクチャとして符号化されたDRAPピクチャを取得させる命令を含む。プロセッサ410にはまた、ビデオビットストリームのIRAPピクチャを取得させる。プロセッサ410には更に、IRAPピクチャを復号化させ、IRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャを復号化させる。プロセッサ410には追加的に、復号化されたDRAPピクチャにおいてランダムアクセスオペレーションを実行させる。
提案される技術はまた、コンピュータプログラム440を含むキャリア450を提供する。キャリア450は、電子信号、光学信号、電磁気信号、磁気信号、電気信号、無線信号、マイクロ波信号、またはコンピュータ読み取り可能な記憶媒体450のうちのいずれかである。
例として、ソフトウェアまたはコンピュータプログラム440は、コンピュータプログラム製品として実現され、それは、通常は、運ばれるか、好ましくは非揮発性のコンピュータ読み取り可能な記憶媒体450であるコンピュータ読み取り可能な媒体440に保存される。コンピュータ読み取り可能な媒体450は、これらに限定されないが、ROM（Read-Only Memory）、RAM（Random Access Memory）、CD（Compact Disc）、DVD（Digital Versatile Disc）、ブルーレイディスク、USB（Universal Serial Bus）メモリ、HDD（Hard Disk Drive）記憶装置、フラッシュメモリ、磁気テープ、他のあらゆる従来のメモリ装置を含む、一つ以上の取り外し可能または取り外し不可能なメモリ装置を含み得る。したがって、コンピュータプログラム440は、プロセッサ410による実行のために、図26におけるユーザ装置400により表される、コンピュータまたは同等の処理装置の動作メモリにロードされ得る。
フロー図またはここに示した図表は、ゆえに、一つ以上のプロセッサにより実行された場合に、コンピュータフロー図または図表としてみなされ得る。対応するユーザクライアントは、機能モジュールのグループとして定義され得る。ここで、プロセッサにより実行される各工程は、機能モジュールに対応する。このケースでは、機能モジュールは、プロセッサ上で動作するコンピュータプログラムとして実装される。ゆえに、ユーザクライアントは、代替的に、機能モジュールのグループとして定義され得る。ここで、機能モジュールは、少なくとも一つのプロセッサ上で動作するコンピュータプログラムとして実装される。
したがって、メモリに属するコンピュータプログラムは、プロセッサにより実行された場合に、説明した工程および／またはタスクの少なくとも一部を実行するように構成された適切な機能モジュールのグループとして組織され得る。そのような機能モジュールの例は、図21にに示される。
図21は、機能モジュールを有するユーザクライアント130の概略ブロック図である。ユーザクライアント130は、DRAPピクチャとIRAPピクチャを取得するためのピクチャ供給器131をを有する。DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化される。ユーザクライアント130また、IRAPピクチャを復号化し、IRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャを復号化するための復号器132を有する。ユーザクライアント130はさらに、復号化されたDRAPピクチャにおいてランダムアクセスオペレーションを実行するためのランダムアクセス部を有する。
実施形態の更なる観点は、ビデオ通信サーバに関する。ビデオ通信サーバは、ユーザクライアントへ、通信チャネル上で少なくとも1つのIRAPピクチャを含むビデオビットストリームを送信するように構成される。ビデオ通信サーバはまた、ユーザクライアントからのフィードバックチャネル上でフィードバックメッセージを受信するように構成される。フィードバックメッセージは、ユーザクライアントにおいて破損または損失したピクチャに対応するビデオビットストリーム内の位置を示す。ビデオ通信サーバは更に、フィードバックメッセージに基づいて、ビデオビットストリームにおける先のIRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして用いてDRAPピクチャを符号化するように構成される。DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化される。ビデオ通信サーバは追加的に、ユーザクライアントへDRAPピクチャを送信するように構成される。
実施形態では、ビデオ通信サーバは、出力の順序または復号化の順序でDRAPピクチャに続く少なくとも一つの非RAPピクチャをユーザクライアントに送信するように構成される。少なくとも一つの非RAPピクチャは、参照ピクチャとして、ビデオビットストリームで復号化の順序におけるDRAPピクチャに先行するあらゆる非RAPピクチャを使用しない。
図22は、実施形態に従うビデオ通信サーバ210のハードウェア実装の図である。ビデオ通信サーバ210は、ビデオビットストリームとDRAPピクチャをユーザクライアントに送信するように構成された送信器211を有する。ビデオ通信サーバ210はまた、ユーザクライアントからのフィードバックチャネル上でフィードバックメッセージを受信するように構成された受信器213を有する。ビデオ通信サーバ210はさらに、フィードバックメッセージに基づいて、DRAPピクチャを符号化するように構成された符号器212を有する。
受信器213は、受信したフィードバックメッセージまたはそれに含まれる情報を符号器212に転送するために、好ましくは、符号器212に接続される。符号器212は、符号化されたDRAPピクチャを含む符号化されたピクチャを、ユーザクライアントへ送信するために送信器211に転送するために、好ましくは、送信器211に接続される。
図22は、分離した送信器211と受信器213を有するようなビデオ通信サーバ210を示す。代替的な実装では、データの受信と送信の両方を管理するために、結合した送受信器がビデオ通信サーバ210に存在し得る。送信器211と受信器213または、送受信器は、無線の送信および受信に対して実装され得る。また、それらは、有線の送信および受信に対して実装され得る。
図23は、ビデオ通信サーバ220のソフトウェアにおける実装を示す。特定の例では、ビデオ通信サーバ220は、プロセッサ221と、プロセッサ221により実行可能な命令を含むメモリ222を有する。プロセッサ221は、ユーザクライアントへの送信のために、ビデオビットストリームとDRAPピクチャを出力するように動作する。プロセッサ121はまた、受信したフィードバックメッセージに基づいて、DRAPピクチャを符号化するように動作する。
実施形態では、ビデオ通信サーバ220はまた、ビデオビットストリームとDRAPピクチャをユーザクライアントに送信し、ユーザクライアントからフィードバックメッセージを受信するように構成されたI/O部223を有する。I/O部223は、送受信器、受信器、および送信器として、または入力ポートと出力ポートとして、実装され得る。
ビデオ通信サーバ220のメモリ222は、好ましくは、符号化処理の間に、再構成されたピクチャを保存しアクセスするために、プロセッサ221により使用されるDPBを有する。
特定の実施形態では、プロセッサ221は、上記に説明したオペレーションを実行するために、メモリ222に保存された命令を実行する際に動作する。よって、プロセッサ221は、規定のソフトウェアの実行を可能とするために、メモリ222に相互接続される。
図24は、機能モジュールを有するビデオ通信サーバ230の概略ブロック図である。ビデオ通信サーバ230は、ユーザクライアントへ、通信チャネル上で少なくとも1つのIRAPピクチャを含むビデオビットストリームを送信するための送信器231を有する。ビデオ通信サーバ230は、ユーザクライアントからのフィードバックチャネル上でフィードバックメッセージを受信するための受信器233も含む。フィードバックメッセージは、ユーザクライアントにおいて破損または損失したピクチャに対応するビデオビットストリーム内の位置を示す。ビデオ通信サーバは更に、フィードバックメッセージに基づいて、ビデオビットストリームにおける先のIRAPピクチャとDRAPピクチャに対する独占的な参照ピクチャとして用いてDRAPピクチャを符号化するための符号器232を有する。DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化される。ビデオ通信サーバ230の送信器231はさらに、DRAPピクチャをユーザクライアントへ送信するためのものである。
図26は、プロセッサ410と、付随するメモリ420と、通信回路430を有するビデオ通信サーバ400の例を示す概略的なブロック図である。この特定の例では、ここに説明するステップ、機能、手順、モジュール、および／またはブロックの少なくともいくつかがコンピュータプログラム440に実装され、それは、一つ以上のプロセッサ410を含む処理回路による実行のためにメモリ420に対してロードされる。
実施形態では、コンピュータプログラム440は、プロセッサ410により実行された場合に、プロセッサ410に、ユーザクライアントへの通信チャネル上で少なくとも1つのIRAPピクチャを含むビデオビットストリームを送信させる命令を含む。プロセッサ410にはまた、ユーザクライアントからのフィードバックチャネル上でフィードバックメッセージを受信させる。フィードバックメッセージは、ユーザクライアントにおいて破損または損失したピクチャに対応するビデオビットストリーム内の位置を示す。プロセッサ410には更に、フィードバックメッセージに基づいて、ビデオビットストリームにおける先のIRAPピクチャとDRAPピクチャに対する独占的な参照ピクチャとして用いてDRAPピクチャを符号化させる。DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化される。プロセッサ410には追加的に、ユーザクライアントへDRAPピクチャを送信させる。
実施形態の更なる観点は、ピクチャのビデオストリームをビデオビットストリームに符号化するための符号器に関する。符号器はビデオストリームにおいてn番目毎のピクチャをRAPピクチャとして符号化し、ビデオストリームにおいて他のピクチャを非RAPピクチャとして符号化するように構成される。符号器はまた、m番目毎のRAPピクチャをIRAPピクチャとして符号化し、他のRAPピクチャを、復号化の順序に従って各最も近接して先行するIRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャとして符号化することにより、n番目毎のピクチャを符号化するように構成される。各DRAPピクチャは、トレーリングピクチャとして符号化され、ビデオビットストリームにおけるランダムアクセスポイントを構成する。
実施形態の別の観点は、ピクチャのビデオストリームをビデオビットストリームに符号化するための符号器に関する。符号器はビデオストリームにおいてn番目毎のピクチャをRAPピクチャとして符号化し、ビデオストリームにおいて他のピクチャを非RAPピクチャとして符号化するように構成される。符号器はまた、少なくともRAPピクチャのサブセットに対して、IRAPピクチャとして、またはDRAPピクチャとしてRAPピクチャを符号化することの間のビットコスト差に基づいて、RAPピクチャがIRAPピクチャとして符号化されるかDRAPピクチャとして符号化されるかを決定（判定）することにより、n番目毎のピクチャを符号化するように構成される。DRAPピクチャは、復号化の順序に従って、各最も近接して先行するIRAPピクチャを、DRAPピクチャに対する独占的な参照ピクチャとして用いる符号器により符号化される。DRAPピクチャは、トレーリングピクチャとして符号化され、ビデオビットストリームにおけるランダムアクセスポイントを構成する。
実施形態では、符号器は、DRAPピクチャとしてRAPピクチャを符号化することに対する推定ビットコストが、IRAPピクチャとしてRAPピクチャを符号化することに対する推定ビットコストから閾値を引いたものより低い場合、DRAPピクチャとしてRAPピクチャを符号化し、それ以外は、IRAPピクチャとしてRAPピクチャを符号化するように構成される。
実施形態では、DRAPピクチャとしてのRAPピクチャの符号化が、最大の距離より大きい、ビデオビットストリームにおける連続するIRAPピクチャ間の距離を導く場合にのみ、RAPピクチャはIRAPピクチャとして符号化されるか、DRAPピクチャとして符号化されるかの判定を行い、それ以外ではIRAPピクチャとしてRAPピクチャを符号化するように構成される。
符号器は、機能モジュールとして含む、ハードウェア、ソフトウェア、またはそれらの組み合わせで、実装され得る。図25は、符号器300のソフトウェアにおける実装の図である。特定の例では、符号器300は、プロセッサ301と、プロセッサ301により実行可能な命令を含むメモリ302を有する。プロセッサ301は、ビデオストリームにおいてn番目毎のピクチャをRAPピクチャとして符号化し、ビデオストリームにおいて他のピクチャを非RAPピクチャとして符号化するように動作する。
実施形態では、符号器300はまた、ビデオビットストリームの符号化されたピクチャを出力するように構成されたI/O部303を有する。I/O部303はまた、好ましくは、符号化されるピクチャを受信するように構成される。I/O部303は、送受信器、受信器、および送信器として、または入力ポートと出力ポートとして、実装され得る。
符号器300のメモリ302は、好ましくは、符号化処理の間に、再構成されたピクチャを保存しアクセスするために、プロセッサ301により使用されるDPBを有する。
特定の実施形態では、プロセッサ301は、上記に説明したオペレーションを実行するために、メモリ302に保存された命令を実行する際に動作する。よって、プロセッサ301は、規定のソフトウェアの実行を可能とするために、メモリ302に相互接続される。
図26は、プロセッサ410と、付随するメモリ420と、通信回路430を有する符号器400の例を示す概略的なブロック図である。この特定の例では、ここに説明するステップ、機能、手順、モジュール、および／またはブロックの少なくともいくつかがコンピュータプログラム440に実装され、それは、一つ以上のプロセッサ410を含む処理回路による実行のためにメモリ420に対してロードされる。
実施形態では、コンピュータプログラム440は、プロセッサ410により実行された場合に、プロセッサ410にn番目毎のピクチャをRAPピクチャとして符号化させ、ビデオストリームにおいて他のピクチャを非RAPピクチャとして符号化させる命令を含む。プロセッサにはまた、m番目毎のRAPピクチャをIRAPピクチャとして符号化させ、他のRAPピクチャを、復号化の順序に従って各最も近接して先行するIRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャとして符号化させることにより、n番目毎のピクチャを符号化させる。各DRAPピクチャは、トレーリングピクチャとして符号化され、ビデオビットストリームにおけるランダムアクセスポイントを構成する。
別の実施形態では、コンピュータプログラム440は、プロセッサ410により実行された場合に、プロセッサ410にn番目毎のピクチャをRAPピクチャとして符号化させ、ビデオストリームにおいて他のピクチャを非RAPピクチャとして符号化させる命令を含む。プロセッサにはまた、少なくともRAPピクチャのサブセットに対して、IRAPピクチャとして、またはDRAPピクチャとしてRAPピクチャを符号化することの間のビットコスト差に基づいて、RAPピクチャがIRAPピクチャとして符号化されるかDRAPピクチャとして符号化されるかを決定（判定）することにより、n番目毎のピクチャを符号化させる。DRAPピクチャは、復号化の順序に従って、各最も近接して先行するIRAPピクチャを、DRAPピクチャに対する独占的な参照ピクチャとして用いる符号器により符号化される。DRAPピクチャは、トレーリングピクチャとして符号化され、ビデオビットストリームにおけるランダムアクセスポイントを構成する。
上記に説明した実施形態は、本発明のいくつかの説明的な例として理解されるべきである。本発明の範囲を逸脱しない限り、様々な改良、組み合わせ、および、変更が、実施形態に対してなされ得ることを、当業者は理解するだろう。特に、異なる実施形態における異なる部分の解決策も、技術的に可能であれば、他の構成に結合され得る。しかしながら、本発明の範囲は、付随の請求項により定義される。

Claims (46)

  1. ビデオビットストリームにおいてランダムアクセスオペレーションを実行するための方法であって、
    依存性ランダムアクセスポイント（DRAP）ピクチャを取得すること（S1）と、ここで、前記DRAPピクチャは、参照として使用される可能性があり前記ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化され、
    前記ビデオビットストリームのイントラランダムアクセスポイント（IRAP）ピクチャを取得すること（S2）と、
    前記IRAPピクチャを復号化すること（S3）と、
    前記DRAPピクチャに対する独占的な参照ピクチャとして前記IRAPピクチャを用いて前記DRAPピクチャを復号化すること（S4）と、
    前記復号化されたDRAPピクチャにおいてランダムアクセスオペレーションを実行すること（S5）を含む、ことを特徴とする方法。
  2. 前記DRAPピクチャを取得すること（S1）は、前記DRAPピクチャに関連付けられた補助的強化情報（SEI）メッセージに少なくとも部分的に基づいて、前記ビデオビットストリームにおける前記DRAPピクチャを識別すること（S1）を含む、ことを特徴とする請求項１に記載の方法。
  3. 前記IRAPピクチャを取得すること（S2）は、前記DRAPピクチャの参照ピクチャセットに含まれる前記IRAPピクチャの識別子に基づいて、復号化ピクチャバッファにおける前記IRAPピクチャを識別すること（S2）を含む、請求項１または２に記載の方法。
  4. 前記DRAPピクチャを取得すること（S1）と、前記IRAPピクチャを取得すること（S2）は、
    前記ビデオビットストリームの符号化されたビデオデータのセグメントであって、前記IRAPピクチャから開始して少なくとも一つのDRAPピクチャを含むセグメントをダウンロードすること（S10）と、
    前方ジャンプまたは早送りの要求に基づいて、前記セグメントにおける前記DRAPを識別すること（S11）を含む、ことを特徴とする請求項１から３のいずれか１項に記載の方法。
  5. 前記DRAPピクチャを取得すること（S1）と、前記IRAPピクチャを取得すること（S2）は、
    前記ビデオビットストリームの符号化されたビデオデータのセグメントの第１の部分をダウンロードすること（S20）と、ここで前記セグメントの前記第１の部分は、前記IRAPピクチャを含み、前記セグメントは前方ジャンプの要求または表現切り替えの要求に基づいて識別され、
    前記前方ジャンプの要求または前記表現切り替えの要求に基づいて識別される前記DRAPピクチャから開始する前記セグメントの第２の部分をダウンロードすること（S21）を含む、ことを特徴とする請求項１から３のいずれか１項に記載の方法。
  6. 前記DRAPピクチャを復号化すること（S4）は、前記復号化の順序に従って、前記ビデオビットストリームにおいて最も近く先行するIRAPピクチャを、前記DRAPピクチャに対する前記独占的な参照ピクチャとして用いて前記DRAPピクチャを復号化する（S4）ことを含む、ことを特徴とする請求項１から５のいずれか１項に記載の方法。
  7. 出力の順序および復号化の順序で前記DRAPピクチャに続く前記ビデオビットストリームの少なくとも一つの非ランダムアクセスポイント（非RAP）ピクチャを復号化すること（S30）を更に含み、前記少なくとも一つの非RAPは、前記ビデオビットストリームにおいて復号化の順序で先行する前記DRAPピクチャに先行するあらゆる非RAPピクチャを参照ピクチャとして使用しない、ことを特徴とする請求項１から６のいずれか１項に記載の方法。
  8. 前記復号化されたDRAPピクチャを出力すること（S32）と、
    前記少なくとも一つの復号化された非RAPピクチャを出力すること（S33）を更に含む、
    ことを特徴とする請求項７に記載の方法。
  9. 前記IRAPピクチャは出力されるべきではないことを示す、前記IRAPピクチャに関連付けられた出力フラグを受信すること（S31）を更に含む、ことを特徴とする請求項８に記載の方法。
  10. 現在のチャネルを表す現在のビデオビットストリームを受信して復号化すること（S40）と、
    別のチャネルを表す前記ビデオビットストリームを受信すること（S41）と、
    前記ビデオビットストリームの最も最近のIRAPピクチャまたは、当該最も最近のIRAPピクチャの復号化されたバージョンをメモリに一時的に保存すること（S42）を更に含み、前記DRAPピクチャを取得すること（S1）と前記IRAPピクチャを取得すること（S2）は、
    前記別のチャネルを識別するチャネル切り替え要求に基づいて、前記メモリから、前記最も最近のIRAPピクチャまたは前記最も最近のIRAPピクチャの前記復号化されたバージョンを引き出すこと（S43）と、
    前記チャネル切り替え要求を受けて前記ビデオビットストリーム内の次のDRAPピクチャとして前記DRAPピクチャを受信すること（S44）を更に含む、ことを特徴とする請求項１から３のいずれか１項に記載の方法。
  11. 前記IRAPピクチャを取得すること（S1）は、通信チャネル上で前記IRAPピクチャを含むビデオビットストリームを受信すること（S50）を含み、
    前記DRAPピクチャを取得すること（S2）は、
    前記ビデオビットストリームにおける破損または損失のピクチャの検出を受けて、フィードバックチャネル上でフィードバックメッセージを送信すること（S51）と、ここで、前記フィードバックメッセージは、前記破損または損失のピクチャに対応する前記ビデオビットストリーム内の位置を示し、
    前記フィードバックメッセージに基づいて生成される前記DRAPピクチャを受信すること（S52）を含む、ことを特徴とする請求項１から３のいずれか１項に記載の方法。
  12. ビデオ通信方法であって、
    少なくとも一つのイントラランダムアクセスポイント（IRAP）ピクチャを含むビデオビットストリームを、通信チャネル上でユーザクライアント（100）に送信すること（S60）と、
    前記ユーザクライアント（100）からフィードバックチャネル上でフィードバックメッセージを受信すること（S61）と、ここで、前記フィードバックメッセージは、前記ユーザクライアント（100）において破損または損失のピクチャに対応する前記ビデオビットストリーム内の位置を示し、
    依存性ランダムアクセスポイント（DRAP）ピクチャを、前記フィードバックメッセージに基づいて、前記ビデオビットストリームにおける前のIRAPピクチャを前記DRAPピクチャに対する独占的な参照ピクチャとして用いて符号化すること（S62）と、ここで、前記DRAPピクチャは、参照として使用される可能性があり前記ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化されており、
    前記DRAPピクチャを前記ユーザクライアント（100）に送信すること（S63）を含む、ことを特徴とする方法。
  13. 出力の順序および復号化の順序で前記DRAPピクチャに続く少なくとも一つの非ランダムアクセスポイント（非RAP）ピクチャを復号化すること（S70）を更に含み、前記少なくとも一つの非RAPは、前記ビデオビットストリームにおいて復号化の順序で前記DRAPピクチャに先行するあらゆる非RAPピクチャを参照ピクチャとして使用しない、ことを特徴とする請求項１２に記載の方法。
  14. ピクチャのビデオストリームをビデオビットストリームに符号化するための方法であって、
    前記ビデオストリームにおけるn番目毎のピクチャをランダムアクセスポイント（RAP）ピクチャとして符号化し、前記ビデオストリームにおける他のピクチャを非RAPピクチャとして符号化すること（S80）を含み、
    前記n番目毎のピクチャを符号化することは、
    m番目毎のRAPピクチャをイントラランダムアクセスポイント（IRAP）ピクチャとして符号化し、他のRAPピクチャを、前記DRAPピクチャに対する独占的な参照ピクチャとして復号化の順序従って、それぞれ最も近く先行するIRAPピクチャを用いて依存性ランダムアクセスポイント（DRAP）ピクチャとして、符号化し、ここで各DRAPピクチャは、参照として使用される可能性があり前記ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化される、ことを特徴とする方法。
  15. ピクチャのビデオストリームをビデオビットストリームに符号化するための方法であって、
    前記ビデオストリームにおけるn番目毎のピクチャをランダムアクセスポイント（RAP）ピクチャとして符号化し、前記ビデオストリームにおける他のピクチャを非RAPピクチャとして符号化すること（S80）を含み、
    前記n番目毎のピクチャを符号化すること（S80）は、
    前記RAPピクチャの少なくともサブセットに対して、前記RAPピクチャはイントラランダムアクセスポイント（IRAP）ピクチャとして符号化されるか、依存性ランダムアクセスポイント（DRAP）ピクチャとして符号化されるかを、前記RAPピクチャをIRAPピクチャとして符号化することとDRAPピクチャとして符号化することの間のビットコスト差に基づいて決定すること（S82）を含み、DRAPピクチャは、復号化の順序に従って、それぞれ最も近く先行するIRAPピクチャを、前記DRAPピクチャに対する独占的な参照ピクチャとして用いて符号化され、前記DRAPピクチャは、トレーリングピクチャとして符号化され、前記ビデオビットストリームにおけるランダムアクセスポイントを構成する、ことを特徴とする方法。
  16. 前記RAPピクチャがIRAPピクチャまたはDRAPピクチャとして復号化されるかを決定すること（S82）は、DRAPピクチャとしてRAPピクチャを符号化することに対する推定ビットコストが、IRAPピクチャとしてRAPピクチャを符号化することに対する推定ビットコストから閾値を引いたものより低い場合、前記RAPピクチャをDRAPピクチャとして符号化し（S83）、それ以外は、前記RAPピクチャをIRAPピクチャとして符号化すること（S84）を含む、ことを特徴とする請求項１５に記載の方法。
  17. 前記RAPピクチャがIRAPピクチャまたはDRAPピクチャとして復号化されるかを決定すること（S82）は、DRAPピクチャとしてのRAPピクチャの符号化が、最大の距離より大きく、ビデオビットストリームにおける連続するIRAPピクチャ間の距離を導く場合にのみ、RAPピクチャはIRAPピクチまたはDRAPピクチャとして符号化されるかを決定し、それ以外では前記RAPピクチャをIRAPピクチャとして符号化することを含む、ことを特徴とする請求項１５または１６に記載の方法。
  18. ユーザクライアント（100、1110、120）であって、
    前記ユーザクライアント（100、110、120）は、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化されるDRAPピクチャを取得するように構成され、
    前記ユーザクライアント（100、110、120）前記ビデオビットストリームのイントラランダムアクセスポイント（IRAP）ピクチャを取得するように構成され、
    前記ユーザクライアント（100、110、120）は、前記IRAPピクチャを復号化するように構成され、
    前記ユーザクライアント（100、110、120）は、前記IRAPピクチャをDRAPピクチャに対する独占的な参照ピクチャとして使用してDRAPピクチャを復号化するように構成され、
    前記ユーザクライアント（100、110、120）は、前記復号化されたDRAPピクチャにおいてランダムアクセスオペレーションを実行するように構成される、ことを特徴とするユーザクライアント。
  19. 前記ユーザクライアント（100、110、120）は、前記DRAPピクチャに関連付けられた補助的強化情報（SEI）メッセージに少なくとも部分的に基づいて、前記ビデオビットストリームにおける前記DRAPピクチャを識別するように構成される、ことを特徴とする請求項１８に記載のユーザクライアント。
  20. 前記ユーザクライアント（100、110、120）は、前記DRAPピクチャの参照ピクチャセットに含まれる前記IRAPピクチャの識別子に基づいて、復号化ピクチャバッファにおける前記IRAPピクチャを識別するように構成される、ことを特徴とする請求項１８または１９に記載のユーザクライアント。
  21. 前記ユーザクライアント（100、110、120）は、前記ビデオビットストリームの符号化されたビデオデータのセグメントであって、前記IRAPピクチャから開始して少なくとも一つのDRAPピクチャを含むセグメントをダウンロードするように構成され、
    前記ユーザクライアント（100、110、120）は、前方ジャンプまたは早送りの要求に基づいて、前記セグメントにおいて前記DRAPピクチャを識別するように構成される、ことを特徴とする請求項１８から２０のいずれか１項に記載のユーザクライアント。
  22. 前記ユーザクライアント（100、110、120）は、前記ビデオビットストリームの符号化されたビデオデータのセグメントの第１の部分をダウンロードするように構成され、ここで前記セグメントの前記第１の部分は、前記IRAPピクチャを含み、前記セグメントは前方ジャンプの要求または表現切り替えの要求に基づいて識別され、
    前記ユーザクライアント（100、110、120）は、前方ジャンプの要求または表現切り替えの要求に基づいて識別された前記DRAPピクチャで開始する前記セグメントの第２の部分をダウンロードするように構成される、ことを特徴とする請求項１８から２０のいずれか１項に記載のユーザクライアント。
  23. 前記ユーザクライアント（100、110、120）は、前記復号化の順序に従って、前記ビデオビットストリームにおいて最も近く先行するIRAPピクチャを、前記DRAPピクチャに対する前記独占的な参照ピクチャとして用いて前記DRAPピクチャを復号化するように構成されることを特徴とする請求項１８から２２のいずれか１項に記載のユーザクライアント。
  24. 前記ユーザクライアント（100、110、120）は、出力の順序および復号化の順序で前記DRAPピクチャに続く前記ビデオビットストリームの少なくとも一つの非ランダムアクセスポイント（非RAP）ピクチャを復号化するように構成され、前記少なくとも一つの非RAPは、前記ビデオビットストリームにおいて復号化の順序で前記DRAPピクチャに先行するあらゆる非RAPピクチャを参照ピクチャとして使用しない、ことを特徴とする請求項１８から２３のいずれか１項に記載のユーザクライアント。
  25. 前記ユーザクライアント（100、110、120）は、前記復号化されたIRAPピクチャを出力するように構成され、
    前記ユーザクライアント（100、110、120）は、前記少なくとも一つの復号化された非RAPピクチャを出力するように構成される、ことを特徴とする請求項２４に記載のユーザクライアント。
  26. 前記ユーザクライアント（100、110、120）は、前記IRAPピクチャは出力されるべきではないことを示す、前記IRAPピクチャに関連付けられた出力フラグを受信するように構成される、ことを特徴とする請求項２５に記載のユーザクライアント。
  27. 前記ユーザクライアント（100、110、120）は、現在のチャネルを表現する現在のビデオビットストリームを受信して復号化するように構成され、
    前記ユーザクライアント（100、110、120）は、別のチャネルを表す前記ビデオビットストリームを受信するように構成され、
    前記ユーザクライアント（100、110、120）は、前記ビデオビットストリームの最も最近のIRAPピクチャ、または前記最も最近のIRAPピクチャの復号化されたバージョンをメモリに一時的に保存するように構成され、
    前記ユーザクライアント（100、110、120）は、前記別のチャネルを識別するチャネル切り替え要求に基づいて、メモリから、前記最も最近のIRAPピクチャ、または、前記最も最近のIRAPピクチャの復号化されたバージョンを引き出すように構成され、
    前記ユーザクライアント（100、110、120）は、前記チャネル切り替え要求を受けてビデオビットストリーム内の次のDRAPピクチャとして前記DRAPピクチャを受信するように構成される、ことを特徴とする請求項１８から２０のいずれか１項に記載のユーザクライアント。
  28. 前記ユーザクライアント（100、110、120）は、通信チャネル上で、前記IRAPピクチャを含むビデオビットストリームを受信して復号化するように構成され、
    前記ユーザクライアント（100、110、120）は、前記ビデオビットストリームにおける破損または損失のピクチャの検出を受けて、フィードバックチャネル上でフィードバックメッセージを送信するように構成され、前記フィードバックメッセージは、前記破損または損失のピクチャに対応する前記ビデオビットストリーム内の位置を示し、
    前記ユーザクライアント（100、110、120）は、前記フィードバックメッセージに基づいて生成された前記DRAPピクチャを受信するように構成される、ことを特徴とする請求項１８から２０のいずれか１項に記載のユーザクライアント。
  29. 前記DRAPピクチャと前記IRAPピクチャを取得するように構成されたピクチャ供給器（111）と、
    前記IRAPピクチャを復号化し、前記DRAPピクチャに対する独占的な参照ピクチャとして前記IRAPピクチャを用いて前記DRAPピクチャを復号化するように構成された復号器（112）と、
    前記DRAPピクチャにおいて前記ランダムアクセスオペレーションを実行するように構成されたランダムアクセス部（113）を有する、ことを特徴とする請求項１８から２８のいずれか1項に記載のユーザクライアント。
  30. プロセッサ（121）と、
    前記プロセッサ（121）により実行可能な命令を含むメモリ（122）を有し、
    前記プロセッサ（121）は、前記DRAPピクチャと前記IRAPピクチャを取得するように動作し、
    前記プロセッサ（121）は、前記IRAPピクチャを復号化し、前記DRAPピクチャに対する前記独占的な参照ピクチャとして前記IRAPピクチャを用いて前記DRAPピクチャを復号するように動作し、
    前記プロセッサ（121）は、前記DRAPピクチャにおいて前記ランダムアクセスオペレーションを実行するように動作する、ことを特徴とする請求項１８から２８のいずれか1項に記載のユーザクライアント。
  31. ユーザクライアント（130）であって、
    ビデオビットストリームの依存性ランダムアクセスポイント（DRAP）ピクチャとイントラランダムアクセスポイント（IRAP）ピクチャを取得するためのピクチャ供給器（131）と、ここで、前記DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化され、
    前記IRAPピクチャを復号化し、前記IRAPピクチャを前記DRAPピクチャに対する独占的な参照ピクチャとして用いて前記DRAPピクチャを復号化するための復号器（132）と、
    前記DRAPピクチャにおいてランダムアクセスオペレーションを実行するように構成されたランダムアクセス部（133）を有する、ことを特徴とするユーザクライアント。
  32. ビデオ通信サーバ（200、210、220）であって、
    前記ビデオ通信サーバ（200、210、220）は、少なくとも一つのイントラランダムアクセスポイント（IRAP）ピクチャを含むビデオビットストリームを、通信チャネル上でユーザクライアント（100）に送信するように構成され、
    前記ビデオ通信サーバ（200、210、220）は、前記ユーザクライアント（100）からフィードバックチャネル上でフィードバックメッセージを受信するように構成され、ここで、前記フィードバックメッセージは、前記ユーザクライアント（100）において破損または損失のピクチャに対応する前記ビデオビットストリーム内の位置を示し、
    前記ビデオ通信サーバ（200、210、220）は、依存性ランダムアクセスポイント（DRAP）ピクチャを、前記フィードバックメッセージに基づいて、前記ビデオビットストリームにおける前のIRAPピクチャを前記DRAPピクチャに対する独占的な参照ピクチャとして用いて符号化するように構成され、ここで、前記DRAPピクチャは、参照として使用される可能性があり前記ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化され、
    前記ビデオ通信サーバ（200、210、220）は、前記DRAPピクチャを前記ユーザクライアント（100）に送信するように構成される、ことを特徴とするビデオ通信サーバ。
  33. 前記ビデオ通信サーバ（200、210、220）は、出力の順序および復号化の順序で前記DRAPピクチャに続く前記ビデオビットストリームの少なくとも一つの非ランダムアクセスポイント（非RAP）ピクチャを復号化するように構成され、前記少なくとも一つの非RAPは、前記ビデオビットストリームにおいて復号化の順序で前記DRAPピクチャに先行するあらゆる非RAPピクチャを参照ピクチャとして使用しない、ことを特徴とする請求項３２に記載のビデオ通信サーバ。
  34. 前記ユーザクライアント（100）から前記ビデオビットストリームと前記DRAPピクチャを送信するように構成される送信器（211）と、
    前記ユーザクライアント（100）から前記フィードバックチャネル上で前記フィードバックメッセージを受信するように構成される受信器（213）と、
    前記フィードバックメッセージに基づいて前記DRAPピクチャを符号化するように構成された符号器（213）と、を有することを特徴とする請求項３２または３３に記載のビデオ通信サーバ。
  35. プロセッサ（221）と、
    前記プロセッサ（221）により実行可能な命令を含むメモリ（222）を有し、
    前記プロセッサ（221）は、前記ユーザクライアントへの送信のために、前k8ビデオビットストリームと前記DRAPピクチャを出力するように動作し、
    前記プロセッサ（221）は、受信したフィードバックメッセージに基づいて、DRAPピクチャを符号化するように動作する、ことを特徴とする請求項３２または３３に記載のビデオ通信サーバ。
  36. ビデオ通信サーバ（230）であって
    少なくとも一つのイントラランダムアクセスポイント（IRAP）ピクチャを含むビデオビットストリームを、通信チャネル上でユーザクライアント（100）に送信するための送信器（231）と、
    前記ユーザクライアント（100）からフィードバックチャネル上でフィードバックメッセージを受信するための受信器（233）と、ここで、前記フィードバックメッセージは、前記ユーザクライアント（100）において破損または損失のピクチャに対応する前記ビデオビットストリーム内の位置を示し、
    依存性ランダムアクセスポイント（DRAP）ピクチャを、前記フィードバックメッセージに基づいて、前記ビデオビットストリームにおける前のIRAPピクチャを前記DRAPピクチャに対する独占的な参照ピクチャとして用いて符号化するための符号器（232）とを有し、
    前記DRAPピクチャは、参照として使用される可能性があり前記ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化され、
    前記送信器（231）は前記DRAPピクチャを前記ユーザクライアント（100）に送信するためのものでもある、ことを特徴とするビデオ通信サーバ。
  37. ピクチャのビデオストリームをビデオビットストリームに符号化するための符号器（30、300）であって、
    前記符号器（30、300）は、前記ビデオストリームにおけるn番目毎のピクチャをランダムアクセスポイント（RAP）ピクチャとして符号化し、前記ビデオストリームにおける他のピクチャを非RAPピクチャとして符号化するように構成され、
    前記符号器（30、300）は、m番目毎のRAPピクチャをイントラランダムアクセスポイント（IRAP）ピクチャとして符号化し、他のピクチャを依存性ランダムアクセスポイント（DRAP）ピクチャに対する独占的な参照ピクチャとして、復号化の順序に従ってそれぞれ最も近く先行するIRAPピクチャを用いて前記DRAPピクチャとして符号化するように構成され、
    各DRAPピクチャは、トレーリングピクチャとして符号化され、前記ビデオビットストリームにおけるランダムアクセスポイントを構成する、ことを特徴とする符号器。
  38. ピクチャのビデオストリームをビデオビットストリームに符号化するための符号器（30、300）であって、
    前記符号器（30、300）は、前記ビデオストリームにおけるn番目毎のピクチャをランダムアクセスポイント（RAP）ピクチャとして符号化し、前記ビデオストリームにおける他のピクチャを非RAPピクチャとして符号化するように構成され、
    前記符号器（30、300）は、少なくとも依存性ランダムアクセスポイント（DRAP）ピクチャのサブセットに対して、前記RAPピクチャをイントラランダムアクセスポイント（IRAP）ピクチャまたはDRAPピクチャとして符号化することの間のビットコストの差に基づいて、前記RAPピクチャを前記IRAPピクチャまたはDRAPピクチャとして符号化されるかを判定することにより、n番目毎のピクチャを符号化するように構成され、
    DRAPピクチャは、復号化の順序に従って、それぞれ最も近く先行するIRAPピクチャを、前記DRAPピクチャに対する参照ピクチャとして使用して復号化され、
    前記DRAPピクチャは、トレーリングピクチャとして符号化され、前記ビデオビットストリームにおけるランダムアクセスポイントを構成する、ことを特徴とする符号器。
  39. 前記符号器（30、300）は、DRAPピクチャとしてRAPピクチャを符号化することに対する推定ビットコストが、IRAPピクチャとしてRAPピクチャを符号化することに対する推定ビットコストから閾値を引いたものより低い場合、DRAPピクチャとして前記RAPピクチャを符号化し、それ以外は、前記RAPピクチャをIRAPピクチャとして符号化するように構成される、ことを特徴とする請求項３８に記載の符号器。
  40. DRAPピクチャとしての前記RAPピクチャの符号化が、最大の距離より大きい、前記ビデオビットストリームにおける連続するIRAPピクチャ間の距離を導く場合にのみ、RAPピクチャはIRAPピクチャまたはDRAPピクチャとして符号化されるかの判定を行い、それ以外ではIRAPピクチャとして前記RAPピクチャを符号化するように構成される、ことを特徴とする請求項３８または３９に記載の符号器。
  41. プロセッサ（301）と、
    前記プロセッサ（301）により実行可能な命令を含むメモリ（302）を有し、
    前記プロセッサ（301）は、前記ビデオストリームにおいてn番目毎のピクチャをRAPピクチャとして符号化し、前記ビデオストリームにおいて前記他のピクチャを非RAPピクチャとして符号化するように動作する、ことを特徴とする請求項３７から４０のいずれか１項に記載の符号器。
  42. コンピュータプログラム（440）であって、プロセッサ（410）により実行された場合に、当該プロセッサ（410）に、
    依存性ランダムアクセスポイント（DRAP）ピクチャを取得させ、ここで前記DRAPピクチャは、参照として使用される可能性があり、ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化され、
    前記ビデオビットストリームのイントラランダムアクセスポイント（IRAP）を取得させ、
    前記IRAPピクチャを復号化させ、
    前記DRAPピクチャに対する独占的な参照ピクチャとして前記IRAPピクチャを用いて前記DRAPピクチャを復号化させ、
    前記復号化されたDRAPピクチャにおいてランダムアクセスオペレーションを実行させる、命令を含むことを特徴とするコンピュータプログラム。
  43. コンピュータプログラム（440）であって、プロセッサ（410）により実行された場合に、当該プロセッサ（410）に、
    少なくとも一つのイントラランダムアクセスポイント（IRAP）ピクチャを含むビデオビットストリームを、通信チャネル上でユーザクライアント（100）に送信させ、
    前記ユーザクライアント（100）からフィードバックチャネル上でフィードバックメッセージを受信させ、ここで、前記フィードバックメッセージは、前記ユーザクライアント（100）において破損または損失のピクチャに対応する前記ビデオビットストリーム内の位置を示し、
    依存性ランダムアクセスポイント（DRAP）ピクチャを、前記フィードバックメッセージに基づいて、前記ビデオビットストリームにおける先のIRAPピクチャを前記DRAPピクチャに対する独占的な参照ピクチャとして用いて符号化させ、ここで、前記DRAPピクチャは、参照として使用される可能性があり前記ビデオビットストリームにおけるランダムアクセスポイントを構成するトレーリングピクチャとして符号化され、
    前記DRAPピクチャを前記ユーザクライアント（100）に送信させる、命令を含むことを特徴とするコンピュータプログラム。
  44. コンピュータプログラム（440）であって、プロセッサ（410）により実行された場合に、当該プロセッサ（410）に、
    前記ビデオストリームにおけるn番目毎のピクチャをランダムアクセスポイント（RAP）ピクチャとして符号化させ、前記ビデオストリームにおける他のピクチャを非RAPピクチャとして符号化させ、
    前記プロセッサ（410）に、m番目毎のRAPピクチャをイントラランダムアクセスポイント（IRAP）ピクチャとして符号化させ、他のピクチャを依存性ランダムアクセスポイント（DRAP）ピクチャに対する独占的な参照ピクチャとして、復号化の順序に従ってそれぞれ最も近く先行するIRAPピクチャを用いて前記DRAPピクチャとして符号化させることにより、前記n番目毎のピクチャを符号化させ、
    各DRAPピクチャは、トレーリングピクチャとして符号化され、前記ビデオビットストリームにおけるランダムアクセスポイントを構成する、命令を含むことを特徴とするコンピュータプログラム。
  45. コンピュータプログラム（440）であって、プロセッサ（410）により実行された場合に、当該プロセッサ（410）に、
    前記ビデオストリームにおけるn番目毎のピクチャをランダムアクセスポイント（RAP）ピクチャとして符号化させ、前記ビデオストリームにおける他のピクチャを非RAPピクチャとして符号化させ、
    前記プロセッサ（410）に、少なくとも依存性ランダムアクセスポイント（DRAP）ピクチャのサブセットに対して、前記RAPピクチャをイントラランダムアクセスポイント（IRAP）ピクチャまたはDRAPピクチャとして符号化することの間のビットコストの差に基づいて、前記RAPピクチャを前記IRAPピクチャまたはDRAPピクチャとして符号化されるかを判定させることにより、n番目毎のピクチャを符号化させ、
    DRAPピクチャは、復号化の順序に従って、それぞれ最も近く先行するIRAPピクチャを、前記DRAPピクチャに対する参照ピクチャとして使用して復号化され、
    前記DRAPピクチャは、トレーリングピクチャとして符号化され、前記ビデオビットストリームにおけるランダムアクセスポイントを構成する、命令を含むことを特徴とするコンピュータプログラム。
  46. 請求項４２から４４のいずれか１項に記載のコンピュータプログラム（440）を含むキャリア（450）であって、前記キャリア（450）は、電子信号、光学信号、電磁気信号、磁気信号、電気信号、無線信号、マイクロ波信号、またはコンピュータ読み取り可能な記憶媒体（450）のうちのいずれかである、ことを特徴とするキャリア。
JP2016568609A 2014-06-18 2015-04-13 ビデオビットストリームにおけるランダムアクセス Pending JP2017522767A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201462013630P 2014-06-18 2014-06-18
US62/013,630 2014-06-18
PCT/EP2015/057975 WO2015192991A1 (en) 2014-06-18 2015-04-13 Random access in a video bitstream

Publications (1)

Publication Number Publication Date
JP2017522767A true JP2017522767A (ja) 2017-08-10

Family

ID=53008459

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016568609A Pending JP2017522767A (ja) 2014-06-18 2015-04-13 ビデオビットストリームにおけるランダムアクセス

Country Status (5)

Country Link
US (2) US10542288B2 (ja)
JP (1) JP2017522767A (ja)
AR (1) AR100737A1 (ja)
TW (1) TWI571113B (ja)
WO (1) WO2015192991A1 (ja)

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2840349C (en) 2011-06-30 2017-07-04 Telefonaktiebolaget L M Ericsson (Publ) Reference picture signaling
WO2015192991A1 (en) * 2014-06-18 2015-12-23 Telefonaktiebolaget L M Ericsson (Publ) Random access in a video bitstream
BR112017015841B1 (pt) * 2015-02-04 2024-01-30 Telefonaktiebolaget Lm Ericsson (Publ) Dispositivo para decodificar amostras de ponto de acesso aleatório dependente, dispositivo para gerar um arquivo de recipiente de mídia, métodos relacionados e arquivo de recipiente de mídia
US9942552B2 (en) * 2015-06-12 2018-04-10 Intel Corporation Low bitrate video coding
CN106470341B (zh) * 2015-08-17 2020-10-02 恩智浦美国有限公司 媒体显示系统
CN106791870B (zh) * 2016-11-30 2019-11-05 华为技术有限公司 一种视频编码方法、视频解码方法以及相关设备
CN108076377B (zh) * 2017-12-26 2020-12-08 浙江大华技术股份有限公司 一种视频的存储、播放方法、装置、电子设备及存储介质
US11290983B2 (en) 2018-04-05 2022-03-29 Telefonaktiebolaget Lm Ericsson (Publ) Multi-stage sidelink control information
US11048745B2 (en) * 2018-06-22 2021-06-29 International Business Machines Corporation Cognitively identifying favorable photograph qualities
US10972656B2 (en) 2018-06-22 2021-04-06 International Business Machines Corporation Cognitively coaching a subject of a photograph
CN113273202A (zh) * 2019-01-04 2021-08-17 华为技术有限公司 基于子图像的随机接入
JP7238155B2 (ja) 2019-03-14 2023-03-13 ノキア テクノロジーズ オサケユイチア ビデオコーディングおよびデコーディングのための装置、方法、およびコンピュータプログラム
ES2946163T3 (es) 2019-05-15 2023-07-13 Huawei Tech Co Ltd Manejo de la herramienta de codificación del refinamiento del vector de movimiento del lado del decodificador (DMVR) para el remuestreo de imágenes de referencia en la codificación de vídeo
CN114073073B (zh) * 2019-07-08 2023-06-06 华为技术有限公司 一种支持混合nal单元的编解码方法和编解码器
US11323730B2 (en) * 2019-09-05 2022-05-03 Apple Inc. Temporally-overlapped video encoding, video decoding and video rendering techniques therefor
EP4117291A4 (en) * 2020-03-05 2024-03-27 LG Electronics, Inc. METHOD AND DEVICE FOR CODING/DECODING VIDEOS WITH MIXED UNITS AND METHOD FOR TRANSMITTING BIT STREAMS
US11276433B2 (en) 2020-06-10 2022-03-15 Rovi Guides, Inc. Systems and methods to improve skip forward functionality
US11277666B2 (en) * 2020-06-10 2022-03-15 Rovi Guides, Inc. Systems and methods to improve skip forward functionality
US11184675B1 (en) 2020-06-10 2021-11-23 Rovi Guides, Inc. Systems and methods to improve skip forward functionality
US11770498B2 (en) * 2020-09-29 2023-09-26 Lemon Inc. Supplemental enhancement information for multi-layer video streams
EP4252424A4 (en) * 2020-12-28 2024-05-29 Beijing Bytedance Network Technology Co., Ltd. CROSS RANDOM ACCESS POINT SAMPLE GROUP
US11368510B1 (en) 2021-04-30 2022-06-21 Zoom Video Communications, Inc. Video frame generation
CN117917075A (zh) * 2021-06-28 2024-04-19 抖音视界有限公司 扩展依赖随机访问点补充增强信息的增强信令通知

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007184909A (ja) * 2005-12-05 2007-07-19 Canon Inc 画像符号化装置、画像符号化装置の制御方法、プログラム並びに記憶媒体
JP2007306160A (ja) * 2006-05-09 2007-11-22 Canon Inc 画像符号化装置及び符号化方法並びに画像復号化装置及び復号化方法
US20100177776A1 (en) * 2009-01-09 2010-07-15 Microsoft Corporation Recovering from dropped frames in real-time transmission of video over ip networks
WO2013044075A2 (en) * 2011-09-23 2013-03-28 Qualcomm Incorporated Reference picture signaling and decoded picture buffer management
JP2014057338A (ja) * 2004-07-01 2014-03-27 Mitsubishi Electric Corp 記録媒体再生システム

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6115420A (en) * 1997-03-14 2000-09-05 Microsoft Corporation Digital video signal encoder and encoding method
AU2002228884A1 (en) 2000-11-03 2002-05-15 Compression Science Video data compression system
EP1264360B1 (en) * 2001-02-12 2006-06-07 The Morgan Crucible Company Plc Flow field plate geometries
US6993078B2 (en) * 2002-03-28 2006-01-31 International Business Machines Corporation Macroblock coding technique with biasing towards skip macroblock coding
KR100492567B1 (ko) * 2003-05-13 2005-06-03 엘지전자 주식회사 이동통신 시스템의 ｈｔｔｐ 기반 비디오 스트리밍 장치및 방법
US8291448B2 (en) * 2004-09-15 2012-10-16 Nokia Corporation Providing zapping streams to broadcast receivers
KR100718351B1 (ko) * 2005-09-28 2007-05-14 주식회사 팬택 동영상 파일의 요약 재생 시스템 및 이를 탑재한 이동통신단말기
BRPI0710236A2 (pt) * 2006-05-03 2011-08-09 Ericsson Telefon Ab L M método e aparelho para a reconstrução de mìdia, produto de programa de computador, aparelho para criar uma representação de mìdia, objeto de dados de ponto de acesso randÈmico, e, representação e documento ou recipiente de mìdia
US8582663B2 (en) * 2006-08-08 2013-11-12 Core Wireless Licensing S.A.R.L. Method, device, and system for multiplexing of video streams
CN101849417A (zh) * 2007-11-05 2010-09-29 汤姆森特许公司 用于快速信道改变和增加的容错性的可缩放视频编码方法
CN101938456B (zh) * 2009-06-30 2014-03-12 华为技术有限公司 一种减小媒体延迟的方法、设备及系统
US9706227B2 (en) * 2011-03-10 2017-07-11 Qualcomm Incorporated Video coding techniques for coding dependent pictures after random access
US9210430B2 (en) * 2012-01-19 2015-12-08 Sharp Kabushiki Kaisha Reference picture set signaling and restriction on an electronic device
WO2013172667A1 (en) * 2012-05-17 2013-11-21 Samsung Electronics Co., Ltd. Recording medium, reproducing device for performing trick play for data of the recording medium, and method thereof
EP2866440B1 (en) 2012-06-24 2018-08-08 Lg Electronics Inc. Image decoding method and apparatus using same
US9591303B2 (en) * 2012-06-28 2017-03-07 Qualcomm Incorporated Random access and signaling of long-term reference pictures in video coding
EP2858350A4 (en) * 2012-07-06 2016-05-04 Samsung Electronics Co Ltd METHOD AND DEVICE FOR MULTILAYER VIDEO DICTIONING FOR DIRECT ACCESS AND METHOD AND DEVICE FOR MULTILAYER VIDEO DECODING FOR DIRECT ACCESS
WO2014051409A1 (ko) * 2012-09-28 2014-04-03 삼성전자 주식회사 참조 픽처 정보를 이용한 병렬 처리 비디오 부호화 방법 및 장치, 병렬 처리 비디오 복호화 방법 및 장치
US9924179B2 (en) * 2013-01-10 2018-03-20 Samsung Electronics Co., Ltd. Method and apparatus for coding multilayer video, method and apparatus for decoding multilayer video
US9674533B2 (en) * 2013-04-05 2017-06-06 Qualcomm Incorporated Picture alignments in multi-layer video coding
WO2014168463A1 (ko) * 2013-04-12 2014-10-16 삼성전자 주식회사 랜덤 엑세스를 위한 멀티 레이어 비디오 부호화 방법 및 그 장치, 랜덤 엑세스를 위한 멀티 레이어 비디오 복호화 방법 및 그 장치
JP6361866B2 (ja) * 2013-05-09 2018-07-25 サン パテント トラスト 画像処理方法および画像処理装置
US10003815B2 (en) * 2013-06-03 2018-06-19 Qualcomm Incorporated Hypothetical reference decoder model and conformance for cross-layer random access skipped pictures
US10284862B2 (en) * 2013-07-14 2019-05-07 Sharp Kabushiki Kaisha Signaling indications and constraints
EP3038365B1 (en) * 2013-08-22 2021-01-13 Sony Corporation Encoding device, encoding method, transmission device, decoding device, decoding method, and reception device
WO2015053598A1 (ko) * 2013-10-12 2015-04-16 삼성전자 주식회사 멀티 레이어 비디오 부호화 방법 및 장치, 멀티 레이어 비디오 복호화 방법 및 장치
US10187662B2 (en) * 2013-10-13 2019-01-22 Sharp Kabushiki Kaisha Signaling parameters in video parameter set extension and decoder picture buffer operation
US10284858B2 (en) * 2013-10-15 2019-05-07 Qualcomm Incorporated Support of multi-mode extraction for multi-layer video codecs
CN104754341B (zh) * 2013-12-31 2019-02-26 华为技术有限公司 一种视频数据编码、解码的方法和装置
US10560710B2 (en) * 2014-01-03 2020-02-11 Qualcomm Incorporated Method for coding recovery point supplemental enhancement information (SEI) messages and region refresh information SEI messages in multi-layer coding
US9807406B2 (en) * 2014-03-17 2017-10-31 Qualcomm Incorporated Picture flushing and decoded picture buffer parameter inference for multi-layer bitstreams
WO2015192991A1 (en) * 2014-06-18 2015-12-23 Telefonaktiebolaget L M Ericsson (Publ) Random access in a video bitstream

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014057338A (ja) * 2004-07-01 2014-03-27 Mitsubishi Electric Corp 記録媒体再生システム
JP2007184909A (ja) * 2005-12-05 2007-07-19 Canon Inc 画像符号化装置、画像符号化装置の制御方法、プログラム並びに記憶媒体
JP2007306160A (ja) * 2006-05-09 2007-11-22 Canon Inc 画像符号化装置及び符号化方法並びに画像復号化装置及び復号化方法
US20100177776A1 (en) * 2009-01-09 2010-07-15 Microsoft Corporation Recovering from dropped frames in real-time transmission of video over ip networks
WO2013044075A2 (en) * 2011-09-23 2013-03-28 Qualcomm Incorporated Reference picture signaling and decoded picture buffer management

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
AKIRA FUJIBAYASHI: "Random access support for HEVC", JOINT COLLABORATIVE TEAM ON VIDEO CODING (JCT-VC) OF ITU-T SG16 WP3 AND ISO/IEC JTC1/SC29/WG11 4TH M, vol. JCTVC-D234, JPN6017048705, 15 January 2011 (2011-01-15), pages pp.1-8. *
MISKA M. HANNUKSELA: "MV-HEVC/SHVC HLS: On TSA and STSA pictures", JOINT COLLABORATIVE TEAM ON VIDEO CODING (JCT-VC) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JCTVC-Q0108, JPN6017048706, 18 March 2014 (2014-03-18), pages pp.1-8. *

Also Published As

Publication number Publication date
US10542288B2 (en) 2020-01-21
US20160219306A1 (en) 2016-07-28
AR100737A1 (es) 2016-10-26
TW201618549A (zh) 2016-05-16
TWI571113B (zh) 2017-02-11
US20200128276A1 (en) 2020-04-23
US11032575B2 (en) 2021-06-08
WO2015192991A1 (en) 2015-12-23

Similar Documents

Publication Publication Date Title
US11032575B2 (en) Random access in a video bitstream
US11856329B2 (en) Dynamic advertisement stream replacement
US11997313B2 (en) Dependent random access point pictures
JP5788101B2 (ja) メディアデータのネットワークストリーミング
KR102218385B1 (ko) 고속 전환을 위한 코덱 기법
EP2754302B1 (en) Network streaming of coded video data
US8918533B2 (en) Video switching for streaming video data
US11025952B2 (en) Video encoding/decoding method and device
US20100118938A1 (en) Encoder and method for generating a stream of data
US20150312303A1 (en) Determining whether to use sidx information when streaming media data
EP2664157B1 (en) Fast channel switching
WO2010069427A1 (en) Method and encoder for providing a tune- in stream for an encoded video stream and method and decoder for tuning into an encoded video stream
US20230027374A1 (en) Decoder, encoder and methods for mixing nal units of different nal unit types in video streams
EP2404451B1 (en) Processing of multimedia data
Pettersson et al. Dependent random access point pictures in HEVC
US20230224532A1 (en) Dynamic resolution change hints for adaptive streaming

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20171207

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20171222

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180319

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20180427