Формула f p s: Показатели игровой производительности — что такое средний, 1% и 0.1% низкие FPS

Показатели игровой производительности — что такое средний, 1% и 0.1% низкие FPS

Этот материал написан посетителем сайта, и за него начислено вознаграждение.

За последние годы можно наблюдать всё растущее понимание, что одного только среднего FPS по какой-либо выбранной для целей тестирования игровой сцене недостаточно для описания производительности компьютерной системы, а минимальный и максимальный FPS в этом деле совсем не помощники. Давайте разберёмся, в чём недостаток среднего FPS, чем так плох минимальный FPS, а также познакомимся с набравшими популярность более удачными мерилами игровой производительности — показателями 1% и 0.1% низкие FPS.

Кадр из ролика What Are 1% & 0.1% Lows? канала Gamers Nexus

Время кадра, мгновенный и средний FPS

Отрисовка каждого кадра в игре занимает некоторое время, которое называется, временем отрисовки кадра, или, коротко, временем кадра (frame time). Исчисляется время кадра обычно в миллисекундах (мс), т.е. тысячных долях секунды. Однако в игровых бенчмарках вместо этой характеристики много чаще используется частота смены кадров или, коротко, частота кадров (frame rate), равная количеству кадров, отрисованных за единицу времени. Измеряется частота кадров в количестве кадров в секунду (frames per second, fps), и для краткости частоту кадров также очень часто также именуют аббревиатурой от названия её единицы измерения, т.е. FPS.

Между временем кадра и частотой кадров есть очевидная математическая связь: значение FPS, подсчитанное непосредственно после отрисовки очередного кадра, именуемое обычно мгновенным FPS, есть величина обратная времени этого кадра:

рекомендации

Необходимо только учесть, что время кадра обычно исчисляется в миллисекундах, а частота кадров в единицах в секунду, поэтому итоговая формула для мгновенного FPS будет такова:

Так, например, если очередной кадр был отрисован, скажем, за 16 мс, то сразу по окончании его отрисовки мгновенный FPS был равен 1000/16 = 62. 5 кадра в секунду.

---

Но главное мерило производительности, это, конечно же, средний FPS по всей игровой сцене, который с одной стороны представляет собой не что иное, как количество кадров n, отрисованных за всё время бенчмарка t

С другой же стороны, средний FPS можно вычислить как величину, обратную среднему времени кадра

В справедливости утверждения, что средний FPS, вычисленный таким образом, совпадает с данным выше определением убедиться нетрудно, ведь время отрисовки всех кадров равно времени бенчмарка

---

Впрочем, всё это, в каком-то смысле, очевидно. А вот что совсем не так очевидно, так это то, что средний FPS не является средним арифметическим значений мгновенного FPS

Математически убедиться в этом, впрочем, опять же несложно: нетрудно заметить, что выражение в левой части неравенства выше

хотя и имеет что-то общее с выражением в правой

но ему в общем случае не равно.  При ближайшем рассмотрении видно, что равенство будет иметь место лишь в частном случае, когда все t_i равны между собой (t₁=t₂=…=t_n), то есть когда значения времени всех кадров идентичны, что, конечно же, практически невозможно.

---

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

помимо всем хорошо знакомого среднего арифметическогосуществует ещё несколько средних величин, из которых нам интересна здесь лишь одна, а именно, среднее гармоническоеЕсли словами, то среднее гармоническое по некоторому набору чисел есть обратная величина к среднему от обратных к числам  величинам. Звучит, конечно, несколько кошмарно, и не очень понятно, зачем вообще нужно, но сейчас разберёмся. Давайте сразу скажем, что в общем и целом две обсуждаемые средние величины не равны друг другу, за исключением частного случая равенства всех чисел в наборе, x₁=x₂=…=x_n, того самого  случая, который для среднего FPS мы отмечали выше.

