Задание параметров для создания видео для демультиплексора concat ffmpeg (чтобы избежать большого перекодирования)

1483
bertieb

ffmpegможет использоваться для объединения файлов вместе :

Если у вас есть медиа-файлы с одинаковыми параметрами кодека и кодека, вы можете объединить их [...]

(выделение мое) Мое намерение 1 состоит в том, чтобы создавать мультимедийные файлы с тем же кодеком и параметрами, чтобы я мог воспользоваться преимуществами concat, не подвергаясь длительному перекодированию.

Преамбула:

У меня есть файл, который я хотел бы вырезать и сохранить полезные части. Я написал скрипт на python, чтобы найти ближайший ключевой кадр к желаемой точке вырезания и вырезать там, так как при выполнении потоковой копии ffmpeg может использовать только I-кадры:

Использование -ss в качестве параметра ввода вместе с -c: v копирование может быть неточным, поскольку ffmpeg вынужден использовать / разбивать только на i-кадрах.

Как это происходит, расколы не происходят в точно нужный момент, но достаточно близко для того момента, когда я могу сосредоточиться на другую часть уравнения. Если я использую concatдемультиплексор на этом этапе, различные части будут идеально объединены вместе - пока все хорошо!

Однако я хотел бы, чтобы между этими сегментами были плавные переходы, поэтому я дополнительно разделил эти сегменты, чтобы короткие переходы можно было использовать для создания перехода с плавным переходом без перекодирования всего набора файлов.

Базовая диаграмма, вероятно, поможет проиллюстрировать это:

 [111AAAA111BBBBB111111CCCCCCC1111DDDDD111] | (original file) [AAAA] [BBBBB] [CCCCCCC] [DDDDD] | (desired clips extracted) [AAA] [A][B] [BBB] [B][C] [CCCCC] [C][D] [DDDD]| (split ends from clips) [AAA][ab][BBB][bc][CCCCC][cd][DDD] | (transitions between short ends) [AAAabBBBbcCCCCCcdDDD] | (intended output) 

Проблема:

Вот куда я попал. Когда я ffmpeg«s concatдемультиплексора присоединиться клипы выше я получаю значительное видео и аудио артефактов при воспроизведении. Я предполагаю, что есть несоответствие в параметрах кодека, как отмечено как обязательное условие наверху этого вопроса. Итак, проверка видео ffprobeдает:

$ ffprobe -i ab-transition.mkv 2>&1 | grep Stream.*Video ; ffprobe -i B.mkv 2>&1 | grep Stream.*Video Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709/bt709/iec61966-2-1), 1280x720, SAR 1:1 DAR 16:9, 62.50 fps, 62.50 tbr, 1k tbn, 120 tbc (default) Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709/bt709/iec61966-2-1), 1280x720 [SAR 1:1 DAR 16:9], 62.50 fps, 62.50 tbr, 1k tbn, 125 tbc (default) 

(Я пропустил вывод аудиопотока, так как потоки имеют якобы одинаковые параметры, но звук не соединен правильно)

Есть отличия. Я использовал -show_streamsдля получения более подробной информации, которая доступна по адресу http://pastebin.com/4vcnDYtj (одна пустая строка, разделяющая 2 выхода). diffВ результате выдается:

7c7 < codec_time_base=1/120 --- > codec_time_base=1/125 70,71c70,71 < start_pts=12 < start_time=0.012000 --- > start_pts=11 > start_time=0.011000 

Обновить:

Я нашел параметры и подходящие параметры для всего, что я вижу, кроме временной базы кодека (tbc). Есть ли настройка, которая позволит мне установить codec_time_base (tbc) ? Настройка не -rимеет никакого эффекта.

Обновление 2: опасаясь, что этот вопрос будет слишком нишевым для SU, я задал вопрос о списке рассылки ffmpeg-user. К сожалению, -time_baseв этом случае не подходит опция кодировщика:

Это опция для внутренних кодеров FFmpeg, которые вы пытаетесь использовать для внешнего кодера (x264).

И еще, к сожалению, когда я спросил об общей осуществимости, ответ был

Я не думаю, что это возможно.

Я попросил разъяснений и возможностей, связанных с оригинальным программным обеспечением для кодирования - в данном случае OBS- которое потенциально менее гибко в спецификации опций, чем ffmpegиз-за необходимости соответствовать спецификациям потребительского формата живого потока (Twitch). Я еще не получил ответ из списка рассылки, но спрашивал и на форумах OBS.

Что еще более важно, позволит ли контроль за ними разрешить мне использовать concatдемультиплексор, ffmpegчтобы объединить их без необходимости длительного процесса кодирования ? Спасибо заранее.

(Я понимаю, что это текстовая стена, поэтому дополнения, вычитания или уточнения, конечно, приветствуются. Я бы дал ссылку на более официальную информацию, но, будучи <10 представителей, я не могу включить более 2 ссылок! )


