Charla: Codificación de vídeo de alta eficiencia

This article is written in American English, which has its own spelling conventions (color, defense, traveled) and some terms that are used in it may be different or absent from other varieties of English. According to the relevant style guide, this should not be changed without broad consensus.

This article is rated B-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computer science Low‑importance This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer scienceWikipedia:WikiProject Computer scienceTemplate:WikiProject Computer scienceComputer science articles Low This article has been rated as Low-importance on the project's importance scale. Things you can help WikiProject Computer science with: Here are some tasks awaiting attention: Article requests : Requested articles/Applied arts and sciences/Computer science, computing, and Internet Cleanup : Computer science articles needing attention Computer science articles needing expert attention Copyedit : Computing Expand : Computer science Infobox : Computer science articles without infoboxes Maintain : Timeline of computing 2020–present Photo : Find pictures for the biographies of computer scientists (see List of computer scientists) Computing articles needing images Stubs : Computer science stubs Unreferenced : WikiProject Computer science/Unreferenced BLPs Project-related : Tag all relevant articles in Category:Computer science and sub-categories with {{WikiProject Computer science}} Computing: Software Low‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles Low This article has been rated as Low-importance on the project's importance scale. This article is supported by WikiProject Software (assessed as Low-importance). This article is supported by Computer hardware task force (assessed as Low-importance). Electronics Low‑importance This article is part of WikiProject Electronics, an attempt to provide a standard approach to writing articles about electronics on Wikipedia. If you would like to participate, you can choose to edit the article attached to this page, or visit the project page, where you can join the project and see a list of open tasks. Leave messages at the project talk pageElectronicsWikipedia:WikiProject ElectronicsTemplate:WikiProject Electronicselectronic articles Low This article has been rated as Low-importance on the project's importance scale. Media Low‑importance This article is within the scope of WikiProject Media, a collaborative effort to improve the coverage of Media on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.MediaWikipedia:WikiProject MediaTemplate:WikiProject MediaMedia articles Low This article has been rated as Low-importance on the project's importance scale. WikiProject Media To-do List: Here are some tasks awaiting attention: Article requests : Mackay Radio Cleanup : Media influence, Video game culture, Sound bite NPOV : Content (media and publishing) Verify : Multimedia, Alternative media, Alternative newspaper Other : Answer requests for comments Television Low‑importance This article is within the scope of WikiProject Television, a collaborative effort to develop and improve Wikipedia articles about television programs. If you would like to participate, please visit the project page where you can join the discussion. To improve this article, please refer to the style guidelines for the type of work.TelevisionWikipedia:WikiProject TelevisionTemplate:WikiProject Televisiontelevision articles Low This article has been rated as Low-importance on the project's importance scale. Computer graphics Mid‑importance This article is within the scope of WikiProject Computer graphics, a collaborative effort to improve the coverage of computer graphics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Computer graphicsWikipedia:WikiProject Computer graphicsTemplate:WikiProject Computer graphicscomputer graphics articles Mid This article has been rated as Mid-importance on the project's importance scale.

Hay que ponerlo un poco en orden. Debería actualizarse una vez que se completen el informe de la reunión JCT-VC y los informes de pruebas subjetivas. Iainerichardson (discusión) 17:39 3 may 2010 (UTC) [ responder ]

La sección de Características necesita ser actualizada, sin embargo, hay demasiada información técnica y demasiadas propuestas para hacer un breve resumen. Se necesita alguien con un buen conocimiento de la tecnología de codificación de video. Bien podríamos esperar a un resumen de las propuestas en la reunión de julio de 2010 para actualizar la sección. -- Dmitry _{( discusión • contibs )} 06:47 14 jun 2010 (UTC) [ responder ]

Parece que la gente hablaba de limpiar este artículo hace casi 4 años. He añadido algunas etiquetas para ayudar a fomentar la limpieza del artículo. TekBoi [Ali Kilinc] ( discusión ) 23:13 21 feb 2014 (UTC) [ responder ]

El artículo ha cambiado mucho en los últimos 4 años. La cantidad de títulos de sección no viola ninguna política de Wikipedia y es menor que la de muchos de los artículos destacados que he leído, el tamaño de la prosa del artículo está por debajo del punto en el que se recomienda dividirlo y no veo cómo el artículo tiene un problema con las citas cuando solo tiene unas pocas citas breves. -- GrandDrake ( discusión ) 17:33 22 feb 2014 (UTC) [ responder ]

Agregué más texto descriptivo sobre cada una de las herramientas de codificación y eliminé la nota de actualización. Pieter3d (discusión) 07:54 8 jul 2012 (UTC) [ responder ]

El artículo se trasladó recientemente sin discusión y tuvo que ser trasladado nuevamente con un traslado solicitado. Me gustaría mencionar que "Codificación de video de alta eficiencia" es precisa y se utiliza en el sitio web del Equipo de colaboración conjunta sobre codificación de video, la organización que está desarrollando HEVC, y se utiliza en el borrador de especificación de HEVC. -- GrandDrake ( discusión ) 00:55, 13 de noviembre de 2012 (UTC) [ responder ]

Si es el mejor de todos Mhiz angel (discusión) 13:00 7 septiembre 2019 (UTC) [ responder ]

