JP2022524618A - エンコーダ、デコーダ、および対応する方法 - Google Patents

エンコーダ、デコーダ、および対応する方法 Download PDF

Info

Publication number
JP2022524618A
JP2022524618A JP2021554984A JP2021554984A JP2022524618A JP 2022524618 A JP2022524618 A JP 2022524618A JP 2021554984 A JP2021554984 A JP 2021554984A JP 2021554984 A JP2021554984 A JP 2021554984A JP 2022524618 A JP2022524618 A JP 2022524618A
Authority
JP
Japan
Prior art keywords
picture
gdr
video
flag
tile
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.)
Granted
Application number
JP2021554984A
Other languages
English (en)
Other versions
JP7399977B2 (ja
Inventor
フヌ・ヘンドリー
イェ-クイ・ワン
ジアンレ・チェン
Original Assignee
ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by ホアウェイ・テクノロジーズ・カンパニー・リミテッド filed Critical ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Publication of JP2022524618A publication Critical patent/JP2022524618A/ja
Priority to JP2023184082A priority Critical patent/JP2024008969A/ja
Application granted granted Critical
Publication of JP7399977B2 publication Critical patent/JP7399977B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70Methods 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods 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/103Selection of coding mode or of prediction mode
    • H04N19/107Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods 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/136Incoming video signal characteristics or properties
    • H04N19/14Coding unit complexity, e.g. amount of activity or edge presence estimation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods 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/162User input
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods 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/17Methods 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/172Methods 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 picture, frame or field
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods 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/17Methods 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/174Methods 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 slice, e.g. a line of blocks or a group of blocks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods 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/188Methods 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 a video data packet, e.g. a network abstraction layer [NAL] unit
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods 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/1883Methods 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 relating to sub-band structure, e.g. hierarchical level, directional tree, e.g. low-high [LH], high-low [HL], high-high [HH]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/20Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video object coding
    • H04N19/23Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video object coding with coding of regions that are present throughout a whole video segment, e.g. sprites, background or mosaic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H04N19/31Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability in the temporal domain
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/43Hardware specially adapted for motion estimation or compensation
    • H04N19/433Hardware specially adapted for motion estimation or compensation characterised by techniques for memory access
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46Embedding additional information in the video signal during the compression process
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/12Systems in which the television signal is transmitted via one channel or a plurality of parallel channels, the bandwidth of each channel being less than the bandwidth of the television signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/55Motion estimation with spatial constraints, e.g. at image or region borders
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/633Control signals issued by server directed to the network components or client
    • H04N21/6332Control signals issued by server directed to the network components or client directed to client
    • H04N21/6336Control signals issued by server directed to the network components or client directed to client directed to decoder
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • H04N7/141Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/147Communication arrangements, e.g. identifying the communication as a video-communication, intermediate storage of the signals

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

ビデオデコーダによって実施される、コーディングされたビデオビットストリームを復号する方法が提供される。方法は、コーディングされたビデオビットストリームをビデオデコーダが受信するステップであって、コーディングされたビデオビットストリームは、コーディングされたビデオシーケンス(CVS)に対応する漸次復号リフレッシュ(GDR)フラグを含む、ステップと、GDRピクチャがCVSの中に存在するかどうかをGDRフラグの値に基づいてビデオデコーダによって決定するステップと、GDRピクチャが存在することをGDRフラグの値が示すとき、GDRピクチャにおいてCVSの復号をビデオデコーダによって開始するステップと、復号されたCVSに従ってビデオデコーダによって画像を生成するステップとを含む。ビデオエンコーダによって実施される符号化の対応する方法も開示される。

Description

関連出願の相互参照
本特許出願は、Fnu Hendryらによって2019年3月11日に出願された「Gradual Decoding Refresh in Video Coding」と題する米国仮特許出願第62/816,722号、およびFnu Hendryらによって2019年7月5日に出願された「Gradual Decoding Refresh in Video Coding」と題する米国仮特許出願第62/871,020号の利益を主張し、その各々が参照により本明細書に組み込まれる。
一般に、本開示は、ビデオコーディングにおける漸次復号リフレッシュをサポートする技法を説明する。より詳細には、本開示は、イントラランダムアクセスポイント(IRAP:intra random access point)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする。
比較的短いビデオでさえ、描くのに必要とされるビデオデータの量は相当であり得、このことは、帯域幅容量が限定された通信ネットワークを横断してデータがストリーミングまたは別の方法で通信されることになるときに困難をもたらす場合がある。したがって、ビデオデータは、一般に、現代の電気通信ネットワークを通じて通信される前に圧縮される。メモリリソースが限定されることがあるので、ビデオが記憶デバイス上に記憶されるときも、ビデオのサイズが問題であり得る。ビデオ圧縮デバイスは、しばしば、ソースにおいてソフトウェアおよび/またはハードウェアを使用して、送信または記憶の前にビデオデータをコーディングし、それによって、デジタルビデオ画像を描写するために必要とされるデータの数量を減らす。圧縮されたデータは、次いで、ビデオデータを復号するビデオ復元デバイスによって宛先において受信される。ネットワークリソースが限定され、より高いビデオ品質の需要が絶えず増大すると、画像品質における犠牲をほとんど伴わずに圧縮率を改善する、改善された圧縮および復元技法が望ましい。
第1の態様は、ビデオデコーダによって実施される、コーディングされたビデオビットストリームを復号する方法に関する。方法は、ビデオデコーダが、コーディングされたビデオビットストリームを受信するステップであって、コーディングされたビデオビットストリームは、コーディングされたビデオシーケンス(CVS:coded video sequence)に対応する漸次復号リフレッシュ(GDR:gradual decoding refresh)フラグを含む、ステップと、ビデオデコーダが、GDRピクチャがCVSの中に存在するかどうかをGDRフラグの値に基づいて決定するステップと、GDRピクチャが存在することをGDRフラグの値が示すとき、ビデオデコーダが、GDRピクチャにおいてCVSの復号を開始するステップと、ビデオデコーダが、復号されたCVSに従って画像を生成するステップとを含む。
本方法は、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
第1の態様それ自体による方法の第1の実装形式では、GDRフラグは、ビットストリームのシーケンスパラメータセットの中に含まれる。
第1の態様それ自体または第1の態様の先行する任意の実装形式による方法の第2の実装形式では、GDRフラグはgdr_enabled_flagと称される。
第1の態様それ自体または第1の態様の先行する任意の実装形式による方法の第3の実装形式では、GDRが有効化されているとき、GDRフラグの値は1である。
第1の態様それ自体または第1の態様の先行する任意の実装形式による方法の第4の実装形式では、GDRピクチャがビデオビットストリームのCVSの中に存在しないとき、GDRフラグは第2の値に設定されるように構成される。
第1の態様それ自体または第1の態様の先行する任意の実装形式による方法の第5の実装形式では、GDRフラグの値は0である。
第2の態様は、ビデオエンコーダによって実施される、ビデオビットストリームを符号化する方法に関する。方法は、ビデオエンコーダが、ビデオビットストリームのコーディングされたビデオシーケンス(CVS)の中に漸次デコーダリフレッシュ(GDR)ピクチャを符号化するステップと、ビデオエンコーダが、GDRピクチャがビデオビットストリームのCVSの中に存在することを示すための第1の値に、GDRフラグを設定するステップと、ビデオエンコーダが、ビデオデコーダに向かう送信のためにビデオビットストリームを記憶するステップとを含む。
本方法は、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
第2の態様それ自体による方法の第1の実装形式では、GDRフラグは、ビットストリームのシーケンスパラメータセットの中に符号化される。
第2の態様それ自体または第2の態様の先行する任意の実装形式による方法の第2の実装形式では、GDRフラグはgdr_enabled_flagと称される。
第2の態様それ自体または第2の態様の先行する任意の実装形式による方法の第3の実装形式では、GDRが有効化されているとき、GDRフラグの第1の値は1である。
第2の態様それ自体または第2の態様の先行する任意の実装形式による方法の第4の実装形式では、GDRピクチャがビデオビットストリームのCVSの中に存在しないとき、GDRフラグは第2の値に設定されるように構成される。
第2の態様それ自体または第2の態様の先行する任意の実装形式による方法の第5の実装形式では、GDRフラグの第2の値は0である。
第3の態様は、復号デバイスに関する。復号デバイスは、コーディングされたビデオビットストリームを受信するように構成された受信器と、受信器に結合されたメモリであって、命令を記憶する、メモリと、メモリに結合されたプロセッサとを含み、プロセッサは、復号デバイスに、コーディングされたビデオビットストリームを受信することであって、コーディングされたビデオビットストリームは、コーディングされたビデオシーケンス(CVS)に対応する漸次復号リフレッシュ(GDR)フラグを含む、ことと、GDRピクチャがCVSの中に存在するかどうかをGDRフラグの値に基づいて決定することと、GDRピクチャが存在することをGDRフラグの値が示すとき、GDRピクチャにおいてCVSの復号を開始することと、復号されたCVSに従って画像を生成することとをさせるために、命令を実行するように構成される。
復号デバイスは、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
第3の態様それ自体による復号デバイスの第1の実装形式では、復号デバイスは、生成された画像を表示するように構成されたディスプレイをさらに備える。
第4の態様は、符号化デバイスに関する。符号化デバイスは、命令を含むメモリと、メモリに結合されたプロセッサであって、符号化デバイスに、ビデオビットストリームのコーディングされたビデオシーケンス(CVS)の中で漸次デコーダリフレッシュ(GDR)ピクチャを符号化することと、GDRピクチャがビデオビットストリームのCVSの中に存在することを示すための第1の値にGDRフラグを設定することとをさせるために、命令を実施するように構成された、プロセッサと、プロセッサに結合された送信器であって、ビデオデコーダに向かってビデオビットストリームを送信するように構成された、送信器とを含む。
符号化デバイスは、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
第4の態様それ自体による符号化デバイスの第1の実装形式では、メモリは、送信器がビデオデコーダに向かってビットストリームを送信する前にビデオビットストリームを記憶する。
第5の態様は、コーディング装置に関する。コーディング装置は、符号化すべきピクチャを受信するか、または復号すべきビットストリームを受信するように構成された、受信器と、受信器に結合された送信器であって、ビットストリームをデコーダへ送信するか、または復号画像をディスプレイへ送信するように構成された、送信器と、受信器または送信器のうちの少なくとも1つに結合されたメモリであって、命令を記憶するように構成された、メモリと、メモリに結合されたプロセッサであって、本明細書で開示する方法のうちのいずれかを行うために、メモリの中に記憶された命令を実行するように構成された、プロセッサとを含む。
コーディング装置は、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
第5の態様それ自体によるコーディング装置の第1の実装形式では、画像を表示するように構成されたディスプレイをさらに備える。
第6の態様は、システムに関する。システムは、エンコーダと、エンコーダと通信しているデコーダとを含み、エンコーダまたはデコーダは、本明細書で開示する復号デバイス、符号化デバイス、またはコーディング装置を含む。
システムは、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
第7の態様は、コーディングするための手段に関する。コーディングするための手段は、符号化すべきピクチャを受信するか、または復号すべきビットストリームを受信するように構成された、受信手段と、受信手段に結合された送信手段であって、ビットストリームを復号手段へ送信するか、または復号画像を表示手段へ送信するように構成された、送信手段と、受信手段または送信手段のうちの少なくとも1つに結合された記憶手段であって、命令を記憶するように構成された、記憶手段と、記憶手段に結合された処理手段であって、本明細書で開示する方法のうちのいずれかを行うために、記憶手段の中に記憶された命令を実行するように構成された、処理手段とを含む。
コーディングするための手段は、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
本開示のより完全な理解のために、添付図面および発明を実施するための形態とともに理解される、以下の簡潔な説明を次に参照し、同様の参照番号は同様の部分を表す。
GDR技法を利用し得る例示的なコーディングシステムを示すブロック図である。 GDR技法を実施し得る例示的なビデオエンコーダを示すブロック図である。 GDR技法を実施し得るビデオデコーダの一例を示すブロック図である。 復号順序および提示順序における、リーディングピクチャ(leading picture)に対するIRAPピクチャと、トレーリングピクチャとの間の関係の描写である。 漸次復号リフレッシュ技法を示す図である。 望ましくない動き探索を示す概略図である。 本開示の一実施形態による、漸次復号リフレッシュ技法を実施するように構成されたビデオビットストリームを示す図である。 コーディングされたビデオビットストリームを復号する方法の一実施形態を示す図である。 ビデオビットストリームを符号化する方法の一実施形態を示す図である。 ビデオコーディングデバイスの概略図である。 コーディングするための手段の一実施形態の概略図である。
図1は、本明細書で説明するようなビデオコーディング技法を利用し得る例示的なコーディングシステム10を示すブロック図である。図1に示すように、コーディングシステム10は、後で宛先デバイス14によって復号されるべき符号化されたビデオデータを提供するソースデバイス12を含む。詳細には、ソースデバイス12は、コンピュータ可読媒体16を介して宛先デバイス14にビデオデータを提供し得る。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(たとえば、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーム機、ビデオストリーミングデバイスなどを含む、広範なデバイスのうちのいずれかを含み得る。場合によっては、ソースデバイス12および宛先デバイス14は、ワイヤレス通信のために装備されうる。
宛先デバイス14は、コンピュータ可読媒体16を介して、復号されるべき符号化されたビデオデータを受信し得る。コンピュータ可読媒体16は、符号化されたビデオデータをソースデバイス12から宛先デバイス14に移動させることが可能な任意のタイプの媒体またはデバイスを含み得る。一例では、コンピュータ可読媒体16は、ソースデバイス12が符号化されたビデオデータを宛先デバイス14へリアルタイムで直接送信することを可能にするための通信媒体を含み得る。符号化されたビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調されてよく、宛先デバイス14へ送信されてよい。通信媒体は、無線周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線路などの、任意のワイヤレスまたは有線の通信媒体を含み得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12から宛先デバイス14への通信を容易にするために有用であり得る任意の他の機器を含み得る。
いくつかの例では、符号化されたデータは、出力インターフェース22から記憶デバイスに出力され得る。同様に、符号化されたデータは、入力インターフェースによって記憶デバイスからアクセスされ得る。記憶デバイスは、ハードドライブ、Blu-ray(登録商標)ディスク、デジタルビデオディスク(DVD)、コンパクトディスク読取り専用メモリ(CD-ROM)、フラッシュメモリ、揮発性メモリもしくは不揮発性メモリ、または符号化されたビデオデータを記憶するための任意の他の好適なデジタル記憶媒体などの、分散されるかまたは局所的にアクセスされる様々なデータ記憶媒体のうちのいずれかを含み得る。さらなる一例では、記憶デバイスは、ソースデバイス12によって生成された符号化されたビデオを記憶し得るファイルサーバまたは別の中間記憶デバイスに相当し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介して記憶デバイスからの記憶済みのビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶すること、およびその符号化されたビデオデータを宛先デバイス14へ送信することが可能な、任意のタイプのサーバでありうる。例示的なファイルサーバは、(たとえば、ウェブサイト用の)ウェブサーバ、ファイル転送プロトコル(FTP)サーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む任意の標準データ接続を通じて符号化されたビデオデータにアクセスし得る。このことは、ファイルサーバ上に記憶された符号化されたビデオデータにアクセスするのに適した、ワイヤレスチャネル(たとえば、Wi-Fi接続)、有線接続(たとえば、デジタル加入者回線(DSL)、ケーブルモデムなど)、またはその両方の組合せを含み得る。記憶デバイスからの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せでありうる。
本開示の技法は、必ずしもワイヤレスの適用例または設定に限定されるとは限らない。本技法は、オーバー・ジ・エア・テレビ放送、ケーブルテレビ送信、衛星テレビ送信、動的適応ストリーミングオーバーHTTP(DASH)などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されるデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他の適用例などの、様々なマルチメディア適用例のうちのいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、コーディングシステム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオ電話などの適用例をサポートするために、一方向または二方向のビデオ送信をサポートするように構成され得る。
図1の例では、ソースデバイス12は、ビデオソース18、ビデオエンコーダ20、および出力インターフェース22を含む。宛先デバイス14は、入力インターフェース28、ビデオデコーダ30、およびディスプレイデバイス32を含む。本開示によれば、ソースデバイス12のビデオエンコーダ20および/または宛先デバイス14のビデオデコーダ30は、ビデオコーディングのための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または構成を含み得る。たとえば、ソースデバイス12は、外部カメラなどの外部のビデオソースからビデオデータを受信し得る。同様に、宛先デバイス14は、統合型ディスプレイデバイスを含むのではなく、外部のディスプレイデバイスとインターフェースし得る。
図1の図示したコーディングシステム10は一例にすぎない。ビデオコーディングのための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって行われうる。本開示の技法は一般にビデオコーディングデバイスによって行われるが、技法はまた、通常、「コーデック」と呼ばれる、ビデオエンコーダ/デコーダによって行われうる。その上、本開示の技法はまた、ビデオプリプロセッサによって行われうる。ビデオエンコーダおよび/またはデコーダは、グラフィックス処理ユニット(GPU)または同様のデバイスでありうる。
ソースデバイス12および宛先デバイス14は、ソースデバイス12が、宛先デバイス14への送信のために、コーディングされたビデオデータを生成するようなコーディングデバイスの例にすぎない。いくつかの例では、ソースデバイス12および宛先デバイス14は、ソースデバイス12および宛先デバイス14の各々がビデオ符号化および復号構成要素を含むように、実質的に対称的に動作し得る。したがって、コーディングシステム10は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオ電話のために、ビデオデバイス12、14の間での一方向または二方向のビデオ送信をサポートし得る。
ソースデバイス12のビデオソース18は、ビデオカメラなどのビデオキャプチャデバイス、前にキャプチャされたビデオを含むビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替形態として、ビデオソース18は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオと、アーカイブされたビデオと、コンピュータ生成されたビデオとの組合せを生成しうる。
場合によっては、ビデオソース18がビデオカメラであるとき、ソースデバイス12および宛先デバイス14は、いわゆるカメラフォンまたはビデオフォンを形成し得る。しかしながら、上述のように、本開示で説明する技法は、一般にビデオコーディングに適用可能であり得、ワイヤレスおよび/または有線の適用例に適用され得る。各場合において、キャプチャ、プリキャプチャ、またはコンピュータ生成されたビデオが、ビデオエンコーダ20によって符号化され得る。符号化されたビデオ情報は、次いで、出力インターフェース22によってコンピュータ可読媒体16上に出力され得る。
コンピュータ可読媒体16は、ワイヤレスブロードキャストもしくは有線ネットワーク送信などの一時的媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Blu-ray(登録商標)ディスク、もしくは他のコンピュータ可読媒体などの、記憶媒体(すなわち、非一時的記憶媒体)を含み得る。いくつかの例では、ネットワークサーバ(図示せず)が、たとえば、ネットワーク送信を介して、ソースデバイス12から符号化されたビデオデータを受信し、宛先デバイス14に符号化されたビデオデータを提供しうる。同様に、ディスクスタンピング設備などの媒体生産設備のコンピューティングデバイスが、ソースデバイス12から符号化されたビデオデータを受信し、符号化されたビデオデータを含むディスクを生産しうる。したがって、様々な例では、コンピュータ可読媒体16は、様々な形態の1つまたは複数のコンピュータ可読媒体を含むものと理解されうる。
宛先デバイス14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ブロックおよび他のコーディングされたユニット、たとえば、group of pictures (GOP)の特性および/または処理を記述するシンタックス要素を含む、ビデオエンコーダ20によって規定されるシンタックス情報を含んでよく、シンタックス情報はまた、ビデオデコーダ30によって使用される。ディスプレイデバイス32は、復号されたビデオデータをユーザに表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスのうちのいずれかを含み得る。
ビデオエンコーダ20およびビデオデコーダ30は、現在開発中の高効率ビデオコーディング(HEVC)規格などのビデオコーディング規格に従って動作してよく、HEVCテストモデル(HM)に準拠し得る。あるいは、ビデオエンコーダ20およびビデオデコーダ30は、あるいは、ムービングピクチャエキスパートグループ(MPEG)-4パート10と呼ばれる、国際電気通信連合電気通信規格セクタ(ITU-T)H.264規格、アドバンストビデオコーディング(AVC)、H.265/HEVC、またはそのような規格の拡張などの、他のプロプライエタリ規格または業界規格に従って動作してよい。しかしながら、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例は、MPEG-2およびITU-T H.263を含む。図1に示さないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は各々、オーディオエンコーダおよびデコーダと統合されてよく、共通のデータストリームまたは別個のデータストリームの中のオーディオとビデオの両方の符号化を処理するための、適切なマルチプレクサ-デマルチプレクサ(MUX-DEMUX)ユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠し得る。
ビデオエンコーダ20およびビデオデコーダ30は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、様々な好適なエンコーダ回路構成のうちのいずれかとして実装されてよい。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体の中にソフトウェアのための命令を記憶してよく、本開示の技法を行うために、1つまたは複数のプロセッサを使用してハードウェアで命令を実行してよい。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダの中に含められてよく、それらのいずれも、組み合わせられたエンコーダ/デコーダ(コーデック)の一部としてそれぞれのデバイスの中で統合されてよい。ビデオエンコーダ20および/またはビデオデコーダ30を含むデバイスは、集積回路、マイクロプロセッサ、および/またはセルラー電話などのワイヤレス通信デバイスを含み得る。
図2は、ビデオコーディング技法を実施し得るビデオエンコーダ20の一例を示すブロック図である。ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを行い得る。イントラコーディングは、所与のビデオフレーム内またはピクチャ内のビデオにおける空間的な冗長性を低減または除去するために、空間予測に依存する。インターコーディングは、ビデオシーケンスの隣接するフレーム内またはピクチャ内のビデオにおける時間的な冗長性を低減または除去するために、時間予測に依存する。イントラモード(Iモード)とは、いくつかの空間ベースのコーディングモードのうちのいずれかを指しうる。単方向(単予測とも呼ばれる)予測(Pモード)または双予測(双予測)とも呼ばれる)(Bモード)などのインターモードとは、いくつかの時間ベースのコーディングモードのうちのいずれかを指しうる。
図2に示すように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在ビデオブロックを受信する。図2の例では、ビデオエンコーダ20は、モード選択ユニット40、参照フレームメモリ64、加算器50、変換処理ユニット52、量子化ユニット54、およびエントロピーコーディングユニット56を含む。次に、モード選択ユニット40は、動き補償ユニット44、動き推定ユニット42、イントラ予測(intra-prediction)(イントラ予測(intra prediction)とも呼ばれる)ユニット46、および区分ユニット48を含む。ビデオブロック再構成のために、ビデオエンコーダ20はまた、逆量子化ユニット58、逆変換ユニット60、および加算器62を含む。ブロック境界をフィルタ処理して再構成ビデオからブロッキネスアーティファクトを除去するために、デブロッキングフィルタ(図2に示さず)も含まれてよい。所望される場合、デブロッキングフィルタは、通常、加算器62の出力をフィルタ処理することになる。デブロッキングフィルタに加えて、(ループ内またはループ後の)追加のフィルタも使用されてよい。そのようなフィルタは、簡潔のために図示されないが、所望される場合、(ループ内フィルタとして)加算器50の出力をフィルタ処理してよい。
符号化プロセス中、ビデオエンコーダ20は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割され得る。動き推定ユニット42および動き補償ユニット44は、1つまたは複数の参照フレームの中の1つまたは複数のブロックに対する受信ビデオブロックのインター予測コーディングを行って、時間予測を提供する。イントラ予測ユニット46は、あるいは、コーディングされるべきブロックと同じフレームまたはスライスの中の1つまたは複数の近傍のブロックに対する受信ビデオブロックのイントラ予測コーディングを行って、空間予測を提供しうる。ビデオエンコーダ20は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、複数のコーディングパスを行いうる。
その上、区分ユニット48は、前のコーディングパスにおける、前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分してよい。たとえば、区分ユニット48は、最初にフレームまたはスライスを最大コーディングユニット(LCU:largest coding unit)に区分してよく、レートひずみ分析(たとえば、レートひずみ最適化)に基づいてLCUの各々をサブコーディングユニット(サブCU)に区分してよい。モード選択ユニット40は、サブCUへのLCUの区分を示す4分木データ構造をさらに生じさせうる。4分木のリーフノードCUは、1つまたは複数の予測ユニット(PU:prediction unit)および1つまたは複数の変換ユニット(TU:transform unit)を含み得る。
本開示は、HEVCのコンテキストにおけるCU、PU、もしくはTU、または他の規格のコンテキストにおける同様のデータ構造(たとえば、H.264/AVCにおけるマクロブロックおよびそれらのサブブロック)のうちのいずれかを指すために、「ブロック」という用語を使用する。CUは、コーディングノード、PU、およびコーディングノードに関連するTUを含む。CUのサイズは、コーディングノードのサイズに対応し、形状が正方形である。CUのサイズは、8×8ピクセルから、最大値が64×64ピクセル以上のツリーブロックのサイズまでにわたりうる。各CUは、1つまたは複数のPUおよび1つまたは複数のTUを含み得る。CUに関連するシンタックスデータは、たとえば、1つまたは複数のPUへのCUの区分を記述し得る。CUが、スキップモードまたはダイレクトモードで符号化されるのか、イントラ予測モードで符号化されるのか、それともインター予測(inter-prediction)(インター予測(inter prediction)とも呼ばれる)モードで符号化されるのかの間で、区分モードは異なりうる。PUは、形状が非正方形となるように区分され得る。CUに関連するシンタックスデータはまた、たとえば、4分木による1つまたは複数のTUへのCUの区分を記述し得る。TUは、形状が正方形または非正方形(たとえば、長方形)であり得る。
モード選択ユニット40は、たとえば、誤差結果に基づいて、コーディングモード、すなわち、イントラモードまたはインターモードのうちの1つを選択してよく、残差ブロックデータを生成するために加算器50に、また参照フレームとして使用するための符号化ブロックを再構成するために加算器62に、得られたイントラコーディングまたはインターコーディングされたブロックを提供する。モード選択ユニット40はまた、動きベクトル、イントラモードインジケータ、区分情報などのシンタックス要素、および他のそのようなシンタックス情報を、エントロピーコーディングユニット56に提供する。
動き推定ユニット42および動き補償ユニット44は、高度に統合され得るが、概念的な目的のために別個に図示される。動き推定ユニット42によって実行される動き推定とは、ビデオブロックに対する動きを推定する、動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在フレーム(または、他のコーディングされたユニット)内でコーディング中の現在ブロックに対して、参照フレーム(または、他のコーディングされたユニット)内の予測ブロックと比べて、現在ビデオフレーム内または現在ピクチャ内でのビデオブロックのPUの変位を示してよい。予測ブロックとは、ピクセル差分の観点から、コーディングされるべきブロックによく合うものであるとわかるブロックであり、ピクセル差分は、絶対差分和(SAD:sum of absolute difference)、2乗差分和(SSD:sum of square difference)、または他の差分メトリックによって決定されてよい。いくつかの例では、ビデオエンコーダ20は、参照フレームメモリ64の中に記憶された参照ピクチャのサブ整数ピクセル位置に対する値を計算し得る。たとえば、ビデオエンコーダ20は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数ピクセル位置の値を補間してよい。したがって、動き推定ユニット42は、フルピクセル位置および分数ピクセル位置に対して動き探索を実行してよく、分数ピクセル精度を有する動きベクトルを出力してよい。
動き推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコーディングされたスライスの中のビデオブロックのPUのための動きベクトルを計算する。参照ピクチャは、参照フレームメモリ64の中に記憶された1つまたは複数の参照ピクチャをその各々が識別する、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択され得る。動き推定ユニット42は、計算された動きベクトルをエントロピー符号化ユニット56および動き補償ユニット44へ送る。
動き補償ユニット44によって行われる動き補償は、動き推定ユニット42によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成することを伴いうる。やはり、動き推定ユニット42および動き補償ユニット44は、いくつかの例では機能的に統合されてよい。現在ビデオブロックのPUのための動きベクトルを受信すると、動き補償ユニット44は、参照ピクチャリストのうちの1つの中で、動きベクトルが指し示す予測ブロックの位置を特定し得る。加算器50は、コーディング中の現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算することによって残差ビデオブロックを形成して、以下で説明するようにピクセル差分値を形成する。一般に、動き推定ユニット42は、ルーマ成分に対して動き推定を実行し、動き補償ユニット44は、ルーマ成分に基づいて計算された動きベクトルを、クロマ成分とルーマ成分の両方のために使用する。モード選択ユニット40はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30によって使用するための、ビデオブロックおよびビデオスライスに関連するシンタックス要素を生成し得る。
イントラ予測ユニット46は、上記で説明したように、動き推定ユニット42および動き補償ユニット44によって行われるインター予測の代替として、現在ブロックをイントラ予測し得る。詳細には、イントラ予測ユニット46は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット46は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化してよく、イントラ予測ユニット46(または、いくつかの例ではモード選択ユニット40)は、使用すべき適切なイントラ予測モードを、テストされたモードから選択してよい。
たとえば、イントラ予測ユニット46は、テストされた様々なイントラ予測モードに対して、レートひずみ分析を用いてレートひずみ値を計算してよく、テストされたモードの中から、レートひずみ特性が最良のイントラ予測モードを選択しうる。レートひずみ分析は、概して、符号化されたブロックと、符号化されたブロックを生じさせるために符号化された、符号化されていない元のブロックとの間のひずみ(すなわち、誤差)の量、ならびに符号化されたブロックを生じさせるために使用されるビットレート(すなわち、ビットの数)を決定する。イントラ予測ユニット46は、様々な符号化ブロックに対して、ひずみおよびレートから比率を計算して、ブロックに対してどのイントラ予測モードが最良のレートひずみ値を示すかを決定し得る。
加えて、イントラ予測ユニット46は、深度モデリングモード(DMM:depth modeling mode)を使用して深度マップの深度ブロックをコーディングするように構成され得る。モード選択ユニット40は、利用可能なDMMモードが、たとえば、レートひずみ最適化(RDO:rate-distortion optimization)を使用して、イントラ予測モードおよび他のDMMモードよりも良好なコーディング結果を生じさせるかどうかを決定し得る。深度マップに対応するテクスチャ画像に対するデータが、参照フレームメモリ64の中に記憶され得る。動き推定ユニット42および動き補償ユニット44はまた、深度マップの深度ブロックをインター予測するように構成され得る。
ブロックのためのイントラ予測モード(たとえば、従来のイントラ予測モード、またはDMMモードのうちの1つ)を選択した後、イントラ予測ユニット46は、ブロックのための選択されたイントラ予測モードを示す情報をエントロピーコーディングユニット56に提供し得る。エントロピーコーディングユニット56は、選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ20は、複数のイントラ予測モードインデックステーブルおよび複数の修正済みのイントラ予測モードインデックステーブル(コードワードマッピングテーブルとも呼ばれる)、様々なブロックに対する符号化コンテキストの定義、ならびにコンテキストの各々に対して使用すべき最確のイントラ予測モード、イントラ予測モードインデックステーブル、および修正済みのイントラ予測モードインデックステーブルの表示を含み得る構成データを、送信されるビットストリームの中に含めてよい。
ビデオエンコーダ20は、コーディング中の元のビデオブロックから、モード選択ユニット40からの予測データを減算することによって、残差ビデオブロックを形成する。加算器50は、この減算演算を行う1つまたは複数の構成要素を表す。
変換処理ユニット52は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を残差ブロックに適用して、残差変換係数値を含むビデオブロックを生じさせる。変換処理ユニット52は、DCTと概念的に同様の他の変換を行いうる。ウェーブレット変換、整数変換、サブバンド変換、または他のタイプの変換も使用され得る。
変換処理ユニット52は、残差ブロックに変換を適用して、残差変換係数のブロックを生じさせる。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。変換処理ユニット52は、得られた変換係数を量子化ユニット54へ送ってよい。量子化ユニット54は、変換係数を量子化してビットレートをさらに低減する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット54は、次いで、量子化変換係数を含む行列の走査を実行し得る。あるいは、エントロピー符号化ユニット56が走査を実行してもよい。
量子化に続いて、エントロピーコーディングユニット56は、量子化変換係数をエントロピーコーディングする。たとえば、エントロピーコーディングユニット56は、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)、確率区間区分エントロピー(PIPE)コーディング、または別のエントロピーコーディング技法を実行してよい。コンテキストベースのエントロピーコーディングの場合には、コンテキストは近傍のブロックに基づいてよい。エントロピーコーディングユニット56によるエントロピーコーディングに続いて、符号化ビットストリームが、別のデバイス(たとえば、ビデオデコーダ30)へ送信されてよく、または後で送信するかもしくは取り出すためにアーカイブされてよい。
逆量子化ユニット58および逆変換ユニット60は、それぞれ、逆量子化および逆変換を適用して、たとえば、後で参照ブロックとして使用するために、ピクセル領域における残差ブロックを再構成する。動き補償ユニット44は、参照フレームメモリ64のフレームのうちの1つの予測ブロックに残差ブロックを加算することによって、参照ブロックを計算し得る。動き補償ユニット44はまた、再構成された残差ブロックに1つまたは複数の補間フィルタを適用して、動き推定における使用のためのサブ整数ピクセル値を計算し得る。加算器62は、再構成された残差ブロックを動き補償ユニット44によって生じた動き補償された予測ブロックに加算し、参照フレームメモリ64の中に記憶するための再構成ビデオブロックを生じさせる。再構成ビデオブロックは、後続のビデオフレームの中のブロックをインターコーディングするための参照ブロックとして、動き推定ユニット42および動き補償ユニット44によって使用され得る。
図3は、ビデオコーディング技法を実施し得るビデオデコーダ30の一例を示すブロック図である。図3の例では、ビデオデコーダ30は、エントロピー復号ユニット70、動き補償ユニット72、イントラ予測ユニット74、逆量子化ユニット76、逆変換ユニット78、参照フレームメモリ82、および加算器80を含む。ビデオデコーダ30は、いくつかの例では、ビデオエンコーダ20(図2)に関して説明した符号化パスとは概して相反の、復号パスを実行し得る。動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルに基づいて予測データを生成し得るが、イントラ予測ユニット74は、エントロピー復号ユニット70から受信されたイントラ予測モードインジケータに基づいて予測データを生成し得る。
復号プロセス中、ビデオデコーダ30は、符号化されたビデオスライスのビデオブロックおよび関連するシンタックス要素を表す符号化されたビデオビットストリームを、ビデオエンコーダ20から受信する。ビデオデコーダ30のエントロピー復号ユニット70は、ビットストリームをエントロピー復号して、量子化係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成する。エントロピー復号ユニット70は、動きベクトルおよび他のシンタックス要素を動き補償ユニット72に転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルでシンタックス要素を受信し得る。
ビデオスライスがイントラコーディングされた(I)スライスとしてコーディングされるとき、イントラ予測ユニット74は、シグナリングされたイントラ予測モード、および現在フレームまたは現在ピクチャの、前に復号されたブロックからのデータに基づいて、現在ビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコーディングされた(たとえば、B、P、またはGPB)スライスとしてコーディングされるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルおよび他のシンタックス要素に基づいて、現在ビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの1つの中の参照ピクチャのうちの1つから生成され得る。ビデオデコーダ30は、参照フレームメモリ82の中に記憶された参照ピクチャに基づいてデフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト0およびリスト1を構成し得る。
動き補償ユニット72は、動きベクトルおよび他のシンタックス要素を構文解析することによって、現在ビデオスライスのビデオブロックのための予測情報を決定し、予測情報を使用して、復号中の現在ビデオブロックのための予測ブロックを生成する。たとえば、動き補償ユニット72は、受信されたシンタックス要素のうちのいくつかを使用して、ビデオスライスのビデオブロックをコーディングするために使用された予測モード(たとえば、イントラ予測またはインター予測)、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)、スライス用の参照ピクチャリストのうちの1つまたは複数に対する構成情報、スライスのインター符号化されたビデオブロックごとの動きベクトル、スライスのインターコーディングされたビデオブロックごとのインター予測ステータス、および現在ビデオスライスの中のビデオブロックを復号するための他の情報を決定する。
動き補償ユニット72はまた、補間フィルタに基づいて補間を行い得る。動き補償ユニット72は、ビデオブロックの符号化中にビデオエンコーダ20によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルに対する補間値を計算し得る。この場合、動き補償ユニット72は、ビデオエンコーダ20によって使用された補間フィルタを、受信されたシンタックス要素から決定し得、その補間フィルタを使用して予測ブロックを生成し得る。
深度マップに対応するテクスチャ画像に対するデータは、参照フレームメモリ82の中に記憶され得る。動き補償ユニット72はまた、深度マップの深度ブロックをインター予測するように構成され得る。
上記のことを念頭に置いて、ビデオ圧縮技法は、空間(イントラピクチャ)予測および/または時間(インターピクチャ)予測を実行して、ビデオシーケンスに固有の冗長性を低減または除去する。ブロックベースのビデオコーディングの場合、ビデオスライス(すなわち、ビデオピクチャ、またはビデオピクチャの一部分)は、ツリーブロック、コーディングツリーブロック(CTB:coding tree block)、コーディングツリーユニット(CTU:coding tree unit)、コーディングユニット(CU:coding unit)、および/またはコーディングノードと呼ばれることもある、ビデオブロックに区分され得る。ピクチャのイントラコーディングされた(I)スライスの中のビデオブロックは、同じピクチャの中の近傍のブロックの中の参照サンプルに対する空間予測を使用して符号化される。ピクチャのインターコーディングされた(PまたはB)スライスの中のビデオブロックは、同じピクチャの中の近傍のブロックの中の参照サンプルに対する空間予測、または他の参照ピクチャの中の参照サンプルに対する時間予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。
空間予測または時間予測は、コーディングされるべきブロックのための予測ブロックをもたらす。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコーディングされたブロックは、予測ブロックを形成する参照サンプルのブロックを指し示す動きベクトル、およびコーディングされたブロックと予測ブロックとの間の差分を示す残差データに従って符号化される。イントラコーディングされたブロックは、イントラコーディングモードおよび残差データに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されてよく、結果として残差変換係数になり、残差変換係数は、次いで、量子化され得る。当初は2次元アレイをなして配置された量子化変換係数は、変換係数の1次元ベクトルを生成するために走査されてよく、なお一層の圧縮を達成するためにエントロピーコーディングが適用されてよい。
画像およびビデオ圧縮は急成長を経ており、様々なコーディング規格に至る。そのようなビデオコーディング規格は、ITU-T H.261、ISO/IEC MPEG-1パート2、ITU-T H.262またはISO/IEC MPEG-2パート2、ITU-T H.263、ISO/IEC MPEG-4パート2、ITU-T H.264またはISO/IEC MPEG-4パート10とも呼ばれるアドバンストビデオコーディング(AVC)、およびITU-T H.265またはMPEG-Hパート2とも呼ばれる高効率ビデオコーディング(HEVC)を含む。AVCは、スケーラブルビデオコーディング(SVC)、マルチビュービデオコーディング(MVC)およびマルチビュービデオコーディングプラス深度(MVC+D)、ならびに3D AVC(3D-AVC)などの拡張を含む。HEVCは、スケーラブルHEVC(SHVC)、マルチビューHEVC(MV-HEVC)、および3D HEVC(3D-HEVC)などの拡張を含む。
ITU-TとISO/IECとの共同ビデオエキスパートチーム(JVET)によって開発中の多用途ビデオコーディング(VVC)と称される新たなビデオコーディング規格もある。VVC規格はいくつかのワーキングドラフトを有するが、特にVVCの1つのワーキングドラフト(WD)、すなわち、B.Bross、J.Chen、およびS.Liu、「Versatile Video Coding (Draft 4)」、JVET-M1001-v5、第13回JVET会合、2019年1月(VVCドラフト4)が、本明細書で参照される。
本明細書で開示する技法の説明は、開発中のビデオコーディング規格、すなわち、ITU-TとISO/IECとの共同ビデオエキスパートチーム(JVET)による多用途ビデオコーディング(VVC)に基づく。しかしながら、本技法は、他のビデオコーデック仕様にも適用される。
図4は、復号順序408および提示順序410における、リーディングピクチャ404に対するIRAPピクチャ402と、トレーリングピクチャ406との間の関係の描写400である。一実施形態では、IRAPピクチャ402は、クリーンランダムアクセス(CRA:clean random access)ピクチャ、またはランダムアクセス復号可能リーディング(RADL:random access decodable leading)ピクチャを伴う瞬時デコーダリフレッシュ(IDR:instantaneous decoder refresh)ピクチャと呼ばれる。HEVCでは、IDRピクチャ、CRAピクチャ、およびブロークンリンクアクセス(BLA:Broken Link Access)ピクチャは、すべてIRAPピクチャ402と考えられる。VVCの場合、2018年10月における第12回JVET会合の間に、IRAPピクチャとしてIDRピクチャとCRAピクチャの両方を有することが合意された。
図4に示すように、リーディングピクチャ404(たとえば、ピクチャ2および3)は、復号順序408でIRAPピクチャ402に後続するが、提示順序410でIRAPピクチャ402に先行する。トレーリングピクチャ406は、復号順序408と提示順序410の両方でIRAPピクチャ402に後続する。2つのリーディングピクチャ404および1つのトレーリングピクチャ406が図4に示されるが、実際の適用例では、より多数またはより少数のリーディングピクチャ404および/またはトレーリングピクチャ406が復号順序408および提示順序410で存在し得ることを、当業者は理解するであろう。
図4の中のリーディングピクチャ404は、2つのタイプ、すなわち、ランダムアクセススキップ可能(RASL:random access skippable)およびRADLに分けられている。復号がIRAPピクチャ402(たとえば、ピクチャ1)から始まるとき、RADLピクチャ(たとえば、ピクチャ3)は正しく復号され得るが、RASLピクチャ(たとえば、ピクチャ2)は正しく復号され得ない。したがって、RASLピクチャは廃棄される。RADLピクチャとRASLピクチャとの間の相違に照らして、IRAPピクチャに関連付けられるリーディングピクチャのタイプは、効率的かつ適切なコーディングのためにRADLまたはRASLのいずれかとして識別されるべきである。HEVCでは、RASLピクチャおよびRADLピクチャが存在するとき、同じIRAPピクチャに関連付けられるRASLピクチャおよびRADLピクチャについて、提示順序410でRASLピクチャがRADLピクチャに先行しなければならないことが制約される。
IRAPピクチャ402は、以下の2つの重要な機能/利点をもたらす。第一に、IRAPピクチャ402の存在は、復号プロセスがそのピクチャから開始できることを示す。この機能は、IRAPピクチャ402がその位置に存在する限り、必ずしもビットストリームの冒頭とは限らず、ビットストリームの中のその位置において復号プロセスが開始するランダムアクセス特徴を可能とする。第二に、IRAPピクチャ402の存在は、RASLピクチャを除き、IRAPピクチャ402において開始しコーディングされたピクチャが、前のピクチャへのいかなる参照も伴わずにコーディングされるように、復号プロセスをリフレッシュする。したがって、ビットストリームの中に存在するIRAPピクチャ402を有することは、IRAPピクチャ402の前にコーディングされたピクチャの復号中に起こり得るいかなるエラーも、IRAPピクチャ402および復号順序408においてIRAPピクチャ402に後続するピクチャに伝搬することを止めることになる。
IRAPピクチャ402は、重要な機能を提供する一方で、圧縮効率への不利益を伴う。IRAPピクチャ402の存在は、ビットレートの急上昇を引き起こす。圧縮効率へのこの不利益は、2つの理由に起因する。第一に、IRAPピクチャ402はイントラ予測されるピクチャであるので、インター予測されるピクチャである他のピクチャ(たとえば、リーディングピクチャ404、トレーリングピクチャ406)と比較すると、ピクチャ自体が、描写するために比較的多くのビットを必要とすることになる。第二に、IRAPピクチャ402の存在が時間予測を破るので(なぜなら、デコーダが復号プロセスをリフレッシュすることになり、このことについての復号プロセスのアクションのうちの1つが、復号ピクチャバッファ(DPB)の中の、前の参照ピクチャを除去することであるからである)、IRAPピクチャ402は、復号順序408でIRAPピクチャ402に後続するピクチャのコーディングを効率のよくないものとし(すなわち、描写するためにより多くのビットを必要とするものとし)、なぜならば、それらはそれらのインター予測コーディングのためにより少ない参照ピクチャしか有しないためである。
IRAPピクチャ402であると考えられるピクチャタイプのうち、HEVCにおけるIDRピクチャは、他のピクチャタイプと比較したとき、異なるシグナリングおよび導出を有する。相違点のうちのいくつかは次の通りである。
IDRピクチャのピクチャ順序カウント(POC:picture order count)値のシグナリングおよび導出のために、POCの最上位ビット(MSB)部分は前のキーピクチャ(key picture)から導出されるのではなく、単に0に等しくなるように設定される。
参照ピクチャ管理のために必要とされる情報をシグナリングするために、IDRピクチャのスライスヘッダは、参照ピクチャ管理を支援するためにシグナリングされることを必要とされる情報を含まない。他のピクチャタイプ(すなわち、CRA、トレーリング、時間サブレイヤアクセス(TSA:temporal sub-layer access)など)の場合、参照ピクチャマーキングプロセス(すなわち、復号ピクチャバッファ(DPB)の中の参照ピクチャのステータス、すなわち、参照のために使用済みおよび参照のために未使用のいずれかを、決定するためのプロセス)のために、以下で説明する参照ピクチャセット(RPS:reference picture set)などの情報、または他の形式の同様の情報(たとえば、参照ピクチャリスト)が必要とされる。しかしながら、IDRピクチャの場合、そのような情報はシグナリングされる必要がなく、なぜならば、IDRの存在が、復号プロセスはDPBの中のすべての参照ピクチャを参照のために未使用であるとして単にマークする、ということを示すからである。
HEVCおよびVVCでは、IRAPピクチャ402およびリーディングピクチャ404は各々、単一のネットワーク抽象化レイヤ(NAL)ユニット内に含まれうる。一組のNALユニットは、アクセスユニットと呼ばれうる。IRAPピクチャ402およびリーディングピクチャ404は、システムレベルアプリケーションによって容易に識別され得るように、異なるNALユニットタイプが与えられる。たとえば、ビデオスプライサは、詳細には、IRAPピクチャ402を非IRAPピクチャから識別するために、またRASLピクチャおよびRADLピクチャを決定することを含め、リーディングピクチャ404をトレーリングピクチャ406から識別するために、コーディングされたビットストリームの中のシンタックス要素のあまりにも多くの詳細を理解する必要なく、コーディングされたピクチャタイプを理解する必要がある。トレーリングピクチャ406は、IRAPピクチャ402に関連付けられ、提示順序410でIRAPピクチャ402に後続するピクチャである。ピクチャは、復号順序408で特定のIRAPピクチャ402に後続してもよく、復号順序408で任意の他のIRAPピクチャ402に先行してもよい。このために、IRAPピクチャ402およびリーディングピクチャ404にそれら自体のNALユニットタイプを与えることは、そのようなアプリケーションの役に立つ。
HEVCの場合、IRAPピクチャのためのNALユニットタイプは以下を含む。
リーディングピクチャを伴うBLA(BLA_W_LP): 復号順序で1つまたは複数のリーディングピクチャが後続し得るブロークンリンクアクセス(BLA)ピクチャのNALユニット。
RADLを伴うBLA(BLA_W_RADL): 復号順序で1つまたは複数のRADLピクチャが後続し得るがRASLピクチャが後続し得ないBLAピクチャのNALユニット。
リーディングピクチャを伴わないBLA(BLA_N_LP): 復号順序でリーディングピクチャが後続しないBLAピクチャのNALユニット。
RADLを伴うIDR(IDR_W_RADL): 復号順序で1つまたは複数のRADLピクチャが後続し得るがRASLピクチャが後続し得ないIDRピクチャのNALユニット。
リーディングピクチャを伴わないIDR(IDR_N_LP): 復号順序でリーディングピクチャが後続しないIDRピクチャのNALユニット。
CRA: リーディングピクチャが後続し得るクリーンランダムアクセス(CRA)ピクチャのNALユニット(すなわち、RASLピクチャもしくはRADLピクチャのいずれか、またはその両方)。
RADL: RADLピクチャのNALユニット。
RASL: RASLピクチャのNALユニット。
VVCの場合、IRAPピクチャ402およびリーディングピクチャ404のためのNALユニットタイプは次の通りである。
RADLを伴うIDR(IDR_W_RADL): 復号順序で1つまたは複数のRADLピクチャが後続し得るがRASLピクチャが後続し得ないIDRピクチャのNALユニット。
リーディングピクチャを伴わないIDR(IDR_N_LP): 復号順序でリーディングピクチャが後続しないIDRピクチャのNALユニット。
CRA: リーディングピクチャが後続し得るクリーンランダムアクセス(CRA)ピクチャのNALユニット(すなわち、RASLピクチャもしくはRADLピクチャのいずれか、またはその両方)。
RADL: RADLピクチャのNALユニット。
RASL: RASLピクチャのNALユニット。
順次イントラリフレッシュ/漸次復号リフレッシュが以下で説明される。
低遅延適用例の場合、ピクチャをIRAPピクチャ(たとえば、IRAPピクチャ402)としてコーディングすることは、そのビットレート要件が非IRAPピクチャ(すなわち、Pピクチャ/Bピクチャ)と比較して相対的に大きく、したがって、より大きいレイテンシ/遅延を引き起こすため、回避することが望ましい。しかしながら、IRAPの使用を完全に回避することは、すべての低遅延適用例において可能であるとは限らない場合がある。たとえば、マルチパーティ遠隔会議などの会話型の適用例の場合、新たなユーザが遠隔会議に参加できる定期的なポイントを提供することが必要である。
新たなユーザがマルチパーティ遠隔会議適用例に参加することを可能にする、ビットストリームへのアクセスを提供するために、1つの可能な方策は、ビットレートにおけるピークを有することを回避するために、IRAPピクチャを使用するのではなく順次イントラリフレッシュ技法(PIR:progressive intra refresh)を使用することである。PIRは、漸次復号リフレッシュ(GDR)と呼ばれることもある。PIRおよびGDRという用語は、本開示において互いに入れ替え可能に使用され得る。
図5は、漸次復号リフレッシュ(GDR)技法500を示す。図示のように、GDR技法500は、ビットストリームのコーディングされたビデオシーケンス(CVS)508内のGDRピクチャ502、1つまたは複数のトレーリングピクチャ504、およびリカバリポイントピクチャ506を用いて示される。一実施形態では、GDRピクチャ502、トレーリングピクチャ504、およびリカバリポイントピクチャ506は、CVS508の中のGDR期間を規定し得る。CVS508は、GDRピクチャ502で開始する一連のピクチャ(または、それらの部分)であり、次のGDRピクチャまでの(ただし、それを含まない)、またはビットストリームの終端までの、すべてのピクチャ(または、それらの部分)を含む。GDR期間は、GDRピクチャ502で開始する一連のピクチャであり、リカバリポイントピクチャ506までの(それを含む)すべてのピクチャを含む。
図5に示すように、GDR技法500または原理は、GDRピクチャ502で開始しリカバリポイントピクチャ506で終了する一連のピクチャにわたって機能する。GDRピクチャ502は、すべてがイントラ予測を使用してコーディングされているブロック(すなわち、イントラ予測ブロック)を含むリフレッシュ済みの/クリーンな領域510、およびすべてがインター予測を使用してコーディングされているブロック(すなわち、インター予測ブロック)を含むリフレッシュされていない/ダーティな領域512を含む。
GDRピクチャ502に直接隣接するトレーリングピクチャ504は、イントラ予測を使用してコーディングされる第1の部分510Aおよびインター予測を使用してコーディングされる第2の部分510Bを有する、リフレッシュ済みの/クリーンな領域510を含む。第2の部分510Bは、たとえば、CVS508のGDR期間内の先行するピクチャの、リフレッシュ済みの/クリーンな領域510を参照することによってコーディングされる。図示のように、トレーリングピクチャ504のリフレッシュ済みの/クリーンな領域510は、一貫した方向で(たとえば、左から右に)コーディングプロセスが移動または進行するにつれて拡大し、それに対応して、リフレッシュされていない/ダーティな領域512を縮小する。最終的に、リフレッシュ済みの/クリーンな領域510しか含まないリカバリポイントピクチャ506が、コーディングプロセスから取得される。特に、さらに以下で説明するように、インター予測ブロックとしてコーディングされる、リフレッシュ済みの/クリーンな領域510の第2の部分510Bは、参照ピクチャの中のリフレッシュ済みの領域/クリーンな領域510を参照するだけでよい。
HEVCでは、図5のGDR技法500が、リカバリポイント補足エンハンスメント情報(SEI:Supplemental Enhancement Information)メッセージおよび領域リフレッシュ情報SEIメッセージを使用して非規範的にサポートされた。これらの2つのSEIメッセージは、GDRがどのように実行されるのかを規定しない。むしろ、その2つのSEIメッセージは、(すなわち、リカバリポイントSEIメッセージによって提供される)GDR期間の中の最初のピクチャおよび最後のピクチャならびに(すなわち、領域リフレッシュ情報SEIメッセージによって提供される)リフレッシュされている領域を示すためのメカニズムを単に提供する。
実際には、GDR技法500は、2つの技法を一緒に使用することによって行われる。それらの2つの技法とは、制約イントラ予測(CIP:constraint intra prediction)、および動きベクトルに対するエンコーダ制約である。CIPは、リフレッシュされていない領域(たとえば、リフレッシュされていない/ダーティな領域512)からのサンプルを使用しない領域が、参照のために使用されることを可能にするので、CIPは、特にイントラ予測ブロック(たとえば、リフレッシュ済みの/クリーンな領域510の第1の部分510A)としてのみコーディングされる領域をコーディングするための、GDR目的のために使用され得る。しかしながら、イントラブロックへの制約が、リフレッシュ済みの領域の中のイントラブロックに対してだけでなくピクチャの中のすべてのイントラブロックにも適用されなければならないので、CIPの使用は深刻なコーディング性能劣化を引き起こす。動きベクトルに対するエンコーダ制約は、リフレッシュ済みの領域の外側に位置する参照ピクチャの中の任意のサンプルをエンコーダが使用することを制限する。そのような制約は、最適でない動き探索を引き起こす。
図6は、GDRをサポートするためにエンコーダ制約を使用するときの、望ましくない動き探索600を示す概略図である。図示のように、動き探索600は、現在ピクチャ602および参照ピクチャ604を示す。現在ピクチャ602および参照ピクチャ604は各々、イントラ予測を用いてコーディングされたリフレッシュ済みの領域606、インター予測を用いてコーディングされたリフレッシュ済みの領域608、およびリフレッシュされていない領域608を含む。リフレッシュ済みの領域604、リフレッシュ済みの領域606、およびリフレッシュされていない領域608は、図5の中のリフレッシュ済みの/クリーンな領域510の第1の部分510A、リフレッシュ済みの/クリーンな領域510の第2の部分510B、およびリフレッシュされていない/ダーティな領域512と同様である。
動き探索プロセス中、エンコーダは、リフレッシュ済みの領域606の外側に位置している参照ブロック612のサンプルのうちのいくつかをもたらす、いかなる動きベクトル610を選択することも制約または防止される。このことは、現在ピクチャ602の中の現在ブロック614を予測するときに参照ブロック612が最良のレートひずみコスト基準を与えるときにさえ行われる。したがって、図6は、GDRをサポートするためのエンコーダ制約を使用するときの、動き探索600における非最適性に対する理由を示す。
JVET寄稿JVET-K0212およびJVET-L0160は、CIPおよびエンコーダ制約手法の使用に基づくGDRの実装形態を記載している。実装形態は、次のように要約され得る。すなわち、列ごとにコーディングユニットに対してイントラ予測モードが強制され、イントラCUの再構成を確実なものにするために、制約付きイントラ予測が有効化され、動きベクトルは、フィルタが原因で広がる誤差(たとえば、6ピクセル)を回避するための追加のマージンを考慮に入れるとともに、イントラ列を再ループさせるときに過去の参照ピクチャを除去しながら、リフレッシュ済みのエリア内を指し示すように制約される。
JVET寄稿JVET-M0529は、ピクチャがGDR期間の中で最初のピクチャおよび最後のピクチャであることを規範的に示すための方法を提案した。提案された着想は次のように機能する。
NALユニットタイプリカバリポイント表示を有する新たなNALユニットを、非ビデオコーディングレイヤ(VCL)NALユニットとして規定する。NALユニットのペイロードは、GDR期間の中の最後のピクチャのPOC値を導出するために使用され得る情報を指定するためのシンタックス要素を含む。タイプリカバリポイント表示を有する非VCL NALユニットを含むアクセスユニットは、リカバリポイント開始(RBP:recovery point begin)アクセスユニット(AU:access unit)と呼ばれ、RBPアクセスユニットの中のピクチャは、RBPピクチャと呼ばれる。復号プロセスは、RBP AUから開始することができる。復号がRBP AUから開始するとき、最後のピクチャを除いてGDR期間の中のすべてのピクチャは出力されない。
既存のGDR設計に関する問題のうちのいくつかについて説明する。
GDRをサポートするための既存の設計/手法は、少なくとも以下の問題を有する。
JVET-M0529におけるGDRを規範的に規定するための方法は、以下の問題を有する。提案された方法は、GDRがどのように行われるのかを説明していない。代わりに、提案された方法は、GDR期間の中の最初のピクチャおよび最後のピクチャを示すためのいくつかのシグナリングを提供するにすぎない。GDR期間の中の最初のピクチャおよび最後のピクチャを示すために、新たな非VCL NALユニットが必要とされる。リカバリポイント表示(RPI:recovery point indication)NALユニットの中に含まれる情報は、GDR期間の中の最初のピクチャのタイルグループヘッダの中に単に含められ得るので、このことは冗長性である。また、提案された方法は、GDR期間の中のピクチャの中のどの領域がリフレッシュ済みの領域およびリフレッシュされていない領域であるのかを表すことができない。
JVET-K0212およびJVET-L0160に記載されるGDR手法は、以下の問題を有する。第一に、CIPの使用。リフレッシュされていない領域からの任意のサンプルが空間的な参照のために使用されることを防止するために、リフレッシュ済みの領域を、いくつかの制約を伴うイントラ予測を用いてコーディングすることが必要である。CIPが使用されるとき、コーディングはピクチャベースであり、そのことは、ピクチャの中のすべてのイントラブロックもCIPイントラブロックとしてコーディングされなければならないことを意味する。したがって、このことは性能劣化を引き起こす。さらに、動きベクトルに関連する参照ブロックのサンプルが、完全に参照ピクチャの中のリフレッシュ済みの領域内にあるとは限らないとき、動き探索を限定するためのエンコーダ制約の使用は、エンコーダが最良の動きベクトルを選ぶことを妨げる。また、イントラ予測のみを用いてコーディングされるリフレッシュ済みの領域はCTUサイズでない。代わりに、リフレッシュ済みの領域は、CTUサイズよりも小さく、最小CUサイズまで小さくなることができる。このことは、ブロックレベルでの表示を必要とし得るので、実装を不必要に複雑にさせる。
本明細書では、ビデオコーディングにおける漸次復号リフレッシュ(GDR)をサポートするための技法が開示される。開示する技法は、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
上記で説明した問題のうちの1つまたは複数を解決するために、本開示は以下の態様を開示する。態様の各々は個別に適用され得、それらのうちのいくつかは組合せで適用され得る。
1) タイプGDR_NUTを有するVCL NALユニットが規定される。
a. NALユニットタイプGDR_NUTを有するピクチャは、GDRピクチャ、すなわち、GDR期間の中の最初のピクチャと呼ばれる。
b. GDRピクチャは、temporalIDが0に等しい。
c. GDRピクチャを含むアクセスユニットは、GDRアクセスユニットと呼ばれる。上述のように、アクセスユニットは一組のNALユニットである。各NALユニットは、単一のピクチャを含み得る。
2) コーディングされたビデオシーケンス(CVS)は、GDRアクセスユニットで開始しうる。
3) 次のことのうちの1つが真であるとき、GDRアクセスユニットはCVSの中の最初のアクセスユニットである。
a. GDRアクセスユニットがビットストリームの中の最初のアクセスユニットである。
b. GDRアクセスユニットがエンドオブシーケンス(EOS)アクセスユニットの直後に続く。
c. GDRアクセスユニットがエンドオブビットストリーム(EOB:end-of-bitstream)アクセスユニットの直後に続く。
d. デコーダフラグ、いわゆる、NoIncorrectPicOutputFlagがGDRピクチャに関連付けられ、デコーダの外側のエンティティによってフラグの値が1(すなわち、真)に等しく設定される。
4) GDRピクチャがCVSの中の最初のアクセスユニットであるとき、以下のことが適用される。
a. DPBの中のすべての参照ピクチャが「参照のために未使用」としてマークされる。
b. ピクチャのPOC MSBが0に等しくなるように設定される。
c. GDRピクチャ、およびGDR期間の中の最後のピクチャを除きGDR期間の中の最後のピクチャまで出力順序でGDRピクチャに後続するすべてのピクチャは、出力されない(すなわち、「出力のために不必要」としてマークされる)。
5) GDRが有効化されているかどうかを指定するためのフラグが、シーケンスレベルパラメータセットの中で(たとえば、SPSの中で)シグナリングされる。
a. フラグはgdr_enabled_flagと指定されうる。
b. フラグが1に等しいとき、GDRピクチャがCVSの中に存在し得る。そうではなく、フラグが0に等しいとき、GDRピクチャがCVSの中に存在しないようにGDRは有効化されていない。
6) GDR期間の中の最後のピクチャのPOC値を導出するために使用され得る情報が、GDRピクチャのタイルグループヘッダの中でシグナリングされる。
a. GDR期間の中の最後のピクチャとGDRピクチャとの間の差分(delta)POCとして、情報がシグナリングされる。情報は、recovery_point_cntと指定されるシンタックス要素を使用してシグナリングされ得る。
b. タイルグループヘッダの中のシンタックス要素recovery_point_cntの存在は、gdr_enabledフラグの値、およびピクチャのNALユニットタイプが条件とされてよく、すなわち、gdr_enabled_flagが1に等しく、かつタイルグループを含むNALユニットのnal_unit_typeがGDR_NUTであるときのみ、フラグが存在する。
7) タイルグループがリフレッシュ済みの領域の一部であるか否かを指定するためのフラグが、タイルグループヘッダの中でシグナリングされる。
a. フラグは、refreshed_region_flagと指定されうる。
b. そのフラグの存在は、gdr_enabled_flagの値、およびタイルグループを含むピクチャがGDR期間内にあるかどうかが、条件とされてよい。したがって、次のことのすべてが真であるときのみ、フラグが存在する。
i. gdr_enabled_flagの値が1に等しい。
ii. 現在ピクチャのPOCが、最後のGDRピクチャのPOC値以上であり(現在ピクチャがGDRピクチャであるとき、最後のGDRピクチャが現在ピクチャである)、GDR期間の中の最後のピクチャのPOCよりも小さい。
c. フラグがタイルグループヘッダの中に存在しないとき、フラグの値は1に等しいものと推測される。
8) refreshed_region_flagが1に等しいすべてのタイルグループは、連結している領域をカバーする。同様に、refreshed_region_flagが0に等しいすべてのタイルグループも、連結している領域をカバーする。
9) refreshed_region_flagを有するタイルグループは、タイプI(すなわち、イントラタイルグループ)またはBもしくはP(すなわち、インタータイルグループ)のものであり得る。
10) GDRピクチャから開始しGDR期間の中の最後のピクチャまでの各ピクチャは、refreshed_region_flagが1に等しい少なくとも1つのタイルグループを含む。
11) GDRピクチャは、refreshed_region_flagが1に等しく、かつtile_group_typeがI(すなわち、イントラタイルグループ)に等しい、少なくとも1つのタイルグループを含む。
12) gdr_enabled_flagが1に等しいとき、長方形タイルグループの情報、すなわち、タイルグループの数およびそれらのアドレスが、ピクチャパラメータセット(PPS:picture parameter set)またはタイルグループヘッダのいずれかの中でシグナリングされることが可能とされる。これを行うために、長方形タイルグループ情報がPPSの中に存在するか否かを指定するために、PPSの中でフラグがシグナリングされる。このフラグは、rect_tile_group_info_in_pps_flagと呼ばれることがある。このフラグは、gdr_enabled_flagが1に等しいとき、1に等しくなるように制約されうる。
a. 一代替形態では、長方形タイルグループ情報がPPSの中に存在するか否かをシグナリングするのではなく、タイルグループ情報(すなわち、長方形タイルグループ、ラスタ走査タイルグループなどの、任意のタイプのタイルグループ)がPPSの中に存在するかどうかを指定するために、より全般的なフラグがPPSの中でシグナリングされ得る。
13) タイルグループ情報がPPSの中に存在しないとき、明示的なタイルグループ識別子(ID)情報のシグナリングが存在しないことが、さらに制約されうる。明示的なタイルグループID情報は、signaled_tile_group_id_flag、signaled_tile_group_id_length_minus1、およびtile_group_id[ i ]を含む。
14) ピクチャの中のリフレッシュ済みの領域とリフレッシュされていない領域との間の境界を横断するループフィルタ処理演算が可能とされるかどうかを指定するために、フラグがシグナリングされる。
a. このフラグはPPSの中でシグナリングされ、loop_filter_across_refreshed_region_enabled_flagと呼ばれることがある。
b. loop_filter_across_refreshed_region_enabled_flagの存在は、loop_filter_across_tile_enabled_flagの値が条件とされうる。loop_filter_across_tile_enabled_flagが0に等しいとき、loop_filter_across_refreshed_region_enabled_flagは存在しなくてよく、その値は0に等しいものと推測される。
c. 一代替形態では、タイルグループヘッダの中でそのフラグがシグナリングされてよく、その存在は、refreshed_region_flagの値が条件とされえ、すなわち、refreshed_region_flagの値が1に等しいときのみ、そのフラグが存在する。
15) タイルグループがリフレッシュ済みの領域であることが示され、リフレッシュ済みの領域を横断するループフィルタが可能とされないことが示されるとき、以下のことが適用される。
a. エッジを共有する近傍タイルグループが、リフレッシュされていないタイルグループであるとき、タイルグループの境界におけるエッジのデブロッキングが行われない。
b. タイルグループの境界におけるブロックに対するサンプル適応オフセット(SAO:sample adaptive offset)プロセスは、リフレッシュ済み領域境界の外側からのいかなるサンプルも使用しない。
c. タイルグループの境界におけるブロックに対する適応ループフィルタ処理(ALF:adaptive loop filtering)プロセスは、リフレッシュ済み領域境界の外側からのいかなるサンプルも使用しない。
16) gdr_enabled_flagが1に等しいとき、各ピクチャは、ピクチャの中のリフレッシュ済みの領域の境界を決定するための変数に関連付けられる。これらの変数は、次のように呼ばれることがある。
a. ピクチャの中のリフレッシュ済みの領域の左の境界位置について、PicRefreshedLeftBoundaryPos。
b. ピクチャの中のリフレッシュ済みの領域の右の境界位置について、PicRefreshedRightBoundaryPos。
c. ピクチャの中のリフレッシュ済みの領域の上の境界位置について、PicRefreshedTopBoundaryPos。
d. ピクチャの中のリフレッシュ済みの領域の下の境界位置について、PicRefreshedBotBoundaryPos。
17) ピクチャの中のリフレッシュ済みの領域の境界が導出され得る。ピクチャのリフレッシュ済みの領域の境界は、タイルグループヘッダが構文解析された後にデコーダによって更新され、タイルグループのrefreshed_region_flagの値は1に等しい。
18) 解決策17)の一代替形態では、ピクチャの中のリフレッシュ済みの領域の境界は、ピクチャの各タイルグループの中で明示的にシグナリングされる。
a. タイルグループが属するピクチャがリフレッシュされていない領域を含むかどうかを示すために、フラグがシグナリングされうる。ピクチャがリフレッシュされていない領域を含まないことが指定されるとき、リフレッシュ済み境界情報はシグナリングされず、単純にピクチャ境界に等しいものと推測されうる。
19) 現在ピクチャに対して、次のように、ループ内フィルタプロセスにおいてリフレッシュ済みの領域の境界が使用される。
a. デブロッキングプロセスの場合、エッジがデブロッキングされる必要があるか否かを決めるために、リフレッシュ済みの領域のエッジを決定する。
b. SAOプロセスの場合、リフレッシュ領域を横断するループフィルタが可能とされないとき、リフレッシュされていない領域からのサンプルを使用することを回避するためにクリッピングプロセスが適用され得るように、リフレッシュ済みの領域の境界を決定する。
c. ALFプロセスの場合、リフレッシュ済みの領域を横断するループフィルタが可能とされないとき、リフレッシュされていない領域からのサンプルを使用することを回避するためにクリッピングプロセスが適用され得るように、リフレッシュ領域の境界を決定する。
20) 動き補償プロセスについて、リフレッシュ済みの領域の境界、特に参照ピクチャの中のリフレッシュ済みの領域の境界についての情報が、次のように使用される。すなわち、現在ピクチャの中の現在ブロックが、refreshed_region_flagが1に等しいタイルグループの中にあり、かつ参照ブロックが、リフレッシュされていない領域を含む参照ピクチャの中にあるとき、以下のことが適用される。
a. 現在ブロックからその参照ピクチャへの動きベクトルは、その参照ピクチャの中のリフレッシュ済みの領域の境界によってクリッピングされる。
b. その参照ピクチャの中のサンプルのための分数補間フィルタについて、これはその参照ピクチャの中のリフレッシュ済みの領域の境界によってクリッピングされる。
本開示の実施形態の詳細な説明が提供される。説明は基礎テキストに関連し、基礎テキストはJVET寄稿JVET-M1001-v5である。すなわち、差分だけが記載されるが、以下で述べられない基礎テキストの中のテキストは、現状のままで適用される。基礎テキストに比べて修正されるテキストは、イタリック体が使用される。
定義が与えられる。
3.1 クリーンランダムアクセス(CRA)ピクチャ: CRA_NUTに等しいnal_unit_typeを各VCL NALユニットが有するIRAPピクチャ。
注 - CRAピクチャは、その復号プロセスにおけるインター予測のために、それ自体以外のいかなるピクチャも参照せず、復号順序でビットストリームの中の最初のピクチャであってよく、または後でビットストリームの中に出現してよい。CRAピクチャは、関連付けられたRADLピクチャまたはRASLピクチャを有してよい。CRAピクチャが1に等しいNoIncorrectPicOutputFlagを有するとき、RASLピクチャは、ビットストリームの中に存在しないピクチャへの参照を含み得るため、復号可能でない場合があるので、関連付けられたRASLピクチャはデコーダによって出力されない。
3.2 コーディングされたビデオシーケンス(CVS): NoIncorrectPicOutputFlagが1に等しいIRAPアクセスユニットまたはNoIncorrectPicOutputFlagが1に等しいGDRアクセスユニットである後続の任意のアクセスユニットまでの(ただし、それを含まない)すべての後続のアクセスユニットを含む、NoIncorrectPicOutputFlagが1に等しいIRAPアクセスユニットまたはNoIncorrectPicOutputFlagが1に等しいGDRアクセスユニットと、それに後続する0、またはNoIncorrectPicOutputFlagが1に等しいIRAPアクセスユニットもしくはNoIncorrectPicOutputFlagが1に等しいGDRアクセスユニットでない、より多くのアクセスユニットとを復号順序で備える、アクセスユニットのシーケンス。
注1 - IRAPアクセスユニットは、IDRアクセスユニットまたはCRAアクセスユニットでありうる。各IDRアクセスユニットに対してNoIncorrectPicOutputFlagの値は1に等しく、復号順序でビットストリームの中の最初のアクセスユニットである各CRAアクセスユニットは、復号順序でエンドオブシーケンスNALユニットに後続するか、または1に等しいHandleCraAsCvsStartFlagを有する、最初のアクセスユニットである。
注2 - 復号順序でビットストリームの中の最初のアクセスユニットである各GDRアクセスユニットに対して、NoIncorrectPicOutputFlagの値が1に等しいことは、復号順序でエンドオブシーケンスNALユニットに後続するか、または1に等しいHandleGdrAsCvsStartFlagを有する、最初のアクセスユニットである。
3.3 漸次復号リフレッシュ(GDR)アクセスユニット: コーディングされたピクチャがGDRピクチャであるアクセスユニット。
3.4 漸次復号リフレッシュ(GDR)ピクチャ: GDR_NUTに等しいnal_unit_typeを各VCL NALユニットが有するピクチャ。
3.5 ランダム・アクセス・スキップド・リーディング(RASL)ピクチャ: RASL_NUTに等しいnal_unit_typeを各VCL NALユニットが有するコーディングされたピクチャ。
注 - すべてのRASLピクチャは、関連付けられるCRAピクチャのリーディングピクチャである。関連付けられるCRAピクチャが、1に等しいNoIncorrectPicOutputFlagを有するとき、ビットストリームの中に存在しないピクチャへの参照をRASLピクチャが含み得るので、RASLピクチャは出力されず、正しく復号可能でない場合がある。RASLピクチャは、非RASLピクチャの復号プロセスのための参照ピクチャとして使用されない。存在するとき、すべてのRASLピクチャは、関連付けられる同じCRAピクチャのすべてのトレーリングピクチャに復号順序で先行する。
シーケンス・パラメータ・セット・ロー・バイト・シーケンス・ペイロード(RBSP:raw byte sequence payload)のシンタックスおよびセマンティック。
Figure 2022524618000002
1に等しいgdr_enabled_flagは、コーディングされたビデオシーケンスの中にGDRピクチャが存在し得ることを指定する。0に等しいgdr_enabled_flagは、コーディングされたビデオシーケンスの中にGDRピクチャが存在しないことを指定する。
ピクチャパラメータセットRBSPのシンタックスおよびセマンティック。
Figure 2022524618000003
1に等しいrect_tile_group_info_in_pps_flagは、長方形タイルグループ情報がPPSの中でシグナリングされることを指定する。0に等しいrect_tile_group_info_in_pps_flagは、長方形タイルグループ情報がPPSの中でシグナリングされないことを指定する。
アクティブなSPSの中のgdr_enabled_flagの値が0に等しいとき、rect_tile_group_info_in_pps_flagの値が0に等しくなければならないことが、ビットストリーム適合の要件である。
1に等しいloop_filter_across_refreshed_region_enabled_flagは、PPSを参照するピクチャの中で、refreshed_region_flagが1に等しいタイルグループの境界を横断するループ内フィルタ処理演算が実行され得ることを指定する。0に等しいloop_filter_across_refreshed_region_enabled_flagは、PPSを参照するピクチャの中で、refreshed_region_flagが1に等しいタイルグループの境界を越えてループ内フィルタ処理演算が実行されないことを指定する。ループ内フィルタ処理演算は、デブロッキングフィルタ、サンプル適応オフセットフィルタ、および適応ループフィルタ演算を含む。存在しないとき、loop_filter_across_refreshed_region_enabled_flagの値は0に等しいものと推測される。
1に等しいsignalled_tile_group_id_flagは、タイルグループごとのタイルグループIDがシグナリングされることを指定する。0に等しいsignalled_tile_group_index_flagは、タイルグループIDがシグナリングされないことを指定する。存在しないとき、signalled_tile_group_index_flagの値は0に等しいものと推測される。
signalled_tile_group_id_length_minus1+1は、存在するときシンタックス要素tile_group_id[ i ]を、かつタイルグループヘッダの中のシンタックス要素tile_group_addressを表すために使用される、ビットの数を指定する。signalled_tile_group_index_length_minus1の値は、両端値を含む0~15という範囲の中になければならない。存在しないとき、signalled_tile_group_index_length_minus1の値は次のように推測される。
rect_tile_group_info_in_pps_flagが1に等しい場合、Ceil( Log2( num_tile_groups_in_pic_minus1 + 1 ) ) - 1。
そうでない場合、Ceil( Log2( NumTilesInPic ) ) - 1。
全般的なタイルグループヘッダのシンタックスおよびセマンティック。
Figure 2022524618000004
tile_group_addressは、タイルグループの中の最初のタイルのタイルアドレスを指定する。存在しないとき、tile_group_addressの値は、0に等しいものと推測される。
rect_tile_group_flagが0に等しい場合、以下のことが適用される。
tile_group_addressは、式6-7によって指定されるタイルIDである。
tile_group_addressの長さは、Ceil( Log2 ( NumTilesInPic ) )ビットである。
tile_group_addressの値は、両端値を含む0~NumTilesInPic - 1という範囲の中になければならない。
そうではなく、rect_tile_group_flagが1に等しく、かつrect_tile_group_info_in_ppsが0に等しい場合、以下のことが適用される。
tile_group_addressは、第iのタイルグループの左上隅角に位置するタイルのタイルインデックスである。
tile_group_addressの長さは、signalled_tile_group_index_length_minus1 + 1ビットである。
signalled_tile_group_id_flagが0に等しい場合、tile_group_addressの値は、両端値を含む0~NumTilesInPic - 1という範囲の中になければならない。そうでない場合、tile_group_addressの値は、両端値を含む0~2( signalled_tile_group_index_length_minus1 + 1 ) - 1という範囲の中になければならない。
それ以外の(rect_tile_group_flagが1に等しく、かつrect_tile_group_info_in_ppsが1に等しい)場合、以下のことが適用される。
tile_group_addressは、タイルグループのタイルグループIDである。
tile_group_addressの長さは、signalled_tile_group_index_length_minus1 + 1ビットである。
signalled_tile_group_id_flagが0に等しい場合、tile_group_addressの値は、両端値を含む0~num_tile_groups_in_pic_minus1という範囲の中になければならない。そうでない場合、tile_group_addressの値は、両端値を含む0~2( signalled_tile_group_index_length_minus1 + 1 ) - 1という範囲の中になければならない。
bottom_right_tile_idは、タイルグループの右下隅角に位置するタイルのタイルインデックスを指定する。single_tile_per_tile_group_flagが1に等しいとき、bottom_right_tile_idは、tile_group_addressに等しいものと推測される。bottom_right_tile_idシンタックス要素の長さは、Ceil( Log2( NumTilesInPic) )ビットである。
現在タイルグループの中のタイルの数を指定する変数NumTilesInCurrTileGroup、タイルグループの左上のタイルのタイルインデックスを指定するTopLeftTileIdx、タイルグループの右下のタイルのタイルインデックスを指定するBottomRightTileIdx、および現在タイルグループの中の第iのタイルのタイルインデックスを指定するTgTileIdx[ i ]が、次のように導出される。
if( rect_tile_group_flag ) {
if ( tile_group_info_in_pps ) {
tileGroupIdx = 0
while( tile_group_address != rect_tile_group_id[ tileGroupIdx ] )
tileGroupIdx++
tileIdx = top_left_tile_idx[ tileGroupIdx ]
BottomRightTileIdx = bottom_right_tile_idx[ tileGroupIdx ]
} else {
tileIdx = tile_group_address
BottomRightTileIdx = bottom_right_tile_id
}
TopLeftTileIdx = tileIdx
deltaTileIdx = BottomRightTileIdx - TopLeftTileIdx
NumTileRowsInTileGroupMinus1 = deltaTileIdx / ( num_tile_columns_minus1 + 1 ) (7-35)
NumTileColumnsInTileGroupMinus1 = deltaTileIdx % ( num_tile_columns_minus1 + 1 )
NumTilesInCurrTileGroup = ( NumTileRowsInTileGroupMinus1 + 1 ) * ( NumTileColumnsInTileGroupMinus1 + 1 )
for( j = 0, tIdx = 0; j < NumTileRowsInTileGroupMinus1 + 1; j++, tileIdx += num_tile_columns_minus1 + 1 )
for( i = 0, currTileIdx = tileIdx; i < NumTileColumnsInTileGroupMinus1 + 1; i++, currTileIdx++, tIdx++ )
TgTileIdx[ tIdx ] = currTileIdx
} else {
NumTilesInCurrTileGroup = num_tiles_in_tile_group_minus1 + 1
TgTileIdx[ 0 ] = tile_group_address
for( i = 1; i < NumTilesInCurrTileGroup; i++ )
TgTileIdx[ i ] = TgTileIdx[ i - 1 ] + 1
}
recovery_poc_cntは、出力順序での復号ピクチャのリカバリポイントを指定する。CVSの中で復号順序で現在ピクチャ(すなわち、GDRピクチャ)に後続し、かつ現在ピクチャのPicOrderCntVal+recovery_poc_cntの値に等しいPicOrderCntValを有する、ピクチャpicAがある場合、ピクチャpicAは、リカバリポイントピクチャと呼ばれる。そうでない場合、現在ピクチャのPicOrderCntVal+recovery_poc_cntの値よりも大きいPicOrderCntValを有する、出力順序で最初のピクチャが、リカバリポイントピクチャと呼ばれる。リカバリポイントピクチャは、復号順序で現在ピクチャに先行してはならない。出力順序でのすべての復号ピクチャは、リカバリポイントピクチャの出力順序位置において開始する内容の中で正確またはほぼ正確であるものと示される。recovery_poc_cntの値は、両端値を含む-MaxPicOrderCntLsb / 2~MaxPicOrderCntLsb / 2 - 1という範囲の中になければならない。
RecoveryPointPocValの値は、次のように導出される。
RecoveryPointPocVal = PicOrderCntVal + recovery_poc_cnt
1に等しいrefreshed_region_flagは、タイルグループの復号が、関連付けられるGDRのNoIncorrectPicOutputFlagの値にかかわらず正確な再構成サンプル値を生成することを指定する。0に等しいrefreshed_region_flagは、タイルグループの復号が、NoIncorrectPicOutputFlagが1に等しい関連付けられるGDRから開始するとき、不正確な再構成サンプル値を生成する場合があることを指定する。存在しないとき、refreshed_region_flagの値は、1に等しいものと推測される。
注x - 現在ピクチャ自体が、NoIncorrectPicOutputFlagが1に等しいGDRピクチャであり得る。
タイルグループがリフレッシュされる境界は、次のように導出される。
tileColIdx = TopLeftTileIdx % ( num_tile_columns_minus1 + 1 )
tileRowIdx = TopLeftTileIdx / ( num_tile_columns_minus1 + 1 )
TGRefreshedLeftBoundary = ColBd[ tileColIdx ] << CtbLog2SizeY
TGRefreshedTopBoundary = RowBd[ tileRowIdx ] << CtbLog2SizeY
tileColIdx = BottomRightTileIdx % ( num_tile_columns_minus1 + 1 )
tileRowIdx = BottomRightTileIdx / ( num_tile_columns_minus1 + 1 )
TGRefreshedRightBoundary = ( ( ColBd[ tileColIdx ] + ColWidth[ tileColIdx ] ) << CtbLog2SizeY ) - 1
TGRefreshedRightBoundary = TGRefreshedRightBoundary > pic_width_in_luma_samples ? pic_width_in_luma_samples : TGRefreshedRightBoundary
TGRefreshedBotBoundary = ( ( RowBd[ tileRowIdx ] + RowHeight[ tileRowIdx ] ) << CtbLog2SizeY ) - 1
TGRefreshedBotBoundary = TGRefreshedBotBoundary > pic_height_in_luma_samples ? pic_height_in_luma_samples : TGRefreshedBotBoundary
NALユニットヘッダのセマンティック。
Figure 2022524618000005
...
nal_unit_typeがGDR_NUTに等しく、コーディングされたタイルグループがGDRピクチャに属するとき、TemporalIdは0に等しくなければならない。
アクセスユニットの順序およびCVSへの関連付けが説明される。
この仕様(すなわち、JVET寄稿JVET-M1001-v5)に準拠するビットストリームは、1つまたは複数のCVSを含む。
CVSは、1つまたは複数のアクセスユニットを含む。NALユニットおよびコーディングされたピクチャの順序、ならびにアクセスユニットへのそれらの関連付けが、第7.4.2.4.4節に記載される。
CVSの最初のアクセスユニットは、以下のうちの1つである。
- NoBrokenPictureOutputFlagが1に等しいIRAPアクセスユニット。
- NoIncorrectPicOutputFlagが1に等しいGDRアクセスユニット。
存在するとき、エンドオブシーケンスNALユニットまたはエンドオブビットストリームNALユニットを含むアクセスユニットの後の次のアクセスユニットが、以下のうちの1つでなければならないことが、ビットストリーム適合の要件である。
- IDRアクセスユニットまたはCRAアクセスユニットであり得るIRAPアクセスユニット。
- GDRアクセスユニット。
8.1.1 コーディングされたピクチャのための復号プロセスが説明される。
...
現在ピクチャがIRAPピクチャであるとき、以下のことが適用される。
- 現在ピクチャが、IDRピクチャ、復号順序でビットストリームの中の最初のピクチャ、または復号順序でエンドオブシーケンスNALユニットに後続する最初のピクチャであるとき、変数NoIncorrectPicOutputFlagは、1に等しく設定される。
- そうではなく、この仕様で指定されないいくつかの外部手段(たとえば、ユーザ入力)が、変数HandleCraAsCvsStartFlagを現在ピクチャに対する値に設定するために利用可能であるとき、変数HandleCraAsCvsStartFlagは、外部手段によって提供される値に等しく設定され、変数NoIncorrectPicOutputFlagは、HandleCraAsCvsStartFlagに等しく設定される。
- そうでない場合、変数HandleCraAsCvsStartFlagは、0に等しく設定され、変数NoIncorrectPicOutputFlagは、0に等しく設定される。
現在ピクチャがGDRピクチャであるとき、以下のことが適用される。
- 現在ピクチャが、GDRピクチャ、復号順序でビットストリームの中の最初のピクチャ、または復号順序でエンドオブシーケンスNALユニットに後続する最初のピクチャであるとき、変数NoIncorrectPicOutputFlagは、1に等しく設定される。
- そうではなく、この仕様で指定されないいくつかの外部手段が、変数HandleGdrAsCvsStartFlagを現在ピクチャに対する値に設定するために利用可能であるとき、変数HandleGdrAsCvsStartFlagは、外部手段によって提供される値に等しく設定され、変数NoIncorrectPicOutputFlagは、HandleGdrAsCvsStartFlagに等しく設定される。
- そうでない場合、変数HandleGdrAsCvsStartFlagは、0に等しく設定され、変数NoIncorrectPicOutputFlagは、0に等しく設定される。
...
現在ピクチャCurrPicに対して復号プロセスは次のように動作する。
1. NALユニットの復号が第8.2節で指定される。
2. 第8.3節におけるプロセスは、タイルグループヘッダレイヤの中のシンタックス要素を使用する以下の復号プロセス、および上記のことを指定する。
- ピクチャ順序カウントに関係する変数および関数が、第8.3.1節で指定されるように導出される。これは、ピクチャの最初のタイルグループに対してのみ呼び出される必要がある。
- 非IDRピクチャのタイルグループごとの復号プロセスの開始において、参照ピクチャリスト0(RefPicList[ 0 ])および参照ピクチャリスト1(RefPicList[ 1 ])の導出のために、第8.3.2節で指定される参照ピクチャリスト構成のための復号プロセスが呼び出される。
- 第8.3.3節における参照ピクチャマーキングのための復号プロセスが呼び出され、参照ピクチャは、「参照のために未使用」または「長期の参照のために使用済み」としてマークされ得る。これは、ピクチャの最初のタイルグループに対してのみ呼び出される。
- PicOutputFlagは次のように設定される。
- 次の条件のうちの1つが真であるとき、PictureOutputFlagは、0に等しく設定される。
- 現在ピクチャがRASLピクチャであり、関連付けられるIRAPピクチャのNoIncorrectPicOutputFlagが1に等しい。
- gdr_enabled_flagが1に等しく、現在ピクチャが、NoIncorrectPicOutputFlagが1に等しいGDRピクチャである。
- gdr_enabled_flagが1に等しく、現在ピクチャが、refreshed_region_flagが0に等しい1つまたは複数のタイルグループを含み、関連付けられるGDRピクチャのNoBrokenPictureOutputFlagが1に等しい。
- そうでない場合、PicOutputFlagは、1に等しく設定される。
3. 復号プロセスは、ツリーユニットをコーディングすること、スケーリング、変換、ループ内フィルタ処理などのために呼び出される。
4. 現在ピクチャのすべてのタイルグループが復号された後、現在の復号ピクチャが「短期の参照のために使用済み」としてマークされる。
ピクチャ順序カウントのための復号プロセスが説明される。
このプロセスの出力は、PicOrderCntVal、すなわち、現在ピクチャのピクチャ順序カウントである。
コーディングされた各ピクチャは、PicOrderCntValとして示されるピクチャ順序カウント変数に関連付けられる。
現在ピクチャが、NoIncorrectPicOutputFlagが1に等しいIRAPピクチャ、またはNoIncorrectPicOutputFlagが1に等しいGDRピクチャでないとき、変数prevPicOrderCntLsbおよびprevPicOrderCntMsbは、次のように導出される。
- 0に等しいTemporalIdを有するとともにRASLまたはRADLピクチャでない、復号順序で前のピクチャを、prevTid0Picとする。
- 変数prevPicOrderCntLsbは、prevTid0Picのtile_group_pic_order_cnt_lsbに等しく設定される。
- 変数prevPicOrderCntMsbは、prevTid0PicのPicOrderCntMsbに等しく設定される。
現在ピクチャの変数PicOrderCntMsbは、次のように導出される。
- 現在ピクチャが、NoIncorrectPicOutputFlagが1に等しいIRAPピクチャ、またはNoIncorrectPicOutputFlagが1に等しいGDRピクチャであるとき、PicOrderCntMsbは、0に等しく設定される。
- そうでない場合、PicOrderCntMsbは、次のように導出される。
if( ( tile_group_pic_order_cnt_lsb < prevPicOrderCntLsb ) && ( ( prevPicOrderCntLsb - tile_group_pic_order_cnt_lsb ) >= ( MaxPicOrderCntLsb / 2 ) ) )
PicOrderCntMsb = prevPicOrderCntMsb + MaxPicOrderCntLsb (8-1)
else if( (tile_group_pic_order_cnt_lsb > prevPicOrderCntLsb ) && ( ( tile_group_pic_order_cnt_lsb - prevPicOrderCntLsb ) > ( MaxPicOrderCntLsb / 2 ) ) )
PicOrderCntMsb = prevPicOrderCntMsb - MaxPicOrderCntLsb
else
PicOrderCntMsb = prevPicOrderCntMsb
PicOrderCntValは、次のように導出される。
PicOrderCntVal = PicOrderCntMsb + tile_group_pic_order_cnt_lsb (8-2)
注1 - NoIncorrectPicOutputFlagが1に等しいIRAPピクチャに対してPicOrderCntMsbが0に等しく設定されるので、NoIncorrectPicOutputFlagが1に等しいすべてのIRAPピクチャは、tile_group_pic_order_cnt_lsbに等しいPicOrderCntValを有する。
注1 - NoIncorrectPicOutputFlagが1に等しいGDRピクチャに対してPicOrderCntMsbが0に等しく設定されるので、NoIncorrectPicOutputFlagが1に等しいすべてのGDRピクチャは、tile_group_pic_order_cnt_lsbに等しいPicOrderCntValを有する。
PicOrderCntValの値は、両端値を含む-231~231 - 1という範囲の中になければならない。
現在ピクチャがGDRピクチャであるとき、LastGDRPocValの値は、PicOrderCntValに等しくなるように設定される。
ピクチャがリフレッシュされた境界位置のための復号プロセスが説明される。
このプロセスは、gdr_enabled_flagが1に等しいときにしか呼び出されない。
このプロセスは、タイルグループヘッダ構文解析が完了した後に呼び出される。
このプロセスの出力は、PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPos、すなわち、現在ピクチャのリフレッシュ済みの領域の境界位置である。
コーディングされた各ピクチャは、PicOrderCntValとして示されるリフレッシュ済み領域境界位置変数のセットに関連付けられる。
PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosは、次のように導出される。
タイルグループが、refreshed_region_flagが1に等しい現在ピクチャの最初に受信されたタイルグループである場合、以下のことが適用される。
PicRefreshedLeftBoundaryPos = TGRefreshedLeftBoundary
PicRefreshedRightBoundaryPos = TGRefreshedRightBoundary
PicRefreshedTopBoundaryPos = TGRefreshedTopBoundary
PicRefreshedBotBoundaryPos = TileGroupBotBoundary
そうではなく、refreshed_region_flagが1に等しい場合、以下のことが適用される。
PicRefreshedLeftBoundaryPos = TGRefreshedLeftBoundary < PicRefreshedLeftBoundaryPos ? TGRefreshedLeftBoundary : PicRefreshedLeftBoundaryPos
PicRefreshedRightBoundaryPos = TGRefreshedRightBoundary > PicRefreshedRightBoundaryPos ? TGRefreshedRightBoundary : PicRefreshedRightBoundaryPos
PicRefreshedTopBoundaryPos = TGRefreshedTopBoundary < PicRefreshedTopBoundaryPos ? TGRefreshedTopBoundary : RefreshedRegionTopBoundaryPos
PicRefreshedBotBoundaryPos = TileGroupBotBoundary > PicRefreshedBotBoundaryPos ? TileGroupBotBoundary : PicRefreshedBotBoundaryPos
参照ピクチャリスト構成のための復号プロセスが説明される。
...
NoIncorrectPicOutputFlagが1に等しいIRAPピクチャまたはNoIncorrectPicOutputFlagが1に等しいGDRピクチャでない、各現在ピクチャに対して、maxPicOrderCnt - minPicOrderCntの値がMaxPicOrderCntLsb / 2よりも小さくなければならないことが、ビットストリーム適合の要件である。
...
参照ピクチャマーキングのための復号プロセス。
...
現在ピクチャが、NoIncorrectPicOutputFlagが1に等しいIRAPピクチャまたはNoIncorrectPicOutputFlagが1に等しいGDRピクチャである場合、(もしあれば)現在、DPBの中にあるすべての参照ピクチャは「参照のために未使用」としてマークされる。
...
時間ルーマ動きベクトル予測のための導出プロセスが説明される。
...
変数currCbは、ルーマロケーション( xCb, yCb )における現在ルーマコーディングブロックを指定する。
変数mvLXColおよびavailableFlagLXColは、次のように導出される。
- tile_group_temporal_mvp_enabled_flagが0に等しい場合、mvLXColの両方の成分は、0に等しく設定され、availableFlagLXColは、0に等しく設定される。
- そうでない(tile_group_temporal_mvp_enabled_flagが1に等しい)場合、以下の順序付きステップが適用される。
1. 右下のコロケートされた動きベクトルが、次のように導出される。
xColBr = xCb + cbWidth (8-414)
yColBr = yCb + cbHeight (8-415)
leftBoundaryPos = gdr_enabled_flag ? RefPicList[ X ][ refIdxLX ]によって参照されるピクチャのPicRefreshedLeftBoundaryPos : 0 (8-415)
topBoundaryPos = gdr_enabled_flag ? RefPicList[ X ][ refIdxLX ]によって参照されるピクチャのPicRefreshedTopBoundaryPos : 0 (8-415)
rightBoundaryPos = gdr_enabled_flag ? RefPicList[ X ][ refIdxLX ]によって参照されるピクチャのPicRefreshedRightBoundaryPos : pic_width_in_luma_samples (8-415)
botBoundaryPos = gdr_enabled_flag ? RefPicList[ X ][ refIdxLX ]によって参照されるピクチャのPicRefreshedBotBoundaryPos : pic_height_in_luma_samples (8-415)
- yCb >> CtbLog2SizeYがyColBr >> CtbLog2SizeYに等しく、yColBrが、両端値を含むtopBoundaryPosからbotBoundaryPosまでの範囲の中にあり、かつxColBrが、両端値を含むleftBoundaryPosからrightBoundaryPosまでの範囲の中にある場合、以下のことが適用される。
- 変数colCbは、ColPicによって指定されるコロケートされたピクチャの内側の、( ( xColBr >> 3 ) << 3, ( yColBr >> 3 ) << 3 )によって与えられる修正済みのロケーションをカバーするルーマコーディングブロックを指定する。
- ルーマロケーション( xColCb, yColCb )は、ColPicによって指定されるコロケートされたピクチャの左上のルーマサンプルに対してcolCbによって指定されるコロケートされたルーマコーディングブロックの左上のサンプルに等しく設定される。
- 第8.5.2.12節で指定されるようなコロケートされた動きベクトルのための導出プロセスは、入力としてcurrCb、colCb、( xColCb, yColCb )、refIdxLX、および0に等しく設定されたsbFlagとともに呼び出され、出力がmvLXColおよびavailableFlagLXColに割り当てられる。
- そうでない場合、mvLXColの両方の成分は、0に等しく設定され、availableFlagLXColは、0に等しく設定される。
2. ...
ルーマサンプル双線形補間プロセスが説明される。
このプロセスの入力は、以下の通りである。
- フルサンプル単位でのルーマロケーション( xIntL, yIntL )、
- 分数サンプル単位でのルーマロケーション( xFracL, yFracL )、
- ルーマ参照サンプルアレイrefPicLXL
- 参照ピクチャのリフレッシュ済み領域境界PicRefreshedLeftBoundaryPos、PicRefreshedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPos。
...
フルサンプル単位でのルーマロケーション( xInti, yInti )は、i = 0..1に対して次のように導出される。
- gdr_enabled_flagが1に等しい場合、以下のことが適用される。
xInti = Clip3( PicRefreshedLeftBoundaryPos, PicRefreshedRightBoundaryPos, xIntL + i ) (8-458)
yInti = Clip3( PicRefreshedTopBoundaryPos, PicRefreshedBotBoundaryPos, yIntL + i ) (8-458)
- そうでない(gdr_enabled_flagが0に等しい)場合、以下のことが適用される。
xInti = sps_ref_wraparound_enabled_flag ? ClipH( ( sps_ref_wraparound_offset_minus1 + 1 ) * MinCbSizeY, picW, ( xIntL + i ) ) : (8-459)
Clip3( 0, picW - 1, xIntL + i )
yInti = Clip3( 0, picH - 1, yIntL + i ) (8-460)
...
ルーマサンプル8タップ補間フィルタ処理プロセスが説明される。
このプロセスの入力は、以下の通りである。
- フルサンプル単位でのルーマロケーション( xIntL, yIntL )、
- 分数サンプル単位でのルーマロケーション( xFracL, yFracL )、
- ルーマ参照サンプルアレイrefPicLXL
- 参照サンプルパディングの方向および量を指定する、dir = 0,1を伴うリストpadVal[ dir ]。
- 参照ピクチャのリフレッシュ済み領域境界PicRefreshedLeftBoundaryPos、PicRefreshedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPos。
...
フルサンプル単位でのルーマロケーション( xInti, yInti )は、i = 0..7に対して次のように導出される。
- gdr_enabled_flagが1に等しい場合、以下のことが適用される。
xInti = Clip3( PicRefreshedLeftBoundaryPos, PicRefreshedRightBoundaryPos, xIntL + i - 3 ) (8-830)
yInti = Clip3( PicRefreshedTopBoundaryPos, PicRefreshedBotBoundaryPos, yIntL + i - 3 ) (8-830)
- そうでない(gdr_enabled_flagが0に等しい)場合、以下のことが適用される。
xInti = sps_ref_wraparound_enabled_flag ? ClipH( ( sps_ref_wraparound_offset_minus1 + 1 ) * MinCbSizeY, picW, xIntL + i - 3 ) : (8-831)
Clip3( 0, picW - 1, xIntL + i - 3 )
yInti = Clip3( 0, picH - 1, yIntL + i - 3 ) (8-832)
クロマサンプル補間プロセスが説明される。
このプロセスの入力は、以下の通りである。
- フルサンプル単位でのクロマロケーション( xIntC, yIntC )、
- 1/32分数サンプル単位でのクロマロケーション( xFracC, yFracC )、
- クロマ参照サンプルアレイrefPicLXC
- 参照ピクチャのリフレッシュ済み領域境界PicRefreshedLeftBoundaryPos、PicRefreshedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPos。
...
変数xOffsetは、( sps_ref_wraparound_offset_minus1 + 1 ) * MinCbSizeY ) / SubWidthCに等しく設定される。
フルサンプル単位でのクロマロケーション( xInti, yInti )は、i = 0..3に対して次のように導出される。
- gdr_enabled_flagが1に等しい場合、以下のことが適用される。
xInti = Clip3( PicRefreshedLeftBoundaryPos / SubWidthC, PicRefreshedRightBoundaryPos / SubWidthC, xIntL + i ) (8-844)
yInti = Clip3( PicRefreshedTopBoundaryPos / SubHeightC, PicRefreshedBotBoundaryPos / SubHeightC, yIntL + i ) (8-844)
- そうでない(gdr_enabled_flagが0に等しい)場合、以下のことが適用される。
xInti = sps_ref_wraparound_enabled_flag ? ClipH( xOffset, picWC, xIntC + i - 1 ) : (8-845)
Clip3( 0, picWC - 1, xIntC + i - 1 )
yInti = Clip3( 0, picHC - 1, yIntC + i - 1 ) (8-846)
デブロッキングフィルタプロセスが説明される。
全般的なプロセス。
...
デブロッキングフィルタプロセスは、以下のタイプのエッジを除いて、ピクチャのすべてのコーディングサブブロックエッジおよび変換ブロックエッジに適用される。
- ピクチャの境界にあるエッジ。
- 以下のことのすべてが満たされるとき、タイルグループtgAの上の境界に一致するエッジ。
- gdr_enabled_flagが1に等しい。
- loop_filter_across_refreshed_region_enabled_flagが0に等しい。
- そのエッジがタイルグループtgBの下の境界に一致し、tgBのrefreshed_region_flagの値がtgAのrefreshed_region_flagの値とは異なる。
- 以下のことのすべてが満たされるとき、タイルグループtgAの左の境界に一致するエッジ。
- gdr_enabled_flagが1に等しい。
- loop_filter_across_refreshed_region_enabled_flagが0に等しい。
- そのエッジがタイルグループtgBの右の境界に一致し、tgBのrefreshed_region_flagの値がtgAのrefreshed_region_flagの値とは異なる。
- loop_filter_across_tiles_enabled_flagが0に等しいとき、タイル境界に一致するエッジ。
- tile_group_loop_filter_across_tile_groups_enabled_flagが0に等しいかまたはtile_group_deblocking_filter_disabled_flagが1に等しいタイルグループの、上または左の境界に一致するエッジ。
- tile_group_deblocking_filter_disabled_flagが1に等しいタイルグループ内のエッジ。
- 考慮される成分の8×8サンプルグリッド境界に対応しないエッジ。
- エッジの両側がインター予測を使用するクロマ成分内のエッジ。
- 関連する変換ユニットのエッジでないクロマ変換ブロックのエッジ。
- IntraSubPartitionsSplit値がISP_NO_SPLITに等しくないコーディングユニットのルーマ変換ブロックを横断するエッジ。
一方向のためのデブロッキングフィルタプロセスが説明される。
...
コーディングブロック幅log2CbW、コーディングブロック高さlog2CbH、およびコーディングブロックの左上のサンプルのロケーション( xCb, yCb )を有するコーディングユニットごとに、edgeTypeがEDGE_VERに等しくxCb % 8が0に等しいとき、またはedgeTypeがEDGE_HORに等しくyCb % 8が0に等しいとき、以下の順序付きステップによってエッジがフィルタ処理される。
1. コーディングブロック幅nCbWが、1 << log2CbWに等しく設定され、コーディングブロック高さnCbHが、1 << log2CbHに等しく設定される。
2. 変数filterEdgeFlagが、次のように導出される。
- edgeTypeがEDGE_VERに等しく、かつ次の条件のうちの1つまたは複数が真である場合、filterEdgeFlagは、0に等しく設定される。
- 現在コーディングブロックの左の境界がピクチャの左の境界である。
- 現在コーディングブロックの左の境界がタイルの左の境界であり、loop_filter_across_tiles_enabled_flagが0に等しい。
- 現在コーディングブロックの左の境界がタイルグループの左の境界であり、tile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
- 現在コーディングブロックの左の境界が現在タイルグループの左の境界であり、次のすべての条件が満たされる。
- gdr_enabled_flagが1に等しい。
- loop_filter_across_refreshed_region_enabled_flagが0に等しい。
- 現在タイルグループの左の境界と境界を共有したタイルグループが存在し、そのrefreshed_region_flagの値が現在タイルグループのrefreshed_region_flagの値とは異なる。
- そうではなく、edgeTypeがEDGE_HORに等しく、かつ次の条件のうちの1つまたは複数が真である場合、変数filterEdgeFlagは、0に等しく設定される。
- 現在ルーマコーディングブロックの上の境界がピクチャの上の境界である。
- 現在コーディングブロックの上の境界がタイルの上の境界であり、loop_filter_across_tiles_enabled_flagが0に等しい。
- 現在コーディングブロックの上の境界がタイルグループの上の境界であり、tile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
- 現在コーディングブロックの上の境界が現在タイルグループの上の境界であり、次のすべての条件が満たされる。
- gdr_enabled_flagが1に等しい。
- loop_filter_across_refreshed_region_enabled_flagが0に等しい。
- 現在タイルグループの上の境界と境界を共有したタイルグループが存在し、そのrefreshed_region_flagの値が現在タイルグループのrefreshed_region_flagの値とは異なる。
- そうでない場合、filterEdgeFlagは、1に等しく設定される。
タイルが統合されると、シンタックスを適合させる。
3. 2次元(nCbW)×(nCbH)アレイedgeFlagsのすべての要素は、0に等しくなるように初期化される。
SAOのためのCTB修正プロセスが説明される。
...
i = 0..nCtbSw - 1かつj = 0..nCtbSh - 1を伴うすべてのサンプルロケーション( xSi, ySj )および( xYi, yYj )に対して、recPicture[ xSi ][ ySj ]をカバーするコーディングブロックを含むコーディングユニットのpcm_loop_filter_disabled_flag、pcm_flag[ xYi ][ yYj ]、およびcu_transquant_bypass_flagの値に応じて、以下のことが適用される。
- ....
将来決定変換/量子化バイパスにおいて保留中の強調されたセクションを修正する。
- そうではなく、SaoTypeIdx[ cIdx ][ rx ][ ry ]が2に等しい場合、以下の順序付きステップが適用される。
1. k = 0..1に対するhPos[ k ]およびvPos[ k ]の値が、SaoEoClass[ cIdx ][ rx ][ ry ]に基づいてTable 8-18の中で指定される。
2. 変数edgeIdxが、次のように導出される。
- 修正済みのサンプルロケーション( xSik', ySjk' )および( xYik', yYik' )が、次のように導出される。
( xSik', ySjk' ) = ( xSi + hPos[ k ], ySj + vPos[ k ] ) (8-1128)
( xYik', yYjk' ) = ( cIdx = = 0 ) ? ( xSik', ySjk' ) : ( xSik' * SubWidthC, ySjk' * SubHeightC ) (8-1129)
- k = 0..1を伴うすべてのサンプルロケーション( xSik', ySjk' )および( xYik', yYjk' )に対して次の条件のうちの1つまたは複数が真である場合、edgeIdxは、0に等しく設定される。
- ロケーション( xSik', ySjk' )におけるサンプルが、ピクチャ境界の外側にある。
- gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、現在タイルグループのrefreshed_region_flagが1に等しく、かつロケーション( xSik', ySjk' )におけるサンプルを含むタイルグループのrefreshed_region_flagが0に等しい。
- ロケーション( xSik', ySjk' )におけるサンプルが、異なるタイルグループに属し、次の2つの条件のうちの1つが真である。
- MinTbAddrZs[ xYik' >> MinTbLog2SizeY ][ yYjk' >> MinTbLog2SizeY ]がMinTbAddrZs[ xYi >> MinTbLog2SizeY ][ yYj >> MinTbLog2SizeY ]よりも小さく、サンプルrecPicture[ xSi ][ ySj ]が属するタイルグループの中のtile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
- MinTbAddrZs[ xYi >> MinTbLog2SizeY ][ yYj >> MinTbLog2SizeY ]がMinTbAddrZs[ xYik' >> MinTbLog2SizeY ][ yYjk' >> MinTbLog2SizeY ]よりも小さく、サンプルrecPicture[ xSik' ][ ySjk' ]が属するタイルグループの中のtile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
- loop_filter_across_tiles_enabled_flagが0に等しく、ロケーション( xSik', ySjk' )におけるサンプルが、異なるタイルに属する。
タイルグループを有しないタイルが組み込まれるとき、強調されたセクションを修正する。
- そうでない場合、edgeIdxは、次のように導出される。
- 以下のことが適用される。
edgeIdx = 2 + Sign( recPicture[ xSi ][ ySj ] - recPicture[ xSi + hPos[ 0 ] ][ ySj + vPos[ 0 ] ] ) + Sign( recPicture[ xSi ][ ySj ] - recPicture[ xSi + hPos[ 1 ] ][ ySj + vPos[ 1 ] ] ) (8-1130)
- edgeIdxが0、1、または2に等しいとき、edgeIdxは次のように修正される。
edgeIdx = ( edgeIdx = = 2 ) ? 0 : ( edgeIdx + 1 ) (8-1131)
3. 修正済みのピクチャサンプルアレイsaoPicture[ xSi ][ ySj ]が、次のように導出される。
saoPicture[ xSi ][ ySj ] = Clip3( 0, ( 1 << bitDepth ) - 1, recPicture[ xSi ][ ySj ] + SaoOffsetVal[ cIdx ][ rx ][ ry ][ edgeIdx ] ) (8-1132)
ALFのためのルーマサンプルに対するコーディングツリーブロックフィルタ処理プロセスが説明される。
...
フィルタ処理済みの再構成ルーマサンプルalfPictureL[ x ][ y ]の導出のために、現在のルーマコーディングツリーブロックの内側の各再構成ルーマサンプルrecPictureL[ x ][ y ]が、x, y = 0..CtbSizeY - 1を伴って次のようにフィルタ処理される。
- ...
- ルーマサンプルの所与のアレイrecPictureの内側の対応するルーマサンプル( x, y )の各々に対するロケーション( hx, vy )は、次のように導出される。
- gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、ロケーション( x, y )におけるルーマサンプルを含むタイルグループtgAのrefreshed_region_flagが1に等しい場合、以下のことが適用される。
- ロケーション( hx, vy )が別のタイルグループtgBの中に位置し、かつtgBのrefreshed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれ、TGRefreshedLeftBoundary、TGRefreshedRightBoundary、TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。
- そうでない場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれ、PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。
hx = Clip3( leftBoundary, rightBoundary, xCtb + x ) (8-1140)
vy = Clip3( topBoundary, botBoundary, yCtb + y ) (8-1141)
- そうでない場合、以下のことが適用される。
hx = Clip3( 0, pic_width_in_luma_samples - 1, xCtb + x ) (8-1140)
vy = Clip3( 0, pic_height_in_luma_samples - 1, yCtb + y ) (8-1141)
- ...
ルーマサンプルに対するALF転置およびフィルタインデックスのための導出プロセスが説明される。
...
ルーマサンプルの所与のアレイrecPictureの内側の対応するルーマサンプル( x, y )の各々に対するロケーション( hx, vy )が、次のように導出される。
- gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、ロケーション( x, y )におけるルーマサンプルを含むタイルグループtgAのrefreshed_region_flagが1に等しい場合、以下のことが適用される。
- ロケーション( hx, vy )が別のタイルグループtgBの中に位置し、かつtgBのrefreshed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれ、TGRefreshedLeftBoundary、TGRefreshedRightBoundary、TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。
- そうでない場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれ、PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。
hx = Clip3( leftBoundary, rightBoundary, x ) (8-1140)
vy = Clip3( topBoundary, botBoundary, y ) (8-1141)
- そうでない場合、以下のことが適用される。
hx = Clip3( 0, pic_width_in_luma_samples - 1, x ) (8-1145)
vy = Clip3( 0, pic_height_in_luma_samples - 1, y ) (8-1146)
クロマサンプルのためのコーディングツリーブロックフィルタ処理プロセスが説明される。
...
フィルタ処理済みの再構成クロマサンプルalfPicture[ x ][ y ]の導出のために、現在のクロマコーディングツリーブロックの内側の各再構成クロマサンプルrecPicture[ x ][ y ]が、x, y = 0..ctbSizeC - 1を伴って次のようにフィルタ処理される。
- クロマサンプルの所与のアレイrecPictureの内側の対応するクロマサンプル( x, y )の各々に対するロケーション( hx, vy )が、次のように導出される。
- gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、ロケーション( x, y )におけるルーマサンプルを含むタイルグループtgAのrefreshed_region_flagが1に等しい場合、以下のことが適用される。
- ロケーション( hx, vy )が別のタイルグループtgBの中に位置し、かつtgBのrefreshed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれ、TGRefreshedLeftBoundary、TGRefreshedRightBoundary、TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。
- そうでない場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれ、PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。
hx = Clip3( leftBoundary / SubWidthC, rightBoundary / SubWidthC, xCtbC + x ) (8-1140)
vy = Clip3( topBoundary / SubWidthC, botBoundary / SubWidthC, yCtbC + y ) (8-1141)
- そうでない場合、以下のことが適用される。
hx = Clip3( 0, pic_width_in_luma_samples / SubWidthC - 1, xCtbC + x ) (8-1177)
vy = Clip3( 0, pic_height_in_luma_samples / SubHeightC - 1, yCtbC + y ) (8-1178)
図7は、本開示の一実施形態による、漸次復号リフレッシュ(GDR)技法700を実施するように構成されたビデオビットストリーム750を示す。GDR技法700は、図5のGDR技法500と同様でありうる。本明細書で使用するビデオビットストリーム750は、コーディングされたビデオビットストリーム、ビットストリーム、またはそれらの変形と呼ばれることもある。図7に示すように、ビットストリーム750は、シーケンスパラメータセット(SPS:sequence parameter set)752、ピクチャパラメータセット(PPS:picture parameter set)754、スライスヘッダ756、および画像データ758を含む。
SPS752は、ピクチャのシーケンス(SOP:sequence of pictures)の中のすべてのピクチャに共通のデータを含む。対照的に、PPS754は、ピクチャ全体に共通のデータを含む。スライスヘッダ756は、たとえば、スライスタイプ、参照ピクチャのうちのどれが使用されるのかなどの、現在スライスについての情報を含む。SPS752およびPPS754は、パラメータセットと総称されることがある。SPS752、PPS754、およびスライスヘッダ756は、ネットワーク抽象化レイヤ(NAL)ユニットのタイプである。NALユニットは、後続すべきデータ(たとえば、コーディングされたビデオデータ)のタイプの表示を含むシンタックス構造である。NALユニットは、ビデオコーディングレイヤ(VCL)NALユニットおよび非VCL NALユニットに分類される。VCL NALユニットは、ビデオピクチャの中のサンプルの値を表すデータを含み、非VCL NALユニットは、パラメータセット(多数のVCL NALユニットに適用され得る重要なヘッダデータ)などの関連する任意の追加情報、および補足エンハンスメント情報(タイミング情報、および復号ビデオ信号の有用性を向上させ得るが、ビデオピクチャの中のサンプルの値を復号するために必要でない、他の追加データ)を含む。ビットストリーム750が、実際の適用例では他のパラメータおよび情報を含み得ることを、当業者は理解するであろう。
ビデオビットストリーム750は、CVS708に対応するGDRフラグを含む。一実施形態では、GDRフラグはSPS752の中で搬送される。しかしながら、GDRフラグは、実際の適用例ではビデオビットストリーム750の中の他の場所に配置されうる。一実施形態では、GDRフラグはgdr_enabled_flagと指定される。GDRフラグの値は、CVS708に対してGDRが有効化されているかどうかを示す。たとえば、GDRフラグの値が1であるとき、GDRは有効化されており、GDRフラグの値が0であるとき、GDRは有効化されていない。
図7の画像データ758は、符号化中または復号中の画像またはビデオに関連するデータを含む。画像データ758は、単に、ペイロード、またはビットストリーム750の中で搬送中のデータと呼ばれることがある。一実施形態では、画像データ758は、GDRピクチャ702、1つまたは複数のトレーリングピクチャ704、およびリカバリポイントピクチャ706を含む、CVS708を含む。一実施形態では、GDRピクチャ702、トレーリングピクチャ704、およびリカバリポイントピクチャ706は、CVS708の中のGDR期間を規定し得る。
図7に示すように、GDR技法700または原理は、GDRピクチャ702で開始しリカバリポイントピクチャ706で終了する一連のピクチャにわたって機能する。GDR技法700、GDRピクチャ702、トレーリングピクチャ704、およびリカバリポイントピクチャ706は、図5のGDR技法500、GDRピクチャ502、トレーリングピクチャ504、およびリカバリポイントピクチャ506と同様である。したがって、簡潔のために、GDR技法700が実施される方式は、図7に関して繰り返さない。
図7に示すように、CVS708の中のGDRピクチャ702、トレーリングピクチャ704、およびリカバリポイントピクチャ706は各々、それら自体のVCL NALユニット730内に含まれる。CVS708の中のVCL NALユニット730のセットは、アクセスユニットと呼ばれることがある。
CVS708の中のGDRピクチャ702を含むNALユニット730は、GDR NALユニットタイプ(GDR_NUT)を有する。すなわち、一実施形態では、CVS708の中のGDRピクチャ702を含むNALユニット730は、トレーリングピクチャ704およびリカバリポイントピクチャ706に対してそれ自体の固有のNALユニットタイプを有する。一実施形態では、GDR_NUTは、ビットストリームがIRAPピクチャで始まる必要があるのではなく、ビットストリームがGDRピクチャ702で始まることを可能にする。GDRピクチャ702のVCL NALユニット730をGDR_NUTとして指定することは、CVS708の中の初期VCL NALユニット730がGDRピクチャ702を含むことを、たとえば、デコーダに示してよい。
一実施形態では、GDRピクチャ702はCVS708の中の初めのピクチャである。一実施形態では、GDRピクチャ702はGDR期間の中の初めのピクチャである。一実施形態では、GDRピクチャ702は0に等しい時間識別子(ID)を有する。時間IDは、他のピクチャに対するピクチャの位置または順序を識別する値または数である。一実施形態では、GDR_NUTを有するVCL NALユニット730を含むアクセスユニットは、GDRアクセスユニットと指定される。一実施形態では、GDRピクチャ702は、別の(たとえば、より大きい)GDRピクチャのコーディングされたスライスである。すなわち、GDRピクチャ702は、より大きいGDRピクチャの一部分でありうる。
図8は、ビデオデコーダ(たとえば、ビデオデコーダ30)によって実施される、コーディングされたビデオビットストリームを復号する方法800の一実施形態である。方法800は、ビデオエンコーダ(たとえば、ビデオエンコーダ20)から復号ビットストリームが直接または間接的に受信された後に実行されてよい。方法800は、IRAPピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とするので、本方法は復号プロセスを改善する。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を許す。したがって、実際には、コーデックの性能が改善され、そのことはより良好なユーザエクスペリエンスにつながる。
ブロック802において、ビデオデコーダは、CVS(たとえば、CVS708)に対応するGDRフラグを含む、コーディングされたビデオビットストリームを受信する。一実施形態では、GDRフラグは、ビットストリーム(たとえば、ビットストリーム750)のシーケンスパラメータセット(たとえば、SPS752)の中に含まれる。一実施形態では、GDRフラグはgdr_enabled_flagと指定される。
ブロック804において、ビデオデコーダは、GDRピクチャ(たとえば、GDRピクチャ702)がCVSの中に存在するかどうかをGDRフラグの値に基づいて決定する。すなわち、DGRフラグは、GDRが有効化されているかどうかを示す。一実施形態では、GDRが有効化されているとき、GDRフラグの値は1である。
ブロック806において、ビデオデコーダは、GDRピクチャが存在することをGDRフラグの値が示すとき、GDRピクチャにおいてCVSの復号を開始する。ブロック808において、ビデオデコーダは、復号されたCVSに従って画像を生成する。画像は、次いで、電子デバイス(たとえば、スマートフォン、タブレット、ラップトップ、パーソナルコンピュータなど)のユーザのために表示され得る。
一実施形態では、方法800は、GDRが有効化されていないことをGDRフラグの値に基づいて決定し得る。一実施形態では、GDRが有効化されていないとき、GDRフラグの値は0である。
図9は、ビデオエンコーダ(たとえば、ビデオエンコーダ20)によって実施される、ビデオビットストリームを符号化する方法900の一実施形態である。(たとえば、ビデオからの)ピクチャがビデオビットストリームの中に符号化され、次いで、ビデオデコーダ(たとえば、ビデオデコーダ30)に向かって送信されることになるとき、方法900が実行され得る。方法900は、IRAPピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とするので、本方法は符号化プロセスを改善する。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されえ、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、実際には、コーデックの性能が改善され、そのことはより良好なユーザエクスペリエンスにつながる。
ブロック902において、ビデオエンコーダは、ビデオビットストリームのCVSの中でGDRピクチャ(たとえば、GDRピクチャ702)を符号化する。ブロック904において、ビデオエンコーダは、GDRピクチャがビデオビットストリームのCVSの中に存在することを示すための第1の値にGDRフラグを設定する。一実施形態では、GDRピクチャが存在するとき、GDRフラグの値は1である。一実施形態では、GDRフラグは、ビットストリーム(たとえば、ビットストリーム750)のシーケンスパラメータセット(たとえば、SPS752)の中に符号化される。一実施形態では、GDRフラグはgdr_enabled_flagと指定される。
ブロック904において、ビデオエンコーダは、GDRが有効化されているとき、GDRピクチャ(たとえば、GDRピクチャ702)をビデオビットストリームのCVSの中に符号化する。
ブロック906において、ビデオエンコーダは、ビデオデコーダに向かう送信のためにビットストリームを記憶する。ビデオビットストリームは、コーディングされたビデオビットストリームまたは符号化されたビデオビットストリームと呼ばれることもある。ビデオエンコーダは、ビデオデコーダに向かってビットストリームを送信することができる。ビデオデコーダによって受信されると、符号化されたビデオビットストリームは、電子デバイス(たとえば、スマートフォン、タブレット、ラップトップ、パーソナルコンピュータなど)のディスプレイまたはスクリーンにおけるユーザへの表示用に画像を生成または生じさせるために、(たとえば、上記で説明したように)復号され得る。
一実施形態では、方法900は、GDRが有効化されていないことをGDRフラグの値に基づいて決定し得る。一実施形態では、GDRが有効化されていないとき、GDRフラグの値は0である。
図10は、本開示の一実施形態によるビデオコーディングデバイス1000(たとえば、ビデオエンコーダ20またはビデオデコーダ30)の概略図である。ビデオコーディングデバイス1000は、本明細書で説明するような、開示する実施形態を実施するのに適している。ビデオコーディングデバイス1000は、データを受信するための入口ポート1010および受信器ユニット(Rx)1020、データを処理するためのプロセッサ、論理ユニット、または中央処理ユニット(CPU)1030、データを送信するための送信器ユニット(Tx)1040および出口ポート1050、ならびにデータを記憶するためのメモリ1060を備える。ビデオコーディングデバイス1000はまた、光信号または電気信号の出口または入口のために、入口ポート1010、受信器ユニット1020、送信器ユニット1040、および出口ポート1050に結合された、光電気(OE:optical-to-electrical)構成要素および電気光(EO:electrical-to-optical)構成要素を含み得る。
プロセッサ1030は、ハードウェアおよびソフトウェアによって実装される。プロセッサ1030は、1つまたは複数のCPUチップ、コア(たとえば、マルチコアプロセッサとして)、フィールドプログラマブルゲートアレイ(FPGA)、特定用途向け集積回路(ASIC)、およびデジタル信号プロセッサ(DSP)として実装されてよい。プロセッサ1030は、入口ポート1010、受信器ユニット1020、送信器ユニット1040、出口ポート1050、およびメモリ1060と通信している。プロセッサ1030はコーディングモジュール1070を備える。コーディングモジュール1070は、上記で説明した開示する実施形態を実施する。たとえば、コーディングモジュール1070は、様々なコーデック機能を実施、処理、準備、または提供する。したがって、コーディングモジュール1070を含むことは、ビデオコーディングデバイス1000の機能への大幅な改善をもたらし、異なる状態へのビデオコーディングデバイス1000の変換に影響を及ぼす。あるいは、コーディングモジュール1070は、メモリ1060の中に記憶されプロセッサ1030によって実行される命令として実装される。
ビデオコーディングデバイス1000はまた、ユーザとの間でデータを通信するための入力および/または出力(I/O)デバイス1080を含み得る。I/Oデバイス1080は、ビデオデータを表示するためのディスプレイ、オーディオデータを出力するためのスピーカーなどの、出力デバイスを含み得る。I/Oデバイス1080はまた、キーボード、マウス、トラックボールなどの入力デバイス、および/またはそのような出力デバイスと相互作用するための対応するインターフェースを含み得る。
メモリ1060は、プログラムが実行のために選択されるときにそのようなプログラムを記憶するために、またプログラム実行中に読み取られる命令およびデータを記憶するために、1つまたは複数のディスク、テープドライブ、およびソリッドステートドライブを備え、オーバーフローデータ記憶デバイスとして使用され得る。メモリ1060は、揮発性および/または不揮発性であってよく、読取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、3元連想メモリ(TCAM:ternary content-addressable memory)、および/またはスタティックランダムアクセスメモリ(SRAM)でありうる。
図11は、コーディングするための手段1100の一実施形態の概略図である。一実施形態では、コーディングするための手段1100は、ビデオコーディングデバイス1102(たとえば、ビデオエンコーダ20またはビデオデコーダ30)の中に実装される。ビデオコーディングデバイス1102は受信手段1101を含む。受信手段1101は、符号化すべきピクチャを受信するか、または復号すべきビットストリームを受信するように構成される。ビデオコーディングデバイス1102は、受信手段1101に結合された送信手段1107を含む。送信手段1107は、ビットストリームをデコーダへ送信するか、または復号画像を表示手段(たとえば、I/Oデバイス1080のうちの1つ)へ送信するように構成される。
ビデオコーディングデバイス1102は記憶手段1103を含む。記憶手段1103は、受信手段1101または送信手段1107のうちの少なくとも1つに結合される。記憶手段1103は、命令を記憶するように構成される。ビデオコーディングデバイス1102はまた、処理手段1105を含む。処理手段1105は、記憶手段1103に結合される。処理手段1105は、本明細書で開示する方法を行うために、記憶手段1103の中に記憶された命令を実行するように構成される。
本明細書に記載する例示的な方法のステップが、必ずしも説明した順序で実行されることを必要とされるとは限らないことも理解されたく、そのような方法のステップの順序は、単に例であるものと理解されたい。同様に、そのような方法の中に追加のステップが含まれてよく、いくつかのステップは、本開示の様々な実施形態に一致する方法の中で省略されてよく組み合わせられてよい。
本開示ではいくつかの実施形態が提供されているが、開示するシステムおよび方法が、本開示の趣旨または範囲から逸脱することなく、多くの他の特定の形態で具現され得ることを理解されたい。本例は限定的ではなく例示的と考えられるべきであり、その意図は本明細書において与えられる詳細に限定されない。たとえば、様々な要素または構成要素が別のシステムの中で組み合わせられてよく、もしくは統合されてよく、またはいくつかの特徴が省略されてよく、もしくは実施されなくてよい。
加えて、様々な実施形態において個別または別個として説明および図示される技法、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技法、または方法と組み合わせられてよく、または統合されてよい。結合されるかもしくは直接結合されるか、または互いに通信するものとして、図示または説明される他の項目は、電気的か、機械的か、または別の方法であるかにかかわらず、いくつかのインターフェース、デバイス、または中間構成要素を通じて、間接的に結合されてよく、または通信していてよい。変更、置換、および改変の他の例は、当業者によって確認可能であり、本明細書で開示する趣旨および範囲から逸脱することなく行うことができる。
10 コーディングシステム
12 ソースデバイス
14 宛先デバイス
16 コンピュータ可読媒体
18 ビデオソース
20 ビデオエンコーダ
22 出力インターフェース
28 入力インターフェース
30 ビデオデコーダ
32 ディスプレイデバイス
40 モード選択ユニット
42 動き推定ユニット
44 動き補償ユニット
46 イントラ予測ユニット
48 区分ユニット
50 加算器
52 変換処理ユニット
54 量子化ユニット
56 エントロピーコーディングユニット
58 逆量子化ユニット
60 逆変換ユニット
62 加算器
64 参照フレームメモリ
70 エントロピー復号ユニット
72 動き補償ユニット
74 イントラ予測ユニット
76 逆量子化ユニット
78 逆変換ユニット
80 加算器
82 参照フレームメモリ
402 IRAPピクチャ
404 リーディングピクチャ
406 トレーリングピクチャ
408 復号順序
410 提示順序
502 GDRピクチャ
504 トレーリングピクチャ
506 リカバリポイントピクチャ
508 コーディングされたビデオシーケンス
510 リフレッシュ済みの/クリーンな領域
512 リフレッシュされていない/ダーティな領域
602 現在ピクチャ
604 参照ピクチャ
604 リフレッシュ済みの領域
606 リフレッシュ済みの領域
608 リフレッシュされていない領域
610 動きベクトル
612 参照ブロック
614 現在ブロック
702 GDRピクチャ
704 トレーリングピクチャ
706 リカバリポイントピクチャ
708 CVS
730 NALユニット
750 ビデオビットストリーム
752 シーケンスパラメータセット(SPS)
754 ピクチャパラメータセット(PPS)
756 スライスヘッダ
758 画像データ
760 ピクチャ
1000 ビデオコーディングデバイス
1010 入口ポート
1020 受信器ユニット(Rx)
1030 プロセッサ
1040 送信器ユニット(Tx)
1050 出口ポート
1060 メモリ
1070 コーディングモジュール
1080 I/Oデバイス
1100 コーディングするための手段
1101 受信手段
1102 ビデオコーディングデバイス
1103 記憶手段
1105 処理手段
1107 送信手段
一般に、本開示は、ビデオコーディングにおける漸次復号リフレッシュをサポートする技法を説明する。より詳細には、本開示は、イントラランダムアクセスポイント(IRAP:intra random access point)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする。
比較的短いビデオでさえ、描くのに必要とされるビデオデータの量は相当であり得、このことは、帯域幅容量が限定された通信ネットワークを横断してデータがストリーミングまたは別の方法で通信されることになるときに困難をもたらす場合がある。したがって、ビデオデータは、一般に、現代の電気通信ネットワークを通じて通信される前に圧縮される。メモリリソースが限定されることがあるので、ビデオが記憶デバイス上に記憶されるときも、ビデオのサイズが問題であり得る。ビデオ圧縮デバイスは、しばしば、ソースにおいてソフトウェアおよび/またはハードウェアを使用して、送信または記憶の前にビデオデータをコーディングし、それによって、デジタルビデオ画像を描写するために必要とされるデータの数量を減らす。圧縮されたデータは、次いで、ビデオデータを復号するビデオ復元デバイスによって宛先において受信される。ネットワークリソースが限定され、より高いビデオ品質の需要が絶えず増大すると、画像品質における犠牲をほとんど伴わずに圧縮率を改善する、改善された圧縮および復元技法が望ましい。
第1の態様は、ビデオデコーダによって実施される、コーディングされたビデオビットストリームを復号する方法に関する。方法は、ビデオデコーダが、コーディングされたビデオビットストリームを受信するステップであって、コーディングされたビデオビットストリームは、コーディングされたビデオシーケンス(CVS:coded video sequence)に対応する漸次復号リフレッシュ(GDR:gradual decoding refresh)フラグを含む、ステップと、ビデオデコーダが、GDRピクチャがCVSの中に存在するかどうかをGDRフラグの値に基づいて決定するステップと、GDRピクチャが存在することをGDRフラグの値が示すとき、ビデオデコーダが、GDRピクチャにおいてCVSの復号を開始するステップと、ビデオデコーダが、復号されたCVSに従って画像を生成するステップとを含む。
本方法は、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
第1の態様それ自体による方法の第1の実装形式では、GDRフラグは、ビットストリームのシーケンスパラメータセットの中に含まれる。
第1の態様それ自体または第1の態様の先行する任意の実装形式による方法の第2の実装形式では、GDRフラグはgdr_enabled_flagと称される。
第1の態様それ自体または第1の態様の先行する任意の実装形式による方法の第3の実装形式では、GDRが有効化されているとき、GDRフラグの値は1である。
第1の態様それ自体または第1の態様の先行する任意の実装形式による方法の第4の実装形式では、GDRピクチャがビデオビットストリームのCVSの中に存在しないとき、GDRフラグは第2の値に設定されるように構成される。
第1の態様それ自体または第1の態様の先行する任意の実装形式による方法の第5の実装形式では、GDRフラグの値は0である。
第2の態様は、ビデオエンコーダによって実施される、ビデオビットストリームを符号化する方法に関する。方法は、ビデオエンコーダが、ビデオビットストリームのコーディングされたビデオシーケンス(CVS)の中に漸次デコーダリフレッシュ(GDR)ピクチャを符号化するステップと、ビデオエンコーダが、GDRピクチャがビデオビットストリームのCVSの中に存在することを示すための第1の値に、GDRフラグを設定するステップと、ビデオエンコーダが、ビデオデコーダに向かう送信のためにビデオビットストリームを記憶するステップとを含む。
本方法は、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
第2の態様それ自体による方法の第1の実装形式では、GDRフラグは、ビットストリームのシーケンスパラメータセットの中に符号化される。
第2の態様それ自体または第2の態様の先行する任意の実装形式による方法の第2の実装形式では、GDRフラグはgdr_enabled_flagと称される。
第2の態様それ自体または第2の態様の先行する任意の実装形式による方法の第3の実装形式では、GDRが有効化されているとき、GDRフラグの第1の値は1である。
第2の態様それ自体または第2の態様の先行する任意の実装形式による方法の第4の実装形式では、GDRピクチャがビデオビットストリームのCVSの中に存在しないとき、GDRフラグは第2の値に設定されるように構成される。
第2の態様それ自体または第2の態様の先行する任意の実装形式による方法の第5の実装形式では、GDRフラグの第2の値は0である。
第3の態様は、復号デバイスに関する。復号デバイスは、コーディングされたビデオビットストリームを受信するように構成された受信器と、受信器に結合されたメモリであって、命令を記憶する、メモリと、メモリに結合されたプロセッサとを含み、プロセッサは、復号デバイスに、コーディングされたビデオビットストリームを受信することであって、コーディングされたビデオビットストリームは、コーディングされたビデオシーケンス(CVS)に対応する漸次復号リフレッシュ(GDR)フラグを含む、ことと、GDRピクチャがCVSの中に存在するかどうかをGDRフラグの値に基づいて決定することと、GDRピクチャが存在することをGDRフラグの値が示すとき、GDRピクチャにおいてCVSの復号を開始することと、復号されたCVSに従って画像を生成することとをさせるために、命令を実行するように構成される。
復号デバイスは、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
第3の態様それ自体による復号デバイスの第1の実装形式では、復号デバイスは、生成された画像を表示するように構成されたディスプレイをさらに備える。
第4の態様は、符号化デバイスに関する。符号化デバイスは、命令を含むメモリと、メモリに結合されたプロセッサであって、符号化デバイスに、ビデオビットストリームのコーディングされたビデオシーケンス(CVS)の中で漸次デコーダリフレッシュ(GDR)ピクチャを符号化することと、GDRピクチャがビデオビットストリームのCVSの中に存在することを示すための第1の値にGDRフラグを設定することとをさせるために、命令を実施するように構成された、プロセッサと、プロセッサに結合された送信器であって、ビデオデコーダに向かってビデオビットストリームを送信するように構成された、送信器とを含む。
符号化デバイスは、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
第4の態様それ自体による符号化デバイスの第1の実装形式では、メモリは、送信器がビデオデコーダに向かってビットストリームを送信する前にビデオビットストリームを記憶する。
第5の態様は、コーディング装置に関する。コーディング装置は、符号化すべきピクチャを受信するか、または復号すべきビットストリームを受信するように構成された、受信器と、受信器に結合された送信器であって、ビットストリームをデコーダへ送信するか、または復号画像をディスプレイへ送信するように構成された、送信器と、受信器または送信器のうちの少なくとも1つに結合されたメモリであって、命令を記憶するように構成された、メモリと、メモリに結合されたプロセッサであって、本明細書で開示する方法のうちのいずれかを行うために、メモリの中に記憶された命令を実行するように構成された、プロセッサとを含む。
コーディング装置は、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
第5の態様それ自体によるコーディング装置の第1の実装形式では、画像を表示するように構成されたディスプレイをさらに備える。
第6の態様は、システムに関する。システムは、エンコーダと、エンコーダと通信しているデコーダとを含み、エンコーダまたはデコーダは、本明細書で開示する復号デバイス、符号化デバイス、またはコーディング装置を含む。
システムは、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
第7の態様は、コーディングするための手段に関する。コーディングするための手段は、符号化すべきピクチャを受信するか、または復号すべきビットストリームを受信するように構成された、受信手段と、受信手段に結合された送信手段であって、ビットストリームを復号手段へ送信するか、または復号画像を表示手段へ送信するように構成された、送信手段と、受信手段または送信手段のうちの少なくとも1つに結合された記憶手段であって、命令を記憶するように構成された、記憶手段と、記憶手段に結合された処理手段であって、本明細書で開示する方法のうちのいずれかを行うために、記憶手段の中に記憶された命令を実行するように構成された、処理手段とを含む。
コーディングするための手段は、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする技法を提供する。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
本開示のより完全な理解のために、添付図面および発明を実施するための形態とともに理解される、以下の簡潔な説明を次に参照し、同様の参照番号は同様の部分を表す。
GDR技法を利用し得る例示的なコーディングシステムを示すブロック図である。 GDR技法を実施し得る例示的なビデオエンコーダを示すブロック図である。 GDR技法を実施し得るビデオデコーダの一例を示すブロック図である。 復号順序および提示順序における、リーディングピクチャ(leading picture)に対するIRAPピクチャと、トレーリングピクチャとの間の関係の描写である。 漸次復号リフレッシュ技法を示す図である。 望ましくない動き探索を示す概略図である。 本開示の一実施形態による、漸次復号リフレッシュ技法を実施するように構成されたビデオビットストリームを示す図である。 コーディングされたビデオビットストリームを復号する方法の一実施形態を示す図である。 ビデオビットストリームを符号化する方法の一実施形態を示す図である。 ビデオコーディングデバイスの概略図である。 コーディングするための手段の一実施形態の概略図である。
図1は、本明細書で説明するようなビデオコーディング技法を利用し得る例示的なコーディングシステム10を示すブロック図である。図1に示すように、コーディングシステム10は、後で宛先デバイス14によって復号されるべき符号化されたビデオデータを提供するソースデバイス12を含む。詳細には、ソースデバイス12は、コンピュータ可読媒体16を介して宛先デバイス14にビデオデータを提供し得る。ソースデバイス12および宛先デバイス14は、デスクトップコンピュータ、ノートブック(たとえば、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビ、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーム機、ビデオストリーミングデバイスなどを含む、広範なデバイスのうちのいずれかを含み得る。場合によっては、ソースデバイス12および宛先デバイス14は、ワイヤレス通信のために装備されうる。
宛先デバイス14は、コンピュータ可読媒体16を介して、復号されるべき符号化されたビデオデータを受信し得る。コンピュータ可読媒体16は、符号化されたビデオデータをソースデバイス12から宛先デバイス14に移動させることが可能な任意のタイプの媒体またはデバイスを含み得る。一例では、コンピュータ可読媒体16は、ソースデバイス12が符号化されたビデオデータを宛先デバイス14へリアルタイムで直接送信することを可能にするための通信媒体を含み得る。符号化されたビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調されてよく、宛先デバイス14へ送信されてよい。通信媒体は、無線周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線路などの、任意のワイヤレスまたは有線の通信媒体を含み得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12から宛先デバイス14への通信を容易にするために有用であり得る任意の他の機器を含み得る。
いくつかの例では、符号化されたデータは、出力インターフェース22から記憶デバイスに出力され得る。同様に、符号化されたデータは、入力インターフェースによって記憶デバイスからアクセスされ得る。記憶デバイスは、ハードドライブ、Blu-ray(登録商標)ディスク、デジタルビデオディスク(DVD)、コンパクトディスク読取り専用メモリ(CD-ROM)、フラッシュメモリ、揮発性メモリもしくは不揮発性メモリ、または符号化されたビデオデータを記憶するための任意の他の好適なデジタル記憶媒体などの、分散されるかまたは局所的にアクセスされる様々なデータ記憶媒体のうちのいずれかを含み得る。さらなる一例では、記憶デバイスは、ソースデバイス12によって生成された符号化されたビデオを記憶し得るファイルサーバまたは別の中間記憶デバイスに相当し得る。宛先デバイス14は、ストリーミングまたはダウンロードを介して記憶デバイスからの記憶済みのビデオデータにアクセスし得る。ファイルサーバは、符号化されたビデオデータを記憶すること、およびその符号化されたビデオデータを宛先デバイス14へ送信することが可能な、任意のタイプのサーバでありうる。例示的なファイルサーバは、(たとえば、ウェブサイト用の)ウェブサーバ、ファイル転送プロトコル(FTP)サーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイス14は、インターネット接続を含む任意の標準データ接続を通じて符号化されたビデオデータにアクセスし得る。このことは、ファイルサーバ上に記憶された符号化されたビデオデータにアクセスするのに適した、ワイヤレスチャネル(たとえば、Wi-Fi接続)、有線接続(たとえば、デジタル加入者回線(DSL)、ケーブルモデムなど)、またはその両方の組合せを含み得る。記憶デバイスからの符号化されたビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せでありうる。
本開示の技法は、必ずしもワイヤレスの適用例または設定に限定されるとは限らない。本技法は、オーバー・ジ・エア・テレビ放送、ケーブルテレビ送信、衛星テレビ送信、動的適応ストリーミングオーバーHTTP(DASH)などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されるデジタルビデオ、データ記憶媒体上に記憶されたデジタルビデオの復号、または他の適用例などの、様々なマルチメディア適用例のうちのいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、コーディングシステム10は、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオ電話などの適用例をサポートするために、一方向または二方向のビデオ送信をサポートするように構成され得る。
図1の例では、ソースデバイス12は、ビデオソース18、ビデオエンコーダ20、および出力インターフェース22を含む。宛先デバイス14は、入力インターフェース28、ビデオデコーダ30、およびディスプレイデバイス32を含む。本開示によれば、ソースデバイス12のビデオエンコーダ20および/または宛先デバイス14のビデオデコーダ30は、ビデオコーディングのための技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または構成を含み得る。たとえば、ソースデバイス12は、外部カメラなどの外部のビデオソースからビデオデータを受信し得る。同様に、宛先デバイス14は、統合型ディスプレイデバイスを含むのではなく、外部のディスプレイデバイスとインターフェースし得る。
図1の図示したコーディングシステム10は一例にすぎない。ビデオコーディングのための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって行われうる。本開示の技法は一般にビデオコーディングデバイスによって行われるが、技法はまた、通常、「コーデック」と呼ばれる、ビデオエンコーダ/デコーダによって行われうる。その上、本開示の技法はまた、ビデオプリプロセッサによって行われうる。ビデオエンコーダおよび/またはデコーダは、グラフィックス処理ユニット(GPU)または同様のデバイスでありうる。
ソースデバイス12および宛先デバイス14は、ソースデバイス12が、宛先デバイス14への送信のために、コーディングされたビデオデータを生成するようなコーディングデバイスの例にすぎない。いくつかの例では、ソースデバイス12および宛先デバイス14は、ソースデバイス12および宛先デバイス14の各々がビデオ符号化および復号構成要素を含むように、実質的に対称的に動作し得る。したがって、コーディングシステム10は、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオ電話のために、ビデオデバイス12、14の間での一方向または二方向のビデオ送信をサポートし得る。
ソースデバイス12のビデオソース18は、ビデオカメラなどのビデオキャプチャデバイス、前にキャプチャされたビデオを含むビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替形態として、ビデオソース18は、ソースビデオとしてのコンピュータグラフィックスベースのデータ、またはライブビデオと、アーカイブされたビデオと、コンピュータ生成されたビデオとの組合せを生成しうる。
場合によっては、ビデオソース18がビデオカメラであるとき、ソースデバイス12および宛先デバイス14は、いわゆるカメラフォンまたはビデオフォンを形成し得る。しかしながら、上述のように、本開示で説明する技法は、一般にビデオコーディングに適用可能であり得、ワイヤレスおよび/または有線の適用例に適用され得る。各場合において、キャプチャ、プリキャプチャ、またはコンピュータ生成されたビデオが、ビデオエンコーダ20によって符号化され得る。符号化されたビデオ情報は、次いで、出力インターフェース22によってコンピュータ可読媒体16上に出力され得る。
コンピュータ可読媒体16は、ワイヤレスブロードキャストもしくは有線ネットワーク送信などの一時的媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Blu-ray(登録商標)ディスク、もしくは他のコンピュータ可読媒体などの、記憶媒体(すなわち、非一時的記憶媒体)を含み得る。いくつかの例では、ネットワークサーバ(図示せず)が、たとえば、ネットワーク送信を介して、ソースデバイス12から符号化されたビデオデータを受信し、宛先デバイス14に符号化されたビデオデータを提供しうる。同様に、ディスクスタンピング設備などの媒体生産設備のコンピューティングデバイスが、ソースデバイス12から符号化されたビデオデータを受信し、符号化されたビデオデータを含むディスクを生産しうる。したがって、様々な例では、コンピュータ可読媒体16は、様々な形態の1つまたは複数のコンピュータ可読媒体を含むものと理解されうる。
宛先デバイス14の入力インターフェース28は、コンピュータ可読媒体16から情報を受信する。コンピュータ可読媒体16の情報は、ブロックおよび他のコーディングされたユニット、たとえば、group of pictures (GOP)の特性および/または処理を記述するシンタックス要素を含む、ビデオエンコーダ20によって規定されるシンタックス情報を含んでよく、シンタックス情報はまた、ビデオデコーダ30によって使用される。ディスプレイデバイス32は、復号されたビデオデータをユーザに表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスのうちのいずれかを含み得る。
ビデオエンコーダ20およびビデオデコーダ30は、現在開発中の高効率ビデオコーディング(HEVC)規格などのビデオコーディング規格に従って動作してよく、HEVCテストモデル(HM)に準拠し得る。あるいは、ビデオエンコーダ20およびビデオデコーダ30は、あるいは、ムービングピクチャエキスパートグループ(MPEG)-4パート10と呼ばれる、国際電気通信連合電気通信規格セクタ(ITU-T)H.264規格、アドバンストビデオコーディング(AVC)、H.265/HEVC、またはそのような規格の拡張などの、他のプロプライエタリ規格または業界規格に従って動作してよい。しかしながら、本開示の技法は、いかなる特定のコーディング規格にも限定されない。ビデオコーディング規格の他の例は、MPEG-2およびITU-T H.263を含む。図1に示さないが、いくつかの態様では、ビデオエンコーダ20およびビデオデコーダ30は各々、オーディオエンコーダおよびデコーダと統合されてよく、共通のデータストリームまたは別個のデータストリームの中のオーディオとビデオの両方の符号化を処理するための、適切なマルチプレクサ-デマルチプレクサ(MUX-DEMUX)ユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠し得る。
ビデオエンコーダ20およびビデオデコーダ30は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、様々な好適なエンコーダ回路構成のうちのいずれかとして実装されてよい。本技法が部分的にソフトウェアで実装されるとき、デバイスは、好適な非一時的コンピュータ可読媒体の中にソフトウェアのための命令を記憶してよく、本開示の技法を行うために、1つまたは複数のプロセッサを使用してハードウェアで命令を実行してよい。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダの中に含められてよく、それらのいずれも、組み合わせられたエンコーダ/デコーダ(コーデック)の一部としてそれぞれのデバイスの中で統合されてよい。ビデオエンコーダ20および/またはビデオデコーダ30を含むデバイスは、集積回路、マイクロプロセッサ、および/またはセルラー電話などのワイヤレス通信デバイスを含み得る。
図2は、ビデオコーディング技法を実施し得るビデオエンコーダ20の一例を示すブロック図である。ビデオエンコーダ20は、ビデオスライス内のビデオブロックのイントラコーディングおよびインターコーディングを行い得る。イントラコーディングは、所与のビデオフレーム内またはピクチャ内のビデオにおける空間的な冗長性を低減または除去するために、空間予測に依存する。インターコーディングは、ビデオシーケンスの隣接するフレーム内またはピクチャ内のビデオにおける時間的な冗長性を低減または除去するために、時間予測に依存する。イントラモード(Iモード)とは、いくつかの空間ベースのコーディングモードのうちのいずれかを指しうる。単方向(単予測とも呼ばれる)予測(Pモード)または双予測(双予測)とも呼ばれる)(Bモード)などのインターモードとは、いくつかの時間ベースのコーディングモードのうちのいずれかを指しうる。
図2に示すように、ビデオエンコーダ20は、符号化されるべきビデオフレーム内の現在ビデオブロックを受信する。図2の例では、ビデオエンコーダ20は、モード選択ユニット40、参照フレームメモリ64、加算器50、変換処理ユニット52、量子化ユニット54、およびエントロピーコーディングユニット56を含む。次に、モード選択ユニット40は、動き補償ユニット44、動き推定ユニット42、イントラ予測(intra-prediction)(イントラ予測(intra prediction)とも呼ばれる)ユニット46、および区分ユニット48を含む。ビデオブロック再構成のために、ビデオエンコーダ20はまた、逆量子化ユニット58、逆変換ユニット60、および加算器62を含む。ブロック境界をフィルタ処理して再構成ビデオからブロッキネスアーティファクトを除去するために、デブロッキングフィルタ(図2に示さず)も含まれてよい。所望される場合、デブロッキングフィルタは、通常、加算器62の出力をフィルタ処理することになる。デブロッキングフィルタに加えて、(ループ内またはループ後の)追加のフィルタも使用されてよい。そのようなフィルタは、簡潔のために図示されないが、所望される場合、(ループ内フィルタとして)加算器50の出力をフィルタ処理してよい。
符号化プロセス中、ビデオエンコーダ20は、コーディングされるべきビデオフレームまたはスライスを受信する。フレームまたはスライスは、複数のビデオブロックに分割され得る。動き推定ユニット42および動き補償ユニット44は、1つまたは複数の参照フレームの中の1つまたは複数のブロックに対する受信ビデオブロックのインター予測コーディングを行って、時間予測を提供する。イントラ予測ユニット46は、あるいは、コーディングされるべきブロックと同じフレームまたはスライスの中の1つまたは複数の近傍のブロックに対する受信ビデオブロックのイントラ予測コーディングを行って、空間予測を提供しうる。ビデオエンコーダ20は、たとえば、ビデオデータのブロックごとに適切なコーディングモードを選択するために、複数のコーディングパスを行いうる。
その上、区分ユニット48は、前のコーディングパスにおける、前の区分方式の評価に基づいて、ビデオデータのブロックをサブブロックに区分してよい。たとえば、区分ユニット48は、最初にフレームまたはスライスを最大コーディングユニット(LCU:largest coding unit)に区分してよく、レートひずみ分析(たとえば、レートひずみ最適化)に基づいてLCUの各々をサブコーディングユニット(サブCU)に区分してよい。モード選択ユニット40は、サブCUへのLCUの区分を示す4分木データ構造をさらに生じさせうる。4分木のリーフノードCUは、1つまたは複数の予測ユニット(PU:prediction unit)および1つまたは複数の変換ユニット(TU:transform unit)を含み得る。
本開示は、HEVCのコンテキストにおけるCU、PU、もしくはTU、または他の規格のコンテキストにおける同様のデータ構造(たとえば、H.264/AVCにおけるマクロブロックおよびそれらのサブブロック)のうちのいずれかを指すために、「ブロック」という用語を使用する。CUは、コーディングノード、PU、およびコーディングノードに関連するTUを含む。CUのサイズは、コーディングノードのサイズに対応し、形状が正方形である。CUのサイズは、8×8ピクセルから、最大値が64×64ピクセル以上のツリーブロックのサイズまでにわたりうる。各CUは、1つまたは複数のPUおよび1つまたは複数のTUを含み得る。CUに関連するシンタックスデータは、たとえば、1つまたは複数のPUへのCUの区分を記述し得る。CUが、スキップモードまたはダイレクトモードで符号化されるのか、イントラ予測モードで符号化されるのか、それともインター予測(inter-prediction)(インター予測(inter prediction)とも呼ばれる)モードで符号化されるのかの間で、区分モードは異なりうる。PUは、形状が非正方形となるように区分され得る。CUに関連するシンタックスデータはまた、たとえば、4分木による1つまたは複数のTUへのCUの区分を記述し得る。TUは、形状が正方形または非正方形(たとえば、長方形)であり得る。
モード選択ユニット40は、たとえば、誤差結果に基づいて、コーディングモード、すなわち、イントラモードまたはインターモードのうちの1つを選択してよく、残差ブロックデータを生成するために加算器50に、また参照フレームとして使用するための符号化ブロックを再構成するために加算器62に、得られたイントラコーディングまたはインターコーディングされたブロックを提供する。モード選択ユニット40はまた、動きベクトル、イントラモードインジケータ、区分情報などのシンタックス要素、および他のそのようなシンタックス情報を、エントロピーコーディングユニット56に提供する。
動き推定ユニット42および動き補償ユニット44は、高度に統合され得るが、概念的な目的のために別個に図示される。動き推定ユニット42によって実行される動き推定とは、ビデオブロックに対する動きを推定する、動きベクトルを生成するプロセスである。動きベクトルは、たとえば、現在フレーム(または、他のコーディングされたユニット)内でコーディング中の現在ブロックに対して、参照フレーム(または、他のコーディングされたユニット)内の予測ブロックと比べて、現在ビデオフレーム内または現在ピクチャ内でのビデオブロックのPUの変位を示してよい。予測ブロックとは、ピクセル差分の観点から、コーディングされるべきブロックによく合うものであるとわかるブロックであり、ピクセル差分は、絶対差分和(SAD:sum of absolute difference)、2乗差分和(SSD:sum of square difference)、または他の差分メトリックによって決定されてよい。いくつかの例では、ビデオエンコーダ20は、参照フレームメモリ64の中に記憶された参照ピクチャのサブ整数ピクセル位置に対する値を計算し得る。たとえば、ビデオエンコーダ20は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数ピクセル位置の値を補間してよい。したがって、動き推定ユニット42は、フルピクセル位置および分数ピクセル位置に対して動き探索を実行してよく、分数ピクセル精度を有する動きベクトルを出力してよい。
動き推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコーディングされたスライスの中のビデオブロックのPUのための動きベクトルを計算する。参照ピクチャは、参照フレームメモリ64の中に記憶された1つまたは複数の参照ピクチャをその各々が識別する、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択され得る。動き推定ユニット42は、計算された動きベクトルをエントロピー符号化ユニット56および動き補償ユニット44へ送る。
動き補償ユニット44によって行われる動き補償は、動き推定ユニット42によって決定された動きベクトルに基づいて予測ブロックをフェッチまたは生成することを伴いうる。やはり、動き推定ユニット42および動き補償ユニット44は、いくつかの例では機能的に統合されてよい。現在ビデオブロックのPUのための動きベクトルを受信すると、動き補償ユニット44は、参照ピクチャリストのうちの1つの中で、動きベクトルが指し示す予測ブロックの位置を特定し得る。加算器50は、コーディング中の現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算することによって残差ビデオブロックを形成して、以下で説明するようにピクセル差分値を形成する。一般に、動き推定ユニット42は、ルーマ成分に対して動き推定を実行し、動き補償ユニット44は、ルーマ成分に基づいて計算された動きベクトルを、クロマ成分とルーマ成分の両方のために使用する。モード選択ユニット40はまた、ビデオスライスのビデオブロックを復号する際にビデオデコーダ30によって使用するための、ビデオブロックおよびビデオスライスに関連するシンタックス要素を生成し得る。
イントラ予測ユニット46は、上記で説明したように、動き推定ユニット42および動き補償ユニット44によって行われるインター予測の代替として、現在ブロックをイントラ予測し得る。詳細には、イントラ予測ユニット46は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測ユニット46は、たとえば、別個の符号化パス中に、様々なイントラ予測モードを使用して現在ブロックを符号化してよく、イントラ予測ユニット46(または、いくつかの例ではモード選択ユニット40)は、使用すべき適切なイントラ予測モードを、テストされたモードから選択してよい。
たとえば、イントラ予測ユニット46は、テストされた様々なイントラ予測モードに対して、レートひずみ分析を用いてレートひずみ値を計算してよく、テストされたモードの中から、レートひずみ特性が最良のイントラ予測モードを選択しうる。レートひずみ分析は、概して、符号化されたブロックと、符号化されたブロックを生じさせるために符号化された、符号化されていない元のブロックとの間のひずみ(すなわち、誤差)の量、ならびに符号化されたブロックを生じさせるために使用されるビットレート(すなわち、ビットの数)を決定する。イントラ予測ユニット46は、様々な符号化ブロックに対して、ひずみおよびレートから比率を計算して、ブロックに対してどのイントラ予測モードが最良のレートひずみ値を示すかを決定し得る。
加えて、イントラ予測ユニット46は、深度モデリングモード(DMM:depth modeling mode)を使用して深度マップの深度ブロックをコーディングするように構成され得る。モード選択ユニット40は、利用可能なDMMモードが、たとえば、レートひずみ最適化(RDO:rate-distortion optimization)を使用して、イントラ予測モードおよび他のDMMモードよりも良好なコーディング結果を生じさせるかどうかを決定し得る。深度マップに対応するテクスチャ画像に対するデータが、参照フレームメモリ64の中に記憶され得る。動き推定ユニット42および動き補償ユニット44はまた、深度マップの深度ブロックをインター予測するように構成され得る。
ブロックのためのイントラ予測モード(たとえば、従来のイントラ予測モード、またはDMMモードのうちの1つ)を選択した後、イントラ予測ユニット46は、ブロックのための選択されたイントラ予測モードを示す情報をエントロピーコーディングユニット56に提供し得る。エントロピーコーディングユニット56は、選択されたイントラ予測モードを示す情報を符号化し得る。ビデオエンコーダ20は、複数のイントラ予測モードインデックステーブルおよび複数の修正済みのイントラ予測モードインデックステーブル(コードワードマッピングテーブルとも呼ばれる)、様々なブロックに対する符号化コンテキストの定義、ならびにコンテキストの各々に対して使用すべき最確のイントラ予測モード、イントラ予測モードインデックステーブル、および修正済みのイントラ予測モードインデックステーブルの表示を含み得る構成データを、送信されるビットストリームの中に含めてよい。
ビデオエンコーダ20は、コーディング中の元のビデオブロックから、モード選択ユニット40からの予測データを減算することによって、残差ビデオブロックを形成する。加算器50は、この減算演算を行う1つまたは複数の構成要素を表す。
変換処理ユニット52は、離散コサイン変換(DCT)または概念的に同様の変換などの変換を残差ブロックに適用して、残差変換係数値を含むビデオブロックを生じさせる。変換処理ユニット52は、DCTと概念的に同様の他の変換を行いうる。ウェーブレット変換、整数変換、サブバンド変換、または他のタイプの変換も使用され得る。
変換処理ユニット52は、残差ブロックに変換を適用して、残差変換係数のブロックを生じさせる。変換は、残差情報をピクセル値領域から周波数領域などの変換領域に変換し得る。変換処理ユニット52は、得られた変換係数を量子化ユニット54へ送ってよい。量子化ユニット54は、変換係数を量子化してビットレートをさらに低減する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット54は、次いで、量子化変換係数を含む行列の走査を実行し得る。あるいは、エントロピー符号化ユニット56が走査を実行してもよい。
量子化に続いて、エントロピーコーディングユニット56は、量子化変換係数をエントロピーコーディングする。たとえば、エントロピーコーディングユニット56は、コンテキスト適応型可変長コーディング(CAVLC)、コンテキスト適応型バイナリ算術コーディング(CABAC)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC)、確率区間区分エントロピー(PIPE)コーディング、または別のエントロピーコーディング技法を実行してよい。コンテキストベースのエントロピーコーディングの場合には、コンテキストは近傍のブロックに基づいてよい。エントロピーコーディングユニット56によるエントロピーコーディングに続いて、符号化ビットストリームが、別のデバイス(たとえば、ビデオデコーダ30)へ送信されてよく、または後で送信するかもしくは取り出すためにアーカイブされてよい。
逆量子化ユニット58および逆変換ユニット60は、それぞれ、逆量子化および逆変換を適用して、たとえば、後で参照ブロックとして使用するために、ピクセル領域における残差ブロックを再構成する。動き補償ユニット44は、参照フレームメモリ64のフレームのうちの1つの予測ブロックに残差ブロックを加算することによって、参照ブロックを計算し得る。動き補償ユニット44はまた、再構成された残差ブロックに1つまたは複数の補間フィルタを適用して、動き推定における使用のためのサブ整数ピクセル値を計算し得る。加算器62は、再構成された残差ブロックを動き補償ユニット44によって生じた動き補償された予測ブロックに加算し、参照フレームメモリ64の中に記憶するための再構成ビデオブロックを生じさせる。再構成ビデオブロックは、後続のビデオフレームの中のブロックをインターコーディングするための参照ブロックとして、動き推定ユニット42および動き補償ユニット44によって使用され得る。
図3は、ビデオコーディング技法を実施し得るビデオデコーダ30の一例を示すブロック図である。図3の例では、ビデオデコーダ30は、エントロピー復号ユニット70、動き補償ユニット72、イントラ予測ユニット74、逆量子化ユニット76、逆変換ユニット78、参照フレームメモリ82、および加算器80を含む。ビデオデコーダ30は、いくつかの例では、ビデオエンコーダ20(図2)に関して説明した符号化パスとは概して相反の、復号パスを実行し得る。動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルに基づいて予測データを生成し得るが、イントラ予測ユニット74は、エントロピー復号ユニット70から受信されたイントラ予測モードインジケータに基づいて予測データを生成し得る。
復号プロセス中、ビデオデコーダ30は、符号化されたビデオスライスのビデオブロックおよび関連するシンタックス要素を表す符号化されたビデオビットストリームを、ビデオエンコーダ20から受信する。ビデオデコーダ30のエントロピー復号ユニット70は、ビットストリームをエントロピー復号して、量子化係数、動きベクトルまたはイントラ予測モードインジケータ、および他のシンタックス要素を生成する。エントロピー復号ユニット70は、動きベクトルおよび他のシンタックス要素を動き補償ユニット72に転送する。ビデオデコーダ30は、ビデオスライスレベルおよび/またはビデオブロックレベルでシンタックス要素を受信し得る。
ビデオスライスがイントラコーディングされた(I)スライスとしてコーディングされるとき、イントラ予測ユニット74は、シグナリングされたイントラ予測モード、および現在フレームまたは現在ピクチャの、前に復号されたブロックからのデータに基づいて、現在ビデオスライスのビデオブロックのための予測データを生成し得る。ビデオフレームがインターコーディングされた(たとえば、B、P、またはGPB)スライスとしてコーディングされるとき、動き補償ユニット72は、エントロピー復号ユニット70から受信された動きベクトルおよび他のシンタックス要素に基づいて、現在ビデオスライスのビデオブロックのための予測ブロックを生成する。予測ブロックは、参照ピクチャリストのうちの1つの中の参照ピクチャのうちの1つから生成され得る。ビデオデコーダ30は、参照フレームメモリ82の中に記憶された参照ピクチャに基づいてデフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト0およびリスト1を構成し得る。
動き補償ユニット72は、動きベクトルおよび他のシンタックス要素を構文解析することによって、現在ビデオスライスのビデオブロックのための予測情報を決定し、予測情報を使用して、復号中の現在ビデオブロックのための予測ブロックを生成する。たとえば、動き補償ユニット72は、受信されたシンタックス要素のうちのいくつかを使用して、ビデオスライスのビデオブロックをコーディングするために使用された予測モード(たとえば、イントラ予測またはインター予測)、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)、スライス用の参照ピクチャリストのうちの1つまたは複数に対する構成情報、スライスのインター符号化されたビデオブロックごとの動きベクトル、スライスのインターコーディングされたビデオブロックごとのインター予測ステータス、および現在ビデオスライスの中のビデオブロックを復号するための他の情報を決定する。
動き補償ユニット72はまた、補間フィルタに基づいて補間を行い得る。動き補償ユニット72は、ビデオブロックの符号化中にビデオエンコーダ20によって使用された補間フィルタを使用して、参照ブロックのサブ整数ピクセルに対する補間値を計算し得る。この場合、動き補償ユニット72は、ビデオエンコーダ20によって使用された補間フィルタを、受信されたシンタックス要素から決定し得、その補間フィルタを使用して予測ブロックを生成し得る。
深度マップに対応するテクスチャ画像に対するデータは、参照フレームメモリ82の中に記憶され得る。動き補償ユニット72はまた、深度マップの深度ブロックをインター予測するように構成され得る。
上記のことを念頭に置いて、ビデオ圧縮技法は、空間(イントラピクチャ)予測および/または時間(インターピクチャ)予測を実行して、ビデオシーケンスに固有の冗長性を低減または除去する。ブロックベースのビデオコーディングの場合、ビデオスライス(すなわち、ビデオピクチャ、またはビデオピクチャの一部分)は、ツリーブロック、コーディングツリーブロック(CTB:coding tree block)、コーディングツリーユニット(CTU:coding tree unit)、コーディングユニット(CU:coding unit)、および/またはコーディングノードと呼ばれることもある、ビデオブロックに区分され得る。ピクチャのイントラコーディングされた(I)スライスの中のビデオブロックは、同じピクチャの中の近傍のブロックの中の参照サンプルに対する空間予測を使用して符号化される。ピクチャのインターコーディングされた(PまたはB)スライスの中のビデオブロックは、同じピクチャの中の近傍のブロックの中の参照サンプルに対する空間予測、または他の参照ピクチャの中の参照サンプルに対する時間予測を使用し得る。ピクチャはフレームと呼ばれることがあり、参照ピクチャは参照フレームと呼ばれることがある。
空間予測または時間予測は、コーディングされるべきブロックのための予測ブロックをもたらす。残差データは、コーディングされるべき元のブロックと予測ブロックとの間のピクセル差分を表す。インターコーディングされたブロックは、予測ブロックを形成する参照サンプルのブロックを指し示す動きベクトル、およびコーディングされたブロックと予測ブロックとの間の差分を示す残差データに従って符号化される。イントラコーディングされたブロックは、イントラコーディングモードおよび残差データに従って符号化される。さらなる圧縮のために、残差データは、ピクセル領域から変換領域に変換されてよく、結果として残差変換係数になり、残差変換係数は、次いで、量子化され得る。当初は2次元アレイをなして配置された量子化変換係数は、変換係数の1次元ベクトルを生成するために走査されてよく、なお一層の圧縮を達成するためにエントロピーコーディングが適用されてよい。
画像およびビデオ圧縮は急成長を経ており、様々なコーディング規格に至る。そのようなビデオコーディング規格は、ITU-T H.261、ISO/IEC MPEG-1パート2、ITU-T H.262またはISO/IEC MPEG-2パート2、ITU-T H.263、ISO/IEC MPEG-4パート2、ITU-T H.264またはISO/IEC MPEG-4パート10とも呼ばれるアドバンストビデオコーディング(AVC)、およびITU-T H.265またはMPEG-Hパート2とも呼ばれる高効率ビデオコーディング(HEVC)を含む。AVCは、スケーラブルビデオコーディング(SVC)、マルチビュービデオコーディング(MVC)およびマルチビュービデオコーディングプラス深度(MVC+D)、ならびに3D AVC(3D-AVC)などの拡張を含む。HEVCは、スケーラブルHEVC(SHVC)、マルチビューHEVC(MV-HEVC)、および3D HEVC(3D-HEVC)などの拡張を含む。
ITU-TとISO/IECとの共同ビデオエキスパートチーム(JVET)によって開発中の多用途ビデオコーディング(VVC)と称される新たなビデオコーディング規格もある。VVC規格はいくつかのワーキングドラフトを有するが、特にVVCの1つのワーキングドラフト(WD)、すなわち、B.Bross、J.Chen、およびS.Liu、「Versatile Video Coding (Draft 4)」、JVET-M1001-v5、第13回JVET会合、2019年1月(VVCドラフト4)が、本明細書で参照される。
本明細書で開示する技法の説明は、開発中のビデオコーディング規格、すなわち、ITU-TとISO/IECとの共同ビデオエキスパートチーム(JVET)による多用途ビデオコーディング(VVC)に基づく。しかしながら、本技法は、他のビデオコーデック仕様にも適用される。
図4は、復号順序408および提示順序410における、リーディングピクチャ404に対するIRAPピクチャ402と、トレーリングピクチャ406との間の関係の描写400である。一実施形態では、IRAPピクチャ402は、クリーンランダムアクセス(CRA:clean random access)ピクチャ、またはランダムアクセス復号可能リーディング(RADL:random access decodable leading)ピクチャを伴う瞬時デコーダリフレッシュ(IDR:instantaneous decoder refresh)ピクチャと呼ばれる。HEVCでは、IDRピクチャ、CRAピクチャ、およびブロークンリンクアクセス(BLA:Broken Link Access)ピクチャは、すべてIRAPピクチャ402と考えられる。VVCの場合、2018年10月における第12回JVET会合の間に、IRAPピクチャとしてIDRピクチャとCRAピクチャの両方を有することが合意された。
図4に示すように、リーディングピクチャ404(たとえば、ピクチャ2および3)は、復号順序408でIRAPピクチャ402に後続するが、提示順序410でIRAPピクチャ402に先行する。トレーリングピクチャ406は、復号順序408と提示順序410の両方でIRAPピクチャ402に後続する。2つのリーディングピクチャ404および1つのトレーリングピクチャ406が図4に示されるが、実際の適用例では、より多数またはより少数のリーディングピクチャ404および/またはトレーリングピクチャ406が復号順序408および提示順序410で存在し得ることを、当業者は理解するであろう。
図4の中のリーディングピクチャ404は、2つのタイプ、すなわち、ランダムアクセススキップドリーディング(RASL:random access skipped leading)およびRADLに分けられている。復号がIRAPピクチャ402(たとえば、ピクチャ1)から始まるとき、RADLピクチャ(たとえば、ピクチャ3)は正しく復号され得るが、RASLピクチャ(たとえば、ピクチャ2)は正しく復号され得ない。したがって、RASLピクチャは廃棄される。RADLピクチャとRASLピクチャとの間の相違に照らして、IRAPピクチャに関連付けられるリーディングピクチャのタイプは、効率的かつ適切なコーディングのためにRADLまたはRASLのいずれかとして識別されるべきである。HEVCでは、RASLピクチャおよびRADLピクチャが存在するとき、同じIRAPピクチャに関連付けられるRASLピクチャおよびRADLピクチャについて、提示順序410でRASLピクチャがRADLピクチャに先行しなければならないことが制約される。
IRAPピクチャ402は、以下の2つの重要な機能/利点をもたらす。第一に、IRAPピクチャ402の存在は、復号プロセスがそのピクチャから開始できることを示す。この機能は、IRAPピクチャ402がその位置に存在する限り、必ずしもビットストリームの冒頭とは限らず、ビットストリームの中のその位置において復号プロセスが開始するランダムアクセス特徴を可能とする。第二に、IRAPピクチャ402の存在は、RASLピクチャを除き、IRAPピクチャ402において開始しコーディングされたピクチャが、前のピクチャへのいかなる参照も伴わずにコーディングされるように、復号プロセスをリフレッシュする。したがって、ビットストリームの中に存在するIRAPピクチャ402を有することは、IRAPピクチャ402の前にコーディングされたピクチャの復号中に起こり得るいかなるエラーも、IRAPピクチャ402および復号順序408においてIRAPピクチャ402に後続するピクチャに伝搬することを止めることになる。
IRAPピクチャ402は、重要な機能を提供する一方で、圧縮効率への不利益を伴う。IRAPピクチャ402の存在は、ビットレートの急上昇を引き起こす。圧縮効率へのこの不利益は、2つの理由に起因する。第一に、IRAPピクチャ402はイントラ予測されるピクチャであるので、インター予測されるピクチャである他のピクチャ(たとえば、リーディングピクチャ404、トレーリングピクチャ406)と比較すると、ピクチャ自体が、描写するために比較的多くのビットを必要とすることになる。第二に、IRAPピクチャ402の存在が時間予測を破るので(なぜなら、デコーダが復号プロセスをリフレッシュすることになり、このことについての復号プロセスのアクションのうちの1つが、復号ピクチャバッファ(DPB)の中の、前の参照ピクチャを除去することであるからである)、IRAPピクチャ402は、復号順序408でIRAPピクチャ402に後続するピクチャのコーディングを効率のよくないものとし(すなわち、描写するためにより多くのビットを必要とするものとし)、なぜならば、それらはそれらのインター予測コーディングのためにより少ない参照ピクチャしか有しないためである。
IRAPピクチャ402であると考えられるピクチャタイプのうち、HEVCにおけるIDRピクチャは、他のピクチャタイプと比較したとき、異なるシグナリングおよび導出を有する。相違点のうちのいくつかは次の通りである。
IDRピクチャのピクチャ順序カウント(POC:picture order count)値のシグナリングおよび導出のために、POCの最上位ビット(MSB)部分は前のキーピクチャ(key picture)から導出されるのではなく、単に0に等しくなるように設定される。
参照ピクチャ管理のために必要とされる情報をシグナリングするために、IDRピクチャのスライスヘッダは、参照ピクチャ管理を支援するためにシグナリングされることを必要とされる情報を含まない。他のピクチャタイプ(すなわち、CRA、トレーリング、時間サブレイヤアクセス(TSA:temporal sub-layer access)など)の場合、参照ピクチャマーキングプロセス(すなわち、復号ピクチャバッファ(DPB)の中の参照ピクチャのステータス、すなわち、参照のために使用済みおよび参照のために未使用のいずれかを、決定するためのプロセス)のために、以下で説明する参照ピクチャセット(RPS:reference picture set)などの情報、または他の形式の同様の情報(たとえば、参照ピクチャリスト)が必要とされる。しかしながら、IDRピクチャの場合、そのような情報はシグナリングされる必要がなく、なぜならば、IDRの存在が、復号プロセスはDPBの中のすべての参照ピクチャを参照のために未使用であるとして単にマークする、ということを示すからである。
HEVCおよびVVCでは、IRAPピクチャ402およびリーディングピクチャ404は各々、単一のネットワーク抽象化レイヤ(NAL)ユニット内に含まれうる。一組のNALユニットは、アクセスユニットと呼ばれうる。IRAPピクチャ402およびリーディングピクチャ404は、システムレベルアプリケーションによって容易に識別され得るように、異なるNALユニットタイプが与えられる。たとえば、ビデオスプライサは、詳細には、IRAPピクチャ402を非IRAPピクチャから識別するために、またRASLピクチャおよびRADLピクチャを決定することを含め、リーディングピクチャ404をトレーリングピクチャ406から識別するために、コーディングされたビットストリームの中のシンタックス要素のあまりにも多くの詳細を理解する必要なく、コーディングされたピクチャタイプを理解する必要がある。トレーリングピクチャ406は、IRAPピクチャ402に関連付けられ、提示順序410でIRAPピクチャ402に後続するピクチャである。ピクチャは、復号順序408で特定のIRAPピクチャ402に後続してもよく、復号順序408で任意の他のIRAPピクチャ402に先行してもよい。このために、IRAPピクチャ402およびリーディングピクチャ404にそれら自体のNALユニットタイプを与えることは、そのようなアプリケーションの役に立つ。
HEVCの場合、IRAPピクチャのためのNALユニットタイプは以下を含む。
リーディングピクチャを伴うBLA(BLA_W_LP): 復号順序で1つまたは複数のリーディングピクチャが後続し得るブロークンリンクアクセス(BLA)ピクチャのNALユニット。
RADLを伴うBLA(BLA_W_RADL): 復号順序で1つまたは複数のRADLピクチャが後続し得るがRASLピクチャが後続し得ないBLAピクチャのNALユニット。
リーディングピクチャを伴わないBLA(BLA_N_LP): 復号順序でリーディングピクチャが後続しないBLAピクチャのNALユニット。
RADLを伴うIDR(IDR_W_RADL): 復号順序で1つまたは複数のRADLピクチャが後続し得るがRASLピクチャが後続し得ないIDRピクチャのNALユニット。
リーディングピクチャを伴わないIDR(IDR_N_LP): 復号順序でリーディングピクチャが後続しないIDRピクチャのNALユニット。
CRA: リーディングピクチャが後続し得るクリーンランダムアクセス(CRA)ピクチャのNALユニット(すなわち、RASLピクチャもしくはRADLピクチャのいずれか、またはその両方)。
RADL: RADLピクチャのNALユニット。
RASL: RASLピクチャのNALユニット。
VVCの場合、IRAPピクチャ402およびリーディングピクチャ404のためのNALユニットタイプは次の通りである。
RADLを伴うIDR(IDR_W_RADL): 復号順序で1つまたは複数のRADLピクチャが後続し得るがRASLピクチャが後続し得ないIDRピクチャのNALユニット。
リーディングピクチャを伴わないIDR(IDR_N_LP): 復号順序でリーディングピクチャが後続しないIDRピクチャのNALユニット。
CRA: リーディングピクチャが後続し得るクリーンランダムアクセス(CRA)ピクチャのNALユニット(すなわち、RASLピクチャもしくはRADLピクチャのいずれか、またはその両方)。
RADL: RADLピクチャのNALユニット。
RASL: RASLピクチャのNALユニット。
順次イントラリフレッシュ/漸次復号リフレッシュが以下で説明される。
低遅延適用例の場合、ピクチャをIRAPピクチャ(たとえば、IRAPピクチャ402)としてコーディングすることは、そのビットレート要件が非IRAPピクチャ(すなわち、Pピクチャ/Bピクチャ)と比較して相対的に大きく、したがって、より大きいレイテンシ/遅延を引き起こすため、回避することが望ましい。しかしながら、IRAPの使用を完全に回避することは、すべての低遅延適用例において可能であるとは限らない場合がある。たとえば、マルチパーティ遠隔会議などの会話型の適用例の場合、新たなユーザが遠隔会議に参加できる定期的なポイントを提供することが必要である。
新たなユーザがマルチパーティ遠隔会議適用例に参加することを可能にする、ビットストリームへのアクセスを提供するために、1つの可能な方策は、ビットレートにおけるピークを有することを回避するために、IRAPピクチャを使用するのではなく順次イントラリフレッシュ技法(PIR:progressive intra refresh)を使用することである。PIRは、漸次復号リフレッシュ(GDR)と呼ばれることもある。PIRおよびGDRという用語は、本開示において互いに入れ替え可能に使用され得る。
図5は、漸次復号リフレッシュ(GDR)技法500を示す。図示のように、GDR技法500は、ビットストリームのコーディングされたビデオシーケンス(CVS)508内のGDRピクチャ502、1つまたは複数のトレーリングピクチャ504、およびリカバリポイントピクチャ506を用いて示される。一実施形態では、GDRピクチャ502、トレーリングピクチャ504、およびリカバリポイントピクチャ506は、CVS508の中のGDR期間を規定し得る。CVS508は、GDRピクチャ502で開始する一連のピクチャ(または、それらの部分)であり、次のGDRピクチャまでの(ただし、それを含まない)、またはビットストリームの終端までの、すべてのピクチャ(または、それらの部分)を含む。GDR期間は、GDRピクチャ502で開始する一連のピクチャであり、リカバリポイントピクチャ506までの(それを含む)すべてのピクチャを含む。
図5に示すように、GDR技法500または原理は、GDRピクチャ502で開始しリカバリポイントピクチャ506で終了する一連のピクチャにわたって機能する。GDRピクチャ502は、すべてがイントラ予測を使用してコーディングされているブロック(すなわち、イントラ予測ブロック)を含むリフレッシュ済みの/クリーンな領域510、およびすべてがインター予測を使用してコーディングされているブロック(すなわち、インター予測ブロック)を含むリフレッシュされていない/ダーティな領域512を含む。
GDRピクチャ502に直接隣接するトレーリングピクチャ504は、イントラ予測を使用してコーディングされる第1の部分510Aおよびインター予測を使用してコーディングされる第2の部分510Bを有する、リフレッシュ済みの/クリーンな領域510を含む。第2の部分510Bは、たとえば、CVS508のGDR期間内の先行するピクチャの、リフレッシュ済みの/クリーンな領域510を参照することによってコーディングされる。図示のように、トレーリングピクチャ504のリフレッシュ済みの/クリーンな領域510は、一貫した方向で(たとえば、左から右に)コーディングプロセスが移動または進行するにつれて拡大し、それに対応して、リフレッシュされていない/ダーティな領域512を縮小する。最終的に、リフレッシュ済みの/クリーンな領域510しか含まないリカバリポイントピクチャ506が、コーディングプロセスから取得される。特に、さらに以下で説明するように、インター予測ブロックとしてコーディングされる、リフレッシュ済みの/クリーンな領域510の第2の部分510Bは、参照ピクチャの中のリフレッシュ済みの領域/クリーンな領域510を参照するだけでよい。
HEVCでは、図5のGDR技法500が、リカバリポイント補足エンハンスメント情報(SEI:Supplemental Enhancement Information)メッセージおよび領域リフレッシュ情報SEIメッセージを使用して非規範的にサポートされた。これらの2つのSEIメッセージは、GDRがどのように実行されるのかを規定しない。むしろ、その2つのSEIメッセージは、(すなわち、リカバリポイントSEIメッセージによって提供される)GDR期間の中の最初のピクチャおよび最後のピクチャならびに(すなわち、領域リフレッシュ情報SEIメッセージによって提供される)リフレッシュされている領域を示すためのメカニズムを単に提供する。
実際には、GDR技法500は、2つの技法を一緒に使用することによって行われる。それらの2つの技法とは、制約イントラ予測(CIP:constraint intra prediction)、および動きベクトルに対するエンコーダ制約である。CIPは、リフレッシュされていない領域(たとえば、リフレッシュされていない/ダーティな領域512)からのサンプルを使用しない領域が、参照のために使用されることを可能にするので、CIPは、特にイントラ予測ブロック(たとえば、リフレッシュ済みの/クリーンな領域510の第1の部分510A)としてのみコーディングされる領域をコーディングするための、GDR目的のために使用され得る。しかしながら、イントラブロックへの制約が、リフレッシュ済みの領域の中のイントラブロックに対してだけでなくピクチャの中のすべてのイントラブロックにも適用されなければならないので、CIPの使用は深刻なコーディング性能劣化を引き起こす。動きベクトルに対するエンコーダ制約は、リフレッシュ済みの領域の外側に位置する参照ピクチャの中の任意のサンプルをエンコーダが使用することを制限する。そのような制約は、最適でない動き探索を引き起こす。
図6は、GDRをサポートするためにエンコーダ制約を使用するときの、望ましくない動き探索600を示す概略図である。図示のように、動き探索600は、現在ピクチャ602および参照ピクチャ603を示す。現在ピクチャ602および参照ピクチャ603は各々、イントラ予測を用いてコーディングされたリフレッシュ済みの領域606、インター予測を用いてコーディングされたリフレッシュ済みの領域608、およびリフレッシュされていない領域608を含む。リフレッシュ済みの領域604、リフレッシュ済みの領域606、およびリフレッシュされていない領域608は、図5の中のリフレッシュ済みの/クリーンな領域510の第1の部分510A、リフレッシュ済みの/クリーンな領域510の第2の部分510B、およびリフレッシュされていない/ダーティな領域512と同様である。
動き探索プロセス中、エンコーダは、リフレッシュ済みの領域606の外側に位置している参照ブロック612のサンプルのうちのいくつかをもたらす、いかなる動きベクトル610を選択することも制約または防止される。このことは、現在ピクチャ602の中の現在ブロック614を予測するときに参照ブロック612が最良のレートひずみコスト基準を与えるときにさえ行われる。したがって、図6は、GDRをサポートするためのエンコーダ制約を使用するときの、動き探索600における非最適性に対する理由を示す。
JVET寄稿JVET-K0212およびJVET-L0160は、CIPおよびエンコーダ制約手法の使用に基づくGDRの実装形態を記載している。実装形態は、次のように要約され得る。すなわち、列ごとにコーディングユニットに対してイントラ予測モードが強制され、イントラCUの再構成を確実なものにするために、制約付きイントラ予測が有効化され、動きベクトルは、フィルタが原因で広がる誤差(たとえば、6ピクセル)を回避するための追加のマージンを考慮に入れるとともに、イントラ列を再ループさせるときに過去の参照ピクチャを除去しながら、リフレッシュ済みのエリア内を指し示すように制約される。
JVET寄稿JVET-M0529は、ピクチャがGDR期間の中で最初のピクチャおよび最後のピクチャであることを規範的に示すための方法を提案した。提案された着想は次のように機能する。
NALユニットタイプリカバリポイント表示を有する新たなNALユニットを、非ビデオコーディングレイヤ(VCL)NALユニットとして規定する。NALユニットのペイロードは、GDR期間の中の最後のピクチャのPOC値を導出するために使用され得る情報を指定するためのシンタックス要素を含む。タイプリカバリポイント表示を有する非VCL NALユニットを含むアクセスユニットは、リカバリポイント開始(RBP:recovery point begin)アクセスユニット(AU:access unit)と呼ばれ、RBPアクセスユニットの中のピクチャは、RBPピクチャと呼ばれる。復号プロセスは、RBP AUから開始することができる。復号がRBP AUから開始するとき、最後のピクチャを除いてGDR期間の中のすべてのピクチャは出力されない。
既存のGDR設計に関する問題のうちのいくつかについて説明する。
GDRをサポートするための既存の設計/手法は、少なくとも以下の問題を有する。
JVET-M0529におけるGDRを規範的に規定するための方法は、以下の問題を有する。提案された方法は、GDRがどのように行われるのかを説明していない。代わりに、提案された方法は、GDR期間の中の最初のピクチャおよび最後のピクチャを示すためのいくつかのシグナリングを提供するにすぎない。GDR期間の中の最初のピクチャおよび最後のピクチャを示すために、新たな非VCL NALユニットが必要とされる。リカバリポイント表示(RPI:recovery point indication)NALユニットの中に含まれる情報は、GDR期間の中の最初のピクチャのタイルグループヘッダの中に単に含められ得るので、このことは冗長性である。また、提案された方法は、GDR期間の中のピクチャの中のどの領域がリフレッシュ済みの領域およびリフレッシュされていない領域であるのかを表すことができない。
JVET-K0212およびJVET-L0160に記載されるGDR手法は、以下の問題を有する。第一に、CIPの使用。リフレッシュされていない領域からの任意のサンプルが空間的な参照のために使用されることを防止するために、リフレッシュ済みの領域を、いくつかの制約を伴うイントラ予測を用いてコーディングすることが必要である。CIPが使用されるとき、コーディングはピクチャベースであり、そのことは、ピクチャの中のすべてのイントラブロックもCIPイントラブロックとしてコーディングされなければならないことを意味する。したがって、このことは性能劣化を引き起こす。さらに、動きベクトルに関連する参照ブロックのサンプルが、完全に参照ピクチャの中のリフレッシュ済みの領域内にあるとは限らないとき、動き探索を限定するためのエンコーダ制約の使用は、エンコーダが最良の動きベクトルを選ぶことを妨げる。また、イントラ予測のみを用いてコーディングされるリフレッシュ済みの領域はCTUサイズでない。代わりに、リフレッシュ済みの領域は、CTUサイズよりも小さく、最小CUサイズまで小さくなることができる。このことは、ブロックレベルでの表示を必要とし得るので、実装を不必要に複雑にさせる。
本明細書では、ビデオコーディングにおける漸次復号リフレッシュ(GDR)をサポートするための技法が開示される。開示する技法は、イントラランダムアクセスポイント(IRAP)ピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とする。GDRピクチャが存在するか否かを示すために、漸次復号リフレッシュ(GDR)フラグの値が使用される。GDRピクチャが存在することをGDRフラグが示すとき、コーディングされたビデオシーケンス(CVS)の復号がGDRピクチャにおいて開始される。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、ビデオコーディングにおけるコーダ/デコーダ(「コーデック」とも呼ばれる)が、現在のコーデックに比べて改善される。実際には、改善されたビデオコーディングプロセスは、ビデオが送られ、受け取られ、かつ/または見られるとき、より良好なユーザエクスペリエンスをユーザに与える。
上記で説明した問題のうちの1つまたは複数を解決するために、本開示は以下の態様を開示する。態様の各々は個別に適用され得、それらのうちのいくつかは組合せで適用され得る。
1) タイプGDR_NUTを有するVCL NALユニットが規定される。
a. NALユニットタイプGDR_NUTを有するピクチャは、GDRピクチャ、すなわち、GDR期間の中の最初のピクチャと呼ばれる。
b. GDRピクチャは、temporalIDが0に等しい。
c. GDRピクチャを含むアクセスユニットは、GDRアクセスユニットと呼ばれる。上述のように、アクセスユニットは一組のNALユニットである。各NALユニットは、単一のピクチャを含み得る。
2) コーディングされたビデオシーケンス(CVS)は、GDRアクセスユニットで開始しうる。
3) 次のことのうちの1つが真であるとき、GDRアクセスユニットはCVSの中の最初のアクセスユニットである。
a. GDRアクセスユニットがビットストリームの中の最初のアクセスユニットである。
b. GDRアクセスユニットがエンドオブシーケンス(EOS)アクセスユニットの直後に続く。
c. GDRアクセスユニットがエンドオブビットストリーム(EOB:end-of-bitstream)アクセスユニットの直後に続く。
d. デコーダフラグ、いわゆる、NoIncorrectPicOutputFlagがGDRピクチャに関連付けられ、デコーダの外側のエンティティによってフラグの値が1(すなわち、真)に等しく設定される。
4) GDRピクチャがCVSの中の最初のアクセスユニットであるとき、以下のことが適用される。
a. DPBの中のすべての参照ピクチャが「参照のために未使用」としてマークされる。
b. ピクチャのPOC MSBが0に等しくなるように設定される。
c. GDRピクチャ、およびGDR期間の中の最後のピクチャを除きGDR期間の中の最後のピクチャまで出力順序でGDRピクチャに後続するすべてのピクチャは、出力されない(すなわち、「出力のために不必要」としてマークされる)。
5) GDRが有効化されているかどうかを指定するためのフラグが、シーケンスレベルパラメータセットの中で(たとえば、SPSの中で)シグナリングされる。
a. フラグはgdr_enabled_flagと指定されうる。
b. フラグが1に等しいとき、GDRピクチャがCVSの中に存在し得る。そうではなく、フラグが0に等しいとき、GDRピクチャがCVSの中に存在しないようにGDRは有効化されていない。
6) GDR期間の中の最後のピクチャのPOC値を導出するために使用され得る情報が、GDRピクチャのタイルグループヘッダの中でシグナリングされる。
a. GDR期間の中の最後のピクチャとGDRピクチャとの間の差分(delta)POCとして、情報がシグナリングされる。情報は、recovery_point_cntと指定されるシンタックス要素を使用してシグナリングされ得る。
b. タイルグループヘッダの中のシンタックス要素recovery_point_cntの存在は、gdr_enabledフラグの値、およびピクチャのNALユニットタイプが条件とされてよく、すなわち、gdr_enabled_flagが1に等しく、かつタイルグループを含むNALユニットのnal_unit_typeがGDR_NUTであるときのみ、フラグが存在する。
7) タイルグループがリフレッシュ済みの領域の一部であるか否かを指定するためのフラグが、タイルグループヘッダの中でシグナリングされる。
a. フラグは、refreshed_region_flagと指定されうる。
b. そのフラグの存在は、gdr_enabled_flagの値、およびタイルグループを含むピクチャがGDR期間内にあるかどうかが、条件とされてよい。したがって、次のことのすべてが真であるときのみ、フラグが存在する。
i. gdr_enabled_flagの値が1に等しい。
ii. 現在ピクチャのPOCが、最後のGDRピクチャのPOC値以上であり(現在ピクチャがGDRピクチャであるとき、最後のGDRピクチャが現在ピクチャである)、GDR期間の中の最後のピクチャのPOCよりも小さい。
c. フラグがタイルグループヘッダの中に存在しないとき、フラグの値は1に等しいものと推測される。
8) refreshed_region_flagが1に等しいすべてのタイルグループは、連結している領域をカバーする。同様に、refreshed_region_flagが0に等しいすべてのタイルグループも、連結している領域をカバーする。
9) refreshed_region_flagを有するタイルグループは、タイプI(すなわち、イントラタイルグループ)またはBもしくはP(すなわち、インタータイルグループ)のものであり得る。
10) GDRピクチャから開始しGDR期間の中の最後のピクチャまでの各ピクチャは、refreshed_region_flagが1に等しい少なくとも1つのタイルグループを含む。
11) GDRピクチャは、refreshed_region_flagが1に等しく、かつtile_group_typeがI(すなわち、イントラタイルグループ)に等しい、少なくとも1つのタイルグループを含む。
12) gdr_enabled_flagが1に等しいとき、長方形タイルグループの情報、すなわち、タイルグループの数およびそれらのアドレスが、ピクチャパラメータセット(PPS:picture parameter set)またはタイルグループヘッダのいずれかの中でシグナリングされることが可能とされる。これを行うために、長方形タイルグループ情報がPPSの中に存在するか否かを指定するために、PPSの中でフラグがシグナリングされる。このフラグは、rect_tile_group_info_in_pps_flagと呼ばれることがある。このフラグは、gdr_enabled_flagが1に等しいとき、1に等しくなるように制約されうる。
a. 一代替形態では、長方形タイルグループ情報がPPSの中に存在するか否かをシグナリングするのではなく、タイルグループ情報(すなわち、長方形タイルグループ、ラスタ走査タイルグループなどの、任意のタイプのタイルグループ)がPPSの中に存在するかどうかを指定するために、より全般的なフラグがPPSの中でシグナリングされ得る。
13) タイルグループ情報がPPSの中に存在しないとき、明示的なタイルグループ識別子(ID)情報のシグナリングが存在しないことが、さらに制約されうる。明示的なタイルグループID情報は、signaled_tile_group_id_flag、signaled_tile_group_id_length_minus1、およびtile_group_id[ i ]を含む。
14) ピクチャの中のリフレッシュ済みの領域とリフレッシュされていない領域との間の境界を横断するループフィルタ処理演算が可能とされるかどうかを指定するために、フラグがシグナリングされる。
a. このフラグはPPSの中でシグナリングされ、loop_filter_across_refreshed_region_enabled_flagと呼ばれることがある。
b. loop_filter_across_refreshed_region_enabled_flagの存在は、loop_filter_across_tile_enabled_flagの値が条件とされうる。loop_filter_across_tile_enabled_flagが0に等しいとき、loop_filter_across_refreshed_region_enabled_flagは存在しなくてよく、その値は0に等しいものと推測される。
c. 一代替形態では、タイルグループヘッダの中でそのフラグがシグナリングされてよく、その存在は、refreshed_region_flagの値が条件とされえ、すなわち、refreshed_region_flagの値が1に等しいときのみ、そのフラグが存在する。
15) タイルグループがリフレッシュ済みの領域であることが示され、リフレッシュ済みの領域を横断するループフィルタが可能とされないことが示されるとき、以下のことが適用される。
a. エッジを共有する近傍タイルグループが、リフレッシュされていないタイルグループであるとき、タイルグループの境界におけるエッジのデブロッキングが行われない。
b. タイルグループの境界におけるブロックに対するサンプル適応オフセット(SAO:sample adaptive offset)プロセスは、リフレッシュ済み領域境界の外側からのいかなるサンプルも使用しない。
c. タイルグループの境界におけるブロックに対する適応ループフィルタ処理(ALF:adaptive loop filtering)プロセスは、リフレッシュ済み領域境界の外側からのいかなるサンプルも使用しない。
16) gdr_enabled_flagが1に等しいとき、各ピクチャは、ピクチャの中のリフレッシュ済みの領域の境界を決定するための変数に関連付けられる。これらの変数は、次のように呼ばれることがある。
a. ピクチャの中のリフレッシュ済みの領域の左の境界位置について、PicRefreshedLeftBoundaryPos。
b. ピクチャの中のリフレッシュ済みの領域の右の境界位置について、PicRefreshedRightBoundaryPos。
c. ピクチャの中のリフレッシュ済みの領域の上の境界位置について、PicRefreshedTopBoundaryPos。
d. ピクチャの中のリフレッシュ済みの領域の下の境界位置について、PicRefreshedBotBoundaryPos。
17) ピクチャの中のリフレッシュ済みの領域の境界が導出され得る。ピクチャのリフレッシュ済みの領域の境界は、タイルグループヘッダが構文解析された後にデコーダによって更新され、タイルグループのrefreshed_region_flagの値は1に等しい。
18) 解決策17)の一代替形態では、ピクチャの中のリフレッシュ済みの領域の境界は、ピクチャの各タイルグループの中で明示的にシグナリングされる。
a. タイルグループが属するピクチャがリフレッシュされていない領域を含むかどうかを示すために、フラグがシグナリングされうる。ピクチャがリフレッシュされていない領域を含まないことが指定されるとき、リフレッシュ済み境界情報はシグナリングされず、単純にピクチャ境界に等しいものと推測されうる。
19) 現在ピクチャに対して、次のように、ループ内フィルタプロセスにおいてリフレッシュ済みの領域の境界が使用される。
a. デブロッキングプロセスの場合、エッジがデブロッキングされる必要があるか否かを決めるために、リフレッシュ済みの領域のエッジを決定する。
b. SAOプロセスの場合、リフレッシュ領域を横断するループフィルタが可能とされないとき、リフレッシュされていない領域からのサンプルを使用することを回避するためにクリッピングプロセスが適用され得るように、リフレッシュ済みの領域の境界を決定する。
c. ALFプロセスの場合、リフレッシュ済みの領域を横断するループフィルタが可能とされないとき、リフレッシュされていない領域からのサンプルを使用することを回避するためにクリッピングプロセスが適用され得るように、リフレッシュ領域の境界を決定する。
20) 動き補償プロセスについて、リフレッシュ済みの領域の境界、特に参照ピクチャの中のリフレッシュ済みの領域の境界についての情報が、次のように使用される。すなわち、現在ピクチャの中の現在ブロックが、refreshed_region_flagが1に等しいタイルグループの中にあり、かつ参照ブロックが、リフレッシュされていない領域を含む参照ピクチャの中にあるとき、以下のことが適用される。
a. 現在ブロックからその参照ピクチャへの動きベクトルは、その参照ピクチャの中のリフレッシュ済みの領域の境界によってクリッピングされる。
b. その参照ピクチャの中のサンプルのための分数補間フィルタについて、これはその参照ピクチャの中のリフレッシュ済みの領域の境界によってクリッピングされる。
本開示の実施形態の詳細な説明が提供される。説明は基礎テキストに関連し、基礎テキストはJVET寄稿JVET-M1001-v5である。すなわち、差分だけが記載されるが、以下で述べられない基礎テキストの中のテキストは、現状のままで適用される。基礎テキストに比べて修正されるテキストは、イタリック体が使用される。
定義が与えられる。
3.1 クリーンランダムアクセス(CRA)ピクチャ: CRA_NUTに等しいnal_unit_typeを各VCL NALユニットが有するIRAPピクチャ。
注 - CRAピクチャは、その復号プロセスにおけるインター予測のために、それ自体以外のいかなるピクチャも参照せず、復号順序でビットストリームの中の最初のピクチャであってよく、または後でビットストリームの中に出現してよい。CRAピクチャは、関連付けられたRADLピクチャまたはRASLピクチャを有してよい。CRAピクチャが1に等しいNoIncorrectPicOutputFlagを有するとき、RASLピクチャは、ビットストリームの中に存在しないピクチャへの参照を含み得るため、復号可能でない場合があるので、関連付けられたRASLピクチャはデコーダによって出力されない。
3.2 コーディングされたビデオシーケンス(CVS): NoIncorrectPicOutputFlagが1に等しいIRAPアクセスユニットまたはNoIncorrectPicOutputFlagが1に等しいGDRアクセスユニットである後続の任意のアクセスユニットまでの(ただし、それを含まない)すべての後続のアクセスユニットを含む、NoIncorrectPicOutputFlagが1に等しいIRAPアクセスユニットまたはNoIncorrectPicOutputFlagが1に等しいGDRアクセスユニットと、それに後続する0、またはNoIncorrectPicOutputFlagが1に等しいIRAPアクセスユニットもしくはNoIncorrectPicOutputFlagが1に等しいGDRアクセスユニットでない、より多くのアクセスユニットとを復号順序で備える、アクセスユニットのシーケンス。
注1 - IRAPアクセスユニットは、IDRアクセスユニットまたはCRAアクセスユニットでありうる。各IDRアクセスユニットに対してNoIncorrectPicOutputFlagの値は1に等しく、復号順序でビットストリームの中の最初のアクセスユニットである各CRAアクセスユニットは、復号順序でエンドオブシーケンスNALユニットに後続するか、または1に等しいHandleCraAsCvsStartFlagを有する、最初のアクセスユニットである。
注2 - 復号順序でビットストリームの中の最初のアクセスユニットである各GDRアクセスユニットに対して、NoIncorrectPicOutputFlagの値が1に等しいことは、復号順序でエンドオブシーケンスNALユニットに後続するか、または1に等しいHandleGdrAsCvsStartFlagを有する、最初のアクセスユニットである。
3.3 漸次復号リフレッシュ(GDR)アクセスユニット: コーディングされたピクチャがGDRピクチャであるアクセスユニット。
3.4 漸次復号リフレッシュ(GDR)ピクチャ: GDR_NUTに等しいnal_unit_typeを各VCL NALユニットが有するピクチャ。
3.5 ランダム・アクセス・スキップド・リーディング(RASL)ピクチャ: RASL_NUTに等しいnal_unit_typeを各VCL NALユニットが有するコーディングされたピクチャ。
注 - すべてのRASLピクチャは、関連付けられるCRAピクチャのリーディングピクチャである。関連付けられるCRAピクチャが、1に等しいNoIncorrectPicOutputFlagを有するとき、ビットストリームの中に存在しないピクチャへの参照をRASLピクチャが含み得るので、RASLピクチャは出力されず、正しく復号可能でない場合がある。RASLピクチャは、非RASLピクチャの復号プロセスのための参照ピクチャとして使用されない。存在するとき、すべてのRASLピクチャは、関連付けられる同じCRAピクチャのすべてのトレーリングピクチャに復号順序で先行する。
シーケンス・パラメータ・セット・ロー・バイト・シーケンス・ペイロード(RBSP:raw byte sequence payload)のシンタックスおよびセマンティック。
Figure 2022524618000017
1に等しいgdr_enabled_flagは、コーディングされたビデオシーケンスの中にGDRピクチャが存在し得ることを指定する。0に等しいgdr_enabled_flagは、コーディングされたビデオシーケンスの中にGDRピクチャが存在しないことを指定する。
ピクチャパラメータセットRBSPのシンタックスおよびセマンティック。
Figure 2022524618000018
1に等しいrect_tile_group_info_in_pps_flagは、長方形タイルグループ情報がPPSの中でシグナリングされることを指定する。0に等しいrect_tile_group_info_in_pps_flagは、長方形タイルグループ情報がPPSの中でシグナリングされないことを指定する。
アクティブなSPSの中のgdr_enabled_flagの値が0に等しいとき、rect_tile_group_info_in_pps_flagの値が0に等しくなければならないことが、ビットストリーム適合の要件である。
1に等しいloop_filter_across_refreshed_region_enabled_flagは、PPSを参照するピクチャの中で、refreshed_region_flagが1に等しいタイルグループの境界を横断するループ内フィルタ処理演算が実行され得ることを指定する。0に等しいloop_filter_across_refreshed_region_enabled_flagは、PPSを参照するピクチャの中で、refreshed_region_flagが1に等しいタイルグループの境界を越えてループ内フィルタ処理演算が実行されないことを指定する。ループ内フィルタ処理演算は、デブロッキングフィルタ、サンプル適応オフセットフィルタ、および適応ループフィルタ演算を含む。存在しないとき、loop_filter_across_refreshed_region_enabled_flagの値は0に等しいものと推測される。
1に等しいsignalled_tile_group_id_flagは、タイルグループごとのタイルグループIDがシグナリングされることを指定する。0に等しいsignalled_tile_group_index_flagは、タイルグループIDがシグナリングされないことを指定する。存在しないとき、signalled_tile_group_index_flagの値は0に等しいものと推測される。
signalled_tile_group_id_length_minus1+1は、存在するときシンタックス要素tile_group_id[ i ]を、かつタイルグループヘッダの中のシンタックス要素tile_group_addressを表すために使用される、ビットの数を指定する。signalled_tile_group_index_length_minus1の値は、両端値を含む0~15という範囲の中になければならない。存在しないとき、signalled_tile_group_index_length_minus1の値は次のように推測される。
rect_tile_group_info_in_pps_flagが1に等しい場合、Ceil( Log2( num_tile_groups_in_pic_minus1 + 1 ) ) - 1。
そうでない場合、Ceil( Log2( NumTilesInPic ) ) - 1。
全般的なタイルグループヘッダのシンタックスおよびセマンティック。
Figure 2022524618000019
tile_group_addressは、タイルグループの中の最初のタイルのタイルアドレスを指定する。存在しないとき、tile_group_addressの値は、0に等しいものと推測される。
rect_tile_group_flagが0に等しい場合、以下のことが適用される。
tile_group_addressは、式6-7によって指定されるタイルIDである。
tile_group_addressの長さは、Ceil( Log2 ( NumTilesInPic ) )ビットである。
tile_group_addressの値は、両端値を含む0~NumTilesInPic - 1という範囲の中になければならない。
そうではなく、rect_tile_group_flagが1に等しく、かつrect_tile_group_info_in_ppsが0に等しい場合、以下のことが適用される。
tile_group_addressは、第iのタイルグループの左上隅角に位置するタイルのタイルインデックスである。
tile_group_addressの長さは、signalled_tile_group_index_length_minus1 + 1ビットである。
signalled_tile_group_id_flagが0に等しい場合、tile_group_addressの値は、両端値を含む0~NumTilesInPic - 1という範囲の中になければならない。そうでない場合、tile_group_addressの値は、両端値を含む0~2( signalled_tile_group_index_length_minus1 + 1 ) - 1という範囲の中になければならない。
それ以外の(rect_tile_group_flagが1に等しく、かつrect_tile_group_info_in_ppsが1に等しい)場合、以下のことが適用される。
tile_group_addressは、タイルグループのタイルグループIDである。
tile_group_addressの長さは、signalled_tile_group_index_length_minus1 + 1ビットである。
signalled_tile_group_id_flagが0に等しい場合、tile_group_addressの値は、両端値を含む0~num_tile_groups_in_pic_minus1という範囲の中になければならない。そうでない場合、tile_group_addressの値は、両端値を含む0~2( signalled_tile_group_index_length_minus1 + 1 ) - 1という範囲の中になければならない。
bottom_right_tile_idは、タイルグループの右下隅角に位置するタイルのタイルインデックスを指定する。single_tile_per_tile_group_flagが1に等しいとき、bottom_right_tile_idは、tile_group_addressに等しいものと推測される。bottom_right_tile_idシンタックス要素の長さは、Ceil( Log2( NumTilesInPic) )ビットである。
現在タイルグループの中のタイルの数を指定する変数NumTilesInCurrTileGroup、タイルグループの左上のタイルのタイルインデックスを指定するTopLeftTileIdx、タイルグループの右下のタイルのタイルインデックスを指定するBottomRightTileIdx、および現在タイルグループの中の第iのタイルのタイルインデックスを指定するTgTileIdx[ i ]が、次のように導出される。
if( rect_tile_group_flag ) {
if ( tile_group_info_in_pps ) {
tileGroupIdx = 0
while( tile_group_address != rect_tile_group_id[ tileGroupIdx ] )
tileGroupIdx++
tileIdx = top_left_tile_idx[ tileGroupIdx ]
BottomRightTileIdx = bottom_right_tile_idx[ tileGroupIdx ]
} else {
tileIdx = tile_group_address
BottomRightTileIdx = bottom_right_tile_id
}
TopLeftTileIdx = tileIdx
deltaTileIdx = BottomRightTileIdx - TopLeftTileIdx
NumTileRowsInTileGroupMinus1 = deltaTileIdx / ( num_tile_columns_minus1 + 1 ) (7-35)
NumTileColumnsInTileGroupMinus1 = deltaTileIdx % ( num_tile_columns_minus1 + 1 )
NumTilesInCurrTileGroup = ( NumTileRowsInTileGroupMinus1 + 1 ) * ( NumTileColumnsInTileGroupMinus1 + 1 )
for( j = 0, tIdx = 0; j < NumTileRowsInTileGroupMinus1 + 1; j++, tileIdx += num_tile_columns_minus1 + 1 )
for( i = 0, currTileIdx = tileIdx; i < NumTileColumnsInTileGroupMinus1 + 1; i++, currTileIdx++, tIdx++ )
TgTileIdx[ tIdx ] = currTileIdx
} else {
NumTilesInCurrTileGroup = num_tiles_in_tile_group_minus1 + 1
TgTileIdx[ 0 ] = tile_group_address
for( i = 1; i < NumTilesInCurrTileGroup; i++ )
TgTileIdx[ i ] = TgTileIdx[ i - 1 ] + 1
}
recovery_poc_cntは、出力順序での復号ピクチャのリカバリポイントを指定する。CVSの中で復号順序で現在ピクチャ(すなわち、GDRピクチャ)に後続し、かつ現在ピクチャのPicOrderCntVal+recovery_poc_cntの値に等しいPicOrderCntValを有する、ピクチャpicAがある場合、ピクチャpicAは、リカバリポイントピクチャと呼ばれる。そうでない場合、現在ピクチャのPicOrderCntVal+recovery_poc_cntの値よりも大きいPicOrderCntValを有する、出力順序で最初のピクチャが、リカバリポイントピクチャと呼ばれる。リカバリポイントピクチャは、復号順序で現在ピクチャに先行してはならない。出力順序でのすべての復号ピクチャは、リカバリポイントピクチャの出力順序位置において開始する内容の中で正確またはほぼ正確であるものと示される。recovery_poc_cntの値は、両端値を含む-MaxPicOrderCntLsb / 2~MaxPicOrderCntLsb / 2 - 1という範囲の中になければならない。
RecoveryPointPocValの値は、次のように導出される。
RecoveryPointPocVal = PicOrderCntVal + recovery_poc_cnt
1に等しいrefreshed_region_flagは、タイルグループの復号が、関連付けられるGDRのNoIncorrectPicOutputFlagの値にかかわらず正確な再構成サンプル値を生成することを指定する。0に等しいrefreshed_region_flagは、タイルグループの復号が、NoIncorrectPicOutputFlagが1に等しい関連付けられるGDRから開始するとき、不正確な再構成サンプル値を生成する場合があることを指定する。存在しないとき、refreshed_region_flagの値は、1に等しいものと推測される。
注x - 現在ピクチャ自体が、NoIncorrectPicOutputFlagが1に等しいGDRピクチャであり得る。
タイルグループがリフレッシュされる境界は、次のように導出される。
tileColIdx = TopLeftTileIdx % ( num_tile_columns_minus1 + 1 )
tileRowIdx = TopLeftTileIdx / ( num_tile_columns_minus1 + 1 )
TGRefreshedLeftBoundary = ColBd[ tileColIdx ] << CtbLog2SizeY
TGRefreshedTopBoundary = RowBd[ tileRowIdx ] << CtbLog2SizeY
tileColIdx = BottomRightTileIdx % ( num_tile_columns_minus1 + 1 )
tileRowIdx = BottomRightTileIdx / ( num_tile_columns_minus1 + 1 )
TGRefreshedRightBoundary = ( ( ColBd[ tileColIdx ] + ColWidth[ tileColIdx ] ) << CtbLog2SizeY ) - 1
TGRefreshedRightBoundary = TGRefreshedRightBoundary > pic_width_in_luma_samples ? pic_width_in_luma_samples : TGRefreshedRightBoundary
TGRefreshedBotBoundary = ( ( RowBd[ tileRowIdx ] + RowHeight[ tileRowIdx ] ) << CtbLog2SizeY ) - 1
TGRefreshedBotBoundary = TGRefreshedBotBoundary > pic_height_in_luma_samples ? pic_height_in_luma_samples : TGRefreshedBotBoundary
NALユニットヘッダのセマンティック。
Figure 2022524618000020
...
nal_unit_typeがGDR_NUTに等しく、コーディングされたタイルグループがGDRピクチャに属するとき、TemporalIdは0に等しくなければならない。
アクセスユニットの順序およびCVSへの関連付けが説明される。
この仕様(すなわち、JVET寄稿JVET-M1001-v5)に準拠するビットストリームは、1つまたは複数のCVSを含む。
CVSは、1つまたは複数のアクセスユニットを含む。NALユニットおよびコーディングされたピクチャの順序、ならびにアクセスユニットへのそれらの関連付けが、第7.4.2.4.4節に記載される。
CVSの最初のアクセスユニットは、以下のうちの1つである。
- NoBrokenPictureOutputFlagが1に等しいIRAPアクセスユニット。
- NoIncorrectPicOutputFlagが1に等しいGDRアクセスユニット。
存在するとき、エンドオブシーケンスNALユニットまたはエンドオブビットストリーム終了NALユニットを含むアクセスユニットの後の次のアクセスユニットが、以下のうちの1つでなければならないことが、ビットストリーム適合の要件である。
- IDRアクセスユニットまたはCRAアクセスユニットであり得るIRAPアクセスユニット。
- GDRアクセスユニット。
8.1.1 コーディングされたピクチャのための復号プロセスが説明される。
...
現在ピクチャがIRAPピクチャであるとき、以下のことが適用される。
- 現在ピクチャが、IDRピクチャ、復号順序でビットストリームの中の最初のピクチャ、または復号順序でエンドオブシーケンスNALユニットに後続する最初のピクチャであるとき、変数NoIncorrectPicOutputFlagは、1に等しく設定される。
- そうではなく、この仕様で指定されないいくつかの外部手段(たとえば、ユーザ入力)が、変数HandleCraAsCvsStartFlagを現在ピクチャに対する値に設定するために利用可能であるとき、変数HandleCraAsCvsStartFlagは、外部手段によって提供される値に等しく設定され、変数NoIncorrectPicOutputFlagは、HandleCraAsCvsStartFlagに等しく設定される。
- そうでない場合、変数HandleCraAsCvsStartFlagは、0に等しく設定され、変数NoIncorrectPicOutputFlagは、0に等しく設定される。
現在ピクチャがGDRピクチャであるとき、以下のことが適用される。
- 現在ピクチャが、GDRピクチャ、復号順序でビットストリームの中の最初のピクチャ、または復号順序でエンドオブシーケンスNALユニットに後続する最初のピクチャであるとき、変数NoIncorrectPicOutputFlagは、1に等しく設定される。
- そうではなく、この仕様で指定されないいくつかの外部手段が、変数HandleGdrAsCvsStartFlagを現在ピクチャに対する値に設定するために利用可能であるとき、変数HandleGdrAsCvsStartFlagは、外部手段によって提供される値に等しく設定され、変数NoIncorrectPicOutputFlagは、HandleGdrAsCvsStartFlagに等しく設定される。
- そうでない場合、変数HandleGdrAsCvsStartFlagは、0に等しく設定され、変数NoIncorrectPicOutputFlagは、0に等しく設定される。
...
現在ピクチャCurrPicに対して復号プロセスは次のように動作する。
1. NALユニットの復号が第8.2節で指定される。
2. 第8.3節におけるプロセスは、タイルグループヘッダレイヤの中のシンタックス要素を使用する以下の復号プロセス、および上記のことを指定する。
- ピクチャ順序カウントに関係する変数および関数が、第8.3.1節で指定されるように導出される。これは、ピクチャの最初のタイルグループに対してのみ呼び出される必要がある。
- 非IDRピクチャのタイルグループごとの復号プロセスの開始において、参照ピクチャリスト0(RefPicList[ 0 ])および参照ピクチャリスト1(RefPicList[ 1 ])の導出のために、第8.3.2節で指定される参照ピクチャリスト構成のための復号プロセスが呼び出される。
- 第8.3.3節における参照ピクチャマーキングのための復号プロセスが呼び出され、参照ピクチャは、「参照のために未使用」または「長期の参照のために使用済み」としてマークされ得る。これは、ピクチャの最初のタイルグループに対してのみ呼び出される。
- PicOutputFlagは次のように設定される。
- 次の条件のうちの1つが真であるとき、PictureOutputFlagは、0に等しく設定される。
- 現在ピクチャがRASLピクチャであり、関連付けられるIRAPピクチャのNoIncorrectPicOutputFlagが1に等しい。
- gdr_enabled_flagが1に等しく、現在ピクチャが、NoIncorrectPicOutputFlagが1に等しいGDRピクチャである。
- gdr_enabled_flagが1に等しく、現在ピクチャが、refreshed_region_flagが0に等しい1つまたは複数のタイルグループを含み、関連付けられるGDRピクチャのNoBrokenPictureOutputFlagが1に等しい。
- そうでない場合、PicOutputFlagは、1に等しく設定される。
3. 復号プロセスは、ツリーユニットをコーディングすること、スケーリング、変換、ループ内フィルタ処理などのために呼び出される。
4. 現在ピクチャのすべてのタイルグループが復号された後、現在の復号ピクチャが「短期の参照のために使用済み」としてマークされる。
ピクチャ順序カウントのための復号プロセスが説明される。
このプロセスの出力は、PicOrderCntVal、すなわち、現在ピクチャのピクチャ順序カウントである。
コーディングされた各ピクチャは、PicOrderCntValとして示されるピクチャ順序カウント変数に関連付けられる。
現在ピクチャが、NoIncorrectPicOutputFlagが1に等しいIRAPピクチャ、またはNoIncorrectPicOutputFlagが1に等しいGDRピクチャでないとき、変数prevPicOrderCntLsbおよびprevPicOrderCntMsbは、次のように導出される。
- 0に等しいTemporalIdを有するとともにRASLまたはRADLピクチャでない、復号順序で前のピクチャを、prevTid0Picとする。
- 変数prevPicOrderCntLsbは、prevTid0Picのtile_group_pic_order_cnt_lsbに等しく設定される。
- 変数prevPicOrderCntMsbは、prevTid0PicのPicOrderCntMsbに等しく設定される。
現在ピクチャの変数PicOrderCntMsbは、次のように導出される。
- 現在ピクチャが、NoIncorrectPicOutputFlagが1に等しいIRAPピクチャ、またはNoIncorrectPicOutputFlagが1に等しいGDRピクチャであるとき、PicOrderCntMsbは、0に等しく設定される。
- そうでない場合、PicOrderCntMsbは、次のように導出される。
if( ( tile_group_pic_order_cnt_lsb < prevPicOrderCntLsb ) && ( ( prevPicOrderCntLsb - tile_group_pic_order_cnt_lsb ) >= ( MaxPicOrderCntLsb / 2 ) ) )
PicOrderCntMsb = prevPicOrderCntMsb + MaxPicOrderCntLsb (8-1)
else if( (tile_group_pic_order_cnt_lsb > prevPicOrderCntLsb ) && ( ( tile_group_pic_order_cnt_lsb - prevPicOrderCntLsb ) > ( MaxPicOrderCntLsb / 2 ) ) )
PicOrderCntMsb = prevPicOrderCntMsb - MaxPicOrderCntLsb
else
PicOrderCntMsb = prevPicOrderCntMsb
PicOrderCntValは、次のように導出される。
PicOrderCntVal = PicOrderCntMsb + tile_group_pic_order_cnt_lsb (8-2)
注1 - NoIncorrectPicOutputFlagが1に等しいIRAPピクチャに対してPicOrderCntMsbが0に等しく設定されるので、NoIncorrectPicOutputFlagが1に等しいすべてのIRAPピクチャは、tile_group_pic_order_cnt_lsbに等しいPicOrderCntValを有する。
注1 - NoIncorrectPicOutputFlagが1に等しいGDRピクチャに対してPicOrderCntMsbが0に等しく設定されるので、NoIncorrectPicOutputFlagが1に等しいすべてのGDRピクチャは、tile_group_pic_order_cnt_lsbに等しいPicOrderCntValを有する。
PicOrderCntValの値は、両端値を含む-231~231 - 1という範囲の中になければならない。
現在ピクチャがGDRピクチャであるとき、LastGDRPocValの値は、PicOrderCntValに等しくなるように設定される。
ピクチャがリフレッシュされた境界位置のための復号プロセスが説明される。
このプロセスは、gdr_enabled_flagが1に等しいときにしか呼び出されない。
このプロセスは、タイルグループヘッダ構文解析が完了した後に呼び出される。
このプロセスの出力は、PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPos、すなわち、現在ピクチャのリフレッシュ済みの領域の境界位置である。
コーディングされた各ピクチャは、PicOrderCntValとして示されるリフレッシュ済み領域境界位置変数のセットに関連付けられる。
PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosは、次のように導出される。
タイルグループが、refreshed_region_flagが1に等しい現在ピクチャの最初に受信されたタイルグループである場合、以下のことが適用される。
PicRefreshedLeftBoundaryPos = TGRefreshedLeftBoundary
PicRefreshedRightBoundaryPos = TGRefreshedRightBoundary
PicRefreshedTopBoundaryPos = TGRefreshedTopBoundary
PicRefreshedBotBoundaryPos = TileGroupBotBoundary
そうではなく、refreshed_region_flagが1に等しい場合、以下のことが適用される。
PicRefreshedLeftBoundaryPos = TGRefreshedLeftBoundary < PicRefreshedLeftBoundaryPos ? TGRefreshedLeftBoundary : PicRefreshedLeftBoundaryPos
PicRefreshedRightBoundaryPos = TGRefreshedRightBoundary > PicRefreshedRightBoundaryPos ? TGRefreshedRightBoundary : PicRefreshedRightBoundaryPos
PicRefreshedTopBoundaryPos = TGRefreshedTopBoundary < PicRefreshedTopBoundaryPos ? TGRefreshedTopBoundary : RefreshedRegionTopBoundaryPos
PicRefreshedBotBoundaryPos = TileGroupBotBoundary > PicRefreshedBotBoundaryPos ? TileGroupBotBoundary : PicRefreshedBotBoundaryPos
参照ピクチャリスト構成のための復号プロセスが説明される。
...
NoIncorrectPicOutputFlagが1に等しいIRAPピクチャまたはNoIncorrectPicOutputFlagが1に等しいGDRピクチャでない、各現在ピクチャに対して、maxPicOrderCnt - minPicOrderCntの値がMaxPicOrderCntLsb / 2よりも小さくなければならないことが、ビットストリーム適合の要件である。
...
参照ピクチャマーキングのための復号プロセス。
...
現在ピクチャが、NoIncorrectPicOutputFlagが1に等しいIRAPピクチャまたはNoIncorrectPicOutputFlagが1に等しいGDRピクチャである場合、(もしあれば)現在、DPBの中にあるすべての参照ピクチャは「参照のために未使用」としてマークされる。
...
時間ルーマ動きベクトル予測のための導出プロセスが説明される。
...
変数currCbは、ルーマロケーション( xCb, yCb )における現在ルーマコーディングブロックを指定する。
変数mvLXColおよびavailableFlagLXColは、次のように導出される。
- tile_group_temporal_mvp_enabled_flagが0に等しい場合、mvLXColの両方の成分は、0に等しく設定され、availableFlagLXColは、0に等しく設定される。
- そうでない(tile_group_temporal_mvp_enabled_flagが1に等しい)場合、以下の順序付きステップが適用される。
1. 右下のコロケートされた動きベクトルが、次のように導出される。
xColBr = xCb + cbWidth (8-414)
yColBr = yCb + cbHeight (8-415)
leftBoundaryPos = gdr_enabled_flag ? RefPicList[ X ][ refIdxLX ]によって参照されるピクチャのPicRefreshedLeftBoundaryPos : 0 (8-415)
topBoundaryPos = gdr_enabled_flag ? RefPicList[ X ][ refIdxLX ]によって参照されるピクチャのPicRefreshedTopBoundaryPos : 0 (8-415)
rightBoundaryPos = gdr_enabled_flag ? RefPicList[ X ][ refIdxLX ]によって参照されるピクチャのPicRefreshedRightBoundaryPos : pic_width_in_luma_samples (8-415)
botBoundaryPos = gdr_enabled_flag ? RefPicList[ X ][ refIdxLX ]によって参照されるピクチャのPicRefreshedBotBoundaryPos : pic_height_in_luma_samples (8-415)
- yCb >> CtbLog2SizeYがyColBr >> CtbLog2SizeYに等しく、yColBrが、両端値を含むtopBoundaryPosからbotBoundaryPosまでの範囲の中にあり、かつxColBrが、両端値を含むleftBoundaryPosからrightBoundaryPosまでの範囲の中にある場合、以下のことが適用される。
- 変数colCbは、ColPicによって指定されるコロケートされたピクチャの内側の、( ( xColBr >> 3 ) << 3, ( yColBr >> 3 ) << 3 )によって与えられる修正済みのロケーションをカバーするルーマコーディングブロックを指定する。
- ルーマロケーション( xColCb, yColCb )は、ColPicによって指定されるコロケートされたピクチャの左上のルーマサンプルに対してcolCbによって指定されるコロケートされたルーマコーディングブロックの左上のサンプルに等しく設定される。
- 第8.5.2.12節で指定されるようなコロケートされた動きベクトルのための導出プロセスは、入力としてcurrCb、colCb、( xColCb, yColCb )、refIdxLX、および0に等しく設定されたsbFlagとともに呼び出され、出力がmvLXColおよびavailableFlagLXColに割り当てられる。
- そうでない場合、mvLXColの両方の成分は、0に等しく設定され、availableFlagLXColは、0に等しく設定される。
2. ...
ルーマサンプル双線形補間プロセスが説明される。
このプロセスの入力は、以下の通りである。
- フルサンプル単位でのルーマロケーション( xIntL, yIntL )、
- 分数サンプル単位でのルーマロケーション( xFracL, yFracL )、
- ルーマ参照サンプルアレイrefPicLXL
- 参照ピクチャのリフレッシュ済み領域境界PicRefreshedLeftBoundaryPos、PicRefreshedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPos。
...
フルサンプル単位でのルーマロケーション( xInti, yInti )は、i = 0..1に対して次のように導出される。
- gdr_enabled_flagが1に等しい場合、以下のことが適用される。
xInti = Clip3( PicRefreshedLeftBoundaryPos, PicRefreshedRightBoundaryPos, xIntL + i ) (8-458)
yInti = Clip3( PicRefreshedTopBoundaryPos, PicRefreshedBotBoundaryPos, yIntL + i ) (8-458)
- そうでない(gdr_enabled_flagが0に等しい)場合、以下のことが適用される。
xInti = sps_ref_wraparound_enabled_flag ? ClipH( ( sps_ref_wraparound_offset_minus1 + 1 ) * MinCbSizeY, picW, ( xIntL + i ) ) : (8-459)
Clip3( 0, picW - 1, xIntL + i )
yInti = Clip3( 0, picH - 1, yIntL + i ) (8-460)
...
ルーマサンプル8タップ補間フィルタ処理プロセスが説明される。
このプロセスの入力は、以下の通りである。
- フルサンプル単位でのルーマロケーション( xIntL, yIntL )、
- 分数サンプル単位でのルーマロケーション( xFracL, yFracL )、
- ルーマ参照サンプルアレイrefPicLXL
- 参照サンプルパディングの方向および量を指定する、dir = 0,1を伴うリストpadVal[ dir ]。
- 参照ピクチャのリフレッシュ済み領域境界PicRefreshedLeftBoundaryPos、PicRefreshedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPos。
...
フルサンプル単位でのルーマロケーション( xInti, yInti )は、i = 0..7に対して次のように導出される。
- gdr_enabled_flagが1に等しい場合、以下のことが適用される。
xInti = Clip3( PicRefreshedLeftBoundaryPos, PicRefreshedRightBoundaryPos, xIntL + i - 3 ) (8-830)
yInti = Clip3( PicRefreshedTopBoundaryPos, PicRefreshedBotBoundaryPos, yIntL + i - 3 ) (8-830)
- そうでない(gdr_enabled_flagが0に等しい)場合、以下のことが適用される。
xInti = sps_ref_wraparound_enabled_flag ? ClipH( ( sps_ref_wraparound_offset_minus1 + 1 ) * MinCbSizeY, picW, xIntL + i - 3 ) : (8-831)
Clip3( 0, picW - 1, xIntL + i - 3 )
yInti = Clip3( 0, picH - 1, yIntL + i - 3 ) (8-832)
クロマサンプル補間プロセスが説明される。
このプロセスの入力は、以下の通りである。
- フルサンプル単位でのクロマロケーション( xIntC, yIntC )、
- 1/32分数サンプル単位でのクロマロケーション( xFracC, yFracC )、
- クロマ参照サンプルアレイrefPicLXC
- 参照ピクチャのリフレッシュ済み領域境界PicRefreshedLeftBoundaryPos、PicRefreshedTopBoundaryPos、PicRefreshedRightBoundaryPos、およびPicRefreshedBotBoundaryPos。
...
変数xOffsetは、( sps_ref_wraparound_offset_minus1 + 1 ) * MinCbSizeY ) / SubWidthCに等しく設定される。
フルサンプル単位でのクロマロケーション( xInti, yInti )は、i = 0..3に対して次のように導出される。
- gdr_enabled_flagが1に等しい場合、以下のことが適用される。
xInti = Clip3( PicRefreshedLeftBoundaryPos / SubWidthC, PicRefreshedRightBoundaryPos / SubWidthC, xIntL + i ) (8-844)
yInti = Clip3( PicRefreshedTopBoundaryPos / SubHeightC, PicRefreshedBotBoundaryPos / SubHeightC, yIntL + i ) (8-844)
- そうでない(gdr_enabled_flagが0に等しい)場合、以下のことが適用される。
xInti = sps_ref_wraparound_enabled_flag ? ClipH( xOffset, picWC, xIntC + i - 1 ) : (8-845)
Clip3( 0, picWC - 1, xIntC + i - 1 )
yInti = Clip3( 0, picHC - 1, yIntC + i - 1 ) (8-846)
デブロッキングフィルタプロセスが説明される。
全般的なプロセス。
...
デブロッキングフィルタプロセスは、以下のタイプのエッジを除いて、ピクチャのすべてのコーディングサブブロックエッジおよび変換ブロックエッジに適用される。
- ピクチャの境界にあるエッジ。
- 以下のことのすべてが満たされるとき、タイルグループtgAの上の境界に一致するエッジ。
- gdr_enabled_flagが1に等しい。
- loop_filter_across_refreshed_region_enabled_flagが0に等しい。
- そのエッジがタイルグループtgBの下の境界に一致し、tgBのrefreshed_region_flagの値がtgAのrefreshed_region_flagの値とは異なる。
- 以下のことのすべてが満たされるとき、タイルグループtgAの左の境界に一致するエッジ。
- gdr_enabled_flagが1に等しい。
- loop_filter_across_refreshed_region_enabled_flagが0に等しい。
- そのエッジがタイルグループtgBの右の境界に一致し、tgBのrefreshed_region_flagの値がtgAのrefreshed_region_flagの値とは異なる。
- loop_filter_across_tiles_enabled_flagが0に等しいとき、タイル境界に一致するエッジ。
- tile_group_loop_filter_across_tile_groups_enabled_flagが0に等しいかまたはtile_group_deblocking_filter_disabled_flagが1に等しいタイルグループの、上または左の境界に一致するエッジ。
- tile_group_deblocking_filter_disabled_flagが1に等しいタイルグループ内のエッジ。
- 考慮される成分の8×8サンプルグリッド境界に対応しないエッジ。
- エッジの両側がインター予測を使用するクロマ成分内のエッジ。
- 関連する変換ユニットのエッジでないクロマ変換ブロックのエッジ。
- IntraSubPartitionsSplit値がISP_NO_SPLITに等しくないコーディングユニットのルーマ変換ブロックを横断するエッジ。
一方向のためのデブロッキングフィルタプロセスが説明される。
...
コーディングブロック幅log2CbW、コーディングブロック高さlog2CbH、およびコーディングブロックの左上のサンプルのロケーション( xCb, yCb )を有するコーディングユニットごとに、edgeTypeがEDGE_VERに等しくxCb % 8が0に等しいとき、またはedgeTypeがEDGE_HORに等しくyCb % 8が0に等しいとき、以下の順序付きステップによってエッジがフィルタ処理される。
1. コーディングブロック幅nCbWが、1 << log2CbWに等しく設定され、コーディングブロック高さnCbHが、1 << log2CbHに等しく設定される。
2. 変数filterEdgeFlagが、次のように導出される。
- edgeTypeがEDGE_VERに等しく、かつ次の条件のうちの1つまたは複数が真である場合、filterEdgeFlagは、0に等しく設定される。
- 現在コーディングブロックの左の境界がピクチャの左の境界である。
- 現在コーディングブロックの左の境界がタイルの左の境界であり、loop_filter_across_tiles_enabled_flagが0に等しい。
- 現在コーディングブロックの左の境界がタイルグループの左の境界であり、tile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
- 現在コーディングブロックの左の境界が現在タイルグループの左の境界であり、次のすべての条件が満たされる。
- gdr_enabled_flagが1に等しい。
- loop_filter_across_refreshed_region_enabled_flagが0に等しい。
- 現在タイルグループの左の境界と境界を共有したタイルグループが存在し、そのrefreshed_region_flagの値が現在タイルグループのrefreshed_region_flagの値とは異なる。
- そうではなく、edgeTypeがEDGE_HORに等しく、かつ次の条件のうちの1つまたは複数が真である場合、変数filterEdgeFlagは、0に等しく設定される。
- 現在ルーマコーディングブロックの上の境界がピクチャの上の境界である。
- 現在コーディングブロックの上の境界がタイルの上の境界であり、loop_filter_across_tiles_enabled_flagが0に等しい。
- 現在コーディングブロックの上の境界がタイルグループの上の境界であり、tile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
- 現在コーディングブロックの上の境界が現在タイルグループの上の境界であり、次のすべての条件が満たされる。
- gdr_enabled_flagが1に等しい。
- loop_filter_across_refreshed_region_enabled_flagが0に等しい。
- 現在タイルグループの上の境界と境界を共有したタイルグループが存在し、そのrefreshed_region_flagの値が現在タイルグループのrefreshed_region_flagの値とは異なる。
- そうでない場合、filterEdgeFlagは、1に等しく設定される。
タイルが統合されると、シンタックスを適合させる。
3. 2次元(nCbW)×(nCbH)アレイedgeFlagsのすべての要素は、0に等しくなるように初期化される。
SAOのためのCTB修正プロセスが説明される。
...
i = 0..nCtbSw - 1かつj = 0..nCtbSh - 1を伴うすべてのサンプルロケーション( xSi, ySj )および( xYi, yYj )に対して、recPicture[ xSi ][ ySj ]をカバーするコーディングブロックを含むコーディングユニットのpcm_loop_filter_disabled_flag、pcm_flag[ xYi ][ yYj ]、およびcu_transquant_bypass_flagの値に応じて、以下のことが適用される。
- ....
将来決定変換/量子化バイパスにおいて保留中の強調されたセクションを修正する。
- そうではなく、SaoTypeIdx[ cIdx ][ rx ][ ry ]が2に等しい場合、以下の順序付きステップが適用される。
1. k = 0..1に対するhPos[ k ]およびvPos[ k ]の値が、SaoEoClass[ cIdx ][ rx ][ ry ]に基づいてTable 8-18の中で指定される。
2. 変数edgeIdxが、次のように導出される。
- 修正済みのサンプルロケーション( xSik', ySjk' )および( xYik', yYik' )が、次のように導出される。
( xSik', ySjk' ) = ( xSi + hPos[ k ], ySj + vPos[ k ] ) (8-1128)
( xYik', yYjk' ) = ( cIdx = = 0 ) ? ( xSik', ySjk' ) : ( xSik' * SubWidthC, ySjk' * SubHeightC ) (8-1129)
- k = 0..1を伴うすべてのサンプルロケーション( xSik', ySjk' )および( xYik', yYjk' )に対して次の条件のうちの1つまたは複数が真である場合、edgeIdxは、0に等しく設定される。
- ロケーション( xSik', ySjk' )におけるサンプルが、ピクチャ境界の外側にある。
- gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、現在タイルグループのrefreshed_region_flagが1に等しく、かつロケーション( xSik', ySjk' )におけるサンプルを含むタイルグループのrefreshed_region_flagが0に等しい。
- ロケーション( xSik', ySjk' )におけるサンプルが、異なるタイルグループに属し、次の2つの条件のうちの1つが真である。
- MinTbAddrZs[ xYik' >> MinTbLog2SizeY ][ yYjk' >> MinTbLog2SizeY ]がMinTbAddrZs[ xYi >> MinTbLog2SizeY ][ yYj >> MinTbLog2SizeY ]よりも小さく、サンプルrecPicture[ xSi ][ ySj ]が属するタイルグループの中のtile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
- MinTbAddrZs[ xYi >> MinTbLog2SizeY ][ yYj >> MinTbLog2SizeY ]がMinTbAddrZs[ xYik' >> MinTbLog2SizeY ][ yYjk' >> MinTbLog2SizeY ]よりも小さく、サンプルrecPicture[ xSik' ][ ySjk' ]が属するタイルグループの中のtile_group_loop_filter_across_tile_groups_enabled_flagが0に等しい。
- loop_filter_across_tiles_enabled_flagが0に等しく、ロケーション( xSik', ySjk' )におけるサンプルが、異なるタイルに属する。
タイルグループを有しないタイルが組み込まれるとき、強調されたセクションを修正する。
- そうでない場合、edgeIdxは、次のように導出される。
- 以下のことが適用される。
edgeIdx = 2 + Sign( recPicture[ xSi ][ ySj ] - recPicture[ xSi + hPos[ 0 ] ][ ySj + vPos[ 0 ] ] ) + Sign( recPicture[ xSi ][ ySj ] - recPicture[ xSi + hPos[ 1 ] ][ ySj + vPos[ 1 ] ] ) (8-1130)
- edgeIdxが0、1、または2に等しいとき、edgeIdxは次のように修正される。
edgeIdx = ( edgeIdx = = 2 ) ? 0 : ( edgeIdx + 1 ) (8-1131)
3. 修正済みのピクチャサンプルアレイsaoPicture[ xSi ][ ySj ]が、次のように導出される。
saoPicture[ xSi ][ ySj ] = Clip3( 0, ( 1 << bitDepth ) - 1, recPicture[ xSi ][ ySj ] + SaoOffsetVal[ cIdx ][ rx ][ ry ][ edgeIdx ] ) (8-1132)
ALFのためのルーマサンプルに対するコーディングツリーブロックフィルタ処理プロセスが説明される。
...
フィルタ処理済みの再構成ルーマサンプルalfPictureL[ x ][ y ]の導出のために、現在のルーマコーディングツリーブロックの内側の各再構成ルーマサンプルrecPictureL[ x ][ y ]が、x, y = 0..CtbSizeY - 1を伴って次のようにフィルタ処理される。
- ...
- ルーマサンプルの所与のアレイrecPictureの内側の対応するルーマサンプル( x, y )の各々に対するロケーション( hx, vy )は、次のように導出される。
- gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、ロケーション( x, y )におけるルーマサンプルを含むタイルグループtgAのrefreshed_region_flagが1に等しい場合、以下のことが適用される。
- ロケーション( hx, vy )が別のタイルグループtgBの中に位置し、かつtgBのrefreshed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれ、TGRefreshedLeftBoundary、TGRefreshedRightBoundary、TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。
- そうでない場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれ、PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。
hx = Clip3( leftBoundary, rightBoundary, xCtb + x ) (8-1140)
vy = Clip3( topBoundary, botBoundary, yCtb + y ) (8-1141)
- そうでない場合、以下のことが適用される。
hx = Clip3( 0, pic_width_in_luma_samples - 1, xCtb + x ) (8-1140)
vy = Clip3( 0, pic_height_in_luma_samples - 1, yCtb + y ) (8-1141)
- ...
ルーマサンプルに対するALF転置およびフィルタインデックスのための導出プロセスが説明される。
...
ルーマサンプルの所与のアレイrecPictureの内側の対応するルーマサンプル( x, y )の各々に対するロケーション( hx, vy )が、次のように導出される。
- gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、ロケーション( x, y )におけるルーマサンプルを含むタイルグループtgAのrefreshed_region_flagが1に等しい場合、以下のことが適用される。
- ロケーション( hx, vy )が別のタイルグループtgBの中に位置し、かつtgBのrefreshed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれ、TGRefreshedLeftBoundary、TGRefreshedRightBoundary、TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。
- そうでない場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれ、PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。
hx = Clip3( leftBoundary, rightBoundary, x ) (8-1140)
vy = Clip3( topBoundary, botBoundary, y ) (8-1141)
- そうでない場合、以下のことが適用される。
hx = Clip3( 0, pic_width_in_luma_samples - 1, x ) (8-1145)
vy = Clip3( 0, pic_height_in_luma_samples - 1, y ) (8-1146)
クロマサンプルのためのコーディングツリーブロックフィルタ処理プロセスが説明される。
...
フィルタ処理済みの再構成クロマサンプルalfPicture[ x ][ y ]の導出のために、現在のクロマコーディングツリーブロックの内側の各再構成クロマサンプルrecPicture[ x ][ y ]が、x, y = 0..ctbSizeC - 1を伴って次のようにフィルタ処理される。
- クロマサンプルの所与のアレイrecPictureの内側の対応するクロマサンプル( x, y )の各々に対するロケーション( hx, vy )が、次のように導出される。
- gdr_enabled_flagが1に等しく、loop_filter_across_refreshed_region_enabled_flagが0に等しく、ロケーション( x, y )におけるルーマサンプルを含むタイルグループtgAのrefreshed_region_flagが1に等しい場合、以下のことが適用される。
- ロケーション( hx, vy )が別のタイルグループtgBの中に位置し、かつtgBのrefreshed_region_flagが0に等しい場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれ、TGRefreshedLeftBoundary、TGRefreshedRightBoundary、TGRefreshedTopBoundary、およびTGRefreshedBotBoundaryに等しく設定される。
- そうでない場合、変数leftBoundary、rightBoundary、topBoundary、およびbotBoundaryは、それぞれ、PicRefreshedLeftBoundaryPos、PicRefreshedRightBoundaryPos、PicRefreshedTopBoundaryPos、およびPicRefreshedBotBoundaryPosに等しく設定される。
hx = Clip3( leftBoundary / SubWidthC, rightBoundary / SubWidthC, xCtbC + x ) (8-1140)
vy = Clip3( topBoundary / SubWidthC, botBoundary / SubWidthC, yCtbC + y ) (8-1141)
- そうでない場合、以下のことが適用される。
hx = Clip3( 0, pic_width_in_luma_samples / SubWidthC - 1, xCtbC + x ) (8-1177)
vy = Clip3( 0, pic_height_in_luma_samples / SubHeightC - 1, yCtbC + y ) (8-1178)
図7は、本開示の一実施形態による、漸次復号リフレッシュ(GDR)技法700を実施するように構成されたビデオビットストリーム750を示す。GDR技法700は、図5のGDR技法500と同様でありうる。本明細書で使用するビデオビットストリーム750は、コーディングされたビデオビットストリーム、ビットストリーム、またはそれらの変形と呼ばれることもある。図7に示すように、ビットストリーム750は、シーケンスパラメータセット(SPS:sequence parameter set)752、ピクチャパラメータセット(PPS:picture parameter set)754、スライスヘッダ756、および画像データ758を含む。
SPS752は、ピクチャのシーケンス(SOP:sequence of pictures)の中のすべてのピクチャに共通のデータを含む。対照的に、PPS754は、ピクチャ全体に共通のデータを含む。スライスヘッダ756は、たとえば、スライスタイプ、参照ピクチャのうちのどれが使用されるのかなどの、現在スライスについての情報を含む。SPS752およびPPS754は、パラメータセットと総称されることがある。SPS752、PPS754、およびスライスヘッダ756は、ネットワーク抽象化レイヤ(NAL)ユニットのタイプである。NALユニットは、後続すべきデータ(たとえば、コーディングされたビデオデータ)のタイプの表示を含むシンタックス構造である。NALユニットは、ビデオコーディングレイヤ(VCL)NALユニットおよび非VCL NALユニットに分類される。VCL NALユニットは、ビデオピクチャの中のサンプルの値を表すデータを含み、非VCL NALユニットは、パラメータセット(多数のVCL NALユニットに適用され得る重要なヘッダデータ)などの関連する任意の追加情報、および補足エンハンスメント情報(タイミング情報、および復号ビデオ信号の有用性を向上させ得るが、ビデオピクチャの中のサンプルの値を復号するために必要でない、他の追加データ)を含む。ビットストリーム750が、実際の適用例では他のパラメータおよび情報を含み得ることを、当業者は理解するであろう。
ビデオビットストリーム750は、CVS708に対応するGDRフラグを含む。一実施形態では、GDRフラグはSPS752の中で搬送される。しかしながら、GDRフラグは、実際の適用例ではビデオビットストリーム750の中の他の場所に配置されうる。一実施形態では、GDRフラグはgdr_enabled_flagと指定される。GDRフラグの値は、CVS708に対してGDRが有効化されているかどうかを示す。たとえば、GDRフラグの値が1であるとき、GDRは有効化されており、GDRフラグの値が0であるとき、GDRは有効化されていない。
図7の画像データ758は、符号化中または復号中の画像またはビデオに関連するデータを含む。画像データ758は、単に、ペイロード、またはビットストリーム750の中で搬送中のデータと呼ばれることがある。一実施形態では、画像データ758は、GDRピクチャ702、1つまたは複数のトレーリングピクチャ704、およびリカバリポイントピクチャ706を含む、CVS708を含む。一実施形態では、GDRピクチャ702、トレーリングピクチャ704、およびリカバリポイントピクチャ706は、CVS708の中のGDR期間を規定し得る。
図7に示すように、GDR技法700または原理は、GDRピクチャ702で開始しリカバリポイントピクチャ706で終了する一連のピクチャにわたって機能する。GDR技法700、GDRピクチャ702、トレーリングピクチャ704、およびリカバリポイントピクチャ706は、図5のGDR技法500、GDRピクチャ502、トレーリングピクチャ504、およびリカバリポイントピクチャ506と同様である。したがって、簡潔のために、GDR技法700が実施される方式は、図7に関して繰り返さない。
図7に示すように、CVS708の中のGDRピクチャ702、トレーリングピクチャ704、およびリカバリポイントピクチャ706は各々、それら自体のVCL NALユニット730内に含まれる。CVS708の中のVCL NALユニット730のセットは、アクセスユニットと呼ばれることがある。
CVS708の中のGDRピクチャ702を含むNALユニット730は、GDR NALユニットタイプ(GDR_NUT)を有する。すなわち、一実施形態では、CVS708の中のGDRピクチャ702を含むNALユニット730は、トレーリングピクチャ704およびリカバリポイントピクチャ706に対してそれ自体の固有のNALユニットタイプを有する。一実施形態では、GDR_NUTは、ビットストリームがIRAPピクチャで始まる必要があるのではなく、ビットストリームがGDRピクチャ702で始まることを可能にする。GDRピクチャ702のVCL NALユニット730をGDR_NUTとして指定することは、CVS708の中の初期VCL NALユニット730がGDRピクチャ702を含むことを、たとえば、デコーダに示してよい。
一実施形態では、GDRピクチャ702はCVS708の中の初めのピクチャである。一実施形態では、GDRピクチャ702はGDR期間の中の初めのピクチャである。一実施形態では、GDRピクチャ702は0に等しい時間識別子(ID)を有する。時間IDは、他のピクチャに対するピクチャの位置または順序を識別する値または数である。一実施形態では、GDR_NUTを有するVCL NALユニット730を含むアクセスユニットは、GDRアクセスユニットと指定される。一実施形態では、GDRピクチャ702は、別の(たとえば、より大きい)GDRピクチャのコーディングされたスライスである。すなわち、GDRピクチャ702は、より大きいGDRピクチャの一部分でありうる。
図8は、ビデオデコーダ(たとえば、ビデオデコーダ30)によって実施される、コーディングされたビデオビットストリームを復号する方法800の一実施形態である。方法800は、ビデオエンコーダ(たとえば、ビデオエンコーダ20)から復号ビットストリームが直接または間接的に受信された後に実行されてよい。方法800は、IRAPピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とするので、本方法は復号プロセスを改善する。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されてよく、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を許す。したがって、実際には、コーデックの性能が改善され、そのことはより良好なユーザエクスペリエンスにつながる。
ブロック802において、ビデオデコーダは、CVS(たとえば、CVS708)に対応するGDRフラグを含む、コーディングされたビデオビットストリームを受信する。一実施形態では、GDRフラグは、ビットストリーム(たとえば、ビットストリーム750)のシーケンスパラメータセット(たとえば、SPS752)の中に含まれる。一実施形態では、GDRフラグはgdr_enabled_flagと指定される。
ブロック804において、ビデオデコーダは、GDRピクチャ(たとえば、GDRピクチャ702)がCVSの中に存在するかどうかをGDRフラグの値に基づいて決定する。すなわち、GDRフラグは、GDRが有効化されているかどうかを示す。一実施形態では、GDRが有効化されているとき、GDRフラグの値は1である。
ブロック806において、ビデオデコーダは、GDRピクチャが存在することをGDRフラグの値が示すとき、GDRピクチャにおいてCVSの復号を開始する。ブロック808において、ビデオデコーダは、復号されたCVSに従って画像を生成する。画像は、次いで、電子デバイス(たとえば、スマートフォン、タブレット、ラップトップ、パーソナルコンピュータなど)のユーザのために表示され得る。
一実施形態では、方法800は、GDRが有効化されていないことをGDRフラグの値に基づいて決定し得る。一実施形態では、GDRが有効化されていないとき、GDRフラグの値は0である。
図9は、ビデオエンコーダ(たとえば、ビデオエンコーダ20)によって実施される、ビデオビットストリームを符号化する方法900の一実施形態である。(たとえば、ビデオからの)ピクチャがビデオビットストリームの中に符号化され、次いで、ビデオデコーダ(たとえば、ビデオデコーダ30)に向かって送信されることになるとき、方法900が実行され得る。方法900は、IRAPピクチャを使用する必要なく順次イントラリフレッシュがランダムアクセスを有効化することを可能とするので、本方法は符号化プロセスを改善する。IRAPピクチャではなくGDRピクチャを使用することによって、たとえば、IRAPピクチャのサイズに対するGDRピクチャのサイズに起因して、よりスムーズな、より一貫したビットレートが達成されえ、そのことは低減されたエンドツーエンド遅延(すなわち、レイテンシ)を可能にする。したがって、実際には、コーデックの性能が改善され、そのことはより良好なユーザエクスペリエンスにつながる。
ブロック902において、ビデオエンコーダは、ビデオビットストリームのCVSの中でGDRピクチャ(たとえば、GDRピクチャ702)を符号化する。ブロック904において、ビデオエンコーダは、GDRピクチャがビデオビットストリームのCVSの中に存在することを示すための第1の値にGDRフラグを設定する。一実施形態では、GDRピクチャが存在するとき、GDRフラグの値は1である。一実施形態では、GDRフラグは、ビットストリーム(たとえば、ビットストリーム750)のシーケンスパラメータセット(たとえば、SPS752)の中に符号化される。一実施形態では、GDRフラグはgdr_enabled_flagと称される。
ブロック904において、ビデオエンコーダは、GDRが有効化されているとき、GDRピクチャ(たとえば、GDRピクチャ702)をビデオビットストリームのCVSの中に符号化する。
ブロック906において、ビデオエンコーダは、ビデオデコーダに向かう送信のためにビットストリームを記憶する。ビデオビットストリームは、コーディングされたビデオビットストリームまたは符号化されたビデオビットストリームと呼ばれることもある。ビデオエンコーダは、ビデオデコーダに向かってビットストリームを送信することができる。ビデオデコーダによって受信されると、符号化されたビデオビットストリームは、電子デバイス(たとえば、スマートフォン、タブレット、ラップトップ、パーソナルコンピュータなど)のディスプレイまたはスクリーンにおけるユーザへの表示用に画像を生成または生じさせるために、(たとえば、上記で説明したように)復号され得る。
一実施形態では、方法900は、GDRが有効化されていないことをGDRフラグの値に基づいて決定し得る。一実施形態では、GDRが有効化されていないとき、GDRフラグの値は0である。
図10は、本開示の一実施形態によるビデオコーディングデバイス1000(たとえば、ビデオエンコーダ20またはビデオデコーダ30)の概略図である。ビデオコーディングデバイス1000は、本明細書で説明するような、開示する実施形態を実施するのに適している。ビデオコーディングデバイス1000は、データを受信するための入口ポート1010および受信器ユニット(Rx)1020、データを処理するためのプロセッサ、論理ユニット、または中央処理ユニット(CPU)1030、データを送信するための送信器ユニット(Tx)1040および出口ポート1050、ならびにデータを記憶するためのメモリ1060を備える。ビデオコーディングデバイス1000はまた、光信号または電気信号の出口または入口のために、入口ポート1010、受信器ユニット1020、送信器ユニット1040、および出口ポート1050に結合された、光電気(OE:optical-to-electrical)構成要素および電気光(EO:electrical-to-optical)構成要素を含み得る。
プロセッサ1030は、ハードウェアおよびソフトウェアによって実装される。プロセッサ1030は、1つまたは複数のCPUチップ、コア(たとえば、マルチコアプロセッサとして)、フィールドプログラマブルゲートアレイ(FPGA)、特定用途向け集積回路(ASIC)、およびデジタル信号プロセッサ(DSP)として実装されてよい。プロセッサ1030は、入口ポート1010、受信器ユニット1020、送信器ユニット1040、出口ポート1050、およびメモリ1060と通信している。プロセッサ1030はコーディングモジュール1070を備える。コーディングモジュール1070は、上記で説明した開示する実施形態を実施する。たとえば、コーディングモジュール1070は、様々なコーデック機能を実施、処理、準備、または提供する。したがって、コーディングモジュール1070を含むことは、ビデオコーディングデバイス1000の機能への大幅な改善をもたらし、異なる状態へのビデオコーディングデバイス1000の変換に影響を及ぼす。あるいは、コーディングモジュール1070は、メモリ1060の中に記憶されプロセッサ1030によって実行される命令として実装される。
ビデオコーディングデバイス1000はまた、ユーザとの間でデータを通信するための入力および/または出力(I/O)デバイス1080を含み得る。I/Oデバイス1080は、ビデオデータを表示するためのディスプレイ、オーディオデータを出力するためのスピーカーなどの、出力デバイスを含み得る。I/Oデバイス1080はまた、キーボード、マウス、トラックボールなどの入力デバイス、および/またはそのような出力デバイスと相互作用するための対応するインターフェースを含み得る。
メモリ1060は、プログラムが実行のために選択されるときにそのようなプログラムを記憶するために、またプログラム実行中に読み取られる命令およびデータを記憶するために、1つまたは複数のディスク、テープドライブ、およびソリッドステートドライブを備え、オーバーフローデータ記憶デバイスとして使用され得る。メモリ1060は、揮発性および/または不揮発性であってよく、読取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、3元連想メモリ(TCAM:ternary content-addressable memory)、および/またはスタティックランダムアクセスメモリ(SRAM)でありうる。
図11は、コーディングするための手段1100の一実施形態の概略図である。一実施形態では、コーディングするための手段1100は、ビデオコーディングデバイス1102(たとえば、ビデオエンコーダ20またはビデオデコーダ30)の中に実装される。ビデオコーディングデバイス1102は受信手段1101を含む。受信手段1101は、符号化すべきピクチャを受信するか、または復号すべきビットストリームを受信するように構成される。ビデオコーディングデバイス1102は、受信手段1101に結合された送信手段1107を含む。送信手段1107は、ビットストリームをデコーダへ送信するか、または復号画像を表示手段(たとえば、I/Oデバイス1080のうちの1つ)へ送信するように構成される。
ビデオコーディングデバイス1102は記憶手段1103を含む。記憶手段1103は、受信手段1101または送信手段1107のうちの少なくとも1つに結合される。記憶手段1103は、命令を記憶するように構成される。ビデオコーディングデバイス1102はまた、処理手段1105を含む。処理手段1105は、記憶手段1103に結合される。処理手段1105は、本明細書で開示する方法を行うために、記憶手段1103の中に記憶された命令を実行するように構成される。
本明細書に記載する例示的な方法のステップが、必ずしも説明した順序で実行されることを必要とされるとは限らないことも理解されたく、そのような方法のステップの順序は、単に例であるものと理解されたい。同様に、そのような方法の中に追加のステップが含まれてよく、いくつかのステップは、本開示の様々な実施形態に一致する方法の中で省略されてよく組み合わせられてよい。
本開示ではいくつかの実施形態が提供されているが、開示するシステムおよび方法が、本開示の趣旨または範囲から逸脱することなく、多くの他の特定の形態で具現され得ることを理解されたい。本例は限定的ではなく例示的と考えられるべきであり、その意図は本明細書において与えられる詳細に限定されない。たとえば、様々な要素または構成要素が別のシステムの中で組み合わせられてよく、もしくは統合されてよく、またはいくつかの特徴が省略されてよく、もしくは実施されなくてよい。
加えて、様々な実施形態において個別または別個として説明および図示される技法、システム、サブシステム、および方法は、本開示の範囲から逸脱することなく、他のシステム、モジュール、技法、または方法と組み合わせられてよく、または統合されてよい。結合されるかもしくは直接結合されるか、または互いに通信するものとして、図示または説明される他の項目は、電気的か、機械的か、または別の方法であるかにかかわらず、いくつかのインターフェース、デバイス、または中間構成要素を通じて、間接的に結合されてよく、または通信していてよい。変更、置換、および改変の他の例は、当業者によって確認可能であり、本明細書で開示する趣旨および範囲から逸脱することなく行うことができる。
10 コーディングシステム
12 ソースデバイス
14 宛先デバイス
16 コンピュータ可読媒体
18 ビデオソース
20 ビデオエンコーダ
22 出力インターフェース
28 入力インターフェース
30 ビデオデコーダ
32 ディスプレイデバイス
40 モード選択ユニット
42 動き推定ユニット
44 動き補償ユニット
46 イントラ予測ユニット
48 区分ユニット
50 加算器
52 変換処理ユニット
54 量子化ユニット
56 エントロピーコーディングユニット
58 逆量子化ユニット
60 逆変換ユニット
62 加算器
64 参照フレームメモリ
70 エントロピー復号ユニット
72 動き補償ユニット
74 イントラ予測ユニット
76 逆量子化ユニット
78 逆変換ユニット
80 加算器
82 参照フレームメモリ
402 IRAPピクチャ
404 リーディングピクチャ
406 トレーリングピクチャ
408 復号順序
410 提示順序
502 GDRピクチャ
504 トレーリングピクチャ
506 リカバリポイントピクチャ
508 コーディングされたビデオシーケンス
510 リフレッシュ済みの/クリーンな領域
512 リフレッシュされていない/ダーティな領域
602 現在ピクチャ
604 参照ピクチャ
604 リフレッシュ済みの領域
606 リフレッシュ済みの領域
608 リフレッシュされていない領域
610 動きベクトル
612 参照ブロック
614 現在ブロック
702 GDRピクチャ
704 トレーリングピクチャ
706 リカバリポイントピクチャ
708 CVS
730 NALユニット
750 ビデオビットストリーム
752 シーケンスパラメータセット(SPS)
754 ピクチャパラメータセット(PPS)
756 スライスヘッダ
758 画像データ
760 ピクチャ
1000 ビデオコーディングデバイス
1010 入口ポート
1020 受信器ユニット(Rx)
1030 プロセッサ
1040 送信器ユニット(Tx)
1050 出口ポート
1060 メモリ
1070 コーディングモジュール
1080 I/Oデバイス
1100 コーディングするための手段
1101 受信手段
1102 ビデオコーディングデバイス
1103 記憶手段
1105 処理手段
1107 送信手段