1 : Для получения дополнительной информации см. Мой связанный вопрос: как эффективно и автоматически объединять видеоклипы с помощью коротких переходов?

2
Пока не сдаюсь. ;-) Я понимаю, что это противоречит вашим намерениям, но пытались ли вы выполнить последнюю операцию concat с кодировщиками вместо копий кодеков, чтобы посмотреть, устраняет ли это артефакты a / v? По крайней мере, не могли бы вы опубликовать полные команды ffmpeg, которые вы используете для генерации клипов и переходов? Mr. What 8 лет назад 1
@ Мистер. Что рад это слышать? Я задавал вопросы повсюду (согласно обновлению). Использование параметров кодека приведет к окончательному транскодированию; но следует устранить артефакты, как вы говорите. Я почти уверен, что проверил это за многие часы, которые я провел! Я могу опубликовать команды наверняка, но переходы генерируются с помощью melt (MLT) согласно моему другому (связанному) вопросу. Кажется, никто из тех, кого я спрашивал, не может изменить время; даже если я займусь этим со стороны источника (OBS), параметр x264 -time_base там игнорируется! bertieb 8 лет назад 0
Более подробно изучив документацию, можно найти фильтр [`урегулирования`] (http://ffmpeg.org/ffmpeg-all.html#settb_002c-asettb), который стоит попробовать, поскольку он будет применяться вне кодировщика x264 - - `ffmpeg input.ext -vf" урегулирование = expr = 1/125 "-c: v libx264 и т. д. output.ext`. Или это уже упоминалось / испытывалось в ваших путешествиях до сих пор? Mr. What 8 лет назад 1
@ Mr.What Этот фильтр выглядел многообещающе, но транскодирование файла с временной базой 125 не могло привести к желаемой временной базе 120 (или любой другой), даже если он сильно жаловался на * «Прошлая длительность 0,874992 (и т. Д.) Слишком большая» *: - / Хорошие мысли, хотя! Сюжет еще более утолщается, так как при подсчете рук исходные файлы при воспроизведении воспроизводят 60 кадров в секунду (не 62-63). Не уверен, что это из-за временной задержки, заставляющей игрока игнорировать кадры. Глубоко в кроличью нору! bertieb 8 лет назад 0
Что ж, странный FPS и временная база совпадают с копированием кодека для вывода ваших непереходных клипов, так что здесь нет ничего удивительного. Мне интересно, может ли включение `-copyinkf` (которое будет включать ведущие не ключевые кадры в выводе` -c copy`) помочь в конечном конкатате, а также, если оно того стоило бы заставить закодированный переходный клип пройти через рациональная частота кадров через `libx264`. В качестве эксперимента попробуйте воссоздать ваши клипы "a" и "b", используя `-copyinkf -c: v copy -c: a copy`, trans. обрезать с помощью `libx264 -r 60`, затем объединить эти три и посмотреть, есть ли разница. Mr. What 8 лет назад 0
@bertieb Вы уже нашли свой ответ? Или это невозможно! Я сталкиваюсь с аналогичной проблемой, когда из-за изменения размера одного из клипов возникает необходимость перекодировать их все только для того, чтобы правильно их объединить. Rohan 8 лет назад 0
@ Рохан да и нет. Я работал над этим, меняя переходы, которые я создавал, - переход от черного к черному, а не к постепенному исчезновению, - но это позволяет избежать проблемы, а не заниматься ею. Я нашел параметр в `ffmpeg`, который контролировал сообщаемую временную базу (немного отличается от ответа` -time_base` ниже!), Но он не дал нужного эффекта в любом случае: - / bertieb 8 лет назад 0

1 ответ на вопрос

1
Mr. What

According to the generic codec options, you can add -time_base to the libx264 encoder set during the creation of the transitional clips.

If I'm reading your file comparisons correctly -- ab-transition.mkv is showing a tcb of 1/120 while B.mkv is showing 1/125 (which is the value you want, right?) -- I'd suggest including an -r value in as well to make certain that both the framerate and time base are maintained:

-c:v libx264 [preset & crf/qp settings] -r 62.50 -time_base 1/125 [output] 

As a side note, I would like to mention that my own attempts at using the concat demuxer without fully re-encoding the output file(s) has always resulted in problems, chiefly audio sync and frame drops. Best results have come through encoding separate clips with lossless audio and video to preserve the original quality...

-c:v -libx264 -preset ultrafast -qp 0 -c:a pcm_s16le 

...then encoding the final file using the same audio/video settings used to create the source video(s).

@ mr-что спасибо за ответ, и вы думаете в том же духе, что и я. К сожалению, ни `-time_base`, ни` -r` не дают нужного эффекта - я обновлю ОП с более подробной информацией. bertieb 8 лет назад 0

Похожие вопросы