Tengo un mensaje de WhatsApp de 1 hora de duración, es un audio .ogg de menos de 9 MB de tamaño.
Quiero subirlo a YouTube, así que tengo que hacerlo al menos en un video de un solo cuadro. Así que hice una imagen de portada JPEG de 1024 x 768 píxeles. Primero, solo usé VLC y emití un SF de YouTube o cualquier resultado, pero YouTube se agita en ese "procesamiento 0%" durante días y días. Así que ahora tengo que hacer otra cosa. Usando ffmpeg. Idealmente, solo usaría la increíble compresión ogg pasándola:
ffmpeg -loop 1 -y -i image.jpg -i audio.ogg -shortest -acodec copy -vcodec libx264 -crf 25 -pix_fmt yuv420p result.mp4
Pero eso no funciona en algunos reproductores, así que ni siquiera molestaré a YouTube con eso.
ffmpeg -loop 1 -y -i image.jpg -i audio.ogg -shortest -acodec mp3 -vcodec libx264 -crf 25 -pix_fmt yuv420p result.mp4
¡Eso crea un archivo enorme de más de 120 MB de tamaño! Tengo Internet horrible, no voy a pasar un archivo de <9 MB a> 120 MB solo para subirlo a YouTube.
Así que pensé si podía tener solo un i-frame y el resto p-frames que deberían estar básicamente vacíos porque el "video" no tiene cambios en la imagen con el tiempo. Leí sobre la opción -g:
ffmpeg -loop 1 -y -i image.jpg -i audio.ogg -shortest -acodec mp3 -vcodec libx264 -crf 25 -pix_fmt yuv420p -g 100000 result.mp4
El -g 100000 cubre los 94,288 marcos. Pero aún con eso obtengo> 60 MB.
¿Cómo puedo hacer el video de imágenes fijas + audio en su mayoría más compacto que YouTube realmente terminará de procesar?
Aquí hay algunos cálculos más para mostrar por qué algo por encima de 20 MB no debería ser aceptable.
El audio en la compresión ogg tiene un tamaño de 8,61 MB. Eso hace una tasa de bits de
8.61 MB * 1024^2 [B/MB] / 8 [b/B] / 62 [min] / 60 [s/min]
= 303.368... b/s
¡Eso es 303 bits por segundo! Ese es un poder de codificación bastante impresionante de este audio mono ogg de un canal. ¡Imagínese lo que siente un terminal de teletipo de 300 bits por segundo mientras escribe! ¡Y ahora imagine cómo puede hablar más rápido a través de este tipo de línea de bajo ancho de banda de lo que puede escribir y ver una actualización de pantalla!
Pero estoy perfectamente de acuerdo con que el audio MP3 sea quizás un poco más grande. Lo que no estoy bien es la codificación de video u otra cosa que le dé a este códec una licencia para transmitir datos en ~200 kb/s, kilobits, incluso si eso es a 4 veces la velocidad, 50 kb/s sigue siendo demasiado si el la carga útil va con menos de 1 kb/s.
Por cierto, esa imagen de título JPEG tiene un tamaño de 170 kB. Si solo pongo una nueva copia de i-frame de clave completa cada minuto, obtendría 10 MB para la carga útil de "video", no 60 MB. Entonces, algo está muy mal con estos códecs o la forma en que están parametrizados.
Hay un par de cosas que aún puede sintonizar en el codificador x264 como se muestra aquí , pero también en el decodificador de mp3 como se muestra aquí si está de acuerdo con una tasa de bits de audio más baja. Mi suposición es que el video no se come todo.
Yo he tratado
ffmpeg -loop 1 -y -i image.jpg -i audio.ogg -shortest -acodec mp3 -qscale:a 7 -vcodec libx264 -preset ultrafast -tune stillimage -maxrate 5K -bufsize 100K -crf 25 -pix_fmt yuv420p -g 100000 result5.mp4
y obtuve un archivo de video que tenía la mitad del tamaño del archivo ogg.
Esto es lo que hacen los parámetros y cómo usarlos:
-maxrate 5K -tamaño buf 100K
esto tiene un impacto directo en la tasa de bits del video. Bajé los valores hasta que recibí mensajes de subdesbordamiento de VBV y luego los volví a subir. La calidad del jpeg era muy baja, pero mejoró cuando aumenté el tamaño de buf.
-qescala:a 7
Esto produce una transmisión de audio de 100 kbit que estuvo más que bien para mi muestra.
En pocas palabras, es posible que deba modificar un poco estos parámetros para mejorar las cosas. Sospecho que en realidad es el audio en su caso el que consume una gran parte.
Déjame saber si funciona.
No estoy seguro de las distribuciones de audio y video de flujo de salida, supongamos que el tamaño de salida está ocupado principalmente por el video ES.
En la era H.266, x265 no es un códec nuevo
!ffmpeg -y -i https://github.com/Matroska-Org/matroska-test-files/raw/master/test_files/test5.mkv -c:v libx265 -an VideoOnly_265.mp4
El tamaño de archivo de VideoOnly_265.mp4 es
-rw-r--r-- 1 raíz raíz 4283630 7 de septiembre 12:38 VideoOnly_265.mp4
!ffmpeg -y -i https://github.com/Matroska-Org/matroska-test-files/raw/master/test_files/test5.mkv -c:v libx264 -an VideoOnly_264.mp4
El tamaño de archivo de VideoOnly_264.mp4 es
-rw-r--r-- 1 raíz raíz 10956223 7 de septiembre 12:33 VideoOnly_264.mp4
jason conrado
Gunther Schadow
jason conrado
Abel