Claims (20)

  1. ビデオデコーダによって実施される、コーディングされたビデオビットストリームを復号する方法であって、
    前記ビデオデコーダが、前記コーディングされたビデオビットストリームを受信するステップであって、前記コーディングされたビデオビットストリームは、コーディングされたビデオシーケンス(CVS)に対応する漸次復号リフレッシュ(GDR)フラグを含む、ステップと、
    前記ビデオデコーダが、前記CVSの中にGDRピクチャが存在するかどうかを前記GDRフラグの値に基づいて決定するステップと、
    前記GDRピクチャが存在することを前記GDRフラグの前記値が示すとき、前記ビデオデコーダが、前記GDRピクチャにおいて前記CVSの復号を開始するステップと、
    前記ビデオデコーダが、復号された前記CVSに従って画像を生成するステップと
    を含む、方法。
  2. 前記GDRフラグは、前記ビットストリームのシーケンスパラメータセットの中に含まれる、請求項1に記載の方法。
  3. 前記GDRフラグはgdr_enabled_flagと指定される、請求項1または2に記載の方法。
  4. 前記GDRが有効化されているとき、前記GDRフラグの前記値は1である、請求項1から3のいずれか一項に記載の方法。
  5. 前記GDRピクチャが前記ビデオビットストリームの前記CVSの中に存在しないとき、前記GDRフラグは第2の値に設定されるように構成される、請求項1から4のいずれか一項に記載の方法。
  6. 前記GDRフラグの前記第2の値は0である、請求項5に記載の方法。
  7. ビデオエンコーダによって実施される、ビデオビットストリームを符号化する方法であって、
    ビデオエンコーダが、前記ビデオビットストリームのコーディングされたビデオシーケンス(CVS)の中に漸次デコーダリフレッシュ(GDR)ピクチャを符号化するステップと、
    前記ビデオエンコーダが、GDRフラグを前記GDRピクチャが前記ビデオビットストリームの前記CVSの中に存在することを示すための第1の値に設定するステップと、
    前記ビデオエンコーダが、ビデオデコーダに向かう送信のために前記ビデオビットストリームを記憶するステップと
    を含む、方法。
  8. 前記GDRフラグは、前記ビデオビットストリームのシーケンスパラメータセットの中に符号化される、請求項7に記載の方法。
  9. 前記GDRフラグはgdr_enabled_flagと指定される、請求項7または8に記載の方法。
  10. 前記GDRが有効化されているとき、前記GDRフラグの前記第1の値は1である、請求項7から9のいずれか一項に記載の方法。
  11. 前記GDRピクチャが前記ビデオビットストリームの前記CVSの中に存在しないとき、前記GDRフラグは第2の値に設定されるように構成される、請求項7から10のいずれか一項に記載の方法。
  12. 前記GDRフラグの前記第2の値は0である、請求項7から11のいずれか一項に記載の方法。
  13. 復号デバイスであって、
    コーディングされたビデオビットストリームを受信するように構成された受信器と、
    前記受信器に結合されたメモリであって、命令を記憶する、メモリと、
    前記メモリに結合されたプロセッサとを備え、前記プロセッサは、前記復号デバイスに、
    前記コーディングされたビデオビットストリームを受信することであって、前記コーディングされたビデオビットストリームは、コーディングされたビデオシーケンス(CVS)に対応する漸次復号リフレッシュ(GDR)フラグを含む、ことと、
    GDRピクチャが前記CVSの中に存在するかどうかを前記GDRフラグの値に基づいて決定することと、
    前記GDRピクチャが存在することを前記GDRフラグの前記値が示すとき、前記GDRピクチャにおいて前記CVSの復号を開始することと、
    復号された前記CVSに従って画像を生成することと
    をさせるために、前記命令を実行するように構成される、
    復号デバイス。
  14. 生成された前記画像を表示するように構成されたディスプレイをさらに備える、請求項13に記載の復号デバイス。
  15. 符号化デバイスであって、
    命令を含むメモリと、
    前記メモリに結合されたプロセッサであって、前記符号化デバイスに、
    前記ビデオビットストリームのコーディングされたビデオシーケンス(CVS)の中で漸次デコーダリフレッシュ(GDR)ピクチャを符号化することと、
    前記GDRピクチャが前記ビデオビットストリームの前記CVSの中に存在することを示すための第1の値にGDRフラグを設定することと
    をさせるために、前記命令を実施するように構成された、プロセッサと、
    前記プロセッサに結合された送信器であって、ビデオデコーダに向かって前記ビデオビットストリームを送信するように構成された、送信器と
    を備える、符号化デバイス。
  16. 前記メモリは、前記送信器が前記ビデオデコーダに向かって前記CVSを送信する前に前記ビデオビットストリームを記憶する、請求項15に記載の符号化デバイス。
  17. 符号化すべきピクチャを受信するか、または復号すべきビットストリームを受信するように構成された、受信器と、
    前記受信器に結合された送信器であって、前記ビットストリームをデコーダへ送信するか、または復号画像をディスプレイへ送信するように構成された、送信器と、
    前記受信器または前記送信器のうちの少なくとも1つに結合されたメモリであって、命令を記憶するように構成された、メモリと、
    前記メモリに結合されたプロセッサであって、請求項1から6のいずれか一項および請求項7から12のいずれか一項に記載の方法を行うために、前記メモリの中に記憶された前記命令を実行するように構成された、プロセッサと
    を備える、コーディング装置。
  18. 画像を表示するように構成されたディスプレイをさらに備える、請求項17に記載のコーディング装置。
  19. エンコーダと、
    前記エンコーダと通信しているデコーダとを備え、前記エンコーダまたは前記デコーダは、請求項13から18のいずれか一項に記載の復号デバイス、符号化デバイス、またはコーディング装置を含む、
    システム。
  20. 符号化すべきピクチャを受信するか、または復号すべきビットストリームを受信するように構成された、受信手段と、
    前記受信手段に結合された送信手段であって、前記ビットストリームを復号手段へ送信するか、または復号画像を表示手段へ送信するように構成された、送信手段と、
    前記受信手段または前記送信手段のうちの少なくとも1つに結合された記憶手段であって、命令を記憶するように構成された、記憶手段と、
    前記記憶手段に結合された処理手段であって、請求項1から6のいずれか一項および請求項7から12のいずれか一項に記載の方法を行うために、前記記憶手段の中に記憶された前記命令を実行するように構成された、処理手段と
    を備える、コーディングするための手段。
