У меня есть несколько видеозаписей с каналов IPTV Full HD, которые я сохранил с помощью VLC. Эти дампы потока хранятся в виде файлов MPEG-TS и содержат видео в кодировке AVC со звуком MPEG.
Я хотел бы извлечь из этих записей определенные клипы, основываясь на точках отсечения с точностью до кадра. Однако мне сложно определить точные отметки времени в миллисекундах, которые мне нужно передать FFMPEGс -ss и -to параметры для точного попадания в нужные мне точки. Вот что я пробовал до сих пор:
Попытка 1
Моя первая попытка заключалась в том, чтобы загрузить .ts файлы в Авидемукс поскольку он обеспечивает удобный покадровый поиск и отображает временную метку текущего кадра с необходимой точностью. Однако, если я поставлю метку времени кадра, к которому стремился (в формате HH:MM:SS.mmm) в FFMPEG параметры, обрезка будет фактически отключена на несколько кадров, иногда более чем на секунду. Дрейф всегда разный и может быть положительным или отрицательным.
Затем я заметил, что для большинства этих записей первый кадр Авидемукс на самом деле показывает отметку времени, которая не равна нулю (например, 00:00:00.280 или даже 00:00:00.216). Я предполагал, что VLC немедленно начинает запись, но Авидемукс игнорирует все до первого I-кадра. Я все еще удивляюсь такой отметке времени, как 00:00:00.216хотя, потому что это видео со скоростью 25 кадров в секунду, а 216 даже не кратно 40 мс.
Попытка 2
Я попробовал двухпроходный процесс, в котором я закодировал видео один раз, начав кодирование немного раньше, чем нужно, и заканчивал его чуть позже желаемого конца. Я бы тогда использовал Авидемукс для подсчета лишних кадров в начале и в конце видео, а также для перемещения точек вырезания на nFrames * 40 ms внутренности. Однако результаты были Все еще неточно, это привело бы меня к тому, что иногда я сокращал видео слишком мало кадров, иногда слишком много.
Теряя доверие к Авидемуксточность отметки времени или, по крайней мере, вывод о том, что некоторые вычисления выполняются иначе, чем FFMPEG, Я подумал, что самым безопасным способом будет использовать тот же инструмент для определения точек вырезания, который я также использую для фактического вырезания видео.
Попытка 3
Я попытался извлечь отдельные кадры вокруг желаемых точек разреза с помощью FFMPEG, используя тот же -ss и -to параметры, которые я использую для обрезки видео, но выбираю только диапазон, близкий к желаемым точкам вырезания, и записываю кадры в файлы изображений. Я бы также использовал фильтр, чтобы записывать точную временную метку каждого кадра, как определено FFMPEG, прямо в картинку. Таким образом, я мог просто считывать желаемые точки разреза и использовать их для фактического кодирования. Моя командная строка будет выглядеть примерно так:
ffmpeg.exe -i input.ts -ss 00:00:29.000 -to 00:00:31.000 -vf drawtext=fontfile=roboto.ttf:fontsize=40:text="%{pts:hms}":fontcolor=white@0.75:x=10:y=10 image%03d.png
Затем я бы нашел точный PNG, в котором я хочу, чтобы был вырезан, посмотрел на метку времени, и если бы она сказала 00:00:30.160, это будет метка времени, которую я бы использовал для -ss фактического разреза.
Однако это Все еще не сработало, и мои точки вырезания все еще на несколько кадров раньше или позже извлеченных PNG. Так меняется FFMPEGвывод из видео в изображения, кажется, влияет на то, как рассчитываются временные метки, потому что они не совпадают!
До сих пор я не нашел способа избежать необходимости выполнять длительный процесс двоичного поиска, чтобы вручную приблизиться к точным временным меткам, на которых должны быть сокращения, что особенно обременительно, потому что я могу получить только нужные мне временные метки, выполнив «полное декодирование» ищет «(т. е. используя -ss после входного параметра, а не до), и поиск позиции может занять много времени после нескольких часов записи.
Как мне найти временную метку, которая нужна для точного кадрирования из FFMPEG в транспортном потоке MPEG без необходимости многократно декодировать, вырезать и сохранять сегменты видео, чтобы вручную продвигаться к ним?
Здесь Медиа информация на одной из записей, если она содержит какие-либо подсказки о чем-то странном с самими потоками:
General
ID : 1 (0x1)
Complete name : C:Users…vlc-record-2021-03-09-00h23m11s.ts
Format : MPEG-TS
File size : 2.31 GiB
Overall bit rate mode : Variable
Video
ID : 256 (0x100)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference frames : 4 frames
Codec ID : 27
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Audio
ID : 257 (0x101)
Menu ID : 1 (0x1)
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 2
Codec ID : 3
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Compression mode : Lossy
Delay relative to video : -248 ms
Menu
ID : 4096 (0x1000)
Menu ID : 1 (0x1)
List : 256 (0x100) (AVC) / 257 (0x101) (MPEG Audio)
Service name : Service01
Service provider : FFmpeg
Service type : digital television