DOCtrs

Подумалось мне, что вполне возможно я тоже могу писать годные посты, а после этого мемасика, я подумал а чем я хуже всех остальных авторов?

Это так сказать фабула, и для текущего поста я выбрал тему, которая нас постоянно окружает, и с которой я в последнее время очень много работал. Сегодня давайте поговорим о такой, вроде бы простой штуке, как видео. Да, просто видео.

Для начала, думаю что ни для кого не секрет, что видео это последовательность картинок. Берем флипбук, быстро его пролистаем и получим видео. Если в случае флипбуков все просто - это, можно сказать, видео без оптимизаций, костылей, блэкджека и всего остального. Если бы в реальном видео использовалась точно такая же технология, то не сложно посчитать сколько весил был современный фильм в качестве 1080p

Для примера возьмем что одна картинка в разрешении 1080p весит 200kb. Получается что при 30 кадрах в секунду и полуторачасовом фильме (90 минут) мы получаем следующее

200 (кб) * 30 (fps) * 90 (мин) * 60 (сек) = 32.4 Гигабайта.

А это уже сравнимо с парочкой, а то и тройкой фильмов в 4к.

Можно было бы призвать на помощь архивацию данных, но, к сожалению, изображения и видео сжимаются меньше всего. Кстати, все ведь помнят такую штуку как кодеки? Так вот, кодеки это по сути те же самые архиваторы. Разница между разными кодеками точно такая же как разница между zip и rar. Каждые просто запаковывают по своему, и соревнуются в скорости и итоговом размере архива.

Так как же еще пытаются уменьшить объем видео? В основном это делают, реализуя алгоритмы на основе 2х видов кадров (их, правда, побольше, но сейчас поговорим только об основных)

1. Опорные кадры - I кадры

2. Промежуточные кадры - P кадры

I кадр - это та самая полноценная картинка, которая занимает так много ценных килобайт, а P кадры - это просто небольшие картинки, которые хранят в себе отличие от I кадра.

Ничего не понятно? Покажу на примере гифки, так как с видео мне сейчас лень работать

I кадр  P кадр  P кадр  P кадр  P кадр  P кадр

Ну а на выходе мы получаем следующее

И в данном случае, вместо того, чтобы потратить 10 кб * 6 кадров = 60 кб, мы потратили только 10 (кб 1 кадр) + (1 (кб) * 5 (кадров)) = 15 килобайт.

Согласитесь, выгода ощутимая.

И в итоге чем больше у нас GOP (расстояние между 2мя I кадрами) тем меньше весит видео. Но как и у любой медали здесь тоже есть обратная сторона. Я думаю, что все наблюдали подобную картинку при просмотре чего бы то ни было хотя бы раз в жизни

Ну и происходит это от того, что i кадры слишком редкие, и при декодировании видео, происходят мелкие ошибки, которые и приводят к тому, что P кадры накладываются не на тот I кадр.

И кстати, возможно вы замечали, что подобные артефакты пропадают при полной смене кадра. Например, при начале съемки с другого ракурса, или другой локации. Все потому, что при подобных финтах, P кадр не может наложиться на старый i кадр. Точнее он может, но он уже не будет выглядеть обрезком как на картинке, которую я показал. Он будет уже точно тем, чем являются опорные кадры (i кадры).

Вот, собственно, именно так и работает вся эта херня, которую мы с вами наблюдаем целыми днями.

Дальше попробую развить эту тему, и в следующем посте (если меня ссаными тряпками не погонят) обсудим, нахрен нам нужны 100+ FPS, если из каждого утюга трубят про пресловутые 24 кадра

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

Первым делом запустим файл, который предоставляет сам разработчик - build.sh

Помимо всего прочего вывода, команда выводит список файлов из папки build

Окей, у нас есть куча файлов, но что теперь? Вон есть index.html. Запускаем его и видим в браузере игру. Что же происходит при этом в консоли?

На данном скрине нас интересует только самая правая колонка - это размер подгружаемого элемента. Можно даже не пользоваться калькулятором, ведь и невооруженным взглядом видно, что 9.6 + 4.8 уже больше 13. А там еще и шрифты на целый ценный килобайт. А ведь это еще только размер передаваемый от сервера браузеру, а реальный размер того же индекса - 12 кб

Хотя, строго говоря, подгрузив все вот эти файлы на ~20кб игра полноценно функционирует что на мой взгляд очень неплохо. Но недостаточно хорошо для js13k.

Что, кстати, говорят его правила на этот счет?

All your code and game assets should be smaller than or equal to 13 kilobytes (that's exactly 13,312 bytes, because of 13 x 1024) when zipped. Your .zip package should contain index.html file in the top level folder structure (not a subfolder) and when unzipped should work in the browser

Ваш код и игровые ресурсы должны быть меньше 13 кб в сжатом виде. Ваш zip пакет должен содержать index.html и после распаковки работать в браузере.

Мало того, что мы

1. Прогнали обе карты запаковщиком, написанным на C. (файл l на 1 и 2 скринах)

2. Запаковали все текстуры запаковщиком, написанным на php (файл m на 1 и 2 скринах). Я кстати, так и не понял почему один запаковщик реализован на C, а другой на php. В гитхаб тоже подвезли требование разнообразия?

3. Прогнали весь код компрессором UglifyJS. (73 кб -> 26 кб)

4. После этого весь код прогнали специальной тулзой, которая специально была разработана для js13k - https://lifthrasiir.github.io/roadroller/ (26 кб -> 12 кб)

Так еще и запаковали зипом.

И на выходе получаем следующее (см 1 скрин)

Как видно, размер получившегося архива - 13296 байт. А 13кб это 13312 байт а не 13000. Об этом кстати в правилах написано :)

Вот так вот у нас и получаются те самые 13 кб.

По сути в данном соревновании разработчики меряются своими инструментами архивации. Но это не умаляет того, что https://github.com/phoboslab/ написал относительно неплохую игруху, которая без сжатия весит тоже не слишком много.

Да, раньше писали игры на ассемблере. Да, раньше играм для запуска не нужны были тонны оперативки. Да, раньше сахар был слаще, а вода мокрее. Но теперь у нас есть простые маленькие игрушки, в которые можно скачать и запустить за пару кликов без до оборудования.

На краю стола, как предположили в коментах, работать не получится. На зарядке она просто не работает.

ПС Мышь не моя - сфоткал у коллеги