Так же как и среднее арифметическое, среднее гармоническое находит своё применение в ряде практических задач. Так, например, если некоторый объект несколько раз подряд преодолевает одно и тоже расстояние с разной скоростью, то его средняя скорость на всём пути есть среднее гармоническое скоростей на всех участках. То есть если n раз проехать расстояние d со скоростями v₁, v₂, …, v_n, то время прохождения каждого отрезка составит t_i = d/v_i, а средняя скорость, равная по определению отношению длины пути, пройденного телом, ко времени, за которое этот путь был пройден, будет равна

т.е. среднему гармоническому скоростей, а не их среднему арифметическому. Например, если Вы по пути на дачу на первом километре попали в “пробку” и двигались со скоростью 30 км/ч, а на втором километре “затор” рассосался и Вы “втопили” уже «под 90», то средняя скорость за 2 километра составила, 2 / (1/30 + 1/90) = 45 км/ч, а не (30 + 90) / 2 = 60 км/ч, в чём легко убедиться. Смотрите, Вы проехали 2 км, и если бы Ваша средняя скорость была равна 60 км/ч, то на дорогу у Вас ушло бы всего навсего 2 км / 60 км/ч = 1/30 ч, т.е. 2 минуты. В реальности же только на первый километр Вы уже потратили 1 км / 30 км/ч = 1/30 ч, эти самые 2 минуты, а затем ещё 1 км / 90 км/ч = 1/90 ч (чуть меньше минуты) ушло на второй километр.

Вообще, среднему арифметическому от скоростей средняя скорость равна лишь тогда, когда тело двигалось с этими скоростями одинаковые промежутки времени, а не одинаковые участки пути, но это уже, как должно быть понятно, не наш случай. Почему? Здесь всё просто — мгновенный FPS суть есть скорость смены кадров на участке длиной в 1 кадр, а не продолжительностью в 1 секунду, а значит и среднюю скорость (средний FPS) следует считать как среднее гармоническое значений мгновенного FPS, а не их среднее арифметическое.

Минимальный, 1% и 0.1% низкие FPS

Что ж, со средним FPS разобрались, едем дальше. Собственно, очень давно известно, что использование каких-либо средних величин в качестве единственных характеристик некоего набора данных — всегда плохая идея. Так, например, в нашем конкретном случае необходимо понимать, что время каждого кадра напрямую зависит от его сложности, и периодически в игре могут встречаться кадры со сложностью, существенно превышающей среднюю, на отрисовку которых, как следствие, уходит заметно больше времени. В результате такие “длинные” кадры задерживаются на экране существенно дольше и могут приводить к визуально заметным “подтормаживаниям” и “фризам”, способным испортить всё удовольствие от игры. И тут надо понимать, что такие “длинные” кадры часто бывают редкими, и проблема использования среднего FPS и состоит как раз в том, что в процессе усреднения значений времени кадра информация о “длинных” редких кадрах теряется.

Поясню на небольшом примере. Пускай, за 1 секунду игрового времени было отрисовано 30 кадров со следующими значениями времени отрисовки в мс:

48, 35, 33, 31, 14, 38, 29, 24, 17, 16, 90, 21, 43, 36, 19, 22, 10, 11, 37, 26, 28, 18, 27, 98, 50, 47, 25, 42, 44, 21

Среднее время кадра равняется 33 мс, а средний FPS — 30 кадрам в секунду. Казалось бы, всё неплохо, но обратите внимание на присутствие парочки очень “длинных” кадров (выделенных жирным шрифтом) со временем отрисовки втрое большим среднего, а именно, 90 и 98 мс. При усреднении значений времени кадров информация о наличии столь “длинных” пускай и редких кадров была потеряна, и в результате полученные средние величины вроде бы сигнализируют о достижении минимального порога играбельности, но на деле визуально заметные “просадки” и “фризы” при подобного рода наборах значений времени кадра неизбежны.

