¿YouTube tartamudea, calienta su computadora portátil, pone en marcha a sus fanáticos o simplemente usa mucha CPU? Incluso si nunca te has dado cuenta, es casi seguro que YouTube en Chrome está usando más energía de la batería de la que necesita. Al igual que otros problemas de rendimiento de Chrome, probablemente sea peor en Mac.
Este es el resultado del cambio a Video HTML5 y peculiaridades con los códecs de video utilizados por YouTube en Chrome en comparación con otros navegadores. Tenga paciencia y le explicaremos por qué Google hizo que la reproducción de YouTube fuera tan ineficiente en primer lugar. Firefox también puede tener el mismo problema.
HTML5, H.264, VP8 y VP9
RELACIONADO: 10 cosas que aún no sabías que podía hacer tu navegador web
YouTube ahora ha abandonado en gran medida el complemento de video Flash para la reproducción de video HTML5. Pero la reproducción de video HTML5 no está estandarizada. Los navegadores pueden elegir qué códec de video desean utilizar y no existe un único códec que prefieran todos los navegadores.
Cuando YouTube usó Flash, usó el códec H.264 para reproducir videos. Los videos con este códec suelen tener la extensión de archivo .mp4 y, a menudo, se denominan videos MP4. Este es un estándar de facto para toda la industria que va más allá de los navegadores web.
Safari, Internet Explorer, Borde de Microsoft , Chrome y Firefox incluyen soporte para reproducir videos codificados en H.264, aunque Firefox se esforzó y evitó incluir esto durante el mayor tiempo posible.
Si bien Apple y Microsoft solo admiten H.264 para la reproducción de video en sus navegadores, Google también ha estado impulsando sus propios códecs. Google adquirió el códec VP8 y lo incorporó a Chrome, y Firefox siguió su ejemplo. Google ahora está impulsando el códec VP9 de próxima generación, que ahora también está integrado en Chrome y Firefox. Los archivos que utilizan este códec suelen tener la extensión de archivo .webm y, en ocasiones, también se denominan archivos WebM.
¿Por qué Google creó VP8 y VP9?
Si bien H.264 es un estándar de facto para toda la industria, tiene un problema importante. Las tecnologías subyacentes están cubiertas por una amplia variedad de patentes. Para utilizar estas tecnologías, si las está integrando en un producto, por ejemplo, deberá pagar una tarifa a la cartera de patentes H.264.
Es por eso que Mozilla resistió tanto tiempo contra H.264: quería que la web se basara en un estándar abierto que no requiriera tarifas. Google lanzó VP8 y VP9 con una promesa de patente irrevocable, lo que permite a las personas hacer lo que quieran con él; Google no intentará extraer tarifas de patentes. Cisco está pagando efectivamente las tarifas de licencia y brinda una enchufar para usuarios de Firefox. Firefox descarga automáticamente este complemento y lo usa para habilitar la compatibilidad con H.264.
VP8 no ha ganado tracción
Pero Google no tuvo mucho éxito con VP8. A principios de 2011, Google Anunciado eliminaría la compatibilidad con H.264 de Chrome para admitir solo códecs abiertos como VP8 y Theora. Más de cuatro años después, Google nunca hizo esto y no hemos escuchado nada sobre esa promesa desde entonces.
Es probable que Mozilla esperara que Google cumpliera su promesa, pero Google nunca pudo; en cambio, Mozilla cedió y agregó soporte H.264 años después. H.264 es el códec estándar de facto actual, nos guste o no, y cuando se usa un navegador de Apple o Microsoft, es el único disponible. También es la única opción real para los navegadores móviles. Muchos sitios web han implementado video HTML5 con solo compatibilidad con H.264, y Chrome y FIrefox quedarían excluidos si no fueran compatibles con H.264.
El verdadero problema: la aceleración del hardware
Aquí hay un problema básico simple. La decodificación (reproducción) H.264 se acelera por hardware. Esto significa que el "trabajo" de reproducir un archivo de video H.264 lo realiza el procesador de gráficos (GPU) de una manera mucho más eficiente. Si la decodificación de hardware no estuviera disponible, la CPU tendría que hacer todo el trabajo de una manera menos eficiente. Esto significa que la reproducción requiere menos tiempo de CPU, lo que significa que se desperdicia menos energía de la batería y se genera menos calor. También podría significar una reproducción más fluida si la CPU no puede seguir el ritmo de reproducción del video.
Realmente, todas las piezas modernas de hardware admiten la decodificación acelerada por hardware H.264. Esto incluye todo tipo de teléfonos inteligentes, tabletas, PC, Mac e incluso Chromebooks. Cuando un navegador web, sí, incluso Chrome, reproduce video H.264, se descarga a la GPU. Incluso Adobe Flash admitía la aceleración por hardware de video H.264.
Pero no existe ningún hardware que acelere los videos VP8 y VP9. Cuando Google Anunciado VP8 A mediados de 2010, una variedad de empresas, incluidos grandes nombres como nVIDIA, AMD y Qualcomm, anunciaron que apoyarían VP8 en sus productos. Pero, más de cinco años después, nunca llegó ningún dispositivo con decodificación VP8 acelerada por hardware.
En el reciente de Google anuncio de VP9, señala que "Más de 20 socios de dispositivos en toda la industria están lanzando productos en 2015 y más allá usando VP9". La misma publicación también señala otras ventajas de VP9, como un tamaño de archivo más pequeño para la misma calidad. Intel, nVIDIA, AMD y otras empresas se han comprometido a admitir la decodificación acelerada por hardware de VP9.
Buscamos para encontrar hardware que admita la decodificación VP9 acelerada por hardware, y todo lo que encontramos fue que Intel lanzó nuevos Haswell y Broadwell conductores para Windows con "soporte de aceleración parcial de ardwareardware (sic)" para VP9 a principios de 2015. Claramente, hay mucho más trabajo por hacer.
Al igual que otros problemas de rendimiento de Chrome, esto puede ser peor en una Mac. Los ingenieros de Chrome resolvieron un error sobre el uso elevado de CPU y la generación de calor en una MacBook con la comentario "El uso de la CPU durante la reproducción de VP9 en una Mac no es un error". Eso puede ser cierto, pero Google probablemente no debería ofrecer todos esos videos VP9 a los usuarios de Chrome en Mac si el uso elevado de la CPU es normal. Eso solo anima a los usuarios de Mac a usar Safari en su lugar.
Cómo hacer que los videos de YouTube Play sean más eficientes
En realidad, es un problema del huevo y la gallina: los fabricantes no van a implementar VP9 acelerado por hardware hasta que se esté utilizando en el mundo real. Google resolvió este problema agregando VP8 y VP9 a Chrome y diciéndole a YouTube que sirva videos VP9 y VP8 a Chrome. YouTube también puede servir videos VP8 y VP9 a Firefox.
Esto puede ahorrar algo de tiempo de descarga, pero significa que YouTube consume más batería y ciclos de CPU en Chrome. En dispositivos con CPU particularmente lentas, los videos pueden incluso tartamudear en lugar de reproducirse sin problemas.
Para obtener una reproducción más eficiente, simplemente puede cambiar a Safari, Microsoft Edge o Internet Explorer. Pero no tienes que hacer eso. Puede instalar la extensión del navegador h264ify para Chrome, lo que obligará a Chrome a solicitar videos H.264 de YouTube. Tendrán el mismo aspecto, pero Chrome los reproducirá con más fluidez.
Descargar h264ify para Chrome , obtener h264ify para Firefox , o consultar la página del proyecto en GitHub para más detalles
Cómo ver si YouTube usa H.264, VP8 o VP9
Para comprobar qué códec está sirviendo YouTube en su navegador, haga clic con el botón derecho en un video de YouTube durante la reproducción y seleccione "Estadísticas para nerds". A la derecha de "Tipo Mime", verá "video / mp4" y el códec "avc" para videos H.264 / MP4.
Para los videos VP8 y VP9, verá "video / webm" y "vp9" o "vp8".
A largo plazo, el empuje VP9 de Google podría ser mejor para la web y generar hardware que pueda proporcionar una decodificación acelerada de este nuevo códec. Pero, en el presente, es posible que desee ahorrar algo de duración de la batería y hacer que su computadora portátil funcione de manera más eficiente al optar por no participar en el experimento de Google y usar video H.264 en su lugar.
Credito de imagen: Esther Vargas en Flickr