La preocupación que tengo con tener muchos ejemplos en el cuadro de niveles es que perjudica la legibilidad del cuadro. Si crees que esos ejemplos son necesarios en Wikipedia, ¿qué opinas sobre la idea de tenerlos en un artículo sobre niveles HEVC? -- GrandDrake ( discusión ) 06:47 27 nov 2012 (UTC) [ responder ]

• Si eliminas resoluciones de la tabla de niveles, sincronízala con la tabla correspondiente de H.264/AVC . Tampoco entiendo su elección de resoluciones (y antes también era mucho más sencilla), por lo que no puedo opinar sobre la inclusión de resoluciones muy similares, pero creo firmemente que estas tablas deberían sincronizarse entre sí en los dos artículos, de modo que se puedan hacer comparaciones directas con facilidad. -- Dmitry _{( discusión • contibs )} 19:44, 27 de noviembre de 2012 (UTC) [ responder ]

Se creó el artículo Niveles y niveles de codificación de video de alta eficiencia que tiene un cuadro con la mayoría de las resoluciones de nivel máximo para H.264/MPEG-4 AVC, incluidas resoluciones como 1280×1024, 3672×1536 y 4096×2304. -- GrandDrake ( discusión ) 03:01 28 nov 2012 (UTC) [ responder ]

Dado que la UIT anunció en un comunicado de prensa que utilizará H.265 para HEVC, propongo que el artículo se traslade a H.265/HEVC. -- GrandDrake ( discusión ) 00:35 28 ene 2013 (UTC) [ responder ]

En realidad, en ese comunicado de prensa se hace referencia principalmente al estándar como HEVC en lugar de H.265. Solo dice que ITU-T H.265 es una de las dos formas en que se identifica formalmente al estándar, pero sigue utilizando el nombre HEVC en el resto del comunicado de prensa. — Mulligatawny ( discusión ) 18:49 29 enero 2013 (UTC) [ responder ]

Estoy de acuerdo. Incluso si la nomenclatura final de la UIT es H.265, el nombre actual ya ha alcanzado una notoriedad considerable. "Codificación de vídeo de alta eficiencia" es el nombre más común, que refleja bastante bien el contenido del artículo y es mucho más amigable para el usuario medio (de hecho, preferiría cambiar el nombre de H.264/MPEG-4 AVC a Codificación de vídeo avanzada por la misma razón). Y si cambiamos el nombre a "H.265/HEVC", seguramente aparecerá algún quisquilloso y lo cambiará a "H.264/MPEG-H Parte 2 HEVC", etc. -- Dmitry _{( discusión • contibs )} 16:26 2 feb 2013 (UTC) [ responder ]

Estoy de acuerdo en que algunos de los artículos sobre estándares de vídeo de Wikipedia no siguen los títulos de los artículos de Wikipedia, como por ejemplo H.262/MPEG-2 Parte 2. Me opondría firmemente a cualquier título de artículo propuesto para HEVC que incluya "Parte 2", ya que sería confuso para el lector medio y demasiado preciso. Supongo que tendría sentido esperar y ver si HEVC seguirá siendo el nombre más común antes de considerar cualquier cambio en el título del artículo. -- GrandDrake ( discusión ) 06:46 8 feb 2013 (UTC) [ responder ]

IBDI se incluye como herramienta de codificación. Sin embargo, no existe ninguna herramienta de codificación IBDI en el FDIS. IBDI se puede realizar con cualquier formato de vídeo rellenando con ceros LSB antes de la codificación y truncando/redondeando/tramado después de la decodificación. Como tal, es una función del codificador y no una herramienta de codificación del formato de vídeo. IBDI solo es posible si la profundidad de bits máxima permitida del formato de vídeo es mayor que la profundidad de bits de entrada. Si el vídeo de entrada es de 8 bits, cualquier formato que permita profundidades de bits mayores que 8 bits puede realizar IBDI. Pero en sentido amplio, cualquier formato de vídeo con más de 2 bits de profundidad de bits puede realizar IBDI para una entrada de 1 bit, por lo que se puede clasificar como que realiza IBDI. Sin embargo, en la práctica, creo que la definición de "más de 8 bits" (sentido estricto) es más útil. Por ejemplo, H.264/AVC también puede utilizar una profundidad de bits superior a 10 bits, pero rara vez se hace referencia a él como IBDI (consulte, por ejemplo, "información de salida de profundidad de 10 bits" en [1]). Desde mi punto de vista, IBDI debería eliminarse del artículo HEVC o añadirse al artículo H.264/AVC (y a cualquier artículo de un códec de vídeo con pérdida que admita profundidades de bits superiores a 8 bits), por razones de coherencia. Conquerist ( discusión ) 21:57, 27 de abril de 2013 (UTC) [ responder ]

Eso explica por qué no se menciona IBDI en el borrador de especificación HEVC ni en "Descripción general del estándar de codificación de video de alta eficiencia (HEVC)", que cubría las herramientas de codificación HEVC. Como IBDI no es una herramienta de codificación HEVC, eliminé esa sección del artículo y moví las referencias a la declaración en la sección Main 10 sobre la eficiencia de codificación mejorada cuando el video se codifica a una profundidad de bits más alta. -- GrandDrake ( discusión ) 02:43, 28 de abril de 2013 (UTC) [ responder ]

Se dice que HEVC mejora la calidad del video y duplica la relación de compresión de datos en comparación con H.264/MPEG-4 AVC.

