>>68395

>Если читать жопой, то безусловно.

Поэтому ты упорно отрицаешь реальность, а также полностью игнорируешь, что разработчик пишет о своих билдах? Напомню, а то может проблемы со зрением:

>from mpv-player/mpv, which offers test builds

Рекомендовать обычным людям (не разрабам) тестовые билды в которых содержится ненужный мусор, а также отсутствуют некоторые либы для более удобного/широкого воспроизведения видео конечному пользователю и которые обновить можно только ручками перекачивая архивы только у тебя ума хватает. Благо хоть разработчики умные и показательно указали, что стоит качать в первую очередь.
>>68418
Разрабы mpv только недавно стали через автосборки гитхаба выпускать версию для винды. При том они указывают, что это тестовые сборки, но никто не мешает их использовать на постоянке. shinchiro собирает mpv для винды где-то с 2017 года, если не раньше. И какое-то время был в принципе единственным вариантом для тех кто не хотел собирать сам себе плеер для винды. Хотел написать, что сборка от shinchiro и самих разработчиков ничем не отличается, кроме того, что в архиве разрабов есть ненужные конечному пользователю файлы, отсутствует возможность апдейта без захода в браузер, не прикладывается мануал с объяснением функций и хоткеев, отсутствует батник с возможностью определить mpv как проигрыватель по умолчанию для кучи форматов видео, нельзя дополнительно сразу скачать новую версию ffmpeg/yt-dlp, но оказывается перечисленного есть и отличия в самой сборке не в пользу разработчиков у которых отсутствуют либы:

>dvdnav egl-angle egl-angle-win32 gl-dxinterop gl-dxinterop-d3d9 iconv libarchive libbluray openal rubberband rubberband-3 sdl2 sdl2-audio sdl2-gamepad sdl2-video uchardet vaapi vaapi-win32 vapoursynth vector zimg zimg-st428

Любители менюшек на блюриках очень расстроятся, кхм.
Также либы у ффмпега используются более старые. Хоть это вряд ли как-то влияет, но в очередной раз "васян" впереди планеты всей:
FFmpeg library versions:
libavcodec 61.27.101
libavdevice 61.4.100
libavfilter 10.6.101
libavformat 61.9.101
libavutil 59.51.100
libswresample 5.4.100
libswscale 8.12.100
У разрабов mpv:
FFmpeg library versions:
libavcodec 61.19.100
libavdevice 61.3.100
libavfilter 10.4.100
libavformat 61.7.100
libavutil 59.39.100
libswresample 5.3.100
libswscale 8.3.100
Так что зашквар это или база решать только тебе. Хочешь всё официальное - скачай билд от разрабов. Хочешь как и большинство людей, которые всё это время сидели на билдах от "mpv-васянов" продолжать на них сидеть - продолжай использовать. Я останусь на сборке от shinchiro пока в официальной версии плеера не появится минимум батник для апдейта.

>>74117
Ничего не понял. Так в исходнике? Или это «восстановленное» движение? Я сейчас не про число кадров в секунду, на него на самом деле плевать, а про характер перемещения объектов.

Если это не изменённые кадры из оригинала, то, кажется, всё понятно.

Для начала почитай про устройство традиционной кинокамеры:
https://ru.wikipedia.org/wiki/Обтюратор_(оптика)

В общем случае кадр киноплёнки засвечивается половину времени съемки кадра (1/48 секунды), ещё половина уходит на протягивание плёнки к следующему. Следовательно, при перемещении объектов съёмки или камеры будет захвачено и проинтегрировано их движение за этот отрезок времени и получена размазанная (если перемещения быстрые) картинка, как на единичном фотокадре с такой же выдержкой. Это нормально, и нормально выглядит при воспроизведении. В зависимости от условий съёмки, светочувствительности плёнки, используемого объектива, скорости кадров и прочего могли подбираться другие параметры обтюратора для сдвига выдержки в более выгодном направлении. В компактных камерах механизм мог упрощаться, отсюда специфический характер движения при съёмках на них.

Теперь посмотрим на кадры из примера. Допустим, между кадром N и кадром N+1 дом сдвинулся влево на определённое расстояние. Можно предположить, что с традиционной выдержкой в половину от 1/24 секунды мы должны увидеть размазанный по половине этого расстояния дом (или другой пропорциональный выдержке смаз). Но на кадрах у нас гораздо более чёткий дом, размазанный на порядок меньше. Почему?

Само собой, потому, что цифровые камеры не привязаны к механике и могут произвольно менять выдержку для каждого кадра, имея огромный запас по чувствительности матрицы. Оператор меняет настройки в зависимости от условий съёмки и нужной картинки, эффекта от видео. Более того, цифровая камера может захватить практически всё движение за время от одного кадра до следующего, за исключением промежутка (постоянно уменьшавшегося с развитием технологий), когда с фотодиодов снимается накопленный заряд, обрабатывается, и в память сохраняются значения, становящиеся потом пикселями картинки.

Тут каждый кадр снят с маленькой выдержкой, и результат скорее можно описать не как панораму, а как поворот камеры на небольшой угол, съёмку с почти статичного положения, поворот для следующего кадра, съёмку и так далее, то есть как серию фотографий, снятых одну за другой. Зачем так делать? Например, потому, что показанного места в реальности не существует, и оно скомпоновано из натурных съёмок и декораций в павильоне. Компоновать и накладывать компьютерную графику проще на мало размазанные объекты, иначе либо придётся вылизывать контуры стыковки, чтобы те не выделялись в движении, либо чёткость объектов из разных источников будет разная, и это будет выглядеть явной вклейкой. Короче говоря, чтобы меньше работы по прихорашиванию делать руками в студии. Или, напротив, имеет место ошибка оператора, проблемы планирования съёмок и прочее.

Таким образом, проблема не в «мазне», как ты считаешь, а в её отсутствии, слишком резких и коротких кадрах. Некоторые уже могли догадаться, что аналогичное происходит в компьютерных играх: ускорители растеризуют объекты каждого кадра в статичном состоянии, рассчитанном для определённого момента времени, не имея представления об их движении до и после. Поэтому для создания иллюзии «нормального» движения требуется генерировать много таких кадров в секунду, чтобы глаз более-менее переставал отличать один от другого, или добавлять более или менее примитивную постобработку (пресловутый «блюрчик для компенсации фиговой частоты кадров»). Серьёзный же рассчёт движения и смазывания при съёмке слишком трудоёмок для обработки реального времени.

Я сделаю вид, что в твоём посте ничего не было про интерполяцию и прочую муру. Великовозрастным дебилам накидали инструментов, с которыми они не умеют работать, и они радостно генерируют мусор, даже не понимая принципов. Вот какого чёрта ты решил, что какой-то волшебный плагин сделает тебе «красиво» в этом случае? В интернете дебилов начитался? Ну так читай дальше, что ты жалуешься на говно на экране? Пихай в рот и жуй как все.