Formato de video universal sin pérdidas

Estoy tratando de encontrar el formato de video sin pérdida más adecuado para video de 1280x720 a 25 fps. El video tiene 4 minutos. El sonido será 320 kbps mp3, eso no es gran cosa. Condiciones ideales:

Sin pérdida (puede ser percepcionalmente sin pérdida)
Contenedor + códec se puede jugar en la mayoría de las plataformas
El códec Container + se puede reproducir en reproductores de DVD modernos (compatible con otros formatos que no sean DVD)
El tamaño es inferior a 700 MB.

¿Es eso posible? Ya he estado luchando tres días, sin resultados satisfactorios, incluso obteniendo archivos de 12 GB (parece mucho: 3 GB / minuto).

video ffmpeg video-editing mrkva
fuente

Para una comparación, ver en.wikipedia.org/wiki/List_of_codecs#Lossless_compression

artistoex

Lo siento, pero prácticamente no puede obtener un video (visualmente) sin pérdida de 720p de 4 minutos comprimido a menos de 700 MB (asumí Megabyte aquí, no "mb", lo que significaría "bit"). ¿Por qué tienes tanta restricción? ¿No puede el video tener codificación h.264?

slhck

Sí, MB, perdón por la confusión. Necesito ajustar videos cca 5 x 4 minutos en 4 GB (limitaciones medias).

mrkva

Como obtiene archivos de 12GiB, supongo que usa una profundidad de color de 24Bit. El flujo de datos de video sin comprimir es de aproximadamente 4GiB por minuto. Esa es una gran cantidad de datos. Lo que quieres es unos 170MiB por minuto. Independientemente del códec que elija, solo puede lograr esto con una escena estática sin mucho movimiento. Me temo que tiene que relajar la restricción para no perder, reducir la velocidad de fotogramas o tolerar un tamaño de archivo más grande.

Marco

¿Puede aclarar que "el códec Container + se puede reproducir en reproductores de DVD modernos (compatibles con otros formatos que no sean DVD)"?

llogan

Respuestas:

El mejor formato real, matemáticamente sin pérdidas que conozco es huffyuv, pero eso producirá archivos enormemente divertidos y no sería compatible con mucho. Para el registro, ffmpeg puede hacerlo con:

ffmpeg -i input -c:v huffyuv -c:a libmp3lame -b:a 320k output.avi

X264, el codificador h.264 de código abierto, tiene un modo sin pérdidas. Esto puede ir dentro de un contenedor MP4 y debería ser compatible con la mayoría del hardware fabricado en los últimos años. El primer comando dará una velocidad de codificación rápida, pero un archivo grande; el segundo comando tomará mucho más tiempo, pero el archivo debe tener aproximadamente la mitad del tamaño del codificado rápido (aunque seguirá siendo bastante grande):

ffmpeg -i input -c:v libx264 -crf 0 -preset ultrafast -c:a libmp3lame -b:a 320k output.mp4

ffmpeg -i input -c:v libx264 -crf 0 -preset veryslow -c:a libmp3lame -b:a 320k output.mp4

Si eso no te da un archivo lo suficientemente pequeño, un crf de 18 generalmente se considera 'visualmente sin pérdidas':

ffmpeg -i input -c:v libx264 -crf 18 -preset veryfast -c:a libmp3lame -b:a 320k output.mp4

En general, recomiendo el ajuste preestablecido muy rápido para codificar con x264, en mi experiencia, ofrece la mejor compensación de velocidad / tamaño (hay una gran caída en el tamaño del archivo entre súper rápido y muy rápido, más lento que eso y es más incremental). El consejo general es utilizar el preajuste más lento que pueda manejar, los preajustes son: ultrarrápido, súper rápido, muy rápido, más rápido, rápido, medio, lento, más lento, muy lento.

Consulte aquí para obtener una guía más detallada sobre la codificación x264.

maldad
fuente

No sugiera veryfastcomo un buen valor predeterminado para pérdida x264. mediumes un buen término medio, pero generalmente lo uso veryslowpara la codificación final de cualquier cosa. Tampoco huffyuves muy rápido, no lo recomendaría para nada más que compatibilidad.

Peter Cordes

ffmpeg tiene algunos otros códecs sin pérdida que podrían valer la pena probar [FFv1 viene a la mente] también. GL!

rogerdpack

Libx264 no reduce a la mitad los dos canales de color (en YUV, UV) en ninguna dirección, incluso si usa un CRF de 0, por lo que no es realmente sin pérdidas. Además, con los errores de redondeo, no se garantiza que los datos sean idénticos bit por bit después de una ronda de compresión x264.