No estoy seguro de que me guste la redacción de esto. "duplicar la relación de compresión de datos" implica (como se menciona más adelante) una medición con la misma calidad subjetiva (de lo contrario, simplemente "duplicar la relación de compresión de datos" no tiene sentido ya que puedes seleccionar la relación que quieras tanto en H.264 como en H.265). O bien puedes mejorar la calidad del video o puedes mantener la misma calidad y duplicar la relación de compresión. David ( discusión ) 11:41 8 ago 2013 (UTC) [ responder ]

Se modificó la declaración para que solo mencione la relación de compresión de datos. -- GrandDrake ( discusión ) 03:37 9 ago 2013 (UTC) [ responder ]

Lo que estamos tratando de decir es que se dice que HEVC tiene el doble de eficiencia de compresión que AVC. Esto significa que HEVC puede codificar video con la misma calidad visual subjetiva, utilizando solo la mitad de la tasa de bits. Alternativamente, una duplicación de la eficiencia de compresión puede proporcionar una calidad visual sustancialmente mayor con la misma tasa de bits que AVC. Tvaughan1 ( discusión ) 06:05, 23 de julio de 2015 (UTC) [ responder ]

Utilicé "bits por color" en el artículo, ya que el término era más común en los resultados de búsqueda de Google, pero el estándar HEVC sí dice "profundidad de bits de las muestras" y los documentos de las personas que están trabajando en HEVC, como "Descripción general del estándar de codificación de video de alta eficiencia (HEVC)", utilizan "bits por muestra". ¿Se debería cambiar "bits por color" por "bits por muestra"? -- GrandDrake ( discusión ) 22:55, 10 de agosto de 2013 (UTC) [ responder ]

No. "Bits por color" o "bpc" es más común y más apropiado para las secciones de descripción general.

Sin embargo, en las secciones técnicas, deberíamos referirnos al modelo de color YUV como en el texto del estándar, utilizando "muestra de luminancia/crominancia" y correspondientemente "bits por muestra de luminancia/crominancia", "bits por muestra", etc. en lugar de términos RGB como "color" o "bpc". -- Dmitry _{( discusión • contibs )} 06:40, 11 de agosto de 2013 (UTC) [ responder ]

Cambié el primer uso de "bits por color" a "bits por color/muestra" para que la gente sepa que son lo mismo, cambié "bits por color" a "bits por muestra" en las secciones técnicas y agregué una nota sobre la profundidad de bits de luminancia/cromía al cuadro de perfiles. -- GrandDrake ( discusión ) 21:21 11 ago 2013 (UTC) [ responder ]

Un " color " se representa típicamente como un conjunto de tres valores ("triestímulo") (o quizás más; por ejemplo, consulte tetracromacia y pentacromacia ). Cada uno de los tres valores representa la intensidad de un color primario en particular , como rojo, verde o azul, o la coordenada a lo largo de un eje en un sistema de representación de color transformado, como YCbCr . Consulte color y espacio de color , pero se necesitan tres valores para formar un color. He oído hablar de "bpc" como abreviatura de "bits por canal" o "bits por componente" antes, lo que tiene sentido, pero nunca había oído que se llamara "bits por color", lo que parece un concepto difícil (especialmente con el submuestreo de croma ). La profundidad de bits que se analiza en el artículo no es bits por color, sino bits por muestra o bits por canal o bits por componente o bits por componente de color, pero no bits por color. — Mulligatawny ( discusión ) 03:41, 12 de agosto de 2013 (UTC) [ responder ]

También me preocupaba esto, ya que las profundidades de bits suelen ser bits por color (media por componente de color primario). Pero en los estándares a los que se hace referencia, las profundidades de bits son para los componentes de luminancia y croma, no para los colores. Y, en general, estos se muestrean de forma diferente. Por lo tanto, bits por muestra, aunque es un término poco común en los sistemas de color, parece razonablemente adecuado en este caso. Mejor que bits por color, al menos. Dicklyon ( discusión ) 03:51 12 ago 2013 (UTC) [ responder ]

Hola,

Envié un comunicado de prensa sobre el decodificador HEVC en ARM en la página HEVC en implementaciones y productos, pero parece que lo eliminaron. ¿Podrían informarme? ¿Debería enviarlo para su revisión? — Comentario anterior sin firmar agregado por 203.201.61.238 ( discusión ) 07:25, 8 de julio de 2014 (UTC) [ responder ]

Se trasladó al artículo Implementaciones y productos de codificación de video de alta eficiencia . En este artículo solo se conservan los anuncios más destacados y ya existen varios decodificadores HEVC de software para ARM. -- GrandDrake ( discusión ) 02:52, 12 de julio de 2014 (UTC) [ responder ]

Agradecería una buena información sobre licencias, bloqueos de marcas y patentes, legalidad del código abierto y otras cuestiones que hacen que la vida de los implementadores y usuarios del código abierto sea miserable. Veo que hay un código abierto publicado, pero no sé sobre sus problemas legales o restricciones de uso. Tal vez alguien tenga ganas de investigar. -- grin ✎ 15:11, 13 de marzo de 2015 (UTC) [ responder ]

Según lo que leí en este artículo y otros relacionados con los códigos de video, necesita una licencia solo para uso comercial, por ejemplo, algunos servicios de transmisión de video como Amazon, etc., deben pagar un pequeño cargo de sus ingresos (0,5%). Los dispositivos integrados como Blue-ray o cualquier hardware de codificación/decodificación de video necesitan licencia para usar esta tecnología.

