Время кадра: FPS не показатель плавности в играх
FPS не показатель плавности в играх
Если сравнить два процессора i3 7300 и i5 7400, то разница показателя FPS будет отличаться незначительно, а иногда i3 отличается большим фреймрейтом чем i5. Тем не менее на практике по ощущениям, разница крайне значительная в пользу i5. Другими словами счетчик FPS не показатель плавности в играх. Это проблема, т.к. все мы привыкли судить именно по FPS.
FPS (Frames Per Second) — это число кадров полностью отрисованных за 1 секунду. FPS = кадры в секунду. Предположим что кадров было нарисовано 50. По простой формуле можно посчитать что каждый кадр рисовался 20 мс (1сек/50кадров). Это значение проще называть время кадра, т.е. время в течении которого показывается кадр. Проблема в том, что например если в течении секунды, 5 кадров будут показаны за 100 мс, а остальные 45 кадров со временем 11,1 мс, то в течении секунды будет показаны всё те же 50 кадров. Счетчик кадров покажет 50 FPS.
Естественно 50 кадров которые выводятся равномерно и 50 кадров с периодическими долгими кадрами, ощущаются кардинальным образом поразомну. По счетчику FPS этого совершенно не видно.
Что бы стабильно по 5 раз в секунду были просадки по времени кадра обычно не бывает. Но когда процессор работает на 100%, то любые сторонние задачи (антивирус, открытый браузер и т.д.) могут вызвать затыки в работе. Например общий фреймрейт составляет 50 кадров, но раз в несколько секунд происходят затыки на 100 мс. Что отжирает всего навсего 4 кадра в секунду по счетчику, но делает игру полностью не играбельной и лучше иметь хорошие 25 кадров, чем те 46 с микрофризами. В таких условиях будет очень хорошо видно как игра фризится и становится очень не комфортной.
В реальности это может выглядеть следующим образом. Например у вас 50 FPS, но половина кадров может быть ближе к 30 мс, а вторая половина ближе к 10 мс. В среднем получается 20 мс и 50 FPS, а ощущается это все не на 50 FPS. Больше всего это касается двухядерных процессоров.
FPS не показатель плавности в играх
Что бы словами описать работу процессора обеспечивающего комфортный уровень плавности, следует в меньшей степени уделять внимание цифрам, а в большей степени таким критериям как плавность, равномерность времени кадра, наличие микрофризов и общая комфортность.
Frame Time (время кадра) лучше отражает плавность в играх, чем FPS. На практике это можно увидеть в программе Afterburner. Ниже приведены три графика среднего времени кадра и FPS. Верхний, это Pentiuum G4560, средний i5 7400 и нижний i7 7700 с частотой 4,9 ГГц. На графиках показан один и тот же отрезок игры Watch Dogs 2, это съезд по центральной дороге в городе — это самое требовательное к процессору место, которое удалось найти.
Когда график времени кадра резко ползет вверх — это уменьшение плавности игры. Когда ползет вниз — это увеличение плавности.
Когда процессора не хватает игре и игре надо например подгрузить следующие кварталы в городе, то на недостаточных процессорах начинаются просадки. Это видно на графиках — i5 и i7 хватает игре,
Второй эффект, который не отражают циферки FPS — это распределение времени кадра в секунду. Назовем это неравномерность времени кадра. То есть время кадра постоянно скачет и при достижении определенных амплитуд проявляется в виде микрофризов. Такое явление встречается на всех трех процессорах, но на i5 и i7 значительно реже чем на Pentium.
Выводы
FPS не показатель плавности в играх и что бы лучше понимать насколько плавной и комфортной будет игра на том или ином процессоре, нужно меньше смотреть в сторону FPS и больше в сторону распределения времени кадра в секунде. Так как на практике может быть так, что за одни и те же деньги один процессор покажет по счетчику FPS меньше кадров чем другой процессор, но распределение времени кадра будет равномерным в отличии от второго процессора, то не смотря на более низкий FPS, первый процессор для игр будет более комфортным.
Неуловимая проблема тайминга кадров / Хабр
Технический директор Croteam Ален Ладавач, участвовавший в разработке Serious Sam и Talos Principle, рассказывает, как ему удалось найти причину торможения графики даже на самых мощных машинах.
Наконец-то появилось объяснение того, почему некоторые игры тормозят на вашем PC (и луч надежды на то, что в ближайшем будущем они тормозить перестанут).
Т-т-тормоза
Вы с нетерпением ждали следующей части вашей любимой серии видеоигр для PC и она наконец вышла. На этот раз вы хотите насладиться ею во всей полноте, поэтому потратили деньги и время на тщательную подготовку. Вы заменили процессор, поставили сверхсовременную видеокарту, добавили ещё ОЗУ — чёрт возьми, даже купили RAID на SSD. Игра должна быть плавной с самой заставки.
Предзаказ наконец разблокирован и вы только что завершили установку. В нервном предвкушении вы впервые запускаете игру. Пока всё хорошо — она работает с частотой 60 кадров в секунду. Или, по крайней мере, так сообщает счётчик кадров тюнера GPU. Но что-то не так. Вы делаете мышью резкие, хаотичные движения. Стрейфитесь влево-вправо, и тут игра… начинает тормозить! Блин, да как такое возможно? Как она может тормозить при 60 кадрах в секунду?
Если такое с вами никогда не случалось, то это может показаться смешным. Но если вы их испытали, то, скорее всего, ненавидите тормоза всей душой. Тормоза в играх. Это не старый добрый «лаг». Не низкая частота кадров. Это просто «тормоза», происходящие при высоких частотах кадров на идеальных, супербыстрых машинах. Что это, откуда они взялись и как от них избавиться? Позвольте мне рассказать вам историю…
Тормоза, плавность, скорость… это ведь одно и то же?
Видеоигры работали с частотой 60 fps ещё со времён
первых аркадных автоматовв 70-х годах. Обычно ожидается, что игра работает с той же частотой, которая используется дисплеем. Так было до популяризации 3D-игр, в которых впервые стала допустимой пониженная частота кадров. В 90-х, когда «
3D-карты» (так мы называли их до того, как они стали «
GPU«) начали заменять программный рендеринг, люди играли в игры при 20 fps, а 35 fps считались приличным значением для серьёзных сетевых боёв.
Я не шучу.
Сегодня у нас есть супербыстрые машины и «разумеется, они могут работать при 60 fps«. Однако количество разочарованных скоростью игр пользователей как никогда велико. Как такое возможно? Проблема оказывается не в том, что игры не могут работать достаточно быстро, а в том, что они тормозят, даже когда могут работать быстро!
Если почитаете разные игровые форумы, то наверняка найдёте подобные сообщения:
Можно подумать, что это единичные проблемы, но посмотрите на статистику поисковых запросов Google:
За последние пять лет тормоза (stutter) стали (относительно) более серьёзной проблемой, чем скорость!
(Учтите, что это относительные значения. Они не значат, что в целом люди спрашивают о торможениях больше, чем о частоте кадров. Они значат, что запросы о частоте кадров (frame rate) остаются на том же уровне, а количество запросов о тормозах растёт, особенно в последнее время.)
Десяток лет в поисках причины необъяснимых тормозов
Пациент скорее жив, чем мёртв, просто тормозит чуть больше, чем нужно.
Впервые я столкнулся с этой проблемой ещё примерно в 2003 году. Мы работали над Serious Sam 2, и пользователи начали отправлять нам отчёты о том, что они тестировали что-то на пустом уровне, и при перемещениях мыши движения не были плавными. Это сопровождалось очень характерным паттерном на графике частоты кадров, который мы прозвали «кардиограммой».
Мы думали, что где-то в коде есть баг, но не могли его найти. Казалось, что проблема появляется и исчезает случайным образом — после перезапуска приложения, перезагрузки машины… а потом игрок менял какую-нибудь опцию скорости и она исчезала. Потом игрок снова включал эту опцию, но проблема не возвращалась. Она была похожа на призрака.
Очевидно, что эта проблема возникала не только у нас. Наблюдая за теми же проблемами в других играх, мы начали думать, что виноваты драйверы. Но это происходило на видеокартах разных производителей. Даже на разных API (OpenGL, DirectX 9, DirectX 11…) — единственным общим у них было то, что они появлялись на разных машинах, в некоторых сценах… иногда.
Несси, бигфут… почти столь же неуловимые, как и проблема с «кардиограммой».
Мы выпустили ещё несколько игр, но это странное поведение по-прежнему появлялось и исчезало. Некоторых пользователей оно раздражало, и мы рекомендовали им изменить опции скорости — иногда это помогало, иногда нет. Такова жизнь, не правда ли?
Но однажды, в отличный зимний день в начале 2013 года мой коллега Дин позвал меня, чтобы я увидел ещё один пример этой проблемы, который он на тот момент мог относительно стабильно воспроизводить. На этот раз проблема возникала на уровне из Serious Sam 3. Мы экспериментировали с опциями в этой сцене, пока до меня внезапно не дошло. Я понял, в чём была причина! И она была очень проста — неудивительно, что она ускользала от всех в течение десятка лет.
Изменив всего одну очень простую опцию игрового движка, мы смогли заставить эту проблему появляться и исчезать в этой конкретной сцене. Но нам стало сразу же очевидно, что на её качественное решение потребуется гораздо больше усилий. Усилий не только с нашей стороны, но и всей игровой экосистемы PC — программистов драйверов GPU, разработчиков API, поставщиков ОС — каждого.
Позвольте объяснить.
В чём же была причина всё это время
Хотел бы я показать вам её на примере сцены из Serious Sam 3, которую мы с Дином исследовали пять лет назад. Или даже ещё лучше — на примере тестовой сцены из Serious Sam 2, в которой мы впервые её увидели. Но, к сожалению, после замены «железа» этот ускользающий зверь может переместиться в другую сцену. У меня есть сцена из
The Talos Principle, в которой мне недавно удалось воспроизвести эту проблему, и я заснял несколько видео, позволившие проанализировать её более подробно.
Но прежде чем мы начнём, убедитесь, что вы на самом деле смотрите видео в 60 fps. Для просмотра представленных ниже примеров переключитесь в 1080p60, как показано на картинке:
Чтобы смотреть видео в 60 fps, переключитесь в YouTube на 1080p60.
Если вы всё сделаете правильно, а ваш компьютер и веб-браузер способны показывать видео с частотой 60 fps, то представленное ниже видео должно воспроизводиться плавно и без всяких тормозов. Если это не так, то именно поэтому мы и говорим об этом — многие другие приложения тоже демонстрируют такое поведение, не только игры. Пока я могу только рекомендовать вам попробовать посмотреть видео на какой-нибудь другой машине, или просто читать текст.
Проверка, проверка, раз, два, три… Вы должны видеть это видео в плавных 60 fps.
А теперь перейдём к делу. Если вы сталкиваетесь с тормозами, то вероятнее всего это выглядит примерно так:
Вот как выглядят «тормоза при 60 fps». Мы называем этот симптом «кардиограммой».
Да, именно так выглядят «тормоза», даже когда игра работает с 60 fps. Вы могли сталкиваться с чем-то подобным в любой современной игре, и вероятно думали, что «игра не оптимизирована». Так вот, вам стоит пересмотреть свою теорию (о том, что такие тормоза возникают из-за «медленного» рендеринга игры). Если игра «слишком медленная», то это значит, что в какие-то моменты она не сможет достаточно быстро отрендерить один кадр, а монитору придётся заново показывать предыдущий кадр. Поэтому когда мы записываем видео такой игры в 60 fps, то видим «пропущенные кадры». (Это такие кадры, при которых следующий кадр не был отрендерен вовремя, поэтому текущий кадр показывается дважды.)
Теперь снова запустите предыдущее видео с тормозами («кардиограммой»), поставьте его на паузу и нажимайте в проигрывателе YouTube клавишу . (точка), чтобы перемещаться от кадра к кадру. Попробуйте заметить, когда один и тот же кадр показывается дважды. Давайте, попробуйте, я подожду…
Ну как, нашли? Нет? Странно, не правда ли?..
Видео выглядит не плавным, когда смотришь всю анимацию в целом, но когда рассматриваешь покадрово, разрывов нет!
Как такое может быть?
Позвольте мне объяснить более подробно. Вот сравнение идеально плавного видео и видео с тормозами в виде
«кардиограммы», воспроизводимые на 1/20 от исходной скорости, чтобы мы могли видеть отдельные кадры:
Сверху правильное видео с 60 fps, снизу «кардиограмма». Воспроизведение замедлено в 20 раз.
Можно заметить две вещи: во-первых, они действительно воспроизводятся с одинаковой частотой — когда сверху есть новый кадр, снизу тоже есть новый кадр. Во-вторых, они по какой-то причине движутся немного по-разному — есть заметный «разрыв» в середине изображения, который становится то более, то менее заметным.
Внимательный зритель может заметить и ещё одну любопытную деталь: нижнее — тормозящее — изображение — которое считается «медленным»… на самом деле «опережает» правильное. Странно, правда?
Если мы посмотрим на два соседних кадра и их тайминги (заметьте, что во всех показанных мной видео были точные таймеры (с точностью 1/10 000 секунды), то можем заметить нечто очень интересное: первые два кадра идеально синхронизированы, но третий…
Шесть идущих друг за другом кадров из видео с точными таймингами. Верхние — правильные, нижние — с «кардиограммой».
…на третьем кадре мы видим, что дерево в «тормозящем» видео значительно опережает свою копию из правильного видео (обведено красным). Также можно заметить, что на этот кадр, похоже, ушло больше времени (обведено жёлтым).
Постойте… если видео «медленнее», и на кадр «ушло больше времени», то как он может опережать правильный?
Чтобы разобраться в этом, вам нужно понять, как в наше время игры и другие трёхмерные интерактивные приложения реализуют анимации и рендеринг. (Опытные разработчики должны простить меня за то, что я надоедаю им с очевидными вещами, но мне нужно быть уверенным, что текст смогут понять все читающие этот текст игроки.)
Краткая история таймингов кадра
Давным-давно, в далёкой-далёкой галактике… Когда разработчики создавали первые видеоигры, они обычно подстраивались под точную частоту кадров, с которой работает дисплей. В регионах NTSC, где телевизоры работали при 60 Гц, это означало 60 fps, в регионах PAL/SECAM, где телевизоры работали при 50 Гц, это означало 50 fps. Они даже и думать не могли о какой-то возможности «пропуска кадра».
Большинство игр было очень вылизанными и упрощёнными концептами, работавшими на конкретном оборудовании — обычно на аркадном компьютере, или на «домашнем микрокомпьютере», наподобие ZX Spectrum, C64, Atari ST, Amstrad CPC 464, Amiga и т.д. По сути, разработчик создавал дизайн, реализовывал и тестировал игру под конкретную машину и конкретную частоту кадров, и был на 100% уверен, что она никогда не пропустит ни кадра.
Скорости объектов тоже хранились в единицах «кадров». Поэтому говорили, не на сколько пикселей в секунду должен двигаться персонаж, а на сколько пикселей за кадр. Известно, что в Sonic The Hedgehog для Sega Genesis скорость вращения, например, была равна 16 пикселям за кадр. У многих игр даже были отдельные версии для регионов PAL и NTSC, в которых анимации вручную рисовались специально под 50 fps и 60 fps. По сути, запуск при любой другой частоте кадров даже не рассматривался.
Когда игры начали работать на более разнообразных машинах — в частности, на PC с расширяемым и заменяемым «железом» — разработчики больше не могли знать, с какой частотой кадров теперь будет работать игра. Дополните это тем фактом, что игры стали более сложными и непредсказуемыми. Самыми выдающимися в этом плане стали 3D-игры, отличавшиеся разнообразием сложности сцен, иногда даже зависящей от игрока. Например, всем нравится стрелять в бочки с топливом — при этом происходит огромный взрыв, красивые эффекты… и неизбежная просадка кадров. Но здесь никто не против пропуска кадров, потому что это так интересно.
Поэтому было очень сложно предсказать, сколько займёт симуляция и рендеринг одного кадра. (Стоит заметить, что на современных консолях «железо» по-прежнему неизменно, но сами игры всё равно часто непредсказуемы и сложны.)
Если мы не можем быть уверенными, при какой частоте кадров будет работать игра, нам приходится измерять текущую частоту кадров и постоянно адаптировать физику и скорость анимаций игры. Если один кадр занимает 1/60 секунды (16,67 мс), а персонаж бежит со скоростью 10 м/с, то в каждом кадре он перемещается на 1/6 метра. Но если кадр перестаёт занимать 1/60 секунды, а вместо этого внезапно начал занимать 1/30 секунды (33,33 мс), то надо начать перемещать персонажа на 1/3 метра (в два раза «быстрее») за кадр, чтобы на экране он продолжал двигаться с кажущейся постоянной скоростью.
Как же игра это делает? По сути она измеряет время в начале одного кадра, а затем в начале следующего и вычисляет разность. Это довольно простой способ, но он очень хорошо работает. То есть простите, он работал хорошо. В 90-х (вспомните фразу «35 fps считались приличным значением для серьёзных сетевых боёв» из начала статьи), людей более чем устраивал этот способ. Но в то время графическая карта (не забывайте, их даже ещё не называли GPU) была очень «тонким» элементом «железа», и попаданием объектов на экран непосредственно управлял основной ЦП. Если в компьютере не было 3D-ускорителя, процессор даже сам отрисовывал эти объекты. Поэтому он точно знал, когда они появятся на экране.
Что происходит сегодня
Со временем у нас появились более сложные GPU, и они становились всё более и более «
асинхронными«. Это значит, что когда ЦП отдаёт GPU команду отрисовать что-то на экране, то GPU просто сохраняет эту команду в буфер, чтобы ЦП занимался своими делами, пока GPU выполняет рендеринг. В результате это привело к тому, что когда ЦП сообщает GPU, что «это конец кадра», GPU просто сохраняет сообщение как ещё один фрагмент данных. Но он не относится к нему как чему-то особо срочному. Да и как он может — ведь ему по-прежнему нужно обрабатывать часть из ранее переданных команд. Он покажет кадр на экране, когда закончит всю работу, которую ему дали раньше.
Поэтому когда игра пытается вычислить тайминги, вычитая метки времени начала двух кадров, то актуальность этого, грубо говоря… весьма сомнительна. Давайте вернёмся к нашему примеру из коротких видео. У нас есть эти кадры, где камера перемещается вдоль деревьев:
Шесть идущих друг за другом кадров из видео с точными таймингами. Верхние — правильные, нижние — с «кардиограммой».
Теперь вспомните то, что я говорил о таймингах и перемещениях. В первых двух кадрах тайминг кадра равен 16,67 мс (то есть 1/60 секунды), и камера движется на одну и ту же величину и сверху, и снизу, поэтому деревья синхронизированы. На третьем кадре (внизу) игра увидела, что время кадра равно 24,8 мс (что больше 1/60 секунды), поэтому она думает, что частота кадров снизилась и торопится переместить камеру чуть дальше… только для того, чтобы обнаружить, что тайминг четвёртого кадра составляет всего 10,7 мс, поэтому камера движется здесь чуть медленнее, и деревья снова более-менее синхронизируются. (Синхронизация восстановится полностью только спустя два кадра.)
Здесь происходит следующее: игра измеряет то, что она считает началом каждого кадра, а эти тайминги кадров иногда по разным причинам колеблются, особенно на такой высоконагруженной многозадачной системе, как PC. Поэтому в некоторые моменты игра думает, что не успевает обеспечить 60 fps, и в какие-то моменты генерирует кадры анимации, рассчитанные на меньшую частоту кадров. Но из-за асинхронной природы работы GPU он на самом деле успевает обеспечить 60 fps для каждого отдельного кадра этой последовательности.
Именно это мы воспринимаем как тормоза — анимация, сгенерированная под изменяющуюся частоту кадров («кардиограмму») на самом деле отображается с правильной постоянной частотой кадров.
То есть, по сути, здесь нет никакой проблемы — всё
действительноработает плавно, просто игра об этом не знает.
При этом мы возвращаемся к началу статьи. Наконец обнаружив причину проблемы (на самом деле, это иллюзия проблемы — ведь её на самом деле нет, так?), вот что мы сделали для проверки:
Сначала мы наблюдаем «кардиограмму», а затем используем небольшой трюк, чтобы избавиться от неё.
В первой части видео вы с самого начала можете увидеть проблему с «кардиограммой». Затем мы изменяем «магическую» опцию, после чего всё становится идеально плавным!
Что же это за волшебная опция? В Serious Engine мы называем её sim_fSyncRate=60. Если говорить простыми словами, то это значит «полностью игнорировать все эти заморочки с таймингами и притвориться, что мы всегда замеряем стабильные 60 fps». И благодаря этому всё работает плавно — просто потому, что всё и так работало плавно! Единственная причина, по которой всё выглядело тормозящим — это ошибочные тайминги, используемые для анимации.
И на этом всё? Достаточно сделать так и всё станет замечательно?
Неужели решение настолько простое?
К сожалению — нет. Это всего лишь тест разработчиков. Если мы перестанем замерять частоту кадров в реальных ситуациях и просто будем предполагать, что она всегда равна 60, то когда она
упадётниже 60 — а на PC она рано или поздно
обязательноупадёт по тем или иным причинам: ОС запустит какой-нибудь фоновый процесс, включится экономия энергии или защита от перегрева GPU/ЦП… кто знает — то всё замедлится.
Итак, если мы изменяем частоту кадров, то возникают торможения, если нет — то всё в какие-то моменты может замедляться. Что же нам делать?
Реальное решение заключается в том, чтобы измерять не начало/завершение рендеринга кадра, а время отображения картинки на экране.
Как же нам сообщить игре, что изображение кадра уже показывается на экране? Вы можете удивиться, узнав это — но на сегодняшний день такого способа нет!
Это шокирует, я понимаю. Можно было ожидать, что это базовая функция каждого графического API. Но оказывается, в процессе постепенных улучшений тут и там все, в сущности, упустили сам смысл проблемы. Мы все забыли о тонких деталях своей работы, продолжая повторять одно и то же, а графические API эволюционировали во всех других аспектах, кроме этого: приложение никаким образом не может точно узнать, что кадр
на самом делеотображается на экране. Мы можем узнать, когда закончится его рендеринг, но не когда он будет показан.
Что дальше?
Но не волнуйтесь, всё не так мрачно. Многие люди в графической экосистеме активно
работаютнад реализацией поддержки правильного тайминга кадров для разных API. Для
Vulkan APIуже есть расширение под названием
VK_GOOGLE_display_timing, которое
продемонстрировалосвою полезность в реализации proof of concept. Однако оно доступно только для ограниченного ассортимента оборудования, в основном на Android и Linux.
Уже ведётся работа по созданию аналогичных и более качественных систем для всех основных графических API. Когда она закончится? Сложно сказать, потому что проблема лежит довольно глубоко внутри различных подсистем ОС.
Однако я заверяю вас, что Croteam безустанно работает над тем, чтобы эта проблема была решена как можно скорее, и все участники экосистемы интерактивной графики понимают и поддерживают наши усилия.
Мы стремимся сделать это решение доступным для более широкой аудитории, и когда это случится, мы подготовим апдейт The Talos Principle с реализацией этой функции.
Различные помехи и другие подробности
Последнюю фразу можно считать концом основного текста. Ниже представлены «бонусные разделы», практически не связанные друг с другом и основным текстом. Вероятно, я буду обновлять их, когда ситуация станет меняться, или в случае возникновения более сложных вопросов, требующих решения в ближайшем будущем.
«Композитор»
Эффект матового стекла? Да, для него нам определённо нужен композитор. Он просто-таки необходим, правда?
За кулисами со всем этим связан концепт под названием «композитный менеджер окон», или композитор. Это система, существующая теперь во всех ОС, которая позволяет окнам быть прозрачными, иметь размытый фон, тени, всплывающие поверх окна Skype и т.д. Композиторы даже могут отображать окна в 3D. Для этого композитор перехватывает управление над последним этапом создания картинки кадра и решает, что ему сделать с ней, прежде чем она попадёт на экран монитора. Это ещё больше всё усложняет.
В некоторых ОС композитор можно отключить в полноэкранном режиме. Но это не всегда возможно, а даже если и возможно — то разве можно запретить запускать игру в оконном режиме?
Управление питанием и тепловыделением против сложности рендеринга
Мы также должны учитывать, что современные ЦП и GPU не работают с фиксированной частотой, а имеют системы, изменяющие их скорости в соответствии с нагрузкой и температурой. Поэтому игра не может просто предполагать, что GPU и ЦП будут иметь одинаковую скорость в каждом кадре. С другой стороны, ОС и драйверы не могут ожидать, что у игры в каждом кадре будет одинаковый объём работы. Чтобы учесть это, необходимо разработать сложные системы для общения этих двух сторон.
А разве мы не можем просто…
Скорее всего нет. 🙂 Обычно измерение времени GPU считается альтернативой таймингам дисплея. Но оно не учитывает наличие композитора и тот факт, что ни один из таймеров рендеринга GPU на самом деле не синхронизирован напрямую с обновлением дисплея. Для идеальной анимации нам абсолютно точно нужно знать время отображения изображения, а не время завершения рендеринга.
Анализ кадров графики — Visual Studio (Windows)
- Чтение занимает 6 мин
В этой статье
Используйте анализ кадров в анализаторе графики Visual Studio, чтобы анализировать и оптимизировать производительность отрисовки в приложениях или играх, использующих Direct3D.
Анализ кадров
Функция анализа кадров использует для диагностики данные из файла журнала графики, применяя ее для получения сводной информации о производительности отрисовки. Информация о производительности не записывается в журнал во время захвата. Она создается позднее во время анализа кадров с помощью событий синхронизации и сбора статистики при воспроизведении кадра. Такой подход имеет ряд преимуществ в сравнении с записью информации о производительности во время захвата.
Анализ кадров позволяет получать усредненные результаты для нескольких воспроизведений одного кадра, что обеспечивает статистически достоверные данные производительности.
Анализ кадров позволяет получать информацию о производительности для конфигураций оборудования и устройств, отличных от тех, где были захвачены данные.
Анализ кадров позволяет получать новые сводки производительности на основе ранее захваченных данных, например, если драйверы GPU были оптимизированы или предоставляют дополнительные возможности отладки.
Помимо этих преимуществ, с помощью анализа кадров также можно изменять способ отрисовки кадра во время воспроизведения. Таким образом можно получать информацию о том, как эти изменения могут повлиять на производительность отрисовки приложения. С помощью этой информации можно выбрать наиболее подходящую из возможных стратегий оптимизации, не применяя их все, чтобы захватить данные и сравнить результаты самостоятельно.
Хотя анализ кадров в первую очередь предназначен для повышения производительности отрисовки, он может быть не менее полезен для повышения качества изображения при заданном уровне производительности или для снижения энергопотребления GPU.
Просмотреть демонстрацию возможностей анализа кадров в приложении можно в видеоролике Анализ кадров графики Visual Studio на канале 9.
Использование анализа кадров
Прежде чем использовать анализ кадров, необходимо захватить графические данные из работающего приложения, так же как при использовании любого другого инструмента анализатора графики. Затем в окне документа журнала графики (.vsglog) выберите вкладку Анализ кадра.
По завершении анализа выводятся результаты. В верхней части вкладки анализа кадров находятся временная шкала и сводная таблица. В нижней части находятся таблицы с подробными данными. Если во время воспроизведения произошли ошибки или были получены предупреждения, сводная информация о них выводится над временной шкалой. Переходя по ссылкам в этой области, можно узнать больше об ошибках и предупреждениях.
Интерпретация результатов
Интерпретируя результаты для каждого варианта, можно получить полезную информацию о производительности и особенностях отрисовки приложения. Подробнее о вариантах отрисовки см. в разделе Варианты далее в этой статье.
Некоторые результаты непосредственно указывают на то, как вариант влияет на производительность отрисовки.
Если вариант «Билинейная фильтрация текстур» показал прирост производительности, то использование билинейной фильтрации текстур в приложении приведет к такому же приросту производительности.
Если вариант «Окно просмотра 1 x 1» показал прирост производительности, то уменьшение размеров целевых объектов отрисовки в приложении повысит производительность отрисовки.
Если вариант «Сжатие текстур BC» показал прирост производительности, то использование сжатия текстур BC в приложении приведет к такому же приросту производительности.
Если вариант 2 x MSAA имеет почти такую же производительность, что и вариант 0 x MSAA, можно включить вариант 2 x MSAA в приложении, чтобы повысить качество отрисовки без снижения производительности.
Другие результаты могут содержать менее явные указания на производительность приложения.
Если вариант «Окно просмотра 1 x 1» показывает очень значительный прирост производительности, возможно, скорость заполнения в приложении выше возможной. Если этот вариант не показывает прироста производительности, возможно, приложение обрабатывает слишком много вершин.
Если вариант «Формат целевого объекта отрисовки с глубиной цвета 16 бит» показывает значительный прирост производительности, возможно, приложение потребляет слишком много пропускной способности памяти.
Если вариант «Половинные/четвертные размеры текстур» показывает значительный прирост производительности, возможно, текстуры занимают слишком много памяти, используют слишком много пропускной способности или используют кэш текстур неэффективно. Если этот вариант не сказывается на производительности, возможно, использование более крупных, подробных текстур не снизит производительность.
Если доступны аппаратные счетчики, вы можете использовать их для сбора очень подробной информации о том, почему производительность отрисовки приложения ухудшается. Все устройства функционального уровня 9.2 и более высокого поддерживают запросы перекрытия глубины (счетчик пикселей перекрыто) и метки времени. Могут быть доступны и другие аппаратные счетчики, если изготовитель GPU реализовал их и предоставил доступ к ним посредством драйвера. Их можно использовать для уточнения причины результатов, отображаемых в сводной таблице. Например, установив процент пикселей, которые были перекрыты при выполнении тесты глубины, можно определить, является ли превышение негативным фактором.
Временная шкала и сводная таблица
По умолчанию временная шкала и сводная таблица отображаются, а другие разделы свернуты.
Временная шкала
На временной шкале показано время выполнения вызовов Draw относительно друг друга. Так как более длинные полоски соответствуют более длительному выполнению вызовов Draw, с их помощью можно определить наиболее затратные по времени вызовы в кадре. Если захваченный кадр содержит очень большое число вызовов Draw, несколько вызовов Draw объединяются в одну полоску, длина которой соответствует суммарному времени выполнения вызовов.
Чтобы увидеть, какому событию вызова Draw соответствует полоска, наведите на нее указатель. При выборе полоски список событий синхронизируется с этим событием.
Таблица
В таблице с числами под временной шкалой показана производительность каждого варианта отрисовки для каждого вызова Draw относительно способа отрисовки по умолчанию в приложении. Каждый столбец соответствует отдельному варианту отрисовки, а каждая строка представляет отдельный вызов Draw, указанный в самом левом столбце. Отсюда можно перейти по ссылке к событию в окне «Список событий графики».
Во втором слева столбце сводной таблицы показано базовое время отрисовки приложения, то есть время выполнения вызова Draw с помощью варианта отрисовки, используемого в приложении по умолчанию. В остальных столбцах показана относительная производительность каждого варианта отрисовки в процентах от базового показателя, что позволяет легко видеть, улучшилась ли производительность. Если значение превышает 100 процентов, вызов выполнялся дольше, чем при базовом варианте, то есть производительность снизилась. Если значение меньше 100 процентов, вызов выполнялся быстрее, то есть производительность возросла.
Значения абсолютного базового времени и относительного времени для вариантов отрисовки на самом деле являются средними значениями, полученными в результате нескольких вызовов (по умолчанию 5). Усреднение позволяет обеспечить достоверность и согласованность данных. Наведя указатель на ячейку в таблице, можно узнать минимальное, максимальное, среднее и центральное значения времени, полученные при выполнении данного вызова Draw с помощью данного варианта отрисовки. Также отображается базовое время.
«Горячие» вызовы Draw
Для привлечения внимания к вызовам Draw, которые занимают большую часть общего времени отрисовки или могут выполняться необычно медленно по причинам, которых можно избежать, строка, содержащая такие «горячие» вызовы Draw, выделяется красным цветом, если ее собственное базовое время более чем на одно стандартное отклонение превышает среднее базовое время всех вызовов Draw в кадре.
Статистическая значимость
Для привлечения внимания к вариантам отрисовки, имеющим наибольшую важность, при анализе кадров определяется статистическая значимость каждого из вариантов отрисовки. Значимые варианты выделяются полужирным шрифтом. Варианты, повышающие производительность, выделяются зеленым цветом, а снижающие производительность — красным. Результаты, не имеющие статистической значимости, имеют обычный шрифт.
Для определения статистической релевантности при анализе кадров используется t-критерий Стьюдента.
Таблица подробных сведений
Под сводной таблицей находится таблица подробных сведений, которая по умолчанию свернута. Ее содержимое зависит от аппаратной платформы компьютера воспроизведения. Информацию о поддерживаемых аппаратных платформах см. в разделе Поддержка оборудования.
Платформы, не поддерживающие аппаратные счетчики
Большинство платформ не полностью поддерживают аппаратные счетчики GPU. К ним относятся все GPU, предлагаемые в настоящее время компаниями Intel, AMD и nVidia. Если аппаратные счетчики для сбора данных отсутствуют, отображается только одна таблица подробных сведений, которая содержит среднее абсолютное время для всех вариантов.
Платформы, поддерживающие аппаратные счетчики
Для платформ, поддерживающих аппаратные счетчики GPU, например на основе микросхемы SOC nVidia T40 и всех микросхем SOC Qualcomm, отображаются несколько таблиц подробных сведений (по одной для каждого варианта). Данные каждого доступного счетчика собираются для каждого варианта отрисовки и отображаются в собственной таблице подробных сведений.
Данные аппаратных счетчиков позволяют получить очень подробное представление о поведении конкретных аппаратных платформ для каждого вызова Draw, что может помочь вам точно установить причины узких мест производительности.
Примечание
Разные аппаратные платформы поддерживают разные счетчики — никаких стандартов нет. Доступные счетчики и предоставляемые ими данные определяются исключительно изготовителем GPU.
Области маркеров и события
Анализ кадров поддерживает пользовательские маркеры и группы событий. Они отображаются в сводной таблице и в таблице подробных сведений.
Для создания маркеров и групп можно использовать API ID3DUserDefinedAnnotation или устаревшие API семейства D3DPERF_. При использовании семейства API D3DPERF_ каждому маркеру и группе можно назначить цвет. Полоса этого цвета будет отображаться в окне анализа кадров в строке, содержащей соответствующий маркер события или группу событий. Это позволяет быстро определять важные события или группы событий отрисовки.
Предупреждения и ошибки
Иногда анализ кадров завершается с предупреждениями или ошибками, сводка по которым приводится над временной шкалой, а подробная информация — в нижней части вкладки анализа кадров.
Как правило, предупреждения и ошибки служат только для информации и не требуют вмешательства.
Предупреждения обычно указывают на отсутствие аппаратной поддержки, но наличие обходного пути, невозможность собрать данные аппаратных счетчиков или возможную недостоверность некоторых данных производительности, например вследствие применения обходного пути.
Ошибки обычно указывают на наличие ошибок в реализации анализа кадров, ошибки в драйвере, отсутствие аппаратной поддержки и обходного пути или попытку приложения выполнить операцию, которая не поддерживается при воспроизведении.
Повторы
Если во время анализа кадров в GPU происходит смена состояний питания, затронутый проход анализа необходимо выполнить повторно, так как тактовая частота GPU изменилась и относительные результаты измерения времени стали недействительны.
Число повторных попыток анализа кадров ограничено 10 попытками. Если в вашей платформе используется агрессивная модель управления питанием или технология Clock gating, это может привести к сбою анализа кадров и получению ошибки из-за превышения числа повторных попыток. Эту проблему можно устранить, уменьшив тактовую частоту и изменив модель управления электропитанием на менее агрессивную, если платформа допускает это.
Поддержка оборудования
Метки времени и запросы перекрытия
Метки времени поддерживаются на всех платформах, которые поддерживают анализ кадров. Запросы перекрытия глубины, необходимые для счетчика «Пикселей перекрыто», поддерживаются на платформах, которые поддерживают функциональный уровень 9.2 или более высокий.
Примечание
Хотя метки времени поддерживаются на всех платформах, которые поддерживают анализ кадров, их точность и согласованность меняется от платформы к платформе.
Счетчики GPU
Поддержка аппаратных счетчиков GPU зависит от оборудования.
Так как ни одно из устройств GPU, в настоящее время предлагаемых компаниями Intel, AMD или nVidia для компьютеров, не обеспечивает надежной поддержки аппаратных счетчиков GPU, при анализе кадров данные этих счетчиков не собираются. Однако при анализе кадров собираются данные аппаратных счетчиков для следующего процессора GPU, который обеспечивает их надежную поддержку:
nVidia T40 (Tegra4)
На всех остальных платформах, поддерживающих анализ кадров, сбор данных аппаратных счетчиков GPU не производится.
Примечание
Так как аппаратные счетчики GPU являются аппаратными ресурсами, для сбора полного набора их показателей для каждого варианта отрисовки требуется несколько проходов. Поэтому порядок сбора показателей счетчиков GPU не определен.
Неподдерживаемые сценарии
Некоторые способы использования анализа кадров не поддерживаются или просто не рекомендуются.
Воспроизведение захватов высокого функционального уровня на устройствах более низкого уровня
При воспроизведении в анализаторе графики файла журнала графики, использующего более высокий функциональный уровень, чем тот, который поддерживается компьютером воспроизведения, происходит автоматическое переключение на WARP. При анализе кадров явное переключение на WARP не происходит и возникает ошибка, так как WARP полезен для проверки правильности приложения Direct3D, но не для анализа его производительности.
Примечание
Хотя необходимо учитывать проблемы, связанные с функциональным уровнем, захватывать и воспроизводить файлы журнала графики можно на разных устройствах и в разных конфигурациях оборудования. Журнал графики можно воспроизвести, если файл журнала не содержит API-интерфейсы и не использует функциональные уровни, которые не поддерживаются на компьютере воспроизведения.
Direct3D 10 и более ранних версий
Если приложение вызывает API Direct3D 10, инструменту анализа кадров не удастся распознать или профилировать его несмотря на то, что он распознается и используется другими инструментами анализатора графики.
Примечание
Это относится только к вызовам API Direct3D, но не к функциональным уровням.
WARP
Анализ кадров предназначен для сбора данных и оптимизации производительности отрисовки на реальном оборудовании. Запуск анализа кадров на устройствах WARP возможен, однако обычно это нецелесообразно, так как производительность WARP на быстром ЦП ниже, чем производительность даже самого простого из современных графических процессоров. Кроме того, производительность WARP может существенно различаться в зависимости от базового ЦП.
Варианты
Любое изменение, которое анализ кадров вносит в способ отрисовки кадра во время воспроизведения, называется вариантом. Варианты, проверяемые при анализе кадров, соответствуют типичным, сравнительно простым изменениям, которые можно внести, чтобы повысить производительность отрисовки или качество изображения в приложении. Это, например, уменьшение размера текстур, использование сжатия текстур или включение различных типов сглаживания. Варианты переопределяют стандартный контекст и параметры отрисовки приложения. Ниже приведена сводная информация о вариантах.
| Вариант | Описание |
|---|---|
| Размер окна просмотра 1 x 1 | Размеры окна просмотра для всех целевых объектов отрисовки уменьшаются до 1 x 1 пикселей. Дополнительные сведения см. в разделе Вариант размера окна просмотра (1×1) |
| 0x MSAA | Многовыборочное сглаживание (MSAA) отключается для всех целевых объектов отрисовки. Дополнительные сведения см. в разделе Варианты 0x/2x/4x MSAA |
| 2x MSAA | Двукратное многовыборочное сглаживание (MSAA) включается для всех целевых объектов отрисовки. Дополнительные сведения см. в разделе Варианты 0x/2x/4x MSAA |
| 4x MSAA | Четырехкратное многовыборочное сглаживание (MSAA) включается для всех целевых объектов отрисовки. Дополнительные сведения см. в разделе Варианты 0x/2x/4x MSAA |
| Точечная фильтрация текстур | Для всех соответствующих образцов текстур устанавливается режим фильтрации DXD11_FILTER_MIN_MAG_MIP_POINT (точечная фильтрация текстур).Дополнительные сведения см. в статье Варианты точечной, билинейной, трилинейной и анизотропной фильтрации текстур. |
| Билинейная фильтрация текстур | Для всех соответствующих образцов текстур устанавливается режим фильтрации DXD11_FILTER_MIN_MAG_LINEAR_MIP_POINT (билинейная фильтрация текстур).Дополнительные сведения см. в статье Варианты точечной, билинейной, трилинейной и анизотропной фильтрации текстур. |
| Трилинейная фильтрация текстур | Для всех соответствующих образцов текстур устанавливается режим фильтрации DXD11_FILTER_MIN_MAG_MIP_LINEAR (трилинейная фильтрация текстур).Дополнительные сведения см. в статье Варианты точечной, билинейной, трилинейной и анизотропной фильтрации текстур. |
| Анизотропная фильтрация текстур | Для всех соответствующих образцов текстур устанавливается режим фильтрации DXD11_FILTER_ANISOTROPIC, а свойству MaxAnisotropy присваивается значение 16 (16-кратная анизотропная фильтрация текстур).Дополнительные сведения см. в статье Варианты точечной, билинейной, трилинейной и анизотропной фильтрации текстур. |
| Формат целевого объекта отрисовки с глубиной цвета 16 бит | Для всех целевых объектов отрисовки и буферов фона задается формат пикселей DXGI_FORMAT_B5G6R5_UNORM (глубина цвета 16 бит, формат 565).Дополнительные сведения см. в разделе Вариант формата однобуферной прорисовки 16 бит/пкс |
| Создание MIP-карт | MIP-карты включаются для всех текстур, не являющихся целевыми объектами отрисовки. Дополнительные сведения см. в разделе Вариант создания MIP-карты. |
| Половинные размеры текстур | Размеры всех текстур, не являющихся целевыми объектами отрисовки, уменьшаются вдвое по сравнению с исходными. Например, текстура размером 256 x 128 уменьшается до 128 x 64 текселя. Дополнительные сведения см. в разделе Вариант размера текстур: половина/четверть. |
| Четвертные размеры текстур | Размеры всех текстур, не являющихся целевыми объектами отрисовки, уменьшаются в четыре раза по сравнению с исходными. Например, текстура размером 256 x 128 уменьшается до 64 x 32 текселя. Дополнительные сведения см. в разделе Вариант размера текстур: половина/четверть. |
| Сжатие текстур BC | Включает блочное сжатие всех текстур, которые имеют вариант формата пикселей B8G8R8X8, B8G8R8A8 или R8G8B8A8. Варианты формата B8G8R8X8 сжимаются с помощью BC1; варианты форматов B8G8R8A8 и R8G8B8A8 сжимаются с помощью BC3. Дополнительные сведения см. в разделе Вариант сжатия текстур BC. |
Результаты для большинства вариантов представляют собой четкие указания: «Уменьшение размера текстур вдвое повысит производительность на 25 процентов» или «Включение варианта «2x MSAA» приведет к снижению производительности всего на 2 процента». Другие варианты могут потребовать дополнительной интерпретации. Например, если вариант, изменяющий размеры окна просмотра на 1 x 1, приводит к значительному приросту производительности, это может указывать на то, что отрисовка замедляется из-за низкой скорости заполнения. Если же производительность изменяется незначительно, это может указывать на то, что отрисовка замедляется из-за обработки вершин.
Far Cry 6: обзор тестов производительности графики для ПК — анализ времени кадра игры
Графический процессор и процессор анализа времени кадра игры
На приведенных ниже диаграммах показаны графические аномалии, такие как заикание и сбои, на построенной диаграмме: время кадра и измерения темпа.
| Время кадра в миллисекундах | FPS |
| 8,3 | 120 |
| 15 | 66 |
| 20 | 50 |
| 25 | 40 |
| 30 | 33 |
| 50 | 20 |
| 70 | 14 |
- FPS в основном измеряет производительность, количество кадров, отображаемых за секунду.
- Frametime AKA Записи Frame Experience в основном измеряют и выявляют аномалии — здесь мы смотрим, сколько времени требуется для рендеринга одного кадра. Измерьте это в хронологическом порядке, и вы увидите аномалии, такие как пики и провалы на графике, указывающие на то, что что-то не так.
По сути, время, необходимое для рендеринга одного кадра, можно отслеживать и маркировать его числом; это задержка. Один кадр может занять, скажем, 17 мс. Более высокая задержка может указывать на медленную частоту кадров, а странные всплески задержки указывают на заикание, дрожание, подергивания; в основном аномалии, которые видны на вашем мониторе. Эти измерения показывают аномалии, такие как небольшие сбои и заикания, которые вы иногда можете (и, пожалуйста, внимательно прочтите это иногда ), видите на экране. Ниже вместе с вами пробежимсяся по парочке заголовков. Имейте в виду, что средний FPS часто имеет большее значение, чем измерение времени кадра.
Пожалуйста, поймите, что чем меньше время кадра, тем выше FPS, поэтому для этих графиков меньше = лучше. Огромные всплески будут заиканияя, толстые линии будут означать плохую частоту кадров, а постепенная оптимизация — это изменение частоты кадров. Как вы могли заметить, мы немного экспериментируем с нашими диаграммами и методологией. Ниже игра в Ultra HD с настройками качества изображения, используемыми в этом обзоре.
Для тестового прогона запустим 30-секундную сцену с разрешением 3840×2160 пикселей как в DX12, так и в DX12 + Raytracing. Использовать Radeon RX 6800 XT в паре с GeForce RTX 3080. Первая быстрее в DX12, вторая — в DX12 + Raytracing. Так что это должно быть интересное наблюдение.
Как только вы видите визуальные пики на 40 мс, вы попадаете в зону заикания. В игровом движке они есть.
Выше Radeon RX 6700 XT — DX12 (шейдинг / растеризация) по производительности
Выше Radeon RX 6800 — производительность DX12 (+ трассировка лучей + FSR)
Выше GeForce RTX 3060 Ti — DX12 (шейдинг / растеризация) по производительности
Выше GeForce RTX 3060 Ti — DX12 (+ трассировка лучей + FSR)
Почти досадно видеть, насколько хорошо работают обе карты, поэтому мы приблизимся еще дальше к максимальному измеренному времени кадра в мс, превышающему время кадра DX12 для 6700 XT (красный) и 3060 Ti (зеленый). Вы можете увидеть очень похожую частоту кадров и поведение во времени, зеленая полоса расположена выше и, следовательно, немного медленнее (большее время кадра — меньше FPS).
Как только мы нажимаем на Raytracing и FSR, изображение показывает в целом очень похожую частоту кадров. Позвольте мне отметить, что этот график составляет максимум 40 мс, тогда как мы обычно строим 60 мс. Обе карты ведут себя немного более проблемно с включенной трассировкой лучей, но добавление FSR, безусловно, помогает, что имеет смысл, поскольку он выполняет рендеринг с более низким разрешением.
Читаем далее:..
Похожие записи:
Hz FPS Frame time
Насколько хорошо, Вы знаете, а если знаете, то понимаете, в чем заключается различие между FPS (частотой кадров в секунду), Hz (герцами) и Frame time (временем кадра)?
Лично для себя, я решил, разобраться в данных понятиях и взаимосвязи между ними. Далее, я изложу свои мысли и наблюдения, стараясь, свои рассуждения, используя понятные и простые примеры, намеренно опуская или пренебрегая определенными деталями. Все описанное далее, может содержать неточности, ошибки, не стоит воспринимать, все описанное в качестве эталона.
В первую очередь, я отдаленно, расскажу об основных терминах и понятиях, затем, последуют примеры с конкретными значениями. Подобный подход поможет лучше, с меньшей запутанностью понять основную мысль.
Представим, что имеется некий ЖК монитор и компьютер с установленными на него приложениями.
Характеристика Hz, в данном случае будет относиться к монитору, ее числовое значение, означает, максимальное количество кадров (изображений), которых, монитор будет способен показать за одну секунду времени.
Характеристика FPS, будет относиться к приложению, установленному на компьютере, ее числовое значение, будет обозначать производительность конкретного приложения на конкретном компьютере, в количестве кадров в секунду, которые могут быть «предоставлены данным приложением» для вывода на монитор.
===================================================
Hz, обладают постоянным и фиксированным значением, его величина, зависит от характеристик и технологического процесса примененного, при производстве ЖК панели, установленной в мониторе. 30, 60, 75Hz, встречается в большинстве мониторов, матрицы же с поддержкой 122, 144, 166, 200, 240Hz, получили распространение в игровых мониторах.
FPS, как правило, обладает не постоянным значением, часто данный параметр, характеризуют, как среднее, минимальное и максимальное значение кадров в секунду, за определенную сцену или промежуток времени, в пределах которого рассматривается данный параметр.
Количество FPS, напрямую зависит от производительности (мощности) компьютера. Для каждого приложения, следует индивидуально рассчитывать и рассматривать данный параметр, так как, у каждого приложения имеются свои, индивидуальные требования, к технической части пк.
Для каждой программы существуют, минимальные и рекомендуемые или максимальные системные требования к «железной составляющей компьютера», или по-другому системные требования. В первом случае, минимальные системные требования, описывают параметры, необходимые для запуска и более – менее стабильной и комфортной работы по, во втором случае, для наилучшего достижения максимальной или оптимальной производительности данного по, на каком – либо пк.
======================================================
Рассмотрим еще один фактор, то как человек воспринимает изображение, состоящие из последовательности, сменяющихся друг за другом кадров.
Начнем с того, что существует миф, в котором говорится, что человек, не способен воспринимать, видеть больше определенного числа кадров в секунду (FPS), часто в качестве подобного значения приводятся цифры в 24, 30, 50, 60 кадров в секунду.
Вы когда-нибудь задавались вопросом, откуда появились, настолько точные цифры, без «разброса» или допустимой погрешности, в несколько единиц?
Почему именно конкретное фиксированное значение, ведь все люди воспринимают аналогичные зрительные явления, немного или полностью по-своему. У одних людей, зрение лучше или хуже, чем у других, тогда почему именно 24 или 50 кадров в секунду?
По моему мнению, было бы правдоподобнее и логичнее, если бы, существовал диапазон чисел, например, от 24 до 50, и утверждалось бы, что человек способен воспринимать от начала и до конца, данного диапазона, в зависимости от индивидуальных способностей. В приведенный числовой диапазон содержит немалое количество значений… и самое главное, каким образом это было настолько точно определено?
На самом деле, ответ на эти вопросы, достаточно прост. Данные значения, являются частью, стандартов, используемых, при кинопроизводстве и телевещании. Появились они, достаточно давно, еще во времена пленки и 24 кадра, это минимальное значение, при котором видео материал, воспринимается более – менее целостно и не выглядит, как слайд шоу, а звук сопровождающий происходящие нормально и без особых проблем «ложится» так, чтобы присутствовало ощущение целостности, между видео и аудио, и самое главное при съемке на пленку, ее расход должен был быть разумным, особенно при немалой длительности видео.
Конечно, данный стандарт, появился далеко не сразу…
С дальнейшим развитием технологий, когда пленка, уже была не настолько востребована и появились новые носители информации, «родились» и новые стандарты, предоставляющие зрителю большую плавность картинки и, следовательно, лучшее погружение в происходящее.
Глаз человека, это не механизм или электроника, поэтому такое понятие, как количество воспринимаемых кадров или мегапикселей, не применимы, потому что глаз видит все происходящие не по кадрово, восприятие, зависит от индивидуальных способностей конкретного человека.
Добавлю, что в видео, количество кадров фиксированное, в некоторых моментах оно может изменяться, для придания эффекта, замедленной или ускоренной съемки.
В видео глаз, привыкает к одному и тому же количеству кадров и воспринимает их плавно, а в играх, такого ощущения надолго или вообще не удается сохранить, так как в разных сценах или, при порой малейших действиях, количество кадров в секунду, может изменяться и глаз неплохо замечает изменения в 10 и более единиц, при условии, если изначально FPS, был не очень большим.
В играх, в отличие от видео, количество кадров, можно ограничить, но зафиксировать, на определенном числе надолго, практически невозможно.
Так же частое мнение, что нужно больше 30 или 60fps в играх, оправданно, далее я уделю этому внимание, рассказав, про время кадра.
==============================================
Пример 01.
Предположим, что имеется монитор с частотой обновления 60Hz, приложение, установленное на пк, «вырабатывает» 80FPS. Как было отмечено ранее, 60Hz означают, что монитор способен максимум отобразить 60 кадров за одну секунду, в таком случае, появляется вопрос, что будет с оставшимися 20 кадрами?
Если речь идет о видео, где как было замечено ранее, количество кадров фиксированное, то оно будет воспроизведено с потерями, данных кадров, в большинстве случаев, это будет незаметно или почти незаметно.
Если речь идет об играх или иных приложениях с нефиксированным количеством кадров, то в дело вступает такое понятие, как время кадра. Оно выражается в миллисекундах (в 1 сек = 1000мс) и показывает, сколько потребовалось времени в миллисекундах, чтобы вывести на монитор данный кадр.
Для расчета используется следующая формула: единица делится на количество кадров в секунду, производимых приложением (fps), полученный результат умножается на одну секунду (1000мс).
Пример
1 : 60fps * 1000мс = 16.6мс
Один кадр, был отображен за 16.6мс
Если кадров, больше, чем способен отобразить монитор, то время кадра становится меньше:
1: 240fps * 1000мс = 4.1мс
Чем меньше время кадра, тем более актуальную «картинку», мы можем видеть.
Из всего изложенного, можно сделать вывод, что большее количество кадров, чем способен физически отобразить монитор, мы не увидим, из – за технического ограничения, строения его матрицы. Но, смысл иметь большее количество fps, чем может отобразить монитор, имеет смысл, так как выводится более «свежее» изображение.
Имеется еще ряд, особенностей влияющий на данные переменные и время кадра, но если их не учитывать, то зависимость остается примерно такой.
Длинный кадр при создании фильма
В статье о правилах видеосъемки обсуждался вопрос длинного кадра. Обычно длительность кадра в фильме или телепередаче не превышает 5-6 секунд. Вы можете убедиться в этом, когда очередной раз будете смотреть телевизор.
Это стандартное правило монтажа, основанное на том, что видео, в котором картинка часто сменяется, смотрится живее и интереснее, воспринимается легче.
Почему так? Оказывается, это правило учитывает особенности человеческого зрения и восприятия окружающих объектов (подробнее — зрительные образы и монтаж).
Длинный кадр — это непрерывный кадр, который длится дольше обычного, съемка без монтажных склеек.
Обычно при монтаже видео длинные кадры разбиваются на короткие, вставляются перебивки, другие кадры. Это классическое правило видеопроизводства.
Но означает ли это, что длинный кадр использовать нельзя? Конечно же, нет. Из любого правила есть исключения. Главным, определяющим моментом при создании фильма является не длительность кадра, а замысел автора данной картины.
Каждый фильм служит для передачи художественного замысла режиссера, что именно он желает донести до зрителя. Если режиссер считает, что для восприятия зрителями смысла, настроения, эмоций, информации необходим именно длинный кадр, он вправе его использовать.
Конечно, не у каждого режиссера использование длинного кадра получается удачным, потому что это один из самых сложных кинематографических приемов. Чем длиннее кадр, тем сложнее получить идеальный результат без монтажной склейки.
Но многие признанные мастера с успехом применяли длинный кадр, и их работы считаются настоящими шедеврами кинематографа.
Вот несколько примеров.
Известная картина Альфреда Хичкока «Веревка» снята именно длинным кадром. При длительности 80 минут, фильм состоит всего из 10 кадров, каждый из которых длится от 6 до 10 минут. Даже стыковка кадров сделана максимально незаметно, на переходах, например, спинах действующих персонажей.
Представьте, насколько сложно снимать такой фильм. Все мизансцены должны быть точно выверены, актеры должны безошибочно помнить текст своей роли, играть без погрешностей, в соответствии с замыслом режиссера. Точно также должны отработать и остальные члены съемочной команды — оператор, осветители, звукорежиссеры и пр.
В обычных фильмах неудачный момент переснимается по нескольку раз, и в этом нет проблемы, если кадр длится 10-30 секунд. А теперь представьте, если надо делать несколько дублей 10-минутного кадра…
При съемке длинного кадра определяющим является мастерство оператора. В этом отношении нужно выделить операторскую работу известного советского кинооператора и режиссера Сергея Урусевского в фильме Михаила Калатозова «Я — Куба».
Практически вся картина снята ручной камерой. Урусевский постоянно использовал внутрикадровый монтаж: движение камеры, изменение фокуса, наезд, отъезд, панораму, трансфокацию. Оператор перемещался с камерой по залу, спускался во время съемки на лифте, заходил в бассейн.
Операторская работа Урусевского до сих пор (с 1964 года) считается эталонной в истории киноискусства.
Мастером длинного кадра является знаменитый итальянец Федерико Феллини. В его картинах планы длительностью несколько минут смотрятся настолько динамично, что зрители совершенно не замечают, что кадры не монтированы.
Из русских знаменитых режиссеров, снимающих не просто длинные, а сверхдлинные кадры, является Андрей Тарковский. Вспомните его фильмы, например, всем известный «Солярис», получивший Гран-при Каннского кинофестиваля. По результатам различных рейтингов эта картина входит в число величайших фантастических фильмов в истории кинематографа.
Тарковский всегда был противником «резки» кадра, считал, что это нарушает целостную ткань катрины.
Вообще, в 70-90-х годах прошлого века многие известные режиссеры использовали длинный кадр как ключевой, стилеобразующий прием.
Бела Тарр в фильме «Макбет», длящемся 1 час, делает всего одну склейку. Этот же прием применяли Микеланджело Антониони, Стэнли Кубрик, Стивен Спилберг, Мартин Скорсезе, Михаэль Ханеке, Пол Томас Андерсон и многие другие.
Была просчитана средняя продолжительность кадра в фильмах семи культовых режиссеров, и получены следующие результаты:
Серджио Леоне — 7 сек.
Федерико Феллини — 8,8 сек.
Франсуа Трюффо — 13,5 сек.
Ингмар Бергман — 16,7 сек.
Жан-Люк Годар — 20,7 сек.
Андрей Тарковский — 40 сек.
Бела Тарр — 178,3 сек.
В наше время (после 2000 г.) режиссеры также используют длинный кадр. В 21-м веке появились цифровые камеры, которые дают возможность снимать сверхдлинные кадры, поскольку теперь нет ограничения времени длительностью кинопленки.
Режиссеры используют эту возможность для новаторских, экспериментальных картин. Например, фильм Майка Фиггиса «Тайм-код» — это полтора часа однокадровой съемки.
Аналогичный пример у нас: Александр Сокуров снял однокадровый фильм об истории России «Русский ковчег» длительностью 87 минут, который снимался в Зимнем дворце с участием 2000 актеров. Примечательно, что фильм был снят за один день, но, правда, с третьей попытки.
Можно назвать много современных фильмов, в которых используются длинные кадры. Вот несколько примеров таких картин:
«Дитя человеческое» (2004) — сцена засады длится 4 мин. 7 сек., сцена сражения — 7 мин. 34 сек.
«Олдбой» (2003) – сцена драки — 2 мин. 34 сек.
«Искупление» (2007) – сцена в Дюнкерке — 5 мин. 7 сек.
«Голод» (2008) – сцена беседы продолжается 16 мин. 30 сек. при полностью статичной камере на всем ее протяжении.
«Честь дракона» (2005) – сцена драки на лестнице — 3 мин. 55 сек.
«Гравитация» (2013) – первый кадр — 17 мин.
«Горячие новости» (2004) — сцена перестрелки 6 мин. 47 сек.
Конечно, это не все примеры длинного кадра в современном кино, хотя распространенным в наше время этот прием назвать нельзя. Удачным или нет получился результат — судите сами.
Что касается телевизионных передач, то существует такое понятие, как репортажное определение длинны кадра: пока длится событие, пока поступает новая информация, кадр может не заканчиваться.
Если репортер заснял какой-то важный, эксклюзивный материал, то его показывают целиком, не обращая внимание на длительность. Здесь главное — информация, а не «смотрибельность».
Вы, наверняка, видели, как по центральному телевидению показывают видео, снятое на мобильный телефон, если оно несет действительно ценную информацию.
Аналогично, если выступает оратор с какой-то значимой речью, то кадр длится столько, сколько нужно. Никто не будет перебивать кадр с обращением, например, президента, какими-то вставками или перебивками.
Итак, подведем итоги: можно ли и нужно ли использовать длинный кадр?
Если вы считаете, что только таким образом вы можете реализовать свой замысел и донести до зрителя смысл или настроение данной сцены, то используйте его.
Если вы считаете, что сможете достойно выполнить съемку длинного кадра — используйте его.
Композиция кадра.
Свадебная видеосъемка
Профессиональное и любительское видео
Организация экранного меню в Sony A7R III. «Отображение/Автопросмотр»
Александр Бахтурин, преподаватель отдела маркетинга, эксперт компании Sony
Самым захватывающим фактором в общении с новейшими цифровыми фотокамерами Sony (A6500/6300/A7M3/A7RM3/A9) оказывается настройка экранного меню. Однако практика показывает, что 80 процентов пользователей за первые 6 месяцев работы с камерой этого не делают. Таким образом, по многочисленным просьбам фотографов, мы решили показать, как организовано меню в моих камерах на примере экранного меню Sony Alpha 7R III. Все советы мы разделили на тематические статьи, каждая из которых посвящена соответствующему разделу меню.
«Звёздочка/Мое меню»; «Качество/Размер изображения»; «Режим съёмки/Работа затвора»; «Экспозиция»; «Фокусировка»; «Цвет/Баланс белого/Обработка изображения»; «Вспышка»; «Помощь при фокусировке»; «Помощь при съемке»; «Видео»; «Затвор/SteadyShot»; «Увеличение»; «Отображение/Автопросмотр»; «Настройка (Чемодан)»; «Сеть и воспроизведение»; «Пользовательские операции», «Пользовательские клавиши», «Пользовательское меню».
Вторая вкладка — группа настроек «Вторая камера», или «Фиолетовая камера» на 9 вкладок. Экраны 6/9 и 7/9 — «Отображение/Автопросмотр».
«Кнопка Disp» — управление выводом данных в видоискатель, и на экран. В ней две подвкладки — «Монитор» и «Видоискатель».
Монитор
Мы видим раскладку всех вариантов выводимой на ЖК-экран информации. Графическая информация — это отображение шкал с выдержками и диафрагмами в кадре. Показать всю информацию — это лучший, по-моему, способ, забыть о снимаемом объекте. Или вообще не найти его… Не показывать — остаётся возможный минимум.
Гистограмма — в правом нижнем углу появляется график, отображающий количество тонов в кадре. Уровень — в центре кадра проецируется «авиагоризонт». Для видоискателя — на ЖК-экране отображается полное функциональное меню настроек, нажатие кнопки Fn и навигация джойстиком/качающимся диском позволяет откорректировать любую информационную зону.
«Монитор выкл.» — необходимая функция для работы с аппаратом, подключённым к компьютеру, при дистанционной съёмке с компьютера или при передаче данных.
Видоискатель
Здесь ситуация аналогичная, как на мониторе. Отображение шкал с выдержками и диафрагмами. Показывать всю информацию — усложнять восприятие кадра. Лучше оставить возможный минимум. Гистограмма — в правом нижнем углу. Уровень — в центре. На экране есть команды «Ввод» и «Отмена», но, как правило, достаточно «поставить галочку» напротив нужного пункта.
«Finder/Monitor» — управление переключением между видоискателем (благодаря датчику приближения) и ЖК-экраном. Хотите, чтобы датчик приближения не реагировал на вас, а ЖК не отключал, выдвиньте экран от камеры. «Авто» — автопереключение по датчику.
Видоискатель — только он (ЖК-экран — тёмный, переключиться обратно можно только глядя в видоискатель). Монитор — только он. Частота кадров в видоискателе — «высокая» навсегда.
Настройка «Зебры» — функция из набора инструментов видеографов, она показывает зоны экспозиционного дисбаланса.
«Сетка» — вспомогательный графический фото/видеоинструмент. «Сетка» — вспомогательный графический фото/видеоинструмент. По задумке, она должна помогать в композиции кадра. Самая простая выглядит, как сетка 3х3, т.е. разделяет кадр по третям — не по «Золотому сечению», но по третям. Вторая — сетка 6х4, полезная более видеографам, нежели фотографам. Затем квадратная сетка 6х4 (диагонали + квадратная сетка). Это комплексный инструмент для рассчёта перспективы и упреждения при съёмке движения — приближающихся/удаляющихся объектов. Наконец, мой любимый режим «Выкл.». Рекомендую пользоваться сеткой крайне редко, только в ситуациях острой необходимости, примерно как «Уровнем».
По «безумству» и негативному результату постоянное пользование сеткой сравнимо только с постоянным ношением поляризационного фильтра на объективе.
«Инструкция настройки экспозиции». По идее — подсказка любителям. Рекомендую выключить и забыть. Думайте сами.
Live View
На втором экране 7/9 находится «Отображение Live View» — включение и выключение функции.
Включённый режим Live View — это диафрагма в постоянном рабочем состоянии — закрытая. Вы видите реальную глубину резкости, реальный баланс белого, реальную работу коррекции и работающую гистограмму, все оттенки и проработку деталей в тенях/светах. Но в темноте студии, в ожидании срабатывания вспышек, вы будете видеть только данные на тёмном экране.
Выключенный режим Live View — это открытая диафрагма и постоянное изображение во время визирования. Вводимую коррекцию не видно даже на гистограмме. Но вы видите всё в видоискателе и на ЖК-экране даже в полной темноте. Эффект сравним с электронно-оптическим усилителем прибора ночного видения.
«Длительность непрерывной съёмки» — демонстрация графической сигнализации об оставшемся месте на карте памяти.
«Автоматический просмотр» — демонстрация только что снятого кадра 2, 5 или 10 секунд. Особенно эта функция была необходима на цифрозеркалках, когда в видоискателе присутствовало оптическое изображение, зачастую не имеющее ничего общего с результатом.
Чем больше вы доверяете камере — тем меньше отвлекаетесь на контроль результата. И даже с контролем отрываться от видоискателя не нужно — вам там всё покажут.
Узнать больше про камеру ILCE-7RM3: https://www.sony.ru/electronics/interchangeable-lens-cameras/ilce-7rm3
FPS против Frametime: секрет плавной игры | Лакшья Шривастава
Вначале были созданы небо и земля. И сказал Бог: да будет свет. И стал свет. Но со светом пришло ужасное заикание, вызывающее рвоту.
Озадаченный, Бог посмотрел в правый верхний угол своего экрана и увидел стабильную частоту кадров 60. Что происходило?
Млечный путь — это просто небесная рвота от всего того заикания, с которым Бог не справился. Фото: Денис ДеджоанниБольшинство из нас может относиться к Богу, когда дело доходит до проблем с заиканием в играх.И хотя в многопользовательских играх вы можете объяснить это проблемами с сервером, когда это происходит в однопользовательских играх, это может сделать их совершенно неиграбельными, и кроме вашей собственной системы винить нечего.
В этом нет смысла. У вас новейшее оборудование, ваш fps постоянно превышает 30, но игра заикается сильнее, чем на первом свидании.
Что ж, вот грязная правда тестов производительности в играх: высокая и стабильная частота кадров — это только одна часть обеспечения бесперебойной работы игры.Другая часть — это часто упускаемый из виду термин, называемый временем кадра.
Допустим, ваша система запускает игру со скоростью 60 кадров в секунду. Это 60 кадров в секунду. Но что происходит за одну секунду? Возможно, ваш компьютер отображает один кадр за первые 0,8 секунды, а остальные 59 кадров за последние 0,2 секунды. В этом случае, хотя счетчик кадров в секунду будет стабильно показывать 60, вы увидите ужасное заикание на экране.
Вот здесь-то и появляется время кадра. Время кадра показывает, доставляются ли ваши кадры с постоянными интервалами в пределах секунды.Таким образом, для плавных 60 кадров в секунду каждый кадр должен отображаться за 1/60 секунды, что составляет 16,67 миллисекунды.
Так как же отслеживать время кадра? И как исправить колеблющееся время кадра? К счастью, есть бесплатное приложение, которое сделает это за вас без лишних хлопот — Сервер статистики Rivatuner.
Вот как это работает. После установки приложение откроется с интерфейсом, который вы видите ниже.
Все, что вам нужно сделать, это нажать зеленую кнопку «Добавить» и найти исполняемый файл игры, в которой у вас возникают проблемы с заиканием.В этом примере мы используем получившую множество наград CRPG Divinity Original Sin II от Larian Studios.
Видите строку справа, в которой написано «Ограничение частоты кадров»? Измените этот 0 рядом с частотой кадров, с которой вы хотите запустить игру. Это будет 30 или 60, в зависимости от того, что поддерживает ваше оборудование. Если ваша система не может поддерживать постоянные 60 кадров в секунду с этой игрой, мы рекомендуем установить этот предел на 30. Введите значение, нажмите Enter, и все готово. Теперь оставьте Риватунер открытым и начните игру.Rivatuner гарантирует, что кадры меняются с регулярными интервалами в каждую секунду в зависимости от установленного вами предела частоты кадров, и в вашем опыте должна быть немедленная разница.
Вот и все. Вы можете добавить больше игр в Rivatuner, как и в первую, и установить для них лимит кадров в секунду индивидуально.
Если вы хотите узнать больше о времени кадра, вот отличное введение в него.
Что такое время кадра? Почему так важно время кадра?
Что такое время кадра?
Время кадра — это время, необходимое для выполнения или рендеринга кадра. Также иногда описывается как миллисекунды между каждым кадром. Это очень полезная метрика, потому что она не только показывает, сколько времени требуется для визуализации или выполнения кадра, но и насколько согласована синхронизация между несколькими визуализируемыми кадрами.
Пример кадра
Видео выше будет служить примером того, как работает время кадра. Посмотрите на разную частоту кадров: 120, 60 и 30 кадров в секунду: синие линии для каждой представляют кадры. Оранжевая линия, прокручивающая кадры, представляет время рендеринга или выполнения.По сути, чем ниже частота кадров, тем больше времени требуется для рендеринга кадра. Чем выше частота кадров, тем короче время рендеринга кадра. Из этого примера мы можем ясно видеть, сколько кадров отображается в зависимости от частоты кадров.
Возьмем, к примеру, нижние 30 кадров в секунду, если игра постоянно работает со скоростью 30 кадров в секунду, то для визуализации одного кадра требуется 33,33 миллисекунды. Если игра постоянно работает со скоростью 60 кадров в секунду, то для визуализации одного кадра требуется 16,67 миллисекунды.Если игра постоянно работает со скоростью 120 кадров в секунду, то для визуализации одного кадра требуется 8,33 миллисекунды. За время, необходимое для рендеринга одного кадра со скоростью 30 кадров в секунду, выполняется рендеринг четырех кадров со скоростью 120 кадров в секунду. Это довольно резкий скачок в количестве визуализируемых кадров.
* Обратите внимание, что это пример кадров, которые отображаются с постоянной скоростью *
Почему так важно время кадра?
Время кадра имеет решающее значение, поскольку входные данные обычно обрабатываются за каждый кадр .Следовательно, чем меньше времени требуется для рендеринга кадра, тем быстрее обрабатываются вводимые пользователем данные. И требуется довольно много времени, чтобы отобразить все на экране, включая физику, анимацию, частицы, объекты, взрывы и многие другие элементы. Все эти факторы влияют на время, необходимое для рендеринга одного кадра.
Также важно, чтобы время кадра было согласованным, потому что вводимые пользователем данные будут варьироваться в зависимости от того, сколько времени требуется для визуализации кадра. Если кадры рендерится в разное время, это может привести к огромному количеству заиканий. .Но это также приведет к увеличению задержки ввода. Изображение начнет прыгать между кадрами и будет выглядеть дрожащим в движении. Но моя любимая часть вишни на мороженом с фруктами — это то, что контролировать это становится полным кошмаром.
через Gfycat
Это пример микро-заикания, возникающего в играх.
Несогласованное время кадра приводит к заиканию
Вы когда-нибудь играли в игру и сталкивались с раздражающими проблемами с заиканием? Это именно то, что происходит, когда игра имеет несогласованное время кадра.Кадры не выполняются или не визуализируются согласованным образом, и время между визуализацией отличается. В свою очередь игра превращается в веселую возню боли и страданий. Где игра скачет, когда вы бессмысленно боретесь за контроль.
Например, представьте, что вы делаете что-то простое, например, о, я не знаю, двигайте своим персонажем. Вы нажимаете кнопку один раз, и для регистрации ввода требуется 50 миллисекунд. Затем вы пытаетесь двигаться в другом направлении, снова нажимаете кнопку, и внезапно требуется 300 миллисекунд, чтобы зарегистрировать тот же самый ввод.К сожалению, к тому времени, когда ваш ввод закончился, вас застрелили. Игра закончена. Ой как чудесно!
Именно поэтому так важно, чтобы кадры рендерились с постоянной скоростью.
Как рассчитать время кадра
Уравнение для понимания этого довольно простое. время кадра = 1000 миллисекунд / кадров в секунду
Ниже приведен пример изменения времени кадра в зависимости от частоты кадров в секунду, с которой работает игра.Чем выше частота кадров, тем меньше времени требуется на рендеринг кадра. Также очень важно, чтобы эти кадры рендерились с постоянной скоростью. Это приводит к снижению задержки ввода и повышению производительности игры.
Frame Time
15 кадров в секунду равны 66,66 миллисекундам для рендеринга кадра
30 кадров в секунду равны 33,33 миллисекундам для рендеринга кадра
45 кадров в секунду равны 22,22 миллисекунды для рендеринга кадра
60 кадров в секунду равны 16.67 миллисекунд для рендеринга кадра
75 кадров в секунду равны 13,33 миллисекунды для рендеринга кадра
90 кадров в секунду равны 11,11 миллисекунды для рендеринга кадра
105 кадров в секунду равны 9,52 миллисекунды для рендеринга кадра
120 кадров в секунду равны 8,33 миллисекунды для рендеринга кадра
Заключение
Из этого можно сделать вывод, что частота кадров — не единственный показатель, который следует изучать при оценке производительности. Время кадра является абсолютно критическим показателем производительности.Анализируя время выполнения и визуализации каждого кадра, мы можем получить представление о производительности визуализируемых кадров. Эта информация помогает нам понять, почему возникают такие проблемы, как проблемы с заиканием, разрывом экрана, несогласованной задержкой ввода и прерывистым движением камеры.
В этом отношении время кадра даже более важно, чем частота кадров. Даже если игра может работать со скоростью 120 кадров в секунду, интервал между кадрами может быть неравномерным, что приведет к тому, что игра будет прыгать и пропускаться, как проигрыватель с битыми записями.Поэтому важно включать время кадра в качестве ключевой метрики в любой анализ производительности.
Эти две статьи более подробно рассматривают эту тему. Посмотрите их
https://www.vortez.net/articles_pages/frame_time_analysis,4.html
Частота кадров и время кадра
При измерении производительности вашего приложения очень легко просто взглянуть на Fraps и сказать, что ваша частота кадров составляет 60 FPS. Многие студенты делают это изначально, не слишком задумываясь о том, что они измеряют или что это означает.Есть случай, когда достаточно просто указать частоту кадров, и несколько случаев, когда вы можете столкнуться с ошибками, в зависимости от того, что вы скажете дальше.
60 кадров в секунду
Причина, по которой измерять FPS, состоит в том, чтобы указать, что скорость, с которой ваше приложение создает кадры, достаточна для создания хорошей иллюзии плавного движения. На самом деле по вашему экрану не движется 3D чайник. Скорее, мы достаточно быстро показываем чайник в разных местах, и зрительная система нашего мозга интерпретирует это как движение.
Если мы хотим сказать, что наше приложение создает кадры достаточно быстро для визуально плавного движения, то указание частоты кадров кажется прекрасным способом сделать это. Для фильмов 24 FPS достаточно, чтобы создать иллюзию из-за того, как наши камеры записывают изображения [1]. Однако, когда у нас есть 3D-сцена в компьютерной игре, 24 FPS недостаточно [2]. Это из-за отсутствия размытия при движении и того, что пользователь контролирует вид. Обычно относительно камеры быстро движется много объектов.В таком случае 60 кадров в секунду считается нормой, а более высокие скорости могут сделать движение еще более плавным. Для виртуальной реальности (VR) целевая норма — 90 FPS [3].
| Платформа | Целевой FPS |
|---|---|
| Кино | 24 |
| Игра | 60 |
| VR | 90 |
Похоже, неплохо было бы посмотреть на вывод Fraps и сказать, что ваше приложение работает со скоростью 60 кадров в секунду и, следовательно, имеет хорошую производительность.Или регистрируйте некоторые значения FPS в разное время, и если они в среднем превышают 60 FPS, то у вас есть графически плавное приложение, верно?
Средний FPS
Не так быстро. Если вы просто измеряете мгновенное значение частоты кадров, вы можете случайно выбрать несколько быстрых кадров. В этом случае 60 FPS ничего не значит, если 80% ваших кадров фактически работают со скоростью 30 FPS, а вы выбрали кадры из других 20%.
Если вы усредните результаты вместе, это также может дать неверное значение.Например, когда большое количество ваших кадров работает со скоростью 90 кадров в секунду, но есть некоторые кадры, которые падают до 20 кадров в секунду.
Если редко низкая частота кадров сохраняется для многих кадров, результатом будет визуальных заиканий , которые вы полностью проигнорируете, если вы просто усредните FPS для нескольких последовательных кадров. Пользователи испытывают моменты резкого падения частоты кадров. Есть еще один эффект, называемый микрозажигания , который также может присутствовать, но его визуально труднее заметить в приложении.
Вместо того, чтобы просто усреднять мгновенную частоту кадров, было бы лучше показать распределение измерений или даже сами измерения. Прежде чем мы перейдем к этому, есть еще одна проблема с использованием частоты кадров.
Время кадра
Рассмотрим случай, когда вы оптимизируете свою производительность. Допустим, ваше приложение работает со скоростью 40 кадров в секунду. Вы отключаете ambient occlusion, и теперь приложение работает со скоростью 60 FPS. Отлично, вы прибавили в производительности 20 FPS.Проблема здесь в том, что если бы ваше приложение изначально работало со скоростью 20 FPS, то отключение ambient occlusion не привело бы к 40 FPS. Фактически, вы получите только 24 кадра в секунду, что приведет к увеличению производительности на 4 кадра в секунду, а не на 20, как раньше.
Вместо измерения частоты кадров следует измерять время кадра [4]. Компьютеру требуется некоторое время для создания кадра. Часть этого времени уходит на анализ геометрии, растеризацию треугольников, раскрашивание фрагментов, создание пост-эффектов и т. Д.При 40 FPS время, необходимое для рендеринга кадра, составляет 25 мс. Когда мы отключаем пост-эффект ambient occlusion и получаем 60 FPS, эта частота кадров соответствует времени кадра 16,7 мс. Фактически, на визуализацию кадра на визуализацию окружающей среды ушло 8,33 мс времени.
Когда мы имеем 20 кадров в секунду, это соответствует времени кадра 50 мс. Отключение окружающей окклюзии по-прежнему дает нам 8,33 мс. Окружающая окклюзия не будет быстрее или медленнее в зависимости от измерения частоты кадров. В этом случае время нового кадра будет 50 — 8.33 = 41,7 мс. Это соответствует частоте кадров 24 кадра в секунду.
Вместо того, чтобы думать о том, сколько выигрывает каждая оптимизация по частоте кадров, подумайте, сколько выиграет время кадра.
Это означает, что частота кадров не является линейной по отношению к производительности [5]. Для перехода с 20 до 30 кадров в секунду требуется оптимизация примерно на 16,7 мс. Это такой же прирост производительности при оптимизации, который требуется для перехода с 30 до 60 кадров в секунду.
Теперь, когда мы измеряем время смены кадров, а не частоту кадров, нам все еще нужен хороший способ обнаружения проблем с помощью измерений производительности.
Визуализация данных
Самый простой способ визуализировать, хорошо ли работает наше приложение, — это отобразить время кадра наших измерений на довольно плотном линейном графике.
Затем нам нужно увидеть, есть ли какие-либо аномалии в данных, и приблизить эти области, если мы хотим их выявить. При увеличении масштаба график можно изменить на гистограмму.
Проблема может заключаться в том, что если мы хотим визуализировать производительность в различных ситуациях, тогда линейный график будет слишком заполнен данными.В этом случае мы могли бы попробовать более эффективную статистическую меру, чем просто среднее значение (которое, как мы показали, проблематично). Например, мы могли бы визуализировать 99-й процентиль времени кадра [6]. Это означает, что мы находим время кадра, под которым приходится 99% измеренного времени. Если есть небольшое количество выбросов, они будут исключены, и мы сможем легко сравнить самые длинные времена кадра.
Тем не менее, это все еще скрывает проблему, если время кадра постоянно велико или если в данных много дрожания, что приводит к визуальному смещению.Хороший график, иллюстрирующий распределение данных, представляет собой коробчатую диаграмму.
На этих графиках показаны минимальный, максимальный, средний, 25-й и 75-й процентили измеренного времени кадра. Вы также можете создать эти графики так, чтобы вместо минимума и максимума вы использовали 1-й и 99-й процентили. Вы также можете отметить выбросы отдельными точками на графике.
Другой сюжет, который визуально легче читать, — это скрипичный сюжет. Он не показывает конкретной статистики, но достаточно интуитивно иллюстрирует распределение.
На этих графиках хорошо видны различные случаи. В некоторых случаях время кадра в среднем велико. В некоторых случаях оно в среднем мало, но данные сильно различаются, а некоторые кадры имеют большое время кадра.
Выбор графика зависит от варианта использования, но ниже приведены некоторые примеры коробок и скрипичных графиков равномерного распределения из [19, 20] и нормального распределения с (20, 0.3). Сами данные тоже здесь.
Следует отметить, что, поскольку сценарий скрипки использует оценку плотности ядра, он пытается оценить распределение.Таким образом, он также заполняет области, где нет реальных точек данных. С другой стороны, скрипичный график равномерного распределения, хотя эстетически неприятен, показывает, что все значения распределены равномерно. Единый прямоугольный график показывает, что 50% значений находятся в диапазоне от 20,5 до 19,5, но не говорит прямо, где находятся остальные 50%. Всегда думайте, какие данные теряются и какие аспекты данных выделяются при визуализации.
Таким образом, при измерении эффективности не указывайте одно число.Лучше попытайтесь описать поведение вашего приложения с помощью измеренных данных о производительности. Описывая прирост производительности, убедитесь, что вы правильно его оцениваете.
Список литературы
[1] Частота кадров: руководство для начинающих. Дуг Бруннер, TechSmith, 2018.
https://www.techsmith.com/blog/frame-rate-beginners-guide/
[2] Иллюзия движения. Пол Бакаус, 2014.
https://paulbakaus.com/tutorials/performance/the-illusion-of-motion/
[3] Важность частоты кадров.IrisVR.
https://help.irisvr.com/hc/en-us/articles/215884547-The-Importance-of-Frame-Rates
[4] Внутри второго: новый взгляд на бенчмаркинг игр. Скотт Уоссон, Технический отчет, 2011 г.
https://techreport.com/review/21516/inside-the-second-a-new-look-at-game-benchmarking
[5] Руководство по оптимизации приложений Mali GPU. ARM, 2011.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0555a/BEIGDEGC.html
[6] Там, где цифры минимального FPS вводят в заблуждение, лучше всего подходит анализ времени кадра.Джефф Кампман, Технический отчет, 2017.
https://techreport.com/review/31546/where-minimum-fps-figures-mislead-frame-time-analysis-shines
: почему важен анализ времени кадра
Анализ производительности видеокарты обсуждался уже много лет. В обсуждениях фанатов во всемирной паутине постоянно поднимается вопрос — что лучше?
Как определить «лучшее»? Качество изображения? Поддержка драйверов? Цена? Единственная область, которая, по общему мнению, может разделять две видеокарты, — это количество кадров в секунду.Этот метод использовался в течение многих лет и по большей части является / был общепринятым методом измерения производительности видеокарты. Действительно, в настоящее время мы сами пользуемся этим методом. Однако есть изменение, в результате которого FPS больше не является единственным методом измерения качества графического процессора.
Проблема с FPS
Хотя измерение кадров в секунду может быть очень хорошим средством измерения скорости графического процессора, оно, как мы увидим, может дать ложное представление об игровом процессе.Измерение FPS осуществляется путем подсчета количества кадров, отрисованных за секунду. Очевидно, что мы недостаточно быстры, чтобы сделать это сами, поэтому мы обычно будем использовать какой-либо инструмент тестирования производительности, например FRAPS. Затем этот инструмент будет использоваться в течение времени, например 60 секунд. Затем общее количество кадров за каждую секунду усредняется за 60-секундный период, чтобы получить среднее значение FPS. То, что метод измерения кадров в секунду нам не покажет, это то, что обычно называют «микровыбросом».
Micro Stutter
Я думаю, можно с уверенностью предположить, что большинство геймеров когда-нибудь сталкивались с микро-заиканием, особенно те, кто использует настройку с несколькими графическими процессорами. Микро-заикание — это термин, используемый для описания ситуации, когда игровой процесс плавный, когда регулярный рендеринг FPS внезапно прерывается из-за большого падения FPS, затем сразу возвращается к нормальному состоянию, затем снова падает и снова увеличивается. Это «заикание» может происходить в течение миллисекунд и чаще всего «ощущается» игроком, а не непосредственно засвидетельствовано из-за минутной шкалы времени.Это микро-заикание испортит игровой процесс.
Представьте, что новейшая видеокарта выдает «в среднем» 100 кадров в секунду в вашей любимой игре. Вы будете в восторге от этой новой карты и, прочитав последние обзоры, броситесь ее покупать. Поиграв в эту игру на новом оборудовании, вы остались немного недовольны. На собственном тестировании вы подтверждаете, что она действительно дает 100 кадров в секунду, однако игровой процесс кажется «нестабильным» по сравнению с вашей предыдущей картой, которая выдавала только 60 кадров в секунду.Почему это? Проще говоря, вы вполне можете столкнуться с микро-заиканием.
Все очень хорошо, если графический процессор выдает высокий средний FPS, но если этот средний показатель FPS маскирует случайные огромные падения FPS, то игровой процесс, вероятно, будет менее удовлетворительным, чем графический процессор, который способен отображать кадры в более последовательным образом, хотя в среднем и медленнее. Под этим я подразумеваю более низкое «общее» среднее значение FPS.
В крайнем случае, скажем, у вас есть графический процессор, способный выдавать 100 кадров в секунду.Для 59 секунд из 60-секундного теста зафиксировано очень маленькое время кадра — 10 мс. Это означает, что в течение 59 секунд ваша игра будет похожа на нож для масла. Однако для одного кадра графический процессор останавливается и приводит к значительному увеличению времени кадра до 999 миллисекунд. При измерении FPS это вряд ли повлияет на среднее измерение FPS, поскольку оно будет замаскировано отличным подсчетом FPS, однако при измерении времени кадра это будет сразу заметно.
Микро-заикание не следует путать с неизбежными провалами и пиками производительности в играх из-за способности рендеринга FPS.Некоторые сцены, особенно в играх с интенсивной графикой, таких как Crysis 3, более требовательны, и поэтому будет происходить падение FPS. Если это падение достаточно велико, оно будет заметно на экране и иногда может «ощущаться» как микрорельеф, из-за которого частота кадров настолько низкая, что игра «кажется» нестабильной. Это просто проблема производительности, и ее можно решить, снизив настройки графики.
Микро-заикание — явление не новое. Как и измерение FPS, этот предмет обсуждается в течение многих лет и, безусловно, является распространенной проблемой для конфигураций с несколькими графическими процессорами, таких как Crossfire (AMD) и SLI (NVIDIA).Конфигурации с несколькими графическими процессорами ужасно страдают от микропереключений просто из-за способа рендеринга графики, который усугубляет уже присущую им проблему. Это не значит, что проблема также встречается с решениями с одним графическим процессором, поскольку, как мы увидим, независимо от того, сколько графических карт у вас есть в системе вашего ПК, микрорельефное заикание — это проблема, которую должен учитывать каждый.
Анализ времени кадра — тоже не новая концепция, хотя до недавнего времени немногие сайты с обзорами использовали его как метод измерения производительности графического процессора.Фантастическая работа Скотта Уоссона в The Tech Report, которому следует отдать должное, показала нам, что анализ времени кадра так же важен, как и прямая производительность FPS, если не больше, и, следовательно, заслуживает похвалы за появление этого феномена. вернуться на передний план оценки производительности графического процессора.
кадров в секунду: A общепринятый, но ошибочный показатель производительности игрыОдин из наиболее распространенных способов обеспечить простое измерение графики. производительность в названиях игр — это частота кадров, выраженная в кадрах в секунду. Однако эта мера может быть довольно обманчивой, особенно с сегодняшними более быстрыми видео оборудование. Хотя это может обеспечить некоторую производительность, когда приходит к заключению об оптимизации, FPS — очень плохой способ измерение производительности приложений. Нелинейность значений FPSПроблема с использованием FPS для измерения производительности, с математической перспектива, заключается в том, что она нелинейна. Но прежде чем я пойду туда, давайте посмотрим по-другому: проще говоря, он задает неправильную сторону вопроса. При оценке производительности кода в приложении для рендеринга в реальном времени Проблема в том, сколько времени требуется для рендеринга каждого кадра и сколько времени части кода способствуют этому. Однако у FPS есть и обратная сторона медали. этого вопроса: это все равно, что спросить, сколько времени потребовалось, чтобы добраться из пункта А в пункт B, и ему сказали, что машина двигалась со скоростью 60 миль в час. Хорошо, если мы знаем расстояние от точки A до точки B и можем вычислить его, но это не то, что мы спросил! Может показаться, что я немного придирчив к деталям и честная часть этого исходит из любимой мозоли.А именно то, что похоже на не реже одного раза в неделю я вижу вопрос по теме:
Или обычная вариация на эту тему:
Эй, заметили, что здесь что-то происходит? Время меняется линейно с количество визуализированных объектов, но не частота кадров! На самом деле это сильно нелинейный, как показано на приведенном выше графике, который отображает частоту кадров из время выполнения от 1 миллисекунды до 40 миллисекунд.Теперь, чтобы проиллюстрируйте, насколько радикально это может исказить восприятие производительности, вы думаю, что человек, жалующийся выше, отреагирует таким же образом на падение с 60FPS до 56,25 кадра в секунду? Наверное, нет, я думаю … но посмотрите это:
Видя такое несоответствие, можно понять, насколько плохие выводы можно сделать, особенно при сравнении методов в разных контекстах. Например, если один метод в приложении вызвал падение с 900 до 450 кадров в секунду, а другой метод в другой движок привел к падению с 60 FPS до 55 FPS, что, как вы могли подумать, более дорогой? Если вы обращали внимание, вы должны подозревать, что падение на 5 кадров в секунду свидетельствует о большей стоимости производительности, чем падение на 450 кадров в секунду. первым способом! Фактически, падение на 5 кадров в секунду соответствует 36.На 4% больше время выполнения, чем падение 450FPS! Так что примите это как пищу для размышлений, если вы в настоящее время используете счетчик FPS в качестве мера вашей производительности. Если вам нужна быстрая индикация производительность между сеансами профилирования, вместо этого используйте время кадра. В DX9 framework, например, вы можете изменить CD3DApplication :: UpdateStats (), чтобы использовать что-то вроде: _sntprintf (m_strFrameStats, cchMaxFrameStats, До следующего раза ….
|
Частота кадров: руководство для начинающих
Начало работы с видео может быть немного пугающим, особенно когда вы слышите так много технических терминов, как частота кадров или fps.
Даже если вы слышали о частоте кадров, бывает трудно сказать, какой вариант лучше всего подходит для ваших видео. В конце концов, при выборе частоты кадров необходимо учитывать множество факторов.
Не волнуйтесь! Мы разбили определение частоты кадров и объяснили, почему это важно, в простом для понимания руководстве.
Вот что вы узнаете:
Что такое частота кадров?
Помните те классные маленькие флипбуки, где в блокноте на каждой странице было изображение, и когда вы быстро пролистывали страницы, казалось, что изображение оживлялось и двигалось?
Вот как работает видео. Будь то цифровой или олдскульный фильм, видео — это серия неподвижных изображений, которые при просмотре по порядку с определенной скоростью создают впечатление движения.Каждое из этих изображений называется «рамкой».
Частота кадров — это скорость, с которой отображаются эти изображения, или насколько быстро вы «пролистываете» книгу. Обычно это выражается как «количество кадров в секунду» или FPS. Таким образом, если видео захватывается и воспроизводится со скоростью 24 кадра в секунду, это означает, что каждая секунда видео показывает 24 отдельных неподвижных изображения.
Скорость, с которой их показывают, заставляет ваш мозг воспринимать плавные движения.
Почему частота кадров имеет значение?
Частота кадров сильно влияет на стиль и качество просмотра видео.Разная частота кадров дает разные впечатления от просмотра, и выбор частоты кадров часто означает размышление о нескольких факторах, например о том, насколько реалистично вы хотите, чтобы ваше видео выглядело, или планируете ли вы использовать такие методы, как замедленное движение или эффекты размытия при движении.
Например, фильмы в голливудском стиле обычно отображаются с частотой 24 кадра в секунду, поскольку эта частота кадров аналогична тому, как мы видим мир, и создает очень кинематографический вид. Прямые трансляции или видео с большим количеством движений, например спортивные соревнования или записи видеоигр, часто имеют более высокую частоту кадров, потому что много всего происходит одновременно.Более высокая частота кадров обеспечивает плавность движения и четкость деталей.
С другой стороны, люди, которые создают анимированные GIF-файлы, часто жертвуют деталями ради меньшего размера файла и выбирают низкую частоту кадров.
Как выбрать лучшую частоту кадров для моего видео?
Во-первых, не бывает «лучшей» частоты кадров. Как указывалось выше, разная частота кадров дает разные результаты, поэтому выбор лучшего означает выбор варианта, который лучше всего соответствует тому, что вы пытаетесь создать.
Несмотря на то, что частота кадров является относительно простой концепцией, существует немало споров по поводу того, какая частота обеспечивает наилучшее качество просмотра, и есть исследования, которые подтверждают практически любую частоту кадров. Если оставить в стороне противоречия, вот четыре вещи, которые нужно учитывать при выборе частоты кадров.
Стиль / Реализм
Частота кадров видео сильно влияет на внешний вид видео, что, в свою очередь, определяет, насколько реалистично оно выглядит.Эта концепция напрямую связана с нашим естественным восприятием мира.
Когда мы видим движение, например, человека, бросающего мяч или проезжающего мимо автомобиля, мы, естественно, видим некоторое размытие движения. В идеале выбранная частота кадров имитирует это размытие при движении, сохраняя максимально реалистичный опыт. Если вы выберете слишком высокую частоту кадров, все начнет выглядеть неестественно, а видео пострадает от так называемого «эффекта мыльной оперы».
По сути, видео показывает слишком много деталей, что делает его неестественным.С другой стороны, если вы выберете слишком низкую частоту кадров, видео начнет выглядеть прерывистым и будет ухудшать восприятие. Чтобы понять, какая частота кадров вам подходит, давайте рассмотрим несколько распространенных вариантов и способы их использования.
24 кадра в секунду — это стандарт для фильмов и телешоу, и он был определен как минимальная скорость, необходимая для захвата видео при сохранении реалистичного движения. Даже если фильм снимается с более высокой частотой кадров, он часто создается и отображается со скоростью 24 кадра в секунду.Большинство художественных фильмов и телешоу снимаются и просматриваются со скоростью 24 кадра в секунду.
30 кадров в секунду — Это был стандарт для телевидения с первых дней и до сих пор широко используется, несмотря на то, что продюсеры движутся в сторону более кинематографических 24 кадров в секунду. Видео с большим количеством движения, например спортивные, часто выигрывают от дополнительных кадров в секунду.
Причины использования 30 кадров в секунду на удивление сложны, и в основном это связано со стандартами телевидения и электричества, установленными давным-давно. Если вы хотите узнать больше, ознакомьтесь с этой статьей о частоте кадров и перейдите к разделу «Современные стандарты видео.”
60 + fps — Все, что выше 30 кадров в секунду, в основном используется для создания замедленного видео или для записи видеоигр. Кроме того, по мере развития технологий многие смартфоны теперь также могут записывать со скоростью 60 кадров в секунду.
Движение
Следующая ключевая переменная, которую следует учитывать при выборе частоты кадров, — это количество движения в вашем видео. Это довольно просто. Если у вас много движения, вы, вероятно, захотите снимать с более высокой частотой кадров.
Это не обязательно означает, что вы хотите, чтобы создавал с более высокой частотой кадров, но захват с более высокой частотой кадров обеспечивает более высокий уровень детализации для количества захваченного движения. Более высокая частота кадров также обеспечивает большую гибкость при редактировании. Вот несколько распространенных вариантов, которые помогут вам решить, что лучше для вас.
24 кадра в секунду — Как указано выше, это минимальная скорость, необходимая для захвата видео с сохранением реалистичного движения.Если вы снимаете действительно загруженную сцену со скоростью 24 кадра в секунду, вы увидите много размытия при движении.
30 кадров в секунду — Если на шесть кадров в секунду больше, чем при 24 кадрах в секунду, вы увидите больше деталей в сценах с высокой динамикой; однако движение начнет выглядеть немного неестественно и пострадает от «эффекта мыльной оперы».
60 + кадров в секунду — Все, что выше 30 кадров в секунду, обычно зарезервировано для записи загруженных сцен с большим количеством движений, таких как видеоигры, легкая атлетика или все, что вы хотите показать в замедленной съемке.
Геймеры записывают с такой скоростью, потому что на их экране одновременно происходит много всего, и чем больше кадров, тем больше деталей. Спорт часто записывается с высокой частотой кадров, поэтому их можно замедлить, чтобы показывать повторы, сохраняя при этом четкое и ясное видео.
Доставка
Способ доставки видео, например, через YouTube или телевещание, и устройство, которое человек использует для просмотра вашего видео, могут сильно повлиять на параметры, которые у вас есть для частоты кадров.
Не все устройства и способы доставки поддерживают все значения частоты кадров, поэтому лучше разобраться с этим, прежде чем начинать съемку.
Чтобы облегчить доставку, давайте рассмотрим несколько наиболее распространенных мест, где люди смотрят видео, и то, как они доставляются.
Потоковое видео в Интернете
Это быстро становится наиболее распространенным способом доставки видео, и многие потоковые сервисы поддерживают широкий диапазон частот кадров. Зрители, как правило, более спокойно относятся к частоте кадров в Интернете; однако важно помнить, что старые телевизоры и компьютерные мониторы могут не иметь частоты обновления экрана, которая могла бы работать с более высокой частотой кадров.
Телевидение
Когда вы создаете видео для телевидения, лучше всего выбирать между 24 и 30 кадрами в секунду. Это гарантирует, что ваши видео будут выглядеть реалистично и соответствовать ожиданиям людей от телевещания. Прямые трансляции, такие как новости и спорт, почти всегда снимаются со скоростью 30 кадров в секунду, тогда как телешоу и фильмы обычно снимаются с частотой 24 кадра в секунду.
Кинопроекторы
Кинотеатры и проекторы в целом по-прежнему остаются невероятно популярным способом просмотра видео. Как и в случае телетрансляций, частота кадров должна составлять 24 кадра в секунду.Это придаст вашему видео «кинематографический» вид, и вы можете быть уверены, что оно будет правильно отображаться на большинстве проекторов.
Размер файла и время экспорта
Последними факторами, которые следует учитывать при выборе частоты кадров, являются размер файла и время экспорта. Эти два варианта довольно просты — чем выше частота кадров, тем больше неподвижных изображений упаковывается в каждую секунду видео.
Чем больше изображений, тем больше информации, а чем больше информации, тем больше файлы и время экспорта.Это особенно важно учитывать при загрузке видео на сайты потокового онлайн-вещания, такие как YouTube, Vimeo и Screencast.
Видео более высокого качества всегда желательно, но файлы большего размера требуют лучшего подключения к Интернету и компьютерного оборудования для потоковой передачи с высочайшим качеством. Это означает, что люди, у которых нет самого современного оборудования или самых быстрых услуг, могут страдать от плохого опыта.
Простое создание и редактирование видео профессионального качества
TechSmith Camtasia упрощает создание и редактирование видео даже для новичков.
Загрузите бесплатную пробную версию!
Заключительные мысли
Выбор частоты кадров требует некоторого размышления, и если вы примете во внимание четыре ключевых момента, описанных выше, вы добьетесь успеха. Если вы хотите поэкспериментировать с частотой кадров и узнать больше о том, как они работают, этот сайт предлагает несколько интересных способов поэкспериментировать.
Выходите и снимайте отличные видео! Посмотрите видео ниже, чтобы получить отличное пошаговое руководство по созданию вашего первого видео с TechSmith Camtasia.
Часто задаваемые вопросы
Одна частота кадров лучше, чем другая?Это зависит от того, над каким типом проекта вы работаете! См. Разделы выше, чтобы узнать о различных значениях частоты кадров и о том, для чего они обычно используются.
Сколько кадров в секунду может видеть человеческий глаз?Большинство людей могут видеть около 30-60 кадров в секунду.
Примечание редактора. Этот пост был первоначально опубликован в марте 2017 года и был обновлен для обеспечения точности и полноты.
Скорость считывания и частота кадров
Считывание и частота кадров
Скорость считывания определяется как величина, обратная времени последовательного преобразования, то есть времени, необходимому для оцифровки одного пикселя. Скорость считывания обычно указывается в пикселях в секунду (например, 500 килопикселей в секунду).
Частота кадров — это величина, обратная времени, необходимому ПЗС-матрице для получения изображения и последующего его полного считывания. Частота кадров обычно выражается в кадрах в секунду (fps).Часто частоту кадров можно приблизительно рассчитать из общего количества пикселей и скорости считывания в сочетании с общим временем экспозиции. В частности:
упрощенная частота кадров = 1 / (количество пикселей / частота дигитайзера + время получения кадра) в кадрах в секунду
Однако есть ряд других факторов, которые могут существенно повлиять на частоту кадров в зависимости от условий эксплуатации.
Чтобы лучше понять частоту кадров, мы определим две другие величины, называемые временем получения кадра , (FAT) и временем чтения кадра , (FRT), которые будут учитывать все эти факторы.Тогда частота кадров определяется как:
.- истинная частота кадров = 1 / (время получения кадра + время считывания кадра)
- время получения кадра = (счетчик сбросов x время параллельного сброса) + открытие затвора + задержка закрытия + время экспозиции
- время считывания кадра = время последовательного сброса + (время параллельного сдвига x параллельный размер) + (время последовательного сброса x подмассив пикселей до и после) + (время последовательного преобразования x считываемые пиксели)
Давайте теперь посмотрим, что означают некоторые из этих параметров.
Чистый счетчик и время параллельной очистки: В зависимости от условий применения может потребоваться очистить ПЗС-матрицу от накопленного заряда перед получением изображения. Источниками этого накопленного заряда могут быть темновой ток и даже события космических лучей. Возможно, придется очищать массив несколько раз, чтобы полностью избавиться от заряда (в новых ПЗС-матрицах это обычно делается от 1 до 3 раз). Счетчик очистки определяется как количество раз, когда выполняется очистка заряда, а время параллельной очистки — это время, необходимое для выполнения каждого сброса.Поскольку необходимо только очистить заряд, а не оцифровать, параллельное время сброса занимает меньше времени, чем обычное считывание.
Последовательное время очистки: Как и в случае с параллельным регистром, иногда может потребоваться очистить последовательный регистр накопленного заряда перед переносом заряда из параллельного регистра. Это серийное ясное время.
Время параллельного сдвига и параллельный размер: Время параллельного сдвига — это время, необходимое для сдвига одной строки пикселей в последовательный регистр во время считывания изображения.Если выполняется бинирование, его необходимо затем умножить на параллельный размер суперпикселя, чтобы получить общее время, необходимое для сдвига заряда.
Последовательное время отбрасывания: При чтении подматрицы с ПЗС может возникнуть необходимость отбросить пиксели как до, так и после интересующей области. Время последовательного сброса — это время, необходимое для достижения этой цели. Кроме того, регистры последовательного интерфейса на большинстве ПЗС имеют ряд пикселей (обычно от 20 до 50), помещенных между частью данных последовательного массива и выходным усилителем.Эти пиксели должны быть отброшены перед чтением данных.
Значимость этих факторов сильно зависит от конкретных условий использования ПЗС-матрицы. В следующих примерах мы приводим FAT, FRT и последующую частоту кадров, рассчитанную с учетом всех факторов, и сравниваем ее с упрощенной частотой кадров (полученной с использованием количества пикселей, деленного на скорость считывания плюс время экспозиции).
Как можно видеть, иногда наблюдаются большие различия в результатах, особенно при чтении подматриц или чтении ПЗС на очень высоких скоростях.
.