ES2611160T3 - Aparato y método para decodificar vídeo comprimido - Google Patents

Aparato y método para decodificar vídeo comprimido Download PDF

Info

Publication number
ES2611160T3
ES2611160T3 ES13290312.1T ES13290312T ES2611160T3 ES 2611160 T3 ES2611160 T3 ES 2611160T3 ES 13290312 T ES13290312 T ES 13290312T ES 2611160 T3 ES2611160 T3 ES 2611160T3
Authority
ES
Spain
Prior art keywords
video
randomization
unit
compressed
randomized
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES13290312.1T
Other languages
English (en)
Inventor
Xiaobo Liu
François Martin
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Squadeo S A S
Squadeo Sas
Original Assignee
Squadeo S A S
Squadeo Sas
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Squadeo S A S, Squadeo Sas filed Critical Squadeo S A S
Application granted granted Critical
Publication of ES2611160T3 publication Critical patent/ES2611160T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H04N19/88—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving rearrangement of data among different coding units, e.g. shuffling, interleaving, scrambling or permutation of pixel data or permutation of transform coefficient data among different blocks
    • 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/40—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video transcoding, i.e. partial or full decoding of a coded input stream followed by re-encoding of the decoded output stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • 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/48—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using compressed domain processing techniques other than decoding, e.g. modification of transform coefficients, variable length coding [VLC] data or run-length data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51—Motion estimation or motion compensation
    • H04N19/513—Processing of motion vectors
    • 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/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • H04N21/42623—Internal components of the client ; Characteristics thereof for processing the incoming bitstream involving specific decryption arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4405—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video stream decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4408—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video stream encryption, e.g. re-encrypting a decrypted video stream for redistribution in a home network

Landscapes

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

Abstract

Aparato para decodificar un vídeo comprimido, comprendiendo el aparato: una unidad de aleatorización de vídeo (220), adaptada para recibir el vídeo comprimido y aleatorizarlo, para producir un vídeo comprimido aleatorizado, en el que la aleatorización realizada mediante la unidad de aleatorización de vídeo (220) comprende una o más operaciones realizadas en unidades de acceso individuales del vídeo comprimido; y en el que la unidad de aleatorización de vídeo (220) está adaptada para producir metadatos de aleatorización que describen una operación de aleatorización aplicada a las unidades de acceso realizada mediante la unidad de aleatorización de vídeo (220); un decodificador de vídeo (130), dispuesto para recibir el vídeo comprimido aleatorizado desde la unidad de aleatorización (220) y adaptado para decodificarlo, para producir un vídeo descomprimido aleatorizado en el dominio de píxel; y una unidad de desaleatorización de vídeo (230), dispuesta para recibir el vídeo descomprimido aleatorizado desde el decodificador de vídeo y adaptada para desaleatorizarlo para producir un vídeo descomprimido desaleatorizado, en el que la unidad de desaleatorización de vídeo (230) está dispuesta para recibir los metadatos de aleatorización desde la unidad de aleatorización de vídeo (220) y adaptada para usarlos para desaleatorizar el vídeo descomprimido aleatorizado en el dominio de píxel recibido desde el decodificador de vídeo (130).

Description