Los usuarios finales no necesitan pagar nada, ya que este códec se integrará con el software/hardware que utilizan. -- Salem F ( discusión ) 11:39 4 nov 2015 (UTC) [ responder ]

Obviamente no me refiero a lo que ya está en el artículo, y por supuesto no hay evidencia anecdótica. :-) Probablemente no veas el significado de la pregunta ya que "será incorporado" no ayuda, por ejemplo, a los programadores de código abierto a saber quién los demandará la próxima semana y por qué. Un antecedente detallado mencionaría las fuentes de quién es el licenciante, sobre qué base, qué está permitido y qué no, etc. -- grin ✎ 13:09, 17 de febrero de 2016 (UTC) [ responder ]

Mi opinión:

El problema con los formatos que pagan regalías es, en primer lugar, que poner un precio a una copia de software es perjudicial para los ecosistemas de software sin costo, ya que hace que ese software sea inviable o ilegal. Nótese que no importa cuán abierta/libre sea la implementación; si implementa un formato patentado, los propietarios de la patente pueden exigir lo que sea. La exigencia puede ser un precio por copia, como en este caso, que es razonable y soportable para un producto que se vende por dinero... Pero no tanto en otros casos: fue un factor decisivo para el soporte de Firefox para H.264 en plataformas sin este soporte, hasta que Cisco gentilmente ofreció pagar sus costos de licencia (ver OpenH264 ). La mayoría de las distribuciones de Linux se entregan sin soporte listo para usar para H.264, AAC, incluso MP3, y en su lugar requieren que el usuario habilite explícitamente un repositorio "restringido" para eso, descrito como "puede ser ilegal en algunos países".

En segundo lugar, se trata de una guerra de formatos , una lucha de dependencia colectiva que tiende a un encierro colectivo a escala global, lo que significa un fin eventual de la elección individual. Por lo tanto, se podría esperar estandarizar algo que todos pudieran adoptar eventualmente (es decir, sin problemas evidentes de interoperabilidad), pero estamos considerando algo que parece incompatible con el ecosistema de software libre/abierto tal como lo conocemos. — 84.214.220.135 ( discusión ) 22:50, 13 de septiembre de 2016 (UTC) [ responder ]

Cita de los desarrolladores de x265[2]: La decodificación y codificación de software en dispositivos de consumo debe estar libre de regalías — 84.214.220.135 ( discusión ) 23:33 13 septiembre 2016 (UTC) [ responder ]

Hola a todos, corríjanme si me equivoco, pero debería incluirse la siguiente declaración: (compatible con mayores profundidades de bits y formatos de submuestreo de croma 4:0:0, 4:2:2 y 4:4:4)

Lectura real: (compatible con mayores profundidades de bits y formatos de submuestreo de croma 4:2:0, 4:2:2 y 4:4:4)

Pm 1982 (discusión) 01:30 20 abr 2015 (UTC) [ responder ]

No, eso no es correcto. Lo que se agregó fue soporte para monocromo (4:0:0), no 4:2:0, que ya era compatible en la primera versión. Además, parece un poco extraño referirse a 4:4:4 como un formato de submuestreo de croma, ya que el formato 4:4:4 no submuestrea el croma. El estándar utiliza el término "formato de croma" o "formato de muestreo de croma", no "formato de submuestreo de croma". Editaré la declaración para mejorar su claridad. Mulligatawny ( discusión ) 18:12 20 abr 2015 (UTC) [ responder ]

• Existen varios algoritmos para la compresión de datos , especialmente para la compresión de datos con pérdida de datos de vídeo/audio.
• Existen varias implementaciones de esto, ya sea en software o como algún ASIC; en el caso del software, este software puede compilarse y el binario compilado puede ejecutarse en varias CPU, o GPU, o DSP, ...
• Hay varios formatos de archivos
• Existen varias normas (por ejemplo, ISO 216 )
• Y luego hay una enorme colección de palabras de moda como, por ejemplo, "estándar de compresión de vídeo", "formato de codificación de vídeo", "contenedor de vídeo", etc. ¿Por qué? Usuario:ScotXW ^t@lk 13:15, 15 de mayo de 2015 (UTC) [ responder ]

El hecho de que HEVC pueda considerarse un algoritmo entra en el tema de las patentes de software, que se trata en varios otros artículos de Wikipedia. En cuanto a "contenedor de video", no pude encontrarlo en el artículo, pero la razón por la que hay una sección sobre contenedores es porque HEVC se puede almacenar en diferentes contenedores, algunos de los cuales son m2ts, mp4 y mkv. -- GrandDrake ( discusión ) 02:15, 27 de mayo de 2015 (UTC) [ responder ]

Si hay un ejemplo más maravilloso de lo que puede salir mal en un artículo de Wiki moderno, no lo encuentro (bueno, tal vez el H.264/MPEG-4 AVC, que es igualmente terrible). Está lleno de jerga que se puede explicar fácilmente, está terriblemente desorganizado y es terriblemente difícil de editar debido al uso excesivo de citas en línea. Así que, de ahora en adelante, intentaré darle forma al texto poco a poco. Para empezar:

• El lede debe ser una descripción general clara y concisa del tema. El lector debe poder detenerse al final del lede y comprender los conceptos básicos del cuerpo. Los lede no deben introducir términos o temas que no estén cubiertos en el cuerpo (es una descripción general del cuerpo). Por eso, existe una regla especial que establece que normalmente no es necesario citar el lede. Este lede consistía en una enorme cantidad de jerga e historia que no ayuda al lector a comprender el tema, en realidad no resumía el sistema y no mencionaba en absoluto los problemas con las licencias. Si no le gusta el lede tal como lo he modificado, MEJÓRELO, no lo devuelva al estado horrible en el que estaba. No necesitamos tener una descripción completa de cada grupo involucrado, cada detalle de los lanzamientos y cada acrónimo en el artículo, ¡déjelo en el cuerpo!

• Las citas son necesarias siempre que alguien pueda cuestionar una afirmación o cuando la cita proporcione una descripción general singular del tema al que el usuario podría querer hacer referencia. Este no es el caso de este artículo, donde las citas se apilan sobre citas que ya cubren las afirmaciones que se citan. Muchas de ellas parecen ser relleno, agregadas simplemente para que el artículo parezca más sólido. Además, el artículo está literalmente lleno de la misma cita que se usa una y otra vez en el mismo párrafo, lo cual es completamente innecesario. He comenzado el proceso de mover citas de uso múltiple a una bibliografía y eliminar sitios de uso único en afirmaciones que ya están cubiertas. También he eliminado algunos de los muchos, muchos ejemplos en los que la misma cita se usa varias veces en el mismo párrafo sin ninguna razón obvia, aunque la cantidad de trabajo aquí es enorme.

• Las referencias en línea, es decir, las citas colocadas en el cuerpo del artículo con las etiquetas <ref></ref>, deben evitarse a toda costa. Hacen que el texto de edición sea muy difícil de leer y, especialmente, de editar. Nuestro objetivo debe ser producir el mismo artículo y, al mismo tiempo, hacer que sea lo más fácil posible para los futuros editores agregar material. Por lo tanto, si va a agregar una cita, verifique que no esté ya incluida en una de las que ya tenemos. Y si va a usar esa cita más de una vez, coloque la etiqueta de cita al final y use SFN para hacer referencia a ella. Esto puede hacer que el texto de edición sea mucho más fácil de mantener.

Gracias por leer mi perorata. Ahora vuelvo a tus habituales guerras de edición. Maury Markowitz ( discusión ) 16:01 2 ene 2016 (UTC) [ responder ]

El encabezado debe contener las redirecciones a este artículo, que incluyen MPEG-H Parte 2 (nombre interno utilizado por la ISO/IEC), H.265 (nombre interno utilizado por la ITU) y JCT-VC (el equipo conjunto que desarrolla HEVC). Por eso esos términos estaban en el primer párrafo. -- GrandDrake ( discusión ) 05:29 4 ene 2016 (UTC) [ responder ]

Eso no es algo que haya visto antes; por el contrario, está bien establecido que los enlaces internos pueden apuntar a subsecciones específicas. Pero si te sientes tan convencido de esto, está bien, pero al menos déjame reorganizarlo para que no sea un galimatías total; estos términos no ayudan al lector a entender el tema y ESE es el propósito principal del encabezado. Maury Markowitz ( discusión ) 17:07 4 ene 2016 (UTC) [ responder ]

Maury Markowitz , estoy de acuerdo en que ayudar al lector a comprender el tema es el objetivo principal del artículo principal. Sin embargo, mencionar las redirecciones entrantes es obligatorio según la directriz WP:R#ASTONISH . Redireccionar los enlaces entrantes a subsecciones específicas ayuda con las cosas asociadas con HEVC, pero no con un sinónimo de HEVC. Así que hice eso para JCT-VC. Pero redireccionar a subsecciones no parece posible para los sinónimos populares de HEVC en su conjunto. -- DavidCary ( discusión ) 19:43, 27 de diciembre de 2021 (UTC) [ responder ]

@ DavidCary : Vaya, ¡registro de respuestas de Necrothread! Maury Markowitz ( discusión ) 20:04 27 dic 2021 (UTC) [ responder ]

Acabo de codificar una película con freno de mano usando x265 y me decepcionó no ver un factor de 2 en la mejora de la eficiencia sobre x264 con la configuración estándar. Después de leer http://www.compression.ru/video/codec_comparison/hevc_2015/MSU_HEVC_comparison_2015_free.pdf entiendo que ves esos números del 50% solo en comparación con codificadores h264 bastante antiguos y no optimizados (e implementaciones de referencia). Las versiones actualizadas o 2015 x265 vs x264 (ambos dos de los mejores codificadores disponibles) dan una mejora del 20-25%. http://www.compression.ru/video/codec_comparison/hevc_2015/MSU_HEVC_comparison_2015_free.pdf

Entonces tal vez se debería mencionar (adicionalmente) los valores más realistas - o esperar hasta que 265 esté aún más optimizado :). — Comentario anterior sin firmar agregado por 134.3.100.150 (discusión) 10:56, 14 de mayo de 2016 (UTC) [ responder ]

