Реальные webp, создаваемые ImageMagick из тех же png, обычно оказываются больше, причём значительно, на треть где-то.
Можете показать примеры изображений? Мне интересны примеры, где webp не работает.
В наших проектах (не связанных с вебом) проводили начальное исследование эффективности сжатия на конкретном (не синтетическом) контенте, и выигрыш по размеру был существенным — в среднем сжатые изображения весили 25% от начального размера PNG
В том то и дело что там нет защиты «только на 2 компьютера» — ipr общий на всех «потребителей». ipr файл — обертка вокруг видеофайла с метаданными, зашитая одним ключем (скорее всего через AES-128). Там есть и плейнтекстовая информация с разметкой внутреннего контента и явный видеобинарник. То есть ключ для раскодировки либо зашит в сам бинарник (меня не удивит если это так), либо каждый раз отправляется с сервера при открытии плеера. При этом видео не разделено на чанки, закодированные разными ключами (как это иногда делают), т.к. после запуска видео можно физически вырубить доступ к сети и раскодировка будет спокойно работать на протяжении всего видео. Вариант с мгновенной раскодировкой во время запуска исключается, поскольку на моем железе нет возможности разжать 3х гиговый бинарник за полсекунды. Плюс плеер постоянно висит достаточно высоко в списке процессов — openssl либа активно работает, нехило загружая процессор.
Основной смысл реверса бинарника в том, что вместе с «сырым» выходным видеофайлом мы получим автоматическую очистку всех ватермарок с ключами активации (видимыми глазом, которые иногда замазывают при публикации видео на торренты, и невидимые, которые команда infoprotector вручную отслеживает по этим раздачам, очевидно налепливая что-то типа полу-рандомного шума на видео, как делают при «атаке» на нейронные сети).
Эти ватермарки-ключи не зашиты в видео, а генерятся плеером на лету и лепятся поверх видеопотока для каждого пользователя в отдельности. И эти ключи являются единственной возможностью отследить человека, сделавшего «рип» видео.
Я уже пробовал тыкать в инфопротектор дебаггером — но он обфусцирован и защищен чем-то типа VMProtect. Пока более глубоко копать времени не было.
Инфопротектор еще очень нестабильно работает на MacOS — билд постоянно вылетает из-за ошибок доступа к памяти.
Не пробовали реверсить бинарник .ipr? Судя по тому, что интернет требуется только для активации, а во время просмотра можно спокойно выключить доступ к сети — ключ для декодирования бинарника либо зашит в сам бинарник, либо получается единовременно при запуске видео.
В итоге остались на OpenGL? У вас есть какая-то статистика платформ и железа, на которых работает КОМПАС? Есть ли там поддержка какого-нибудь DX12 или Vulkan?
Рассматривали ли вы варианты реализации рендеринга через другие графические API?
Специфичный кейс:
Есть ли возможность встраивать кадры сырого рендера на OpenGL / Vulkan / DX / Metal внутрь окон с контролами? (с пересечением / перекрытием кадра контролами или без)
Обратите внимание на сигнатуры в вашем коде — wstring против wchar_t из статьи. wstring поддерживает структурное равенство через ==, массив wchar_t — нет.
Именно такие малозаметные изменения и опечатки говорят в пользу статического анализа кода.
Тогда ещё вопрос — основной платформой и для текущего кроспилятора и для «к примеру, скриптования» является Android? Почему именно Java (как платформа в первую очередь, JVM)? Понятно, что кроспилированные шейдеры можно использовать в сыром виде, но что со скриптованием? Рассматривали ли вы какие-то альтернативные варианты типа скриптового рантайма на С например?
А по какой причине шейдеры в GLSL кроспилируются каждый раз в рантайме заново, а не заранее на этапе сборки и не бандлятся в игру/приложение собственно в виде GLSL?
В Amazon Kindle есть такая фича — поиск выделенного слова в оксфордском толковом словаре. Однако в большом количестве случаев непонятное слово объясняется через другое, ещё более непонятное слово, либо через тавтологию (например слово Хs-множественное число слова X). При этом нельзя рекурсивно искать слово через сноску. Ещё один минус такого подхода — перестаёшь ассоциировать слова на английском со словами на русском. То есть понятны смысл и контекст применения слова, но не можешь найти аналогичное слово на русском, хотя чаще всего есть простой и однозначный перевод. Очень неудобно в случаях, когда надо перевести какое-то предложение незнающему человеку — начинаются долгие раздумывания про «как это по-русски», хотя весь смысл предложения понятен.
В идеале надо и переводить, и смотреть толкование в словаре eng-eng.
Это, насколько я знаю, двухмерный режим OpenGL, трёхмерный чуть иначе работает: там посылаем кучу всякой фигни, отсекаем невидимые камерой грани, строим z-буфер, по нему рисуем плоскости с натянутой текстурой, хитро обсчитанной
У OpenGL нет «двухмерного режима», есть только API команды, которые описывают текущий вариант использования механизма отсечения невидимых граней (glCullFace), либо использования z-buffer (glDepthFunc). В случае если он не используется — мы просто пишем что не используем его (просто не включаем его в текущий render buffer). Но это не значит что его нельзя включить для 2Д рендеринга.
Опять же — OpenGL не знает что вы через него пытаетесь рисовать, он всё считает трёхмерной геометрией.
2Д обычно рисовать быстрее просто потому, что не нужно считать попиксельное освещение. Но при этом 2Д может быть медленнее в случае если оно рисуется через alpha-blend с огромным количеством накладывающихся слоёв. Хороший пример — закрытие игрового «мира» чёрной подложкой и рисование чего-то другого поверх (например экрана опций). В случае, если появляется такое большое количество «перерисовок» (overdraw) мобилки начинают сильно захлёбываться из-за «физического» ограничения на количество отрисовываемых пикселей за кадр — fillrate. ПК от этого обычно меньше стадают из-за большей общей производительности.
Да, именно об отсутствии понятия 2Д для GPU я написал выше. Все вершины считаются трёхмерными, вся математика с положением — в трёхмерном пространстве.
Пайплайн со скриншота как раз явно содержит передачу массива вершин — input geometry and attributes, которые определяют трёхмерные объекты (даже если они плоские)
Более интересен ваш пример с шейдерами — это и есть обычный режим работы OpenGL. Расчёт экранных координат переданных вершин расчитывается в vertex shader — там где умножается матрица 4х4 на четырёхмерный вектор. Мерность матрицы и положения вершины как бы намекает на трёхмерную природу — вектор вершины хранит её положение в трёхмерном пространстве (в гомогенном виде — четвёртая составляющая), а матрица — обычная матрица трансформации в трёхмерном пространстве (translate — rotate — scale). То есть Love тоже работает как «эмулятор 2Д в 3Д пространстве», и это крайне эффективно.
Отсечение невидимой геометрии за пределами камеры — это пользовательский код, которого нет в графическом драйвере по умолчанию. То есть если вы будете использовать сырой OpenGL для отрисовки 3Д геометрии, там тоже не будет фильтрации геометрии, выходящей за границы камеры (неважно — перспективной или ортографической, либо вообще камеры с кастомной матрицей проекции) пока её не напишешь вручную (frustum culling)
поэтому 2d эмулируется через 3d, у которого камера перемещается по одной плоскости.
Ну, тут просто слегка избыточная трата ресурсов, что может быть критично на телефонах.
Для GPU, кстати, вообще нет понятия «2Д» — она в любом случае рисует трёхмерные примитивы (меши). Именно такой способ «ускоренного» рендеринга (через «эмуляцю» 2Д через 3Д) позволяет существенно увеличить производительность, особенно на телефонах. Именно таким ускорением (переводом рендеринга с CPU на GPU) в своё время занимались Adobe с их Molehill (Stage3D). И скорее всего именно так уже работает Love, если посмотреть на love.graphics API (например вот — явный отсыл к графическому Stencil Buffer love2d.org/wiki/love.graphics.setInvertedStencil) Точнее сказать не могу, т.к. уже написал выше что сам не пробовал Love. Но очень советую поглубже копнуть в эту тему, интересно уточнить как именно работает рендеринг в Love
Просто в тему — есть ещё более быстрый и более cache-friendly вариант блюра — «Dual Filtering Blur». Именно на этот метод ссылается автор интеловской статьи про ресёрч реалтаймового блюра.
Подробнее можно прочитать вот тут community.arm.com/graphics/b/blog/posts/moving-mobile-graphics#siggraph2015
Bandwidth-Efficient Rendering — Marius Bjørge, ARM — Notes (презентация с описанием и примерами кода)
Недавно годный доклад на эту тему опубликовали на youtube. Я сам практикую немного другие вещи (ECS / Entitas), но то что сделали они мне очень понравилось www.youtube.com/watch?v=raQ3iHhE_Kk
Очень советую к просмотру, примеры кода так же можно найти по коментам и в блоге (https://blogs.unity3d.com/2017/11/20/making-cool-stuff-with-scriptableobjects/)
Если что — я не биолог, но суть примерно такая:
«Мы не могли не заметить, что механизм кодирования генов парами, который мы предложили, предполагает возможность использования его (механизма кодирования парами) для копирования генетического материала»
Можете показать примеры изображений? Мне интересны примеры, где webp не работает.
В наших проектах (не связанных с вебом) проводили начальное исследование эффективности сжатия на конкретном (не синтетическом) контенте, и выигрыш по размеру был существенным — в среднем сжатые изображения весили 25% от начального размера PNG
adb shell dumpsys surfaceflinger)Основной смысл реверса бинарника в том, что вместе с «сырым» выходным видеофайлом мы получим автоматическую очистку всех ватермарок с ключами активации (видимыми глазом, которые иногда замазывают при публикации видео на торренты, и невидимые, которые команда infoprotector вручную отслеживает по этим раздачам, очевидно налепливая что-то типа полу-рандомного шума на видео, как делают при «атаке» на нейронные сети).
Эти ватермарки-ключи не зашиты в видео, а генерятся плеером на лету и лепятся поверх видеопотока для каждого пользователя в отдельности. И эти ключи являются единственной возможностью отследить человека, сделавшего «рип» видео.
Я уже пробовал тыкать в инфопротектор дебаггером — но он обфусцирован и защищен чем-то типа VMProtect. Пока более глубоко копать времени не было.
Не пробовали реверсить бинарник .ipr? Судя по тому, что интернет требуется только для активации, а во время просмотра можно спокойно выключить доступ к сети — ключ для декодирования бинарника либо зашит в сам бинарник, либо получается единовременно при запуске видео.
Рассматривали ли вы варианты реализации рендеринга через другие графические API?
Есть ли возможность встраивать кадры сырого рендера на OpenGL / Vulkan / DX / Metal внутрь окон с контролами? (с пересечением / перекрытием кадра контролами или без)
wstringпротивwchar_tиз статьи.wstringподдерживает структурное равенство через==, массивwchar_t— нет.Именно такие малозаметные изменения и опечатки говорят в пользу статического анализа кода.
В идеале надо и переводить, и смотреть толкование в словаре eng-eng.
Очень советую, крайне полезный опыт, большинство вопросов сразу пропадут :)
У OpenGL нет «двухмерного режима», есть только API команды, которые описывают текущий вариант использования механизма отсечения невидимых граней (glCullFace), либо использования z-buffer (glDepthFunc). В случае если он не используется — мы просто пишем что не используем его (просто не включаем его в текущий render buffer). Но это не значит что его нельзя включить для 2Д рендеринга.
Опять же — OpenGL не знает что вы через него пытаетесь рисовать, он всё считает трёхмерной геометрией.
2Д обычно рисовать быстрее просто потому, что не нужно считать попиксельное освещение. Но при этом 2Д может быть медленнее в случае если оно рисуется через alpha-blend с огромным количеством накладывающихся слоёв. Хороший пример — закрытие игрового «мира» чёрной подложкой и рисование чего-то другого поверх (например экрана опций). В случае, если появляется такое большое количество «перерисовок» (overdraw) мобилки начинают сильно захлёбываться из-за «физического» ограничения на количество отрисовываемых пикселей за кадр — fillrate. ПК от этого обычно меньше стадают из-за большей общей производительности.
Да, именно об отсутствии понятия 2Д для GPU я написал выше. Все вершины считаются трёхмерными, вся математика с положением — в трёхмерном пространстве.
Пайплайн со скриншота как раз явно содержит передачу массива вершин — input geometry and attributes, которые определяют трёхмерные объекты (даже если они плоские)
Более интересен ваш пример с шейдерами — это и есть обычный режим работы OpenGL. Расчёт экранных координат переданных вершин расчитывается в vertex shader — там где умножается матрица 4х4 на четырёхмерный вектор. Мерность матрицы и положения вершины как бы намекает на трёхмерную природу — вектор вершины хранит её положение в трёхмерном пространстве (в гомогенном виде — четвёртая составляющая), а матрица — обычная матрица трансформации в трёхмерном пространстве (translate — rotate — scale). То есть Love тоже работает как «эмулятор 2Д в 3Д пространстве», и это крайне эффективно.
Отсечение невидимой геометрии за пределами камеры — это пользовательский код, которого нет в графическом драйвере по умолчанию. То есть если вы будете использовать сырой OpenGL для отрисовки 3Д геометрии, там тоже не будет фильтрации геометрии, выходящей за границы камеры (неважно — перспективной или ортографической, либо вообще камеры с кастомной матрицей проекции) пока её не напишешь вручную (frustum culling)
Для GPU, кстати, вообще нет понятия «2Д» — она в любом случае рисует трёхмерные примитивы (меши). Именно такой способ «ускоренного» рендеринга (через «эмуляцю» 2Д через 3Д) позволяет существенно увеличить производительность, особенно на телефонах. Именно таким ускорением (переводом рендеринга с CPU на GPU) в своё время занимались Adobe с их Molehill (Stage3D). И скорее всего именно так уже работает Love, если посмотреть на love.graphics API (например вот — явный отсыл к графическому Stencil Buffer love2d.org/wiki/love.graphics.setInvertedStencil) Точнее сказать не могу, т.к. уже написал выше что сам не пробовал Love. Но очень советую поглубже копнуть в эту тему, интересно уточнить как именно работает рендеринг в Love
И наверное общий вопрос: чем принципиально отличаются Lua движки типа Defold / Corona / Love? На что в первую очередь обратить внимание при выборе?
Подробнее можно прочитать вот тут community.arm.com/graphics/b/blog/posts/moving-mobile-graphics#siggraph2015
Bandwidth-Efficient Rendering — Marius Bjørge, ARM — Notes (презентация с описанием и примерами кода)
Очень советую к просмотру, примеры кода так же можно найти по коментам и в блоге (https://blogs.unity3d.com/2017/11/20/making-cool-stuff-with-scriptableobjects/)
«Мы не могли не заметить, что механизм кодирования генов парами, который мы предложили, предполагает возможность использования его (механизма кодирования парами) для копирования генетического материала»