Чем же дополнить средний FPS, чтобы лучше описать весь набор значений времени кадров? Возможно, минимальным значением? Нет, не стоит. Дело в том, что минимальный мгновенный FPS, как любой единичный элемент набора данных, может оказаться грубым выбросом. Например, минимальное значение мгновенного FPS может оказаться таковым не по причине сложности соответствующего кадра, а из-за внешних факторов, например, запланированного старта какой-нибудь службы Windows ровно в момент отрисовки этого кадра. При этом, устранить все внешние факторы, которые могут повлиять на единичное значение мгновенного FPS, практически невозможно, и, что важнее, этого и не требуется, при грамотном подходе к описанию имеющегося набора данных. Но каков же этот грамотный подход? 

В математической статистике существует понятие процентиля, которое для наших целей можно определить как значение, ниже которого находится определённый процент данных из набора. Например, 99-процентиль — значение, ниже которого находятся 99% данных из набора. В нашем примере с 30 кадрами, отрисованными за 1 с, 99-процентиль равен 96 мс, и означает это, что 99% значений времени кадра из нашего набора меньше 96 мс, и лишь 1% больше или равен этому значению. Обратите особое внимание, что в нашем конкретном случае из-за малого числа данных в наборе существенной разницы между минимальным значением и 99-процентилем нет, и, как следствие, 99-процентиль здесь ничем не лучше минимального значения в отношении грубых промахов. По сути из всего нашего набора данных лишь единственное значение (минимальное) и не попало “под” 99-процентиль. Однако, если набор данных будет существенно больше, скажем, будет содержать время отрисовки нескольких тысяч кадров, то “длинных” кадров, не попадающих “под” 99-процентиль будет уже порядка нескольких десятков и вместо единственного минимального значения, которое, возможно, является грубым выбросом, у нас будет иметься уже какая-никакая статистика по всем редким “длинным” кадрам. Это обеспечит не только более адекватное описание набора данных, но и значительно лучшую воспроизводимость результатов.

Надеюсь, теперь понятно, чем так хороши процентили, и здесь осталось прояснить лишь какие конкретно процентили использовать. И тут всё, по большому счёту, определяется негласными соглашениями в какой-либо области, и в игровых бенчмарках де-факто стандартом стали 99- и 99.9-процентили времени кадра. Точнее, как уже отмечалось выше, в игровых бенчмарках обычно приводят значения FPS, поэтому и вместо 99- и 99. 9-процентилей времени кадра в результатах обычно фигурируют обратные им 1- и 0.1-процентили FPS, именуемые 1% низкий FPS и 0.1% низкий FPS, соответственно. При этом следует понимать, что 1% и 0.1% от всего набора данных — это лишь небольшая часть данных, описывающая редкие и крайне редкие игровые события. Поэтому в самом факте, что 1% низкий FPS и 0.1% низкий FPS оказываются зачастую значительно ниже среднего FPS нет ничего страшного — такая картина лишь говорит о том, что сложность кадров в игровой сцене непостоянна, что совершенно нормально. Плохо лишь, если обсуждаемые показатели «просаживаются» на конкретной игровой системе слишком сильно, выходя за границы играбельности, так как в этом случае нас ожидают визуальные неприятности.

Последнее, о чём, пожалуй, стоит ещё обмолвиться, перед тем, как перейти к выводам, так это так называемый средний за секунду (или по секунде) FPS, а также характеристики на нём основанные, например, минимальный средний за секунду FPS. Этот «зверь», впрочем, простой: средний за секунду FPS — это просто средний FPS на отрезке в 1 с. Равен он количеству кадров, отображённых за одну прошедшую конкретную секунду, но, так же как и средний FPS за всё время бенчмарка, может быть посчитан и как среднее гармоническое значений мгновенного FPS за эту конкретную секунду. Обычно, именно средний за секунду FPS и отображают на экране различные счётчики частоты кадров наподобие FRAPS, так как значение мгновенного FPS пришлось бы обновлять настолько часто, что в этом месиве всё равно бы никто ничего не разобрал. Использовать же значения среднего за секунду FPS вместо значений FPS мгновенного для более детального анализа бессмысленно, так как наиболее важная информация о времени отрисовки «длинных» кадров в них уже потеряна (см. пример выше). А касательно минимального среднего за секунду FPS упомянем лишь, что он, в отличие от минимального мгновенного FPS, может быть больше, скажем, 0.1% низкого FPS, что периодически порождает путаницу и неразбериху.