Adisak

En mis experimentos con ffmpeg 3.4.1, libx264 utilizó el formato de píxeles yuv444, donde "444" significa "no reducir la parte U, V". Y, al OP explícitamente no le importan los errores de redondeo: "puede ser percepcionalmente sin pérdidas". Entonces, @Adisak, sus preocupaciones son razonables, pero no aplicables a esta respuesta.

Jim DeLaHunt

ffmpeg y libx264 en modo YUV negociarán un formato de píxel YUV basado en la entrada. Entonces, si la entrada es YUV 4: 2: 0, entonces también lo es el formato de píxeles de salida. Si la entrada es YUV 4: 4: 4 o RGB, entonces la salida es YUV 4: 4: 4.

Gyan

En estos días me gusta webm :

ffmpeg -i input.avi -c:v libvpx-vp9 -lossless 1 output.webm

Para realizar una conversión más rápida, con procesadores de varios núcleos, he leído que se recomienda usar un hilo menos que el de los núcleos reales. Entonces, con un núcleo de 8 puede especificar 7 hilos como este:

ffmpeg -i input.avi -c:v libvpx-vp9 -threads 7 -lossless 1 output.webm

LonnieBest
fuente

Me gusta usar la variable de entorno% NUMBER_OF_PROCESSORS% para determinar el recuento de hilos a usar. Si el recuento es 1 o 2, utilicé todos los procesadores. Si el recuento es 3 o 4, uso todos menos un procesador. Y si el recuento es mayor, utilizo todos menos dos procesadores para el recuento de subprocesos.

Adisak

Como expresiones de DOS, se ve así: if "% ADJUSTED_CPUCOUNT%" EQU "" (if% NUMBER_OF_PROCESSORS% EQU 1 (set ADJUSTED_CPUCOUNT = 1) else if% NUMBER_OF_PROCESSORS% EQU 2 (set ADJUSTED_CPUCOUNT = 2) más if% NUMBER_CONSE EQU 3 (conjunto ADJUSTED_CPUCOUNT = 2) más si% NUMBER_OF_PROCESSORS% EQU 4 (conjunto ADJUSTED_CPUCOUNT = 3) else (set / A ADJUSTED_CPUCOUNT =% NUMBER_OF_PROCESSORS% -2))

Adisak

superuser.com/questions/155305/… dice que ffmpeg ya elige el número óptimo de subprocesos

Boris

Una mejor opción que webm (en estos días) es quizás el formato av1 .

LonnieBest

-1

# ENVASE

para tener compatibilidad total con reproductores de DVD, necesitará usar formato MPEG-2, contenedor, restricciones, códecs. Supongo que "jugadores modernos" significa compatibilidad con "mp4", que es básicamente y principalmente un reproductor de archivos mp4 - H.264, MPEG-4, AVC => libx264
leer más: https://de.wikipedia.org/wiki /H.264

# VIDEO

Echar un vistazo a https://trac.ffmpeg.org/wiki/Encode/H.264 , especialmente la parte en que se trata de "perfil" y "nivel", para la compatibilidad
Usando -profile:v high -level 4.0debe hacerlo

# AUDIO

Evite volver a codificar pistas de audio con códecs con pérdida: cualquier formato mp3 tiene pérdida, incluso 320 kbps.
Usar en su -c:a copylugar.

Hasta ahora, hizo un muy buen trabajo para mí. Sin problemas de sincronización.
Las secuencias de audio no están vinculadas a fotogramas clave. Cortes precisos son posibles.
Si su pista de audio está grabada a una frecuencia de muestreo de 44 kHz, use máx. 256 kbps

Use códecs con pérdida solo para la codificación final de su video, si necesita cumplir ciertos requisitos previos.

He oído hablar de algunos problemas de sincronización de audio, pero parece que el problema principal fue que era material protegido (!).

# Finalmente

Prefiero algo como esto:
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4

d'oh
fuente

La opción "-level 4.0" no es necesaria. El nivel en x264 se determina en función de la resolución y el FPS, por lo que generalmente no tiene sentido configurarlo manualmente, esto no mejorará nada. Por lo que sé, ffmpeg puede establecer el nivel correcto automáticamente, por lo que, a menos que tenga una buena razón para forzarlo y comprender completamente cómo elegir el nivel basado en FPS y resolución, no debe usar la opción "-level". Si le interesa la compatibilidad más alta, use el perfil "línea base" en lugar de "alto".

Lissanro Rayen