comandos - comprimir video ffmpeg
¿Cómo extraer segmentos de video con precisión de tiempo con ffmpeg? (4)
Esta no es una zona de preguntas particularmente nueva, pero probé lo que allí se sugirió sin mucha suerte. Entonces, mi historia
Tengo una gran cantidad de 15 segundos de video straight-from-camera.mov de los cuales quiero extraer un fragmento específico, que puedo identificar por hora de inicio y de detención, en segundos. Empecé tratando de hacer lo que llamaré una "extracción de copia": para obtener segundos del 9 al 12,
ffmpeg -i test.mov -vcodec copy -acodec copy -ss 9 -to 12 test-copy.mov
Este no fue un mal comienzo, pero hay algunos cuadros negros al principio y al final del clip, que no puedo tener: tiene que ser una edición limpia del original. Por lo tanto, traté de recodificar el original en un nuevo clip recortado:
ffmpeg -i test.mov -ss 00:00:09 -t 00:00:03 test-out.mov
Esto es mejor, pero no del todo: ya no hay marcos negros al principio del clip, pero todavía están allí al final.
Después de un poco más de navegación y lectura, entonces sospeché que el problema es que ffmpeg está teniendo problemas para encontrar los puntos adecuados debido a la falta de fotogramas clave en el video original. Así que grabé el video original para (supuestamente) agregar fotogramas clave, en un par de formas diferentes. Como quiero poder elegir video en límites de un segundo ("de 9 segundos a 12 segundos"), intenté, copiando varias sugerencias en la web,
ffmpeg -i test.mov -force_key_frames "expr:gte(t, n_forced)" test-forced.mp4
y
ffmpeg -i test.mov -g 1 test-g-inserted.mp4
(Construí estos como mp4 en base a algunos comentarios sobre un contenedor mp4 que se necesita para respaldar la búsqueda de fotogramas clave, pero honestamente estoy pirateando aquí.) Luego probé la extracción como antes, pero en estos nuevos videos que presumiblemente ahora tienen fotogramas clave en ellos. Sin suerte, ambos parecen ser lo mismo; el inicio está bien, pero todavía hay cuadros negros al final. (FWIW, test-forced.mp4 y test-g-inserted.mp4 también tienen tramas negras finales).
Entonces: todavía estoy atrapado, y me gustaría no estarlo. ¿Alguna idea de lo que estoy haciendo mal? Siento que estoy cerca, pero realmente necesito deshacerme de esos tramas negras que se arrastran ...
Creo que el problema que tienen la pregunta y otras respuestas es que están usando -ss como una opción en el archivo de salida, no en el archivo de entrada. La mayoría de las opciones de ffmpeg no son globales, sino que solo se aplican al archivo que preceden. A menudo no es obvio dónde debe ir una opción, por lo que a veces se requiere prueba y error.
Usado correctamente, antes del archivo de entrada al que deben aplicar, -ss y -t funcionó bien para mí. Al incluir el audio en la salida, tuve que usar el más -shortest como una opción para el archivo de salida, o recibí 2 minutos de audio con 2 segundos de video.
Versión ffmpeg N-67413-g2a88c74 (básicamente fuente git del 14 de diciembre de 2014)
Aquí hay una línea de comando que usé para hacer un clip recientemente. (Realmente retocado para ser un mejor ejemplo, ya que me fui en audio para esto, y no lo hice de forma remota).
ffmpeg -ss 120.2 -t 0.75 -i ../mcdeint.60p.lossless264.slow.mkv -c:a libopus -shortest -aspect 16:9 -preset veryslow -x264-params nr=250:ref=6 -crf 22 -movflags +faststart clip2.mkv
Con -c:a copy (la fuente tiene audio AC3), la reproducción comienza wonky con mplayer. Probablemente toma audio desde el comienzo del cuadro de audio que contiene el inicio, y luego tiene que usar un desplazamiento aa / v en el contenedor. Al arrancar, el audio tarda una fracción de segundo en adelantarse al video con ese desplazamiento, y hasta entonces el video se reproduce a muy bajo nivel de FPS. Así que codifiqué el audio. Ni opus ni pcm_s16le pueden ir en mp4, así que usé un contenedor mkv para este ejemplo.
La fuente es una codificación x264 sin pérdida ( -qp 0 ) a partir de un yadif muy lento = 3: 1, mcdeint = 3: 1: 10 (en algunos videos BFF entrelazados de un DVD NTSC, probablemente desde una cámara DV). NO es todo lo I encuadro, es P cuadros con un intervalo de fotograma clave normal.
Al ajustar -ss en 0,2 segundos, hice exactamente lo que esperaba, así que ffmpeg debe manejar la decodificación hasta el punto requerido. No fue solo una coincidencia de un cuadro donde quería uno. Quizás -accurate_seek es el predeterminado? También obtengo el mismo resultado (salida gif idéntica byte-by-byte) que cuando uso una fuente ffvhuff sin pérdidas como entrada. (pero funciona más rápido, ya que no tiene que decodificar hasta el punto solicitado).
Otra opción posiblemente relevante es -seek2any , pero dice "buscar sin fotogramas clave en el nivel de demuxer", que suena como si le permitiera buscar de forma que produciría una salida ilegible. (es decir, comenzar a decodificar sin generar realmente las referencias que requiere el marco actual, simplemente use todo gris?)
No he intentado usar la -c:v copy , ya que estoy recortando un clip muy corto para hacer un ciclo, así que sé que no habrá marcos donde los necesite.
Esta es la línea de comando que realmente utilicé, para hacer un clip de cámara lenta corta sin sonido.
ffmpeg -ss 120.2 -t 0.75 -i ../vid.yadif3.1,mcdeint3.1.10.ffvhuff.mkv -an -shortest -aspect 16:9 -c:v libx264 -preset veryslow -x264-params nr=250:ref=6 -crf 22 -filter:v "setpts=3.0*PTS" -movflags +faststart -r 20 clip.mp4
Tenga en cuenta que el -r 20 era importante, porque a diferencia de mkv, la salida MP4 de ffmpeg es constante-frame-rate-only (edit: porque -vsync vfr no es el predeterminado con el mp4 muxer). Sin decirlo diferente, establecería el FPS de salida = FPS de entrada, y marcos duplicados cuando sea necesario para que eso suceda. x264 y el gif animado (con transparencia) pueden codificar cuadros duplicados de manera muy eficiente, pero sigue siendo una tontería.
Antes de cocinar esto como ejemplo, lo había hecho en 2 pasos, uno de salida a mkv, luego ffmpeg -i clip.mkv -c:v copy -movflags +faststart -r 20 clip.mp4 a remix. Por cierto, es posible cambiar los fps de un video cuando remixing, sin xcodificación, simplemente no con ffmpeg. https://superuser.com/questions/740196/reducing-video-size-with-avconv-why-does-the-size-increase . Pero de todos modos, ffmpeg solo envió 45 fotogramas a libx264 cuando hacía el mkv, aunque creía que estaba haciendo un video de 2.2 segundos a 60 fps. No use ffmpeg con mp4 para trabajar con cosas FPS variables.
editar: resulta ffmpeg se predetermina a -vsync vfr para salida mkv, pero no para mp4. Con -vsync vfr , ffmpeg puede escribir VFR en la salida mp4 sin problemas.
Y de nuevo para salida gif, en caso de que decida no ponerlo con video HTML5 ( <video controls autoplay loop> <source src="clip.mp4" type="video/mp4"> </video> )
ffmpeg -ss 120.2 -t 0.75 -i ../vid.yadif3.1,mcdeint3.1.10.ffvhuff.mkv -an -shortest -aspect 16:9 -filter:v "setpts=3.0*PTS,scale=854x480" -r 20 clip.gif
Tuve que usar scale= porque el contenedor gif no almacena una relación de aspecto, por lo que no se puede escalar automáticamente en la reproducción. (mi video de 720x480 píxeles de 16: 9 se escala a 854x480 en la reproducción. En realidad debería ser 853.333, pero eso se redondea, y luego ffmpeg almacena 853x480 en el contenedor de mkv, por lo tanto, usa -aspect 16: 9 todo el tiempo, por lo que mi mp4 almacenar la relación de aspecto adecuada [SAR 32:27 DAR 16:9] , en lugar de [SAR 186:157 DAR 279:157] )
Me gustaría saber también. Hasta ahora he convertido mis videos sin pérdida, he extraído un segmento y los he recodificado después de la edición:
ffmpeg -i input -ss 9.48 -t 3.52 -c:v libx264 -crf 0 -g 1 -c:a copy TempIframe.mp4
Pero este es un proceso lento y con pérdida de tiempo ...
He intentado lo siguiente sin éxito:
ffmpeg -i source.mp4 -ss 1 -c:v copy -seek2any 1 -avoid_negative_ts 1 -safe 1 -c:a copy segment.mp4
No es necesario agregar fotogramas clave; como dice Peter, es simplemente una cuestión de obtener las opciones en el orden correcto. Sin embargo, consulte https://trac.ffmpeg.org/wiki/Seeking para obtener la guía oficial definitiva sobre cómo hacerlo bien.
Ok, en primer lugar, suponiendo que conoces la duración de inicio y finalización; agregaremos cuadros clave a esa duración.
ffmpeg -i a.mp4 -force_key_frames 00:00:09,00:00:12 out.mp4
La mayoría de las veces puede cortar directamente el video con perfección, pero en su caso no lo ayuda; así que lo hemos solucionado por orden superior. Tenga cuidado al no agregar demasiados marcos clave, ya que puede ser un problema durante la codificación según los documentos de Ffmpeg .
Ahora puede volver a intentar cortar el video de una hora específica.
ffmpeg -ss 00:00:09 -i out.mp4 -t 00:00:03 -vcodec copy -acodec copy -y final.mp4
Esto resolverá el problema ya que hemos agregado los fotogramas clave manualmente en los puntos de inicio y fin del corte. Funcionó para mí
Aclamaciones.:)