Существует несколько «стандартных» частот кадров, но их становится так много, что поддерживать произвольные частоты кадров проще, чем конкретно поддерживать многие конкретные. Это особенно верно для программных плееров, таких как VLC.
Все больше поддержки существует для ПЕРЕМЕННЫХ fps. (VFR, переменная частота кадров). Здесь интервал между кадрами в одном и том же видео не является постоянным. Многие форматы файлов контейнеров видео (такие как Matroska ( .mkv
) или MPEG-4 ( .mp4
тесно связанные с Apple .mov
)) даже не хранят число FPS, а скорее базу времени (например, 1/30 секунды), а затем каждый кадр имеет метку времени, кратную этой временной базе. Просто так получилось, что интервал между каждым кадром составляет одно или небольшое целое число единиц временной базы в видео CFR (с постоянной частотой кадров).
Видеозапись с камеры слежения с пропущенными почти дублированными кадрами была бы очевидным вариантом использования VFR. Более того, если он сжимается с помощью упрощенного видеокодека, который не пользуется хорошим преимуществом временной избыточности (с интер (p и b) кадрами). ( Поиграйте с ним, чтобы пропустить почти дуплексные ffmpeg -vf mpdecimate
кадры. Используйте -vsync 2
при выводе в mp4, потому что по какой-то причине он не используется по умолчанию для этого мультиплексора, но для mkv.)
Еще один случай - современные смартфоны. Например, мой брат Moto G (2nd gen) записывает видео VFR. Это снижает частоту кадров, когда сенсору нужно больше света. Некоторые из результатов работы mediainfo на mp4, созданной программным обеспечением телефона, записаны в помещении:
Bit rate : 9 999 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Rotation : 90°
Frame rate mode : Variable
Frame rate : 16.587 fps
Minimum frame rate : 14.985 fps
Maximum frame rate : 30.030 fps
Воспроизведение одного видеопотока VFR не сложно. Программное обеспечение просто готово к отображению следующего кадра, спит до тех пор, пока оно не будет отображено, затем просыпается и отображает его
Все становится немного сложнее, если принять во внимание тот факт, что люди могут видеть видеокадры только тогда, когда их отображает монитор. VFR мониторы существуют, но все еще редки. (Google для G-Sync Freesync).
Изменение отображаемого изображения во время его сканирования на монитор приводит к ужасному разрыву видео (обычно это наблюдается при игре в игру с отключенным vsync). Это ограничивает игрока изменением отображаемого изображения на частоте 50 или 60 Гц. (ЭЛТ поддерживают произвольные частоты обновления в пределах диапазона, но сложно готовить режимы с правильной синхронизацией, поэтому большинство людей просто использовали несколько фиксированных частот обновления. И теперь у людей есть ЖК-дисплеи, которые в любом случае поддерживают только фиксированную частоту обновления. Мониторы freesync более распространены в любом случае. Я очень жду этого :)
Таким образом, с частотой кадров видео, которая не кратна или не является фактором частоты обновления монитора, некоторые кадры будут отображаться для трех обновлений монитора, а некоторые для 2, например, даже если предполагается, что видео имеет постоянную частоту 25 кадров в секунду. (на мониторе 60 Гц).
Ситуация усложняется, когда вы хотите работать с несколькими клипами и плавно переходить между ними, или «картинка в картинке», или различными другими эффектами. Писать ПО для редактирования видео гораздо проще, если предположить, что все клипы имеют новый кадр одновременно. (Они заставляют выравнивание клипа привязываться к целым кадрам).
Вот почему NLE (такие как kdenlive или pitivi, чтобы выбрать случайные примеры бесплатного программного обеспечения), с большей вероятностью заставят вас установить фиксированный FPS и отбросить / дублировать кадры из ваших клипов, чтобы они соответствовали этой частоте кадров. Выбранный вами CFR может быть произвольным, но обычно он должен быть постоянным для всего «проекта».
(Любые NLE полностью работают с клипами VFR, и производят выход VFR в этом случае?)
Итак, в итоге, когда у нас есть мониторы с переменной синхронизацией и операционные системы, единственное, что нас сдерживает, я думаю, будет редактирование видео. И радиовещание, так как очевидно, что CFR также имеет большое значение для этого?
Если вам интересно, надоедливые нецелочисленные частоты кадров 29,970 (на самом деле 30000/1001) и 23,976 (на самом деле 24000/1001, из телецининга) являются ошибкой цвета NTSC. поиск 1.001 . Если бы только они были готовы рискнуть несколькими черно-белыми наборами, не способными обработать дополнительную частоту 0,1% для звуковой поднесущей, мир был бы избавлен от этой чепухи. (Думаю, я где-то видел другую статью, в которой это звучало более похоже на то, что многие комплекты были бы хорошими, но они не были уверены в идеальном компатите. Википедия заставляет звучать так, будто ни один из наборов не обработал бы аудио поднесущую на 0,1% выше. IDK факты.)
Однако раздражающая частота кадров - один из меньших грехов вещания. Это действительно чередование, которое было проклятием качества видео на современных (все пиксели освещены одновременно) экранах, и это не изменилось бы. Я до сих пор не понимаю, почему чересстрочная развертка сохранялась для HDTV. Почему было определено разрешение 1080i60 вместо использования 720p60 для получения одинакового временного разрешения для спорта и прочего? Это похоже на 1920x540p60, но с глупым вертикальным смещением между нечетными и четными полями, которое требует много вычислений на приемном конце, чтобы не выглядеть ужасно.
редактировать:
Для вашего случая использования я бы абсолютно рекомендовал архивировать на родном FPS. Не выбрасывайте информацию, отбрасывая кадры. Не дублируйте кадры и не делайте ваши файлы больше (или заставьте ваш кодер h.264 тратить больше времени, замечая дубликаты и выводя кадр, полный пропущенных макроблоков, который занимает всего 20 байтов для всего кадра).
В будущем, когда мы надеемся, что у всех будут дисплеи freesync, способные воспроизводить любую частоту кадров, вы захотите отменить подтягивание до 24 кадров в секунду, чтобы ваше видео воспроизводилось более плавно! Или если freesync каким-то образом не завоевывает популярность, или дисплей, который появляется после LCD, имеет CFR, тогда преобразование скорости, вероятно, лучше всего делать во время воспроизведения. Это не то же самое, что 24fps даже отлично воспроизводится на мониторе 60 Гц. (Я визуально не замечаю тот факт, что некоторые кадры отображаются для 3 * 1/60-го, а некоторые отображаются для 2 * 1/60-го, но это правда).
Если у вас проблемы с Quicktime, тогда IDK. Возможно, убедитесь, что Handbrake создает файлы с правильной частотой кадров, заданной в потоке битов h.264, а также в контейнере. (Да, заголовки h.264, очевидно, могут хранить частоту кадров, отдельную от того, что говорит контейнер. См. Документацию для mkvmerge --fix-bitstream-timing-information
. И попробуйте использовать его с, --default-duration 16fps
чтобы создать файл mkv. Затем передайте обратно в mp4 и посмотрите, исправляет ли это quicktime? ) Или, может быть, есть способ сделать это с помощью инструментов mp4. См. Например: /ubuntu/370692/how-to-change-the-framerate-of-a-video-without-reencoding
Я могу гарантировать, что произвольная частота кадров mp4 действительна, и даже переменная частота кадров mp4 действительна. Если Quicktime играет неправильно, это может быть ошибка Quicktime. Или, возможно, вина Ручного тормоза в том, что файл был неверным. Я обычно просто использую ffmpeg напрямую, потому что я командная строка ниндзя.