Однажды я вырезал сорока секунды из интервью, бросил его в колоду и наблюдал, как динамик начинает наступление на полную кампанию за семь секунд до того, как я хотел. Я тщательно настроил начало. Триммер проигнорировал меня, по крайней мере, так оно выглядело. Это не так: он сделал единственное, что может сделать быстрая резка, которая начинать с ближайшего ключевого кадра до того, как я просила. Как только вы это узнаете, поведение перестает быть ошибкой и становится выбором с двумя вариантами, и выбор правильного занимает секунду.
TL;DR: Быстрая обрезка копирует существующий видеопоток, а не перекодирует его, а копия может начинаться только с ключевого кадра. Попросите начать в 0:07 с файла, чьи ключевые кадры находятся на десяти секундах, а обрезка начинается в 0:00, потому что это последняя точка, с которой может начать декодер. Конец приземляется там, где вы просили, только начало дрейфует, и оно дрейфует задом наперед. Исправление, когда вам нужна точная рамка, — это перекодировать, что медленнее и стоит немного качественных. выше видеотриммер Предлагает оба и по умолчанию для быстрого.
Почему обрезка начинается раньше, чем вы просили?
Потому что почти ни один кадр в видео не является полной картинкой.
Сжатие видео работает, сохраняя один полный кадр, а затем описывая изменения. ключевой кадр, правильно кадр IDR в H.264, держит целый образ и ни от чего не зависит. Рамки после того, как он сохраняет различия: этот блок сместился на четыре пикселя, эта область не изменилась, эти пиксели стали немного темнее. Кадр на полпути к этой последовательности сам по себе бессмысленен, то, как diff бессмысленен без файла, к которому он относится.
Поэтому, когда вы просите начать в 0:07, а инструмент копирует поток без его декодирования, копировать нечего. Есть описание того, чем 0:07 отличается от чего-то раньше. Единственные места, где игрок может начать, — это ключевые кадры, и единственным безопасным является последний ключевой кадр или до вашей начальной точки.
Альтернатива состоит в том, чтобы расшифровать видео до 0:07, выбросить то, что было раньше, и сжать то, что осталось, в новый файл, который начинается со свежего ключевого кадра. Это точно, и это медленный путь, потому что он выполняет реальную работу на каждом кадре, а не копирует байты.
На каком расстоянии, на самом деле, ключевые кадры?
Кроме того, что большинство людей предполагает, и пробел решает, насколько неправильно выглядит быстрый разрез.
Я измерил его, а не гадал. Кодировка тридцати секунд тестового кадра с x264 по умолчанию, а затем перечисление ключевых кадров:
ffmpeg -f lavfi -i "testsrc=duration=30:size=640x360:rate=25" -c:v libx264 clip.mp4
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 clip.mp4 \
| awk -F, '$2 ~ /K/ {print $1}'
# 0.000000
# 10.000000
# 20.000000
Один ключевой кадр каждые десять секунд. Это по умолчанию 250 кадров между ключевыми кадрами x264, 25 кадров в секунду. В файле, закодированном с этими значениями по умолчанию, быстрая обрезка может начаться до десяти секунд до выбранной вами точки.
Большинство кадров, которые вы обрабатываете, более дружелюбны, потому что большая их часть была сделана для потоковой передачи, где игрокам нужны частые точки входа для переключения. Вот диапазон, который стоит знать:
| Источник | Типичный зазор в ключе | Дрейф в худшем случае на быстром разрезе |
|---|---|---|
| Запись телефона | от 1 до 2 секунд | едва заметный |
| Потоковое видео, HLS или Dash | от 2 до 6 секунд | Заметно на коротком клипе |
| x264 или ffmpeg по умолчанию | 10 секунд со скоростью 25 кадров в секунду | разрушает короткий путь |
| Регистратор экрана, низкая съемка | 10 секунд и более | разрушает короткий путь |
Шаблон: все, что закодировано для игрока, имеет близкие ключевые кадры, а все, что закодировано для хранения, — нет.
Что делает дрейф с файлом?
Он перемещает начало и оставляет конец в покое, о чем стоит быть точным, потому что легко предположить, что все окно скользит.
Запрос того же клипа на 0:07 до 0:15, окно восьми секунд, с копией потока:
| просил | Ключевые кадры в источнике | Результат | Что случилось |
|---|---|---|---|
| 7 до 15 с | 0, 10, 20 | от 0 до 15,08 с | Начало падало обратно на ключевой кадр в 0 |
| 12-20-е годы | 0, 10, 20 | 10 с 20.08с | Старт упал обратно на ключевой кадр в 10 |
| 7 до 15 с | Каждые 2с | 6 с до 15.08с | Начало отступило на один ключевой кадр |
Конец во всех трех. Я проверил, что хэшированием кадров, а не доверием длительности: последний кадр вывода байт-идентичен исходному кадру через 15,04 секунды, что является кадром после того, что я просил, и правильное место для остановки. Что изменилось, так и начинается.
Поэтому файл длиннее выбранного вами окна. Сокращение, которое вы думали, что это восемь секунд, наступает как пятнадцать, не потому, что что-то перерасходилось, а потому, что появилось семь секунд вводного ввода. На клипе, где ключевые кадры находятся на расстоянии двух секунд друг от друга, тот же разрез составляет девять секунд, и никто не замечает.
Когда вместо этого нужно перекодировать?
Три случая, а за их пределами быстрый путь является лучшим инструментом.
Вам нужен определенный кадр. Нарезая слово, на жест, в тот момент, когда мяч бьет биту. Точность ключевого кадра недостаточно хороша, и никакой заботы о слайдере не поможет, потому что предел находится в файле, а не в интерфейсе.
Клип короткий. Семь секунды ввод на тридцать секунд — это неприятность. На четырехсекундном крое все дело в этом.
Вы вырезаете файл с разреженными ключевыми кадрами. Записи экрана и все, что экспортировалось один раз для архива, как показывают приведенные выше измерения.
Стоимость реальная, но меньше, чем люди боятся. Перекодировка декодирует каждый кадр в окне и снова сжимает его, поэтому требуется время, пропорциональное длине выреза, а не размеру файла, и он теряет генерацию качества. При постоянном коэффициенте 23, что и использует триммер для своего точного режима, эта потеря близка к невидимому на одном проходе. Это второй проход по кадрам, которые уже были сжаты один раз, что то же самое Потеря генерации, которая регулирует сжатие вообще.
Как найти ключевые кадры в своем файле?
Одна команда, и она заранее сообщает вам, будет ли быстрый путь.
# the first ten keyframe timestamps, in seconds
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 input.mp4 \
| awk -F, '$2 ~ /K/ {print $1}' | head -10
Если пробелы в одну или две секунды, быстро обрежьте и перестаньте думать об этом. Если их десять, и ваши сокращения имеют значение, повторно кодируйте.
Для этого есть второе применение. Если вы производите кадры, которые будут вырезать другие люди, кодирование с более коротким интервалом ключевого кадра значительно облегчает их жизнь при небольшой цене в размере файла. Ключевой кадр — это полное изображение, поэтому больше из них означает больше байтов, поэтому кодировщики размещают их, когда никто ничего не просит.
Обрезка теряет качество?
Быстрый путь не делает, в строгом смысле. Ничего не декодировано, поэтому ничего не сжимается повторно: кадры в выходных данных — это те же сжатые кадры, что были во входных, байтах для байтов, в новом контейнере. Обрезайте файл в десять раз таким образом, а десятая по качеству идентична первому.
Точный путь делает один раз. Окно декодируется и снова сжимается, поэтому оно улавливает одно поколение потерь. На хорошо закодированном источнике с разумной целью это трудно увидеть, и разумное правило состоит в том, чтобы сделать резать, который вам нужен, за один проход от оригинала, а не обрезать отделку.
Ни один из путей не увеличивает, не повышает или улучшает что-либо. Триммер снимает время, а это вся работа.
Почему мой обрезанный клип не начинает воспроизводиться сразу?
Из-за того, где приземляется индекс, и это тот же флаг, который имеет значение при сжатии.
MP4 содержит таблицу, описывающую, где начинается каждый кадр. Написанный в очевидном порядке, эта таблица заканчивается в конце файла, потому что кодер знает его содержимое только после завершения. Играл с диска, все в порядке. Подаваемый через HTTP, игрок не может запуститься, пока не придет весь файл.
Триммер проходит -movflags +faststart, который делает быстрый второй пас и перемещает эту таблицу на переднюю часть. Затем начинается воспроизведение, когда он загружается, что вам нужно, когда файл переходит в приложение чата, CMS или слайд, который извлекает его из URL-адреса.
Что происходит с аудио?
Звук вырезается на границах кадров, и они намного короче, чем интервалы видео, поэтому звук может начинаться ближе к вашей отметке, чем на картинке.
Это несоответствие является источником другой классической ошибки обрезки: клипа, звук которого немного опережает картину, или начинается с фрагмента слова. Исправление находится в аргументах, а не в редактировании, и триммер передает его: -avoid_negative_ts make_zero Перебазирует временные метки обоих потоков, так что выход начинается с нуля, при этом потоки все еще выровнены друг относительно друга. Без него потоковая копия может испускать отрицательные временные метки для кадров между ключевым кадром и вашей точкой отсечки, и игроки не согласны с тем, что с ними делать. Кто-то пропускает, кто-то останавливается, кто-то воспроизводит звук раньше.
Если вам нужен только звук, сначала вырезаем видео, а затем Извлечение звука это неправильный порядок. Извлеките сначала и вырежьте аудио, потому что звуковые сокращения точно по кадрам и дешевы.
А лучше в телефонном приложении обрезать?
Для быстрого личного клипа все в порядке, и это прямо здесь. Ни за что вы будете публиковать, нет, и причина не очевидна.
Редакторы телефонов обычно перекодируют при экспорте, и делают это с настройками, выбранными для скорости и предсказуемого размера файла, а не для Fidelity. Вы платите поколение потерь за каждую отделку. Хуже того, некоторые из них не деструктивно, сохраняя ваши входные и выходные точки в виде метаданных рядом с оригиналом, что выглядит как обрезка телефона и вовсе не является обрезкой, как только файл покидает его: получатель получает полный клип или список редактирования, который их проигрывает.
Обрезка режима копирования позволяет избежать обеих проблем. Файл, который вы получаете, — это файл, который все получают, и кадры в нем никогда не декодировались.
видео покидает мою машину?
нет , йо- Разрез проходит через ffmpeg скомпилирован в WebAssembly Внутри вкладки браузера: файл читается с диска в память страниц, обрезается и возвращается в качестве загрузки. Сетевая панель в DevTools остается пустой от видео, пока это происходит.
Для кадров это имеет большее значение, чем для большинства типов файлов. Клип обычно является самой большой и самой личной вещью, которую кто-либо редактирует, и обычное устройство для бесплатного онлайн-триммера заключается в том, что вы загружаете свои кадры незнакомцу и доверяете политике удержания на странице, которую не прочитали. Здесь не существует копии, которую нужно сохранить.
Ограничения — это скорее вкладки, а не план: один разрез ограничен тридцатью минутами, и весь источник должен поместиться в память браузера. Кроме того, инструмент для рабочего стола более быстрый и надежный, и лучше, чем вручить вам вкладку, на которой на девятой минуте не хватает памяти.
Когда настольный редактор является правильным инструментом?
Когда вы делаете больше, чем снимаете время. Соединяя несколько клипов, добавляя заголовки, цвет, музыку или вырезку на волне, которую нужно просмотреть на уровне образца. Это редакция, а не триммер, а правильный ответ — настоящий редактор.
В браузере разделительная линия почти так же чиста. Снять один кусок с одного клипа — это обрезка. Соединение частей вместе видеоредактор, йо- Уменьшение результата компрессор, а изменение контейнера или кодека преобразователь, что является Отличие от работы от сжатия Хотя они постоянно путаются.
Почему предварительный просмотр и экспортированный файл не согласны?
Поскольку интерфейс Trim собирает один и тот же номер из трех мест, которые не согласны с тем, что такое число, и перевод их в одно значение — это большая часть работы в триммере.
Текстовое поле дает вам все, что напечатал кто-то, что может быть 7, 0:07, 00:00:07 или 7.25, йо- Слайдер дает поплавок с большей точностью, чем кто-либо хочет. элемент видео's currentTime Дает еще один float, который вовсе не является временной меткой кадра: браузерам разрешено сообщать о позиции между кадрами, и они это делают.
Если эти трое приземляются на несколько разные секунды, предварительный просмотр показывает одно, а экспорт производит другое, а именно специфический баг, из-за которого триммер ощущается сломанным, даже если обрезка правильная. Здесь парсер принимает все три формы Timecode, разрешает их выравнивание по правому краю, поэтому последняя часть всегда составляет секунды, независимо от длины, и передает одно значение как для предварительного просмотра, так и для экспорта. Полетипированное поле ничего не возвращает, а не бросает, поэтому вход не взрывается при каждом нажатии клавиши 0:0, йо-
Практический совет: введите Timecode, а не перетаскивание, когда важна точная секунда. Слайдер для поиска момента, поле для его именования.
Как вырезать секцию из середины?
Два разреза и соединение, и ни один триммер не делает это за один шаг, что достаточно часто удивляет людей.
Удаление середины зажима означает сохранение детали до выбора и после нее, то есть двух отдельных окон, а затем их обратно. Триммер здесь выдает одно окно за прогон, поэтому последовательность: Обрезка от начала до начала плохой секции, обрезка от конца плохого до конца, затем соедините их в видеоредактор, йо-
Две вещи, на которые стоит обратить внимание, когда вы это делаете. Соединение работает чисто, когда обе части имеют общий кодек, разрешение и частоту кадров, которые они будут, если оба исходят из одного и того же исходного файла через обрезки режима копирования. И шов приземляется на границу ключевого кадра с обеих сторон, поэтому вторая часть начинается немного раньше, чем вы пометили, точно так, как описано выше. Если точка отсечки имеет значение, используйте точный режим для второй части.
Другой вариант — остановиться до того, как начать: если то, что вы хотите, является ярким, а не редактированием, два отдельных клипа часто более полезны, чем один клип с вышитым из него зазором.