JP2021554984A 2019-03-11 2020-03-11 エンコーダ、デコーダ、および対応する方法 Active JP7399977B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023184082A JP2024008969A (ja) 2019-03-11 2023-10-26 エンコーダ、デコーダ、および対応する方法

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201962816722P 2019-03-11 2019-03-11
US62/816,722 2019-03-11
US201962871020P 2019-07-05 2019-07-05
US62/871,020 2019-07-05
PCT/US2020/022180 WO2020185957A1 (en) 2019-03-11 2020-03-11 Gradual decoding refresh in video coding

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2023184082A Division JP2024008969A (ja) 2019-03-11 2023-10-26 エンコーダ、デコーダ、および対応する方法

Publications (2)

Publication Number Publication Date
JP2022524618A true JP2022524618A (ja) 2022-05-09
JP7399977B2 JP7399977B2 (ja) 2023-12-18

Family

ID=72426295

Family Applications (8)

Application Number Title Priority Date Filing Date
JP2021554984A Active JP7399977B2 (ja) 2019-03-11 2020-03-11 エンコーダ、デコーダ、および対応する方法
JP2021554982A Active JP7337948B2 (ja) 2019-03-11 2020-03-11 エンコーダ、デコーダ、および対応する方法
JP2021555265A Active JP7302000B2 (ja) 2019-03-11 2020-03-11 エンコーダ、デコーダ、および対応する方法
JP2021554681A Active JP7364685B2 (ja) 2019-03-11 2020-03-11 エンコーダ、デコーダおよび対応する方法
JP2023101903A Pending JP2023130378A (ja) 2019-03-11 2023-06-21 エンコーダ、デコーダ、および対応する方法
JP2023135533A Pending JP2023160851A (ja) 2019-03-11 2023-08-23 エンコーダ、デコーダ、および対応する方法
JP2023173335A Pending JP2023181208A (ja) 2019-03-11 2023-10-05 エンコーダ、デコーダおよび対応する方法
JP2023184082A Pending JP2024008969A (ja) 2019-03-11 2023-10-26 エンコーダ、デコーダ、および対応する方法