Выводы

1. Одного лишь среднего числа кадров в секунду в результатах тестов игровой производительности не достаточно. Это единственное значение (как, в принципе, и любое другое) никак не способно описать всю картину в целом, зачастую упуская крайне важные детали.
2. Дополнять среднее число кадров минимальным и максимальным бессмысленно, так как эти единичные значение из набора данных статистически не устойчивы, а максимальное число кадров ещё и в целом показатель бесполезный.
3. Значительно лучше дополнять среднее число кадров значениями процентилей, например, 1% низким FPS и 0.1% низким FPS, детально обсуждаемыми в тексте статьи. При этом дополнительно указывать ещё и минимальный FPS вместе с процентилями — глупость, так как весь смысл процентилей и состоит как раз в том, чтобы не опираться на статистически недостоверный показатель минимального числа кадров.
4. Конечно, при небольшом количестве сравниваемых систем (2–3) можно приводить и сами графики (или гистограммы) времени кадра, дающие возможность увидеть все детали игровой производительности участников сравнения, но при большем количестве конфигураций такой подход уже не сработает, так как визуально разобрать что-то будет уже крайне сложно.
   Поэтому наиболее универсальны способ — приводить в результатах значения среднего, 1% низкого и 0.1% низкого FPS.
5. Для накопления значений времени кадров можно использовать всем известную утилиту FRAPS, однако, у неё имеется ряд ограничений, например, отсутствие поддержки современных API (DirectX 12, Vulkan). Значительно лучше в этом плане смотрится свободный инструмент PresentMon, который поддерживает все графические API и к тому же умеет работать с UWP-приложениями. Кстати, именно PresentMon накапливает значения времени кадров, информацию о которых затем отображают такие известные утилиты, как FrameView и OCAT.

Этот материал написан посетителем сайта, и за него начислено вознаграждение.

Разберёмся с кадрами в секунду

В этой заметке расскажу откуда появились 24 кадра в секунду, почему в США их 29,97. Зачем играм так много FPS и почему 25 кадр не работает.

Вступление

Любая анимация существует благодаря инертности зрения. Если изображения сменяются достаточно быстро, то мозг не видит их по отдельности, а создаёт иллюзию непрерывного движения. Скорость смены изображений должна быть выше 10-12 в секунду, иначе мозг воспринимает картинки по-отдельности. Казалось бы, вот и подходящая для человека кадровая частота — 12 FPS и больше. Но не всё так просто.

Немые фильмы

Представьте себе ленту немого фильма, в которой 1 500 отдельных изображений. Если мы покажем фильм со скоростью 12 кадров в секунду, то увидим что-то такое. Гифку сделал по ссылке, чтобы не раздражала мерцанием.

Движение есть, но мерцание в кадре всё портит. Оно появилось из-за того, что мы должны закрыть проектор, чтобы прокрутить ленту дальше и показать новое изображение. По словам Томаса Эдисона, наше зрение не заметит мерцание, если мы будем прокручивать ленту со скоростью 46 кадров в секунду. Но это не лучший вариант, и вот почему.

Сейчас у нас фильм состоит из 1 500 изображений и мы его проигрываем со скоростью 12 кадров в секунду.
Получается 1 500 кадров / 12 кадров в секунду = 125 секунд
Значит, нам достаточно 1 500 кадров, что создать двухминутный фильм.

Со скоростью 46 кадров в секунду наш фильм будет идти всего 32 секунды. То есть, чтобы восстановить хронометраж мы должны создать не 1 500 кадров, а 5 750 = 125 секунд * 46 кадров в секунду. Кинолента будет длиннее в четыре раза, количество кадров больше, а значит отснять, смонтировать и показать фильм выйдет намного дороже.

