Revisión general de VP8
En general, desde la perspectiva de la eficiencia de la compresión, VP8 es mucho peor que H.264. Las principales debilidades mencionadas anteriormente son la falta de un algoritmo de cuantificación adaptativo adecuado, la falta de fotogramas B, la falta de transformadas de 8×8 y filtros en bucle no adaptativos. Desde este punto de vista, predigo que VP8 debería ser comparable al perfil básico de VC-1 o H.264, en lugar de H.264. Por supuesto, VP8 es mucho mejor que Theora y superó fácilmente a Dirac en mis pruebas.
Si tan solo Google pudiera abrir la licencia para mejorar el formato de flujo de código, esto va en contra del hecho de que tantas empresas han anunciado soporte para VP8. Cuanto más software admita un formato de archivo, más difícil será cambiarlo, por lo que soy escéptico ante cualquier afirmación de que pasaremos otros 6 a 12 meses arreglando VP8. En resumen, el lanzamiento de VP8 es demasiado pronto: un arreglo razonable debería ser tener primero una fase de prueba, durante la cual se revisará la versión beta y, cuando esté completa, se lanzará oficialmente.
Actualización: Parece que Google está abierto a cualquier posibilidad de modificar el estándar: esto obviamente significa que el estándar es la versión final, un producto terminado lleno de varias lagunas.
No estoy muy seguro desde la perspectiva de la velocidad de decodificación. La implementación actual parece ser aproximadamente un 16% más lenta que el decodificador H.264 de ffmpeg (lo que significa que puede ser más lento que los decodificadores más avanzados como, por ejemplo). CoreAVC 25-35% más lento). Por supuesto, esto no es una prueba concluyente de qué tan rápida es una implementación completamente optimizada, pero la implementación parece muy bien optimizada y tiene código ensamblador SIMD para casi todas las funciones principales de procesamiento de señales digitales, por lo que realmente dudo que aún pueda mejorar mucho. .
Se puede esperar que bajo el mismo grado de optimización, VP8 y H.264 tengan aproximadamente la misma velocidad de decodificación. Esto realmente no es una ventaja para VP8: H.264 ya tiene mucho soporte de hardware, pero VP8 depende básicamente de la decodificación de software, por lo que esta "aproximadamente la misma velocidad" no es suficiente en muchos casos. En comparación, Theora es casi un 35% más rápido que el decodificador H.264 de ffmpeg.
Finalmente, la cuestión de las patentes parece que volverá a convertirse en un dolor de cabeza. VP8 se parece demasiado a H.264: una descripción brillante pero algo inexacta de VP8 es "la base de H.264 más un mejor algoritmo de codificación de entropía". Si bien no soy abogado, naturalmente no puedo imaginar que se salgan con la suya, especialmente en el entorno actual que favorece los litigios sobre patentes. Incluso VC-1, que tiene estándares más diferentes que VP8 y H.264, no puede escapar de la nube de patentes de software.
Sería extremadamente cauteloso hasta que tengamos pruebas concluyentes de que VP8 es (patentado) seguro. Dado que Google no ha brindado a los usuarios de VP8 ninguna protección contra litigios de patentes y los correspondientes mecanismos de compensación, esto será un peligro oculto más grave. Lo más importante es que Google no ha publicado ninguna razón legítima por la que partes de VP8 no infrinjan otras patentes, como lo hizo Sun con su estándar OMS: dicha información realmente puede reducir las preocupaciones de los usuarios y ser más explícitos sobre su posición.
Pero en cualquier caso, si Google tiene la suerte de evitar todos los posibles desafíos de patentes para VP8, VP8 será sin duda una mejora importante en comparación con Theora.
Suplemento A: Codificador y decodificador VP8 de On2
Aunque este artículo se centra en discutir cuestiones relacionadas con el formato de vídeo VP8, desde la perspectiva del uso real, las reescrituras y mejoras del software, y para Para aquellos que están listos para probar VP8, la calidad del codificador y decodificador VP8 lanzado oficialmente (desde la perspectiva del código, la tasa de compresión y la velocidad) es mejor que los que mencioné anteriormente. Entonces, después de leer la mayor parte del código de VP8, aquí están mis pensamientos sobre el software.
Inicialmente iba a dejar que On2 continuara con este punto, pensé que el codificador era técnicamente nuevo para VP8, por lo que probablemente no necesitaban hacerlo de una calidad particularmente alta ni mejorarlo.
Sin embargo, cuando comencé a leer este programador, todas estas buenas intenciones se vinieron abajo: había notas que indicaban que ciertas correcciones de errores se remontaban a principios de 2004. Bueno, ¡este codificador es incluso más antiguo que x264! Supongo que el software VP8 actual simplemente es una evolución del software VP7 original. De todos modos, esto significa que no puedo perdonar a On2. Tienen al menos 6 años para desarrollar VP8 y han invertido un equipo de I+D mucho mayor que x264.
Antes de analizar el codificador, es importante tener en cuenta que el software estándar de VP8 no es terrible. De hecho, desde una perspectiva de compresión, no creo que se pueda avanzar más con el enfoque estándar. Supongo que su codificador, bajo los parámetros más lentos, puede alcanzar una desviación PSNR máxima del 5% al 10% que pueden obtener. Obviamente, si usa un algoritmo extraño como MB-tree, todavía hay mucho margen de mejora, sin mencionar que no tiene ninguna optimización psicológica visual. Pero este codificador estándar hace su trabajo a conciencia. Esto contrasta marcadamente con el codificador estándar de VP3, que es como un basurero (pregúntele a cualquier desarrollador de Theora).
Antes de entrar en detalles técnicos específicos (ds, dices muchas tonterías), déjame hacer algunos comentarios sobre la calidad del código. Aunque hay toneladas de errores administrativos en los comentarios, la calidad del código de este software es mucho mejor que la de VP3. También parecen estar empezando a implementar sistemas de control de versiones mediante comentarios, lo cual es realmente extraño. El código ensamblador es mucho peor, con una increíble cantidad de programación de copiar y pegar, algunas instrucciones completamente inútiles que no hacen nada, operaciones de carga/almacenamiento no alineadas que deberían estar alineadas con estructuras de datos y algo de código que simplemente no puedes entender de todos modos. Función escrita de forma engorrosa y más lenta. Si el código C todavía es una mezcla, la calidad de escritura del ensamblaje es claramente pan comido.
ME: Búsqueda de diamantes, hexadecimales y de rango completo. Todos los métodos son muy sencillos de implementar: por ejemplo, la búsqueda hexagonal tiene una cantidad inimaginable de código redundante (casi la mitad de las posiciones de búsqueda se repiten). La búsqueda de rango completo es incluso peor en términos de eficiencia, pero considerando que es inútil excepto en configuraciones de codificación extremadamente lentas, no me quejaré.
ME subpíxel con precisión decimal: algoritmo iterativo de búsqueda de diamantes y cuadrados simple y claro. Nada de particular interés aquí.
Cuantización: La parte de cuantización contiene principalmente dos modos, un modo rápido y un modo ligeramente más lento. El primero es básicamente equivalente a la cuantificación de la zona muerta en x264, y el segundo agrega un peso de sesgo basado en 0 ejecuciones al primero. (No estoy seguro de lo útil que sea, pero me gusta). Después de esto, realizaron dos tipos de "optimización de coeficientes". El primero simplemente intenta mover cada coeficiente distinto de cero hacia cero; un modo más lento intenta todas las ***2^16 combinaciones posibles de redondeo de coeficientes DCT. Quien haya escrito esto necesita leer sobre qué es la cuantificación trellis (la solución de programación dinámica para este problema) y nunca escribir este algoritmo de complejidad de tiempo exponencial en el codificador.
RC (procesamiento de tipo de marco): para mejorar (aumentar) la calidad, VP8 introdujo "marcos dorados" y "marcos altref": estos son dos conceptos sobre los que tengo grandes dudas, porque esto significa As Como resultado, el vídeo puede saltar periódicamente a un nivel de calidad más alto, lo cual es muy malo en la práctica. También puede ver el impacto de este concepto en el gráfico de PSNR (consulte el enlace original): aproximadamente cada 12 cuadros, la calidad aumentará. Es poco probable que la combinación de este tipo de fluctuación en un vídeo visto continuamente dé lugar a una buena evaluación subjetiva de la calidad.
RC (Introducción general): el control de la tasa de código se basa completamente en un algoritmo de retroalimentación. En algunas situaciones con tasas de código constantes estrictas y restricciones estrictas del búfer, es posible que este algoritmo no logre un buen rendimiento. Además, el algoritmo RC intracuadro no tiene ningún mecanismo adaptativo para el cuantificador (como cómo RC lo controla cuando el cuadro actual excede el límite de capacidad).
En cambio, RC se basa en codificar repetidamente un cuadro para que alcance el tamaño objetivo, lo que hace que este método de control sea inútil en casos de uso práctico. Hay dos razones. En situaciones de baja latencia, es decir, cuando la plataforma no puede tolerar grandes retrasos, repetir la codificación varias veces puede hacer que los fotogramas recibidos por el codificador no estén sincronizados en el tiempo. En cualquier otra situación, siempre que la plataforma pueda aceptar el uso de subprocesos múltiples basados en cuadros (el retraso que conlleva), este algoritmo de codificación de subprocesos múltiples, que es mucho más rápido que el subproceso múltiple tradicional basado en cortes, hará la codificación repetida es imposible de lograr.
Filtro en bucle: la selección de parámetros del filtro en bucle del codificador se optimiza en función de maximizar PSNR. No estoy seguro de si esta idea es buena, pero estoy seguro de que cualquiera que intente optimizar H.264 de esta manera terminará produciendo resultados con una calidad subjetiva particularmente pobre (a menudo, un efecto muy borroso).
Rendimiento general: incluso con el subproceso múltiple activado y usando la configuración más rápida, su codificador era lento. En mi plataforma 1.6G Core i7, su velocidad de codificación de 1080p es de alrededor de 26 fps, lo que ni siquiera es lo suficientemente rápido para la compresión en tiempo real. En comparación, x264 logró 101 fps utilizando su ajuste preestablecido "ultrarápido" más rápido. Básicamente puedo decir con certeza que el codificador VP8 de On2 no será más rápido que x264 en ningún sentido, pero la incapacidad de generar medios de transmisión HD en una plataforma moderna de cuatro núcleos es realmente incomprensible en 2010. Además, las opciones de velocidad en el codificador son extremadamente confusas y poco intuitivas y nunca parecen funcionar correctamente, por ejemplo, el modo de codificación rápida (-rt) parece ignorarse por completo en 2 pasadas;
Rendimiento general de compresión: similar a lo mencionado anteriormente, desde la perspectiva de la relación de compresión, este codificador hace un trabajo realmente bueno dentro del rango estándar dado. La configuración del algoritmo más lento en el codificador claramente no está optimizada en absoluto (especialmente mire los comentarios que dejaron en las secciones de búsqueda de movimiento y cuantificación), pero al menos todavía funcionan.