IMPORTANTE: PROBLEMA RESUELTO (AÚN UN PAR DE PREGUNTAS, AUNQUE), PUBLICÉ ALGUNA INFORMACIÓN DEBAJO DE LA PUBLICACIÓN ORIGINAL COMO UNA ACTUALIZACIÓN SI ALGUIEN ENCUENTRA ESTO ÚTIL:
Pregunta rápida: ¿cuáles son las ventajas de usar los códecs no long-GOP más comunes para editar (DNxHD/DNxHR y Prores) frente a H.264 intra-frame con una tasa de bits alta? En teoría, la capacidad de compresión, incluso si es solo dentro del cuadro, es mejor con H.264, y solo por estar dentro del cuadro, el rendimiento de reproducción durante la edición debería ser equivalente a los otros dos códecs. Además, H.264 admite hasta 12 bits y 4:4:4 (por lo que es flexible). He leído lo que pude con respecto a estos códecs, pero todavía tengo que encontrar una razón por la cual el intra-frame H.264 no se usa más ampliamente para la edición.
Para que conste, pregunto esto porque estoy comenzando un proyecto HDR a partir de un video H.264 high 10 UHD 4:2:0, y tengo dos problemas: si trato de editar con proxies (con DNxHR o Prores ), tengo serios problemas de sincronización entre el archivo de origen y los proxies, por lo que no puedo editar correctamente. Y si transcodifico el archivo fuente a un archivo que no tiene esos problemas de sincronización (como DNxHR, con DNxHR para proxies también), pierdo los datos HDR y el video parece SDR (y esto sucede con cualquier códec, no solo DNxHR No he podido conservar la información HDR del archivo fuente con ningún códec, y probé con FFmpeg y Adobe Media Encoder), pero eso es un problema para otra publicación. La cosa es que estoy atascado usando el metraje original como archivo fuente, pero no puedo editar de esa manera sin proxies (obviamente, la reproducción es extremadamente lenta), así que me preguntaba si transcodificar el archivo de origen a un video H.264 intra-frame y trabajar con eso (y sin proxies) tendría un impacto en la calidad final. No he encontrado información que compare intra-frame H.264 con otros códecs intermedios, en cuanto a calidad y rendimiento.
Gracias de antemano.
ACTUALIZACIÓN (03/02/20):
Hice algunas pruebas para ver cómo se comporta el intra-frame H.264 con Adobe Premiere Pro 2020:
1)Transcodifiqué el metraje original (H.264, contenedor MKV, HDR, 10 bits, UHD, 4:2:0, VBR) con FFmpeg a una "versión" intra-frame del archivo, sin cambiar ninguna otra configuración (acaba de agregar -intra a mi línea de comando FFmpeg original). Usé CRF 18 y veryslow como preestablecido (tengo una muy buena CPU, por lo que todo el archivo se transcodificó durante la noche). Luego importé el archivo a Adobe Premiere Pro 2020. Primero, debo decir que aún no comencé a editar, pero al menos me di cuenta de que era compatible y se comportó como un video dentro del cuadro mientras probaba la reproducción ( Podía avanzar y retroceder muy rápido). Tampoco pude ver ninguna diferencia en la calidad en comparación con el metraje original. En otras palabras, el intra-frame H.264, hasta ahora, parece una buena alternativa a otros códecs intermedios como Prores o DNxHD/DNxHR. De hecho,
2)Sé que los pasos adicionales de transcodificación nunca son buenos en cuanto a la calidad, pero como tenía que transcodificar a un video dentro del cuadro de todos modos, hice otra prueba y transcodifiqué el metraje original a un video HEVC usando FFmpeg (con libx265), manteniendo todo los ajustes originales. El CRF utilizado fue 18, con veryslow como preestablecido también. Usé el perfil main10-intra de x265. Luego hice lo mismo con otro video, que era SDR. Como es de esperar, tomó un poco más de tiempo, pero quería hacer esto por un par de razones: primero, porque quería saber cómo Adobe Premiere Pro 2020 maneja un video intracuadro H.265 HDR UHD. Segundo, porque he leído (y no me citen en esto) que después de transcodificar cualquier video de 8 bits a uno de 10 bits, muchos perciben un aumento en la calidad, debido al espacio de color más amplio que permite que el codificador elija entre muchos más colores durante la transcodificación, lo que reduce las bandas. Bueno, no percibí ninguna diferencia en cuanto a la calidad (en comparación con el archivo H.264 intra-frame y con el metraje original, tanto en los archivos HDR como SDR), pero los tamaños de archivo eran obviamente más pequeños y al menos en mi PC se desempeñaron muy bien en Premiere Pro (la reproducción fue tan rápida como con los videos intra-frame H.264). Obviamente, la reproducción de video HDR no muestra los colores correctos, pero eso es una restricción de Premiere debido a la forma en que maneja los espacios de color (todavía no hay REC2020). pero los tamaños de archivo eran obviamente más pequeños y al menos en mi PC funcionaron muy bien en Premiere Pro (la reproducción fue tan rápida como con los videos H.264 intra-frame). Obviamente, la reproducción de video HDR no muestra los colores correctos, pero eso es una restricción de Premiere debido a la forma en que maneja los espacios de color (todavía no hay REC2020). pero los tamaños de archivo eran obviamente más pequeños y al menos en mi PC funcionaron muy bien en Premiere Pro (la reproducción fue tan rápida como con los videos H.264 intra-frame). Obviamente, la reproducción de video HDR no muestra los colores correctos, pero eso es una restricción de Premiere debido a la forma en que maneja los espacios de color (todavía no hay REC2020).
3)Debido a que tuve problemas de color mientras transcodificaba a DNxHR antes y no pude resolver eso, comencé a pensar que podría tener que ver con el submuestreo de croma (ninguno de los tipos de DNxHR admite 4:2:0, que es el submuestreo del vídeo original). Esa fue otra razón para probar con H.264 (o H.265) dentro del cuadro, para ver si la transcodificación a 4:2:0, 4:2:2 o 4:4:4 producía una diferencia similar en los colores en comparación con DNxHR. Resulta que cuando se transcodifica a 4:2:0 (con H.264 o H.265 como códecs), los colores se ven exactamente iguales a los del metraje original, y tanto 4:2:2 como 4:4:4 se ven mucho como el video DNxHR (colores lavados). No puedo ver la diferencia entre 4:2:2 y 4:4:4, pero cuando se compara con 4:2:0, la diferencia es enorme. En primer lugar, nunca quise aumentar la muestra del video, fue solo porque DNxHR no es compatible con 4: 2: 0, pero nunca esperé tal diferencia. Y si fue por sobremuestreo, no entiendo muy bien por qué 4:2:2 y 4:4:4 se ven exactamente iguales. Tal vez sea algún tipo de error de FFmpeg que interfiere con el espacio de color cuando se realiza un muestreo superior, no sé.
De todos modos, ahora tengo videos dentro del cuadro H.264 y H.265 en funcionamiento, sin los problemas de color (revisé los archivos visualmente, con Mediainfo y con la pestaña Lumetri scopes de Premiere. De hecho, conservaron todos los metadatos necesarios para HDR) , sin problemas de sincronización (también hice un par de proxies con exactamente la misma configuración, pero con menos resolución. Se sincronizan perfectamente con el archivo de origen), con un tamaño de archivo más pequeño que con DNxHR y Prores, y que funcionan muy bien en Premiere Pro 2020 durante la vista previa (tal vez no lo hagan con una CPU inferior, no lo sé). Entonces, uno podría decir, mientras tanto (tengo que comenzar a editar, tal vez encuentre algunos problemas en el camino. Y aún no he probado para exportar desde Premiere usando estos archivos), que mi problema está resuelto.
Pero mi pregunta sigue siendo después de estas pruebas: ¿por qué intra-frame H.264 o intra-frame H265 no se extienden más como alternativas a DNxHR o Prores (los códecs intermedios más utilizados)? No puedo ver nada más que ventajas: tamaño de archivo más pequeño, buen rendimiento de reproducción, muy buena calidad (y si tiene suficiente espacio, incluso podría hacer un archivo sin pérdida H.264 intra-frame si lo desea), conservan el HDR datos, y ambos códecs son muy conocidos y extendidos. Incluso tienen sus propios perfiles intra-frame (por ejemplo, H.265 tiene main10-intra, main444-10-intra, etc.). Los tiempos de transcodificación, en mi experiencia, al menos usando FFmpeg en una PC, no son tan diferentes en comparación con DNxHR o Prores. ¿Hay alguna razón por la que esta no sea la forma ideal de hacerlo durante la edición, además del hecho de que estas "versiones" dentro del cuadro de H.264 y H.
Gracias, cualquier idea sobre esto sería apreciada. Y no me importa compartir los comandos FFmpeg que utilicé si alguien lo encuentra útil.
ProRes/CineForm/DNxHR se popularizó gracias a las plataformas que decidieron utilizarlos. Inicialmente, H.264 no tenía implementaciones de 10 bits y H.265 no existía.
Esos formatos están hechos para resistir la recodificación y son muy rápidos de codificar/decodificar. No se modifican minuciosamente para obtener la mejor calidad posible a una tasa de bits determinada.
Varias cámaras pueden guardar archivos en all-intra H.264. Sé que Panasonic y Sony lo apoyan. Sony lo llama XAVC SI. Ese es solo su nombre de marca para H.264 all-intra con soporte de 10 bits, 12 bits, 422 y 444. Y admite audio PCM que en realidad no cumple con las especificaciones del contenedor MP4. Estos formatos se están poniendo de moda en las cámaras porque las cámaras tienen requisitos de tasa de bits muy específicos para escribir en una tarjeta SD. Pero luego, si observa una grabadora externa como la Ninja V que puede grabar en un SSD, grabará en ProRes/DNxHR porque puede manejar la tasa de bits más alta, y porque nadie saldrá corriendo a comprar algo que diga que es compatible. XAVC SI. La gente quiere ProRes/DNxHR porque les simplifica la vida.
Entonces, si desea el archivo all-intra de la mejor calidad, ciertamente puede obtenerlo. Puedes hacerlo sin pérdidas. Puede hacer un renderizado FFMPEG "muy lento". Pero Premiere/Resolve no agregará la opción de hacer un renderizado de proxy durante toda la noche.
Aquí hay una muy buena discusión sobre la calidad de all-intra H.265 vs. H.264 vs. ProRes: https://www.eoshd.com/comments/topic/46562-prores-vs-h264-vs-h265- e-ipb-vs-all-i-que-buenos-son-en-realidad/
La razón por la que H.265 no es mucho mejor que H.264 es que la mayoría de las ganancias en compresión en los códecs más nuevos provienen de la compresión temporal avanzada y, por definición, all-intra no tiene compresión temporal.
Tal vez en el futuro tengamos más formatos all-intra estándar, pero eso probablemente será algo posterior a HEVC. Podría decirse que hay un beneficio en mantener el metraje de archivo en un formato all-intra con el que es fácil trabajar. Un formato all-intra tiene menos peculiaridades y podría ser mejor para subir a YouTube en algunos casos, dependiendo de cómo se lleve con la transcodificación. Pero estos son casos extremos. La versión all-intra es, por definición, de menor calidad para una tasa de bits determinada.
La verdadera pesadilla, que es lo que te hizo hacer la pregunta en primer lugar, es lidiar con esos metadatos HDR. Es todo un montón de vudú que podría resolver con ffprobe, mkvmerge y mkvpropedit.
Debe averiguar cuál es realmente su problema: ¿Qué metadatos hay en el archivo? ¿Son etiquetas en la transmisión de video o etiquetas en una transmisión de datos lateral separada? Debería poder obtener FFMPEG para preservar eso. Pero lo que funciona en un formato de contenedor podría no funcionar en absoluto para otro formato de contenedor.
Parece que a Premiere no le gusta su archivo fuente y estropea la sincronización, y a FFMPEG no le gusta su archivo fuente y estropea los metadatos. ¿De dónde proviene exactamente esta fuente?
puntapié
Raulo1985
Raulo1985