Numerosos estudios han demostrado un beneficio en la eficiencia de compresión de aproximadamente el 50%, incluido un estudio realizado recientemente por Netflix. Los estudios académicos generalmente comparan el codificador de referencia HEVC HM con el codificador de referencia AVC JM. Los estudios prácticos a menudo comparan x264 con x265. La ganancia en la eficiencia de compresión se mide típicamente con resoluciones de 1080P o superiores (la ganancia es menor para tamaños de imagen más pequeños), a velocidades de bits típicas de consumo. El porcentaje de ganancia en la eficiencia es menor a velocidades de bits altas (si le das a cualquier códec suficientes bits, la calidad se acerca a la compresión sin pérdida). Por cierto, fundé y dirijo el proyecto x265. Tvaughan1 ( discusión ) 18:58, 26 de mayo de 2017 (UTC) [ responder ]

Hola compañeros wikipedistas,

Acabo de modificar 2 enlaces externos en High Efficiency Video Coding . Tómese un momento para revisar mi edición . Si tiene alguna pregunta o necesita que el bot ignore los enlaces o la página en su totalidad, visite esta sencilla sección de preguntas frecuentes para obtener información adicional. Hice los siguientes cambios:

• Se agregó el archivo https://web.archive.org/web/20141101215501/http://www.ittiam.com/News/en/press-releases/2014/158-Ittiam-Systems-announces-availability-of-its-third-generation-H265HEVC-codec-with-422-12-bit-support.aspx a http://www.ittiam.com/News/en/press-releases/2014/158-Ittiam-Systems-announces-availability-of-its-third-generation-H265HEVC-codec-with-422-12-bit-support.aspx
• Se agregó el archivo https://web.archive.org/web/20131020023304/http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/ a http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/

Cuando haya terminado de revisar mis cambios, puede seguir las instrucciones de la plantilla a continuación para solucionar cualquier problema con las URL.

Este mensaje fue publicado antes de febrero de 2018. Después de febrero de 2018 , las secciones de la página de discusión "Enlaces externos modificados" ya no son generadas ni monitoreadas por InternetArchiveBot . No se requiere ninguna acción especial con respecto a estos avisos de la página de discusión, aparte de la verificación regular usando las instrucciones de la herramienta de archivo que se encuentran a continuación. Los editores tienen permiso para eliminar estas secciones de la página de discusión "Enlaces externos modificados" si desean despejar las páginas de discusión, pero consulte la RfC antes de realizar eliminaciones sistemáticas masivas. Este mensaje se actualiza dinámicamente a través de la plantilla (última actualización: 5 de junio de 2024) .{{source check}}

• Si ha descubierto URL que el bot consideró erróneamente como muertas, puede informarlas con esta herramienta.
• Si encuentra un error con algún archivo o con las URL en sí, puede solucionarlo con esta herramienta.

Saludos.— InternetArchiveBot ( Reportar error ) 15:24 3 nov 2017 (UTC) [ responder ]

¿Aporta algo realmente la sección de "Implementaciones y productos"? Si es así, está lejos de ser completa, ya que básicamente todos los teléfonos móviles o reproductores multimedia son compatibles con HEVC. No tiene nada que ver con el códec en sí, solo con la adaptación industrial del mismo. ¿No se podría decir esto de forma más breve? — Comentario anterior sin firmar añadido por Jsvensso (discusión • contribuciones ) 14:23, 31 de diciembre de 2017 (UTC) [ responder ]

No parece necesario enumerar cada una de las tarjetas gráficas de Nvidia que admiten HEVC, especialmente porque todas tienen exactamente el mismo decodificador HEVC y pertenecen a la misma generación o a una generación posterior. 192.150.137.20 (discusión) 06:14 24 may 2019 (UTC) [ responder ]

Este artículo hace innumerables menciones a los mismos números que encontramos en todas partes sobre la eficiencia de compresión H.265 (50 % menor a 720p, 60 % a 1080p en comparación con H.264), pero dice sorprendentemente poco sobre el otro lado de la desventaja: el costo computacional de la decodificación . En ese aspecto, ¿cómo se compara con otros códecs? A excepción de algunos números absolutos sobre algún hardware de propósito especial, las únicas menciones que encontré en el artículo bastante largo fueron:

El uso efectivo de estas mejoras requiere mucha más capacidad de procesamiento de señales para comprimir el video, pero tiene menos impacto en la cantidad de cálculo necesario para la descompresión.
— en #Concept , no se da ninguna referencia.

Las pruebas mostraron que los tamaños grandes de CTU aumentan la eficiencia de codificación y al mismo tiempo reducen el tiempo de decodificación.[110]
— en #Eficiencia de codificación , la referencia dada es ^[1] .

HEVC fue diseñado para mejorar sustancialmente la eficiencia de codificación en comparación con H.264/MPEG-4 AVC HP […] a expensas de una mayor complejidad computacional.[16] […] Los codificadores HEVC pueden compensar la complejidad computacional, la tasa de compresión, la robustez a los errores y el tiempo de retardo de codificación.[16] Dos de las características clave en las que HEVC mejoró en comparación con H.264/MPEG-4 AVC fueron la compatibilidad con video de mayor resolución y métodos de procesamiento paralelo mejorados.[16]
— en #Características , la referencia dada es ^[2] .

Sólo se presentan tendencias generales, no cifras, ni órdenes de magnitud, ni comparación. Además, aunque estas frases pueden llevar al lector distraído a creer que el H.265 es más eficiente en la decodificación que sus predecesores, en realidad se trata de comparaciones internas (el costo de decodificación del H.265 con respecto a sus predecesores es menor que el costo de codificación del H.265 con respecto a sus predecesores; el H.265 con unidades de almacenamiento de gran tamaño tiene un tiempo de decodificación reducido con respecto al H.265 con unidades de almacenamiento de gran tamaño).