Family Applications After (7)

Application Number Title Priority Date Filing Date
JP2021554982A Active JP7337948B2 (ja) 2019-03-11 2020-03-11 エンコーダ、デコーダ、および対応する方法
JP2021555265A Active JP7302000B2 (ja) 2019-03-11 2020-03-11 エンコーダ、デコーダ、および対応する方法
JP2021554681A Active JP7364685B2 (ja) 2019-03-11 2020-03-11 エンコーダ、デコーダおよび対応する方法
JP2023101903A Pending JP2023130378A (ja) 2019-03-11 2023-06-21 エンコーダ、デコーダ、および対応する方法
JP2023135533A Pending JP2023160851A (ja) 2019-03-11 2023-08-23 エンコーダ、デコーダ、および対応する方法
JP2023173335A Pending JP2023181208A (ja) 2019-03-11 2023-10-05 エンコーダ、デコーダおよび対応する方法
JP2023184082A Pending JP2024008969A (ja) 2019-03-11 2023-10-26 エンコーダ、デコーダ、および対応する方法

Country Status (8)

Country Link
US (7) US11632545B2 (ja)
EP (5) EP4432649A2 (ja)
JP (8) JP7399977B2 (ja)
KR (4) KR20210132197A (ja)
CN (4) CN113924781A (ja)
BR (1) BR112021017985A2 (ja)
MX (4) MX2021011012A (ja)
WO (4) WO2020185957A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022526088A (ja) * 2019-03-11 2022-05-23 ホアウェイ・テクノロジーズ・カンパニー・リミテッド エンコーダ、デコーダ、および対応する方法

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112534810A (zh) * 2018-08-06 2021-03-19 夏普株式会社 运动图像解码装置以及运动图像编码装置
BR112021002832A2 (pt) * 2018-08-17 2021-05-04 Huawei Technologies Co., Ltd. gerenciamento de imagem de referência em codificação de vídeo
CN113924784B (zh) * 2019-03-12 2024-06-11 现代自动车株式会社 用于编码和解码影像的方法
GB2617304B (en) * 2019-03-20 2024-04-03 V Nova Int Ltd Residual filtering in signal enhancement coding
ES2953120T3 (es) * 2019-04-23 2023-11-08 Guangdong Oppo Mobile Telecommunications Corp Ltd Método de decodificación de imágenes, decodificador y medio de almacenamiento
CN114930825A (zh) 2019-12-26 2022-08-19 字节跳动有限公司 用于在编解码图片中实现解码顺序的技术
US11758171B2 (en) 2019-12-27 2023-09-12 Alibaba Group Holding Limited Methods and systems for performing gradual decoding refresh processing on pictures
JP7460790B2 (ja) * 2020-03-19 2024-04-02 バイトダンス インコーポレイテッド 参照ピクチャ順序の制約
US11533499B2 (en) * 2020-03-31 2022-12-20 Tencent America LLC Method for signaling mixed NAL unit type and subpicture partitioning in coded video stream
US11496730B2 (en) * 2020-04-03 2022-11-08 Electronics And Telecommunications Research Institute Method, apparatus and storage medium for image encoding/decoding using subpicture
WO2022174431A1 (zh) * 2021-02-20 2022-08-25 深圳市大疆创新科技有限公司 图像传输方法、可移动平台、设备及计算机可读存储介质
CN114630122B (zh) 2021-03-19 2023-04-28 杭州海康威视数字技术股份有限公司 基于自适应帧内刷新机制的解码、编码方法及相关设备
EP4415099A1 (en) 2021-10-06 2024-08-14 Soulbrain Co., Ltd. Electrolyte and secondary battery comprising same

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014051915A1 (en) * 2012-09-28 2014-04-03 Qualcomm Incorporated Signaling of regions of interest and gradual decoding refresh in video coding
WO2014107723A1 (en) * 2013-01-07 2014-07-10 Qualcomm Incorporated Gradual decoding refresh with temporal scalability support in video coding

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8300690B2 (en) 2002-07-16 2012-10-30 Nokia Corporation Method for random access and gradual picture refresh in video coding
US20040260827A1 (en) * 2003-06-19 2004-12-23 Nokia Corporation Stream switching based on gradual decoder refresh
EP2119187B1 (en) * 2007-02-23 2017-07-19 Nokia Technologies Oy Backward-compatible characterization of aggregated media data units
TW201032597A (en) * 2009-01-28 2010-09-01 Nokia Corp Method and apparatus for video coding and decoding
TW201210325A (en) * 2010-07-21 2012-03-01 Nokia Corp Method and apparatus for indicating switching points in a streaming session
US9237356B2 (en) * 2011-09-23 2016-01-12 Qualcomm Incorporated Reference picture list construction for video coding
US9264717B2 (en) * 2011-10-31 2016-02-16 Qualcomm Incorporated Random access with advanced decoded picture buffer (DPB) management in video coding
US9124895B2 (en) * 2011-11-04 2015-09-01 Qualcomm Incorporated Video coding with network abstraction layer units that include multiple encoded picture partitions
US9736476B2 (en) * 2012-04-27 2017-08-15 Qualcomm Incorporated Full random access from clean random access pictures in video coding
AU2013282644B2 (en) 2012-06-25 2016-05-12 Nec Corporation Video encoding/decoding device, method, and program
US9225978B2 (en) * 2012-06-28 2015-12-29 Qualcomm Incorporated Streaming adaption based on clean random access (CRA) pictures
US9648322B2 (en) * 2012-07-10 2017-05-09 Qualcomm Incorporated Coding random access pictures for video coding
US10003815B2 (en) * 2013-06-03 2018-06-19 Qualcomm Incorporated Hypothetical reference decoder model and conformance for cross-layer random access skipped pictures
EP3039861A1 (en) * 2013-08-28 2016-07-06 Cisco Technology, Inc. Support for trick modes in hevc streams
WO2015047162A1 (en) * 2013-09-26 2015-04-02 Telefonaktiebolaget L M Ericsson (Publ) Hybrid codec scalable video
CN106416250B (zh) * 2013-12-02 2020-12-04 诺基亚技术有限公司 视频编码和解码
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
US10136152B2 (en) * 2014-03-24 2018-11-20 Qualcomm Incorporated Use of specific HEVC SEI messages for multi-layer video codecs
JP6398569B2 (ja) * 2014-10-07 2018-10-03 株式会社ソシオネクスト 画像符号化装置、画像符号化方法および画像符号化プログラム
WO2017052626A1 (en) * 2015-09-25 2017-03-30 Intel Corporation Power gate with metal on both sides
US20170111642A1 (en) * 2015-10-14 2017-04-20 Qualcomm Incorporated Support of random access and switching of layers and sub-layers in multi-layer video files
US10638147B2 (en) * 2018-06-01 2020-04-28 Apple Inc. Gradual decoder refresh techniques with management of reference pictures
US10972755B2 (en) * 2018-12-03 2021-04-06 Mediatek Singapore Pte. Ltd. Method and system of NAL unit header structure for signaling new elements
US11956471B2 (en) * 2018-12-20 2024-04-09 Telefonaktiebolaget Lm Ericsson (Publ) Normative indication of recovery point
JP7399977B2 (ja) * 2019-03-11 2023-12-18 ホアウェイ・テクノロジーズ・カンパニー・リミテッド エンコーダ、デコーダ、および対応する方法
EP3939305A4 (en) * 2019-03-11 2022-12-21 Telefonaktiebolaget Lm Ericsson (Publ) PROCEDURE FOR RECOVERY POINT PROCESS FOR VIDEO ENCODER AND ASSOCIATED DEVICE
US11228777B2 (en) * 2019-12-30 2022-01-18 Tencent America LLC Method for layerwise random access in a coded video stream
KR20220141794A (ko) * 2020-03-05 2022-10-20 엘지전자 주식회사 혼성 nal 유닛 타입에 기반하는 영상 부호화/복호화 방법, 장치 및 비트스트림을 전송하는 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2014051915A1 (en) * 2012-09-28 2014-04-03 Qualcomm Incorporated Signaling of regions of interest and gradual decoding refresh in video coding
WO2014107723A1 (en) * 2013-01-07 2014-07-10 Qualcomm Incorporated Gradual decoding refresh with temporal scalability support in video coding

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
HENDRY, YE-KUI WANG, JIANLE CHEN, AND SEUNGWOOK HONG: "AHG14/AHG17: GDR - Gradual decoding refresh", JOINT VIDEO EXPERTS TEAM (JVET) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JVET-N0115-v1, JPN6022053365, March 2019 (2019-03-01), pages 1 - 5, ISSN: 0004946547 *
JEAN-MARC THIESSE, AND DIDIER NICHOLSON: "Improved Cyclic Intra Refresh", JOINT VIDEO EXPERTS TEAM (JVET) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JVET-K0212-v2, JPN6022053366, July 2018 (2018-07-01), pages 1 - 8, ISSN: 0004946545 *
JEAN-MARC THIESSE, DIDIER NICHOLSON, AND DAVID GOMMELET: "AHG14: Updates on Intra Refresh Proposal", JOINT VIDEO EXPERTS TEAM (JVET) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JVET-M0387-v2, JPN6022053364, January 2019 (2019-01-01), pages 1 - 13, ISSN: 0004946546 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022526088A (ja) * 2019-03-11 2022-05-23 ホアウェイ・テクノロジーズ・カンパニー・リミテッド エンコーダ、デコーダ、および対応する方法
JP7302000B2 (ja) 2019-03-11 2023-07-03 ホアウェイ・テクノロジーズ・カンパニー・リミテッド エンコーダ、デコーダ、および対応する方法
US11917134B2 (en) 2019-03-11 2024-02-27 Huawei Technologies Co., Ltd. Gradual decoding refresh in video coding

