Использование -ss в качестве параметра ввода вместе с -c:v копирование может быть неточным, поскольку ffmpeg вынужден использовать / разбивать только на i-кадрах. Хотя это - если возможно - отрегулирует время начала потока к отрицательному значению, чтобы компенсировать это. По сути, если вы укажете "второй 157", а ключевой кадр не будет до второго 159, он будет включать в себя две секунды звука (без видео) в начале, а затем начнется с первого ключевого кадра. Поэтому будьте осторожны при разделении и копировании кодеков.
Чтобы избежать этого, я сначала попытался найти временные метки фреймов, необходимых для -ss и -to создав плитку из всех близлежащих фреймов. Я сгенерировал плитки используя
ffmpeg -i "INPUT.mkv" -ss 09:55 -t 3 -vf "drawtext=fontfile=I\\:\Misc\\\\~Software\\\\~OS\\\\I386\\\\arial.ttf: fontsize=60: text='F%{n}\(%{pict_type}\)\@%{pts\:hms}': x=(w-tw)/2: y=h-(2*lh): fontcolor=white: box=1: boxcolor=0x00000000@1,scale=320:-1,tile=layout=12x10" tiles%03d.png
и в соответствии с ними необходимый ключевой кадр должен начинаться с 00:09:56.012, а последний необходимый кадр должен быть в 00:10:00.224. Тем не менее, фрагмент, созданный при вырезании с этими временными метками
ffmpeg -i "INPUT.mkv" -map 0:0 -map 0:4 -map 0:5 -map 0:6 -ss 09:56.012 -to 00:10:00.224 -vcodec copy -acodec copy J01.mkv
начинается с неключевого кадра (только звук) и заканчивается не в том месте. Напротив, обрезка одного и того же фрагмента в Avidemux работает нормально, даже если для настроек вывода видео и аудио установлено значение Copy (IIUC, перекодирование не требуется и запуск с кадра без ключа). Отображаемые метки времени в Avidemux также различаются (-ss 09:56.346 -to 10:00.558 и -ss 09:56.012 -to 10:00.224).
Я также пробовал резать по pkt_dts_time (https://stackoverflow.com/questions/14005110/), но это тоже не сработало.
п.с. Другая процедура, аналогичная той, что я пытаюсь сделать (для вышеупомянутого Avidemux), - когда в Sony Vegas вы увеличиваете временную шкалу, пока не можете переходить от одного кадра к другому, а затем устанавливаете первый кадр после смены сцены (что также является ключевым кадром). ) в качестве начальной точки и последнего кадра той же сцены (после которого следует следующий ключевой кадр, который не нужен) в качестве конечной точки, а затем рендеринга. Нечто подобное можно сделать и в Avidemux, одновременно копируя видео и аудио потоки.
edit1: вот журнал для версии -copyts : pastebin. com /Cxzrc8Er. Должен ли я делать другие, а?
edit2: Вот результаты для "PATHTO\ffprobe.exe" -select_streams v -show_entries packet=pts_time,flags -of compact -read_intervals 580%600 "INPUT.mkv" | findstr K
packet|pts_time=578.160000|flags=K
packet|pts_time=581.205000|flags=K
packet|pts_time=583.499000|flags=K
packet|pts_time=585.042000|flags=K
packet|pts_time=588.671000|flags=K
packet|pts_time=594.885000|flags=K
packet|pts_time=596.012000|flags=K
Я также попробовал всю комбинацию команд (плитки, перечисление кадров таким образом, разрезание фрагмента двумя различными способами) на двух других видео, и результаты схожи. Время ключевого кадра, указанное в терминале с использованием предложенной вами команды, совпадает с указанным в тайлах; и, как правило, вырезание по моему методу оставляет небольшой замороженный участок (~ 1 с) в начале и иногда несколько нежелательных кадров в конце, а вырезание по вашему методу оставляет более длинный пустой видеопоток в начале.
Я также нашел лучший фрагмент видео для экспериментов, потому что визуально легче определить, сколько искомых кадров пропущено, а нежелательных добавлено (imgur.com /a /DTzmt, соответствующую часть можно загрузить с сайта bit.ly). /Kmnz112f1). Ваше решение сработало лучше и на нем.
Кроме того, просто чтобы убедиться: Вы имели в виду -ss 09: 56.01 3, а не -ss 09: 56.01 2 в исходном решении? И правильно ли я догадываюсь, что это обычно работает на видео, которые вы режете, и что это не работает на моем, необычно?