Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 33
Приветствую! Хорошая техническая статья. А можно для неспециалиста пояснить: мы жмём исходный поток во сколько раз? Если судить о 1.4гб/200Мб, то это x7 ?
Какие сферы применения вы предполагаете? Облачный гейминг? (Большеват все таки бюджет по полосе).
И интересно, что "классическое видео" ParkJoy вообще нигде не выложено в открытый доступ. В отличие от Лены jpg. Где его можно глянуть?
Тут, но где его брал автор - я не знаю. По кадру из статьи вроде это оно
Почему оно "печально известное"? Какие-то проблемы с авторскими правами?
О, прямо въетнамские флешбэки пошли как кадр из parkjoy увидел. Насмотрелся я на него в своё время при отладке AVC-Intra кодека для ПЛИС...
Само кодирование, кстати, вполне себе реализуемо аппаратно для AVC-Intra или HEVC-Intra с потоком 100-200 мегабит в секунду и с микроскопической задержкой в 16-32 строки пикселей за счёт блочной структуры кодирования. Но вот выбрать правильную стеиень квантования чтобы уложиться в CBR, не зная заранее содержимое всего кадра - это из серии гадания по хрустальному шару. Так то по предыдущему кадру можно статистику набрать, но при резкой смене плана это не помогает. У нас даже шутка была, что каждый сотрудник компании за время работы придумывает как минимум один новый алгоритм контроля битрейта.
Блоки 32х32. Сжимаю jpeg и zlib со средним сжатием. Помечаю, что занимает меньше. Объединяю в макроблоки - прямоугольные области с только jpeg и только zlib кодированием - пережимается макроблок целиком. Работает в реальном времени с приемлемым потоком. Степень сжатия регулируется только для jpeg. Если в полёте больше чем 3 кадра - сжимаем сильнее. Если 3 и меньше на протяжении секунды - немного уменьшаем сжатие до тех пор, пока не превысим 3 кадра в полёте. Это в aeroadmin реализация. Удаленное администрирование требует минимальных задержек.
Все операции многопоточно - минимум задержка
Имеются ли артефакты на границах блоков? Сжимается только покадровое изменение картины? В библиотеках самого jpeg вроде как имеется уже возможность поиграть с размером блоков DCT (lossy), а затем ещё поднастроить результат квантования (lossless).
Сжатие только покадрово. Артефакты блоков не видно. Виден муар от сжатия текста jpeg. Но как-только появляется возможность, то сильно сжатые блоки обновляются с меньшим сжатием и артефакты исчезают.
В jpeg только качество выставляется и цветовое прореживание.
Нет необходимости прям точно в какой-то размер вписываться
Кстати вроде как подобный метод с переменным сжатием используется в DJVU. Там получается так что делаются из изображения слои, каждый слой это свой пространственный фильтр низкой частоты грубо говоря (например, усреднение по соседним точкам). Как только производная от изменения яркости становится большой (или в спектре появляются ВЧ-составляющие) применяется уже более мелкое сжатие локальной области. То есть сжимаются уже не исходная картина, а разбитая на эти слои, потом они снова складываются-восстанавливаются.
В ещё стародавнее время в мультиплее можно было передавать изображение игры практически мгновенно, создавая двоичный поток об этой сцене по коаксиалу 10 мбит, в качестве проигрывателя - движок самой игры, там уже и текстуры есть и всё что нужно, достаточно представлять координаты и дерево объектов.
Гипотетически, можно байткод, который и формирует это дело между GPU<->CPU перехватывать и уже отправлять непосредственно его, включая физику, а далее его восстанавливать на GPU-приёмнике, наверняка подобного рода технологию рано или поздно завезут, так как GPU в облаке как сервис и виртуальные видеокарты прямо говорят о том что это необходимо сделать, в этом случае можно рендерить хоть 8к, разумеется, для нативных фильмовых сцен это дело не подойдёт а для геймплея вполне.
Примерно так же в Линуксе работал графический сервер иксов по сети, отправлялись команды типа "отрисовать окно", "отрисовать кнопку", "вывести текст". В результате программа работала на одном компьютере, а её интерфейс - на другом. Но сейчас от этого ушли...
Ну почему же, если в качестве байткода вызывать методы того же Qt. Более того в новой почти полнофункциональной операционной системе называемой нынче "браузер" рендерить часть веб-контента AJAX-ом, то фактически эти самые JSON-XML-подобные пакеты и есть некая имитация иксов, концепт которых был ещё в середине 90-х. Можно образно сказать что фронтенд - это имитация рабочего стола и прочих элементов GUI, созданных на бекенде. А там хоть Ncurses или Turbo Vision по сети, но это уже более ранняя история.
А в чем смысл? Для рендеринга потребуется такой же мощный GPU, как и в локальном варианте. Нужны текстуры, значит нужна вся игра локально (за минусом бинарника). Сэкономить CPU?
Ну что вы, это же ворота в дивный новый мир. В котором нет спираченных игр, крякнутых, хакнутых, с читкодами. В котором никто не отреверсинженирит твою игру и не позаимствует решения. В котором пользователи не смогут заплатив за игру однажды играть потом, собаки такие, всю жизнь. И наигравшись перепродать игру не смогут. Пользователь вообще доступа к коду лишен. Он может только платить и получать видеопоток. Идеальный потребитель!
Именно так! Пользователь освобождается от бремени переноса к себе бинарников геймплея и физики, которые лежат на сервере а на его стороне лишь тонкий клиент с GPU для отрисовки. Аналогично все САПР-ы. Мало того, там автоматом виртуальная флешка с ключами привязанные к ГлобалУслугам (эту тему кстати не только у нас курируют, взять те же корневые сертификаты) с биометрическим ID. Ну и соответственно трафик может быть для векторной графики из разряда US Robotics 56k
И какие от этого плюсы для пользователя? Текстуры, звуки, катсцены, модели, тексты и прочее это и есть 99% объёма игры. Сэкономить на паре десятков мегабайт бинарей в игре на 100 гигабайт?
Для антарктической экспедиции, когда охота поиграть с друзьями на другом континенте а видос через исчезающий Старлинк или другой спутник на высоких широтах уже не прогнать через 
.
И поэтому вместо таскания по сети только пакетов, нужных для мультиплеера, мы будем таскать те же пакеты для мультиплеера и к ним ещё пакеты, описывающие кадры? Звучит заманчиво (нет).
Нет, маленько не так, мультиплеер может содержать элементы, который производитель игры хочет скрыть, ну вроде как все хотят чтобы ЗП капала за ПО, принимаем как должное. Поэтому невозможно будет описать сцену без скрытой физики, например, в мультиплее помимо людей ещё что-то делает ИИ а также меняется сцена по какому-то алгоритму или сюжет, которого нет в синглплее. В этом случае конечно же будут пакеты которые помогают эти изменения прорисовать. На клиентской стороне только текстуры, полигоны, звук/миди, базовая физика которая в общедоступном движке ну и по мелочам сетевые протоколы и локальное хранилище. Всё остальное уже в облаке. Мало того, если канал совсем небольшой то передаваться может "усечённая сцена" или отсутствовать мелкая моторика у персонажей.
Такое давно решается серверной логикой для ключевых механик. F2P часто такие, в том числе и синглплеерные.
Всё верно, речь идёт не о сервер-рендеринге а именно об этом действии на машине пользователя, которая выступает в качестве визуализатора, содержит терабайты текстур, демок, интро итд а по факту принимает поток графа сцены, который уже можно протолкнуть через узкополосные или падающие каналы. При этом, действительно, механика и прочее поведенческое "ноу-хау" (чтобы скрыть от читер-крякеров) из разряда ИИ, отрабатывается на игровом сервере. Вообщем это что то среднее между тонким клиентом и сервером.
А если геймплей охота глянуть через спутник, ASDL, диалап, пусть даже и спустя сотню миллисекунд, может там MMORPG 8k, такая где нужно увидеть на экране пиксель чтобы разгадать где спрятался юнит, сжатие без потерь не пойдёт, канал не позволит, с потерями - будет один большой блюр на весь экран с косинусными артефактами. То есть это потенциально индустриальная задача, когда разработчики игры, CAE/CAD/CAM могут движением мыши сгенерировать легковесный вьюер без игрового движка (99.9 это текстуры и полигоны), чтобы можно было смотреть на удалёнке что происходит, делать туторы и классрумы под сотню человек не напрягая связь. Причём это может быть универсальное решение в виде некой стандартной либы под CPU-GPU, что-то как раз из разряда x11-ов и Wayland-а, только более адаптировано под эту задачу, включающую обработку таймаутов, лагов и непрорисовок (пока что эти интерфейсы подразумевают идеальную связь)
Автор для кодирования использует топовую видеокарту, в которой уже и так есть готовый энкодер, который может выдавать аналогичное качество кодирования 🤦♂️
Вот если бы это всё чудо работало без GPU - тогда да. А так смысл в нем, если есть NVENC?
Перевод вроде неплохой и содержание интересное. Но к середине статьи начинается использование кучи аббревиатур без каких-либо расшифровок и пояснений, что для неподготовленного человека проблемно.
Немного не по теме: на текущем проекте где я работаю мы используем инфраструктуру (рабочие станции) заказчика через Parsec. В принципе хватает интернет канала в 10-15 мегабайт чтобы получать картинку в 4к и без проблем видеть анимации интерфейса в той же визуал студии. Это в разы лучше чем всякие Remote Desktop / VNC и прочие. Думаю для большинства игр, за исключением киберспорта, этого тоже будет достаточно.
Крутая штука для VR может выйти. Там не проблема локально гонять поток в +400МБит, проблема пожать картинку за приемлемое время. Если транскодирование будет занимать условных 8мс, из которых 7мс сеть, то это будет своего рода микрореволюция! Сейчас самые крутые задержки которые только получается у меня выжать на Pico это 20мс. Из которых сеть 6мс на wifi5
Зачем изобретать "новое", когда есть JpegXS. Тот-же wavelet на весь кадр, упрощенное энтропийное кодирование, возможности предсказания из прошлого фрейма, правда возникают вопросы о стоимости лицензии.
Motion JPEG существует уже очень давно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой удивительно быстрый видеокодек для стриминга