En un momento en que el consumo de energía es una preocupación urgente (más que el almacenamiento y el ancho de banda), esta falta de interés me sorprende.

Como no soy experto, una búsqueda rápida en Google me dio lo siguiente:

Debido a la importante potencia de procesamiento necesaria para decodificar cualquiera de estos dos nuevos códecs [H.265 y AV1], no es práctico esperar que los dispositivos los reproduzcan a menos que hayan sido diseñados específicamente para admitir la decodificación por hardware.
— HEVC (H.265): ¿Qué es y por qué debería importarle? 2018-09-24

HEVC/H.265 tiene como contrapartida que requiere casi 10 veces más potencia de procesamiento [ Nota: no se dice si esto se aplica a la codificación, decodificación o ambas; pero más adelante en el mismo párrafo, el autor menciona la decodificación]. […] Aunque algunos programas como VideoLAN son capaces de decodificar este tipo de códec, la decodificación por software, aunque es más flexible, no es una opción ya que la decodificación por hardware suele ser más rápida y ahorra batería enormemente.
— H.264 vs H.265 — Una comparación técnica. ¿Cuándo dominará el mercado el H.265? 2016-06-09

Una mayor eficiencia suele tener un coste: la complejidad. El formato H.265 es mucho más difícil de codificar debido a su complejidad y puede requerir hasta diez veces más potencia de procesamiento para codificar a la misma velocidad que el H.264. […] La decodificación es un problema menor, pero la carga se duplica aproximadamente en comparación con el H.264. […]

Cualquier computadora puede decodificar H.265 mediante software (al menos en teoría). […] Sin embargo, la decodificación por software no es la mejor opción, porque no es demasiado eficiente.[…]
— Todo lo que necesitas saber sobre h.265/HEVC en tu PC 2015-02-04

Parece que la decodificación H.265 es más costosa y requiere una actualización de hardware para convertirse en una opción sin desperdiciar demasiada energía y potencia informática. ¿Podría algún experto en la materia aportar su opinión sobre este tema?

Saludos, Maëlan 14:18, 22 de febrero de 2020 (UTC) [ responder ]

La descodificación es más costosa en comparación con las tecnologías anteriores, algo que ocurre con todos los códecs. Las mejoras de eficiencia se producen a costa de una mayor complejidad, y parte de esta complejidad está en el lado del descodificador. Por lo tanto, en ese sentido, HEVC no es tan especial. Sin embargo, a medida que los fabricantes de hardware incorporan hardware de descodificación dedicado a sus productos, el aumento de la complejidad de la descodificación se vuelve cada vez menos relevante, ya que el hardware para fines especiales es significativamente más eficiente que los enfoques basados ​​en software. Con la descodificación por hardware, el consumo de energía se reduce a niveles casi insignificantes, al menos en comparación con el software.

Han pasado casi siete años desde que se introdujo el sistema HEVC. En este momento, los decodificadores de hardware están lo suficientemente extendidos como para que, al ritmo al que la gente suele actualizar sus dispositivos, "tener que" comprar un dispositivo nuevo ya no sea un problema, a menos que el hardware tenga cinco años o más.

La falta de cifras de rendimiento reales y sólidas para la decodificación de software es lamentable, pero no tan sorprendente. Después de todo, para que un códec se use ampliamente, la decodificación de software debe convertirse en un nicho. Por lo tanto, no hay mucha longevidad comercial en escribir un decodificador de software y mostrar lo bien que funciona. Realmente no he prestado mucha atención a este espacio, pero el único punto de referencia que he encontrado es este de Ronald S. Bultje, quien trabajó en la creación de VP9 en Google y fundó una empresa de tecnología de video llamada Two Orioles. La publicación se centra en la decodificación de VP9, ​​pero incluye comparaciones con dos decodificadores de software HEVC de código abierto diferentes. Si bien esta es una publicación de blog y, por lo tanto, una fuente autopublicada, podría ser útil debido a la trayectoria del autor, aunque no tengo mucha experiencia en cómo se deben evaluar las fuentes autopublicadas (aunque sé que no son automáticamente inutilizables). También existe la posibilidad de sesgo que debe tenerse en cuenta, ya que el autor es uno de los creadores de un estándar de codificación de vídeo competitivo y de varios productos relacionados con él.

Otro factor que influye en la falta de puntos de referencia para la decodificación de software es probablemente que el software puede mejorar con las actualizaciones. Y no solo los decodificadores de software mejoran con el tiempo, sino que los codificadores también reciben mejoras y pueden ofrecer más calidad con menos bits. Por lo tanto, cuando se normaliza para la calidad de vídeo, la misma versión exacta de un decodificador de software funcionará mejor si se le proporciona un vídeo de la misma calidad generado por un codificador más eficiente. El método o la métrica de normalización de la calidad también afectarán la prueba; ¿utiliza PSNR, SSIM, VMAF o algún otro método para asegurarse de que los vídeos que alimenta a los codificadores que está probando tengan la misma calidad?

En cuanto a la falta de cifras concretas sobre la complejidad de la decodificación por software, puede resultar bastante difícil hacerlo, ya que hay muchas variables, los resultados pueden ser diferentes unos meses después de realizar las pruebas y todos los resultados serán casi inútiles cuando los decodificadores de hardware finalmente tomen el relevo. A la luz de todo eso, hacer una comparación de codificadores es más atractivo y probablemente sea más fácil encontrar financiación para ello.