Легче изменить конструкцию проектора. Поэтому вместо обычного обтюратора поставили трёхлезвийный.

Теперь один кадр показывают три раза и только потом сменяют на новый. Получается частота кадров (хоть и одинаковых) увеличилась. Количество мерцания увеличилось по количеству, но в три раза сократилось по времени. Таким образом инертность зрения стала «съедать» мерцание в кадре.

Мы сменяем кадры со скоростью 16 FPS, но зрителям показываем один и тот же кадр три раза.
И получаем 48 спроецированных кадра в секунду = 16 кадров * 3 повторения. Прямо как и хотел Эдисон, даже лучше.

Мы взяли 16 FPS, а не 12 или 14, так как 16 — минимальное целое число, которое умножается на 3 и в результате даёт число больше 46.

Вот мы и получили первую кадровую частоту — 16 FPS для немых фильмов. Плюс немых фильмов в том, что мы можем легко увеличить или уменьшить количество кадров в секунду, это повлияет только на скорость воспроизведения. Ручку проектора крутил человек и мог варьировать скорость кадров от 14 до 26 FPS.

Звук

Всё сложнее стало со звуком. Теперь нельзя крутить фильм быстрее или медленнее. Нужно соблюдать постоянную кадровую частоту, чтобы скорость, а значит и тембр голоса не изменялся на протяжении фильма. С 16 FPS была проблема, звук не звучал точно, как задумывалось. Нужно было выбрать новую частоту, чтобы она была больше 16 и в итоге давала 48 проецируемых FPS. В итоге, вместо трёхлезвийного обтюратора стали использовать двулезвийный. И утвердили новый фрейм рейт — 24 FPS.

24 кадра * 2 повторения = 48 проецируемых кадров в секунду. Всё просто и удобно. 24 нацело делится на 2, 3 и 4. То есть мы знаем, что половина секунды — 12 FPS, треть — 8, а четверть — 6.

Тут вроде становится понятно — мы и сейчас используем 24 FPS. Тогда зачем нам 25, 30 и тем более 29,97?

Телевизор

Когда решили транслировать изображение по телевизору возникли новые проблемы. Показывать два раза один и тот же кадр было не вариант, да и технически это было сложновато. Ещё надо передать аналоговый сигнал по радиоволнам. И чем больше кадров, тем больше вес файла — значит канал передачи должен быть шире, а значит и дороже. Поэтому стали передавать кадры по половинкам — полукадрами. Разбиваем изображение на полосы и показываем сначала все нечётные, а потом все чётные. Инертность зрения делает своё дело и мы видим целый кадр.

Кадр из людей в чёрном 3

В телевизоре происходит то же самое, только намного быстрее.

По-умному, это называется чересстрочная развёртка и обозначается буквой «i», от слова «interlaced». Ролик с чересстрочной развёрткой и разрешением 1920 × 1080 будет называтся 1080i. А такой же ролик с прогрессивной развёрткой — 1080p. Это означает «progressive» или то, что кадры передаются целиком.

Чтобы не было лишних шумов и конструкция телевизора была проще, полукадры решили обновлять с частотой электросети. Для Европы это 50 Гц. Получилось 50 полукадров в секунду или 25 целых кадров в секунду. В США частота электросетей 60 Гц, значит полукадров будет 60, а кадров соответственно 30.

И вот вроде как всё хорошо, но тут появляется цвет.

Цвет

Теперь через тот же канал нужно донести больше информации. Мы должны передать чёрно-белое изображение для старых телевизоров, цветное изображение и звук. И сделать это было довольно сложно. Потому что как только мы добавляем в электромагнитный спектр информацию о цвете его частота пересекается со звуком и создаёт помехи. Чтобы чётко разделить цвет и звук решили снизить частоту полукадров на 0,1%.

60 полукадров — 0,1% = 59,94 полукадров в секунду
59,94 полукадров в секунду/2 = 29,97 кадров в секунду

Система вещания с такой странной кадровой частотой называется NTSC и использовалась в США и ещё парочке стран.