Also Published As

Publication number Publication date
EP3928508A4 (en) 2022-08-17
JP7399977B2 (ja) 2023-12-18
JP2022524617A (ja) 2022-05-09
CN113557722A (zh) 2021-10-26
JP7364685B2 (ja) 2023-10-18
WO2020185959A1 (en) 2020-09-17
US20230156184A1 (en) 2023-05-18
JP7302000B2 (ja) 2023-07-03
CN113924781A (zh) 2022-01-11
EP3928508A1 (en) 2021-12-29
JP7337948B2 (ja) 2023-09-04
WO2020185956A1 (en) 2020-09-17
JP2022524810A (ja) 2022-05-10
CN113615175A (zh) 2021-11-05
US11917134B2 (en) 2024-02-27
BR112021017985A2 (pt) 2021-11-16
US20240163425A1 (en) 2024-05-16
US11973939B2 (en) 2024-04-30
US20210409690A1 (en) 2021-12-30
US20210409691A1 (en) 2021-12-30
JP2024008969A (ja) 2024-01-19
US20220014755A1 (en) 2022-01-13
EP3928520A4 (en) 2022-08-17
MX2021011038A (es) 2021-10-13
MX2021011012A (es) 2021-11-12
JP2022526088A (ja) 2022-05-23
US11632545B2 (en) 2023-04-18
KR20210132197A (ko) 2021-11-03
MX2021011014A (es) 2021-11-12
EP3928511A4 (en) 2022-06-22
JP2023181208A (ja) 2023-12-21
EP3928511A1 (en) 2021-12-29
EP3928512A4 (en) 2022-06-22
WO2020185957A1 (en) 2020-09-17
US11856189B2 (en) 2023-12-26
KR20210134036A (ko) 2021-11-08
MX2021011013A (es) 2021-11-12
CN113557733A (zh) 2021-10-26
EP4432649A2 (en) 2024-09-18
US20240244189A1 (en) 2024-07-18
WO2020185962A1 (en) 2020-09-17
JP2023130378A (ja) 2023-09-20
EP3928520A1 (en) 2021-12-29
KR20210134390A (ko) 2021-11-09
US20210409689A1 (en) 2021-12-30
KR20210134774A (ko) 2021-11-10
JP2023160851A (ja) 2023-11-02
EP3928512A1 (en) 2021-12-29

Similar Documents

Publication Publication Date Title
JP7399977B2 (ja) エンコーダ、デコーダ、および対応する方法
US11895312B2 (en) Output of prior pictures for pictures starting a new coded video sequence in video coding

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211109

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211109

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20221212

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221219

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230320

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20230626

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231026

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20231106

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20231120

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20231206

R150 Certificate of patent or registration of utility model

Ref document number: 7399977

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150