En lo que respecta a las estimaciones, probablemente encontrará más fuentes si utiliza el término "complejidad de decodificación" en sus búsquedas. Una búsqueda rápida arrojó lo siguiente:

• Análisis de la complejidad del decodificador HEVC de próxima generación
• Rendimiento y complejidad de HEVC para video 4K
• Análisis de la complejidad y la implementación de HEVC

TL;DR : Las pruebas son difíciles y, dado que la esperanza es que la decodificación de software eventualmente se vuelva innecesaria, no hay muchos incentivos. -- Veikk0.ma 18:01, 22 de febrero de 2020 (UTC) [ responder ]

¡Buenos puntos! El costo de energía del ancho de banda y el espacio de almacenamiento ahorrado (un valor negativo) tenderá a cancelar el necesario para el procesamiento adicional. Pero acabo de notar que decía, en <ref name=HEVCTechnicolorJuly2012Overview>, "Los requisitos generales <sic> de HEVC son mejorar la eficiencia de compresión en un factor de al menos dos en comparación con el estándar de compresión H.264/AVC" y "El tiempo de codificación se incrementa solo en un 10% y el tiempo de decodificación en un 60% en su mejor perfil de codificación y estructura de codificación, en comparación con el modelo SW de referencia H.264/AVC [4]" (Mismo lugar). Noto cómo en la mente del autor, está implícito/supuesto que la "eficiencia" se trata principalmente (incluso esencialmente) del tamaño, no del costo de procesamiento. Lo menciono porque lo estabas buscando. Estoy de acuerdo con la parte no golpeada: "Con la decodificación de hardware, el uso de energía cae a niveles casi insignificantes, al menos cuando se compara con el software". Sin duda, el coste energético relativo de la decodificación basada en hardware es más importante que el de la basada en software. Si la preocupación de Maëlan es que el consumo de energía de mil millones de decodificadores de hardware puede alcanzar niveles significativos, digo que es una idea interesante, pero probablemente no, especialmente en comparación con el importante consumo de energía de los ASIC que realizan pruebas de trabajo para respaldar los registros distribuidos de criptomonedas . -- 50.201.195.170 ( discusión ) 10:55, 21 de enero de 2021 (UTC) [ responder ]

"Además, en el perfil Main 10, el vídeo de 8 bits se puede codificar con una profundidad de bits superior a 10 bits, lo que permite una eficiencia de codificación mejorada en comparación con el perfil Main". Cuatro fuentes respaldaron esta afirmación. Eliminé una y encontré una segunda (<ref name=HEVCTechnicolorJuly2012Overview>) que tampoco respalda la afirmación. No he comprobado las otras dos, pero tengo la sensación de que tampoco la respaldan y me pregunto si es verdad y me voy a desconectar pronto. La fuente de Ericsson es vaga.

De cualquier manera, la sección, especialmente el último párrafo de la sección (para el cual <ref name=HEVCApril2013M0166> es la referencia), parece tener muchos más detalles de los que son apropiados para una prueba cruda (PSNR), especialmente dado 114. -- 50.201.195.170 ( discusión ) 10:55, 21 de enero de 2021 (UTC) [ responder ]

Cierto; se confirmó que los otros dos no son compatibles. También es correcto " n -bit", pero " n -bits" debería ser " n bits"; se está arreglando (también se ajustará mejor a las fuentes) y se están ajustando los detalles.-- 50.201.195.170 ( discusión ) 10:44 6 feb 2021 (UTC) [ responder ]

Me gustaría ver en el mapa de artículos la adopción de la radiodifusión terrestre, cuando este códec sea el estándar. — Comentario anterior sin firmar añadido por 46.187.202.138 ( discusión ) 04:12, 18 de junio de 2020 (UTC) [ responder ]

𓅓𓅓تِاɬبِعُ اليك يصلك كل جديد يُالقنبِ💔𓅓𓅓

𓅓𓅓𓅓 ح͓֘ــٚـٚ҉ـ☬ـاڴ❉ـم͜ الم͜ـ☬ـج̀اࢦ ج٪ڪ☬ـ꙰ـنِجَ قا☬سُ҉مِ ُ꙰ـط꙰ـ☬ـۅٖٚ͜ꪆه ̗ڜtreatmentخ͜⃢ـ༅ـص͜ـ☬ـينِ𓅓𖤍☬🇾🇪⃢١⚚˼١⚚ 134.35.169.125 (discusión) 08:07 1 dic 2022 (UTC) [ responder ]

Nuestras descripciones de los perfiles de las versiones 2 y 3+ se convierten rápidamente en un muro de texto incomprensible, que consta de:

• 50% de nombres de perfil o una lista de dichos nombres
• Repetición del 45 % de lo que hace un perfil similar, por ejemplo, Main 12 tiene 400 y 420 al igual que Main 10.
• 5% de cosas nuevas, como por ejemplo lo que hace que Main 12 no sea Main 10: más cosas.

Esto no es útil. Tenemos que encontrar una manera de hacerlo menos repetitivo, pero que siga estando bien organizado. Como dos tablas, una para las características y otra para la compatibilidad obligatoria con versiones anteriores, tal vez. Artoria 2e5 🌉 09:49, 21 de noviembre de 2023 (UTC) [ responder ]