В Европе таких сложностей не было, в качестве стандарта сразу взяли PAL, который был создан, чтобы решить проблемы с цветом. Поэтому как было 25 кадров в секунду, так и осталось.

>30 FPS

Зачем же тогда делают фильмы в 60 FPS?
Дело в том, что камера размывает любое резкое движение в сторону направления объекта. Величина размытия зависит от расстояния, которое объект прошёл за 1 кадр. И чем больше количество кадров в секунду, тем меньше размытие.

1 секунда / 25 фпс = 0,04
1 секунда / 60 фпс = 0,016

Это называется моушн-блюр.

Разница между фильмами с 25 FPS и 60 FPS только в плавности движения. Резкие движения в фильме выглядят менее размытыми. За счёт этого картинка кажется более реалистичной. Вот в этом и смысл.

25 кадр

Представьте, что мы берём книгу в которой 24 страницы — 23 белые и 1 красная. Если мы пролистнём книгу за одну секунду, то точно заметим, что одна страница другого цвета. Если страниц в книге 25, то ничего не изменится. Страница не станет невидимой и тем более не будет влиять на подсознание, она просто пролистнётся не за 1/24 секунды, а за 1/25. Вот и вся разница. Даже если страниц будет больше 100 — глаз поймёт, что одна из них отличается. Абсолютно то же самое с видео.

Наше зрение не ограничивается считыванием какого-то определённого количества кадров в секунду. Различия между кадрами будут заметны и на двухстах, и на пятистах кадрах в секунду.

Слоумоушн и таймлапс

Слоумоушн это, когда мы снимаем видео с большей частотой кадров, а смотрим с меньшей — снимаем в 120, смотрим в 25.

Снимем на айфон 6 секунд в 120 FPS. Это значит, что за секунду он создаст 120 изображений. За 6 секунд — 720. А смотреть мы их будем в 25 FPS. Это значит, что 720 изображений / 25 FPS мы будем смотреть почти 29 секунд. За это время мы и рассмотрим все детали.

А если мы возьмём высокоскоростную камеру, снимем 1 секунду с фреймрейтом 5 000 FPS и посмотрим в 25 FPS.

5 000 * 1 / 25 = 200 секунд или 3 минуты 20 секунд

Одну секунду реального времени мы смотрим целых 3 минуты.

Можно в деталях рассмотреть выстрел пистолета под водой.

После таких расчётов становится понятно почему Slow Mo Guys не выкладывают свои ролики в 60 FPS. Мы просто увидим меньше деталей.

5 000 * 1 / 60 = 83 секунды или 1 минута 22 секунды

Также, есть противоположность для слоумоушна — timelapse. Снимаем видео с меньшей частотой, а проигрываем с большей. Ставим штатив на балкон и делаем одну фотографию в день на протяжении года. Получается, что у нас получилось видео с частотой кадров — 1 кадр в день. За год у нас получилось 365 кадров. Теперь мы включаем скорость 25 FPS. В итоге, получаем 365 / 25 = 14,6 секунд в которые уместился целый год.

Игры

Почему тогда играм недостаточно 25 FPS? А нужно намного больше: 60 или даже 100 FPS.

Как написано в абзаце про фильмы с 60 FPS — камера всегда снимает с небольшим размытием в движении. Компьютер же создаёт абсолютно чёткие изображения. Из-за этого мозгу сложнее складывать их в непрерывную картинку. И чем больше движения в игре, тем больше чётких кадров нам нужно для корректного восприятия.

Для сапёра нам хватит и 2 FPS. Два раза в секунду компьютер будет обновлять изображение на мониторе и показывать попали мы в бомбу или нет. А для Counter-Strike не хватит и 30. Просто потому, что движения там слишком динамичные.

Конечно, игры научились включать искуственное размытие, но оно похоже только мешает игровому процессу. По крайней мере, я не знаю ни одного человека, который включает моушн-блюр в играх. Да и система лишний раз нагружается.

