¿Cómo codifica YouTube mis cargas y qué códec debo usar para cargar?

Relacionado con ¿Qué códecs/formatos son apropiados para la grabación de video de movimiento completo para youtube? Me pregunto exactamente cómo puedo esperar que Youtube maneje mis videos. Sé que tienen una configuración de procesamiento bastante entusiasta que genera múltiples copias de mi carga en diferentes resoluciones; 1080p, 720p y 480p y aparentemente móvil, como mínimo.

¿Qué códec(s) utilizan? Como productor, tengo la opción de descargar el archivo como MP4; sin embargo, observo que un descargador de terceros (que es extremadamente turbio y de mala calidad) baja los archivos como FLV. Básicamente, me pregunto si mi códec se conservará o se sobrescribirá con H.264 o lo que sea que usen. Teniendo en cuenta su asombrosa compatibilidad entre dispositivos, asumo que usan un estándar muy común o múltiples códecs para cada video.

Entonces, ¿en qué códec puedo esperar que salgan mis videos y, si depende, de qué depende? ¿Debo ajustar mi propia codificación para "jugar bien" con el códec de Youtube, o importa, en cuanto a la calidad? Sé que puedo lanzar casi cualquier cosa en Youtube y lo aceptará, así que lo que más me preocupa es la calidad del video.

aquí hay una herramienta para ver los formatos disponibles para un video: h3xed.com/web-and-internet/…

Respuestas (4)

Alguna información general sobre los formatos utilizados:

YouTube utiliza 4 formatos de contenedor y 4 códecs diferentes. Depende de la popularidad del video qué códecs se utilizan para su video (vea a continuación por qué). En general, cada uno de sus videos cargados se codificará en h.264 y se multiplexará en un contenedor .flv y .mp4. Ese es el estándar y esto sucederá para cada video. Aunque .flv solo se usará para resoluciones inferiores a 720p. Lo que significa que solo existirán 360p y 480p en un contenedor .flv. Aunque todos los videos por debajo de 720p también tendrán una versión mp4 disponible. Para 240p, YouTube también usa 3gp, que es un códec bastante antiguo (basado en MPEG-4 Parte 2 (que no debe confundirse con MPEG4 Parte 10, también conocido como h.264) destinado a dispositivos móviles (mucho antes de la era de los teléfonos inteligentes), viene en el contenedor .3gpp.

El otro códec utilizado es VP8, que viene en el formato de contenedor WebM. WebM es un formato desarrollado por Google y fue pensado como un códec de video estándar para HTML5, el soporte para él es ahora bastante bueno en la mayoría de los navegadores modernos. WebM se introdujo con la versión HTML5 de YouTube. YouTube solo codifica algunos videos en WebM después de que se cargaron y, en su mayoría, solo videos populares (según los videos que vi codificados en WebM), por lo que no es seguro que su video esté presente en WebM. Aunque esto está cambiando con WebM ganando más apoyo.

YouTube también admite VP8/VP9 en el contenedor WebM. Esto es compatible con todos los principales navegadores desde hace varios años. Con WebM, también introdujeron compatibilidad con el códec de audio Opus (además de AAC, que se usa en todos los demás contenedores).

Con respecto a su pregunta vinculada (¿tal vez deberían fusionarse?)

¿Qué códec/contenedor debería usar para cargar?

Eso depende, si está limitado/preocupado por su velocidad de carga, entonces use h.264 Level 3.1/4.1 con Main Profile para SD o High Profile para HD. YouTube aceptará esto muy bien y se verá bien después de que los servidores de YouTube lo codifiquen. Por lo general, recomendaría una tasa de bits de ~4-5 Mbit/s para material de 720p y ~8-9 Mbit/s para 1080p. Para 4k, elige ~15-25 Mbit/s o más dependiendo de la complejidad del metraje. El contenido de "dibujos animados" con pocos colores generalmente puede tener una tasa de bits mucho más baja en general. Este suele ser un buen equilibrio entre tamaño y calidad. Si desea una mejor calidad, elija una tasa de bits más alta, y si desea un video más pequeño, elija una tasa de bits más baja.

Pero tenga en cuenta que YouTube SIEMPRE codificará su video una vez que se cargue, sin importar el códec y la configuración que use. Entonces, si desea la mejor calidad teórica para sus cargas, elija un códec sin pérdidas para cargar o al menos visualmente sin pérdidas. Vea YouTube como el resultado final en un formato de entrega/consumidor y la carga en YouTube es el último paso en la producción y durante la producción desea permanecer sin pérdidas. Pero tenga en cuenta que todo esto es solo una cuestión teórica, prácticamente diría que realmente no importa, ya que estamos hablando de YouTube y no de transmisiones de televisión o cine. En casi todos los casos, una codificación h264 de tasa de bits muy alta (20-40mbit/s) será suficiente incluso para contenido de alta gama.

Pero si realmente quiere hacerlo de la manera "perfecta", use un códec de producción y no un códec de consumo como h.264. MJPEG sería un buen códec para eso, YouTube definitivamente lo admite en un contenedor .avi o .mov. MJPEG es un códec con pérdida, pero la calidad visual será la misma que la fuente (si elige una configuración de calidad lo suficientemente alta, esto es prácticamente JPEG como códec de video). Optar por un códec sin pérdidas real sería una pérdida de espacio en el disco duro y ancho de banda, en mi opinión.

Pero si desea cargar su video realmente sin pérdidas y no le importa el tiempo de carga, le recomiendo usar un códec QuickTime estándar, ya que YouTube debería admitir casi todos (tenga en cuenta que no todos son sin pérdidas, h264 también es un códec QuickTime estándar). Aunque YouTube no indica qué códecs de QuickTime son compatibles, desafortunadamente. La animación o JPEG2000 deberían funcionar, supongo. Ambos códecs pueden ser 100 % sin pérdidas dependiendo de la configuración en el caso de JPEG2000.

Cuando se trata de velocidades de fotogramas, si puede elegir, use 25 FPS o 30 FPS durante la grabación/animación (por ahora, YouTube también admite videos de 50 y 60 FPS o más, así que úselo si su contenido se beneficia de una velocidad de fotogramas más alta), a YouTube le gustan las velocidades de fotogramas estándar como 25 o 30 FPS como máximo (o de nuevo una de las opciones de FPS más altas), pero si su metraje ya viene en otra velocidad de fotogramas como 24 FPS, entonces quédese con eso y no interpole hacia arriba o hacia abajo. YouTube manejará la conversión por ti y generalmente lo hace mejor que tu codificador promedio. Tienen que lidiar con todo tipo de velocidades de fotogramas todos los días y resolvieron este problema (en realidad muy complicado) muy bien.

Audio:

Para el audio, use PCM si desea permanecer sin pérdidas con el audio también, pero nuevamente, esto es solo una mejora teórica de la calidad. AAC generalmente hará el mismo trabajo en cuanto a calidad (subjetivo) y será más pequeño. Recomiendo una tasa de bits de 128-192 kbps para AAC. El impacto del tamaño generalmente no es tan grande como el códec de video, por lo que también puede usar 192 kbps o más si cree que su contenido de audio es muy sensible. YouTube convertirá el audio a ~24 kbps (móvil, también conocido como 3gp), ~64 kbps (240p), ~128 kbps (360p/480p) y ~192 kbps (720p+) usando el códec AAC y Opus (solo WebM).

Estoy de acuerdo con esta respuesta. Pero hay un límite práctico: la velocidad de subida. ¿Cuánto tiempo estás permitiendo para una carga? Todo un fin de semana, una noche o un par de horas hasta el final de su jornada laboral. Yo mismo puse el límite de 2 GB para 10 minutos de video, lo que necesita alrededor de 4 horas de tiempo de carga en mi caso. ¿Pero esto realmente restringe la calidad? Mi video de 2 GB tiene una tasa de bits de 30 Mbit/s, que YouTube convierte a 3 Mbit/s. Una codificación sin pérdidas multiplicaría el tiempo de carga, pero la salida de YouTube seguiría siendo de 3 Mbit/s. Por favor, establezca sus límites personales usted mismo.
Claro, es por eso que dejé (con suerte) bastante claro que es teórico y de ninguna manera práctico. Se recomienda H.264 para casi todos los casos. El único caso de uso práctico real para MJPEG que se me ocurre es cuando se producen bandas de color con la primera codificación h.264 que empeorará con la segunda codificación de YouTube.
Youtube admite h.264 de alto perfil, por lo que debe usarlo siempre. El perfil principal para contenido SD es una tontería. Omitir 8x8dct siempre es una mala idea. En x264, habilitar 8x8dct es la compensación más eficiente del tiempo de CPU para una mejor calidad por tamaño de archivo (también conocido como velocidad: distorsión o RD).
H.264 se verá mucho mejor con la misma tasa de bits que MJPEG. Si desea una mejor calidad, simplemente suba la tasa de bits (o la configuración de calidad en calidad constante en lugar del modo de tasa de bits objetivo). Puede ir hasta h.264 sin pérdidas si no le importa cargar un archivo enorme. Probablemente será más pequeño que j2k sin pérdidas. Sin embargo, ambos son de calidad perfecta, ya que eso es lo que significa sin pérdidas.
Para audio, IDK si youtube admite FLAC o no. Si es así, esa sería su opción preferida para lossless. De lo contrario, sí, AAC de alta tasa de bits hecho con un buen codificador. ( -c:a libfdk-aac, no los codificadores predeterminados faaco incorporados aacen ffmpeg.)

El formato de salida de video de YT depende de varios factores. Para la mayoría de los videos comunes, utilizan flujos de video codificados H264 (AAC o MP3 para audio) en forma de archivos contenedores MP4 y FLV.

Estos son solo contenedores que contienen los datos de video codificados, aunque el formato codificado H264 no es una garantía con los archivos FLV (o en teoría con los archivos MP4), ya que también pueden contener Sorenson Spark, On2 VP6 y otros (especialmente en el caso de videos más antiguos ).

Los FLV se utilizan porque se garantiza que se pueden reproducir con Flash-player.

Realmente no depende del software de descarga determinar el formato, simplemente descargan lo que está disponible usando la itagURL del video "interno" (no la que está en el navegador) para identificar las opciones. Si opcionalmente convierten el video, sería una función, pero no estaría relacionada con los formatos de YT.

También hay otros formatos además de estos, como 3GP, WEBM y películas en 3D. Algunos para teléfonos de destino y el nuevo estándar Html5 (que se está implementando mientras hablamos) que puede reproducir videos directamente con html (es decir, sin flash-player).

Pero volvamos a los formatos más comunes: en cuanto a la calidad, realmente no importa. Si el FLV contiene H264, puede reproducirlo tan bien como un archivo contenedor MP4 con el reproductor VLC de f.ex VideoLAN . Si el FLV no contiene H264 y lo desea como un contenedor MP4 que contiene H264, deberá volver a codificarlo, lo que significa que perderá calidad.

Como YT actualmente parece preferir H264, también sugeriría cargar en este formato (consulte su información sobre tamaños y velocidades de bits para evitar recodificar para obtener la mejor resolución).

Su pregunta es "¿Cómo codifica YouTube mis cargas y qué códec debo usar para cargar?".

Al profundizar en su pregunta, veo: "¿Debo ajustar mi propia codificación para" jugar bien "con el códec de Youtube, o importa, en cuanto a la calidad? Sé que puedo lanzar casi cualquier cosa en Youtube y lo tomará, así que Lo que más me preocupa es la calidad del video".

La respuesta es que YouTube usa Lavf57.25.100 para codificar videos nuevos, mientras que los videos de algunos años de antigüedad se codificaron con un codificador patentado (que no tiene "Lavf57.25.100" incrustado en su ID, sino que tiene esta oración: "Archivo IsoMedia producido por Google, 5-11-2011"). Los videos antiguos no se recodificaron cuando se cambió el algoritmo.

Es aceptable usar muchos códecs diferentes, YouTube recomienda H.264; consulte aquí: https://support.google.com/youtube/answer/1722171?hl=en .

Por alguna razón, elige no preguntar sobre el contenedor (que no es lo mismo que un códec). También asume que 1080P estará disponible y no pregunta sobre lo más importante: la tasa de bits (seguida de la resolución).

Si carga un video con una resolución de 1080P a 60FPS, la resolución máxima disponible es 720P (a 60 FPS, en un dispositivo móvil, capaz de 1080P), cargar un video de 1080P a 29,97 FPS permite verlo en 1080P en un dispositivo móvil.

Lo que SÍ es importante es la tasa de bits y la resolución si la "calidad" es su objetivo. No puede mejorar o usar sin pérdidas para hacer trampa, ya que YouTube ejecuta una 'Prueba de compresión' para determinar cuánto pueden aplastar su video con una degradación mínima: cargue una papilla y será una papilla altamente comprimida, cargue alta resolución y alta tasa de bits, luego YouTube retrocederá en el aplastamiento y ofrecerá una experiencia de visualización mucho mejor.

Consulte: https://support.google.com/youtube/answer/1722171?hl=en .

Tenga en cuenta que existen diferentes Resoluciones y 'Expectativas de calidad'. Para videos 4K con expectativas bajas, puede cargar videos que tengan una tasa de bits de 35-45 Mbps, pero si es un "productor" y la calidad es su objetivo, necesita una tasa de cuadros más alta y usar al menos 66-85 Mbps para el Tasa de bits de la cámara (antes de comprimirla muy suavemente).

Si mejora un video de baja resolución y usa un códec sin comprimir con la esperanza de obtener la mejor calidad posible, lo atraparán (y lo reducirán a papilla).

Grabe con una cámara de calidad de producción, video de alta velocidad de fotogramas y velocidad de bits, muy suavemente comprimido (Ffmpeg Q = <10) para obtener los mejores resultados: el "códec" (sus palabras) no es el único factor determinante (aunque desaconsejaría uno viejo).

Ffmpeg admite contenedores .MP4 y el códec H.264, así que utilícelos.

Las personas a menudo se quejan de que YouTube arruina sus videos, el problema es que no subieron la calidad lo suficientemente alta en primer lugar para "activar el interruptor" y hacer que el compresor de YouTube pise suavemente su carga. Los videos perfectos con vista de píxeles son posibles. Se aplica la regla GIGO.

Gracias por el enlace oficial "Configuración de codificación de carga recomendada" , que responde directamente a "¿qué códec debo usar para cargar?" ¡parte!

Están codificados con Lavf57.25.100.

Esta es una de las pocas páginas de ayuda en conflicto que contiene mejor información que algunas de las otras: https://support.google.com/youtube/answer/6039860?hl=en