Разная трактовка цифр, это вне области моего понимания.

Iurii
Разницу в 1фпс вы не заметите, к тому же, как вы знаете, рефреш экрана это отдельная песня. Я кстати афр пока так и не юзал. Афр это фича по переключению монитора в режим демонстрации источника. Это как знаете как, аналоговый ТВ синхронизировался по сигналу, потом оцифровали сигнал и ввели независимую частоту экрана, 100гц, а теперь с этим же борются, ибо самое правильное показывать так, как заложено в источнике. Хотя сильной разницы я не вижу, это для гурманов...

Шутите? На динамичной сцене будет дёргаться.У меня такого нет в мониторах. Но телевизор умеет переключаться на fps источника, если источник в USB гнедо всунуть. Я это проверял 50/60fps. Поэтому там не видно строба как на Youtube, когда ролик на 50fps туда зальёшь.
Но это всё фигня, если исходник хороший. Всегда можно перекодировать в целевую fps.

Iurii
Не шучу, а так считаю, плюс минус 1 ФПС это в пределах дребезга кадров...

Если вы не слышали ничего об автофрейм рейт, о чем тогда спорите. Монитором управляет источник, афр это способность источника менять частоту хдми под контент, который источник воспроизводит, это своими словами, а так посмотрите инет

Я ещё раз говорю, у меня нет такого монитора. Телевизоры умеет переключать частоту кадров. но подстраиваться под плавающую FPS могут только плееры или телевизоры с так называемой уплавнялкой. Если частота кадров источника не совпадает ни с одной из частот монитора или ТВ, то для преобразования потока на ходу требуются дополнительные ресурсы. Телевизоры с такой технологией стоят дороже. На них не видно строба даже когда показывают кино, скажем, с 23fps или любой другой fps. Такого телевизора у меня тоже нет.

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

Iurii
По моему вы вообще ничего не смыслите в цифровом видео. А как же фреймбуфер, оверлей. Вы хоть представляете процесс вывода на экран? В винде проще, там разрешение синхронизировано с хдми, а вот линукс, он же андроид, может иметь разные разрешение хдми и десктопа. Я попробую на пальцах объяснить как я понимаю, за точность не ручаюсь. Вот ваше видео декодируется, и уже чистые кадры помещаются в буфер. Оттуда независимый проц берет изображение для отправки на хдми, а вот Моник подстраивается под то, что диктует хдми, но хдми работает только в стандартных режимах, например 60фпс, и это как правило выше, чем необходимо.

На счёт квадрата, он дёргается визуально, когда частоты не хватает, а квадрат перемещен дальше, чем человеческая психика это воспринимает, как плавное движение. Аналогично психика ниже 15 ФПС считает за слайдшоу, а выше уже гладко. И не сам квадрат дёргается, а лишь граница контрастных объектов.

Если не согласны, то мы по разному понимаем процесс восприятия видео, и нам не о чем спорить. Оставайтесь при своем...

Есть два пути демонстрации отдельных кадров при стабильной частоте монитора. Первый, это показ того, что отснято, а второй - прорисовка новых кадров, исходя из имеющегося и требуемых меток времени, для получения плавного движения в динамических сценах. Последний вариант требует больших вычислительных затрат, а первый можно выполнить даже аппаратным декодером. Поэтому в большинстве бюджетных девайсов последний, затратный вариант и не используют. Но перерисовку отдельных кадров и их добавление при (повышении fps, например, в два раза), можно успешно сделать в редакторе. Первый инструмент для этих целей, который появился много лет назад, назывался Twixtor и поставлялся отдельно в виде плагина. Сейчас подобные инструменты есть в профессиональных редакторах. Хотя работают они похуже, но зато потребляют меньше ресурсов, что немаловажно при высоком разрешении видео.

Iurii
Вы это знаете, или представляете умозрительно? Я знаю что можно все дорисовать, но к процессу вывода на экран это отношения не имеет. Если вы не понимаете всю цепочку показа, какой смысл с нами обсуждать, что вы там сможете дорисовать... По факту, Моник покажет то, что вы ему посетите в буфер. Не успеете обновить буфер с нужную мс, это ваши проблемы. И ещё раз, то что вы показали плюс минус 1 ФПС, это больше похоже на среднее отклонение, технический параметр, нежели на переменную ФПС. Если хотите разбираться, давай те тогда спеки, как метки времени передаются, и как на них реагирует аппаратура, а то ваши рассуждения похожи на типичные умозаключения лоха. Я то вам пишу просто из своего представления, как устроено любое цифровое устройство видеовывода, а вы какую то ересь несёте, основанную на премьере. Вот что для вас значит ФПС в игре?

Я про игры ничего не знаю, так как в них не играю. Слышал только краем уха, что там fps игры меняется, исходя из возможностей ПК. А на быстрых ПК и мониторах используется 144fps.

Что касается видео, то то что я говорю, можно проиллюстрировать графически. Вы сами можете нарисовать кадры камеры и монитора на временной шкале. Да и в роликах это прекрасно видно в виде неравномерного движения подвижных объектов.

Да даже на словах можно это объяснить, если упростить картину.
Представим для наглядности, что камера снимает 1.5 fps, то есть три кадра за две секунды, а монитор показывает 3fps. Если мы даже просто будем демонстрировать этот поток, то он синхронизируется через кадр и мы получим вполне плавное движение. А если ещё и дорисуем каждый второй кадр на основе каждого первого, то ещё улучшим результат. Подробнее. Первый кадр монитора и камеры будут началом синхронизации. Тогда второй кадр для монитора мы синтезируем из первого кадра камеры, а второй кадр камеры совпадёт с третьим монитора и т.д.

А теперь предположим, что у нас монитор работает с частотой 3fps, а наша камера снимает с частотой 2fps. Если мы продублируем третий кадр камеры, то получим неравномерное движение. Ведь между вторым и третьем исходным кадром прошло определённое время. Если мы дорисуем один кадр, то куда бы мы его не поместили, он попадёт невпопад со шкалой времени монитора. Идеального места не существует. Поэтому нам придётся действовать иначе. На основе первого исходного кадра мы синтезируем второй кадр для монитора, а на основе второго исходного - третий кадр для монитора. То есть потребуется сразу вдове больше вычислительной мощности. Только так можно получить плавное движение. Иначе оно будет дёрганое.

Эта проблема не была такой актуальной до появления больших экранов, где разрешение человеческого зрения не позволяло заметить все эти неравномерности. На больших экранах, расположенных в малых помещениях, всё это стало очевидным. Именно поэтому 30fps для 4K оказались недостаточны, а 8К уже снимают при 120fps. Всё это приходится учитывать при конвертировании видео из одной fps в другую, если требуется обеспечить плавность движения на мониторах с постоянной fps.

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

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

Игры вы не понимаете, ок, а тогда в чем разница вывести подготовленную 3д картинку с текстурами, или раскодированный кадр видео. Может теперь задумайтесь?