На восприятие также влияет то, что фильмы мы смотрим с постоянной кадровой частотой. В играх же, в зависимости от происходящего, FPS меняется. Как только FPS резко падает, мозг сразу же замечает это. То же самое было бы и с фильмами, если бы кадров в секунду было то 25, то 60.

FPS для игр важен не только для комфортного восприятия игры. Частота кадров равна частоте обновления физической модели. Это значит, чем больше FPS, тем чаще компьютер проверяет сделали вы выстрел или нет. Иногда эти доли секунды важны.

Похоже, что всё, что хотел рассказать — рассказал. Вот кратко все тезисы этой заметки.

Итоги

1) Первый фрейм рейт — 16 FPS
2) Звук увеличил кадровую частоту и сделал её постоянной — 24 FPS
3) Частота электросети определила новую кадровую частоту для телевизоров — 25 FPS и 30 FPS
4) Цвет превратил 30 FPS в 29,97 FPS из-за того, что не дружил со звуком
5) Фильмы в 60 FPS плавнее
6) Слоумоушн — снимаем с бóльшим FPS, смотрим с меньшим. В таймлапсе наоборот
7) Игры генерируют абсолютно чёткие кадры, поэтому нужно больше FPS, чтобы создать плавное движение
8) В фильмах кадры в секунду постоянные, в играх зависят от ситуации

Источники

The History of Frame Rate for Film
Why is TV 29.97 frames per second?
Почему нам мало 30 fps?
Why aren’t Slow Mo Guys videos 60fps?

python — fps — как разделить счетчик на функцию времени, чтобы определить fps

спросил 5 лет, 8 месяцев назад

Изменено 4 месяца назад

Просмотрено 35 тысяч раз

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

Я пытался инициализировать время как

 fps_time = time.time
fps_time = число с плавающей запятой (время.время)
fps_time = np.float (время. время)
fps_time = время()
 

Тогда для расчета фпс,

 фпс = (счетчик/время_фпс)
FPS = float (счетчик / fps_time)
FPS = float (счетчик (fps_time))
 

Но я получаю сообщения об ошибках: объект не вызывается или не поддерживается операнд для /: ‘int’ и ‘встроенные функции’

Заранее спасибо за помощь!

• питон
• opencv
• время
• частота кадров
• операций

1

• Вот очень простой способ распечатать частоту кадров вашей программы в каждом кадре (счетчик не требуется):

   время импорта
  пока верно:
      start_time = time. time() # время начала цикла
      ########################
      # здесь ваш причудливый код #
      ########################
      print("FPS: ", 1.0 / (time.time() - start_time)) # FPS = 1 / время обработки цикла
   

• Если вы хотите, чтобы средняя частота кадров для превышала x секунды, вы можете сделать так (требуется счетчик):

   время импорта
  start_time = время.время()
  x = 1 # отображает частоту кадров каждую 1 секунду
  счетчик = 0
  пока верно:
      ########################
      # здесь ваш причудливый код #
      ########################
      счетчик+=1
      если (time.time() - start_time) >
    x :
          print("FPS: ", counter / (time.time() - start_time))
          счетчик = 0
          start_time = время.время()
   

Надеюсь, это поможет!

1

Прекрасно работает

 Время импорта
импорт коллекций
класс фпс:
    def __init__(я,среднее значение=50):
        self. frametimestamps = collections.deque(maxlen=avageof)
    защита __call__(сам):
        self.frametimestamps.append(время.время())
        если (len (self.frametimestamps) > 1):
            вернуть len(self.frametimestamps)/(self.frametimestamps[-1]-self.frametimestamps[0])
        еще:
            вернуть 0,0
кадров в секунду = кадров в секунду ()
для i в диапазоне (100):
    время сна (0,1)
    печать (кадров в секунду ())
 

Убедитесь, что fps вызывается один раз за кадр

1

