Estoy tratando de convertir mi biblioteca de videos al formato HEVC para ganar espacio. Ejecuté el siguiente comando en todos los archivos de video en mi biblioteca:
#!/bin/bash for i in *.mp4; do #Output new files by prepending "X265" to the names avconv -i "$i" -c:v libx265 -c:a copy X265_"$i" done
Ahora, la mayoría de los videos se convierten bien y la calidad es la misma que antes. Sin embargo, algunos videos que son de muy alta calidad (por ejemplo, una película impresa de 5GB) pierde calidad; el video está pixelado.
No estoy seguro de qué hacer en este caso. ¿Necesito modificar el parámetro crf
en mi línea de comando? ¿O algo más?
La cuestión es que estoy haciendo una conversión masiva. Entonces, necesito un método donde avconv
ajuste automáticamente cualquier parámetro que necesite ajuste, para cada video.
UPDATE-1
Encontré que crf
es la perilla que necesito ajustar. El CRF predeterminado es 28. Para una mejor calidad, podría usar algo menos de 28. Por ejemplo:
avconv -i input.mp4 -c:v libx265 -x265-params crf=23 -c:a copy output.mp4
Sin embargo, el problema es que para algunos videos CRF un valor de 28 es suficientemente bueno, mientras que para algunos videos, se requiere un CRF más bajo. Esto es algo que tengo que verificar manualmente convirtiendo pequeñas secciones de los videos grandes. Pero en la conversión masiva, ¿cómo verifico cada video manualmente? ¿Hay alguna manera de que avconv
pueda ajustar el CRF de acuerdo con el video de entrada de manera inteligente?
ACTUALIZACIÓN-2
Descubrí que hay un --lossless
opción en x265: http://x265.readthedocs.org/en/default/lossless.html .
Sin embargo, no sé cómo usarlo correctamente. Intenté usarlo de la siguiente manera pero arrojó resultados opuestos (el video estaba aún más pixelado):
avconv -i input.mp4 -c:v libx265 -x265-params lossless -c:a copy output.mp4
Comentarios
Respuesta
Según mi propia experiencia, si no desea absolutamente ninguna pérdida de calidad, –lossless es lo que estás buscando.
No estoy seguro acerca de avconv
pero el comando que escribiste parece idéntico al que hago con FFmpeg
. En FFmpeg
puede pasar el parámetro de esta manera:
ffmpeg -i INPUT.mkv -c:v libx265 -preset ultrafast -x265-params lossless=1 OUTPUT.mkv
La mayoría de x265
(opciones sin valor) se pueden especificar de esta manera (excepto los que solo tienen CLI, solo se usan con x265
binario directamente).
Con eso fuera del camino, me gustaría compartir mi experiencia con la codificación x265
. Para la mayoría de los videos (ya sea WMV, MPEG o AVC /H.264) Yo uso crf=23
. x265
decide el resto de los parámetros y normalmente hace un buen trabajo.
Sin embargo, a menudo, antes de comprometerme a transcodificar un video en su totalidad, pruebo mi configuración convirtiendo una pequeña parte del video en cuestión. Aquí hay un ejemplo, supongamos que un archivo mkv con la transmisión 0 es video, la transmisión 1 siendo audio DTS, y el flujo 2 es un subtítulo:
ffmpeg -hide_banner \ -ss 0 \ -i "INPUT.mkv" \ -attach "COVER.jpg" \ -map_metadata 0 \ -map_chapters 0 \ -metadata title="TITLE" \ -map 0:0 -metadata:s:v:0 language=eng \ -map 0:1 -metadata:s:a:0 language=eng -metadata:s:a:0 title="Surround 5.1 (DTS)" \ -map 0:2 -metadata:s:s:0 language=eng -metadata:s:s:0 title="English" \ -metadata:s:t:0 filename="Cover.jpg" -metadata:s:t:0 mimetype="image/jpeg" \ -c:v libx265 -preset ultrafast -x265-params \ crf=22:qcomp=0.8:aq-mode=1:aq_strength=1.0:qg-size=16:psy-rd=0.7:psy-rdoq=5.0:rdoq-level=1:merange=44 \ -c:a copy \ -c:s copy \ -t 120 \ "OUTPUT.HEVC.DTS.Sample.mkv"
Tenga en cuenta que las barras invertidas señalan saltos de línea en un comando largo, lo hago para ayudarme a realizar un seguimiento de varios bits de una entrada CLI compleja. Antes de explicarlo línea por línea, la parte en la que conviertes solo una pequeña parte de un video es la segunda línea y la penúltima línea: -ss 0
significa buscar 0 segundos antes comienza a decodificar la entrada, y -t 120
significa dejar de escribir en la salida después de 120 segundos. También puede utilizar los formatos de hora hh: mm: ss o hh: mm: ss.sss.
Ahora línea por línea:
-
-hide_banner
evita queFFmpeg
muestre información de compilación al inicio. Simplemente no «quiero verlo cuando me desplazo hacia arriba en la consola; -
-ss 0
busca 0 segundos antes de comenzar a decodificar la entrada. Tenga en cuenta que si este parámetro se proporciona después del archivo de entrada y antes del archivo de salida, se convierte en una opción de salida y le dice affmpeg
para decodificar e ignorar la entrada hasta x segundos, y luego comenzar a escribir en la salida.Como opción de entrada, es menos precisa (porque la búsqueda no es precisa en la mayoría de los formatos de contenedor), pero casi no lleva tiempo.Como opción de salida, es muy precisa, pero toma una cantidad considerable de tiempo decodificar todo el flujo antes del tiempo especificado, y para propósitos de prueba no quiere perder tiempo; -
-i "INPUT.mkv"
: especifique el archivo de entrada; -
-attach "COVER.jpg"
: adjunte una carátula (imagen en miniatura, póster, lo que sea) a la salida. la portada generalmente se muestra en los exploradores de archivos; -
-map_metadata 0
: Copie todos y cada uno de los metadatos de la entrada 0, que en el ejemplo es solo la entrada; -
-map_chapters 0
: copia la información del capítulo (si está presente) de la entrada 0; -
-metadata title="TITLE"
: Establece el título del video; -
-map 0:0 ...
: Asigna el flujo 0 de la entrada 0, lo que significa que queremos que el primer flujo de la entrada se escriba en la salida Dado que esta transmisión es una transmisión de video, es la primera transmisión de video en la salida , de ahí el especificador de transmisión:s:v:0
. Establecer su idioma etiqueta al inglés; -
-map 0:1 ...
: similar a la línea 8, asigne la segunda transmisión (audio DTS) y establezca su idioma y título (para una identificación más fácil al elegir de los jugadores); -
-map 0:2 ...
: similar a la línea 9, excepto que esta transmisión es un subtítulo; -
-metadata:s:t:0 ...
: establece metadatos para la portada. Esto es necesario para el formato de contenedor mkv; -
-c:v libx265 ...
: opciones de códec de video. Es tan largo que lo he dividido en dos líneas. Esta configuración es buena para video bluray de alta calidad (1080p) con bandas mínimas en gradiente (que x265 apesta). Lo más probable es que sea excesivo para los DVD, los programas de televisión y los videos del teléfono. Esta configuración se roba principalmente de esta publicación de Doom9 ; -
crf=22:...
: continuación del códec de video parámetros. Vea la publicación del foro mencionada anteriormente; -
-c:a copy
: Copiar sobre audio; -
-c:s copy
: Copia los subtítulos; -
-t 120
: deja de escribir en la salida después de 120 segundos, lo que nos da un clip de 2 minutos para obtener una vista previa de la calidad de la transcodificación; -
"OUTPUT.HEVC.DTS.Sample.mkv"
: nombre del archivo de salida. Etiqueto los nombres de mis archivos con el códec de vídeo y el códec de audio principal.
Vaya. Esta es mi primera respuesta, así que si hay algo que me haya perdido, deje un comentario. No soy un experto en producción de videos, solo soy un tipo que es demasiado vago para ver una película al poner el disco en el reproductor.
PD. Quizás esta pregunta pertenece a otra parte, ya que no está fuertemente relacionado con Unix & Linux.
Comentarios
- Exactamente lo que estaba buscando ! Buena cobertura de opciones. ¿Sabe si ffmpeg se negará en
c:s copy
si no hay contenido de subtítulos? - @ElderGeek No, ffmpeg sólo dirá algo si esa opción tiene algún efecto.
- @TheBitByte Sí y no, creo. No ‘ no desea archivos h265 sin pérdida. Es ‘ un flujo de bits sin formato sin ningún tipo de compresión. Es ‘ enorme. Por lo que entiendo sobre la implementación de h265 o específicamente x265, no es un método de compresión sin pérdidas. Cualquier grado de compresión resultará en pérdida de información, pero no necesariamente pérdida de calidad de visualización. Pero ‘ no soy un experto en temas de h265, por lo que ‘ es posible que me haya perdido algo
- @ TheBitByte No ‘ no creo que haya un nivel de compresión sin pérdidas en h265. Para la opción sin compresión, ‘ es simplemente
--lossless
. Busqué en vano una conversión sin pérdidas de h264 a h265, y lo que ‘ he aprendido me dice que ‘ es matemáticamente imposible. - Realmente debería editar el comando que contiene el
--lossless
cambiar de esta respuesta, porque puesto allí como respuesta a esta pregunta, parece que usted ‘ lo dice ‘ s compresión sin pérdida, lo cual es engañoso.
Responder
Recientemente me he tomado la molestia de transcodificar todo mi catálogo de videos a HEVC. Utilizo https://github.com/FallingSnow/h265ize con la siguiente configuración.
h265ize -v -m medium -q 20 -x –no-sao – -aq-mode 3 –delete –stats
-v – Salida detallada
-m medio – Medio velocidad de codificación (menor calidad superior, cualquier cosa más lenta que encuentre no vale la pena el tiempo / calidad dif)
-q 20 – el CRF usado, 20 es similar a 18 o así en x264 pero bueno.Esto es para contenido de 1080p (90% de mi TV). Tiendo a usar 22 para mis películas 4K
-x – Usa comandos definidos centralmente x265
–no-sao desactiva la compensación adaptativa de muestra (mejora la velocidad de codificación)
–aq-mode 3 – usa la cuantificación adaptable con variación automática, ayuda a codificaciones de 8 bits, especialmente en áreas oscuras, se detiene la mayoría de las bandas que pueden ocurrir (a expensas del tiempo de codificación)
–delete – reemplace el archivo de codificación con archivo codificado (prueba antes de usar este)
–stats – Escribe estadísticas en un archivo csv en la raíz de la ruta desde la que corrió.
Las velocidades de codificación son de alrededor de 30 fps (para la mayoría de las cosas de 1080p) en mi equipo. Dual Xeon E5 2687W v2, pero obligo al proceso FFMPEG a no usar el primer lado de uno de los procesadores (es mi servidor Plex, así que debo asegurarme de que haya una sobrecarga para la transcodificación si es necesario en la reproducción, etc.)
Sí, me tomó un tiempo convertir la mayor parte, y ahora tengo una tarea programada que se ejecuta dos veces al día para codificar las cosas de ese día en x265.
El ahorro de espacio han sido enormes. Mi SAN inicial tenía un uso de 20 TB, ahora tiene alrededor de 12, pero obviamente también se agregó con 6 meses más de contenido.
También comencé a transcodificar todas mis películas, sin embargo un proceso continuo, ya que tengo que identificar los niveles de calidad (Radarr, afortunadamente, las etiquetas bien) y usar una de las tres configuraciones de transcodificación:
-m slower -q 18 -x --no-sao --aq-mode 3
para transcodificaciones de 720p
-m medium -q 20 -x --no-sao --aq-mode 3
para 1080p
-m medium -q 22 -x --no-sao
para 2160p
Espero que eso ayude a algunas personas. Grita si alguien necesita un configurándolo todo a mano. Y antes de codificar todo en x265, piense en la reproducción, si el cliente no es compatible con x265 nativo, entonces el transcade puede ser costoso en términos de CPU y calidad.
Comentarios
- Con x265 2.4 y versiones posteriores (con las nuevas tablas lambda que ofrecen codificaciones más nítidas), SAO suele algo bueno para la calidad por tasa de bits. Aún mancha ligeramente, pero reduce otros artefactos lo suficiente como para que valga la pena.
-
-q 20
no es CRF 20, es ‘ s control de velocidad de QP constante . El modo predeterminado y recomendado, CRF, aumenta el QP en escenas de alta complejidad, por lo que no ‘ no gasta demasiado muchos bits en escenas que son demasiado difíciles de codificar. (Si desea un QP más cercano al uniforme, aumenteqcomp
desde el 0,6 predeterminado hasta quizás 0,7 o 0,8. Más cerca de 1.0 está más cerca de CQP). - cómo ¿Maneja codificaciones hdr / sdr cuando no ‘ no sabe cuál es la fuente?
Responder
La sintaxis correcta para habilitar el modo sin pérdidas para el codificador x265 en ffmpeg es -x265-params lossless=1
(debe agregar =1
).
Sin embargo, para la codificación sin pérdidas hay mejores opciones de códecs. Al probar, descubrí que FFV1 se comprime mucho mejor (tamaño de archivo = ~ 80% de x265) al menos en algunos tipos de video (si se elige la mejor configuración para ambos códecs). Y también funciona más rápido y (AFAIK) no está gravado por patentes. Es decir, es superior a H.265 sin pérdidas en todos los aspectos para el archivo de video. Sin embargo, el compromiso es la compatibilidad con el software y hardware de reproducción actuales.
--lossless
de hecho podrían agrandar el archivo, si decodifica el códec previamente con pérdida y luego encuentra lo que decodificó sin pérdidas. La calidad seguirá siendo exactamente la misma que la entrada.