Мой вывод ffmpeg всегда добавляет лишние 30 секунд тишины в конце

Это код / ​​аргумент, который я использую для объединения 1 аудио и 1 изображения в 1 видео. По какой-то причине он добавляет 30 секунд тишины к концу выходного видео независимо от источника.

Я запускаю это на Win10 x64 с установленной последней версией ffmpeg. Я проверил код, но не могу определить, где происходит тишина.

ffmpeg -y -loop 1 -framerate 2 -i "some.png" -i "with.mp3" 
-c:v libx264 -tune stillimage -c:a aac -b:a 192k -pix_fmt yuv420p -shortest "result.mkv"

Вывод не должен содержать дополнительных 30 секунд тишины. Он должен закончиться, когда закончится звук.

Я должен добавить, что я скопировал большинство аргументов с какого-то веб-сайта, и этот OP, похоже, прекрасно его использует, поэтому я не уверен, что это только моя проблема.


windows ffmpeg albumart
person Thomas K    schedule 22.04.2019    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Использовать

ffmpeg -y -loop 1 -framerate 2 -i "some.png" -i "with.mp3" -c:v libx264 -tune stillimage -c:a aac -b:a 192k -pix_fmt yuv420p -shortest -fflags +shortest -max_interleave_delta 100M "result.mkv"

Контейнеры (AVI, MP4, MKV) обычно хранят несколько потоков с чередованием, то есть несколько секунд видео, затем несколько секунд аудио и так далее. Таким образом, ffmpeg буферизует данные из всех потоков при записи.

-shortest действует на относительно высоком уровне и запускается по завершении первого из потоков. Однако буферизованные данные из других потоков все равно будут записаны в файл. -fflags shortest действует на более низком уровне и останавливает запись буферизованных данных при использовании с достаточно высоким значением max_interleave_delta.

person Gyan    schedule 23.04.2019
comment
Безопаснее добавлять + в случае, если ffmpeg устанавливает свои собственные флаги. - person Gyan; 03.05.2020

arrow_upward
1
arrow_downward

Когда у вас слишком низкая частота кадров, что возникает соблазн сделать при объединении звука с изображением "постера", ffmpeg сталкивается с проблемами.
Время вывода оказывается неверным. У меня все еще было неправильное время вывода с «-shortest -fflags + short -max_interleave_delta 100M» (хотя это улучшило его), поэтому мне пришлось сократить вывод с помощью команды «-t».

А затем, если вы возьмете результат и скопируете его с помощью "ffmpeg -i output.mp4 output-copy.mp4", это вызовет следующую проблему: "https://trac.ffmpeg.org/ticket/6375?Cversion=0"
(

Too many packets buffered for output stream 0:1.  
[aac @ 0x7ffda6818c00] Qavg: 65179.457  
[aac @ 0x7ffda6818c00] 2 frames left in the queue on closing

)
Что решается с помощью "-max_muxing_queue_size 9999" (до вывода, после ввода)

И опять же, если вы установите fps (или «-r») выше, все проблемы исчезнут.

Глядя на документ ffmpeg для "max_muxing_queue_size", я понял:

-max_muxing_queue_size пакетов (вывод, на поток)

При перекодировании аудио- и / или видеопотоков ffmpeg не начнет запись в вывод, пока не получит по одному пакету для каждого такого потока. Пока это произойдет, пакеты для других потоков буферизуются. Эта опция устанавливает размер этого буфера в пакетах для соответствующего выходного потока.

Я думаю, что ffmpeg должен захватывать один видеокадр и много звуковых кадров одновременно, поэтому ему необходимо одновременно буферизовать много звуковых кадров, и он не привык к этому, он используется для ... буферизации 1/30 (для 30 кадров в секунду) этих аудиокадров, соедините их с видеокадром и двигайтесь дальше. Может быть.

Я думаю, что ffmpeg должен работать, чтобы это было более плавно, может быть ... но idk, может быть, вам просто нужно раз и навсегда прочитать всю документацию ffmpeg.
Может быть, добавьте подсказку, "буфер мультиплексора должен быть увеличен, обнаружен, хотите чтобы поднять его? чтобы предварительно установить это, см. документацию для "max_muxer (etc)" ".
Я не знаю, почему существует неправильное время вывода, но что-то похожее.

person Debrune e brune    schedule 16.06.2020