Возможно, вы захотите сделать что-нибудь в этом вкусе:

 def program():
  start_time = time.time() #запись времени начала программы
  счетчик_кадров = 0
  # случайная логика
  для я в диапазоне (0, 100):
    для j в диапазоне (0, 100):
      # делаем что-то, что рендерит новый кадр
      frame_counter += 1 # количество кадров
  end_time = time.time() #запись времени окончания программы
  fps = счетчик_кадров / число с плавающей запятой (время_конца - время_начала)
 

Конечно, вам не нужно ждать окончания программы, чтобы вычислить end_time и fps , вы можете делать это время от времени, чтобы сообщать о FPS во время работы программы. Повторная инициализация

start_time после сообщения текущей оценки FPS также может помочь в сообщении более точной оценки FPS.

Это пример кода нахождения FPS. Я использовал его для предварительной обработки, логического вывода и постобработки. Надеюсь, это поможет!

 время импорта
...
dt, tt, num_im = [0,0, 0,0, 0,0], 0,0, 0
для изображения в изображениях:
    число_им += 1
    t1 = время.время()
    # задание 1....
    t2 = время.время()
    dt[0] += t2 - t1
    # задача2...
    t3 = время.время()
    dt[1] += t3 - t2
    # задача3...
    dt[2] += время.время() - t3
    тт += время.время() - t1
t = кортеж (x / num_im * 1E3 для x в dt)
print(f'task1 {t[0]:.2f} мс, task2 {t[1]:.2f} мс, task3 {t[2]:.2f} мс, FPS {num_im / tt:.2f}' )
 

 из времени импортировать спящий режим,время
кадр/с = 0
число кадров в секунду = 0
время_начала = время()
пока верно:
   если (время()-время_начала) > 1:
     количество кадров в секунду = количество_кадров в секунду
     количество кадров в секунду = 1
     время_начала = время()
  еще:
     fps_count += 1
  печать("Кадр/с:",кадров/с)
 

FPS = количество циклов в секунду

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя адрес электронной почты и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

mcps — Как рассчитать производительность видеодекодера в кадрах в секунду (fps)?

спросил 13 лет, 5 месяцев назад

Изменено 8 месяцев назад

Просмотрено 5к раз

Как мы можем получить производительность видеодекодера относительно того, сколько кадров он может декодировать в секунду. Я знаю, что для получения fps используются следующие параметры, но не могу связать их в формуле, которая дает точный ответ:

секунды, затраченные на декодирование видеопоследовательности, общее количество кадров в закодированной видеопоследовательности, тактовая частота оборудования/процессора, выполняющего код, миллион циклов в секунду (MCPS) декодера

Как связаны MCPS и кадры в секунду ?

• производительность
• мс

0

Учитывая расчет Байрона. Я думаю, что это должно быть больше строк:

Файл F для кодирования, который состоит из N кадров требуется T секунд для кодирования на процессоре, который может выполнять X MCPS

чем я бы сказал, что кодировщик использует: (T*X)/N MC(миллионов циклов) на кадр

учитывая, что частота кадров равна F (например, 25 кадров в секунду)

чем приведенное выше значение, умноженное на F, дает используется MCPS для кодировщика.

, если это меньше, чем MCPS вашего процессора, вы можете кодировать в реальном времени (или быстрее).

R

Когда кодек указывает номер MCPS, это относится к конкретной аппаратной конфигурации.

Миллион циклов в секунду. Этот параметр описывает производительность любого программного обеспечения на данном процессоре. Например, когда мы говорим, что кодек потребляет 100 MCPS на данном процессоре, это означает, что он потребляет 100 миллионов циклов процессора каждую секунду. Справка

Также некоторые видео лучше кодируются разными кодеками. Различные видеопотоки будут иметь разные характеристики производительности в зависимости от типа закодированного видео. Есть кодеки, которые очень хорошо и быстро кодируют аниме, но ужасно работают с фильмами на DVD. Есть много параметров, которые нужно учитывать.

Лучший способ определить производительность конкретного алгоритма — запустить его на том же оборудовании для типов потоков, которые, по вашему мнению, вы будете кодировать.