codificación sin pérdidas h264
¿Es posible realizar una codificación completamente sin pérdidas en h264? Por sin pérdida, quiero decir que si le doy una serie de fotogramas y los codifico, y luego si extraigo todos los fotogramas del video codificado, obtendré exactamente los mismos fotogramas que en la entrada, píxel por píxel, fotograma por fotograma. ¿Es realmente posible? Tomemos este ejemplo:
Genero un montón de fotogramas, luego codifico la secuencia de imágenes a un AVI sin comprimir (con algo como virtualdub), luego aplico h264 sin pérdida (la ayuda los archivos afirman que la configuración de q qp 0 hace que la compresión sin pérdidas, pero no estoy seguro de si eso significa que no hay pérdida en cualquier punto del proceso o que solo la cuantización es sin pérdidas). Luego puedo extraer los fotogramas del video h264 resultante con algo como mplayer.
Probé con Handbrake primero, pero resulta que no admite codificación sin pérdida. Probé x264 pero se bloquea. Puede ser porque mi archivo AVI de origen está en el espacio de color RGB en lugar de YV12. No sé cómo alimenta una serie de mapas de bits YV12 y en qué formato a x264 de todos modos, así que ni siquiera puedo intentarlo.
En resumen lo que quiero saber si hay una manera de ir desde
Serie de mapas de bits sin pérdida (en cualquier espacio de color) -> alguna transformación -> codificación h264 -> decodificación h264 -> alguna transformación -> la serie original de mapas de bits sin pérdida
Si hay una manera de lograr esto?
EDITAR: Hay un punto MUY válido acerca de H264 sin pérdidas que no tiene demasiado sentido. Soy muy consciente de que no hay manera de que pudiera decir (con solo mis ojos) la diferencia entre y clip sin comprimir y otro comprimido a una alta velocidad en H264, pero no creo que no esté exento de usos. Por ejemplo, puede ser útil para almacenar video para editar sin tomar grandes cantidades de espacio y no perder calidad y gastar demasiado tiempo de codificación cada vez que se guarda el archivo.
ACTUALIZACIÓN 2: Ahora x264 no se bloquea. Puedo usar como fuentes avisynth o lagarith yv12 sin pérdidas (para evitar el advertencia de compresión del espacio de color). Howerver, incluso con q qp 0 y una fuente rgb o yv12 todavía tengo algunas diferencias, mínimas pero presentes. Esto es preocupante, porque toda la información que he encontrado en la codificación predictiva sin pérdida (q qp 0) afirma que toda la codificación debe ser sin pérdida, pero no puedo verificarlo.
8 answers
Voy a agregar una respuesta tardía a esta después de pasar todo el día tratando de averiguar cómo obtener píxeles YUV 4:4:4 en x264. Mientras que x264 acepta píxeles 4:2:0 raw en un archivo, es realmente bastante difícil obtener píxeles 4:4:4 pasados. Con las versiones recientes de ffmpeg, lo siguiente funciona para una codificación y extracción completamente sin pérdidas para verificar la codificación.
Primero, escribe tus píxeles raw yuv 4:4:4 en un archivo en formato plano. Los planos son un conjunto de bytes Y, a continuación, la U y V bytes donde U y V utilizan 128 como el valor cero. Ahora, invoque ffmpeg y pase el tamaño de los fotogramas raw YUV como use el formato de píxel "yuv444p" dos veces, así:
ffmpeg -y -s 480x480 -pix_fmt yuv444p -i Tree480.yuv \
-c:v libx264 -pix_fmt yuv444p -profile:v high444 -crf 0 \
-preset:v slow \
Tree480_lossless.m4v
Una vez que se realiza la codificación a h264 y el empaquetado como un archivo Quicktime, se pueden extraer exactamente los mismos bytes de la siguiente manera:
ffmpeg -y -i Tree480_lossless.m4v -vcodec rawvideo -pix_fmt yuv444p \
Tree480_m4v_decoded.yuv
Finalmente, verifique los dos archivos binarios con diff:
$ diff -s Tree480.yuv Tree480_m4v_decoded.yuv
Files Tree480.yuv and Tree480_m4v_decoded.yuv are identical
Solo tenga en cuenta que necesita escribir los bytes YUV en un archivo usted mismo, no deje que ffmpeg haga ninguna conversión del YUV valores!
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-08-29 09:05:33
Si x264 hace codificación sin pérdida pero no le gusta su formato de entrada, entonces su mejor opción es usar ffmpeg para tratar con el archivo de entrada. Intenta comenzar con algo como
ffmpeg -i input.avi -f yuv4mpegpipe -pix_fmt yuv420p -y /dev/stdout \
| x264 $OPTIONS -o output.264 /dev/stdin
Y añadiendo opciones desde allí. YUV4MPEG es un formato sin comprimir sin pérdida adecuado para canalizar entre diferentes herramientas de video; ffmpeg sabe cómo escribirlo y x264 sabe cómo leerlo.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-07-15 01:56:28
No conozco sus requisitos para la compresión y descompresión, pero un archivador de propósito general (como 7-zip con LZMA2) debería ser capaz de comprimir casi tan pequeño o, en algunos casos, incluso significativamente más pequeño que un códec de video sin pérdida. Y es mucho más simple y más seguro que toda una cadena de procesamiento de video. La desventaja es la velocidad mucho más lenta, y que tienes que extraer antes de verlo. Pero para las imágenes, creo que deberías probarlo.
También hay formatos de imagen sin pérdida, como .png.
Para codificar RGB sin pérdida con x264, debe usar la versión de línea de comandos de x264 (no puede confiar en las GUI en este caso de borde, probablemente lo estropearán) r2020 o más reciente, con algo así:
x264 --qp 0 --preset fast --input-csp rgb --output-csp rgb --colormatrix GBR --output "the_lossless_output.mkv" "someinput.avs"
Cualquier pérdida/diferencia entre la entrada y la salida debe ser de alguna conversión de espacio de color (ya sea antes de la codificación, o en la reproducción), configuración incorrecta o algún encabezado/meta-datos que se perdió. x264 no soporta RGBA, pero RGB está bien. YUV 4: 4: 4 la compresión es más eficiente, pero perderá algunos datos en la conversión del espacio de color ya que su entrada es RGB. YV12 / i420 es mucho más pequeño y, con mucho, el espacio de color más común en el video, pero tiene menos resolución de croma.
Más información sobre la configuración de x264: http://mewiki.project357.com/wiki/X264_Settings
También, evite lagarith. Utiliza x87 coma flotante... y hay mejores alternativa. http://codecs.multimedia.cx/?p=303 http://mod16.org/hurfdurf/?p=142
EDITAR: No se por qué no voté. Por favor, deja un comentario cuando lo hagas.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-06-07 17:09:48
FFmpeg tiene un modo "sin pérdidas" para x264, consulte Guía de codificación FFmpeg y x264
En esencia es -qp 0
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-09-29 20:34:39
Para generar H. 264 sin pérdidas con HandBrake GUI, configure el Códec de video: H. 264, Calidad Constante, RF: 0, Perfil H. 264: auto. Aunque este archivo no es compatible de forma nativa por Apple, se puede volver a codificar como casi sin pérdidas para la reproducción.
Ventana de actividad de HandBrake GUI:
H. 264 Profile: auto; Codificación a la constante RF 0.000000... perfil alto 4:4:4 Predictivo, nivel 3.0, 4:2:0 8-bit
Perfil H. 264: alto; Codificación a RF constante 0.000000... sin pérdidas requiere perfil high444, deshabilitando... perfil alto , nivel 3.0
Si no puede obtener compresión sin pérdida utilizando un codificador y decodificador h.264, tal vez usted podría mirar en dos alternativas:
(1) En lugar de pasar todos los datos en formato h.264, algunas personas están experimentando con la transmisión de algunos de los datos con un residual "canal lateral":
- (archivo h. 264) - > decodificación h264 - > alguna transformación- > una aproximación con pérdida de la serie original de mapas de bits
- (archivo residual comprimido) dec > decodificador- > una serie de sin pérdida mapas de bits residuales
- Para cada píxel en cada mapa de bits, approximate_pixel + residual_pixel = un píxel bit por bit igual al píxel original.
(2) Utilice el formato de compresión de vídeo Dirac en modo "sin pérdidas".
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2011-08-26 03:44:53
Estoy de acuerdo en que a veces la pérdida de datos es aceptable, pero no es simplemente una cuestión de cómo se ve inmediatamente después de la compresión.
Incluso una pérdida visualmente imperceptible de datos de color puede degradar el metraje de tal manera que la corrección de color, la clave de pantalla verde, el seguimiento y otras tareas posteriores se vuelven más difíciles o imposibles, lo que agrega gastos a una producción.
Realmente depende de cuándo y cómo se comprime en la canalización, pero en última instancia, tiene sentido archivar el original calidad, ya que el almacenamiento suele ser mucho menos costoso que el reinicio.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2012-07-12 23:37:30
Esto no es exactamente una respuesta a su pregunta, sino más bien una razón por la que ser con pérdida puede ser mejor que sin pérdida.
Aquí hay una comparación de la misma imagen pero codificada de manera diferente con un formato con y sin pérdida.
PNG (sin pérdidas) 148 kB:
JPEG-8 (con pérdidas) 36 kB:
JPEG-10 (con pérdidas) 65 kB:
JPEG-12 (con pérdidas) 122 kB:
Ahora abre tanto la imagen PNG (sin pérdidas) como la imagen JPEG-10 (con pérdidas) en dos pestañas nuevas en su navegador web. Voltear hacia adelante y hacia atrás, se puede ver una débil diferencia, pero apenas. Mi punto es que nunca se notaría la diferencia en la calidad sin mirar a ambos al mismo tiempo y examinarlos de cerca. La compresión de datos sin pérdida no vale la pena en la mayoría de los casos porque los formatos con pérdida pueden darle la calidad exacta a un costo menor (tamaño de archivo).