ES2965445T3 - Restricciones de imagen del tipo de unidad NAL mixta - Google Patents
Restricciones de imagen del tipo de unidad NAL mixta Download PDFInfo
- Publication number
- ES2965445T3 ES2965445T3 ES20771048T ES20771048T ES2965445T3 ES 2965445 T3 ES2965445 T3 ES 2965445T3 ES 20771048 T ES20771048 T ES 20771048T ES 20771048 T ES20771048 T ES 20771048T ES 2965445 T3 ES2965445 T3 ES 2965445T3
- Authority
- ES
- Spain
- Prior art keywords
- image
- nal
- images
- irap
- video
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 claims description 108
- 108091000069 Cystinyl Aminopeptidase Proteins 0.000 claims description 11
- 102100020872 Leucyl-cystinyl aminopeptidase Human genes 0.000 claims description 11
- 238000004891 communication Methods 0.000 claims description 11
- FMYKJLXRRQTBOR-UBFHEZILSA-N (2s)-2-acetamido-4-methyl-n-[4-methyl-1-oxo-1-[[(2s)-1-oxohexan-2-yl]amino]pentan-2-yl]pentanamide Chemical compound CCCC[C@@H](C=O)NC(=O)C(CC(C)C)NC(=O)[C@H](CC(C)C)NC(C)=O FMYKJLXRRQTBOR-UBFHEZILSA-N 0.000 claims description 6
- 230000007246 mechanism Effects 0.000 abstract description 32
- 230000033001 locomotion Effects 0.000 description 87
- 230000008569 process Effects 0.000 description 47
- 230000009466 transformation Effects 0.000 description 45
- 208000037170 Delayed Emergence from Anesthesia Diseases 0.000 description 31
- 238000013139 quantization Methods 0.000 description 26
- 239000013598 vector Substances 0.000 description 24
- 238000007906 compression Methods 0.000 description 20
- 230000006835 compression Effects 0.000 description 19
- 238000010586 diagram Methods 0.000 description 16
- 238000013459 approach Methods 0.000 description 14
- 230000002123 temporal effect Effects 0.000 description 13
- 238000009795 derivation Methods 0.000 description 12
- 241000023320 Luma <angiosperm> Species 0.000 description 11
- OSWPMRLSEDHDFF-UHFFFAOYSA-N methyl salicylate Chemical compound COC(=O)C1=CC=CC=C1O OSWPMRLSEDHDFF-UHFFFAOYSA-N 0.000 description 11
- 238000004458 analytical method Methods 0.000 description 10
- 230000005540 biological transmission Effects 0.000 description 10
- 238000000605 extraction Methods 0.000 description 10
- 230000003044 adaptive effect Effects 0.000 description 8
- 238000001914 filtration Methods 0.000 description 8
- 238000012545 processing Methods 0.000 description 8
- 101150114515 CTBS gene Proteins 0.000 description 7
- 230000008901 benefit Effects 0.000 description 7
- 230000001419 dependent effect Effects 0.000 description 7
- 230000007774 longterm Effects 0.000 description 7
- 238000007726 management method Methods 0.000 description 7
- 230000008859 change Effects 0.000 description 6
- 238000011017 operating method Methods 0.000 description 6
- 230000011664 signaling Effects 0.000 description 6
- 238000000844 transformation Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 238000013461 design Methods 0.000 description 4
- 238000011144 upstream manufacturing Methods 0.000 description 4
- 230000003139 buffering effect Effects 0.000 description 3
- 238000006073 displacement reaction Methods 0.000 description 3
- 230000004886 head movement Effects 0.000 description 3
- 239000000203 mixture Substances 0.000 description 3
- 238000005457 optimization Methods 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 230000001629 suppression Effects 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 2
- 230000006837 decompression Effects 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 230000002542 deteriorative effect Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000009499 grossing Methods 0.000 description 2
- 230000003116 impacting effect Effects 0.000 description 2
- 239000011159 matrix material Substances 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 101100510671 Rattus norvegicus Lnpep gene Proteins 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 230000004927 fusion Effects 0.000 description 1
- 238000007499 fusion processing Methods 0.000 description 1
- 235000019580 granularity Nutrition 0.000 description 1
- 238000005286 illumination Methods 0.000 description 1
- 238000012804 iterative process Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 238000004513 sizing Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000000638 solvent extraction Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
- H04N19/103—Selection of coding mode or of prediction mode
- H04N19/105—Selection of the reference unit for prediction within a chosen coding or prediction mode, e.g. adaptive choice of position and number of pixels used for prediction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
- H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
- H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
- H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
- H04N19/188—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a video data packet, e.g. a network abstraction layer [NAL] unit
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/189—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding
- H04N19/196—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding being specially adapted for the computation of encoding parameters, e.g. by averaging previously computed encoding parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/42—Methods 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/43—Hardware specially adapted for motion estimation or compensation
- H04N19/433—Hardware specially adapted for motion estimation or compensation characterised by techniques for memory access
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
- H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/90—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
- H04N19/91—Entropy coding, e.g. variable length coding [VLC] or arithmetic coding
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
Abstract
Se divulga un mecanismo de codificación de vídeo. El mecanismo incluye recibir un flujo de bits que comprende una bandera y una pluralidad de subimágenes asociadas con una imagen. La pluralidad de subimágenes está contenida en una pluralidad de unidades de capa de abstracción de red (NAL) de capa de codificación de vídeo (VCL). El mecanismo determina que las unidades VCL NAL de una o más de las subimágenes de la imagen tienen todas un primer valor particular de tipo de unidad NAL y otras unidades VCL NAL en la imagen tienen todas un segundo valor particular diferente de tipo de unidad NAL basado en un valor de la bandera. Una o más de las subimágenes se decodifican basándose en el primer valor particular del tipo de unidad NAL y el segundo valor particular del tipo de unidad NAL. Una o más de las subimágenes se reenvían para su visualización como parte de una secuencia de vídeo decodificada. (Traducción automática con Google Translate, sin valor legal)
Description
DESCRIPCIÓN
Restricciones de imagen del tipo de unidad NAL mixta
Referencia cruzada a solicitudes relacionadas
Esta solicitud de patente reivindica el beneficio de la Solicitud de Patente Provisional de EE. UU., No.
62/816,749, presentada el 11 de Marzo de 2019 por Ye-Kui Wang, y colaboradores, y titulada “Support Of Mixed NAL Unit Types Within One Picture In Video Coding”, (“Soporte de Tipos de Unidad NAL Mixta Dentro de una Imagen en Codificación de Video”), y la solicitud de Patente Provisional de EE. UU., No. 62/832,132, presentada el 10 de Abril de 2019 por Ye-Kui Wang, y colaboradores, y titulada “Support Of Mixed NAL Unit Types Within One Picture In Video Coding”, (“Soporte de Tipos de Unidad NAL Mixta Dentro de una Imagen en Codificación de Video”).
Campo técnico
La presente descripción está relacionada en general con una codificación de video, y se relaciona específicamente con la codificación de sub-imágenes de imágenes en codificación de video.
Antecedentes
La cantidad de datos de video necesarios para representar incluso un video relativamente corto puede ser sustancial, lo cual puede dar como resultado dificultades cuando los datos se han de transmitir o comunicar de otra manera a través de una red de comunicaciones con capacidad de ancho de banda limitada. Así, los datos de video se comprimen en general antes de ser comunicados a través de las redes de telecomunicaciones de hoy en día por modem. El tamaño de un video también podría ser un problema cuando el video se almacena en un dispositivo de almacenamiento, debido a que los recursos de memoria son muy limitados. Los dispositivos de compresión de video utilizan frecuentemente software y/o hardware en la fuente para codificar los datos de video antes de la transmisión o almacenamiento, reduciendo de esta manera la cantidad de datos necesarios para representar las imágenes de video digitales. Los datos comprimidos son luego recibidos en el destino por un dispositivo de descompresión de video que decodifica los datos de video. Con recursos de red limitados y demandas de una mayor calidad de video, son deseables técnicas mejoradas de compresión y descompresión que mejoren la relación de compresión con poco o ningún sacrificio en la calidad de la imagen. HANNUKSELA (NOKIA) M M: “AHG12/AHG17: On merging of MCTSs for viewport-dependent streaming (“Al fusionarse los MCTS para transmisión en directo dependiente de la ventana gráfica”)” propone que se permitan sub-imágenes de la misma imagen codificada que tengan diferentes valores nal_unit_type de modo que el diseño de VVC pueda ser habilitado para unir los MCTS que se originan a partir de una imagen de acceso aleatorio y los MCTS que se originan a partir de una imagen de acceso no aleatorio en la misma imagen codificada sin dificultad sustancial. HANNUKSELA (NOKIA) M M ET AL: “AHG12: On grouping of tiles (“Al agrupar mosaicos”)” describe dividir y decodificar una imagen basada en sub-imágenes, y las sub-imágenes son tratadas como imágenes en el proceso de decodificación. Y describe además un indicador habilitado de multiple_subpics para indicar que una imagen contiene exactamente una sub-imagen, o que una imagen puede contener más de una sub-imagen.
Compendio
En una realización, la descripción incluye un método según la reivindicación 1 implementado en un decodificador.
Una imagen se puede dividir en múltiples sub-imágenes. Dichas sub-imágenes se pueden codificar en sub flujos de bits separados, que luego se pueden fusionar en un flujo de bits para transmisión a un decodificador. Por ejemplo, las sub-imágenes se pueden emplear para aplicaciones de realidad virtual (VR). Como un ejemplo específico, un usuario solo puede ver una porción de una imagen de VR en cualquier momento. Por consiguiente, se pueden transmitir diferentes sub-imágenes en diferentes resoluciones de modo que se puede asignar más ancho de banda a las sub-imágenes que es probable que se muestren y las sub-imágenes que es improbable que se muestren se pueden comprimir para incrementar la eficiencia de codificación. Además, los flujos de video se pueden codificar utilizando imágenes de punto de acceso intraaleatorio (IRAP). Una imagen IRAP se codifica de acuerdo con la intra-predicción y se pueden decodificar sin referencia a otras imágenes. Las imágenes no IRAP se pueden codificar de acuerdo con la inter-predicción y se pueden decodificar por referencia a otras imágenes. Las imágenes no IRAP son significativamente más condensadas que las imágenes IRAP. Sin embargo, una secuencia de video debe comenzar a decodificarse con una imagen IRAP ya que la imagen IRAP contiene suficientes datos que se han de decodificar sin referencia a otras imágenes. Las imágenes IRAP se pueden utilizar en sub-imágenes, y pueden permitir cambios de resolución dinámicos. Por consiguiente, un sistema de video puede transmitir más imágenes IRAP para sub-imágenes que es más probable que se vean (por ejemplo, con base en la ventana gráfica actual de los usuarios) y pocas imágenes IRAP para sub-imágenes que es improbable que se vean a fin de incrementar adicionalmente la eficiencia de la codificación. Sin embargo, las sub-imágenes son parte de la misma imagen. Por consiguiente, este esquema puede dar como resultado una imagen que contiene tanto una sub-imagen IRAP como una sub-imagen no IRAP. Algunos sistemas de video no están equipados para manejar una imagen mixta tanto con regiones IRAP como no IRAP. La presente descripción incluye un indicador que indica si una imagen es mixta y por consiguiente contiene tanto componentes IRAP como no IRAP. Además, el indicador restringe la imagen de tal modo que la imagen mixta contiene exactamente dos tipos de unidad NAL que incluyen un tipo IRAP y un tipo no IRAP. Basándose en este indicador, el decodificador puede tratar diferentes sub-imágenes de manera diferente cuando se decodifican a fin de decodificar y mostrar apropiadamente la imagen/sub-imágenes. Este indicador se puede almacenar en un PPS y puede ser denominado como un mixed_nalu_types_in_pic_flag. Como tal, los mecanismos descritos permiten la implementación de una funcionalidad adicional. Además, los mecanismos descritos permiten cambios de resolución dinámicos cuando se emplean flujos de bits de sub-imágenes. Por consiguiente, los mecanismos descritos permiten que los flujos de bits de sub-imágenes de resolución más baja sean transmitidos cuando se transmite el video de VR sin deteriorar significativamente la experiencia del usuario. Como tal, los mecanismos descritos incrementan la eficiencia de la codificación, y por tanto reducen el uso de recursos de red, recursos de memoria y/o recursos de procesamiento en el codificador y en el decodificador.
Según la invención reivindicada, el primer valor particular de tipo de unidad NAL indica que la imagen contiene un único tipo de sub-imagen de punto de acceso intra-aleatorio (IRAP), y en donde el segundo valor particular de tipo de unidad NAL, indica que la imagen contiene un único tipo de sub-imagen no IRAP.
Opcionalmente, en cualquiera de los aspectos anteriores, se proporciona otra implementación del aspecto, en donde el primer valor particular del tipo de unidad NAL es igual a la actualización de decodificación instantánea (IDR) con la imagen inicial decodificable de acceso aleatorio (IDR_W_RADL), IDR sin imágenes iniciales (Id R_N_LP), o tipo de unidad NAL de acceso aleatorio limpio (CRA) (CRA_NUT).
Opcionalmente, en cualquiera de los aspectos anteriores, se proporciona otra implementación del aspecto, en donde el segundo valor particular del tipo de unidad NAL es igual al tipo de unidad NAL de la imagen posterior (TRAIL_NUT), el tipo de unidad NAL de la imagen inicial decodificable de acceso aleatorio (RADL_n Ut ), o tipo de unidad NAL de imagen inicial omitida de acceso aleatorio (RASL), (RASL_NUT).
Opcionalmente, en cualquiera de los aspectos anteriores, se proporciona otra implementación del aspecto, en donde el indicador es un mixed_nalu_types_in_pic_flag.
El mixed_nalu_types_in_pic_flag es igual a uno cuando se especifica que cada imagen que se refiere al PPS tiene más de una unidad NAL VCL y las unidades NAL VCL no tienen el mismo valor del tipo de unidad NAL (nal_unit_type), y en donde mixed_nalu_types_in_pic_flag es igual a cero cuando cada imagen que se refiere al PPS tiene una o más unidades NAL VCL y las unidades NAL VCL de cada imagen que se refiere al PPS tienen el mismo valor de nal_unit_type.
En una realización, la descripción incluye un método según la reivindicación 6 implementado en un codificador.
Una imagen se puede dividir en múltiples sub-imágenes. Dichas sub-imágenes se pueden codificar en sub flujos de bits separados, que luego se pueden fusionar en un flujo de bits para ser transmitido a un decodificador. Por ejemplo, se pueden emplear sub-imágenes para aplicaciones de realidad virtual (VR). Como un ejemplo específico, un usuario solo puede ver una porción de una imagen VR en cualquier momento. Por consiguiente, se pueden transmitir diferentes sub-imágenes en diferentes resoluciones de modo que se pueda asignar más ancho de banda a las sub-imágenes que es probable que se muestren y las sub-imágenes que no es probable que se muestren se puedan comprimir para incrementar la eficiencia de la codificación. Además, los flujos de video se pueden codificar utilizando imágenes de punto de acceso intraaleatorio (IRAP). Una imagen IRAP se codifica de acuerdo con una intra-predicción y se puede decodificar sin referencia a otras imágenes. Las imágenes no IRAP se pueden codificar de acuerdo con la inter predicción y se pueden decodificar por referencia a otras imágenes. Las imágenes no IRAP se condensan más significativamente que las imágenes IRAP. Sin embargo, una secuencia de video debe comenzar a decodificarse con una imagen IRAP, ya que la imagen IRAP contiene suficientes datos para ser decodificados sin referirse a otras imágenes. Las imágenes IRAP se pueden utilizar en sub-imágenes y pueden permitir cambios de resolución dinámicos. Por consiguiente, un sistema de video puede transmitir más imágenes IRAP para sub-imágenes que es más probable que se vean (por ejemplo, con base en la ventana gráfica actual del usuario) y pocas imágenes IRAP para sub-imágenes que es poco probable que se vean a fin de incrementar además la eficiencia de codificación. Sin embargo, las sub-imágenes son parte de la misma imagen. Por consiguiente, este esquema puede dar como resultado una imagen que contiene tanto una sub-imagen IRAP como una sub-imagen no IRAP. Algunos sub-sistemas de video no están equipados para manejar una imagen mixta tanto con regiones IRAP como no IRAP. La presente descripción incluye un indicador que indica si una imagen es mixta y por consiguiente contiene tanto componentes IRAP como no IRAP. Además, el indicador restringe la imagen de tal modo que la imagen mixta contiene exactamente dos tipos de unidad NAL, que incluyen una de tipo IRAP y una de tipo no IRAP. Con base en este indicador, el decodificador puede tratar diferentes sub-imágenes de manera diferente cuando se decodifican a fin de decodificar y mostrar apropiadamente la imagen/sub-imágenes. Este indicador es almacenado en un PPS y puede ser referido como un mixed_nalu_types_in_pic_flag. Como tal, los mecanismos descritos permiten la implementación de una funcionalidad adicional. Además, los mecanismos descritos permiten cambios dinámicos de resolución cuando emplean flujos de bits de sub-imágenes. Por lo tanto, los mecanismos descritos permiten flujos de bits de sub-imágenes de resolución más baja que han de ser transmitidos cuando se transmite el video de VR sin deteriorar significativamente la experiencia del usuario. Como tal, los mecanismos descritos incrementan la eficiencia de codificación y por consiguiente reducen el uso de recursos de red, recursos de memoria y/o recursos de procesamiento en el codificador y el decodificador.
Opcionalmente, en cualquiera de los aspectos anteriores, se proporciona otra implementación del aspecto, en donde el primer valor particular del tipo de unidad NAL es igual a IDR_W_RADL, IDR_N_LP o CRA_NUT.
Opcionalmente, en cualquiera de los aspectos anteriores, se proporciona otra implementación del aspecto, en donde el segundo valor particular del tipo de unidad NAL es igual a TRAIL_NUT, RADL_NU o RASL_NU.
Opcionalmente, en cualquiera de los aspectos anteriores, se proporciona otra implementación del aspecto, en donde el indicador es un mixed_nalu_types_in_pic_flag.
El mixed_nalu_types_in_pic_flag es igual a uno cuando se específica que cada imagen que se refiere al PPS tiene más de una unidad NAL VCL y las unidades NAL VCL no tienen el mismo valor del nal_unit_type, y en donde mixed_nalu_types_in_pic_flag es igual a cero cuando cada imagen que se refiere al PPS tiene una o más unidades NAL VC<l>y las unidades NAL VCL de cada imagen que se refieren al PPS tiene el mismo valor de nal_unit_type.
En una realización, la descripción incluye un dispositivo de codificación de video que comprende: un procesador, un receptor acoplado al procesador, una memoria acoplada al procesador, y un transmisor acoplado al procesador, en donde el procesador, receptor, memoria y transmisor se configuran para llevar a cabo el método de cualquiera de los aspectos anteriores.
Estas y otras características se entenderán más claramente a partir de la siguiente descripción detallada tomada en combinación con las figuras adjuntas y las reivindicaciones.
Breve descripción de los dibujos
Para un entendimiento más completo de esta descripción, ahora se hace referencia a la siguiente breve descripción, tomada en combinación con las figuras adjuntas y la descripción detallada, en donde números de referencia similares representan partes similares.
La FIG. 1 es un diagrama de flujo de un método ejemplar de codificar una señal de video.
La FIG. 2 es un diagrama esquemático de un sistema de codificación y decodificación (códec) ejemplar para codificación de video.
La FIG. 3 es un diagrama esquemático que ilustra un codificador de video ejemplar.
La FIG. 4 es un diagrama esquemático que ilustra un decodificador de video ejemplar.
La FIG. 5 es un diagrama esquemático que ilustra una secuencia de video codificada ejemplar.
La FIG. 6 es un diagrama esquemático que ilustra una pluralidad de flujos de video de sub-imagen divididos a partir de un flujo de video de imágenes de realidad virtual (VR).
La FIG. 7 es un diagrama esquemático que ilustra un flujo de bits ejemplar que contiene imágenes con tipos de unidad de Capa de Abstracción de Red (NAL) mixtos.
La FIG. 8 es un diagrama esquemático de un dispositivo de codificación de video ejemplar.
La FIG. 9 es un diagrama de flujo de un método ejemplar para codificar una secuencia de video que contiene una imagen con tipos de unidad NAL mixtos en un flujo de bits.
La FIG. 10 es un diagrama de flujo de un método ejemplar para decodificar una secuencia de video que contiene una imagen con tipos de unidad NAL mixta a partir de un flujo de bits.
La FIG. 11 es un diagrama esquemático de un sistema ejemplar para codificar una secuencia de video que contiene una imagen con tipos de unidad NAL mixta en un flujo de bits.
Descripción detallada
Debe entenderse al comienzo que aunque a continuación se proporciona una implementación ilustrativa de una o más realizaciones, los sistemas y/o métodos descritos pueden implementarse utilizando cualquier número de técnicas, ya sean conocidas actualmente o existentes. La descripción no debe limitarse de ninguna manera a las implementaciones ilustrativas, dibujos y técnicas ilustrados a continuación, incluidos los diseños e implementaciones ejemplares ilustrados y descritos en la presente memoria, pero puede modificarse dentro del alcance de las reivindicaciones adjuntas.
Se utilizan en la presente los siguientes acrónimos, Secuencia de Video Codificado (CVS), Memoria Intermedia de Imagen Decodificada (DPB), Actualización de Decodificación Instantánea (IDR), Punto de Acceso Intra-Aleatorio (IRAP), Bit Menos Significativo (LSB), Bit Más Significativo (MSB), Capa de Abstracción de Red (NAL), Cómputo de Orden de Imagen (POC), Carga Útil de Secuencia de Byte sin Procesar (RBSP), Conjunto de Parámetros de Secuencia (SPS), y Borrador de Trabajo (WD).
Se pueden emplear muchas técnicas de compresión de video para reducir el tamaño de los archivos de video con pérdida mínima de datos. Por ejemplo, las técnicas de compresión de video pueden incluir llevar a cabo predicción espacial (por ejemplo, intra-imagen) y/o predicción temporal (por ejemplo, inter-imágenes) para reducir o eliminar la redundancia de datos en las secuencias de video. Para la codificación de video basada en bloques, un segmento de video (por ejemplo, una imagen de video o una porción de una imagen de video) se puede dividir en bloques de video, que también pueden ser referidos como bloques de árbol, bloques de árbol de codificación (CTB), unidades de árbol de codificación (CTU), unidades de codificación (CU) y/o nodos de codificación. Los bloques de video en un segmento intra-codificado (I) de una imagen se codifican utilizando predicción espacial con respecto a las muestras de referencia en bloques subyacentes en la misma imagen. Los bloques de video en un segmento de predicción unidireccional (P) o de predicción bidireccional (B) inter-codificado de una imagen se pueden codificar al emplear predicción espacial con respecto a las muestras de referencia en los bloques subyacentes en la misma imagen o predicción temporal con respecto a las muestras de referencia en otras imágenes de referencia. Las imágenes pueden ser referidas como fotogramas y/o imágenes, y las imágenes de referencia pueden ser referidas como fotogramas de referencia y/o imágenes de referencia. La predicción espacial o temporal da como resultado un bloque predictivo que representa un bloque de imagen. Los datos residuales representan diferencias de píxeles entre el bloque de imagen original y el bloque predictivo. Por consiguiente, un bloque inter-codificado se codifica de acuerdo con un vector de movimiento que apunta a un bloque de muestras de referencia que forman el bloque predictivo y los datos residuales que indican la diferencia entre el bloque codificado y el bloque predictivo. Un bloque intra-codificado se codifica de acuerdo con un modo de intra-codificación y los datos residuales. Para compresión adicional, los datos residuales se pueden transformar del dominio de píxel a un dominio de transformación. Esto da como resultado coeficientes de transformación residuales, que se pueden cuantificar. Los coeficientes de transformación cuantificados se pueden disponer inicialmente en una matriz bidimensional. Los coeficientes de transformación cuantificados se pueden escanear a fin de producir un vector unidimensional de coeficientes de transformación. Se puede aplicar codificación de entropía para lograr aún más compresión. Estas técnicas de compresión de video se analizan con mayor detalle a continuación.
Para garantizar que un video codificado se pueda decodificar con precisión, el video se codifica y decodifica de acuerdo con normas de codificación de video correspondientes. Las normas de codificación de video incluyen Sector de Normalización (ITU-T) H.261 de Unión Internacional de Telecomunicaciones (ITU), Organización Internacional para Normalización/Comisión Electrotécnica Internacional (ISO/IEC), Grupo de Expertos en Cinematografía (MPEG)-1 Parte 2, ITU-T H.262 o ISO/IEC MPEG-2 Parte 2, ITU-T H.263, I<s>O/IEC MPEG-4 Parte 2, Codificación de Video Avanzada (AVC), también conocida como ITU-T H.264 o ISO/IEC MPEG-4 Parte 10 y Codificación de Video de Alta Eficiencia (HEVC), también conocida como ITU-T H.265 o MPEG-H Parte 2. La AVC incluye extensiones tales como Codificación de Video Escalable (SVC), Codificación de Video de Múltiples Puntos de Vista (MVC) y Codificación de Video de Múltiples Puntos de Vista de más Profundidad (Mv C+D) y AVC tridimensional (3D) (3D-AVC). La HEVC incluye extensiones tales como HEVC Escalable (SHVC), HEVC de Múltiples Puntos de Vista (MV-HEVC) y HEVC 3D (3D-HEVC). El equipo conjunto de expertos de video (JVET) de ITU-T e ISO/IEC ha comenzado a desarrollar una norma de codificación de video referida como Codificación de Video Versátil (VVC). La VVC se incluye en un Borrador de Trabajo (WD), que incluye JVET-M1001-v6 que proporciona una descripción del algoritmo, una descripción del lado del codificador del VVC WD, y software de referencia.
Los sistemas de codificación de video pueden codificar un video empleando imágenes IRAP e imágenes no IRAP. Las imágenes IRAP son imágenes codificadas de acuerdo con la intra-predicción que sirven como puntos de acceso aleatorio para una secuencia de video. En la intra-predicción, los bloques de una imagen se codifican por referencia a otros bloques de la misma imagen. Esto es en contraste con las imágenes no IRAP que emplean la inter-predicción. En la inter-predicción, los bloques de una imagen actual se codifican por referencia a otros bloques en una imagen de referencia que es diferente de la imagen actual. Dado que una imagen IRAP se codifica sin referencia a otras imágenes, la imagen IRAP se puede decodificar sin decodificar primero cualesquiera otras imágenes. Por consiguiente, un decodificador puede comenzar a decodificar una imagen de video en cualquier imagen IRAP. En contraste, una imagen no IRAP se codifica en referencia a otras imágenes y, por consiguiente, un decodificador es incapaz en general de comenzar a decodificar una secuencia de video en una imagen no IRAP. Las imágenes IRAP también actualizan la DPB. Esto es debido a que la imagen IRAP es un punto de partida para una CVS, y las imágenes en la CVS no se refieren a imágenes en la CVS anterior. Como tal, las imágenes IRAP también pueden detener los errores de codificación relacionados con la inter-predicción debido a que dichos errores no se pueden propagar a través de la imagen IRAP. Sin embargo, las imágenes IRAP son significativamente más grandes que las imágenes no IRAP desde un punto de vista del tamaño de los datos. Como tal, una secuencia de video incluye en general muchas imágenes no IRAP con un número más pequeño de imágenes IRAP intercaladas para equilibrar la eficiencia de codificación con funcionalidad. Por ejemplo, una CVS de sesenta fotogramas puede incluir una imagen IRAP y cincuenta y nueve imágenes no IRAP.
En algunos casos, los sistemas de codificación de video se pueden emplear para codificar un video de realidad virtual (VR), que también puede ser referido como un video de 360 grados. Un video de VR puede incluir una esfera de contenido de video mostrada como si el usuario estuviera en el centro de la esfera. Solo una porción de la esfera, referida como una ventana gráfica, se muestra al usuario. Por ejemplo, el usuario puede emplear un dispositivo de visualización montado en la cabeza (HMD) que selecciona y muestra una ventana gráfica de la esfera basada en el movimiento de la cabeza del usuario. Esto proporciona la impresión de estar físicamente presente en un espacio virtual como es representado por el video. A fin de lograr este resultado, cada imagen de la secuencia de video incluye una esfera completa de datos de video en un momento en el tiempo correspondiente. Sin embargo, solo una pequeña poción (por ejemplo, una ventana gráfica individual) de la imagen se muestra al usuario. El resto de la imagen se desecha sin ser representada. La imagen completa se transmite en general de modo que se pueda seleccionar dinámicamente y se muestre en una ventana gráfica diferente en respuesta al movimiento de la cabeza del usuario. Este procedimiento puede dar por resultado tamaños de archivo de video muy grandes.
A fin de mejorar la eficiencia de la codificación, algunos sistemas dividen las imágenes en sub-imágenes. Una sub-imagen es una región espacial definida de una imagen. Cada sub-imagen contiene una ventana gráfica correspondiente de la imagen. El video se puede codificar en dos o más resoluciones. Cada resolución se codifica en un sub-flujo de bits diferente. Cuando un usuario transmite el video de VR, el sistema de codificación puede fusionar los sub-flujos de bits en un flujo de bits para transmisión basándose en la ventana gráfica actual en uso por el usuario. Específicamente, la ventana gráfica actual se obtiene a partir del sub-flujo de bits de alta resolución y las ventanas gráficas que no están siendo visualizadas se obtienen a partir del flujo de bits de baja resolución. De esta manera, se muestra al usuario el video de mayor calidad y se elimina el video de menor calidad. En caso de que el usuario seleccione una nueva ventana gráfica, el video de menor resolución se presenta al usuario. El decodificador puede solicitar que la nueva ventana gráfica reciba el video de mayor resolución. El codificador entonces puede alterar el proceso de fusión consecuentemente. Una vez que se alcanza una imagen IRAP, el decodificador puede comenzar a decodificar la secuencia de video de mayor resolución en la nueva ventana gráfica. Este enfoque incrementa significativamente la compresión de video sin impactar negativamente en la experiencia de visión del usuario.
Una preocupación con el enfoque antes mencionado es que la duración de tiempo necesaria para cambiar las resoluciones se basa en la duración de tiempo hasta que se alcanza una imagen IRAP. Esto es debido a que el decodificador es incapaz de estar decodificando una secuencia de video diferente en una imagen no IRAP como se ha descrito anteriormente. Un enfoque para reducir dicha latencia es incluir más imágenes IRAP. Sin embargo, esto da como resultado un incremento en el tamaño del archivo. A fin de equilibrar la funcionalidad con eficiencia de codificación, diferentes ventanas gráficas/sub-imágenes pueden incluir imágenes IRAP en diferentes frecuencias. Por ejemplo, las ventanas gráficas que son más probables que se observen pueden tener más imágenes IRAP que otras ventanas gráficas. Por ejemplo, en un contexto de baloncesto, las ventanas gráficas relacionadas con las canastas y/o la cancha central pueden incluir imágenes IRAP con una mayor frecuencia que las ventanas gráficas que visualizan las gradas o el techo ya que tales ventanas gráficas son menos probables que sean vistas por el usuario.
Este enfoque conduce a otros problemas. Específicamente, las sub-imágenes que contienen las ventanas gráficas son parte de una sola imagen. Cuando diferentes sub-imágenes tienen imágenes IRAP en diferentes frecuencias, algunas de las imágenes incluyen tanto sub-imágenes IRAP como sub-imágenes no IRAP. Esto es un problema debido a que las imágenes se almacenan en un flujo de bits empleando unidades NAL. Una unidad NAL es una unidad de almacenamiento que contiene un conjunto de parámetros o un segmento de una imagen y un encabezado de segmento correspondiente. Una unidad de acceso es una unidad que contiene una imagen completa. Como tal, una unidad de acceso contiene todas las unidades NAL relacionadas con la imagen. Las unidades NAL también contienen un tipo que indica el tipo de imagen que incluye el segmento. En algunos sistemas de video, todas las unidades NAL relacionadas con una única imagen (por ejemplo, incluida en la misma unidad de acceso) se requiere que tengan el mismo tipo. Como tal, el mecanismo de almacenamiento de unidad NAL puede dejar de funcionar correctamente cuando una imagen incluye tanto sub-imágenes IRAP como sub-imágenes no IRAP.
Se han descrito en la presente memoria, mecanismos para ajustar el esquema de almacenamiento NAL para soportar las imágenes que incluyen tanto sub-imágenes IRAP como sub-imágenes no IRAP. Esto a su vez, permite videos de VR que incluyen diferentes frecuencias de sub-imágenes IRAP para diferentes ventanas gráficas. La invención utiliza un indicador que indica si una imagen es mixta. En particular, el indicador indica si la imagen contiene tanto sub-imágenes IRAP como no IRAP. Basándose en este indicador, el decodificador puede tratar diferentes tipos de sub-imágenes de manera diferente cuando se decodifican a fin de decodificar y mostrar apropiadamente la imagen/sub-imágenes. Este indicador se almacena en un conjunto de parámetros de imagen (PPS) y se puede referir como un mixed_nalu_types_in_pic_flag.
La invención implica un indicador que indica si una imagen es mixta. En particular, el indicador indica si la imagen contiene tanto sub-imágenes IRAP como no IRAP. Además, el indicador restringe la imagen de tal manera que la imagen mixta contiene exactamente dos tipos de unidad NAL, que incluyen un tipo IRAP y un tipo no IRAP. Por ejemplo, la imagen puede contener unidades NAL IRAP, que incluyen una y solamente una de la actualización de decodificación instantánea (IDR) con imagen inicial decodificable de acceso aleatorio (IDR_W_RADL), IDR sin imágenes iniciales (IDR_N_LP) o tipo de unidad NAL de acceso aleatorio limpio (CRA), (CRA_NUT). Además, la imagen puede contener unidades NAL no IRAP, incluida una y solo una del tipo de unidad NAL de imagen final (TRAIL_NUT), tipo de unidad NAL de imagen inicial decodificable de acceso aleatorio (RADL_NUT) o tipo de unidad NAL de imagen inicial omitida de acceso aleatorio (RASL), (RASL_NUT). Con base en este indicador, el decodificador puede tratar diferentes sub-imágenes de manera diferente cuando se decodifican a fin de decodificar y mostrar apropiadamente la imagen/sub-imágenes. Este indicador se almacena en un PPS y puede ser referido como un mixed_nalu_types_in_pic_flag.
La FIG. 1 es un diagrama de flujo de un método 100 de operación ejemplar para codificar una señal de video. Específicamente, una señal de video se codifica en un codificador. El proceso de codificación comprime la señal de video empleando varios mecanismos para reducir el tamaño del archivo de video. Un tamaño de archivo más pequeño permite que el archivo de video comprimido se transmita hacia un usuario, mientras que se reduce la sobrecarga de ancho de banda asociada. El decodificador decodifica luego el archivo de video comprimido para reconstruir la señal de video original para mostrarla a un usuario final. El proceso de decodificación refleja en general el proceso de codificación para permitir que el decodificador reconstruya consistentemente la señal de video.
En la etapa 101, la señal de video es introducida en el codificador. Como otro ejemplo, la señal de video puede ser un archivo de video no comprimido almacenado en la memoria. Como otro ejemplo, el archivo de video se puede capturar mediante un dispositivo de captura de video, tal como una cámara de video, y codificarlo para soportar la transmisión en directo del video. El archivo de video puede incluir tanto un componente de audio como un componente de video. El componente de video contiene una serie fotogramas de imagen que, cuando se observan en una secuencia, da la impresión visual de movimiento. Las fotogramas que contienen pixeles que se expresan en términos de luz, referidos en la presente memoria como componentes de luma (o muestras de luma), y color, que es referido como componentes de croma (o muestras de color). En algunos ejemplos, los fotogramas también pueden contener valores de profundidad para soportar la observación tridimensional.
En la etapa 103, el video se divide en bloques. Dividir incluye subdividir los pixeles en cada fotograma en bloques cuadrados y/o rectangulares para compresión. Por ejemplo, en la Codificación de Video de Alta Eficiencia (HEVC) (también conocida como H.265 y MPEG-H Parte 2) el fotograma puede ser dividido en primer lugar en unidades de árbol de codificación (CTU), que son bloques de un tamaño predefinido (por ejemplo, sesenta y cuatro pixeles por sesenta y cuatro pixeles). Las CTU contienen muestras tanto de luma como de croma. Los árboles de codificación se pueden emplear para dividir las CTU en bloques y luego subdividir recursivamente los bloques hasta que se logren configuraciones que soportan la codificación adicional. Por ejemplo, los componentes luma de un fotograma se pueden subdividir hasta que los bloques individuales contengan valores de iluminación relativamente homogéneos. Además, los componentes de croma de un fotograma se pueden subdividir hasta que los bloques individuales contengan valores de color relativamente homogéneos. Por consiguiente, los mecanismos de división varían dependiendo del contenido de los fotogramas de video.
En la etapa 105, se emplean varios mecanismos de compresión para comprimir los bloques de imágenes divididos en la etapa 103. Por ejemplo, se pueden emplear inter-predicción y/o intra-predicción. La inter predicción está diseñada para beneficiarse del hecho de que los objetos en una escena común tiendan a presentarse en fotogramas sucesivos. Por consiguiente, un bloque que representa un objeto en un fotograma de referencia necesita ser descrito repetidamente en fotogramas adyacentes. Específicamente, un objeto tal como una mesa, puede permanecer en una posición constante durante múltiples fotogramas. Por consiguiente, la mesa se describe una vez y los fotogramas adyacentes pueden referirse de nuevo al fotograma de referencia. Se pueden emplear mecanismos de coincidencia de patrones para hacer coincidir objetos en múltiples fotogramas. Además, los objetos en movimiento pueden estar representados a través de fotogramas múltiples, debido al movimiento del objeto o al movimiento de la cámara. Como un ejemplo particular, un video puede mostrar un automóvil que se mueve a través de la pantalla sobre múltiples fotogramas. Se pueden mostrar vectores de movimiento para describir este movimiento. Un vector de movimiento es un vector bidimensional que proporciona un desplazamiento de las coordenadas de un objeto en un fotograma a las coordenadas del objeto en un fotograma de referencia. Como tal, la inter-predicción puede codificar un bloque de imagen en un fotograma actual como un conjunto de vectores de movimiento que indican un desplazamiento de un bloque correspondiente en un fotograma de referencia.
La intra-predicción codifica bloques en un fotograma común. La intra-predicción se beneficia del hecho de que los componentes de luma y de croma tienden a agruparse en un fotograma. Por ejemplo, un parche de verde en una posición de un árbol tiende a ser colocado junto a parches de verde similares. La intrapredicción emplea múltiples modos de predicción direccionales (por ejemplo, treinta y tres en HEVC), un modo plano y un modo de corriente continua (CC). Los modos direccionales indican que un bloque actual es similar a/el mismo que, las muestras de un bloque subyacente en una dirección correspondiente. El modo plano indica que una serie de bloques a lo largo de una fila/columna (por ejemplo, un plano) se pueden interpolar con base en los bloques contiguos en los bordes de la fila, el modo plano, en efecto, indica una transición suave de luz/color a lo largo de una fila/columna al emplear una inclinación relativamente constante en los valores cambiantes. Se emplea el modo de CC para el suavizado del límite e indica que un bloque es similar a/el mismo que, un valor promedio asociado con las muestras de todos los bloques contiguos asociados con las direcciones angulares de los modos de predicción direccionales. Por consiguiente, los bloques de intra-predicción pueden representar bloques de imágenes en varios valores de modo de predicción relacional en lugar de los valores reales. Además, los bloques de inter-predicción pueden representar bloques de imágenes como valores de vectores de movimiento en lugar de los valores reales. En cualquier caso, los bloques de predicción pueden no representar exactamente los bloques de imágenes en algunos casos. Se almacenan cualesquiera diferencias en los bloques residuales. Las transformaciones se pueden aplicar a los bloques residuales para comprimir adicionalmente el archivo.
En la etapa 107, se pueden aplicar varias técnicas de filtración. En la HEVC, los filtros se aplican de acuerdo con un esquema de filtración en bucle. La predicción basada en bloques analizada anteriormente puede dar como resultado la creación de imágenes de bloques en el decodificador. Además, el esquema de predicción basada en bloques puede codificar un bloque y luego reconstruir el bloque codificado para su uso posterior como un bloque de referencia. El esquema de filtración en bucle aplica relativamente los filtros de supresión de ruido, filtros de desbloqueo, filtro de bucle adaptivos, y filtros de compensación adaptiva de muestra (SAO) a los bloques/fotogramas. Estos filtros mitigan dichos artefactos de bloqueo de modo que el archivo codificado se puede reconstruir con precisión. Además, estos filtros mitigan los artefactos en los bloques de referencia reconstruidos de modo que los artefactos son menos probables de crear artefactos adicionales en los bloques subsiguientes que se codifican basándose en los bloques de referencia reconstruidos.
Una vez que la señal de video se ha dividido, comprimido, y filtrado, los datos resultantes se codifican en un flujo de bits en la etapa 109. El flujo de bits incluye los datos analizados anteriormente así como cualquiera de los datos de señalización deseados para soportar la reconstrucción de la señal de video apropiada en el decodificador. Por ejemplo, dichos datos pueden incluir datos de partición, datos de predicción, bloques residuales y varios indicadores que proporcionan instrucciones de codificación al decodificador. El flujo de bits se puede almacenar en la memoria para transmisión hacia un decodificador al solicitarse. El flujo de bits también se puede transmitir y/o transmitir de manera múltiple hacia una pluralidad de decodificadores. La creación del flujo de bits es un proceso iterativo. Por consiguiente, las etapas 101, 103, 105, 107, y 109 pueden ocurrir continua y/o simultáneamente sobre muchos fotogramas y bloques. El orden mostrado en la FIG. 1 es presentado para claridad y facilidad de análisis, y no pretende limitar el proceso de codificación de video a un orden particular.
El decodificador recibe el flujo de bits y comienza el proceso de decodificación en la etapa 111. Específicamente, el decodificador emplea un esquema de decodificación de entropía para convertir el flujo de bits en datos de sintaxis y de video correspondientes. El decodificador emplea los datos de sintaxis del flujo de bits para determinar las divisiones para los fotogramas en la etapa 111. La división debo coincidir con los resultados de la división de bloques en la etapa 103. Ahora se describe la codificación/decodificación de entropía como se emplea en la etapa 111. El codificador hace muchas selecciones durante el proceso de compresión, tal como seleccionar esquemas de partición de bloques a partir de varias posibles selecciones basadas en el posicionamiento espacial de los valores en la imagen o imágenes de entrada. La señalización de las selecciones exactas puede emplear un gran número de contenedores. Como se utiliza en la presente memoria, un contenedor es un valor binario que se trata como una variable (por ejemplo, un valor de bit que puede variar dependiendo del contexto). La codificación de entropía permite que el codificador elimine cualesquiera opciones que claramente no son viables para un caso particular, dejando un conjunto de opciones permisibles. A cada opción permisible luego se le asigna una palabra código. La longitud de las palabras código se basa en el número de opciones permisibles (por ejemplo, un contenedor para dos opciones, dos contenedores para tres o cuatro opciones, etc.) El codificador luego codifica la palabra código para la opción seleccionada. Este esquema reduce el tamaño de las palabras código ya que las palabras código son tan grandes como se desee para indicar únicamente una selección de un subconjunto pequeño de opciones permisibles como lo opuesto a indicar únicamente la selección de un conjunto potencialmente grande de todas las posibles opciones. El decodificador luego decodifica la selección determinando el conjunto de opciones permisibles en una manera similar al codificador. Al determinar el conjunto de opciones permisibles, el decodificador puede leer la palabra código y determinar la selección hecha por el codificador.
En la etapa 113, el decodificador realiza la decodificación de bloques. Específicamente, el decodificador emplea transformaciones inversas para generar bloques residuales. Luego el decodificador emplea los bloques residuales y los bloques de predicción correspondientes para reconstruir los bloques de imágenes de acuerdo con la división. Los bloques de predicción pueden incluir tanto bloques de intra-predicción como bloques de inter-predicción como son generados en el codificador en la etapa 105. Los bloques de imagen reconstruida luego se colocan en los fotogramas de una señal de video reconstruida de acuerdo con los datos de división determinados en la etapa 111. La sintaxis para la etapa 113 también se puede señalizar en el flujo de bits mediante codificación de entropía como se ha analizado anteriormente.
En la etapa 115, se realiza la filtración en los fotogramas de la señal de video reconstruida de una manera similar a la etapa 107 en el codificador. Por ejemplo, los filtros de supresión de ruido, filtros de desbloqueo, filtros de bucle adaptivos, y filtros SAO se pueden aplicar a los fotogramas para eliminar los artefactos de bloqueo. Una vez que los fotogramas se filtran, la señal de video se puede enviar a un dispositivo de visualización en la etapa 117 para su visión por un usuario final.
La FIG. 2 es un diagrama esquemático de un sistema de codificación y de decodificación ejemplar (códec) 200 para la codificación de video. Especialmente, el sistema códec 200 proporciona funcionalidad para soportar la implementación del método operativo 100. El sistema códec 200 se generaliza para presentar componentes empleados tanto en un codificador como un decodificador. El sistema códec 200 recibe y divide una señal de video como se ha analizado con respecto a las etapas 101 y 103 en el método operativo 100, lo que da por resultado una señal 201 de video dividida. El sistema códec 200 luego comprime la señal 201 de video dividida en un flujo de bits codificado cuando actúa como un codificador como se ha analizado con respecto a las etapas 105, 107, y 109 en el método 100. Cuando actúa como un decodificador, el sistema códec 200 genera una seña de video de salida procedente del flujo de bits como se ha analizado con respecto a las etapas 111, 113, 115, y 117 en el método operativo 100. El sistema códec 200 incluye un componente 211 de control de codificador general, un componente 213 de escalamiento y cuantificación de transformación, un componente 215 de estimación intra-imagen, un componente 217 de predicción intraimagen, un componente 219 de compensación de movimiento, un componente 221 de estimación de movimiento, un componente 229 de escalamiento y transformación inversa, un componente 227 de análisis de control de filtro, un componente 225 de filtros en bucle, un componente 223 de memoria intermedia de imagen decodificada, y un componente 231 de codificación aritmética binaria adaptiva de contexto (CABAC) y formateo de encabezado. Dichos componentes se acoplan como se muestra. En la FIG. 2, las líneas negras indican el movimiento de los datos que se han de codificar/decodificar mientras que las líneas de trazos indican el movimiento de los datos de control que controla la operación de otros componentes. Los componentes del sistema códec 200 pueden estar todos presentes en el codificador. El decodificador puede incluir un subconjunto de los componentes del sistema códec 200. Por ejemplo, el decodificador puede incluir el componente 217 de predicción intra-imagen, el componente 219 de compensación de movimiento, el componente 229 de escalamiento y transformación inversa, el componente 225 de filtros en bucle, y el componente 223 de memoria intermedia de imagen decodificada. A continuación se describen estos componentes.
La señal 201 de video dividida es una secuencia de video capturada que ha sido dividida en bloques de pixeles por un árbol de codificación. Un árbol de codificación emplea varios modos de división para subdividir un bloque de pixeles en bloques más pequeños de pixeles. Estos bloques luego se pueden subdividir adicionalmente en bloques más pequeños. Los bloques pueden ser referidos como nodos en el árbol de codificación. Los nodos padres más grandes se dividen en nodos hijos más pequeños. El número de veces en que un nodo se subdivide es referido como la profundidad del árbol del nodo/codificación. Los bloques divididos se pueden incluir en unidades de codificación (CU) en algunos casos. Por ejemplo, una CU puede ser una sub-porción de una CTU que contiene un bloque de luma, bloque o bloques de croma de diferencia de rojo (Cr), y un bloque o bloques de croma de diferencia de azul (Cb) junto con instrucciones de sintaxis correspondiente para la CU. Los modos de división pueden incluir un árbol binario (BT), un árbol triple (TT), y un árbol cuádruple (QT) empleados para la división de un nodo en dos, tres, o cuatro nodos hijos, respectivamente, de formas variables dependiendo de los modos de división empleados. La señal 201 de video dividida se reenvía al componente 211 de control de codificador general, al componente 213 de escalamiento y cuantificación de transformación, al componente 215 de estimación de intra-imagen, al componente 227 de análisis de control de filtro, y al componente 221 de estimación de movimiento para compresión.
El componente 211 de control de codificador general está configurado para tomar decisiones relacionadas con la codificación de las imágenes de la secuencia de video en el flujo de bits de acuerdo con las restricciones de aplicación. Por ejemplo, el componente 211 de control de codificador general gestiona la optimización del tamaño de la tasa de bits/flujo de bits con respecto a la calidad de reconstrucción. Dichas decisiones se pueden tomar basándose en la disponibilidad de espacio/ancho de banda de almacenamiento y solicitudes de resolución de imagen. El componente 211 de control de codificador general también gestiona la utilización de la memoria intermedia a la luz de la velocidad de transmisión para mitigar los problemas de infrautilización y sobreutilización de la memoria intermedia. Para gestionar estos problemas, el componente 211 de control de codificador general gestiona la división, predicción, y filtración por los otros componentes. Por ejemplo, el componente 211 de control de codificador general puede incrementar dinámicamente la complejidad de la compresión para incrementar la resolución y el incremento del uso de ancho de banda o disminuir la complejidad de compresión para disminuir la resolución y el uso de ancho de banda. Por consiguiente, el componente 211 de control de codificador general controla los otros componentes del sistema códec 200 para equilibrar la calidad de reconstrucción de la señal de video con cuestiones sobre la tasa de bits. El componente 211 de control de codificador general crea datos de control, lo que controla la operación de los otros componentes. Los datos de control también se reenvían al componente 231 de formateo de encabezado y CABAC para que sean codificados en el flujo de bits para señalizar los parámetros para decodificación en el decodificador.
La señal 201 de video dividida también se envía al componente 221 de estimación de movimiento y al componente 219 de compensación de movimiento para su inter-predicción. Un fotograma o segmento de la señal 201 de video dividida se puede dividir en múltiples bloques de video. El componente 221 de estimación de movimiento y el componente 219 de compensación de movimiento realizan la codificación inter-predictiva del bloque de video recibido con respeto a uno o más bloques en uno o más fotogramas de referencia para proporcionar la predicción temporal. El sistema códec 200 puede realizar múltiples pasadas de codificación, por ejemplo, para seleccionar un modo de codificación apropiado para cada bloque de datos de video.
El componente 221 de estimación de movimiento y el componente 219 de compensación de movimiento pueden estar muy integrados, pero se ilustran por separado con propósitos conceptuales. La estimación de movimiento, realizada por el componente 221 de estimación de movimiento, es el proceso de generación de vectores de movimiento, que estiman el movimiento para los bloques de video. Un vector de movimiento por ejemplo, puede indicar el desplazamiento de un objeto codificado con respecto a un bloque predictivo. Un bloque predictivo es un bloque que se ha encontrado que coincide estrechamente con el bloque que ha de ser codificado, en términos de diferencia de pixeles. Un bloque predictivo también puede ser referido como un bloque de referencia. Dicha diferencia de pixeles se puede determinar por la suma de la diferencia absoluta (SAD), suma de la diferencia cuadrada (SSD), u otras métricas de diferencia. La HEVC emplea varios objetos codificados que incluyen una CTU, bloques de árboles de codificación (CTB), y las CU. Por ejemplo, una CTU se puede dividir en un CTB, que puede luego dividirse en un CB para inclusión en las CU. Una CU se puede codificar como una unidad de predicción (PU) que contiene datos de predicción y/o una unidad de transformación (TU) que contiene datos residuales transformados para la CU. El componente 221 de estimación de movimiento genera vectores de movimiento, PU, y TU utilizando un análisis de distorsión de tasa como parte de un proceso de optimización de distorsión de tasa. Por ejemplo, el componente 221 de estimación de movimiento puede determinar múltiples bloques de referencia, múltiples vectores de movimiento, etc., para un bloque/fotograma actual, y puede seleccionar los bloques de referencia, vectores de movimiento, etc. que tienen las mejores características de distorsión de tasa. Las mejores características de distorsión de tasa equilibran tanto la calidad de la reconstrucción del video (por ejemplo, cantidad de datos perdidos por compresión) con la eficiencia de codificación (por ejemplo, tamaño de la codificación final).
En algunos ejemplos, el sistema códec 200 puede calcular valores para las posiciones de pixeles sub-enteros de las imágenes de referencia almacenadas en el componente 223 de memoria intermedia de imágenes decodificadas. Por ejemplo, el sistema códec 200 de video puede interpolar valores de posiciones de pixeles de un cuarto, posiciones de pixeles de un octavo, u otras posiciones de pixeles fraccionarias de la imagen de referencia. Por lo tanto, el componente 221 de estimación de movimiento puede realizar una búsqueda de movimiento con respecto a las posiciones de pixeles completas y posiciones de pixeles fraccionarias y emitir un vector de movimiento con precisión de pixeles fraccionaria. El componente 221 de estimación de movimiento calcula un vector de movimiento para una PU de un bloque de video en un segmento inter codificado comparando la posición de la PU con la posición de un bloque predictivo de una imagen de referencia. El componente 221 de estimación de movimiento emite el vector de movimiento calculado como datos de movimiento para el componente 231 de formateo de encabezado y CABAC para la codificación y movimiento al componente 219 de compensación de movimiento.
La compensación de movimiento, realizada por el componente 219 de compensación de movimiento, puede implicar buscar o generar el bloque predictivo basándose en el vector de movimiento determinado por el componente 221 de estimación de movimiento. Nuevamente, el componente 221 de estimación de movimiento y el componente 219 de compensación de movimiento se pueden integrar funcionalmente, en algunos ejemplos. Tras recibir el vector de movimiento para la PU del bloque de video actual, el componente 219 de compensación de movimiento puede ubicar el bloque predictivo al que apunta el vector de movimiento. Un bloque de video residual se forma luego restando los valores de pixel del bloque predictivo de los valores de pixel del bloque de video actual que se está codificando, formando valores de diferencia de pixeles. En general, el componente 221 de estimación de movimiento realiza la estimación de movimiento con respecto a los componentes de luma, y el componente 219 de compensación de movimiento utiliza los vectores de movimiento calculados basándose en los componentes de luma tanto para los componentes de croma como los componentes de luma. El bloque predictivo y el bloque residual se reenvían para transformar el componente 213 de escalamiento y cuantificación.
La señal 201 de video dividida también es enviada al componente 215 de estimación intra-imagen y al componente 217 de predicción intra-imagen. Como con el componente 221 de estimación de movimiento y el componente 219 de compensación de movimiento, el componente 215 de estimación intra-imagen y el componente 217 de predicción intra-imagen pueden estar muy integrados, pero se ilustran por separado con propósitos conceptuales. El componente 215 de estimación intra-imagen y el componente 217 de predicción intra-imagen, intra-predicen un bloque actual con respecto a los bloques en un fotograma actual, como una alternativa a la inter-predicción realizada por el componente 221 de estimación de movimiento y el componente 219 de compensación de movimiento entre fotogramas, como se describe anteriormente. En particular, el componente 215 de estimación intra-imagen determina un modo de intra-predicción para usar para codificar un bloque actual. En algunos ejemplos, el componente 215 de estimación intra-imagen selecciona un modo de intra-predicción apropiado para codificar un bloque actual de múltiples modos de intra-predicción ensayados. Los modos de intra-predicción seleccionados luego se reenvían al componente CABAC 231 y de formateo de encabezado para codificación.
Por ejemplo, el componente 215 de estimación intra-imagen calcula los valores de distorsión de tasa utilizando un análisis de distorsión de tasa para los diversos modos de intra-predicción ensayados, y selecciona el modo de intra-predicción que tiene las mejores características de distorsión de tasa entre los modos ensayados. El análisis de distorsión de tasa determina una cantidad de distorsión (o error) entre un bloque codificado y un bloque no codificado original que se codificó para producir el bloque codificado, así como una tasa de bits (por ejemplo, un número de bits) utilizada para producir el bloque codificado. El componente 215 de estimación intra-imagen calcula las relaciones a partir de las distorsiones y las tasas para los diversos bloques codificados para determinar qué modo de intra-predicción muestra el mejor valor de distorsión de tasa para el bloque. Además, el componente 215 de estimación intra-imagen se puede configurar para codificar bloques de profundidad de un mapa de profundidad utilizando un modo de modelado de profundidad (DMM) basándose en la optimización de distorsión de tasa (RDO).
El componente 217 de predicción intra-imagen puede generar un bloque residual a partir del bloque predictivo basándose en lo modos de intra-predicción seleccionados por el componente 215 de estimación intra-imagen cuando se implementa en un codificador o leer el boque residual del flujo de bits cuando se implementa en un decodificador. El bloque residual incluye la diferencia en los valores entre el bloque predictivo y el original, representada como una matriz. El bloque residual luego se reenvía al componente 213 de escalamiento y cuantificación de transformación. El componente 215 de estimación intra-imagen y el componente 217 de predicción intra-imagen pueden operar tanto sobre componentes de luma como de croma.
El componente 213 de escalamiento y cuantificación de transformación está configurado para comprimir adicionalmente el bloque residual. El componente 213 de escalamiento y cuantificación de transformación aplica una transformación, tal como una transformación de coseno discreta (DCT), una transformación de seno discreta (DST), o una transformación conceptualmente similar, al bloque residual, produciendo un bloque de video que comprende valores de coeficientes de transformación residual. También se podrían utilizar transformaciones de ondículas, transformaciones de números enteros, transformaciones de sub banda u otros tipos de transformaciones. La transformación puede convertir la información residual desde un dominio de valor de pixel a un dominio de transformación, tal como un dominio de frecuencia. El componente 213 de escalamiento y cuantificación de transformación también se configura para escalar la información residual transformada, por ejemplo basada en frecuencia. Dicho escalamiento implica aplicar un factor de escala a la información residual de modo que se cuantifique la información de frecuencia diferente en granularidades diferentes, lo cual puede afectar a la calidad visual final del video reconstruido. El componente 213 de escalamiento y cuantificación de transformación también está configurado para cuantificar los coeficientes de transformación para reducir adicionalmente la tasa de bits. El proceso de cuantificación puede reducir la profundidad de bits de acuerdo con alguno o todos los coeficientes. El grado de cuantificación se puede modificar ajustando un parámetro de cuantificación. En algunos ejemplos, el componente 213 de escalamiento y cuantificación de transformación puede luego realizar un escaneo de la matriz que incluye los coeficientes de transformación cuantificados. Los coeficientes de transformación cuantificados se reenvían al componente 231 de formateo de encabezado y CABAC para ser codificados en el flujo de bits.
El componente 229 de escalamiento y transformación inversa aplica una operación inversa del componente 213 de escalamiento y cuantificación de transformación para soportar la estimación de movimiento. El componente 229 de escalamiento y transformación inversa aplica el escalamiento, transformación inversos, y/o cuantificación para reconstruir el bloque residual en el dominio de pixel, por ejemplo, para uso posterior como un bloque de referencia que puede resultar un bloque predictivo para otro bloque actual. El componente 221 de estimación de movimiento y/o el componente 219 de compensación de movimiento pueden calcular un bloque de referencia añadiendo el bloque residual de nuevo a un bloque predictivo correspondiente para su uso en la estimación de movimiento de un bloque/fotograma, posterior. Se aplican filtros a los bloques de referencia reconstruidos para mitigar los artefactos creados durante el escalamiento, cuantificación y transformación. Dichos artefactos de otra manera podría provocar una predicción imprecisa (y crear artefactos adicionales) cuando se predicen bloques subsiguientes.
El componente 227 de análisis de control de filtro y el componente 225 de filtros en bucle aplican los filtros a los bloques residuales y/o a los bloques de imágenes reconstruidas. Por ejemplo, el bloque residual transformado procedente del componente 229 de escalamiento y transformación inversa se puede combinar con un bloque de predicción correspondiente procedente del componente 217 de predicción intra-imagen y/o del componente 219 de compensación de movimiento para reconstruir el bloque de imagen original. Los filtros luego se pueden aplicar al bloque de imágenes reconstruidas. En algunos ejemplos, los filtros en vez de ello se pueden aplicar a los bloques residuales. Como con otros componentes en la FIG. 2, el componente 227 de análisis de control de filtro y el componente 225 de filtros en bucle están muy integrados y se pueden implementar conjuntamente, pero son representados por separado con propósitos conceptuales. Los filtros aplicados a los bloques de referencia reconstruidos se aplican a las regiones espaciales particulares e incluyen múltiples parámetros para ajustar cuántos de estos filtros se aplican. El componente 227 de análisis de control de filtro analiza los bloques de referencia reconstruidos para determinar donde se deben aplicar dichos filtros y establece parámetros correspondientes. Tales datos se reenvían al componente 231 de formateo de encabezado y CABAC como datos de control de filtro para codificación. El componente 225 de filtros en bucle aplica estos filtros basándose en los datos de control de filtros. Los filtros pueden incluir un filtro de desbloqueo, un filtro de supresión de ruido, un filtro SAO, y un filtro de bucle adaptivo. Dichos filtros se pueden aplicar en el dominio espacial/de pixel (por ejemplo, en un bloque de pixel reconstruido) o en el dominio de frecuencia, dependiendo del ejemplo.
Cuando opera como un codificador, el bloque de imágenes reconstruido filtrado, el bloque residual, y/o bloque de predicción se almacenan en el componente 223 de memoria intermedia de imágenes decodificadas para uso posterior en la estimación de movimiento como se ha analizado anteriormente. Cuando opera como un decodificador, el componente 223 de memoria intermedia de imágenes decodificadas almacena y reenvía los boques reconstruidos y filtrados hacia un dispositivo de visualización como parte de una señal de video de salida. El componente 223 de memoria intermedia de imágenes decodificadas puede ser cualquier dispositivo de memoria capaz de almacenar bloques de predicción, bloques residuales y/o bloques de imágenes reconstruidas.
El componente 231 de formateo de encabezado y CABAC recibe los datos procedentes de los diversos componentes del sistema códec 200 y codifica dichos datos en un flujo de bits codificado para la transmisión hacia un decodificador. Específicamente, el componente 231 de formateo de encabezado y CABAC genera varios encabezados para codificar datos de control, tal como los datos de control general y los datos de control de filtro. Además, los datos de predicción, incluyendo datos de intra-predicción y movimiento, así como los datos residuales en la forma de datos de coeficiente de transformación cuantificados todos se codifican en el flujo de bits. El flujo de bits principal incluye toda la información deseada por el decodificador para reconstruir la señal 201 de video dividida original. Dicha información también puede incluir tablas de índice de modo de intra-predicción (también referidas como tablas de correspondencia de palabra código), definiciones de contexto de codificación para distintos bloques, indicaciones de nodos de intra-predicción más probables, una indicación de la información de división, etc. Dichos datos se pueden codificar al emplear codificación de entropía. Por ejemplo, la información se puede codificar empleando codificación de longitud variable adaptiva de contexto (CAVLC), CABAC, codificación aritmética binaria adaptiva de contexto basada en sintaxis (SBAC), codificación de entropía de división de intervalo de probabilidad (PIPE), u otra técnica de codificación de entropía. Después de la codificación de entropía, el flujo de bits codificados se puede transmitir a otro dispositivo (por ejemplo, un decodificador de video) o se puede archivar para transmisión o recuperación posterior.
La FIG. 3 es un diagrama de bloques que ilustra un codificador ejemplar 300 de video. El codificador 300 de video se puede emplear para implementar las funciones de codificación del sistema códec 200 y/o las etapas 101, 103, 105, 107, y/o 109 de implementación del método operativo 100. El codificador 300 divide una señal de video de entrada, dando como resultado una señal 301 de video dividida, que es sustancialmente similar a la señal 201 de video dividida. La señal 301 de video dividida luego se comprime y se codifica por un flujo de bits por componentes de codificador 300.
Específicamente, la señal 301 de video dividida se reenvía a un componente 317 de predicción intra-imagen para intra-predicción. El componente 317 de predicción intra-imagen puede ser sustancialmente similar al componente 215 de estimación intra-imagen y al componente 217 de predicción intra-imagen. La señal 301 de video dividida también se reenvía a un componente 321 de compensación de movimiento para inter predicción basándose en los bloques de referencia en un componente 323 de memoria intermedia de imágenes decodificadas. El componente 321 de compensación de movimiento puede ser sustancialmente similar al componente 221 de estimación de movimiento y al componente 219 de compensación de movimiento. Los bloques de predicción y los bloques residuales del componente 317 de predicción intraimagen y del componente 321 de compensación de movimiento se reenvían a un componente 313 de transformación y cuantificación para transformación y cuantificación de los bloques residuales. El componente 313 de transformación y cuantificación puede ser sustancialmente similar al componente 213 de escalamiento y cuantificación de transformación. Los bloques residuales transformados y cuantificados y los bloques de predicción correspondientes (junto con los datos de control asociados) se reenvían a un componente 331 de codificación de entropía para codificación en un flujo de bits. El componente 331 de codificación de entropía puede ser sustancialmente similar al componente 231 de formateo de encabezado y CABAC.
Los bloques residuales transformados y cuantificados y/o los bloques de predicción correspondientes también se reenvían desde el componente 313 de transformación y cuantificación a un componente 329 de transformación y cuantificación inversa para reconstrucción en bloques de referencia para uso por el componente 321 de compensación de movimiento. El componente 329 de transformación y cuantificación inversa puede ser sustancialmente similar al componente 229 de escalamiento y transformación inversa. Los filtros en bucle en un componente 325 de filtro en bucle también se aplican a los bloques residuales y/o bloques de referencia reconstruidos, dependiendo del ejemplo. El componente 325 de filtros en bucle puede ser sustancialmente similar al componente 227 de análisis de control de filtro y al componente 225 de filtros en bucle. El componente 325 de filtros en bucle puede incluir múltiples filtros como se ha analizado con respecto al componente 225 de filtros en bucle. Los bloques filtrados luego se almacenan en un componente 323 de memoria intermedia de imágenes decodificadas para usar como bloques de referencia por el componente 321 de compensación de movimiento. El componente 323 de memoria intermedia de imágenes decodificadas puede ser sustancialmente similar al componente 223 de memoria intermedia de imágenes decodificadas.
La FIG. 4 es un diagrama de bloques que ilustra un decodificador ejemplar 400 de video. El decodificador 400 de video se puede emplear para implementar las funciones de decodificación del sistema códec 200 y/o las etapas 111, 113, 115, y/o 117 de implementación para el método operativo 100. El decodificador 400 recibe un flujo de bits, por ejemplo procedentes de un decodificador 300, y genera una señal de video de salida reconstruida basándose en el flujo de bits para presentación a un usuario final.
El flujo de bits es recibido por un componente 433 de decodificación de entropía. El componente 433 de decodificación de entropía está configurado para implementar un esquema de decodificación de entropía, tal como codificación CAVLC, CABAC, SBAC, PIPE, u otras técnicas de codificación de entropía. Por ejemplo, el componente 433 de decodificación de entropía puede emplear información de encabezado para proporcionar un contexto para interpretar los datos adicionales codificados como palabras código en el flujo de bits. La información decodificada incluye cualquier información deseada para decodificar la señal de video, tal como datos de control general, datos de control de filtro, información de división, datos de movimiento, datos de predicción, y coeficientes de transformación cuantificada de bloques residuales. Los coeficientes de transformación cuantificada se reenvían a un componente 429 de transformación y cuantificación inversa para reconstrucción en bloques residuales. El componente 429 de transformación y cuantificación inversa puede ser similar al componente 329 de transformación y cuantificación inversa.
Los bloques residuales reconstruidos y/o bloques de predicción se envían al componente 417 de predicción intra-imágenes para reconstrucción en bloques de imagen basándose en las operaciones de intra-predicción. El componente 417 de predicción intra-imagen puede ser similar al componente 215 de estimación intraimagen y a un componente 217 de predicción intra-imagen. Específicamente, el componente 417 de predicción intra-imagen emplea modos de predicción para ubicar un bloque de referencia en el fotograma y aplica un bloque residual al resultado para reconstruir los bloques de imágenes intra-predichos. Los bloques de imágenes intra-predichos reconstruidos y/o los bloques residuales y los datos de inter-predicción correspondientes se reenvían a un componente 423 de memoria intermedia de imágenes decodificadas a través de un componente 425 de filtros en bucle, que puede ser sustancialmente similar al componente 223 de memoria intermedia de imágenes decodificadas y al componente 225 de filtros en bucle, respectivamente. El componente 425 de filtros en bucle filtra los bloques de imágenes reconstruidas, bloques residuales y/o bloques de predicción, y dicha información se almacena en el componente 423 de memoria intermedia de imágenes decodificadas. Los bloques de imágenes reconstruidos del componente 423 de memoria intermedia de imágenes decodificadas se reenvía a un componente 421 de compensación de movimiento para inter-predicción. El componente 421 de compensación de movimiento puede ser sustancialmente similar al componente 221 de estimación de movimiento y/o al componente 219 de compensación de movimiento. Específicamente, el componente 421 de compensación de movimiento emplea vectores de movimiento procedentes de un bloque de referencia para generar un bloque de predicción y aplica un bloque residual al resultado para reconstruir un bloque de imágenes. Los bloques reconstruidos resultantes también se pueden reenviar a través del componente 425 de filtros en bucle al componente 423 de memoria intermedia de imágenes decodificadas. El componente 423 de memoria intermedia de imágenes decodificadas continúa almacenando los bloques de imágenes reconstruidos adicionales, que se pueden reconstruir en fotogramas a través de la información de división. Dichos fotogramas también se pueden colocar en una secuencia. La secuencia se envía hacia un dispositivo de visualización como una señal de video de salida reconstruida.
La FIG. 5 es un diagrama esquemático que ilustra una CVS 500 ejemplar. Por ejemplo, la CVS 500 puede ser codificada por un codificador, tal como un sistema códec 200 y/o un codificador 300, de acuerdo con un método 100. Además, la CVS 500 puede ser decodificada por un decodificador, tal como un sistema códec 200 y/o decodificador 400. La CVS 500 incluye imágenes codificadas en un orden 508 de decodificación. Un orden 508 de decodificación es un orden en el cual las imágenes se colocan en un flujo de bits. Las imágenes de la CVS 500 luego se emiten en un orden 510 de presentación. Un orden 510 de presentación es un orden en el cual las imágenes deben ser mostradas por un decodificador para provocar que el video resultante se muestre apropiadamente. Por ejemplo, las imágenes de la CVS 500 se pueden colocar en general en el orden de presentación 510. Sin embargo, ciertas imágenes se pueden mover en diferentes ubicaciones para incrementar la eficiencia de la codificación, por ejemplo, colocando imágenes similares en proximidad más cercana para soportar la inter-predicción. El movimiento de dichas imágenes de esta manera da como resultado el orden 508 de decodificación. En el ejemplo mostrado, las imágenes se indexan en el orden 508 de decodificación de cero a cuatro. En el orden 510 de presentación, las imágenes en el índice dos y el índice tres se han movido enfrente de la imagen en el índice cero.
La CVS 500 incluye una imagen IRAP 502. Una imagen IRAP 502 es una imagen codificada de acuerdo con la intra-predicción que sirve como un punto de acceso aleatorio para la CVS 500. Específicamente, los bloques de imagen IRAP 502 se codifican por referencia a otros bloques de la imagen IRAP 502. Dado que la imagen IRAP 502 se codifica sin referencia a otras imágenes, la imagen IRAP 502 se puede decodificar sin decodificar primero cualquiera de las otras imágenes. Por consiguiente, un decodificador puede comenzar a decodificar la CVS 500 en la imagen IRAP 502. Además, la imagen IRAP 502 puede hacer que se actualice la DPB. Por ejemplo, las imágenes presentadas después de una imagen IRAP 502 pueden no depender de las imágenes anteriores a la imagen IRAP 502 (por ejemplo, índice de imagen cero) para inter-predicción. Como tal, la memoria intermedia de imágenes se puede actualizar una vez que se ha decodificado la imagen IRAP 502. Esto tiene el efecto de detener cualesquiera errores de codificación relacionados con inter predicción debido a que dichos errores no se pueden propagar a través de la imagen IRAP 502. La imagen IRAP 502 puede incluir varios tipos de imágenes. Por ejemplo, una imagen IRAP se puede codificar como una IDR o CRA. Una IDR es una imagen intra-codificada que comienza en una nueva CVS 500 y actualiza la memoria intermedia de imágenes. Una imagen de CRA es una imagen intra-codificada que actúa como un punto de acceso aleatorio sin comenzar una nueva CVS 500 o actualizar la memoria intermedia de imágenes. De esta manera, las imágenes iniciales 504 asociadas con una CRA pueden referirse a imágenes antes de la CRA, mientras que las imágenes iniciales 504 asociadas con una IDR pueden no referirse a imágenes antes de la IDR.
La CVS 500 también incluye varias imágenes no IRAP. Éstas incluyen imágenes iniciales 504 e imágenes finales 506. Una imagen inicial 504 es una imagen posicionada después de la imagen IRAP 502 en el orden 508 de decodificación, pero posicionada antes de la imagen IRAP 502 en el orden 510 de presentación. Las imágenes finales 506 se posicionan después de la imagen IRAP 502 tanto el orden 508 de decodificación como en el orden 510 de presentación. Las imágenes iniciales 504 y las imágenes finales 506 se codifican ambas de acuerdo con la inter-predicción. Las imágenes finales 506 se codifican con referencia a la imagen IRAP 502 o a las imágenes colocadas después de la imagen IRAP 502. Por tanto, las imágenes finales 506 siempre se pueden decodificar una vez que se ha decodificado la imagen IRAP 502. Las imágenes iniciales 504 pueden incluir imágenes iniciales omitidas de acceso aleatorio (RASL) e iniciales decodificables de acceso aleatorio (RADL). Una imagen RASL se codifica por referencia a las imágenes anteriores a la imagen IRAP 502, pero codificada en una posición después de la imagen IRAP 502. Ya que las imágenes RASL se basan en imágenes previas, la imagen RASL no se puede decodificar cuando el decodificador comienza a decodificar una imagen IRAP 502. Por consiguiente, las imágenes RASL se omiten y no se decodifican cuando se utiliza la imagen IRAP 502 como un punto de acceso aleatorio. Sin embargo, las imágenes RASL se decodifican y se muestran cuando el decodificador utiliza una imagen IRAP previa (antes del índice cero y no mostrada) como el punto de acceso aleatorio. Las imágenes RADL se codifican en referencia con la imagen IRAP 502 y/o imágenes después de la imagen IRAP 502, pero se posicionan antes de la imagen IRAP 502 en el orden 510 de presentación. Dado que las imágenes RADL no se basan en las imágenes anteriores a la imagen IRAP 502, las imágenes RADL se pueden decodificar y presentar cuando la imagen IRAP 502 es el punto de acceso aleatorio.
Las imágenes procedentes de la CVS 500 se pueden almacenar, cada una, en una unidad de acceso. Además, las imágenes se pueden dividir en segmentos, y los segmentos se pueden incluir en unidades NAL. Una unidad NAL es una unidad de almacenamiento que contiene un conjunto de parámetros o un segmento de una imagen y un encabezado de segmento correspondiente. Las unidades NAL son tipos asignados para indicar al decodificador el tipo de datos contenidos en la unidad NAL. Por ejemplo, los segmentos de una imagen IRAP 502 pueden estar contenidos en una IDR con unidad NAL RADL (IDR_W_RADL), una IDR con unidad NAL sin imágenes iniciales (IDR_N_LP), una unidad NAL CRA, etc. La unidad IDR_W_RADL NAL indica que la imagen IRAP 502 es una imagen IDR que se asocia con una imagen inicial RADL 504. La unidad IDR_N_LP NAL indica que la imagen IRAP 502 es una imagen IDR que no se asocia con ninguna de las imágenes iniciales 504. La unidad NAL CRA indica que la imagen IRAP 502 es una imagen CRA que se puede asociar con las imágenes iniciales 504. Los segmentos de las imágenes no IRAP también se pueden colocar en las unidades NAL. Por ejemplo, Los segmentos de las imágenes finales 506 se pueden colocar en un tipo de unidad NAL de imagen final (TRAIL_NUT), que indica que las imágenes finales 506 son imágenes codificadas de inter-predicción. Los segmentos de las imágenes iniciales 504 se pueden incluir en el tipo de unidad NAL RASL (R<a>SL_NUT) y/o un tipo de unidad NAL RADL (RADL_NUT), que pueden indicar que las imágenes correspondientes son imágenes iniciales 504 codificadas inter-predicción de los tipos correspondientes. Señalizando los segmentos de las imágenes en las unidades NAL correspondientes, el decodificador puede determinar fácilmente los mecanismos de decodificación apropiados para aplicar a cada imagen/segmento.
La FIG. 6 es un diagrama esquemático que ilustra una pluralidad de flujos 601, 602 y 603 de video de sub imágenes divididos a partir de un flujo 600 de video de imagen de VR. Por ejemplo, cada uno de los flujos 601-603 de video de sub-imágenes y/o del flujo 600 de video de imagen de Vr se pueden codificar en una CVS 500. Por consiguiente, los flujos 601-603 de video de sub-imágenes y/o el flujo 600 de video de imagen de VR pueden ser codificados por un codificador, tal como el sistema de códec 200 y/o el codificador 300, de acuerdo con el método 100. Además, los flujos 601-603 de video de sub-imágenes y/o el flujo 600 de video de imagen de VR pueden ser decodificados por un decodificador, tal como el sistema de códec 200 y/o el decodificador 400.
Un flujo 600 de video de imágenes de VR incluye una pluralidad de imágenes presentadas a lo largo del tiempo. Específicamente, la VR opera codificando una esfera de contenido de video, que se puede mostrar como si el usuario estuviera en el centro de la esfera. Cada imagen incluye la esfera completa. Mientras tanto, solo una porción de la imagen, conocida como ventana gráfica, se muestra al usuario. Por ejemplo, el usuario puede emplear un dispositivo de visualización montado en la cabeza (HMD) que selecciona y muestra una ventana gráfica de la esfera basándose en el movimiento de la cabeza del usuario. Esto proporciona la impresión de estar físicamente presente en un espacio virtual como el representado por el video. A fin de lograr este resultado, cada imagen de la secuencia de video incluye una esfera completa de datos de video en un momento correspondiente en el tiempo. Sin embargo, se muestra al usuario solo una pequeña porción (por ejemplo, una ventana gráfica individual) de la imagen. El resto de la imagen se elimina sin que se reproduzca. La imagen completa se transmite generalmente de modo que se pueda seleccionar y mostrar dinámicamente una ventana gráfica diferente en respuesta al movimiento de la cabeza del usuario.
En el ejemplo mostrado, las imágenes del flujo 600 de video de imágenes de VR se pueden subdividir cada una en sub-imágenes basadas en ventanas gráficas disponibles. Por consiguiente, cada imagen y sub imagen correspondiente incluye una posición temporal (por ejemplo, orden de las imágenes) como parte de la presentación temporal. Los flujos 601-603 de video de sub-imágenes se crean cuando la subdivisión se aplica consistentemente a lo largo del tiempo. Dicha subdivisión consistente crea flujos 601-603 de video de sub-imágenes donde cada flujo contiene un conjunto de sub-imágenes de un tamaño, forma, y posición espacial predeterminados con respecto a las imágenes correspondientes en el flujo 600 de video de imágenes de VR. Además, el conjunto de sub-imágenes en un flujo 601-603 de video de sub-imágenes varía en posición temporal durante el tiempo de presentación. Como tal, las sub-imágenes de los flujos 601-603 de video de sub-imágenes se pueden alinear en el dominio de tiempo basándose en la posición temporal. Luego, las sub-imágenes de los flujos 601-603 de video de sub-imágenes en cada posición temporal se pueden fusionar en el dominio espacial basándose en la posición espacial predefinida para reconstruir el flujo 600 de video de imágenes de VR para su visualización. Específicamente, los flujos 601-603 de video de sub imágenes se pueden codificar cada uno en sub-flujos de bits separados. Cuando estos sub-flujos de bits se fusionan juntos, dan como resultado un flujo de bits que incluye el conjunto completo de imágenes a lo largo del tiempo. El flujo de bits resultante se puede transmitir hacia el decodificador para decodificar y mostrar basándose en la ventana gráfica actualmente seleccionada por el usuario.
Uno de los problemas con el video de VR es que todos los flujos 601-603 de video de sub-imágenes se pueden transmitir a un usuario con alta calidad (por ejemplo, alta resolución). Esto permite que el decodificador seleccione dinámicamente la ventana gráfica actual del usuario y muestre la o las sub imágenes de los flujos 601-603 de video de sub-imágenes correspondientes en tiempo real. Sin embargo, el usuario solo puede ver una única ventana gráfica individual, por ejemplo, del flujo 601 de video de sub imágenes, mientras que se eliminan los flujos 602-603 de video de sub-imágenes. Como tal, la transmisión de los flujos 602-603 de video de sub-imágenes en alta calidad puede desperdiciar una cantidad significativa de ancho de banda. A fin de mejorar la eficiencia de codificación, el video de VR se puede codificar en una pluralidad de flujos 600 de video donde cada flujo 600 de video se codifica con una diferente calidad/resolución. De esta manera, el decodificador puede transmitir una solicitud para un flujo 601 de video de sub-imágenes actual. En respuesta, el codificador (o un creador de segmentos inmediatos u otro servidor de contenido) puede seleccionar el flujo 601 de video de sub-imágenes de mayor calidad a partir del flujo 600 de video de mayor calidad y de los flujos 602-603 de video de sub-imágenes de menor calidad del flujo 600 de video de menor calidad. El codificador puede luego fusionar estos sub-flujos de bits juntos en un flujo de bits codificado completo para la transmisión al decodificador. De esta manera, el decodificador recibe una serie de imágenes donde la ventana gráfica actual es de mayor calidad y las otras ventanas gráficas son de menor calidad. Además, las sub-imágenes de mayor calidad se muestran en general al usuario (ausentes de movimiento de la cabeza) y las sub-imágenes de menor calidad se eliminan en general, lo cual equilibra la funcionalidad con la eficiencia de la codificación.
En el caso de que el usuario pase de ver el flujo 601 de video de sub-imágenes al flujo 602 de video de sub imágenes, el decodificador solicita que el nuevo flujo 602 de video de sub-imágenes actual se transmita con mayor calidad. El codificador luego puede alterar el mecanismo de fusión por consiguiente. Como se observa en lo anterior, un decodificador solo puede comenzar a decodificar una nueva CVS 500 en una imagen IRAP 502. Por consiguiente, el flujo 602 de video de sub-imágenes se muestra en la menor calidad hasta que se alcanza una imagen/sub-imagen IRAP. La imagen IRAP se puede luego decodificar en mayor calidad para comenzar la decodificación de la versión de mayor calidad del flujo 602 de video de sub-imágenes. Este enfoque incrementa significativamente la compresión de video sin impactar negativamente la experiencia de visión del usuario.
Una preocupación con el enfoque mencionado anteriormente es que la duración de tiempo necesaria para cambiar las resoluciones se basa en la duración de tiempo hasta que se alcanza una imagen IRAP en el flujo de video. Esto es debido a que el decodificador es incapaz de comenzar a decodificar una versión diferente del flujo 602 de video de sub-imágenes en una imagen no IRAP. Un enfoque para reducir esta latencia es incluir más imágenes IRAP. Sin embargo, esto da como resultado un incremento en el tamaño del archivo. A de fin de equilibrar la funcionalidad con la eficiencia de codificación, diferentes flujos 601-603 de video de ventanas gráficas/sub-imágenes pueden incluir imágenes IRAP en diferentes frecuencias. Por ejemplo, los flujos 601-603 de video de ventanas gráficas/sub-imágenes que son más probables que sean observados, pueden tener más imágenes IRAP que los oros flujos 601-603 de video de ventanas gráficas/sub-imágenes. Por ejemplo, en el contexto de baloncesto, los flujos 601-603 de video de ventanas gráficas/sub-imágenes relacionados con las canastas y/o la cancha central pueden incluir imágenes IRAP a una mayor frecuencia que los flujos 601-603 de video de ventanas gráficas/sub-imágenes que ven las gradas o el techo tal como los flujos 601-603 de video de ventanas gráficas/sub-imágenes que es menos probable que sean observadas por el usuario.
Este enfoque conduce a problemas adicionales. Específicamente, las sub-imágenes de los flujos 601-603 de video de sub-imágenes que comparten un POC son parte de una sola imagen. Como se observa en lo anterior, los segmentos de una imagen se incluyen en una unidad NAL basada en un tipo de imagen. En algunos sistemas de codificación de video, todas las unidades NAL relacionadas con una sola imagen se restringen para incluir el mismo tipo de unidad NAL. Cuando diferentes flujos 601-603 de video de sub imágenes tienen imágenes IRAP en diferentes frecuencias, algunas de las imágenes incluyen tanto sub imágenes IRAP como sub-imágenes no IRAP. Esto viola la restricción de que cada imagen individual debe emplear solo unidades NAL del mismo tipo.
La presente descripción aborda este problema eliminando la restricción de que todas las unidades NAL para segmentos en una imagen empleen el mismo tipo de unidad NAL. Por ejemplo, una imagen se incluye en una unidad de acceso. Al eliminar esta restricción, una unidad de acceso puede incluir tanto tipos de unidad NAL IRAP como tipos de unidad NAL no IRAP. Además, un indicador está codificado para indicar cuando una unidad de imagen/acceso incluye una mezcla de tipos de unidad NAL IRAP y tipos de unidad NAL no IRAP. En algunos ejemplos, el indicador es un tipo de unidad NAL mixta en el indicador de imagen (mixed_nalu_types_in_pic_flag). Además, se aplica una restricción que requiere que una unidad de imagen/acceso mixta individual pueda solo contener un tipo de unidad<n>A<l>IRAP y un tipo de unidad NAL no IRAP. Esto impide que ocurran las mezclas de tipo de unidad NAL no pretendidas. Si estas mezclas se permitieron, el decodificador tendría que ser diseñado para gestionar dichas mezclas. Esto incrementaría innecesariamente la complejidad del hardware requerido sin proporcionar un beneficio adicional al proceso de codificación. Por ejemplo, la imagen mixta puede incluir un tipo de unidad NAL IRAP seleccionada a partir de IDR_W_RADL, I<d>R_N_LP, o CRA_NUT. Además, la imagen mixta puede incluir un tipo de unidad<n>A<l>no IRAP seleccionada a partir de TRAIL_NUT, RADL_NUT, y RASL_NUT. Las implementaciones ejemplares de este esquema se han analizado con más detalle a continuación.
La FIG. 7 es un diagrama esquemático que ilustra un flujo ejemplar 700 de bits que contiene imágenes con tipos de unidad NAL mixtas. Por ejemplo, el flujo 700 de bits puede ser generado por un sistema códec 200 y/o un codificador 300 para decodificación por un sistema códec 200 y/o un decodificador 400 según el método 100. Además, el flujo 700 de bits puede incluir un flujo 600 de video de imágenes de VR fusionado a partir de flujos 601-603 de video de sub-imagen múltiples en una pluralidad de resoluciones de video donde cada flujo de video de sub-imágenes contiene una CVS 500 en una diferente posición espacial.
El flujo 700 de bits incluye un conjunto 710 de parámetros de secuencia (SPS), uno más conjuntos 711 de parámetros de imagen (PPS), una pluralidad de encabezados 715 de segmento, y datos 720 de imagen. Un SPS 710 contiene datos de secuencia comunes a todas las imágenes en la secuencia de video contenidas en el flujo 700 de bits. Dichos datos pueden incluir dimensionamiento de imagen, profundidad de bit, parámetros de herramienta de codificación, restricciones de tasa de bits, etc. El PPS 711 contiene parámetros que se aplican a una imagen completa. Por tanto, cada imagen en la secuencia de videos puede referirse a un PPS 711. Se debe observar que, mientras que cada imagen se refiere a un PPS 711, un PPS 711 individual puede contener datos para múltiples imágenes en algunos ejemplos. Por ejemplo, se pueden codificar múltiples imágenes similares de acuerdo con parámetros similares. En tal caso, un<p>P<s>711 individual puede contener datos para dichas imágenes similares. El PPS 711 puede indicar herramientas de codificación disponibles para los segmentos en las imágenes correspondientes, parámetros de cuantificación, desplazamientos, etc. El encabezado 715 de segmento contiene parámetros que son específicos para cada segmento en una imagen. Por tanto, puede haber un encabezado 715 de segmento por segmento en la secuencia de video. El encabezado 715 de segmento puede contener información de tipo de segmento, cómputo del orden de imagen (POC), listas de imágenes de referencia, ponderaciones de predicción, puntos de entrada de mosaico, parámetros de desbloqueo, etc. Se debe observar que un encabezado 715 de segmento también puede ser referido como un encabezado de grupo de mosaicos en algunos contextos.
Los datos 720 de imagen contienen datos de video codificados de acuerdo con inter-predicción y/o intrapredicción así como datos residuales transformados y cuantificados correspondientes. Por ejemplo, una secuencia de video incluye una pluralidad de imágenes 721 codificadas como datos 720 de imagen. Una imagen 721 es un solo fotograma de una secuencia de video y por consiguiente se muestra en general como una sola unidad cuando se muestra la secuencia de video. Sin embargo, las sub-imágenes 723 se pueden mostrar para implementar ciertas tecnologías tal como la realidad virtual. Las imágenes 721 se refieren cada una a un PPS 711. Las imágenes 721 se pueden dividir en sub-imágenes 723, mosaicos, y/o segmentos. Una sub-imagen 723 es una región espacial de una imagen 721 que se aplica consistentemente sobre una secuencia de video codificada. Por consiguiente, una sub-imagen 723 puede ser presentada por un HMD en un contexto de VR. Además, una sub-imagen 723 con un POC especificado se puede obtener a partir de un flujo 601-603 de video de sub-imágenes en una resolución correspondiente. Una sub-imagen 723 puede referirse a la SPS 710. En algunos sistemas, los segmentos 725 son referidos como grupos de mosaicos que contienen mosaicos. Los segmentos 725 y/o grupos de mosaicos de los mosaicos se refieren a un encabezado 715 de segmento. Un segmento 725 se puede definir como un número entero de mosaicos completos o un número entero de filas de CTU completas consecutivas dentro del mosaico de una imagen 721 que están exclusivamente contenidos en una unidad NAL individual. Por tanto, los segmentos 725 se dividen adicionalmente en CTU y/o CTB. Los CTU/CTB se dividen adicionalmente en bloques de codificación basándose en árboles de codificación. Los bloques de codificación se pueden luego codificar/decodificar de acuerdo con los mecanismos de predicción.
Los conjuntos de parámetros y/o segmentos 725 se codifican en unidades NAL. Una unidad NAL se puede definir como una estructura de sintaxis que contiene una indicación del tipo de datos a seguir y bytes que contienen esos datos en forma de un RBSP intercalado según sea necesario con los bytes de prevención de emulación. Más específicamente, una unidad NAL es una unidad de almacenamiento que contiene un conjunto de parámetros o un segmento 725 de una imagen 721 y un encabezado 715 de segmento correspondiente. Específicamente, las unidades NAL VCL 740 son unidades NAL que contienen un segmento 725 de una imagen 721 y un encabezado 715 de segmento correspondiente. Además, la unidades NAL no VCL 730 contienen conjuntos de parámetros, tal como el SPS 710 y el PPS 711. Pueden emplearse varios tipos de unidades NAL. Por ejemplo, el SPS 710 y el PPS 711 se pueden incluir en un tipo de unidad NAL SPS (SPS_NUT) 731 y un tipo de unidad NAL PPS (PPS_NUT) 732, respectivamente, las cuales son ambas unidades NAL no VCL 730.
Como se ha observado anteriormente, las imágenes IRAP, tales como la imagen IRAP 502, pueden estar contenidas en las unidades NAL IRAP 745. Las imágenes no IRAP, tal como las imágenes iniciales 504 y las imágenes finales 506, pueden estar incluidas en las unidades NAL no IRAP 749. Específicamente, una unidad NAL IRAP 745 es cualquier unidad NAL que contiene un segmento 725 tomado a partir de una imagen o sub-imagen IRAP. Una unidad NAL no IRAP 749 es cualquier unidad NAL que contiene un segmento 725 tomado a partir de cualquier imagen que no sea la imagen o sub-imagen IRAP (por ejemplo, imágenes iniciales o imágenes finales). Las unidades NAL IRAP 745 y las unidades NAL no IRAP 749 son ambas unidades NAL VCL 740 ya que ambas contienen datos de segmento. En una realización ejemplar, una unidad NAL IRAP 745 puede incluir segmento 725 de una imagen de IDR sin imágenes iniciales o una IDR asociada con imágenes RADL en una unidad NAL 741 IDR_N_LP o una unidad IDR_w_RADL NAL 742, respectivamente. Además, una unidad NAL IRAP 745 puede incluir segmentos 725 procedentes de una imagen CRA en una CRA_NUT 743. En una realización ejemplar, una unidad NAL no IRAP 749 puede incluir segmentos 725 procedentes de una imagen RASL, una imagen RADL, o una imagen final, en una RASL_NUT 746, una RADL_NUT 747, o una TRAIL_NUT 748, respectivamente. En una realización ejemplar, una lista completa de posibles unidades NAL se muestra a continuación como es clasificada por el tipo de unidad NAL.
Como se ha indicado anteriormente, un flujo de video de VR puede incluir sub-imágenes 723 con imágenes IRAP en diferentes frecuencias. Esto permite que se empleen pocas imágenes IRAP para regiones espaciales que un usuario no es probable que busque y que se empleen más imágenes IRAP para regiones espaciales que un usuario es probable que vea a menudo. De esta manera, las regiones espaciales que el usuario a las que es probable que vuelva, regularmente se pueden ajustar rápidamente a una mayor resolución. Cuando este enfoque da como resultado una imagen 721 que incluye tanto unidades NAL IRAP 745 como unidades NAL no IRAP 749, la imagen 721 es referida como una imagen mixta. Esta condición se puede señalizar mediante tipos de unidad NAL mixtas en el indicador de imagen (mixed_nalu_types_in_pic_flag) 727. El mixed_nalu_types_in_pic_flag 727 se establece en el PPS 711. Además, el mixed_nalu_types_in_pic_flag 727 se puede establecer igual a uno cuando se especifica que cada imagen 721 que se refiere al PPS 711 tiene más de una unidad NAL VCL 740 y las unidades NAL VCL 740 no tienen el mismo valor del tipo de unidad NAL (nal_unit_type). Además, el mixed_nalu_types_in_pic_flag 727 se puede establecer igual a cero cuando cada imagen 721 que se refiere al PPS 711 tiene una o más unidades NAL VCL 740 y las unidades NAL VCL 740 de cada imagen 721 que se refieren al PPS 711 tienen todas el mismo valor de nal_unit_type.
Además, se emplea una restricción de tal modo que las unidades NAL VCL 740 de una o más de las sub imágenes 723 de la imagen 721 tienen todas un primer valor particular de tipo de unidad NAL y otras unidades NAL VCL 740 en la imagen 721 tienen todas un segundo valor particular diferente del tipo de unidad NAL cuando el mixed_nalu_types_in_pic_flag 727 es establecido. En particular, la restricción requiere que una imagen mixta 721 contenga un solo tipo de unidad NAL IRAP 745 y un solo tipo de unidad NAL no IRAP 749. Por ejemplo, la imagen 721 puede incluir una o más unidades NAL IDR_N_LP 741, una o más unidades NAL IDR_W_RADL 742, o una o más CRA_NUTs 743, pero no cualquier combinación de dichas unidades NAL IRAP 745. Además, la imagen 721 puede incluir una o más RASL_NUTs 746, una o más RADL_NUTs 747, o una o más TRAIL_NUTs 748, pero no cualquier combinación de estas unidades NAL IRAP 745.
En una implementación ejemplar, se emplean tipos de imágenes para definir procesos de decodificación. Dichos procesos incluyen derivación de la identificación de la imagen, por ejemplo, por cómputo de orden de la imagen (POC), marcando el estado de imágenes de referencia en la memoria intermedia de imágenes decodificadas (DPB), salidas de imágenes procedentes de la DPB, etc. Una imagen se puede identificar por el tipo basándose en el tipo de unidad NAL que contiene toda la imagen codificada o una sub-porción de la misma. En algunos sistemas de codificación de video, los tipos de imágenes pueden incluir imágenes de actualización de decodificación instantánea (IDR) e imágenes no IDR. En otros sistemas de codificación de video, los tipos de imágenes pueden incluir imágenes finales, imágenes de acceso de subcapa temporal (TSA), imágenes de acceso de subcapa temporal de modo escalonado (STSA), imágenes iniciales decodificables de acceso aleatorio (RADL), imágenes iniciales omitidas de acceso aleatorio (RASL), imágenes de acceso de enlace roto (BLA), imágenes de acceso aleatorio instantáneo e imágenes de acceso aleatorio limpio. Dichos tipos de imágenes se pueden diferenciar además basándose en si la imagen es una imagen referenciada de subcapa o una imagen no referenciada de subcapa. Una imagen BLA se puede diferenciar además como BLA con imagen inicial, BLA con imagen RADL, y BLA sin imagen inicial. Una imagen IDR se puede diferenciar además como una IDR con imagen RADL y una IDR sin imagen inicial.
Tales tipos de imágenes se pueden emplear para implementar varias funciones relacionadas con el video. Por ejemplo, se pueden emplear imágenes IDR, BLA y/o CRA para implementar una imagen IRAP. Una imagen IRAP puede proporcionar las siguientes funcionalidades/beneficios. La presencia de una imagen IRAP puede indicar que se puede iniciar un proceso de decodificación a partir de esa imagen. Esta funcionalidad permite la implementación de una característica de acceso aleatorio en la que un proceso de decodificación comienza en una posición designada en un flujo de bits mientras que una imagen IRAP está presente en esa posición. Dicha posición no es necesaria en el comienzo de un flujo de bits. La presencia de una imagen IRAP también actualiza un proceso de decodificación de tal modo que las imágenes codificadas que comienzan en la imagen IRAP, excluyendo las imágenes RASL, se codifican sin ninguna referencia a las imágenes posicionadas antes de la imagen IRAP. Por consiguiente, una imagen IRAP posicionada en un flujo de bits detiene la propagación de los errores de decodificación. Por tanto, los errores de decodificación de las imágenes codificadas posicionadas antes de la imagen IRAP no se pueden propagar a través de la imagen IRAP y a las imágenes que siguen a la imagen IRAP en el orden de decodificación.
Las imágenes IRAP proporcionan varias funcionalidades, pero crean una penalización para la eficiencia de compresión. Por consiguiente, la presencia de una imagen IRAP puede provocar una sobrecarga en la tasa de bits. Esta penalización a la eficiencia de compresión tiene varias causas. Por ejemplo, una imagen IRAP es una imagen intra-predicha que es representada significativamente por más bits que las imágenes interpredichas utilizadas como imágenes no IRAP. Además, la presencia de una imagen IRAP rompe la predicción temporal utilizada en la inter-predicción. Específicamente, la imagen IRAP actualiza el proceso de decodificación eliminando las imágenes de referencia previas de la DPB. La eliminación de las imágenes de referencia previas reduce la disponibilidad de imágenes de referencia para su uso en la codificación de imágenes que siguen a la imagen IRAP en el orden de decodificación, y por tanto reduce la eficiencia de este proceso.
Las imágenes IDR pueden emplear diferentes procesos de señalización y derivación que otros tipos de imágenes IRAP. Por ejemplo, los procesos de señalización y derivación relacionados con IDR pueden establecer la parte del bit más significativa (MSB) del POC en cero en lugar de derivar el MSB de una imagen clave previa. Además, un encabezado de segmento de una imagen IDR puede no contener información utilizada para ayudar en la gestión de la imagen de referencia. Mientras tanto, otros tipos de imágenes, tal como CRA, finales, TSA, etc., pueden contener información de imagen de referencia tal como un conjunto de imágenes de referencia (RPS) o una lista de imágenes de referencia, que se pueden emplear para implementar el proceso de marcación de imágenes de referencia. El proceso de marcación de imágenes de referencia es el proceso de determinación del estado de las imágenes de referencia en el DPB ya sean utilizadas para referencia o no utilizadas para referencia. Para las imágenes IDR, dicha información puede no ser señalizada porque la presencia de IDR que indica que el proceso de decodificación marcará simplemente todas las imágenes de referencia en la DPB como no utilizadas para referencia.
Además de los tipos de imágenes, la identificación de la imagen por POC también se emplea para múltiples propósitos, tal como para usar la gestión de imágenes de referencia en inter-predicción, para emitir imágenes procedentes de la DPB, para escalamiento de vectores de movimiento, para predicción ponderada, etc. Por ejemplo, en algunos sistemas de codificación de video, las imágenes en la DPB se pueden marcar como utilizadas para referencia a corto plazo, utilizadas para referencia a largo plazo, o no utilizadas para referencia. Una vez que una imagen se ha marcado no utilizada para referencia, la imagen ya no puede ser utilizada para predicción. Cuando está imagen ya no es necesaria para la emisión de la imagen se puede eliminar de la DPB. En otros sistemas de codificación de video, se pueden marcar las imágenes de referencia como a corto plazo y a largo plazo. Una imagen de referencia se puede marcar como no utilizada para referencia cuando la imagen ya no es necesaria para referencia de predicción. La conversión entre estos estados puede ser controlada mediante el proceso de marcación de imágenes de referencia decodificadas. Un proceso de ventana deslizante implícita y/o un proceso de operación de control de gestión de memoria explícita (MMCO) se puede emplear como mecanismos de marcación de imágenes de referencia decodificadas. El proceso de ventana deslizante marca una imagen de referencia a corto plazo como no utilizada para referencia cuando el número de fotogramas de referencia es igual a un número máximo especificado indicado como max_num_ref_frames en el SPS. Las imágenes de referencia a corto plazo se pueden almacenar en una manera primero en entrar-primero en salir de modo que las imágenes a corto plazo decodificadas más recientemente son retenidas en la DPB. El proceso MMCO explícito puede incluir múltiples comandos de MMCO. Un comando MMCO puede marcar una o más imágenes de referencia a corto plazo o a largo plazo como no utilizadas para referencia, marcar todas las imágenes como no utilizadas para referencia, o marcar la imagen de referencia actual o una imagen de referencia a corto plazo existente como a largo plazo y asignar un índice de imagen a largo plazo a esa imagen de referencia a largo plazo.
En algunos sistemas de codificación de video de las operaciones de marcación de imagen de referencia, así como los procesos de emisión y eliminación de imágenes de la DPB son realizados después de que una imagen haya sido decodificada. Otros sistemas de codificación de video emplean un RPS para gestión de imágenes de referencia. La diferencia más fundamental entre el mecanismo RPS y el proceso de MMCO/ventana deslizante es que para cada segmento particular el RPS proporciona un conjunto completo de las imágenes de referencia que son utilizadas por la imagen actual o cualquier imagen subsiguiente. Así, un conjunto completo de todas las imágenes que se deben mantener en la DPB para uso por la imagen actual o futura se señalizan en el RPS. Esto es diferente del esquema de MMCO/ventana deslizante donde solo los cambios relativos a la DPB se señalizan. Con el mecanismo RPS, no es necesaria información procedente de las imágenes anteriores en el orden de decodificación para mantener el estado correcto de imágenes de referencia en la DPB. El orden de decodificación de imágenes y operaciones de la DPB se alteran en algunos sistemas de codificación de video a fin de explotar las ventajas de RPS y mejorar la resiliencia del error. En algunos sistemas de codificación de video, las operaciones de marcación y almacenamiento en la memoria intermedia de la imagen que incluyen tanto emisión como eliminación de imágenes decodificadas procedentes de la DPB se pueden aplicar después de que se haya decodificado una imagen actual. En otros sistemas de codificación de video, el RPS es decodificado primero procedente de un encabezado de segmento de la imagen actual, y luego se pueden aplicar operaciones de marcación y almacenamiento en la memoria intermedia de imagen antes de decodificar la imagen actual.
En la VVC, el enfoque de gestión de imágenes de referencia se puede resumir como sigue. Dos listas de imágenes de referencia, indicadas como lista 0 y lista 1, se señalizan y se derivan directamente. No se basan en RPS o en la ventana deslizante más el proceso MMCO como se ha analizado anteriormente. La marcación de la imagen de referencia se basa directamente en las listas 0 y 1 de imágenes de referencia que utilizan tanto entradas activas como inactivas en las listas de imágenes de referencia, mientras que solo las entradas activas se pueden utilizar como índices de referencia en la inter-predicción de la CTU. La información para derivación de las dos listas de imágenes de referencia se señaliza por los elementos de sintaxis y estructuras de sintaxis en el SPS, el PPS y el encabezado del segmento. Las estructuras RPL predefinidas se señalizan en el SPS para uso mediante referencia en el encabezado del segmento. Las dos listas de imágenes de referencia se generan para todos los tipos de segmentos, incluyendo segmentos de inter-predicción bidireccional (B), segmentos de inter-predicción unidireccional (P) y segmentos de intrapredicción (I). Las dos listas de imágenes de referencia se pueden construir sin utilizar un proceso de inicialización de listas de imágenes de referencia o un proceso de modificación de lista de imágenes de referencia. Las imágenes de referencia a largo plazo (LTRP) se identifican por POC LSB. Los ciclos POC MSB Delta se pueden señalizar para LTRP como es determinado por una base de imagen por imagen.
A fin de codificar una imagen de video, la imagen es dividida en primer lugar, y las divisiones se codifican en un flujo de bits. Hay disponibles varios esquemas de división de imágenes. Por ejemplo, una imagen se puede dividir en segmentos regulares, segmentos dependientes, mosaicos y/o de acuerdo con el Procesamiento Paralelo de Frente de Onda (WPP). Por simplicidad, HEVC restringe codificadores de modo que solo los segmentos regulares, segmentos dependientes, mosaicos, WPP, y combinaciones de los mismos se pueden utilizar cuando se divide un segmento en grupos de CTB para codificación de video. Esta división se puede aplicar para soportar la coincidencia de tamaño de la Unidad de Transferencia Máxima (MTU), procesamiento paralelo, y retraso de extremo a extremo reducido. La MTU indica la cantidad máxima de datos que se pueden transmitir en un solo paquete. Si una carga útil de un paquete excede la MTU, esa carga útil se divide en dos paquetes a través de un proceso llamado fragmentación.
Un segmento regular, también referido simplemente como un segmento, es una porción dividida de una imagen que se puede reconstruir independientemente de otros segmentos regulares dentro de la misma imagen, no obstante algunas interdependencias debidas a las operaciones de filtración en bucle. Cada segmento regular es encapsulado en su propia unidad de Capa de Abstracción de Red (NAL) para transmisión. Además, la predicción en la imagen (intra-predicción de muestras, predicción de información de movimiento, predicción de modo de codificación) y dependencia de codificación de entropía a través de límites de segmentos se pueden deshabilitar para soportar la reconstrucción independiente. Dicha reconstrucción independiente soporta la paralelización. Por ejemplo, la paralelización basada en segmentos regulares emplea comunicación inter-procesador o inter-núcleo mínima. Sin embargo, como cada segmento regular es independiente, cada segmento se asocia con un encabezado de segmento separado. El uso de segmentos regulares puede incurrir en un encabezado de codificación sustancial debido al costo de bits del encabezado de segmento para cada segmento y debido a la falta de predicción a través de los límites del segmento. Además, los segmentos regulares se pueden emplear para soportar la coincidencia para los requisitos de tamaño de la MTU. Específicamente, como un segmento regular está encapsulado en una unidad NAL separada y se puede codificar independientemente, cada segmento regular debe ser más pequeño que la MTU en los esquemas de MTU para evitar la rotura del segmento en múltiples paquetes. Como tal, el objetivo de la paralelización y el objetivo de la coincidencia de tamaño de la MTU pueden imponer demandas contradictorias a una configuración de segmento en una imagen.
Los segmentos dependientes son similares a los segmentos regulares, pero tienen encabezados de segmento acortados y permiten la división de los límites del bloque de árbol de la imagen sin rotura de la predicción en la imagen. Por consiguiente, los segmentos dependientes permiten que un segmento regular sea fragmentado en múltiples unidades NAL, lo que proporciona retraso de extremo a extremo reducido al permitir que una parte de un segmento regular sea enviada antes de que la codificación del segmento regular completo se haya completado.
Las imágenes se pueden dividir en grupos/segmentos de mosaicos y mosaicos. Un mosaico es una secuencia de CTU que cubre una región rectangular de una imagen. Un grupo/segmento de mosaicos contiene un número de mosaicos de una imagen. El modo de grupo de mosaicos de escaneo de trama y el modo de grupo de mosaicos rectangulares se pueden emplear para crear mosaicos. En el modo de grupo de mosaicos de escaneo de trama, un grupo de mosaicos contiene una secuencia de mosaicos en el escaneo de fotogramas de mosaicos de una imagen. En el modo de grupo de mosaicos rectangulares, un grupo de mosaicos contiene un número de mosaicos de una imagen que forman colectivamente una región rectangular de la imagen. Los mosaicos dentro de un grupo de mosaicos rectangulares están en el orden de escaneo de trama de mosaico del grupo de mosaicos. Por ejemplo, un mosaico puede ser una porción dividida de una imagen creada por límites horizontales y verticales que crean columnas y filas de mosaicos. Los mosaicos se pueden codificar en el orden de escaneo de trama (derecha a izquierda y de arriba a abajo). El orden de escaneo de los CTB es local dentro de un mosaico. Por consiguiente, los CTB en un primer mosaico se codifican en el orden de escaneo de trama, antes de proseguir a los CTB en el siguiente mosaico. Similar a los segmentos regulares, los mosaicos rompen dependencias de la predicción en la imagen, así como dependencias de decodificación de entropía. Sin embargo, los mosaicos no se pueden incluir en las unidades NAL individuales, y por tanto los mosaicos no se pueden utilizar para coincidencia de tamaño de la MTU. Cada mosaico se puede procesar por un procesador/núcleo, y la comunicación inter-procesador/inter-núcleo empleada para predicción en imagen entre las unidades de procesamiento que decodifican los mosaicos contiguos puede limitarse a transportar un encabezado de segmento compartido (cuando los mosaicos adyacentes están en el mismo segmento), y realizar el intercambio relacionado con la filtración en bucle de las muestras y metadatos reconstruidos. Cuando más de un mosaico está incluido en un segmento, el desplazamiento de byte de punto de entrada para cada mosaico distinto del primer desplazamiento del punto de entrada en el segmento se puede señalizar en el encabezado de segmento. Para cada segmento y mosaico, se debe cumplir al menos una de las siguientes condiciones: 1) todos los bloques de árboles codificados en un segmento pertenecen al mismo mosaico; y 2) todos los bloques de árboles codificados en un mosaico pertenecen al mismo segmento.
En WPP, la imagen se divide en filas individuales de CTB. Los mecanismos de decodificación y predicción de entropía pueden utilizar datos procedentes de los CTB en otras filas. El procesamiento paralelo se hace posible a través de la decodificación paralela de filas de CTB. Por ejemplo, una fila actual se puede decodificar en paralelo con una fila precedente. Sin embargo, la decodificación de la fila actual se retrasa del proceso de decodificación de las filas precedentes por dos CTB. Este retraso asegura que los datos relacionados con el CTB anterior y el CTB anterior y a la derecha del CTB actual en la fila actual están disponibles antes de que se codifique el CTB actual. Este enfoque aparece como un frente de onda cuando se representa gráficamente. Este inicio escalonado permite la paralelización con hasta muchos procesadores/núcleos ya que la imagen contiene filas de CTB. Debido a que se permite la predicción en imagen entre las filas de bloques de árboles contiguos dentro de una imagen, la comunicación interprocesador/inter-núcleo para permitir la predicción en imagen pueda ser sustancial. La división de WPP no considera tamaños de unidad NAL. Por consiguiente, WPP no soporta la coincidencia de tamaño de la MTU. Sin embargo, se pueden utilizar segmentos regulares en combinación con WPP, con cierta sobrecarga de codificación, para implementar la coincidencia de tamaño de la MTU según se desee. Finalmente, un segmento de frente de onda puede contener exactamente una fila de CTB. Además, cuando se emplea WPP y cuando un segmento comienza dentro de una fila de CTB, el segmento debe finalizar en la misma fila de CTB.
Los mosaicos también pueden incluir conjuntos de mosaicos restringidos de movimiento. Un conjunto de mosaicos restringidos de movimiento (MCTS) es un conjunto de mosaicos diseñados de tal modo que los vectores de movimiento asociados se restringen para apuntar a ubicaciones de muestras completas dentro del MCTS y a ubicaciones de muestra fraccionaria que requieren solo ubicaciones de muestra completa dentro del MCTS para interpolación. Además, no se permite el uso de candidatos de vector de movimiento para la predicción de vectores de movimiento temporal derivados de bloques fuera del MCTS. De esta manera, cada MCTS puede ser decodificado independientemente sin la existencia de mosaicos no incluidos en el MCTS. Los mensajes de información de mejora complementaria (SEI) de MCTS temporales se pueden utilizar para indicar la existencia de MCTS en el flujo de bits y señalizar los MCTS. El mensaje SEI de MCTS proporciona información complementaria que se puede utilizar en la extracción del sub-flujo de bits MCTS (especificado como parte de la semántica del mensaje SEI) para generar un flujo de bits conforme para un conjunto de MCTS. La información incluye varios conjuntos de información de extracción, cada uno de los cuales define un número de conjuntos de MCTS y contiene bytes de carga útil de secuencia de bytes sin procesar (RBSP) del conjunto de parámetros de video de sustitución (VPS), conjuntos de parámetros de secuencia (SPS) y conjuntos de parámetros de imagen (PPS) que se han de utilizar durante el proceso de extracción del sub-flujo de bits MCTS. Cuando la extracción del sub-flujo de bits de acuerdo con el proceso de extracción del sub-flujo de bits MCTS, los conjuntos de parámetros (VPS, SPS, y PPS) se pueden reescribir o reemplazar, y los encabezados de segmento pueden actualizarse debido a que uno o todos los elementos de sintaxis relacionados con la dirección del segmento (incluido first_slice_segment_in_pic_flag y slice_segment_address) pueden emplear diferentes valores en el sub-flujo de bits extraídos.
Las aplicaciones de VR, también referidas como aplicaciones de video de 360 grados, pueden mostrar solo parte de una esfera completa y en consecuencia solo un subconjunto de una imagen completa. Un suministro dependiente de ventana gráfica 360 sobre la transmisión adaptiva dinámica sobre el mecanismo de protocolo de transferencia de hipertexto (DASH) puede ser empleado para reducir la tasa de bits y el suministro de soporte de video de 360 grados a través de mecanismos de transmisión. Este mecanismo divide la esfera/imagen proyectada en múltiples MCTS, por ejemplo empleando la proyección de mapas de cubos (CMP). Dos o más flujos de bits se pueden codificar con diferentes resoluciones o calidades espaciales. Cuando se suministran datos al decodificador, los MCTS procedentes de un flujo de bits de mayor resolución/calidad se transmiten para la ventana gráfica para que sean mostrados (por ejemplo, la ventana gráfica frontal). Los MCTS procedentes de los flujos de bits de menor resolución/calidad se transmiten para las otras ventanas gráficas. Estos MCTS se empaquetan en una cierta forma y luego se envían al receptor para ser decodificados. La expectación es que la ventana gráfica vista por el usuario es representada por un MCTS de alta resolución/calidad para crear una experiencia de visión positiva. Cuando la cabeza del usuario se mueve para ver otra ventana gráfica (por ejemplo, la ventana gráfica izquierda o derecha), el contenido mostrado proviene de la ventana gráfica de menor resolución/calidad durante un período corto mientras el sistema está obteniendo los MCTS de alta resolución/calidad para la nueva ventana gráfica. Cuando la cabeza del usuario se gira para ver otra ventana gráfica, hay un retraso entre el momento en que la cabeza del usuario se gira y el momento en el que se ve una representación de mayor resolución/calidad de la ventana gráfica. Este retraso depende de cómo de rápido pueda obtener el sistema los MCTS de mayor resolución/calidad para esa ventana gráfica, lo que a su vez depende del período IRAP. El período IRAP es el intervalo entre las ocurrencias de dos IRAP. Este retraso se refiere al período IRAP debido a que los MCTS de la nueva ventana gráfica solo pueden ser decodificables comenzando desde una imagen IRAP.
Por ejemplo, si el período IRAP es codificado cada segundo entonces se aplica lo siguiente. El mejor escenario para el retraso es el mismo que el retraso de viaje de ida y vuelta de red si la cabeza del usuario se gira para ver la nueva ventana gráfica justo antes de que el sistema comience a obtener el nuevo segmento/período de IRAP. En este escenario, el sistema sería capaz de solicitar los MCTS de mayor resolución/calidad para la nueva ventana gráfica de manera instantánea, y de esta manera solo el retraso es el retraso del viaje de ida y vuelta de la red, que es el retraso de la solicitud de obtención más el tiempo de transmisión de los MCTS solicitados, asumiendo que el retraso del almacenamiento en la memoria intermedia mínimo se puede establecer en aproximadamente cero y el retraso del sensor es pequeño y despreciable. El retraso del viaje de ida y vuelta de la red puede ser de aproximadamente doscientos milisegundos, por ejemplo. En el peor de los escenarios para el retraso es el retraso de período IRAP viaje de ida y vuelta de red si la cabeza del usuario gira para ver la nueva ventana gráfica justo después de que el sistema ya haya solicitado el siguiente segmento. Los flujos de bits se pueden codificar con imágenes IRAP más frecuentes de modo que el período IRAP es más corto para mejorar el peor de los escenarios anterior, ya que esto reduce el retraso completo. Sin embargo, este enfoque incrementa los requisitos de ancho de banda ya que la eficiencia de la compresión se reduce.
En una implementación ejemplar, las sub-imágenes de la misma imagen codificada se permite que contengan diferentes valores nal_unit_type. Este mecanismo se describe a continuación. Las imágenes se pueden dividir en sub-imágenes. Una sub-imagen es un conjunto rectangular de grupos/segmentos de mosaicos que comienza con un grupo de mosaicos que tiene un tile_group_address igual a cero. Cada sub imagen puede referirse a un PPS correspondiente y por tanto puede tener una división de mosaico separada. La existencia de sub-imágenes puede ser indicada en el PPS. Cada sub-imagen se trata como una imagen en el proceso de decodificación. La filtración en bucle a través de los límites de la sub-imagen siempre puede ser deshabilitada. El ancho y la altura de la sub-imagen se pueden especificar en unidades de tamaños de CTU de luma. La ubicación de una sub-imagen en una imagen puede no estar señalizada, pero puede derivarse utilizando la siguiente regla. La sub-imagen toma la siguiente ubicación sin ocupar en el orden de escaneo de trama de la CTU dentro de una imagen que es lo bastante grande para contener la sub-imagen dentro de los límites de la imagen. Las imágenes de referencia para decodificar cada sub-imagen se generan extrayendo el área colocada con la sub-imagen actual de las imágenes de referencia en la memoria intermedia de imágenes decodificadas. El área extraída es una sub-imagen decodificada y, por lo tanto, la inter-predicción tiene lugar entre sub-imágenes del mismo tamaño y la misma ubicación dentro de la imagen. En tal caso, permitir diferentes valores nal_unit_type dentro de una imagen codificada permite que las sub imágenes que se originan a partir de una imagen de acceso aleatorio y las sub-imágenes que se originan a partir de una imagen de acceso no aleatorio se fusionen en la misma imagen codificada sin dificultad sustancial (por ejemplo, sin modificaciones de nivel VCL). Tal beneficio también vale para la codificación basada en McTS.
Permitir diferentes valores de nal_unit_type dentro de una imagen codificada puede ser beneficioso en otros escenarios. Por ejemplo, un usuario puede mirar algunas áreas de un contenido de video de 360 grados con más frecuencia que otras áreas. Para crear un mejor equilibrio entre la eficiencia de codificación y la latencia de cambio de la ventana gráfica de calidad comparable promedio en MCTS/suministro de video de 360 grados dependiente de la ventana gráfica basada en sub-imágenes, se pueden codificar imágenes IRAP más frecuentes para áreas más comúnmente contempladas que las otras áreas. La latencia de cambio de ventana gráfica de calidad comparable es la latencia experimentada por el usuario cuando cambia desde una primera ventana gráfica a una segunda ventana gráfica hasta que la calidad de presentación de la segunda ventana gráfica alcanza una calidad de presentación comparable a la de la primera ventana gráfica.
Otra implementación emplea las siguientes soluciones para el soporte de tipos de unidad NAL mixta dentro de una imagen, incluida la derivación de POC y la gestión de imágenes de referencia. Un indicador (sps_mixed_tile_groups_ in_pic_flag) está presente en un conjunto de parámetros al que los grupos de mosaicos hacen referencia directa o indirectamente para especificar si puede haber o no imágenes con sub imágenes IRAP y no IRAP mezcladas. Para una unidad NAL que contiene un grupo de mosaicos IDR, un indicador (poc_msb_reset_flag) está presente en un encabezado de grupo de mosaicos correspondiente para especificar si el POC MSB se reinicia o no en la derivación de POC para la imagen. Se define una variable denominada PicRefreshFlag y se asocia con una imagen. Este indicador especifica si la derivación de POC y el estado de DPB deben actualizarse al decodificar la imagen. El valor de PicRefreshFlag se deriva de la siguiente manera. Si el grupo de mosaicos actual está incluido en la primera unidad de acceso en el flujo de bits, PicRefreshFlag se establece igual a uno. De lo contrario, si el grupo de mosaicos actual es un grupo de mosaicos IDR, PicRefreshFlag se establece igual a sps_mixed_tile_groups_in_pic_flag ? poc_msb_reset_flag : 1. De lo contrario, si el grupo de mosaicos actual es un grupo de mosaicos<c>R<a>, se aplica lo siguiente. Si la unidad de acceso actual es la primera unidad de acceso de una secuencia codificada, PicRefreshFlag se establece igual a uno. La unidad de acceso actual es la primera unidad de acceso de una secuencia codificada cuando la unidad de acceso sigue inmediatamente a una unidad NAL de fin de secuencia o la variable asociada HandleCraAsFirstPicInCvsFlag se establece igual a uno. De lo contrario, PicRefreshFlag se establece igual a cero (por ejemplo, el grupo de mosaicos actual no pertenece a la primera unidad de acceso en el flujo de bits y no es un grupo de mosaicos IRAP).
Cuando PicRefreshFlag es igual a uno, el valor de POC MSB (PicOrderCntMsb) se restablece para que sea igual a cero durante la derivación de POC para la imagen. La información empleada para la gestión de imágenes de referencia, tal como el conjunto de imágenes de referencia (RPS) o la lista de imágenes de referencia (RPL), se señaliza en el encabezado del grupo/segmento de mosaicos independientemente del tipo de unidad NAL correspondiente. Las listas de imágenes de referencia se construyen al comienzo de la decodificación de cada grupo de mosaicos independientemente del tipo de unidad NAL. Las listas de imágenes de referencia pueden incluir RefPicList[ 0 ] y RefPicList[ 1 ] para un enfoque RPL, RefPicList0[ ] y RefPicList1[ ] para un enfoque RPS, o listas similares que contienen imágenes de referencia para operaciones de inter-predicción para una imagen. Cuando PicRefreshFlag es igual a uno, durante el proceso de marcación de la imagen de referencia, todas las imágenes de referencia en el DPB se marcan como no utilizadas como referencia.
Tales implementaciones están asociadas con ciertos problemas. Por ejemplo, cuando no se permite la mezcla de valores nal_unit_type dentro de una imagen y cuando la derivación de si una imagen es una imagen IRAP y la derivación de la variable NoRaslOutputFlag se describen a nivel de imagen, el decodificador puede realizar estas derivaciones después de recibir la primera unidad NAL VCL de cualquier imagen. Sin embargo, debido al soporte de tipos de unidades nAl mixtas dentro de una imagen, el decodificador tendría que esperar la llegada de otras unidades NAL VCL de una imagen antes de realizar las derivaciones anteriores. En el peor de los casos, el decodificador tendría que esperar la llegada de la última unidad NAL VCL de una imagen. Además, dichos sistemas pueden señalizar un indicador en los encabezados del grupo de mosaicos de las unidades IDR NAL para especificar si POC MSB se reinicia o no en la derivación de POC para la imagen. Este mecanismo tiene los siguientes problemas. El caso de tipos de unidades CRA NAL mezcladas y tipos de unidades NAL no IRAP no sería soportado por este mecanismo. Además, la señalización de esta información en el encabezado de grupo/segmento de mosaicos de la unidad NAL VCL requeriría que se cambiara el valor durante la extracción del flujo de bits o la fusión cuando se produzca un cambio en el estado de si las unidades NAL IRAP (IDR o CRA) se mezclan con unidades NAL no IRAP en una imagen. Dicha reescritura de los encabezados de los segmentos ocurriría cada vez que un usuario solicite el video y, por lo tanto, requiere importantes recursos de hardware. Además, se permiten algunas otras mezclas de diferentes tipos de unidades NAL dentro de una imagen distintas de la mezcla de un tipo de unidad NAL IRAP particular y un tipo de unidad NAL no IRAP particular. Tal flexibilidad no proporciona soporte para casos de uso prácticos mientras que complica el diseño del códec, lo que aumenta innecesariamente la complejidad del decodificador y, por tanto, aumenta los costes de implementación asociados.
En general, esta descripción describe técnicas para el soporte del acceso de la sub-imagen o acceso aleatorio basado en MCTS en la codificación de video. Más específicamente, esta descripción describe diseños mejorados para soportar tipos de unidad NAL mixtas dentro de una imagen, que se emplea para soportar un acceso aleatorio basado en sub-imágenes o MCTS. La descripción de las técnicas se basa en la norma VVC, pero también se aplica a otras especificaciones de códec de video/medios.
Para resolver los problemas anteriores, se describen las siguientes implementaciones ejemplares. Dichas implementaciones se pueden aplicar individualmente o en combinación. Según la invención, cada imagen está asociada con una indicación de si la imagen contiene valores de nal_unit_type mezclados. Esta indicación se señaliza en el PPS. Esta indicación apoya la determinación de si reiniciar el POC MSB y/o reiniciar el DPB marcando todas las imágenes de referencia como no utilizadas para referencia. Cuando la indicación se señaliza en el PPS, se puede llevar a cabo un cambio de valor en el PPS durante la fusión o extracción separada. Sin embargo, esto es aceptable ya que los PPS se reescriben y reemplazan por otros mecanismos durante dicha extracción o fusión de flujos de bits.
En una alternativa que no forma parte de la invención reivindicada, esta indicación se puede señalizar en el encabezado del grupo de mosaicos, pero se requiere que sea la misma para todos los grupos de mosaicos de una imagen. Sin embargo, en este caso, puede ser necesario cambiar el valor durante la extracción del sub-flujo de bits de MCTS/secuencias de sub-imagen. En una alternativa que no forma parte de la invención reivindicada, esta indicación se puede señalizar en el encabezado de la unidad NAL, pero se requiere que sea la misma para todos los grupos de mosaicos de una imagen. Sin embargo, en este caso, puede ser necesario cambiar el valor durante la extracción del flujo de bits de MCTS/secuencias de sub-imagen. En una alternativa que no forma parte de la invención reivindicada, esta indicación se puede señalizar definiendo tales tipos de unidades NAL VCL adicionales que, cuando se utilicen para una imagen, todas las unidades NAL VCL de la imagen tendrán el mismo valor de tipo de unidad NAL. Sin embargo, en este caso, el valor de tipo de unidad NAL de las unidades NAL VCL puede necesitar ser cambiado durante la extracción de sub flujo de bits de MCTS/ secuencias de sub-imagen. En una alternativa que no forma parte de la invención reivindicada, esta indicación puede ser señalizada definiendo dichos tipos de unidades NAL IRAP VCL adicionales que, cuando se utilicen para una imagen, todas las unidades NAL VCL de la imagen tendrán el mismo valor de tipo de unidad NAL. Sin embargo, en este caso, el valor de tipo de unidad NAL de las unidades NAL VCL puede necesitar ser cambiado durante la extracción de sub-flujo de bits de MCTS/ secuencias de sub-imagen. Alternativamente, cada imagen que tiene al menos una unidad NAL VCL con cualquiera de los tipos de unidad NAL IRAP puede asociarse con una indicación de si la imagen contiene valores de tipo de unidad NAL mixta.
Además, se aplica una restricción de modo que se permita dicha mezcla de valores nal_unit_type dentro de una imagen de una manera limitada al permitir únicamente tipos de unidades NAL IRAP y no IRAP mezcladas. Para cualquier imagen particular, todas las unidades NAL VCL tienen el mismo tipo de unidad NAL o algunas unidades NAL VCL tienen un tipo de unidad NAL IRAP particular y el resto tienen el tipo de unidad NAL VCL no IRAP particular. En otras palabras, las unidades NAL VCL de cualquier imagen particular no pueden tener más de un tipo de unidad NAL IRAP y no pueden tener más de un tipo de unidad NAL no IRAP. Una imagen se puede considerar como una imagen IRAP solo si la imagen no contiene valores mezclados de nal_unit_type y las unidades NAL VCL tienen un tipo de unidad NAL IRAP. Para cualquier unidad NAL IRAP (incluido IDR) que no pertenezca a una imagen IRAP, el POC MSB puede no ser reiniciado. Para cualquier unidad NAL IRAP (incluido IDR) que no pertenezca a una imagen IRAp , el DPB no se reinicia y, por lo tanto, no se realiza la marcación de todas las imágenes de referencia como no utilizadas para referencia. El TemporalId puede establecerse igual a cero para una imagen si al menos una unidad NAL VCL de la imagen es una unidad NAL IRAP.
Lo siguiente es una implementación específica de uno o más de los aspectos descritos anteriormente. Una imagen IRAP puede definirse como una imagen codificada para la que el valor de mixed_nalu_types_in_pic_flag es igual a cero y cada unidad NAL VCL tiene un nal_unit_type en el intervalo de IDR_W_RADL a<r>S<v>_IRAP_VCL13, inclusive. La sintaxis y semántica PPS ejemplares son como sigue.
El mixed_nalu_types_in_pic_flag se establece igual a cero para especificar que cada imagen que se refiere al PPS tiene múltiples unidades NAL VCL y estas unidades NAL no tienen el mismo valor de nal_unit_type. El mixed_nalu_types_ in_pic_flag se establece igual a cero para especificar que las unidades NAL VCL de cada imagen que se refieren al PPS tienen el mismo valor de nal_unit_type.
La sintaxis del encabezado del grupo/segmento de mosaicos ejemplar es como sigue.
Las semánticas ejemplares de encabezado de unidad NAL son las siguientes. Para las unidades NAL VCL de cualquier imagen particular, se cumplirá con cualquiera de las dos siguientes condiciones. Todas las unidades NAL VCL tienen el mismo valor de nal_unit_type. Algunas de las unidades NAL VCL tienen un valor de tipo de unidad NAL IRAP particular (es decir, un valor de nal_unit_type en el intervalo de IDR_W_RADL a RSV_IRAP_VCL13, inclusive), mientras que todas las demás unidades NAL VCL tienen un tipo de unidad NAL VCL no IRAP particular (es decir, un valor de nal_unit_type en el intervalo de TRAIL_NUT a RSV_VCL_7, inclusive, o en el intervalo de RSV_VCL14 a RSV_VCL15, inclusive). El nuh_temporal_id_plus1 menos 1 especifica un identificador temporal para la unidad NAL. El valor de nuh_temporal_id_plus1 no será igual a cero.
La variable TemporalId se deriva de la siguiente manera:
Temporalld = nuh_temporal_id_plus1 - 1 (7-1)
Cuando nal_unit_type está en el intervalo de IDR_W_RADL a RSV_IRAP_VCL13, inclusive, para una unidad NAL VCL de una imagen, independientemente del valor tipo de unidad nal de otras unidades NAL VCL de la imagen, TemporalId será igual a cero para todas las unidades NAL VCL de la imagen. El valor de TemporalId será el mismo para todas las unidades NAL VCL de una unidad de acceso. El valor de TemporalId de una imagen codificada o una unidad de acceso es el valor de TemporalId de las unidades NAL VCL de la imagen codificada o la unidad de acceso.
Un ejemplo de proceso de decodificación para una imagen codificada es el siguiente. El proceso de decodificación funciona de la siguiente manera para la imagen actual CurrPic. La decodificación de unidades NAL se especifica en esta memoria. Los siguientes procesos de decodificación utilizan elementos de sintaxis en la capa de encabezado del grupo de mosaicos y anteriores. Las variables y funciones relacionadas con el cómputo del orden de imágenes se derivan como se especifica en la presente memoria. Esto se invoca solo para el primer grupo/segmento de mosaicos de una imagen. Al comienzo del proceso de decodificación para cada grupo/segmento de mosaicos, se invoca el proceso de decodificación para la construcción de listas de imágenes de referencia para la derivación de la lista 0 de imágenes de referencia (RefPicList[ 0 ]) y la lista 1 de imágenes de referencia (RefPicList[ 1 ]). Si la imagen actual es una imagen IDR, entonces el proceso de decodificación para la construcción de listas de imágenes de referencia puede invocarse con el propósito de verificar la conformidad del flujo de bits, pero puede no ser necesario para decodificar la imagen actual o las imágenes que siguen a la imagen actual en el orden de decodificación.
Un proceso de decodificación para la construcción de listas de imágenes de referencia es el siguiente. Este proceso se invoca al comienzo del proceso de decodificación para cada grupo de mosaicos. Las imágenes de referencia se abordan a través de índices de referencia. Un índice de referencia es un índice en una lista de imágenes de referencia. Al decodificar un grupo I de mosaicos, no se utiliza una lista de imágenes de referencia en la decodificación de los datos del grupo de mosaicos. Cuando se decodifica un grupo P de mosaicos, solo se utiliza la lista cero de imágenes de referencia (RefPicList[ 0 ]) en la decodificación de los datos del grupo de mosaicos. Al decodificar un grupo B de mosaicos, tanto la lista cero de imágenes de referencia como la lista uno de imágenes de referencia (RefPicList[ 1 ]) se utilizan en la decodificación de los datos del grupo de mosaicos. Al comienzo del proceso de decodificación para cada grupo de mosaicos, se derivan las listas de imágenes de referencia RefPicList[ 0 ] y RefPicList[ 1 ]. Las listas de imágenes de referencia se utilizan para marcar las imágenes de referencia o para decodificar los datos del grupo de mosaicos. Para cualquier grupo de mosaicos de una imagen IDR o un grupo I de mosaicos de una imagen no IDR, RefPicList[ 0 ] y RefPicList[ 1 ] pueden derivarse con el propósito de verificar la conformidad del flujo de bits, pero su derivación no es necesaria para decodificar la imagen actual o imágenes que siguen a la imagen actual en orden de decodificación. Para un grupo P de mosaicos, RefPicList[ 1 ] puede derivarse con el propósito de verificar la conformidad del flujo de bits, pero la derivación no es necesaria para decodificar la imagen actual o las imágenes que siguen a la imagen actual en el orden de decodificación.
La FIG. 8 es un diagrama esquemático de un dispositivo ejemplar 800 de codificación de video. El dispositivo 800 de codificación de video es adecuado para implementar los ejemplos/realizaciones descritos como se describe en la presente memoria. El dispositivo 800 de codificación de video comprende puertos 820 aguas abajo, puertos 850 aguas arriba, y/o unidades transceptoras (Tx/Rx) 810, que incluyen transmisores y/o receptores para comunicar datos aguas arriba y/o aguas abajo sobre una red. El dispositivo 800 de codificación de video también incluye un procesador 830 que incluye una unidad lógica y/o una unidad de procesamiento central (CPU) para procesar los datos y una memoria 832 para almacenar los datos. El dispositivo 800 de codificación de video también puede comprender componentes eléctricos, opto-eléctricos (OE), componentes electro-ópticos (EO), y/o componentes de comunicación inalámbrica acoplados a los puertos 850 aguas arriba y/o puertos 820 aguas abajo para comunicación de datos a través de redes de comunicación eléctricas, ópticas o inalámbricas. El dispositivo 800 de codificación de video también puede incluir dispositivos 860 de entrada y/o salida (I/O) para comunicar datos a y desde un usuario. Los dispositivos I/O 860 pueden incluir dispositivos de salida tales como un dispositivo de visualización para mostrar datos de video, altavoces para emitir datos de audio, etc. Los dispositivos I/O 860 también pueden incluir dispositivos de entrada, tales como un teclado, ratón, bola de seguimiento, etc., y/o interfaces correspondientes para interactuar con dichos dispositivos de salida.
El procesador 830 está implementado por hardware y software. El procesador 830 se puede implementar como uno o más chips CPU, núcleos (por ejemplo, como un procesador de múltiples núcleos), agrupaciones de puerta programable en campo (FPGA), circuitos integrados específicos de aplicación (ASIC), y procesadores de señal digitales (DSP). El procesador 830 está en comunicación con los puertos 820 de aguas abajo, Tx/Rx 810, puertos 850 de aguas arriba, y memoria 832. El procesador 830 comprende un módulo 814 de codificación. El módulo 814 de codificación implementa las realizaciones descritas en la presente memoria, tales como métodos 100, 900, y 1000, que pueden emplear una CVS 500, un flujo 600 de video de imágenes de VR y un flujo 700 de bits. El módulo 814 de codificación también puede implementar cualquier otro método/mecanismo descrito en la presente memoria. Además, el módulo 814 de codificación puede implementar un sistema códec 200, un codificador 300, y/o un decodificador 400. Por ejemplo, el módulo 814 de codificación puede establecer un indicador en un PPS para indicar cuando una imagen contiene unidades tanto IRAP como NAL no IRAP y restringir dichas imágenes para contener solo un único tipo de unidad NAL IRAP y un único tipo de unidad NAL no IRAP. Por tanto, el módulo 814 de codificación hace que el dispositivo 800 de codificación de video proporcione funcionalidad adicional y/o eficiencia de codificación cuando codifica datos de video. Como tal, el módulo 814 de codificación mejora la funcionalidad del dispositivo 800 de codificación de video así como aborda los problemas que son específicos para las técnicas de codificación de video. Además, el módulo 814 de codificación efectúa una transformación del dispositivo 800 de codificación de video a un estado diferente. Alternativamente, el módulo 814 de codificación se puede implementar como instrucciones almacenadas en la memoria 832 y ejecutadas por el procesados 830 (por ejemplo, como un producto de programa informático almacenado en un medio no transitorio).
La memoria 832 comprende uno o más tipos de memoria tal como discos, unidades de cinta, unidades de estado sólido, memoria solo de lectura (ROM), memoria de acceso aleatorio (RAM), memoria flash, memoria direccionable de contenido ternario (TCAM), memoria de acceso aleatorio estático (SRAM), etc. La memoria 832 se puede utilizar como un dispositivo de almacenamiento de datos se exceso de flujo, para almacenar programas cuando estos programas se seleccionan para ejecución, y para almacenar instrucciones y datos que se leen durante la ejecución del programa.
La FIG. 9 es un diagrama de flujo de un método ejemplar 900 de codificación de una secuencia de video, tal como la CVS 500, que contiene una imagen con tipos de unidades NAL mixtas en un flujo de bits, tal como un flujo 700 de bits que incluye el flujo 600 de video de imágenes de VR fusionado a partir de múltiples flujos 601-603 de video de sub-imágenes en una pluralidad de resoluciones de video. El método 900 puede ser empleado por un codificador, tal como un sistema códec 200, un codificador 300 y/o un dispositivo 800 de codificación de video cuando se lleva a cabo el método 100.
El método 900 puede comenzar cuando un codificador recibe una secuencia de video que incluye una pluralidad de imágenes, tal como imágenes de VR, y determina codificar esa secuencia de video en un flujo de bits, por ejemplo basándose en una entrada de usuario. En la etapa 901, el codificador determina que una imagen de la secuencia de video contiene una pluralidad de sub-imágenes de diferentes tipos.
En la etapa 903, el codificador codifica las sub-imágenes de la imagen en una pluralidad de unidades NAL VCL en un flujo de bits.
En la etapa 905, el codificador codifica un PPS en el flujo de bits. El codificador también codifica un indicador en el PPS y, por lo tanto, en el flujo de bits. El indicador está configurado para indicar que las unidades NAL VCL de una o más de las sub-imágenes de la imagen tienen todas un primer valor particular del tipo de unidad NAL y otras unidades NAL VCL en la imagen todas tienen un segundo valor particular diferente de tipos de unidad NAL. Por ejemplo, el primer valor particular del tipo de unidad NAL puede indicar que la imagen contiene un único tipo de sub-imagen IRAP. Como ejemplo específico, el primer valor particular del tipo de unidad NAL puede ser igual a uno de IDR_W_RADL, IDR_N_Lp o CRA_NuT. Por consiguiente, la imagen puede tener cualquier número de sub-imágenes de IRAP, pero todas las sub-imágenes de IRAP deben ser del mismo tipo (por ejemplo, una y solo una de IDR_W_RADL, IDR_N_LP o CRA_NUT). Además, el segundo valor particular del tipo de unidad NAL puede indicar que la imagen contiene un único tipo de sub imagen no IRAP. Como ejemplo específico, el segundo valor particular del tipo de unidad NAL puede ser igual a TRAIL_NUT, RADL_NUT o R<a>SL_NUT. En consecuencia, la imagen puede tener cualquier número de sub-imágenes no IRAP, pero todas las sub-imágenes no IRAP deben ser del mismo tipo (por ejemplo, una y solo una de TRAIL_NUT, RADL_NUT o RASL_NUT).
En la etapa 907, el codificador almacena el flujo de bits que incluye el indicador para comunicación hacia un decodificador. En algunos ejemplos, el indicador es un indicador mixed_nalu_types_in_pic_flag. En un ejemplo específico, el mixed_nalu_types_in_pic_flag puede establecerse igual a uno cuando se especifica que cada imagen que hace referencia al PPS tiene más de una unidad NAL VCL y las unidades NAL VCL no tienen el mismo valor del tipo de unidad NAL (nal_unit_type). Además, el mixed_nalu_types_in_pic_flag puede establecerse igual a cero cuando cada imagen que se refiere al PPS tiene una o más unidades NAL VCL y las unidades NAL VCL de cada imagen que se refiere al PPS tienen el mismo valor de nal_unit_type.
La FIG. 10 es un diagrama de flujo de un método ejemplar 1000 para decodificar una secuencia de video, tal como CVS 500, que contiene una imagen con tipos de unidades NAL mixtas procedente de un flujo de bits, tal como un flujo 700 de bits que incluye el flujo 600 de video de imágenes de VR fusionadas a partir de múltiples flujos 601-603 de sub-imágenes de video en una pluralidad de resoluciones de video. El método 1000 puede ser empleado por un decodificador, tal como un sistema códec 200, un decodificador 400 y/o un dispositivo 800 de codificación de video cuando se lleva a cabo el método 100.
El método 1000 puede comenzar cuando un decodificador comienza a recibir un flujo de bits de datos codificados que representan una secuencia de video, por ejemplo como resultado del método 900. En la etapa 1001, el decodificador recibe un flujo de bits. El flujo de bits comprende un indicador y una pluralidad de sub-imágenes asociadas con una imagen. Las sub-imágenes están divididas en segmentos, que están contenidos en unidades NAL VCL. Por consiguiente, cada una de la pluralidad de sub-imágenes también está contenida en una pluralidad de unidades NAL VCL. El flujo de bits también incluye un PPS. El PPS contiene el indicador. Como ejemplo específico, el indicador puede ser un mixed_nalu_types_in_pic_flag. Además, el mixed_nalu_types_in_pic_flag puede establecerse igual a uno cuando se especifica que cada imagen que hace referencia al PPS tiene más de una unidad NAL VCL y las unidades NAL VCL no tienen el mismo valor de nal_unit_type. Además, el mixed_nalu_types_in_pic_flag puede establecerse igual a cero cuando cada imagen que hace referencia al PPS tiene una o más unidades NAL VCL y las unidades NAL VCL de cada imagen que hace referencia al PPS tienen el mismo valor de nal_unit_type.
En la etapa 1003, el decodificador determina que las unidades NAL VCL de una o más de las sub-imágenes de la imagen tienen todas un primer valor particular del tipo de unidad NAL y otras (por ejemplo, el resto de) unidades NAL VCL en todas las imágenes (por ejemplo, para las sub-imágenes restantes) tienen un segundo valor particular diferente del tipo de unidad NAL con base en un valor del indicador. Por ejemplo, el primer valor particular del tipo de unidad NAL puede indicar que la imagen contiene un único tipo de sub-imagen IRAP. Como ejemplo específico, el primer valor particular del tipo de unidad NAL puede ser igual a uno de IDR_W_RADL, IDR_N_LP o CRA_NUT. Por consiguiente, la imagen puede tener cualquier número de sub imágenes de IRAP, pero todas las sub-imágenes de IRAP deben ser del mismo tipo (por ejemplo, una y solo una de IDR_W_RADL, IDR_N_LP o CRA_NUT). Además, el segundo valor particular del tipo de unidad NAL puede indicar que la imagen contiene un solo tipo de sub-imagen no IRAP. Como ejemplo específico, el segundo valor particular del tipo de unidad NAL puede ser igual a TRAIL_NUT, RADL_NUT o RASL_NUT. En consecuencia, la imagen puede tener cualquier número de sub-imágenes que no sean IRAP, pero todas las sub-imágenes que no sean IRAP deben ser del mismo tipo (por ejemplo, una y solo una de TRAIL_NUT, RADL_NUT o RASL_NUT).
En la etapa 1005, el decodificador decodifica una o más de las sub-imágenes basándose en el primer valor particular del tipo de unidad NAL y en el segundo valor particular del tipo de unidad NAL.
En la etapa 1007, una o más de las sub-imágenes son reenviadas para su presentación como parte de una secuencia de video decodificada.
La FIG. 11 es un diagrama esquemático de un sistema ejemplar 1100 para codificar una secuencia de video, tal como CVS 500, que contiene una imagen con tipos de unidades NAL mixtas en un flujo de bits, tal como un flujo 700 de bits que incluye el flujo 600 de video de imágenes de VR fusionado a partir de múltiples sub imágenes de flujos 601-603 de video en una pluralidad de resoluciones de video. El sistema 1100 puede implementarse mediante un codificador y un decodificador tal como un sistema códec 200, un codificador 300, un decodificador 400 y/o un dispositivo 800 de codificación de video. Además, el sistema 1100 puede emplearse cuando se implementan los métodos 100, 900, y/o 1000.
El sistema 1100 incluye un codificador 1102 de video. El codificador 1102 de video comprende un módulo 1101 de determinación para determinar que una imagen contiene una pluralidad de sub-imágenes de diferentes tipos. El codificador 1102 de video comprende además un módulo 1103 de codificación para codificar las sub-imágenes de la imagen en una pluralidad de unidades NAL VCL en un flujo de bits. El módulo 1103 de codificación es además para codificar en el flujo de bits un conjunto de indicadores para indicar que las unidades NAL VCL de uno o más de las sub-imágenes de la imagen tienen todas un primer valor particular del tipo de unidad NAL y otras unidades NAL VCL en la imagen tienen todas un segundo valor particular diferente del tipo de unidad NAL. El codificador 1102 de video comprende además un módulo 1105 de almacenamiento para almacenar el flujo de bits para su comunicación hacia un decodificador. El codificador 1102 de video comprende además un módulo 1107 de transmisión para transmitir el flujo de bits hacia el decodificador 1110 de video. El codificador 1102 de video puede configurarse además para realizar cualquiera de las etapas del método 900.
El sistema 1100 también incluye un decodificador 1110 de video. El decodificador 1110 de video comprende un módulo 1111 de recepción para recibir un flujo de bits que comprende un indicador y una pluralidad de sub-imágenes asociadas con una imagen, en donde la pluralidad de sub-imágenes están contenidas en una pluralidad de unidades NAL VCL. El decodificador 1110 de video comprende además un módulo 1113 de determinación para determinar las unidades NAL VCL de una o más de las sub-imágenes de la imagen, todas tienen un primer valor particular del tipo de unidad NAL y otras unidades NAL VCL en la imagen tienen todas un segundo valor diferente del valor particular del tipo de unidad NAL con base en un valor del indicador. El decodificador 1110 de video comprende además un módulo 1115 de decodificación para decodificar una o más de las sub-imágenes basándose en el primer valor particular del tipo de unidad NAL y en el segundo valor particular del tipo de unidad NAL. El decodificador 1110 de video comprende además un módulo 1117 de reenvío para reenviar una o más de las sub-imágenes para su presentación como parte de una secuencia de video decodificada. El decodificador 1110 de video puede configurarse además para realizar cualquiera de las etapas del método 1000.
Un primer componente se acopla directamente a un segundo componente cuando no hay componentes de intervención, excepto para una línea, un trazo, u otro medio entre el primer componente y el segundo componente. El primer componente está indirectamente acoplado al segundo componente cuando hay componentes de intervención diferentes de una línea, un trazo u otro medio entre el primer componente y el segundo componente. El término “acoplado” y sus variantes incluyen tanto directamente acoplado como indirectamente acoplado. El uso del término “aproximadamente” significa un intervalo que incluye ± 10% del número subsiguiente, a menos que se establezca de otra manera.
También se debe entender que las etapas de los métodos ejemplares expuestos en la presente memoria no se requiere que sean llevadas a cabo necesariamente en el orden descrito, y el orden de las etapas de estos métodos se debe entender que es simplemente ejemplar. Del mismo modo, se pueden incluir etapas adicionales en dichos métodos, y se pueden omitir o combinar ciertas etapas, en métodos consistentes con varias realizaciones de la presente descripción.
Aunque se han proporcionado varias realizaciones en la presente descripción, se puede entender que los sistemas y métodos descritos se podrían implementados en muchas otras formas específicas sin apartarse del espíritu o alcance de la presente descripción. Los presentes ejemplos se han de considerar como ilustrativos y no restrictivos, y la intención no se va a limitar a los detalles dados en la presente memoria. Por ejemplo, los diversos elementos o componentes se pueden combinar o integrar en otro sistema o ciertas características se pueden omitir, o no implementar.
Además, las técnicas, sistemas, subsistemas y métodos descritos e ilustrados en las diversas realizaciones como discretas o separadas se pueden combinar o integrar con otros sistemas, componentes, técnicas o métodos sin apartarse del alcance de la presente descripción. Otros ejemplos de cambios, sustituciones y alteraciones son discernibles por un experto en la técnica y se pueden realizar sin apartarse del espíritu y alcance descritos en la presente memoria.
Claims (12)
1. Un método implementado en un decodificador, comprendiendo el método:
recibir (1001), mediante un receptor del decodificador, un flujo de bits que comprende un indicador y una pluralidad de sub-imágenes asociadas con una imagen, en donde las sub-imágenes están contenidas en una pluralidad de unidades de capa de codificación de video, VCL, de capa de abstracción de red (NAL); en donde el flujo de bits incluye un conjunto de parámetros de imagen, PPS, que contiene el indicador; determinar (1003), mediante un procesador del decodificador, basándose en un valor del indicador, que todas las unidades NAL VCL de la imagen tienen un mismo tipo de unidad NAL, o que las unidades NAL VCL de una o más de las sub-imágenes de la imagen tienen todas un valor particular de un tipo de unidad NAL de punto de acceso intra-aleatorio, IRAP, y que todas las otras unidades NAL VCL de la imagen tienen un valor particular de un tipo de unidad NAL, no IRAP; y
decodificar (1005), mediante el procesador, una o más de las sub-imágenes basándose en el valor particular del tipo de unidad NAL IRAP o en el valor particular del tipo de unidad NAL, no IRAP.
2. El método según la reivindicación 1, en donde el valor particular del tipo de unidad NAL IRAP es igual a una actualización de decodificación instantánea, IDR, con imagen inicial decodificable de acceso aleatorio IDR_W_RADL, una IDR sin imágenes iniciales IDR_N_LP, o un tipo de unidad NAL de acceso aleatorio limpio, CRA, CRA_NUT.
3. El método según cualquiera de las reivindicaciones 1-2, en donde el valor particular del tipo de unidad NAL, no IRAP es igual a un tipo unidad NAL de imagen final, TRAIL_NUT, un tipo de unidad nAl de imagen inicial decodificable de acceso aleatorio, RADL_NUT, o un tipo de unidad NAL de imagen inicial omitida de acceso aleatorio, RASL, RASL_NUT.
4. El método según cualquiera de las reivindicaciones 1-3, en donde el indicador es un mixed_nalu_types_in_pic_flag.
5. El método según cualquiera de las reivindicaciones 1-4, en donde el mixed_nalu_types_in_pic_flag es igual a uno cuando se especifica que cada imagen que se refiere al PPS tiene más de una unidad NAL VCL y que las unidades NAL VCL no tienen el mismo valor de tipo de unidad NAL (nal_unit_type), y en donde el mixed_nalu_types_in_pic_flag es igual a cero cuando cada imagen que se refiere al PPS tiene una o más unidades NAL VCL y que las unidades NAL VCL de cada imagen que se refieren al PPS tienen el mismo valor de nal_unit_type.
6. Un método implementado en un codificador, comprendiendo el método:
determinar (901), mediante un procesador del codificador, que una imagen contiene una pluralidad de sub imágenes de diferentes tipos;
codificar (903), mediante el procesador, las sub-imágenes de la imagen en una pluralidad de unidades de capa unidades de capa de abstracción de red (NAL), de capa de codificación de video (VCL), en un flujo de bits;
codificar (905) en el flujo de bits, mediante el procesador, un indicador establecido para indicar que todas las unidades NAL VCL de la imagen tienen el mismo tipo de unidad NAL, o que las unidades NAL VCL de una o más sub-imágenes de la imagen tienen todas un valor particular de un tipo de unidad NAL, de punto de acceso intra-aleatorio IRAP, y que todas las otras unidades NAL VCL en la imagen tienen un valor particular de un tipo de unidad NAL no IRAP;
codificar (905) un conjunto de parámetros de imagen, PPS en el flujo de bits, en donde el indicador está codificado en el PPS; y
almacenar (907), mediante una memoria acoplada al procesador, el flujo de bits para comunicación hacia un decodificador.
7. El método según la reivindicación 6, en donde el valor particular del tipo de unidad NAL IRAP es igual a una Actualización de Decodificación Instantánea, IDR, con imagen inicial decodificable de acceso aleatorio, IDR_W_RADL, una IDR sin imágenes iniciales, IDR_N_LP, o un tipo de unidad NAL de acceso aleatorio limpio CRA, CRA_NUT.
8. El método según cualquiera de las reivindicaciones 6-7, en donde el valor particular del tipo de unidad NAL no IRAP es igual a un tipo de unidad NAL de imagen final, TRAIL_NUT, un tipo de unidad NAL de imagen inicial decodificable de acceso aleatorio, RADL_NUT, o un tipo de unidad NAL, de imagen inicial omitida de acceso aleatorio, RASL, RASL_NUT.
9. El método según cualquiera de las reivindicaciones 6-8, en donde el indicador es mixed_nalu_types_in_pic_flag.
10. El método según cualquiera de las reivindicaciones 6-9, en donde mixed_nalu_types_in_pic_flag es igual a uno cuando se especifica que cada imagen que se refiere al PPS tiene más de una unidad NAL VCL y que las unidades NAL VCL no tienen el mismo valor del tipo de unidad NAL, nal_unit_type, y en donde mixed_nalu_types_in_pic_flag es igual a cero cuando cada imagen que se refiere al PPS tiene una o más unidades NAL VCL y que las unidades NAL VCL de cada imagen que se refieren al PPS tienen el mismo valor de nal_unit_type.
11. Un dispositivo (800) de codificación de video, que comprende:
un procesador (830), un receptor (810) acoplado a un procesador (830), y una memoria (832) acoplada al procesador (830), en donde el procesador (830), el receptor (810) y la memoria (832) están configurados para realizar el método según cualquiera de las reivindicaciones 1-5.
12. Un dispositivo (800) de codificación de video que comprende:
un procesador (830), una memoria (832) acoplada al procesador (830), y un transmisor (810) acoplado al procesador (830), en donde el procesador (830), la memoria (832), y el transmisor (810) están configurados para realizar el método según cualquiera de las reivindicaciones 6-10.
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201962816749P | 2019-03-11 | 2019-03-11 | |
US201962832132P | 2019-04-10 | 2019-04-10 | |
PCT/US2020/022137 WO2020185923A1 (en) | 2019-03-11 | 2020-03-11 | Mixed nal unit type picture constraints |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2965445T3 true ES2965445T3 (es) | 2024-04-15 |
Family
ID=72426929
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES20771048T Active ES2965445T3 (es) | 2019-03-11 | 2020-03-11 | Restricciones de imagen del tipo de unidad NAL mixta |
ES20770118T Active ES2972701T3 (es) | 2019-03-11 | 2020-03-11 | Imágenes con tipos de unidad NAL mezclados |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES20770118T Active ES2972701T3 (es) | 2019-03-11 | 2020-03-11 | Imágenes con tipos de unidad NAL mezclados |
Country Status (16)
Country | Link |
---|---|
US (2) | US20210409780A1 (es) |
EP (4) | EP3925212B1 (es) |
JP (4) | JP7322169B2 (es) |
KR (4) | KR20240064016A (es) |
CN (8) | CN113615170B (es) |
AU (2) | AU2020234831B2 (es) |
BR (1) | BR112021017889A2 (es) |
CA (1) | CA3133079C (es) |
DK (2) | DK3925213T5 (es) |
ES (2) | ES2965445T3 (es) |
FI (2) | FI3925212T3 (es) |
HU (2) | HUE063045T4 (es) |
MX (2) | MX2021011048A (es) |
PL (2) | PL3925213T3 (es) |
PT (2) | PT3925212T (es) |
WO (2) | WO2020185922A1 (es) |
Families Citing this family (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2020141248A1 (en) * | 2019-01-02 | 2020-07-09 | Nokia Technologies Oy | An apparatus, a method and a computer program for video coding and decoding |
KR20240064016A (ko) * | 2019-03-11 | 2024-05-10 | 후아웨이 테크놀러지 컴퍼니 리미티드 | 혼합된 nal 유닛 유형 픽처 제약 |
KR20210034536A (ko) * | 2019-09-20 | 2021-03-30 | 한국전자통신연구원 | 영상 부호화/복호화 방법, 장치 및 비트스트림을 저장한 기록 매체 |
KR20220101711A (ko) * | 2019-12-23 | 2022-07-19 | 엘지전자 주식회사 | Nal 유닛 관련 정보 기반 영상 또는 비디오 코딩 |
KR20220101712A (ko) * | 2019-12-23 | 2022-07-19 | 엘지전자 주식회사 | 슬라이스 또는 픽처에 대한 nal 유닛 타입 기반 영상 또는 비디오 코딩 |
US11399188B2 (en) | 2020-01-01 | 2022-07-26 | Tencent America LLC | Method for mixed NAL unit type support in a coded picture |
MX2022010889A (es) * | 2020-03-05 | 2022-10-27 | Lg Electronics Inc | Metodo y dispositivo de codificacion/decodificacion de imagen basado en el tipo de unidad nal combinada, y metodo para trasmitir flujo de bits. |
JP7420965B2 (ja) * | 2020-03-20 | 2024-01-23 | バイトダンス インコーポレイテッド | 隣接するサブピクチャのコーディング |
CN115668943A (zh) * | 2020-03-23 | 2023-01-31 | Lg电子株式会社 | 基于混合nal单元类型的图像编码/解码方法和设备及存储比特流的记录介质 |
KR20230002395A (ko) | 2020-04-20 | 2023-01-05 | 바이트댄스 아이엔씨 | 레퍼런스 픽처 목록에 대한 제약 |
CN113875245A (zh) * | 2020-04-24 | 2021-12-31 | 株式会社迓廷试 | 影像的译码方法及装置 |
US11818371B2 (en) | 2020-10-07 | 2023-11-14 | Nokia Technologies Oy | Coded picture with mixed VCL NAL unit type |
WO2023059080A1 (ko) | 2021-10-06 | 2023-04-13 | 솔브레인 주식회사 | 전해액 및 이를 포함하는 이차전지 |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20110115087A (ko) * | 2010-04-14 | 2011-10-20 | 삼성전자주식회사 | 3차원 영상 데이터를 부호화하는 방법 및 장치와 복호화 방법 및 장치 |
US20130114694A1 (en) * | 2011-11-08 | 2013-05-09 | Qualcomm Incorporated | Parameter set groups for coded video data |
US20140092995A1 (en) * | 2012-09-28 | 2014-04-03 | Sharp Laboratories Of America, Inc. | Electronic devices for signaling a random access point picture message |
US20140218473A1 (en) * | 2013-01-07 | 2014-08-07 | Nokia Corporation | Method and apparatus for video coding and decoding |
US20140301463A1 (en) * | 2013-04-05 | 2014-10-09 | Nokia Corporation | Method and apparatus for video coding and decoding |
US20140301477A1 (en) * | 2013-04-07 | 2014-10-09 | Sharp Laboratories Of America, Inc. | Signaling dpb parameters in vps extension and dpb operation |
WO2014166328A1 (en) * | 2013-04-08 | 2014-10-16 | Mediatek Singapore Pte. Ltd. | Method and apparatus for quantization matrix signaling and representation in scalable video coding |
US9602822B2 (en) * | 2013-04-17 | 2017-03-21 | Qualcomm Incorporated | Indication of cross-layer picture type alignment in multi-layer video coding |
GB2516424A (en) * | 2013-07-15 | 2015-01-28 | Nokia Corp | A method, an apparatus and a computer program product for video coding and decoding |
US9794558B2 (en) * | 2014-01-08 | 2017-10-17 | Qualcomm Incorporated | Support of non-HEVC base layer in HEVC multi-layer extensions |
WO2015194191A1 (en) * | 2014-06-19 | 2015-12-23 | Sharp Kabushiki Kaisha | Method for decoding a video bitstream |
US9866851B2 (en) * | 2014-06-20 | 2018-01-09 | Qualcomm Incorporated | Full picture order count reset for multi-layer codecs |
CN109691110B (zh) * | 2016-09-08 | 2023-07-25 | 佳稳集团有限公司 | 利用空间布局信息的同步多视点影像的编码/解码方法以及其装置 |
US10638133B2 (en) * | 2018-01-31 | 2020-04-28 | Qualcomm Incorporated | Delta quantization parameter (QP) coding options for video |
BR112021012679A2 (pt) * | 2018-12-27 | 2021-09-08 | Huawei Technologies Co., Ltd. | Codificador de vídeo, decodificador de vídeo e métodos correspondentes |
EP4072139A3 (en) * | 2019-01-02 | 2022-11-09 | Nokia Technologies Oy | An apparatus, a method and a computer program for video coding and decoding |
KR20210107121A (ko) | 2019-01-04 | 2021-08-31 | 후아웨이 테크놀러지 컴퍼니 리미티드 | 비디오 인코더, 비디오 디코더 및 대응하는 방법 |
KR20210118183A (ko) * | 2019-02-01 | 2021-09-29 | 프라운호퍼 게젤샤프트 쭈르 푀르데룽 데어 안겐반텐 포르슝 에. 베. | 서브픽처 또는 영역 단위 랜덤 액세스가 가능한 비디오 코덱 및 이를 이용한 비디오 합성을 위한 개념 |
KR20240064016A (ko) * | 2019-03-11 | 2024-05-10 | 후아웨이 테크놀러지 컴퍼니 리미티드 | 혼합된 nal 유닛 유형 픽처 제약 |
US11375232B2 (en) * | 2019-12-10 | 2022-06-28 | Zte (Uk) Limited | Sub picture signaling in video coding |
-
2020
- 2020-03-11 KR KR1020247013949A patent/KR20240064016A/ko active Application Filing
- 2020-03-11 EP EP20770118.6A patent/EP3925212B1/en active Active
- 2020-03-11 MX MX2021011048A patent/MX2021011048A/es unknown
- 2020-03-11 DK DK20771048.4T patent/DK3925213T5/da active
- 2020-03-11 PT PT207701186T patent/PT3925212T/pt unknown
- 2020-03-11 ES ES20771048T patent/ES2965445T3/es active Active
- 2020-03-11 BR BR112021017889A patent/BR112021017889A2/pt active Search and Examination
- 2020-03-11 EP EP23191008.4A patent/EP4246980A3/en active Pending
- 2020-03-11 AU AU2020234831A patent/AU2020234831B2/en active Active
- 2020-03-11 CN CN202080019678.8A patent/CN113615170B/zh active Active
- 2020-03-11 HU HUE20771048A patent/HUE063045T4/hu unknown
- 2020-03-11 HU HUE20770118A patent/HUE065459T2/hu unknown
- 2020-03-11 PL PL20771048.4T patent/PL3925213T3/pl unknown
- 2020-03-11 CA CA3133079A patent/CA3133079C/en active Active
- 2020-03-11 KR KR1020247013966A patent/KR20240056804A/ko active Application Filing
- 2020-03-11 CN CN202211188702.8A patent/CN115550659A/zh active Pending
- 2020-03-11 PL PL20770118.6T patent/PL3925212T3/pl unknown
- 2020-03-11 EP EP23213868.5A patent/EP4307680A3/en active Pending
- 2020-03-11 WO PCT/US2020/022136 patent/WO2020185922A1/en active Application Filing
- 2020-03-11 JP JP2021555262A patent/JP7322169B2/ja active Active
- 2020-03-11 CN CN202111086240.4A patent/CN114007071B/zh active Active
- 2020-03-11 KR KR1020217032469A patent/KR102662351B1/ko active IP Right Grant
- 2020-03-11 CN CN202210475433.7A patent/CN115022640B/zh active Active
- 2020-03-11 PT PT207710484T patent/PT3925213T/pt unknown
- 2020-03-11 CN CN202210875035.4A patent/CN115442595B/zh active Active
- 2020-03-11 MX MX2021011021A patent/MX2021011021A/es unknown
- 2020-03-11 CN CN202211184305.3A patent/CN115733984A/zh active Pending
- 2020-03-11 FI FIEP20770118.6T patent/FI3925212T3/fi active
- 2020-03-11 CN CN202080019614.8A patent/CN113940062A/zh active Pending
- 2020-03-11 JP JP2021555264A patent/JP7322170B2/ja active Active
- 2020-03-11 KR KR1020217032470A patent/KR102662352B1/ko active IP Right Grant
- 2020-03-11 WO PCT/US2020/022137 patent/WO2020185923A1/en unknown
- 2020-03-11 FI FIEP20771048.4T patent/FI3925213T5/fi active
- 2020-03-11 EP EP20771048.4A patent/EP3925213B9/en active Active
- 2020-03-11 DK DK20770118.6T patent/DK3925212T3/da active
- 2020-03-11 ES ES20770118T patent/ES2972701T3/es active Active
- 2020-03-11 CN CN202111088477.6A patent/CN114007072B/zh active Active
-
2021
- 2021-09-09 US US17/471,064 patent/US20210409780A1/en active Pending
- 2021-09-09 US US17/471,066 patent/US20210409733A1/en active Pending
-
2023
- 2023-07-26 JP JP2023121816A patent/JP2023138575A/ja active Pending
- 2023-07-26 JP JP2023121817A patent/JP2023153159A/ja active Pending
-
2024
- 2024-01-24 AU AU2024200437A patent/AU2024200437A1/en active Pending
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2965445T3 (es) | Restricciones de imagen del tipo de unidad NAL mixta | |
ES2951060T3 (es) | Señalización de identificadores de subimágenes en la codificación de vídeo | |
ES2744201T3 (es) | Dispositivo y procedimiento para la codificación escalable de información de vídeo | |
US12041249B2 (en) | Mixed NAL unit picture constraints in video coding | |
ES2974627T3 (es) | Manejo de múltiples tamaños de imagen y ventanas de conformidad para el remuestreo de imágenes de referencia en la codificación de video | |
ES2967911T3 (es) | Codificación de vídeo entrelazado con imágenes principales | |
BR112021012632A2 (pt) | Codificador de vídeo, decodificador de vídeo e métodos correspondentes | |
ES2974230T3 (es) | Gestión de imágenes de referencia en codificación de vídeo en capas | |
ES2968830T3 (es) | Intercodificación en codificación de vídeo con soporte de múltiples capas | |
BR112021012649A2 (pt) | Codificador de vídeo, decodificador de vídeo e métodos correspondentes | |
ES2944451T3 (es) | Señalización de identificaciones de subimagen en codificación de vídeo basada en subimagen |