Спасибо) Когда вы перемешаетесь по анимации в адресной строке меняется URL страницы. Так что достаточно просто переместится так, чтобы по центру экрана был интересующий вас элемент/комната и скопировать URL из адресной строки
@Flest@KrivisKrivaitis Готово, сохраняю в jpeg 100% качества. Опция доступна в разделе "Что это?". Можно скачать любой кадр. После каждого обновления крупного буду запускать регенерацию изображений.
У меня, например, Redmi Note 9 Pro, у него написано, что экран 2400×1080. Это количество точек на экране. Но количество точек не равно количеству пикселей. У этого телефона DPR 2.57, т.е. столько точек в одном пикселе. Берем 1080 делим на 2.57 и получаем 393. Именно такое число пикселей будет ширина любого сайта на этом телефоне в вертикальном положении. Это легко увидеть, достаточно распечатать window.innerWidth или screen.availWidth в js на любом сайте, где включена адаптация под мобильники.
Поэтому когда DPR выше 1, то нужно ширину устройства делить на DPR, чтобы узнать реальное количество пикселей )
Короче, это мой последний ответ вам, так как ваши вопросы просто отвлекают, особо ничем не помогают...
Webp легче запрограммировать на rust, чтобы потом перекинуть на wasm, который будет загружаться в браузере. Но я не проверял как на rust распаковывать mp4 или другие форматы, поэтому не обладаю полной информацией. Может окажется, что webp сложнее остальных распаковывать. Не знаю, поэтому эту идею не хочу обсуждать пока не попробую ей на деле и не изучу все
там качество сильно плавает в зависимости как сжимать. По сути те же результаты, что и при webm (vp9). Однако идея webp в другом - распаковывать секции на wasm и рендерить каждый кадр каждой секции отдельно. Тем самым можно как минимум убрать синхронизацию видео потоков. Но это по сути разрабатывать многопоточный wasm, а на выходе профит будет не сильно большой по сжатию и опять же теряется пиксельная четкость (которую вы не видите, к сожалению :D ).
Т.е. идея webp в том, что с ним легче работать на ЯП, проще распаковывать.
В этом посте много было хороших советов, некоторые я применил. А в диалогах один пользователь предложил вариант с webp и показал какие результаты он получил с ним.
Я создал велосипед. Я знаю, что есть варианты получше, которые будут круче результат давать, но явно не тот путь, что предлагаете вы. Мой велосипед дал результаты на тех вводных, что у меня, значительно лучше, чем существующие готовые решения. Это причина, почему я написал статью. Критиковать можно сколько угодно что это велосипед, но это не отменяет того, что он отлично подошел проекту как замена предыдущего способа рендера.
В любом случае спасибо за ваше мнение и потраченное время)
то, что вы показали на скриншоте имеет плохое размыленное качество. Сравните с моим скриншот, он не из оригинала, а уже из видео формата моего, скриншот во время рендера.
Вы просите оценить ваш результат. Я не могу его оценить, так как результата нет. Вы просто увеличили crf, убрали частоту ключевого кадра. Я с этим баловался ещё пару лет назад, тоже получал размер в 1.2МБ на 1 секцию. Вы думаете вы что-то новое предложили применив такие параметры?)) Качество плохое, а без частых ключевых кадров непонятно как рендерить постоянно растущую анимацию (вы ловко перекинули это на "тема отдельного разговора" :D)
Простите, а что за mkv, я же для браузера делаю. И нет указания каждый 10 кадр ключевой. Да и в целом повторюсь, у видео форматов нет сохранения пиксельной четкости, вы никак ими не добьетесь этого. То, что вы на скриншоте показываете - это условно 100%, покажите как на 200%, будет ли также все четко, как вот на этой картинке:
В js, как и в других языках высокого уровня, с побитовыми операция проблем особых нет. Везде есть побитовые операторы и можно как угодно изворачиваться над битами.
Я пробовал похожий вариант с упаковкой каждого пикселя и его изменения. Т.е. грубо говоря у нас есть пиксель первого кадра, мы смотрим все изменения этого пикселя в других кадрах, упаковываем это. И полученный "код" заносим в словарь, чтобы реиспользовать. Все это реализовал, но по итогу получился очень большой файл, в несколько раз превышающий mp4. В итоге как я не пробовал этот способ оптимизировать всегда выходило так, что таком способом упаковка анимации дает плохой результат как минимум в моей анимации)
Я уже переключил все на Brotli. В итоге вместо 82МБ стало весить 57 :) Правда пришлось расчехлять wasm, так как декодировать Brotli не просто так) На транспортировку HTTP я не могу Brotli подключить, так как у CDN это платная функция, да и я сжимаю максимальным уровнем 11, подозреваю CDN не предлагает такое сжатие (хотя нужно проверять).
Статистика ведь будет сильно разной в зависимости от сайта, аудитория везде разная ведь. Я статистику собираю, в моем случае 59,5% пользователи моб устройств. В среднем ширина экрана где-то 400px у этих пользователей. И 36% пользователей ПК, у них преобладает ширина 1920.
Но согласен, часы из назад в будущее выглядят очень похоже. Ещё пока что до назад в будущее не добрался, пока только мини отсылка - одна из машин летающих из назад в будущее
Спасибо) Это не совсем связано со стыками анимации. Это больше связано с самим способом подсветки. Для подсветки используется 4 элемента <div> полупрозрачных, их я выстраиваю так, чтобы они закрывалю всю сцену, кроме нужного фрагмента. И вот иногда они стыкуются плохо. Я попробую найти замену такой подсветке. Если полностью перейду на рендер через канвас, то подсветку переделаю на него и тогда все будет четко ;)
Думаю он бы подошел здесь) Интересную мысль подкинули, спасибо! В следующей попытке ещё сильнее улучшить сжатие обязательно попробую ваш способ. Пока что остановлюсь на том что есть.
В нем массив объектов матрицы сцен. В каждом объекте есть поле preview. В нем адрес до jpg файла превью сцены. Удаляем из адреса имя файла и получаем что-то типа такого:
scene/t0l2/b1l3/fin/
В этом каталоге лежат 60 png файлов этой секции. Формат имени файла - frame_%02d.png . Например
В итоге если вы пройдете по всем объектам матрицы и скачаете все png файлы, должно быть 2.2 ГБ. Ну а дальше нужно сделать что-то, что будет лучше моего формата работать в баузерах. Буду признателен, если сможете что-то лучше предложить, чем мой велосипед ) Однако очень сомневаюсь, так как текущий формат весит 57МБ и позволяет зумить насколько угодно сохраняя пиксельную четкость.
Он и так известен вернее 3 - H265
На всякий случай проверяйте вот такой сайт перед выбором формата, так как не все поддерживается https://caniuse.com/?search=H265
П.с. Перечитал вдоль и поперек …. Не нашел почему так важны размеры секций для лучшего сжатия … :-)
Если размер секции будет большой, для ссылки внутри файла нужно будет применять uint32, это 4 байта на адрес. Например, если секция 1000*1000, то максимальный размер файла (если брать 2 байта на пиксель после квантования):
1000 * 1000 * 2 * 60 кадров = 120 000 000
Для того, чтобы ссылаться на любой байт этого файла нужно адрес uint32.
Для хранения адреса в 3 байтах вместо 4 нужен размер файла меньше 2^24 = 16777216.
Если взять мой размер секции, то это
508 * 406 * 2 * 60 = 24749760
Видно, что мой размер секции больше, чем uint24, но не на много. Я взял по максимум, в реальности после RLE упаковки такой размер уже не будет и адреса все будут укладываться в uint24. Тем самым сотни тысяч повторений внутри файла будут ссылаться используя адреса из 3 байт, вместо адресов из 4. Надеюсь доступно рассказал)
Вы дадите исходную анимацию ?;-)
Без проблем. Одна доступна и по сети. Вы займетесь поиском формата, который лучше моего сожмет? Если да, то я расскажу как формировать URL для скачивания 2.2 ГБ png файлов.
Спасибо) Когда вы перемешаетесь по анимации в адресной строке меняется URL страницы. Так что достаточно просто переместится так, чтобы по центру экрана был интересующий вас элемент/комната и скопировать URL из адресной строки
Вот ссылка на ждуна, он сидит за кассой: https://floor796.com/#t0l2,495,857
Здравствуйте) Извините, не увидел сообщение ранее. Я, конечно, не против)
@Flest@KrivisKrivaitis Готово, сохраняю в jpeg 100% качества. Опция доступна в разделе "Что это?". Можно скачать любой кадр. После каждого обновления крупного буду запускать регенерацию изображений.
Хорошая идея, я позже запилю такой функционал. Пока что простого быстрого способа так сделать нет под рукой
Возможно вы не те цифры смотрите)
У меня, например, Redmi Note 9 Pro, у него написано, что экран 2400×1080. Это количество точек на экране. Но количество точек не равно количеству пикселей. У этого телефона DPR 2.57, т.е. столько точек в одном пикселе. Берем 1080 делим на 2.57 и получаем 393. Именно такое число пикселей будет ширина любого сайта на этом телефоне в вертикальном положении. Это легко увидеть, достаточно распечатать window.innerWidth или screen.availWidth в js на любом сайте, где включена адаптация под мобильники.
Поэтому когда DPR выше 1, то нужно ширину устройства делить на DPR, чтобы узнать реальное количество пикселей )
Короче, это мой последний ответ вам, так как ваши вопросы просто отвлекают, особо ничем не помогают...
Webp легче запрограммировать на rust, чтобы потом перекинуть на wasm, который будет загружаться в браузере. Но я не проверял как на rust распаковывать mp4 или другие форматы, поэтому не обладаю полной информацией. Может окажется, что webp сложнее остальных распаковывать. Не знаю, поэтому эту идею не хочу обсуждать пока не попробую ей на деле и не изучу все
ЯП - язык программирования.
там качество сильно плавает в зависимости как сжимать. По сути те же результаты, что и при webm (vp9). Однако идея webp в другом - распаковывать секции на wasm и рендерить каждый кадр каждой секции отдельно. Тем самым можно как минимум убрать синхронизацию видео потоков. Но это по сути разрабатывать многопоточный wasm, а на выходе профит будет не сильно большой по сжатию и опять же теряется пиксельная четкость (которую вы не видите, к сожалению :D ).
Т.е. идея webp в том, что с ним легче работать на ЯП, проще распаковывать.
В этом посте много было хороших советов, некоторые я применил. А в диалогах один пользователь предложил вариант с webp и показал какие результаты он получил с ним.
Я создал велосипед. Я знаю, что есть варианты получше, которые будут круче результат давать, но явно не тот путь, что предлагаете вы. Мой велосипед дал результаты на тех вводных, что у меня, значительно лучше, чем существующие готовые решения. Это причина, почему я написал статью. Критиковать можно сколько угодно что это велосипед, но это не отменяет того, что он отлично подошел проекту как замена предыдущего способа рендера.
В любом случае спасибо за ваше мнение и потраченное время)
то, что вы показали на скриншоте имеет плохое размыленное качество. Сравните с моим скриншот, он не из оригинала, а уже из видео формата моего, скриншот во время рендера.
Вы просите оценить ваш результат. Я не могу его оценить, так как результата нет. Вы просто увеличили crf, убрали частоту ключевого кадра. Я с этим баловался ещё пару лет назад, тоже получал размер в 1.2МБ на 1 секцию. Вы думаете вы что-то новое предложили применив такие параметры?)) Качество плохое, а без частых ключевых кадров непонятно как рендерить постоянно растущую анимацию (вы ловко перекинули это на "тема отдельного разговора" :D)
Простите, а что за mkv, я же для браузера делаю. И нет указания каждый 10 кадр ключевой. Да и в целом повторюсь, у видео форматов нет сохранения пиксельной четкости, вы никак ими не добьетесь этого. То, что вы на скриншоте показываете - это условно 100%, покажите как на 200%, будет ли также все четко, как вот на этой картинке:
В js, как и в других языках высокого уровня, с побитовыми операция проблем особых нет. Везде есть побитовые операторы и можно как угодно изворачиваться над битами.
Я пробовал похожий вариант с упаковкой каждого пикселя и его изменения. Т.е. грубо говоря у нас есть пиксель первого кадра, мы смотрим все изменения этого пикселя в других кадрах, упаковываем это. И полученный "код" заносим в словарь, чтобы реиспользовать. Все это реализовал, но по итогу получился очень большой файл, в несколько раз превышающий mp4. В итоге как я не пробовал этот способ оптимизировать всегда выходило так, что таком способом упаковка анимации дает плохой результат как минимум в моей анимации)
Я уже переключил все на Brotli. В итоге вместо 82МБ стало весить 57 :) Правда пришлось расчехлять wasm, так как декодировать Brotli не просто так) На транспортировку HTTP я не могу Brotli подключить, так как у CDN это платная функция, да и я сжимаю максимальным уровнем 11, подозреваю CDN не предлагает такое сжатие (хотя нужно проверять).
Статистика ведь будет сильно разной в зависимости от сайта, аудитория везде разная ведь. Я статистику собираю, в моем случае 59,5% пользователи моб устройств. В среднем ширина экрана где-то 400px у этих пользователей. И 36% пользователей ПК, у них преобладает ширина 1920.
Да, это Pink Floyd) Часы тоже оттуда, они были в клипе, вот тут можно их увидеть https://youtu.be/YR5ApYxkU-U?t=177 .
Но согласен, часы из назад в будущее выглядят очень похоже. Ещё пока что до назад в будущее не добрался, пока только мини отсылка - одна из машин летающих из назад в будущее
Спасибо) Это не совсем связано со стыками анимации. Это больше связано с самим способом подсветки. Для подсветки используется 4 элемента <div> полупрозрачных, их я выстраиваю так, чтобы они закрывалю всю сцену, кроме нужного фрагмента. И вот иногда они стыкуются плохо. Я попробую найти замену такой подсветке. Если полностью перейду на рендер через канвас, то подсветку переделаю на него и тогда все будет четко ;)
не совсем понял откуда вообще звук появился)) Я делаю немой проект, там нет звука. Там нужна синхронизация видео потоков.
В любом случае спасибо за высказанное мнение
Думаю он бы подошел здесь) Интересную мысль подкинули, спасибо! В следующей попытке ещё сильнее улучшить сжатие обязательно попробую ваш способ. Пока что остановлюсь на том что есть.
Ну так ведь повторяющиеся фрагменты (в который раз уточняю, вы читали статью?). Мы ищем по всем предыдущим кадрам есть ли где-то повторение фрагмента.
Загружаем файл https://floor796.com/data/matrix.json
В нем массив объектов матрицы сцен. В каждом объекте есть поле preview. В нем адрес до jpg файла превью сцены. Удаляем из адреса имя файла и получаем что-то типа такого:
В этом каталоге лежат 60 png файлов этой секции. Формат имени файла - frame_%02d.png . Например
https://floor796.com/data/scene/t0r0/t4r0/fin/frame_06.png
В итоге если вы пройдете по всем объектам матрицы и скачаете все png файлы, должно быть 2.2 ГБ. Ну а дальше нужно сделать что-то, что будет лучше моего формата работать в баузерах. Буду признателен, если сможете что-то лучше предложить, чем мой велосипед ) Однако очень сомневаюсь, так как текущий формат весит 57МБ и позволяет зумить насколько угодно сохраняя пиксельную четкость.
На всякий случай проверяйте вот такой сайт перед выбором формата, так как не все поддерживается https://caniuse.com/?search=H265
Если размер секции будет большой, для ссылки внутри файла нужно будет применять uint32, это 4 байта на адрес. Например, если секция 1000*1000, то максимальный размер файла (если брать 2 байта на пиксель после квантования):
1000 * 1000 * 2 * 60 кадров = 120 000 000
Для того, чтобы ссылаться на любой байт этого файла нужно адрес uint32.
Для хранения адреса в 3 байтах вместо 4 нужен размер файла меньше 2^24 = 16777216.
Если взять мой размер секции, то это
508 * 406 * 2 * 60 = 24749760
Видно, что мой размер секции больше, чем uint24, но не на много. Я взял по максимум, в реальности после RLE упаковки такой размер уже не будет и адреса все будут укладываться в uint24. Тем самым сотни тысяч повторений внутри файла будут ссылаться используя адреса из 3 байт, вместо адресов из 4. Надеюсь доступно рассказал)
Без проблем. Одна доступна и по сети. Вы займетесь поиском формата, который лучше моего сожмет? Если да, то я расскажу как формировать URL для скачивания 2.2 ГБ png файлов.