5
10
15
20
25
30
35
40
45
50
55
60
65
DESCRIPCION
Aparato y metodo para decodificar v^deo comprimido
Esta invencion se refiere a la decodificacion de v^deo digital comprimido. Es particularmente pertinente a una aplicacion de software para reproducir v^deo, que usa un dispositivo decodificador de hardware especializado para realizar la decodificacion (descompresion).
La distribucion de v^deo a traves de internet es un mercado que crece rapidamente. El denominado contenido “superpuesto” (Over The Top) (OTT) puede entregarse a traves de una conexion de internet de banda ancha. Tfpicamente, este contenido se suministra mediante una tercera parte, siendo el Proveedor de Servicio de Internet (iSP) responsable unicamente de transportar los paquetes del Protocolo de Internet (IP) subyacentes. Los servicios OTT, en particular, representan un mercado de rapido crecimiento. Posibilitan a los usuarios finales disfrutar de video en dispositivos inteligentes tales como telefonos y tabletas inteligentes. Recientemente, se han hecho disponibles muchas aplicaciones de software, para ver video sobre servicios OTT. Sin embargo la mayona del contenido para estos servicios esta limitado en calidad y resolucion - es tfpicamente Definicion Estandar (SD) en lugar de Alta Definicion (HD).
Muchos dispositivos inteligentes estan basados en sistemas operativos abiertos (tales como Android). Esto posibilita que los desarrolladores creen rapidamente aplicaciones para los dispositivos. Sin embargo, la naturaleza abierta de estos sistemas operativos puede ser de interes para los proveedores de contenido, que pueden ser reacios a proporcionar contenido de alta calidad a alta resolucion en tales plataformas sin medidas apropiadas para proteger el contenido de copia no autorizada. Si pudiera proporcionarse proteccion de contenido adecuada, los proveedores de contenido podnan estar mas dispuestos a distribuir contenido HD de alta calidad.
Una solucion que se ha sugerido es usar un “entorno confiable”, para proteger la ruta de entrega de video completa. Un ejemplo de esto es la tecnologfa “TrustZone®” desarrollada por ARM Ltd. Una solucion de este tipo puede resolver el problema de proteccion de contenido, pero puede ser complicada de implementar. En particular, la necesidad de certificados y otros mecanismos de seguridad fuertes en un entorno de este tipo pone una carga adicional en los desarrolladores de aplicacion de software, que pueden necesitar pasar a traves de un proceso de certificacion cada vez que se actualiza la aplicacion de software.
El documento de la tecnica anterior SANGGU KWON et al: “Digital Video Scrambling Using Motion Vector and Slice Relocation”, 1 de enero de 2005 (), Image Analysis and Recognition Lecture Notes in Computer Science; LNCS, Springer, Berlin, DE, paginas 207 - 214, XP019020136, ISBN: 978-3-540-29069-8 desvela aleatorizacion de un flujo de bits de video usando una tecnica de aleatorizacion que distorsiona deliberadamente las secuencias de video original de una manera reversible relocalizando arbitrariamente los vectores de movimiento diferenciales y las posiciones de inicio de macrobloque en un corte. Esta tecnica de aleatorizacion tiene por objeto superar el problema de que las tecnicas de aleatorizacion de video a menudo aumentan la tasa de bits de los datos de origen.
La invencion se expone en el conjunto adjunto de las reivindicaciones.
En este aparato, el video se decodifica (descomprime) en forma aleatorizada. Esto puede hacer mas diffcil para un usuario malicioso copiar el video, puesto que el video esta en forma aleatorizada tanto en la entrada como en la salida del decodificador de video.
La unidad de aleatorizacion de video esta adaptada preferentemente para aleatorizar el video comprimido de tal manera que: no evita la decodificacion del video mediante el decodificador de video; modifica el contenido visual del video descomprimido aleatorizado despues de decodificacion; y es reversible mediante la unidad de desaleatorizacion de video, de manera que el video descomprimido desaleatorizado es identico o sustancialmente identico al video que se producina si el video comprimido se hubiera de decodificar mediante el decodificador de video, sin aleatorizacion.
Preferentemente la modificacion del contenido visual crea una perturbacion visual perceptible. Esto resultana molesto para un observador que ve el video descomprimido aleatorizado, haciendo de esta manera mas diffcil para un usuario malicioso hacer copias ilfcitas de alta calidad del video.
La aleatorizacion es sistematica en el sentido que es posible que la unidad de desaleatorizacion de video reconstruya (de manera precisa o al menos aproximadamente) el video descomprimido que se hubiera producido por el decodificador de video si no se hubiera aplicado aleatorizacion.
Preferentemente, no se requiere modificacion del decodificador de video. Esto significa que el video comprimido y el video comprimido aleatorizado pueden decodificarse ambos mediante el decodificador de video de la misma manera. Es decir, la aleatorizacion es transparente para el decodificador de video.
5
10
15
20
25
30
35
40
45
50
55
60
65
El v^deo descomprimido desaleatorizado puede considerarse sustancialmente identico al video descomprimido correspondiente sin aleatorizacion si contiene el mismo numero de fotogramas y una mayona de estos fotogramas son identicos a sus homologos en el video descomprimido al que no se ha aplicado aleatorizacion. Preferentemente, cualquier fotograma que no sea identico a sus homologos es visualmente similar a ellos.
Preferentemente, la unidad de aleatorizacion de video esta adaptada para producir metadatos de aleatorizacion que describen una operacion de aleatorizacion realizada mediante la unidad de aleatorizacion de video; y la unidad de desaleatorizacion de video esta dispuesta para recibir los metadatos de aleatorizacion desde la unidad de aleatorizacion y esta adaptada para usarlos para desaleatorizar el video descomprimido aleatorizado recibido desde el decodificador de video.
Los metadatos de aleatorizacion preferentemente no se proporcionan al decodificador de video.
La aleatorizacion realizada mediante la unidad de aleatorizacion de video puede comprender una o mas operaciones realizadas en unidades de acceso individuales del video comprimido.
Es decir, la modificacion no trata todas las unidades de acceso de manera uniforme. Al menos algunas unidades de acceso se tratan de manera diferente - una operacion que se realiza en una unidad de acceso es diferente de una operacion que se realiza en al menos otra unidad de acceso. Una unidad de acceso puede comprender la representacion codificada de un unico fotograma del video o parte de un fotograma.
La aleatorizacion realizada mediante la unidad de aleatorizacion de video puede comprender al menos uno de: cambiar una ordenacion de unidades de acceso en el video comprimido; insertar una o mas unidades de acceso adicionales en el video comprimido; y eliminar una o mas unidades de acceso a partir del video comprimido.
Preferentemente, cambiar la ordenacion de unidades de acceso comprende cambiar su orden de presentacion sin cambiar el orden en el que se decodifican mediante el decodificador de video.
Opcionalmente, la unidad de aleatorizacion de video puede adaptarse para detectar si pueden insertarse, eliminarse o reordenarse unidades de acceso particulares sin adaptacion adicional del video comprimido. Si es necesaria adaptacion adicional, la unidad de aleatorizacion de video esta adaptada preferentemente para realizar esta adaptacion adicional. La unidad de aleatorizacion de video puede adaptarse tambien para detectar si las unidades de acceso no pueden insertarse, eliminarse o reordenarse, incluso con adaptacion adicional del video comprimido. Si esto se detecta, la unidad de aleatorizacion de video puede desactivar la aleatorizacion para las unidades de acceso pertinentes.
La unidad de aleatorizacion de video puede controlarse para aplicar aleatorizacion a primeras porciones del video y no aplicar aleatorizacion a segundas porciones del video.
La primera y segunda porciones se seleccionan preferentemente de manera aleatoria o pseudo-aleatoria.
El decodificador de video puede comprender un decodificador de video de hardware.
Un decodificador de hardware es tfpicamente un dispositivo electronico separado (por ejemplo, un circuito integrado separado o “chip”), que esta disenado espedficamente para decodificar flujos de video comprimidos.
Preferentemente, el video comprimido y el decodificador de video cumplen con una norma de codificacion de video predeterminada; y la unidad de aleatorizacion de video esta adaptada para aleatorizar el video comprimido de tal manera que el video comprimido aleatorizado tambien cumple con la misma norma de codificacion de video.
Es decir, la aleatorizacion realizada mediante la unidad de aleatorizacion de video no rompe la conformidad del flujo de bits de video con la norma de codificacion de video. El decodificador de video conforme a la norma puede entonces usarse para decodificar el flujo de bits comprimido aleatorizado.
El decodificador de video y el video comprimido pueden cumplir con la norma H.264 y la aleatorizacion puede comprender modificar el Recuento de Orden de Instantanea (POC) de una pluralidad de unidades de acceso en el video comprimido H.264.
La modificacion del POC preferentemente comprende al menos uno de: reordenar los valores de POC de un conjunto de unidades de acceso; y multiplicar los valores de POC de un conjunto de unidades de acceso por un numero entero. Reordenar los valores de POC tiene el efecto de permutar el orden de presentacion original de las unidades de acceso. Multiplicar los valores de POC por un numero entero posibilita que se inserten una o mas unidades de acceso adicionales entre unidades de acceso originales.
Como ya se ha mencionado anteriormente, la unidad de aleatorizacion de video puede adaptarse para detectar si pueden insertarse, eliminarse, o reordenarse unidades de acceso particulares sin adaptacion adicional del video
5
10
15
20
25
30
35
40
45
50
55
60
65
comprimido. Si es necesaria adaptacion adicional, la unidad de aleatorizacion esta adaptada preferentemente para realizar esta adaptacion adicional. En el caso de la norma H.264, esta adaptacion puede comprender modificar la sintaxis del flujo de video comprimido en otros aspectos (ademas de modificar el POC de las unidades de acceso).
La unidad de aleatorizacion de video puede adaptarse para: detectar que el recuento de orden de instantanea esta codificado implfcitamente en el video comprimido y, en respuesta: modificar informacion de encabezamiento del video comprimido para senalizar que el recuento de orden de instantanea esta codificado explfcitamente; y asignar un valor de recuento de orden de instantanea explfcito en cada unidad de acceso del video comprimido.
En algunos flujos de video H.264, el POC es implfcito. Convertir tales flujos para codificar el POC, explfcitamente hace posible aleatorizar el video modificando el POC.
La unidad de aleatorizacion de video puede adaptarse para detectar en el video comprimido un modo de codificacion que requerina que el decodificador de video usara el recuento de orden de instantanea para decodificar una o mas unidades de acceso y, en respuesta: desactivar la aleatorizacion; o modificar el video comprimido de modo que el decodificador de video no necesite usar el recuento de orden de instantanea para decodificar la una o mas unidades de acceso.
En general, el POC no es necesario en el proceso de decodificacion, sino que unicamente determina el orden de presentacion (visualizacion) de los fotogramas despues de que se han decodificado. Sin embargo, en ciertos modos de codificacion, la decodificacion de un fotograma es dependiente de su POC. En estos modos, la aleatorizacion modificando el POC puede conducir a errores de decodificacion - por ejemplo, cambios perceptibles en el contenido visual de los fotogramas decodificados.
Detectar un modo de este tipo puede comprender detectar un modo de prediccion temporal en el que los vectores de movimiento son dependientes de valores de POC (prediccion directa temporal). Como alternativa o ademas, detectar un modo de este tipo puede comprender detectar un modo de prediccion ponderado en el que la prediccion ponderada es dependiente de los valores de POC.
La unidad de aleatorizacion de video puede adaptarse para: detectar que el video comprimido esta codificado de acuerdo con el perfil de lmea de base de la norma H.264 y, en respuesta, modificar el video comprimido para convertirlo a otro perfil H.264.
Es decir, la unidad de aleatorizacion de video puede adaptarse para modificar la sintaxis del flujo de video comprimido, para convertirlo desde un flujo de bits de perfil de lmea de base conforme en un flujo de bits que cumple con un perfil diferente, preferentemente el perfil principal. En el perfil de lmea de base, el orden de presentacion de fotogramas es tfpicamente el mismo que su orden de decodificacion. Por lo tanto, si un video de perfil de lmea de base se aleatorizo modificando el POC de ciertos fotogramas, un usuario malicioso podna desaleatorizar el video presentando los fotogramas en el orden en el que se decodificaron. Convertir el video a otro perfil (en particular, el perfil principal) puede ayudar a distinguir el hecho de que el orden de presentacion verdadero es el mismo que el orden de decodificacion.
Tambien se proporciona un dispositivo electronico portatil tal como un telefono movil o dispositivo informatico de tableta, que comprende un aparato como se ha resumido anteriormente.
La presente invencion puede ser particularmente beneficiosa en un dispositivo de este tipo, puesto que es comun que se proporcione un reproductor de video como una aplicacion de software en un dispositivo de este tipo. Esta aplicacion se ejecuta en un microprocesador o microcontrolador de fin general. Sin embargo, es tambien comun que se use un acelerador de hardware (separado del procesador de fin general) para decodificar el video comprimido, puesto que el procesador de fin general no tiene suficiente potencia de procesamiento. Incluso si el software de aplicacion de reproductor de video y el dispositivo acelerador de hardware fueran seguros (individualmente), puede ser posible para un usuario malicioso interceptar el video entre la aplicacion de software (procesador de fin general) y el acelerador de hardware. De acuerdo con una realizacion de la presente invencion, el software de aplicacion controla el procesador de fin general para aleatorizar el video comprimido antes de enviarlo al acelerador de hardware, y controla el procesador de fin general para desaleatorizar el video descomprimido aleatorizado recibido desde el acelerador de hardware. Es decir, las funciones de la unidad de aleatorizacion y unidad de desaleatorizacion pueden realizarse mediante el procesador de fin general bajo el control del software de aplicacion de reproductor de video.
De acuerdo con otro aspecto de la invencion, se proporciona un metodo de decodificacion de un video comprimido, que comprende:
aleatorizar el video comprimido, para producir un video comprimido aleatorizado;
decodificar el video comprimido aleatorizado, para producir un video descomprimido aleatorizado; y
desaleatorizar el video descomprimido aleatorizado, para producir un video descomprimido desaleatorizado.
5
10
15
20
25
30
35
40
45
50
55
60
65
Se proporciona tambien un medio legible por ordenador no transitorio que almacena un programa informatico, comprendiendo el programa informatico medios de codigo de programa informatico adaptados para realizar todas las etapas de un metodo como se ha resumido anteriormente cuando dicho programa se ejecuta en un ordenador.
La invencion se describira ahora a modo de ejemplo con referencia a los dibujos adjuntos, en los que:
la Figura 1 muestra un reproductor de video convencional ideal;
la Figura 2 muestra un reproductor de video de acuerdo con una realizacion de la invencion;
la Figura 3 muestra la unidad de aleatorizacion de video de la Figura 2 en mayor detalle;
la Figura 4 muestra la unidad de desaleatorizacion de video de la Figura 2 en mayor detalle;
la Figura 5 ilustra los diferentes tipos de fotograma usados de acuerdo con una realizacion de la invencion;
la Figura 6 es un diagrama de flujo que ilustra aleatorizacion mediante redistribucion;
la Figura 7 es un diagrama de flujo que ilustra aleatorizacion mediante insercion de AU;
la Figura 8 es un diagrama de flujo que ilustra aleatorizacion mediante sustitucion de AU;
la Figura 9 es un diagrama de flujo que ilustra un procedimiento de desaleatorizacion;
la Figura 10 es un diagrama de flujo de pseudo-codigo que ilustra las etapas iniciales de un metodo de aleatorizacion para un video codificado usando H.264;
la Figura 11 es un diagrama de flujo de pseudo-codigo que continua desde la Figura 10, que ilustra aleatorizacion mediante redistribucion;
la Figura 12 es un diagrama de flujo de pseudo-codigo que continua desde la Figura 11, que ilustra aleatorizacion mediante insercion de fotograma; y
la Figura 13 es un diagrama de flujo que ilustra un metodo ejecutado mediante la unidad de control aleatorio de la Figura 2.
Para consumir contenido de video de alta calidad HD en dispositivos inteligentes tfpicos, es deseable usar un decodificador de video de hardware (HW) disponible en el dispositivo inteligente. Esto es debido a que un decodificador de software, que se ejecuta en un procesador de fin general en un dispositivo inteligente, puede no tener suficiente potencia de procesamiento para decodificar video de HD. Un sistema tfpico estana compuesto de un reproductor de video (normalmente integrado en la aplicacion del proveedor de servicio) de software (SW) que empleara el decodificador de video de HW de la plataforma para realizar la decodificacion real del flujo de video comprimido.
Un ejemplo de un sistema de este tipo se ilustra en la Figura 1. Un flujo de audio y video se entrega desde una fuente 100 a un reproductor de video de software 110. El reproductor de video de software 110 es una aplicacion de software, que se ejecuta en un procesador de fin general de un dispositivo inteligente. En el reproductor de video de software 110, el audio y el video se manejan mediante rutas de procesamiento diferentes. El flujo de audio se desempaqueta mediante una unidad de desempaquetamiento de audio 112 y se pada a una unidad de desencriptacion de audio 114 para desencriptarse. El flujo desencriptado se decodifica mediante el decodificador de audio 116 antes de pasarse al representador de audio 118. Este emite una senal de audio que se entrega a un sumidero de audio 140 (por ejemplo, un altavoz). El flujo de video se desempaqueta mediante una unidad de desempaquetamiento de video 122 y a continuacion se desencripta mediante la unidad de desencriptacion de video 124. El reproductor de video de software 110 a continuacion envfa el video desencriptado a un decodificador de video de hardware 130, para decodificacion. El video decodificado (descomprimido) se envfa de vuelta desde el decodificador de video de hardware 130 al reproductor de video de software 110 y se representa mediante un representador de video 128. La senal de video emitida mediante el representador de video 128 se suministra a un sumidero de video 150 (por ejemplo, la pantalla de visualizacion del dispositivo inteligente). Como entenderan los expertos en la materia, los componentes 112-128 del reproductor de video de software 110 representan unidades funcionales de la aplicacion de software, todas las cuales se ejecutan en el procesador de fin general (no mostrado). Sin embargo, el decodificador de video de hardware 130 es un dispositivo de hardware separado.
El reproductor de video de software 110 se protege tfpicamente mediante mecanismos de seguridad de software, tales como: ofuscacion de codigo, anti-depuracion, anti-manipulacion y anti-acceso privilegiado a la rafz. Sin embargo, hay dos puntos en esta arquitectura donde un usuario malicioso podna obtener acceso al contenido. En primer lugar, entre la unidad de desencriptacion de video 124 y el decodificador de video de hardware 130, el video esta disponible desencriptado, en el dominio comprimido. En segundo lugar, entre el decodificador de video de hardware 130 y el representador de video 128, el video esta disponible desencriptado en el dominio de pixel.
Los presentes inventores han reconocido que sena deseable evitar la necesidad de un entorno confiable en la plataforma, pero aun asf posibilitar la distribucion segura de video de alta calidad HD. La solucion proporcionada de acuerdo con las realizaciones de la presente invencion es poner en marcha un mecanismo de aleatorizacion de video en el dominio comprimido y proporcionar un mecanismo de desaleatorizacion de video en el dominio de pixel. Con este enfoque, si el contenido se obtiene mediante un usuario malicioso en los puntos debiles anteriormente identificados, sera apenas visible debido a la degradacion visual creada por el aleatorizador. En algunas realizaciones, para hacer el sistema mas robusto a ingeniena inversa del flujo aleatorizado por un usuario malicioso, se usa un mecanismo de control aleatorio, para activar el mecanismo de aleatorizacion en momentos arbitrarios en el tiempo.
5
10
15
20
25
30
35
40
45
50
55
60
65
La Figura 2 ilustra un reproductor de v^deo de software 210 de acuerdo con una realizacion de la presente invencion. Este esta basado en la arquitectura de la Figura 1. A menos que se especifique de otra manera, los componentes compartidos son similares y no se describiran de nuevo. Las diferencias principales son que el reproductor de video de software 210 comprende una unidad de aleatorizacion de video 220, una unidad de desaleatorizacion de video 230 y una unidad de control aleatorio 240. La unidad de aleatorizacion de video 220 opera en el dominio
comprimido. Recibe un flujo elemental comprimido de video desencriptado, desde la unidad de desencriptacion de
video 124 y genera un flujo elemental comprimido de video aleatorizado como salida. Esta salida se suministra al
decodificador de video de hardware 130 (que puede ser identico al decodificador de la Figura 1). La unidad de
desaleatorizacion de video 230 opera en el dominio de pixel. Toma un video descomprimido aleatorizado, recibido desde el decodificador de video de hardware 130, y genera un video descomprimido desaleatorizado basandose en metadatos de aleatorizacion. Los metadatos de aleatorizacion se suministran desde la unidad de aleatorizacion de video 220 a la unidad de desaleatorizacion de video 230, dentro del reproductor de video de software 210. La salida de la unidad de desaleatorizacion de video 230 se suministra al representador de video 128 para presentacion. El modulo de control aleatorio 240 controla la unidad de aleatorizacion de video 220, para activar aleatoriamente el proceso de aleatorizacion.
La unidad de aleatorizacion de video 220 y la unidad de desaleatorizacion de video 230 estan integradas en el reproductor de video de software 210 y pueden protegerse mediante mecanismos de proteccion de software (algunos ejemplos de los cuales son conocidos en la tecnica).
La unidad de aleatorizacion de video 220 procesa las unidades de acceso (AU) en el dominio comprimido e implementa varios mecanismos de aleatorizacion que pueden realizarse independientemente o en combinacion. Estos incluyen: reordenacion de AU de video (redistribucion); insercion de AU de video; eliminacion de AU de video; y sustitucion de AU de video. Las funciones del modulo de control aleatorio 240 y la unidad de aleatorizacion de video 220 se ilustran en mayor detalle en la Figura 3. El modulo de control 240 comprende un generador de numeros aleatorios 242. Los numeros aleatorios que genera se usan para controlar la activacion de los cuatro mecanismos de aleatorizacion de la unidad de aleatorizacion de video 220. La unidad de aleatorizacion de video 220 recibe las AU mediante una memoria intermedia de entrada 310 (que los recibe desde la unidad de desencriptacion de video 124. A partir de esta memoria intermedia, las AU se suministran a cuatro modulos funcionales que implementan la redistribucion, insercion, eliminacion y sustitucion de las AU, respectivamente. Las AU aleatorizadas se emiten a continuacion a una memoria intermedia de salida 330, desde donde se enviaran al decodificador de video de hardware 130. Los metadatos acerca de la aleatorizacion se generan en los modulos funcionales. Estos metadatos de aleatorizacion describen las operaciones que tienen que aplicarse a las AU (es decir, como se han modificado en los procesos de aleatorizacion). Estos metadatos de aleatorizacion se emiten a una memoria intermedia de metadatos 340. Desde este punto, se entregan a la unidad de desaleatorizacion de video 230, que usa los metadatos de aleatorizacion para reconstruir (desaleatorizar) el flujo de video descomprimido correctamente. Para insercion y sustitucion de las AU, necesitan proporcionarse AU adicionales. Estas se almacenan en una memoria intermedia de insercion de AU 222. En la presente realizacion, las AU insertadas son copias de otras AU en el flujo elemental.
El modulo de desaleatorizacion de video 230 procesa fotogramas en el dominio de pixel e implementa varios mecanismos de desaleatorizacion que son dependientes de los mecanismos de aleatorizacion aplicados en la unidad de aleatorizacion de video 220. Estos incluyen un redistribuidor de fotogramas; un descartador de fotogramas; y un interpolador de fotogramas. Esto se ilustra en la Figura 4. Una memoria intermedia de entrada de fotograma 410 recibe fotogramas del video aleatorizado descomprimido desde el decodificador de video de hardware 130. La unidad de desaleatorizacion de video 230 toma fotogramas desde esta memoria intermedia de entrada de fotograma 410 y toma los metadatos de aleatorizacion desde la memoria intermedia de metadatos 340 como sus entradas. Modifica los fotogramas de manera apropiada, para invertir los efectos de la aleatorizacion del dominio comprimido que se aplico anteriormente. La redistribucion de fotogramas deshace la redistribucion de AU realizada en la unidad de aleatorizacion de video 220. La eliminacion de fotogramas deshace la insercion de AU realizada en la unidad de aleatorizacion de video 220. La interpolacion de fotogramas deshace la eliminacion de AU realizada en la unidad de aleatorizacion de video 220. La interpolacion reconstruye el fotograma perdido desde fotogramas vecinos (por ejemplo, usando tecnicas conocidas para interpolacion de movimiento). Como tal, el fotograma reconstruido puede no ser identico al fotograma codificado en la Au que se elimino. Sin embargo, siempre que las diferencias sean pequenas, pueden no ser facilmente perceptibles por un observador.
Aunque puede haberse llevado a cabo cualquiera de cuatro operaciones en la unidad de aleatorizacion de video 220, unicamente son necesarias tres unidades funcionalidades para desaleatorizar el video. Esto es debido a que la sustitucion de AU en la unidad de aleatorizacion de video 220 puede verse como una combinacion de eliminacion de fotograma e insercion de fotograma. Por lo tanto, puede deshacerse por una combinacion de eliminacion de fotograma e interpolacion de fotograma.
Como se usa en el presente documento, una “Unidad de Acceso” (AU) significa una subestructura logica de un flujo elemental. El flujo elemental es un flujo de bits binario que contiene datos de video codificado (es decir, comprimido). Cada fotograma es una version decodificada (descomprimida) de una respectiva unidad de acceso.
5
10
15
20
25
30
35
40
45
50
55
60
65
Datos de v^deo “comprimido” significa una representacion de un video que no comprime datos de p^xeles adecuados para presentar en una pantalla. Se prefiere una representacion mas compacta que los datos de pfxeles en bruto (en terminos del numero de bits necesarios para representar el video). Los datos de video comprimido deben decodificarse para reconstruir datos de pfxeles adecuados para representacion. En algunas realizaciones el video se comprime usando un metodo descompresion codificado por transformacion de movimiento compensado basado en bloques, tal como aquellos que seran familiares para el experto en la materia.
Un ejemplo detallado se describira ahora, que muestra como pueden implementarse las operaciones de aleatorizacion y desaleatorizacion, usando el codec de video H.264. Los expertos en la materia apreciaran que la invencion no esta limitada en alcance a este codec y, entendiendo los principios desvelados a continuacion, pueden construirse ejemplos similares para otros codecs.
Los metodos de aleatorizacion descritos a continuacion son dependientes de los tipos de fotogramas en el dominio comprimido. Los expertos en la materia estaran familiarizados con los tipos habituales de fotogramas comprimidos encontrados en esquemas de codificacion de movimiento compensado convencionales. Lo siguientes es un breve resumen de los tipos y sus caractensticas relevantes. Estos se ilustran en la Figura 5.
• Intra fotograma: (“fotograma I”) este tipo de fotograma se codifica sin referencia a ningun fotograma pasado o futuro. Un tipo particular de un fotograma I es un fotograma de Refresco de Decodificador Instantaneo (IDR). Ningun fotograma recibido despues de un fotograma de IDR puede usar ningun fotograma antes del fotograma de IDR como un fotograma de referencia para decodificacion.
• Fotograma predicho: (“fotograma P”) un fotograma que se codifica con referencia a un fotograma pasado. Este tipo de fotograma puede usarse tambien como un fotograma de referencia para uno o mas fotogramas decodificados posteriormente.
• Fotograma predicho bidireccional: (“fotograma B”) un fotograma que se codifica con referencia a fotogramas pasados y/o futuros.
Puede extraerse una distincion entre fotogramas que se usaran como fotogramas de referencia en el proceso de decodificacion y aquellos que no se usaran como fotogramas de referencia en el proceso de decodificacion. En el caso de H.264, esto se aplica principalmente a fotogramas B pero tambien ocasionalmente a fotogramas P. Podemos hacer la distincion entre fotogramas B (y fotogramas P) que se usaran como referencias para la codificacion de otros fotogramas y fotogramas B (y fotogramas P) que no se usaran como referencia para la codificacion de otros fotogramas. Cuando se requiera, por motivos de claridad, los primeros se denominaran “fotogramas rB” (respectivamente “fotogramas rP”) y los ultimos se denominaran “fotogramas nrB” (respectivamente “fotogramas nrP”).
Los metodos de aleatorizacion son de manera que el flujo resultante del mecanismo de aleatorizacion permanece conforme con la sintaxis del esquema de codificacion. En otras palabras, permanece un flujo de bits codificado valido, de acuerdo con la definicion del codec. Esto es deseable para evitar errores en el decodificador de HW y de modo que el decodificador no requiera modificacion.
Los metodos de aleatorizacion se aplican en el dominio comprimido pero son reversibles en el dominio de pixel. Realizar la aleatorizacion no requiere decodificacion de los fotogramas recibidos - en su lugar, la aleatorizacion opera en elementos de sintaxis de nivel superior del flujo de video comprimido.
El recuento de orden de instantanea (POC) se usa en el proceso de decodificacion para identificar el orden de presentacion (visualizacion) de cada uno de los fotogramas decodificados. Puesto que el uso de la prediccion bidireccional del orden de fotograma decodificado es diferente del orden de visualizacion - los fotogramas de referencia para un fotograma B deben decodificarse antes del mismo fotograma B, incluso aunque el fotograma B tenga lugar en un instante de presentacion anterior. El POC normalmente esta embebido en la sintaxis de alto nivel de un fotograma codificado y se usa en la ultima etapa del proceso de decodificacion, para reordenar apropiadamente los fotogramas de acuerdo con su orden de visualizacion. Los procesos de aleatorizacion descritos a continuacion manipulan el POC de una pluralidad de fotogramas (opcionalmente ademas de otras modificaciones).
La aleatorizacion mediante reordenacion se ilustra en la Figura 6. El principio es reorganizar el orden de presentacion de algunos de los fotogramas, cambiando el valor de POC embebido en cada unidad de acceso. Si no se compensa (en la unidad de desaleatorizacion de video 230) esto crea molestia visual en forma de fuerte vibracion. Cuanto mas movimiento este presente en el contenido de video, mas pronunciada sera la molestia. El proceso de desaleatorizacion correspondiente reordena los fotogramas apropiadamente. Una restriccion se aplica para las AU que codifican fotogramas de referencia: si se usa una AU re-ordenada como referencia, su mdice de referencia debera mantenerse de modo que las AU que lo usan como una AU de referencia en su proceso de decodificacion se decodifican apropiadamente.
El procedimiento de redistribucion empieza en la etapa 610, en la que la unidad de aleatorizacion de video 220 comprueba si se ha activado la redistribucion mediante la unidad de control aleatorio 240. Si es asf, la siguiente AU se lee desde la memoria intermedia de entrada 310, en la etapa 620. A continuacion, en la etapa 630, la unidad de
5
10
15
20
25
30
35
40
45
50
55
60
65
aleatorizacion de v^deo 220 comprueba si el POC puede cambiarse sin modificacion adicional de la AU. Si es asf, el metodo continua a la etapa 660 y el valor de POC se cambia. Si el POC no puede cambiarse sin adaptacion adicional de la AU, el metodo continua a la etapa 640 y la unidad de aleatorizacion comprueba si el POC puede cambiarse en conjunto con la adaptacion adicional de la Au. Si es asf, el metodo continua a la etapa 650 y se realiza la adaptacion adicional necesaria de la AU. El metodo a continuacion continua a la etapa 660. Despues de la etapa 660, la AU con su valor de POC modificado se escribe en la memoria intermedia de salida 330, en la etapa 670. En la etapa 610, si la unidad de aleatorizacion de video 220 determina que no se ha activado la redistribucion, el metodo continua a la etapa 690. El metodo puede continuar tambien a la etapa 690 si se determina en la etapa 640 que el POC no puede cambiarse (incluso con adaptacion adicional de la AU). En la etapa 690, la unidad de aleatorizacion de video 220 comprueba si el POC debe adaptarse debido a que se ha realizado aleatorizacion en las AU anteriores. (La aleatorizacion aplicada a los valores de POC de las AU anteriores puede tener un efecto en cadena en los valores de POC de Au posteriores, incluso si estas AU posteriores no se aleatorizan ellas mismas). En este caso, el metodo continua a la etapa 660, para actualizar los valores de POC. De otra manera, el metodo continua directamente a la etapa 670, para escribir la AU en la memoria intermedia de salida 330. Finalmente, en la etapa 680, se escriben metadatos de aleatorizacion a la memoria intermedia de metadatos 340. El procedimiento se repite para cada unidad de acceso. Despues de la unidad de acceso final, el procedimiento de redistribucion finaliza.
La aleatorizacion mediante insercion de AU se ilustra en la Figura 7. El principio es insertar AU entre AU existentes en el dominio comprimido. Si el contenido de las AU insertadas esta relativamente descorrelacionado con las AU adyacentes creara discontinuidades visuales fuertes, provocando molestias (si no se eliminan mediante la desaleatorizacion apropiada). Cuanto menos movimiento este presente en el contenido mayor molestia se creara. El proceso de desaleatorizacion comprende eliminar los fotogramas adicionales insertados. Preferentemente, las AU insertadas no debenan ser facilmente identificables (para un usuario malicioso). De manera ideal, la AU insertada debena ser diferente en cada insercion. Una restriccion es que las AU insertadas no deberan usarse como una referencia para la decodificacion de los fotogramas codificados originales en el flujo. Si un fotograma original tuviera que decodificarse usando un fotograma insertado como un fotograma de referencia, su proceso de decodificacion se corrompena. Para evitar esto en la presente realizacion, el sistema asegura que los fotogramas insertados no entren en la memoria intermedia de referencia, usando unicamente una AU de nrB o una de nrP presente en el flujo. Como alternativa o ademas, el sistema podna insertar un conjunto continuo de AU cuya decodificacion es autonoma. Sin embargo, en el ultimo caso, esto puede realizarse unicamente inmediatamente antes de un fotograma de IDR, como se ejemplifica a continuacion.
La estructura de flujo de entrada es:
IDR P P P P P P B P B P IDR P B P B
La estructura de flujo de salida, despues de la insercion de un Grupo de Instantaneas (GOP) autonomas [IDR P P P] antes del segundo fotograma de IDR, es:
IDR P P P P P P B P B P [IDR P P P] IDR P B P B
Puesto que el GOP se inserta inmediatamente antes de un fotograma de IDR, ninguno de los fotogramas posteriores hara referencia a fotogramas en el GOP insertados como fotogramas de referencia. Para que esa decodificacion del GOP insertado sea autonoma, el mismo GOP insertado comienza tambien con un fotograma de IDR.
Con referencia a la Figura 7, el proceso se insercion comienza y se lee una AU desde la memoria intermedia de entrada 310, en la etapa 710. A continuacion, en la etapa 715, la unidad de aleatorizacion de video 220 comprueba si se ha activado insercion de AU mediante la unidad de control aleatorio 240. Si se ha activado la insercion de AU, el metodo continua a la etapa 720 y la unidad de aleatorizacion de video 220 comprueba si puede insertarse una AU sin adaptacion adicional del flujo elemental. Si es asf, el metodo continua a la etapa 735 y la AU a insertarse se lee desde la memoria intermedia de insercion de AU 222. El POC de la AU insertada se actualiza en la etapa 740. Despues de eso, el metodo continua a la etapa 760 y la unidad de aleatorizacion comprueba si el POC debe actualizarse debido a la aleatorizacion que se realizo en AU anteriores. Si es asf, el POC se actualiza en la etapa 765 y el metodo continua a la etapa 745. Si no, el metodo continua directamente a la etapa 745. En la etapa 745, si se ha insertado una AU, la AU insertada se escribe en la memoria intermedia de salida 330. El metodo a continuacion continua a la etapa 750, en la que la AU original (lefda desde la memoria intermedia de entrada en la etapa 710) se escribe en la memoria intermedia de salida 330. Finalmente, los metadatos de aleatorizacion se escriben en la memoria intermedia de metadatos 340, en la etapa 755. En la etapa 715, si la unidad de aleatorizacion determina que no se ha activado esa insercion de AU, el metodo continua a la etapa 760. En la etapa 720, si la unidad de aleatorizacion 220 determina que una AU no puede insertarse sin adaptacion adicional del flujo elemental, el metodo continua a la etapa 725. En la etapa 725, la unidad de aleatorizacion de video 220 comprueba si puede insertarse una AU en conjunto con adaptacion adicional del flujo de bits. Si es asf, la adaptacion necesaria se realiza en la etapa 730 y el metodo continua a la etapa 735. Si una AU no puede insertarse incluso con adaptacion adicional del flujo, el metodo continua desde la etapa 725 a la etapa 760. Este procedimiento se realiza para cada AU en la secuencia. Cuando se han procesado todas las AU, el procedimiento finaliza.
5
10
15
20
25
30
35
40
45
50
55
60
65
La aleatorizacion puede comprender tambien eliminacion de las AU, que es la inversa de insertar las AU y es relativamente facil de implementar. Las AU se leen desde la memoria intermedia de entrada 310 y se copian a la memoria intermedia de salida 330 a menos que se tengan que eliminar. Es decir, unicamente las AU que no se eliminan se escriben en la memoria intermedia de salida 330. En general, no hay necesidad de cambiar el valor de POC de cada AU, excepto cuando necesita actualizarse como consecuencia de aleatorizacion que se aplico a AU anteriores en el video. Se crea molestia visual puesto que se reduce la velocidad de fotogramas del contenido. El proceso de desaleatorizacion comprende reconstruir los fotogramas que corresponden a las AU perdidas, en el dominio de pixel, por medio de interpolacion de fotograma basada en movimiento. Puesto que la reconstruccion por interpolacion no es perfecta, la representacion final puede contener algunos artefactos visuales relacionados con el proceso de re-interpolacion. Preferentemente, las AU que se usaran como fotogramas de referencia para decodificar otros fotogramas no se eliminan. Es decir, unicamente se eliminan AU de nrB o nrP.
La aleatorizacion mediante sustitucion de AU se ilustra en la Figura 8. El principio es combinar eliminacion de AU e insercion de AU. Con referencia a la Figura 8, cuando se inicia el proceso de aleatorizacion de sustitucion de AU, se lee una AU desde la memoria intermedia de entrada 310, en la etapa 805. A continuacion, la unidad de aleatorizacion de video 220 comprueba, en la etapa 810, si la sustitucion de AU se ha activado por la unidad de control aleatorio 240. Si es asf, el metodo continua a la etapa 820. En la etapa 820, la unidad de aleatorizacion de video 220 comprueba si esta AU puede sustituirse sin adaptacion adicional del flujo. Si es asf, el metodo continua a la etapa 835 y se lee la AU a insertarse en lugar de la AU actual desde la memoria intermedia de insercion de AU 222. El metodo a continuacion continua a la etapa 840. En este punto, el POC de la AU de fotograma insertada se actualiza. A continuacion, en la etapa 845, la Au (insertada) se escribe en la memoria intermedia de salida 330. Finalmente, en la etapa 850, los metadatos de aleatorizacion correspondientes se escriben en la memoria intermedia de metadatos 340. Si la unidad de aleatorizacion determina, en la etapa 820, que la AU no puede sustituirse sin adaptacion adicional del flujo, el metodo continua a la etapa 825 y la unidad de aleatorizacion comprueba si la AU puede sustituirse en conjunto con adaptacion adicional. Si es asf, el metodo continua a la etapa 830 y se realiza la adaptacion adicional necesaria. Despues de eso, el metodo continua a la etapa 835, como anteriormente. En la etapa 810, si no se ha activado sustitucion de AU, el metodo continua a la etapa 855 y la unidad de aleatorizacion de video 220 comprueba si el POC necesita actualizarse debido a que se realizo aleatorizacion en AU anteriores. Si es asf, el metodo continua a la etapa 840 y a continuacion a la etapa 845. Si no, el metodo continua directamente a la etapa 845, en la que la AU (original) se escribe en la memoria intermedia de salida. En la etapa 825, si la AU actual no puede sustituirse incluso en conjunto con adaptacion adicional del flujo, el metodo tambien continua a la etapa 855. Despues de que se ha realizado el proceso para cada AU, el proceso finaliza.
La Figura 9 resume el proceso de desaleatorizacion. Cuando la desaleatorizacion comienza, la unidad de desaleatorizacion de video 230 lee metadatos de aleatorizacion desde la memoria intermedia de metadatos 340, en la etapa 910. A continuacion, en la etapa 915, la unidad de desaleatorizacion de video 230 comprueba (usando los metadatos) si se realizo redistribucion de POC mediante la unidad de aleatorizacion de video 220. Si ha tenido lugar redistribucion de POC, el metodo continua a la etapa 920 y la unidad de desaleatorizacion de video 230 lee el fotograma correcto desde la memoria intermedia de entrada de fotograma 410. Desde este punto, el metodo continua a la etapa 960 y el fotograma se escribe en una memoria intermedia de salida de fotograma 420. Si no hubo redistribucion de pOc, el metodo continua a la etapa 925 y la unidad de desaleatorizacion comprueba si se ha insertado una AU. Si es asf, el metodo continua a la etapa 930 y se descarta el siguiente fotograma en la memoria intermedia de entrada de fotograma 410. Si no se ha insertado Au, el metodo continua en su lugar a la etapa 935 y la unidad de desaleatorizacion de video 230 comprueba si se ha eliminado una AU. Si es asf, el fotograma faltante se reconstruye mediante interpolacion, en la etapa 940. Desde este punto, el metodo continua a la etapa 960 y el fotograma interpolado se escribe en la memoria intermedia de salida de fotograma 420. Si no se ha eliminado una AU, el metodo continua en su lugar a la etapa 945 y la unidad de desaleatorizacion de video 230 comprueba si se ha sustituido una AU. Si es asf, el metodo continua a la etapa 950. El siguiente fotograma en la memoria intermedia de entrada de fotograma 410 se descarta y el fotograma faltante se reconstruye mediante interpolacion. Una vez mas, el metodo continua a la etapa 960 y el fotograma interpolado se escribe en la memoria intermedia de salida de fotograma 420. Si no ha habido sustitucion de AU, el metodo continua desde la etapa 945 a la etapa 955. Esto significa que no se realizo aleatorizacion en esta parte del video. El siguiente fotograma se lee desde la memoria intermedia de entrada de fotograma 410 y el metodo continua directamente a la etapa 960, en la que este fotograma se escribe en la memoria intermedia de salida de fotograma 420. Despues de que, o bien, todas los fotogramas se han descartado en la etapa 930, o bien, se han escrito en la memoria intermedia de salida en la etapa 960, el proceso finaliza.
Una implementacion espedfica de los procesos de aleatorizacion se describira ahora en mayor detalle, para un video comprimido codificado de acuerdo con la norma H.264. En particular, se proporcionaran ejemplos de como implementar aleatorizacion redistribuyendo y aleatorizando mediante insercion de fotograma, para un flujo codificado H.264. Cuando se usa una variable sin definirse de otra manera en este punto, puede suponerse que la variable se define en la norma H.264 y que esta presente en el flujo de bits de video comprimido. La norma H.264 se define en la Recomendacion de la ITU-T de H.264, “Advanced video coding for generic audiovisual services”. Esta es la misma que la norma conocida como MPEG-4 AVC, definida en ISO/IEC 14496-10, “Information technology -- Coding of audio-visual objects -- Part 10: Advanced Video Coding”. En caso de cualquier ambiguedad, debenan tomarse las referencias a la norma para hacer referencia a la version, revision o edicion de la norma vigente en la fecha de
5
10
15
20
25
30
35
40
45
50
55
60
65
prioridad de la presente invencion. Sin embargo, es habitual que las ultimas versiones de tales normas sean compatibles hacia atras con versiones anteriores - las ultimas versiones amplfan la norma, mientras mantienen los elementos normativos de las versiones anteriores. Por lo tanto, se ha de esperar que no surja ambiguedad y que un flujo de bits que cumpla con cualquier version futura de la norma tambien cumpla con la version vigente en la fecha de prioridad.
Alguna informacion preliminar es util para entender los detalles de como se implementa la aleatorizacion.
El Recuento de Orden de Instantanea (POC) se usa en el proceso de decodificacion de H.264 para identificar el orden de visualizacion (es decir, orden de presentacion) de cada fotograma decodificado. Para prediccion bidireccional, en particular, el orden en el que se decodifican los fotogramas puede ser diferente del orden en el que se visualizan. Una manera de implicar una redistribucion de los fotogramas decodificados es modificar el POC en el flujo codificado. El POC de cada AU se codifica explfcitamente en el flujo (modo 0) o se determina implfcitamente durante el proceso de decodificacion (modo 1 y modo 2). Puesto que la aleatorizacion cambiara el POC en el flujo, si la decodificacion es implfcita es necesario convertir desde uno de los modos implfcitos (modo 1 y modo 2) al modo explfcito (modo 0). Para detalles adicionales de como se recupera el POC durante el proceso de decodificacion H.264, se hace referencia al lector al documento “H.264/AVC Frame and picture management” (lain G. Richardson, enero de 2004), disponible en lmea en: www4.rgu.ac.uk/files/avc_picmanagement_draft1.pdf. Esta informacion ya sera familiar para los expertos en la materia.
Hay dos modos de decodificacion en los que la etapa de compensacion de movimiento realizada por el decodificador de video de hardware 130 sera dependiente del valor de POC. Estos son los modos de “prediccion directa temporal” y “prediccion ponderada”. Puesto que el POC no se usa simplemente para determinar el orden de presentacion, en estos modos, su uso debe detectarse por la unidad de aleatorizacion de video 220, para tenerlos en cuenta para la modificacion del POC.
El perfil de lmea de base H.264 es un perfil espedfico donde no hay prediccion bidireccional. En ese caso, el flujo de video codificado consiste exclusivamente en fotogramas I y fotogramas P. El orden de decodificacion normalmente sera identico al orden de visualizacion. En consecuencia, para un flujo de perfil de lmea de base, normalmente sera mas facil para un usuario malicioso detectar y deshacer cualquier redistribucion del orden de visualizacion de los fotogramas decodificados. Una manera para superar el problema es convertir el flujo de perfil de lmea de base en un flujo de perfil principal. Esto puede hacerse simplemente cambiando la semantica de alto nivel del flujo - por ejemplo, modificando informacion de encabezamiento. No es necesario decodificar y volver a codificar el video para convertir desde lmea de base a perfil principal.
La implementacion del proceso de aleatorizacion se describira ahora. Por claridad y simplicidad, la explicacion a continuacion no menciona la activacion y desactivacion de la aleatorizacion mediante el modulo de control aleatorio.
Si la senalizacion del POC es implfcita (modo 1 o modo 2) el flujo de bits de video comprimido se modifica de modo que la senalizacion se haga explfcita (modo 0). Esto puede realizarse en dos etapas. En primer lugar, la estructura de datos sequence_parameter_set se modifica en dos aspectos:
pic_order_cnt_type = 0 log2_max_pic_order_cnt_lsb_minus4 = 4
Sequence_parameter_set (SPS) es una estructura de datos de encabezamiento definida en la norma H.264. Por conveniencia del lector se reproduce en el apendice a continuacion. Los parametros en este encabezamiento definen como se codifican las AU posteriores en el flujo (hasta la siguiente aparicion de sequence_parameter_set). Observese que el valor de log2_max_pic_order_cnt_lsb_minus4 debera estar en el intervalo de 0 a 12, inclusivo.
En segundo lugar, para cada AU, modificar la estructura de datos slice_header para asignar un valor de POC explfcito en pic_order_cnt_lsb. El slice_header es una estructura de datos de encabezamiento definida en H.264, que describe como se codifica un “corte”. Tfpicamente, hay un corte para cada AU, pero es posible codificar una AU como una pluralidad de cortes, en los que cada corte representa una porcion del fotograma de video.
Para realizar la aleatorizacion, el flujo de video comprimido se analiza AU a AU. El metodo de aleatorizacion opera en grupos de AU consecutivas del mismo tipo. Cada grupo de este tipo se indicara en el presente documento como un “edit_gop”. Los valores de POC de las AU en el edit_gop se manipulan y se insertan fotogramas en el edit_gop. Limitar la manipulacion de POC a un grupo de AU consecutivas del mismo tipo ayuda a evitar una situacion en la que las AU hacen referencia a las AU de referencia incorrecta, en el proceso de decodificacion. En la presente realizacion, cada edit_gop esta limitado en tamano, para contener un maximo de 8 AU consecutivas. Esto es para limitar el retardo de procesamiento que podna introducirse por la aleatorizacion y desaleatorizacion. Si tienen lugar mas de 8 AU del mismo tipo consecutivamente en el flujo comprimido, entonces estas se subdividiran en varios edit_gop consecutivos del mismo tipo.
5
10
15
20
25
30
35
40
45
50
55
60
65
Lo siguiente es un ejemplo. Considerese la siguiente estructura de flujo:
I nrB nrB P nrB nrB P P P B B
Este flujo se dividira en 6 edit_gop:
Edit_gop_1: I Edit_gop_2: nrB nrB Edit_gop_3: P Edit_gop_4: nrB nrB Edit_gop_5: P P P Edit_gop_6: B B
Las siguientes variables se usan en el transcurso del proceso de aleatorizacion:
• Edit_gop_type: indica el tipo de AU (por ejemplo, I, rP, nrP, rB, nrB) de las AU consecutivas en el edit_gop.
• Edit_gop_size: el numero de AU consecutivas del mismo tipo que constituyen el edit_gop.
• Edit_gop_count: el numero de edit_gop procesados hasta ahora. Esto se usa en el caso de insercion de fotograma, para refrescar el origen del fotograma nrB que se esta insertando en el flujo. En otras palabras, despues de que se ha procesado un numero especificado de edit_gop, una nueva AU nrB desde el flujo de video comprimido se copiara en la memoria intermedia de insercion de AU 222.
• Get_nrb_to_insert: variable booleana (es decir, una variable binaria, que puede asumir el valor “VERDADERO” o el valor “FALSO”). Cuando es VERDADERO, esto indica que debena copiarse un fotograma nrB a la memoria intermedia de insercion de AU 222 para uso posterior como una AU insertada.
• First_AU_in_edit_gop: variable booleana que, cuando es VERDADERO, indica que la AU actualmente procesada es la primera de edit_gop.
• nextAU_type: indica el tipo de la AU en el flujo que sigue a la AU que se esta procesando actualmente.
• Direct_spatial_mv_pred_flag: un parametro H.264 presente en el flujo, que define el tipo de prediccion directa
usada en prediccion de movimiento. Para explicacion adicional, vease tambien:
http://wiki.multimedia.cx/index.php?title=Motion_Prediction
• Nr_gop: se refiere a un edit_gop constituido por AU no de referencia
• Sub_edit_gop: un subconjunto de un edit_gop excluyendo la primera AU y la ultima AU del edit_gop (en algunos casos es preferible no aleatorizar las AU al inicio y final de un edit_gop, respectivamente).
• POC_list: una lista de todos los valores de POC de las AU que constituyen el sub_edit_gop.
• New_poc_list: esta contiene una redistribucion de la lista de POC.
• Poc_org: el valor de POC original de una AU, referenciado en poc_list
• Poc_new: el valor de POC redistribuido de una AU, referenciado en New_poc_list
• Org_flag: valor booleano que indica si la AU actual estaba en el flujo original. Este se usa para distinguir AU
insertadas desde AU originales, en el flujo aleatorizado de salida.
La Figura 10 es un diagrama de flujo de pseudo-codigo que ilustra las primeras etapas del proceso de aleatorizacion realizadas mediante la unidad de aleatorizacion de video 220, de acuerdo con la presente realizacion. En primer lugar, en la etapa 1010, las variables necesarias para realizar aleatorizacion se inicializan. A continuacion, en la etapa 1020, se construye el edit_gop, usando las AU recibidas secuencialmente mediante la memoria intermedia de entrada 310. Para preparar la insercion de fotograma, el valor de POC de cada AU se multiplica por 2. La primera AU de nrB detectada se graba en la memoria intermedia de insercion de AU 222, para uso mas tarde como un fotograma insertado. La construccion del edit_gop continua hasta que se alcance el tamano maximo (8 AU), o se recupere una AU de un tipo diferente de la memoria intermedia de entrada 310.
La Figura 11 es un diagrama de flujo de pseudo-codigo que ilustra la aleatorizacion del edit_gop mediante redistribucion. Si edit_gop contiene solamente una AU, no puede redistribuirse. Analogamente, si todas las AU en el edit_gop usan prediccion directa temporal (Direct_spatial_mv_pred_flag==1), no se realiza redistribucion. Si edit_gop consiste en fotogramas nrB o nrP (es decir, si edit_gop es un nr_gop) todas las AU en el edit_gop pueden redistribuirse. De otra manera, el primer fotograma y el ultimo fotograma del edit_gop se excluyen de la redistribucion. En este ultimo caso, el edit_gop debe contener mas de 3 fotogramas para que la redistribucion sea posible. La redistribucion se consigue haciendo a new_poc_list una permutacion aleatoria de los valores de POC en poc_list. En otras palabras, el conjunto original de los valores de pOc se vuelve a asignar a las diversas AU en un orden aleatorio. Los valores de poc_org y poc_new para cada AU en el edit_gop se escriben en la memoria intermedia de metadatos 340. Org_flag se establece a VERDADERO y esta variable se escribe tambien en la memoria intermedia de metadatos 340, para cada AU.
La Figura 12 es un diagrama de flujo de pseudo-codigo que ilustra la aleatorizacion de edit_gop mediante insercion de fotograma. La insercion de fotograma se realiza en la etapa 1210, y la unidad de aleatorizacion prepara para el siguiente edit_gop en la etapa 1220.
5
10
15
20
25
30
35
40
45
50
55
60
65
En la etapa 1210, la unidad de aleatorizacion de v^deo 220 selecciona aleatoriamente posiciones en la secuencia de AU donde debieran insertarse los fotogramas adicionales. En cada posicion seleccionada, la AU de nrB que se almacena en la memoria intermedia de insercion de AU 222 se inserta en la secuencia. Como alternativa, la AU a insertarse puede generarse automaticamente - es decir, puede insertarse una AU sintetica en lugar de insertar una copia de otra AU desde el mismo flujo. El valor de POC de la AU insertada se actualiza con el valor de POC correcto. Los valores de poc_org y poc_new para cada AU insertada se escriben en la memoria intermedia de metadatos 340. Org_flag se establece a FALSO y esta variable se escribe tambien en la memoria intermedia de metadatos 340, para cada AU insertada.
En la etapa 1220, edit_gop se escribe en la memoria intermedia de salida 330. La unidad de aleatorizacion de video 220 comprueba si hay alguna AU mas para procesar. Si no, el proceso termina. Si hay aun mas AU para procesar, las variables usadas en la aleatorizacion se reinicializan. Si se han procesado 20 edit_gop desde que se refrescaran por ultima vez los contenidos de la memoria intermedia de insercion de AU, la bandera get_nrB_to_insert se establece a VERDADERO. El proceso a continuacion vuelve a la etapa 1020 en la Figura 10.
En ciertos casos, debena tenerse cuidado especial, para evitar interferir con la decodificacion del video comprimido aleatorizado.
En un primer ejemplo, se debe tener cuidado especial cuando se maneja un flujo que incorpora prediccion temporal. El parametro H.264 direct_spatial_mv_pred_flag especifica el metodo usado en el proceso de decodificacion para derivar vectores de movimiento (MV) e indices de referencia para inter prediccion como sigue:
• Si direct_spatial_mv_pred_flag es igual a 1, el proceso de derivacion para vectores de movimiento de luma para dB_Skip, B_Direct_16x16 y B_Direct_8x8 debera usar prediccion de modo directo espacial. En este caso, la prediccion directa es espacial y no depende de valores de POC de AU. Esto significa que la redistribucion de POC es posible y la insercion de fotogramas es posible.
• De otra manera - es decir, si direct_spatial_mv_pred_flag es igual a 0 - los valores de POC del primer fotograma de referencia en ambas listas de referencia (Lista0 y Lista1) y el valor de POC de los fotogramas B estan implicados en el proceso de calcular el valor de MV cuando el tipo de macro-bloque (MB) es uno de: B_Skip, B_Direct_16x16 o B_Direct_8x8. (Las listas de referencia son listas de fotogramas de referencia para el proceso de decodificacion, como se especifica mediante la norma H.264). En este caso, la prediccion directa es temporal y los valores de POC de AU estan implicados en el calculo de vector de movimiento. Esto significa que la redistribucion de POC es posible en ciertos casos, y la insercion de fotograma es posible bajo la condicion de que todos los valores de POC se multiplicaran por 2 originalmente.
En particular, para redistribucion de POC en el caso de prediccion directa temporal (es decir, cuando direct_spatial_mv_pred_flag es igual a 0):
• Para un nr_gop que consiste en fotogramas nrB, los valores de POC no debenan redistribuirse;
• Para un r_gop que consiste en fotogramas B, los valores de POC no debenan redistribuirse;
• Para un r_gop que consiste en fotogramas I/IDR/P, el algoritmo de modificacion de POC podna aplicarse aun - en principio - a algunas AU del edit_gop, puesto que unicamente la primera y la ultima AU en el edit_gop pueden implicarse en el proceso de calcular valores de MV, dentro del decodificador. Sin embargo, el valor de direct_spatial_mv_pred_flag esta presente en el slice_header, por lo que puede cambiar para cada corte en el edit_gop. En principio, sena posible redistribuir los valores de POC en un edit_gop de este tipo, pero esto requerina comprobar el valor de direct_spatial_mv_pred_flag para cada corte y calcular apropiadamente la redistribucion del POC. Por lo tanto, para evitar introducir retardo excesivo en el sistema, el presente metodo no redistribuye valores de POC si alguno de los recortes en el edit_gop tienen un direct_spatial_mv_pred_flag que es igual a 1.
Para insercion de fotograma, se aplica un unico procedimiento independientemente del valor de direct_spatial_mv_pred_flag. El valor de POC de cada fotograma se multiplica por 2, que posibilita que la unidad de aleatorizacion 220 inserte fotogramas sin afectar el calculo de vector de movimiento en el decodificador, para cualquier valor de direct_spatial_mv_pred_flag y para cualquier tipo de edit_gop.
En un segundo ejemplo necesita tenerse cuidado especial cuando se maneja un flujo que incorpora prediccion ponderada. Hay tres posibles modos de prediccion ponderada definidos en la norma H.264. El valor de weighted_bipred_idc debera ser 0, 1 o 2. Estos modos se definen como sigue:
• weighted_bipred_idc igual a 0 especifica que la prediccion ponderada por defecto debera aplicarse a cortes B.
• weighted_bipred_idc igual a 1 especifica que la prediccion ponderada explfcita debera aplicarse a cortes B.
• weighted_bipred_idc igual a 2 especifica que la prediccion ponderada implfcita debera aplicarse a cortes B.
En los primeros dos casos (0 y 1), la prediccion no es dependiente de los valores de POC de otros fotogramas y
puede realizarse redistribucion de POC e insercion de fotograma.
5
10
15
20
25
30
35
40
45
50
55
60
65
Para redistribucion de POC en el tercer caso, cuando weighted_bipred_idc es igual a 2, cambiar el valor de POC sin adaptacion adicional provocana que las instantaneas se decodificaran incorrectamente. Para evitar esto, se realiza adaptacion adicional del flujo de bits. En particular, la informacion de encabezamiento del flujo comprimido se modifica, convirtiendo el modo de prediccion ponderado desde un modo impUcito a un modo expUcito. Esto se hace en las siguientes etapas:
• Modificar el Conjunto de Parametros de Instantanea (PPS), estableciendo weighted_bipred_flag a 1,
• Calcular una weighted_table para cada fotograma e insertarla en el flujo,
• Modificar el slice_header, e indicar a que weighted_table calculada debera hacer referencia para prediccion ponderada.
Para insercion de fotograma, se aplica un unico procedimiento independientemente del valor de weighted_bipred_idc. El valor de POC de cada fotograma se multiplica por 2, que posibilita que la unidad de aleatorizacion de video 220 inserte fotogramas sin afectar la decodificacion, para cualquier valor de weighted_bipred_idc y para cualquier tipo de edit_gop.
Preferentemente, debena tenerse cuidado especial cuando se manejan flujos de perfil de lmea de base. Para aleatorizar un flujo de perfil de lmea de base, la unidad de aleatorizacion modifica la sintaxis de alto nivel del flujo de modo que se haga un flujo de perfil principal valido. Esta modificacion comprende las siguientes etapas:
• Modificar el SPS, para distinguir el flujo de perfil de lmea de base como un flujo de perfil principal; y
• Cambiar algunos fotogramas P en fotogramas B.
En el perfil de lmea base, no hay fotogramas B y generalmente el POC evolucionara de una manera incremental. Este no es el caso en el perfil principal donde el POC no es incremental entre fotogramas, debido a las diferentes ordenaciones usadas para decodificacion de las AU y presentacion de los fotogramas. En consecuencia, en el caso de un flujo de perfil de lmea de base, si la unidad de aleatorizacion simplemente modifica el POC, puede ser facil para un usuario malicioso detectar esto y deshacer la aleatorizacion. Los fotogramas P en el flujo de perfil de lmea de base pueden convertirse para parecer como fotogramas B en el flujo de perfil principal sin recodificacion y con unicamente una modificacion de sintaxis de alto nivel. Una vez que se ha adaptado la sintaxis del flujo de esta manera, el proceso de aleatorizacion puede aplicarse como ya se ha descrito anteriormente. Los valores de POC de las AU en el flujo pueden modificarse con una probabilidad reducida de que un usuario malicioso podra identificar e invertir el proceso de aleatorizacion, simplemente consiguiendo acceso a la salida del decodificador de video de hardware 130.
Para posibilitar la desaleatorizacion correcta del flujo decodificado en la unidad de desaleatorizacion de video 230 antes de representacion, se genera un conjunto de metadatos durante el proceso de aleatorizacion (redistribucion de POC o insercion de fotograma, en los ejemplos anteriormente detallados). Para cada AU que va en la memoria intermedia de salida 330, la unidad de aleatorizacion de video 220 proporciona los siguientes metadatos asociados:
• poc_org: un numero entero que se establece al valor de POC original (para una AU existente) o se establece a -1 (para un fotograma insertado)
• poc_new: un numero entero que es el valor de POC modificado despues de la aplicacion del proceso de aleatorizacion
• org_flag; un valor booleano (representado por un numero entero). Cuando este se establece a 0 indica un fotograma insertado, que debena descartarse para representacion. Cuando se establece a 1, indica un fotograma original, que debena representarse.
Los procesos de desaleatorizacion no se describiran en detalle, puesto que simplemente invierten el proceso de aleatorizacion, que se ha descrito en detalle anteriormente. Los expertos en la materia, entenderan facilmente mediante esta etapa, como implementar los procesos de desaleatorizacion correspondientes.
La descripcion anterior se ha concentrado en las modificaciones de nivel de flujo que se usan para implementar la aleatorizacion. En algunos casos, pueden requerirse modificaciones de nivel de sistema tambien. Por ejemplo, en algunos decodificadores de video conocidos, la entrada al decodificador comprende una Indicacion de Tiempo de Composicion (CTS) ademas de la AU. La indicacion de tiempo de composicion es una referencia de tiempo que indica el instante en el que un fotograma de decodificacion debera presentarse en la pantalla. (En sistemas MPEG-2, esto se conoce tambien como la indicacion de tiempo de presentacion: PTS.) La cTs normalmente se proporciona en la capa de sistema que encapsula el flujo. En un sistema ideal, la CTS y el POC estan correlacionados en tiempo. Si el decodificador usa la CTS, ademas de las AU, para decodificar el video, entonces debena modificarse la CTS en el proceso de aleatorizacion, de modo que sea coherente con el valor de POC de cada AU. Esto evitara errores en el decodificador, debido a la inconsistencia entre valores de CTS y POC.
En este caso, los metadatos de aleatorizacion para cada AU se ampliaran con las dos siguientes variables (cada una de tipo int largo) para asegurar desaleatorizacion apropiada:
5
10
15
20
25
30
35
40
45
50
55
60
65
• cts_org: el valor de CTS original o -1 para un fotograma insertado
• cts_new: el valor de CTS modificada despues de la aplicacion del proceso de aleatorizacion
Como se ha mencionado anteriormente, la descripcion de los procesos de aleatorizacion anteriores no tuvo en cuenta el uso de la unidad de control aleatorio 240, que activa y desactiva la aleatorizacion a tiempos aleatorios. Sin embargo, los detalles esenciales de la aleatorizacion son los mismos cuando se usa el modulo de control aleatorio 240. Cuando la aleatorizacion esta desactivada, para una AU dada, el valor poc_new sera igual al valor poc_org y org_flag sera igual a 1.
Un metodo ejemplar ejecutado mediante la unidad de control aleatorio 240 se describira ahora, con referencia al diagrama de flujo de la Figura 13. La unidad de control aleatorio puede operarse para activar y desactivar aleatoriamente la aleatorizacion. La Figura 13 ilustra el proceso de activacion/desactivacion para un metodo de aleatorizacion. Este proceso se replica para cada metodo de aleatorizacion. El metodo se inicia y la unidad de control aleatorio 240 selecciona aleatoriamente un numero N de 8 bits, entre 0 y 255 (excluyendo el 0 y 255). Este numero de 8 bits se genera mediante el generador de numeros aleatorios 242 de la unidad de control aleatorio 240. A continuacion, en la etapa 1315, la unidad inicia un temporizador T de granularidad To. En la etapa 1320, la unidad de control aleatorio lee el bit menos significativo b del numero N. En la etapa 1325, comprueba si b es igual a 1. Si es asf, se activa la aleatorizacion, en la etapa 1330. Si no (es decir, b es igual a 0), se desactiva la aleatorizacion, en la etapa 1335. En cualquier caso, el metodo a continuacion continua a la etapa 1340 y espera T0 segundos antes de continuar a la etapa 1345. En esta etapa, se anade T0 a la variable del temporizador T. La unidad de control aleatorio a continuacion comprueba, en la etapa 1350, si T es mayor que 255 T0 veces. Si lo es, el metodo se mueve a la etapa 1310 y se selecciona aleatoriamente un nuevo numero N. Si no, el metodo se mueve a la etapa 1355 y el numero existente N se desplaza a la derecha en un bit. Desde la etapa 1355, el metodo vuelve a la etapa 1320.
T0 se elige para que este en el orden de segundos, de modo que la aleatorizacion puede aplicarse de una manera significativa antes de que se desactive de nuevo. Opcionalmente, To puede tambien aleatorizarse, para hacer que sea mas diffcil para un usuario malicioso detectar la activacion y desactivacion de la aleatorizacion. Para el mismo fin, el numero N puede elegirse opcionalmente a partir del subconjunto de numeros enteros entre 0 y 255 que contienen no mas de dos bits identicos adyacentes (en forma binaria de N). Por ejemplo, se permitina 0b00101101, pero no 0b11100100. Esto ayuda a evitar que los medios de aleatorizacion permanezcan activados o desactivados durante un periodo continuo largo.
Aunque la invencion se ha ilustrado y descrito en detalle en los dibujos y descripcion anterior, tal ilustracion y descripcion se han de considerar ilustrativas o ejemplares y no restrictivas; la invencion no esta limitada a las realizaciones desveladas.
Por ejemplo, en las realizaciones anteriormente descritas, la mayona de las unidades funcionales del reproductor de video se implementan como software que se ejecuta en un procesador de fin general pero la decodificacion de video se realiza mediante un procesador de hardware separado. Esto no es esencial. Por ejemplo, las unidades funcionales tales como la unidad de aleatorizacion y la unidad de desaleatorizacion pueden implementarse en hardware o en software. Analogamente, no es esencial que el decodificador de video sea un procesador de video de hardware particular. En otras realizaciones, podna implementarse mediante software que se ejecuta en un procesador de fin general - ya sea el mismo procesador o un procesador diferente en el que se esta ejecutando la aplicacion de reproductor de video.
En las realizaciones anteriormente descritas, cuando se realiza aleatorizacion mediante insercion de AU, la AU insertada era una copia de otra AU en el mismo flujo de video. Otra posibilidad es sintetizar una AU artificial. Por ejemplo, la unidad de aleatorizacion puede generar una AU que representa un fotograma nrB con vectores de movimiento aleatorios y sin textura (es decir, una senal de diferencia de fotograma de movimiento compensado que es cero). Un fotograma de este tipo puede generarse automaticamente basandose en caractensticas de alto nivel del flujo (tales como anchura, altura, etc.). Puesto que se codifica usando vectores de movimiento unicamente, despues de que se ha decodificado cada bloque del fotograma sintetizado sera una copia (aleatoriamente seleccionada) de parte de un fotograma de referencia arbitrario. Este metodo puede proporcionar mayor molestia visual que simplemente insertar una copia de una AU entera.
Pueden entenderse otras variaciones a las realizaciones desveladas y efectuarse por los expertos en la materia al poner en practica la invencion reivindicada, a partir de un estudio de los dibujos, la divulgacion y las reivindicaciones adjuntas. En las reivindicaciones, la palabra “que comprende” no excluye otros elementos o etapas, y el artfculo indefinido “un”, “una”, no excluye una pluralidad. Un unico procesador u otra unidad pueden satisfacer las funciones de varios elementos indicados en las reivindicaciones. El simple hecho de que se indiquen ciertas medidas en reivindicaciones mutuamente dependientes diferentes no indica que una combinacion de estas medidas no pueda usarse para aprovechamiento. Un programa informatico puede almacenarse y/o distribuirse en un medio adecuado, tal como un medio de almacenamiento optico o un medio de estado solido suministrado junto con o como parte de otro hardware, pero puede distribuirse tambien en otras formas, tales como mediante internet u otros sistemas de telecomunicacion alambricos o inalambricos. Cualquier signo de referencia en las reivindicaciones no debena interpretarse como que limita el alcance.
5
10
15
20
25
Apendice - estructuras de datos H.264
Como se ha explicado anteriormente, en el contexto de los ejemplos detallados, un flujo de video comprimido H.264 se aleatoriza modificando el flujo de bits en varios aspectos. Por completitud y referencia conveniente, las definiciones de las estructuras de datos relevantes de la norma H.264 se reproducen a continuacion.
La columna a la derecha en cada tabla indica el tamano de cada campo de datos. El numero entre parentesis es el tamano, en bits; “v” indica un campo de tamano variable. Los siguientes tipos se definen en la norma H.264 (seccion 7.2):
• u(n): numero entero sin signo que usa n bits. Cuando n es “v” en la tabla de sintaxis, el numero de bits vana de una manera dependiente del valor de otros elementos de sintaxis. El proceso de analisis para este descriptor se especifica mediante el valor de retorno de la funcion read_bits(n) interpretado como una representacion binaria de un numero entero sin signo con el bit mas significativo escrito en primer lugar.
• ue(v): elemento de sintaxis codificado con Exp-Golomb de numero entero sin signo con el primer bit a la izquierda.
• se(v): elemento de sintaxis codificado con Exp-Golomb de numero entero con signo con el primer bit a la izquierda.
Conjunto de parametros de secuencia (SPS)
Existe al menos una aparicion de SPS en cada flujo de video. Sin embargo, SPS puede aparecer mas frecuentemente que una vez por video. En particular, para video de difusion, donde el usuario final puede unirse a la sesion en cualquier momento; o en el caso de flujo continuo adaptativo, donde los parametros de secuencia pueden cambiar dependiendo de las condiciones de la red. Los parametros encontrados en el SPS son aplicables a todas las AU posteriores hasta que se encuentre un nuevo SPS en el flujo.
seq parameter set data() {
profile idc
u(8)
constraint set0 flag
u(1)
constraint setl flag
u(1)
constraint set2 flag
u(1)
constraint set3 flag
u(1)
constraint set4 flag
u(1)
constraint set5 flag
u(1)
reserved zero 2bits /* igual a 0 */
u(2)
Level idc
u(8)
seq parameter set id
ue(v)
if(profile_idc == 100 | | profile_idc == 110 | | profile_idc == 122 | | profile_idc == 244 | | profile_idc == 44 | | profile_idc == 83 | | profile_idc == 86 | | profile_idc == 118 | | profile idc == 128) {
chroma format idc
ue(v)
if(chroma format idc == 3)
separate colour plane flag
u(1)
bit depth luma minus8
ue(v)
bit depth chroma minus8
ue(v)
qpprime y zero transform bypass flag
u(1)
seq scaling matrix present flag
u(1)
if(seq scaling matrix present flag)
for(i = 0; i < ((chroma format idc != 3) ? 8 : 12); i++) {
seq scaling list present flag[il
u(1)
if(seq scaling list present flag[il)
if(i<6)
scaling_list(ScalingList4x4[i], 16, UseDefaultScalingMatrix4x4Flag[il)
else
scaling_list(ScalingList8x8[i - 6], 64, UseDefaultScalingMatrix8x8Flag[i - 6l)
}
}
log2 max frame num minus4
ue(v)
seq parameter set data() {
pic order cnt type
ue(v)
if(pic order cnt type == 0)
log2 max pic order cnt lsb minus4
ue(v)
else if(pic order cnt type == 1) {
delta pic order always zero flag
u(1)
offset for non ref pic
se(v)
offset for top to bottom field
se(v)
num ref frames in pic order cnt cycle
ue(v)
for(i = 0; i < num ref frames in pic order cnt cycle; i++)
offset for ref frame [il
se(v)
}
max num ref frames
ue(v)
gaps in frame num value allowed flag
u(1)
pic width in mbs minusl
ue(v)
pic height in map units minusl
ue(v)
frame mbs only flag
u(1)
if(!frame mbs only flag)
mb adaptive frame field flag
u(1)
direct 8x8 inference flag
u(1)
frame cropping flag
us)
if(frame cropping flag) {
frame crop left offset
ue(v)
frame crop right offset
ue(v)
frame crop top offset
ue(v)
frame crop bottom offset
ue(v)
}
vui parameters present flag
u(1)
if(vui parameters present flag)
vui parameters()
J______________________________________________________
Conjunto de parametros de instantanea (PPS)
Hay al menos una aparicion de PPS en cada flujo de v^deo. Sin embargo, PPS puede aparecer mas frecuentemente 5 que una vez por video. En particular, para video de difusion, donde el usuario final puede unirse a la sesion en cualquier momento, o en el caso de flujo continuo adaptativo, donde los parametros de secuencia pueden cambiar dependiendo de las condiciones de la red. Los parametros encontrados en el PPS son aplicables a todas las AU posteriores hasta que se encuentre un nuevo pPs en el flujo. SPS y PPS se insertan normalmente en el flujo uno despues del otro.
10
pic parameter set rbsp() {
pic parameter set id
ue(v)
seq parameter set id
ue(v)
entropy coding mode flag
u(1)
bottom field pic order in frame present flag
u(1)
num siice groups minusl
ue(v)
if(num slice groups minusl > 0) {
slice group map type
ue(v)
if(slice group map type == 0)
for(iGroup = 0; iGroup <= num_slice_groups_minus1; iGroup++)
run length minus1[iGroup]
ue(v)
else if(slice group map type == 2)
for(iGroup = 0; iGroup < num_slice_groups_minus1; iGroup++) {
top left[iGroupl
ue(v)
bottom right[iGroupl
ue(v)
}
else if(slice_group_map_type == 3 || slice_group_map_type == 4 || slice group map type == 5) {
slice group change direction flag
41___
pic parameter set rbsp() {
slice group change rate minusl
ue(v)
} else if(slice group map type == 6) {
pic size in map units minusl
ue(v)
for(i = 0; i <= pic size in map units minusl; i++)
slice group id[il
u(v)
}
}
num ref idx I0 default active minusl
ue(v)
num ref idx I1 default active minusl
ue(v)
weighted pred flag
u(1)
weighted bipred idc
u(2)
pic init qp minus26 /* relativo a 26 */
se(v)
pic init qs minus26 /* relativo a 26 */
se(v)
chroma qp index offset
se(v)
deblocking filter control present flag
u(1)
constrained intra pred flag
u(1)
redundant pic cnt present flag
u(1)
if(more rbsp data()) {
transform 8x8 mode flag
u(1)
pic scaling matrix present flag
u(1)
if(pic scaling matrix present flag)
for(i=0; i < 6 + ((chroma_format_idc != 3) ? 2 : 6) * transform 8x8 mode flag; i++) {
pic scaling list present flag[il
u(1)
if(pic scaling list present flag[il)
if(i<6)
scaling_list(ScalingList4x4[i], 16, UseDefaultScalingMatrix4x4Flag[i])
else
scaling_list(ScalingList8x8[i-6], 64, UseDefaultScalingMatrix8x8Flag[i-6l)
}
second chroma qp index offset
se(v)
}
rbsp trailing bits()
J______________________________________________________
Sintaxis de encabezamiento de recorte
^picamente, hay un corte por AU que representa un fotograma de v^deo. Sin embargo, la norma no evita que un 5 codificador cree muchos cortes por Au, representando cada corte una porcion de un fotograma de video. Para cada corte, hay un encabezamiento de corte en el flujo de video.
slice header() {
first mb in slice
ue(v)
slice type
ue(v)
pic parameter set id
ue(v)
if(separate colour plane flag == 1)
colour plane id
u(2)
frame num
u(v)
if(!frame mbs only flag) {
field pic flag
u(1)
if(field pic flag)
bottom field flag
u(1)
}
if(IdrPicFlag)
idr pic id
ue(v)
if(pic order cnt type == 0) {
pic order cnt lsb
uiv)___
slice header() {
if(bottom_field_pic_order_in_frame_present_flag && !field pic flag)
delta pic order cnt bottom
se(v)
}
if(pic order cnt type == 1 && !delta pic order always zero flag) {
delta pic order cnt[01
se(v)
if(bottom_field_pic_order_in_frame_present_flag && field pic flag)
delta pic order cnt[1]
se(v)
}
if(redundantpiccnt presentflag)
redundant pic cnt
ue(v)
if(slice type == B)
direct-spatial mv pred flag
u(1)
if(slice type == P | | slice type == SP | | slice type == B) {
num ref idx active override flag
u(1)
if(num ref idx active override flag) {
num ref idx I0 active minusl
ue(v)
if(slice type == B)
num ref idx I1 active minusl
ue(v)
}
}
if(nal unit type == 20)
ref pic list mvc modification()/* veaseAnexo H*/
else
ref pic list modification()
if((weighted_pred_flag && (slice_type == P | | slice_type == SP)) | |(weighted bipred idc == 1 && slice type == B))
pred weight table()
if(nal ref idc != 0)
dec ref pic marking()
if(entropy coding mode flag && slice type != I && slice type != SI )
cabac init idc
ue(v)
slice qp delta
se(v)
if(slice type == SP | | slice type == SI) {
if(slice type == SP)
sp for switch flag
u(1)
slice qs delta
se(v)
}
if(deblocking filter control present flag) {
disable deblocking filter idc
ue(v)
if(disable deblocking filter idc != 1) {
slice alpha c0 offset div2
se(v)
slice beta offset div2
se(v)
}
}
if(num_slice_groups_minus1 > 0 && slice_group_map_type >= 3 && slice group map type <= 5)
slice group change cycle
u(v)
J__________________________________________________________

Claims (13)

  1. 5
    10
    15
    20
    25
    30
    35
    40
    45
    50
    55
    60
    65
    REIVINDICACIONES
    1. Aparato para decodificar un v^deo comprimido, comprendiendo el aparato:
    una unidad de aleatorizacion de v^deo (220), adaptada para recibir el v^deo comprimido y aleatorizarlo, para producir un video comprimido aleatorizado, en el que la aleatorizacion realizada mediante la unidad de aleatorizacion de video (220) comprende una o mas operaciones realizadas en unidades de acceso individuales del video comprimido; y en el que la unidad de aleatorizacion de video (220) esta adaptada para producir metadatos de aleatorizacion que describen una operacion de aleatorizacion aplicada a las unidades de acceso realizada mediante la unidad de aleatorizacion de video (220);
    un decodificador de video (130), dispuesto para recibir el video comprimido aleatorizado desde la unidad de aleatorizacion (220) y adaptado para decodificarlo, para producir un video descomprimido aleatorizado en el dominio de pixel; y
    una unidad de desaleatorizacion de video (230), dispuesta para recibir el video descomprimido aleatorizado desde el decodificador de video y adaptada para desaleatorizarlo para producir un video descomprimido desaleatorizado, en el que la unidad de desaleatorizacion de video (230) esta dispuesta para recibir los metadatos de aleatorizacion desde la unidad de aleatorizacion de video (220) y adaptada para usarlos para desaleatorizar el video descomprimido aleatorizado en el dominio de pixel recibido desde el decodificador de video (130).
  2. 2. El aparato de la reivindicacion 1, en el que la unidad de aleatorizacion de video (220) esta adaptada para aleatorizar el video comprimido de una manera que:
    no evita la decodificacion del video mediante el decodificador de video (130); modifica el contenido visual del video descomprimido aleatorizado despues de decodificacion; y es reversible mediante la unidad de desaleatorizacion de video (230), de manera que el video desaleatorizado es identico o sustancialmente identico al video que se producina si el video hubiera de decodificar mediante el decodificador de video, sin aleatorizacion.
  3. 3. El aparato de la reivindicacion 1 o la reivindicacion 2, en el que la aleatorizacion realizada mediante la unidad de aleatorizacion de video (220) comprende al menos uno de:
    cambiar una ordenacion de unidades de acceso en el video comprimido; insertar una o mas unidades de acceso adicionales en el video comprimido; y eliminar una o mas unidades de acceso del video comprimido.
  4. 4. El aparato de una cualquiera de las reivindicaciones 1 a 3, en el que la unidad de aleatorizacion de video (220) esta controlada para aplicar aleatorizacion a primeras porciones del video y no aplicar aleatorizacion a segundas porciones del video.
  5. 5. El aparato de la reivindicacion 4, en el que las primeras y segundas porciones se seleccionan aleatoriamente o pseudo-aleatoriamente.
  6. 6. El aparato de una cualquiera de las reivindicaciones 1 a 5, en el que el decodificador de video (130) es un decodificador de video de hardware.
  7. 7. El aparato de una cualquiera de las reivindicaciones 1 a 6, en el que el video comprimido y el decodificador de video cumplen con una norma de codificacion de video predeterminada; y la unidad de aleatorizacion de video (220) esta adaptada para aleatorizar el video comprimido de tal manera que el video comprimido aleatorizado cumple con la misma norma de codificacion de video.
  8. 8. El aparato de la reivindicacion 7, en el que el decodificador de video (130) y el video comprimido cumplen con la norma H.264 y en el que la aleatorizacion comprende modificar el recuento de orden de instantanea, de una pluralidad de unidades de acceso en el video comprimido H.264.
  9. 9. El aparato de la reivindicacion 8, en el que la unidad de aleatorizacion de video (220) esta adaptada para:
    detectar si el recuento de orden de instantanea esta codificado implfcitamente en el video comprimido y, en caso afirmativo, en respuesta:
    modificar informacion de encabezamiento del video comprimido para senalizar que el recuento de orden de instantanea esta codificado explfcitamente; y
    asignar un valor de recuento de orden de instantanea explfcito en cada unidad de acceso del video comprimido.
    descomprimido comprimido se
    5
    10
    15
    20
    25
    30
  10. 10. El aparato de la reivindicacion 8 o la reivindicacion 9, en el que la unidad de aleatorizacion de v^deo (220) esta adaptada para detectar en el video comprimido un modo de codificacion que requerina que el decodificador de v^deo usara el recuento de orden de instantanea para decodificar una o mas unidades de acceso y, en respuesta:
    desactivar la aleatorizacion; o
    modificar el video comprimido para convertirlo a otro perfil H.264, de modo que el decodificador de video no necesite usar el recuento de orden de instantanea para decodificar las una o mas unidades de acceso.
  11. 11. El aparato de una cualquiera de las reivindicaciones 7 a 9 en el que la unidad de aleatorizacion de video (220) esta adaptada para:
    detectar si el video comprimido esta codificado de acuerdo con el perfil de lmea de base de la norma H.264 y, en caso afirmativo, en respuesta,
    modificar el video comprimido para convertirlo a otro perfil H.264.
  12. 12. Un metodo de decodificacion de un video comprimido, que comprende:
    aleatorizar el video comprimido, para producir un video comprimido aleatorizado; en el que la aleatorizacion realizada comprende una o mas operaciones realizadas en unidades de acceso individuales del video comprimido; y en el que se producen metadatos de aleatorizacion de video que describen una operacion de aleatorizacion aplicada a las unidades de acceso realizada mediante una unidad de aleatorizacion de video (220);
    entregar el video comprimido aleatorizado a un decodificador de video (130), para decodificar el video comprimido aleatorizado para producir un video descomprimido aleatorizado en el dominio de pixel; recibir desde el decodificador de video el video descomprimido aleatorizado; y
    desaleatorizar el video descomprimido aleatorizado, para producir un video descomprimido desaleatorizado, en el que los metadatos de aleatorizacion se reciben desde la unidad de aleatorizacion de video (220) para desaleatorizar el video descomprimido aleatorizado en el dominio de pixel recibido desde el decodificador de video (130).
  13. 13. Un medio legible por ordenador no transitorio que almacena un programa informatico, comprendiendo el programa informatico medios de codigo de programa informatico adaptados para realizar todas las etapas de la reivindicacion 12 cuando dicho programa se ejecuta en un ordenador.
ES13290312.1T 2013-12-11 2013-12-11 Aparato y método para decodificar vídeo comprimido Active ES2611160T3 (es)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP13290312.1A EP2884748B1 (en) 2013-12-11 2013-12-11 Apparatus and method for decoding compressed video

Publications (1)

Publication Number Publication Date
ES2611160T3 true ES2611160T3 (es) 2017-05-05

Family

ID=49918495

Family Applications (1)

Application Number Title Priority Date Filing Date
ES13290312.1T Active ES2611160T3 (es) 2013-12-11 2013-12-11 Aparato y método para decodificar vídeo comprimido

Country Status (5)

Country Link
US (1) US9781451B2 (es)
EP (1) EP2884748B1 (es)
CN (1) CN104717553B (es)
ES (1) ES2611160T3 (es)
PL (1) PL2884748T3 (es)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105578265B (zh) * 2015-12-10 2019-03-05 杭州当虹科技有限公司 一种基于h264、h265视频分析的时间戳补偿或修正的方法
FR3050090B1 (fr) * 2016-04-08 2018-03-23 Squadeo Extraction de flux video
CN108206930A (zh) * 2016-12-16 2018-06-26 杭州海康威视数字技术股份有限公司 基于隐私遮蔽显示图像的方法及装置
US10841621B2 (en) * 2017-03-01 2020-11-17 Wyse Technology L.L.C. Fault recovery of video bitstream in remote sessions
CN109391846B (zh) * 2017-08-07 2020-09-01 浙江宇视科技有限公司 一种自适应模式选择的视频加扰方法及装置
EP3468207A1 (en) 2017-10-06 2019-04-10 Nagravision S.A. Masking technique
WO2019068353A1 (en) 2017-10-06 2019-04-11 Nagravision Sa MASKING TECHNIQUE
EP3467697A1 (en) 2017-10-06 2019-04-10 Nagravision S.A. Masking technique
US11356698B2 (en) 2019-12-30 2022-06-07 Tencent America LLC Method for parameter set reference constraints in coded video stream
CN112765027B (zh) * 2021-01-22 2022-05-17 北京航空航天大学 一种检测应用程序执行过程中冗余零的方法

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4083302B2 (ja) * 1998-08-12 2008-04-30 株式会社東芝 動画像スクランブル／デスクランブル装置
KR100594042B1 (ko) * 1999-09-22 2006-06-28 삼성전자주식회사 비동기 이동통신시스템의 멀티 스크램블링 코드 생성 장치 및 방법
FR2835141B1 (fr) * 2002-01-18 2004-02-20 Daniel Lecomte Dispositif pour securiser la transmission, l'enregistrement et la visualisation de programmes audiovisuels
US20030204718A1 (en) * 2002-04-29 2003-10-30 The Boeing Company Architecture containing embedded compression and encryption algorithms within a data file
MXPA04011537A (es) * 2002-05-21 2005-02-14 Thomson Licensing Sa Proteccion contra falsificacion de transporte clave.
FR2854530B1 (fr) * 2003-05-02 2005-07-22 Medialive Procede et dispositif pour securiser la transmission, l'enregistrement et la visualisation de flux empaquetes audiovisuels numeriques
CN101286678A (zh) * 2007-04-10 2008-10-15 桂林吉星电子等平衡动力有限公司 嵌套式永磁同步电机伺服系统及其控制运行方法
CN101821973B (zh) * 2007-06-25 2014-03-12 熵敏通讯公司 用于多通道、多流、复用的传输流处理的多格式流再复用器
KR100973657B1 (ko) * 2007-11-01 2010-08-02 경희대학교 산학협력단 디블록킹 필터링을 포함하는 코덱 사이의 트랜스코딩 방법 및 장치
US20130271571A1 (en) * 2010-12-27 2013-10-17 Telefonaktiebolaget L M Ericsson (Publ) Method and Arrangement for Processing of Encoded Video
US9143306B2 (en) * 2011-10-12 2015-09-22 Nxp B.V. Device and method for encoding bits to symbols for a communication system
US9332269B2 (en) * 2012-06-27 2016-05-03 Broadcom Corporation Slice overhead coding
CN102883167A (zh) * 2012-09-19 2013-01-16 旗瀚科技有限公司 一种视频图像数据处理方法及系统
US10182038B2 (en) * 2013-07-29 2019-01-15 Mobitv, Inc. Efficient common storage of partially encrypted content

Also Published As

Publication number Publication date
US9781451B2 (en) 2017-10-03
CN104717553B (zh) 2018-09-25
US20150163520A1 (en) 2015-06-11
EP2884748A1 (en) 2015-06-17
EP2884748B1 (en) 2016-10-19
CN104717553A (zh) 2015-06-17
PL2884748T3 (pl) 2017-05-31

Similar Documents

Publication Publication Date Title
ES2611160T3 (es) Aparato y método para decodificar vídeo comprimido
JP7303170B2 (ja) 効率的削減または効率的ランダムアクセスを可能にする画像／ビデオデータストリームについての概念
ES2808531T3 (es) Transmisión de datos de reconstrucción en una jerarquía de calidad de señal escalonada
CN113228633B (zh) 视频编解码的方法和设备
ES2837853T3 (es) Codificación de datos de vídeo para un conjunto de capas de salida
ES2371074T3 (es) Método de codificación y aparato que permite un rápido cambio de canal de vídeo comprimido.
ES2824770T3 (es) Asignación de agrupación de mosaicos y muestras en formatos de archivo HEVC y L-HEVC
JP6107969B2 (ja) Ｊｃｔｖｃ−ｌ０２２６：ｖｐｓ及びｖｐｓ＿ｅｘｔｅｎｓｉｏｎ更新
CN113678457B (zh) 视频编解码方法、计算机系统和电子设备
CN110035331B (zh) 一种媒体信息的处理方法及装置
ES2877048T3 (es) Diseño de valor de Poc para codificación de vídeo multicapa
JP2025126258A (ja) 独立的に符号化されたタイルを組み込む基本ビットストリームを保護するためのシステムおよび方法
BR112016024233B1 (pt) Método e aparelho para codificar uma imagem de camada de aperfeiçoamento em um fluxo de bits de múltiplas camadas
BR112016022080B1 (pt) Uso genérico de mensagens de sei de hevc para codecs de múltiplas camadas
CN109587478B (zh) 一种媒体信息的处理方法及装置
BR112016030377B1 (pt) Método e aparelho para converter informações de vídeo em código em um fluxo de bits, assim como memória legível por computador
TW200822756A (en) Creation and handling of a bitstream comprising video frames and auxiliary data
CN112292859A (zh) 在解码中使用带外流结尾nal单元的方法和装置
EP2611065A2 (en) Method for selectively scrambling bit-streams
ES2963550T3 (es) Incorporación de datos dentro de coeficientes transformados usando operaciones de reparto de bits
ES2711892T3 (es) Señalización de puntos de operación para el transporte de extensiones de la HEVC
JP7342261B2 (ja) 符号化されたビデオビットストリームを復号化する方法、装置及びコンピュータプログラム
CN113632456B (zh) 视频编码方法、装置和存储介质
CN113273152B (zh) 媒体解码的方法、装置与计算机可读介质
KR20080006585A (ko) 스케일러블 비디오 코딩에서 비트 스트림 순서의 시그널링