Если вам, как мне, напряжно вчитываться и компилировать много буковок в суть, то вот калькулятор https://unity.com/ru/runtime-fee-estimator
И в двух словах:
1) Если вы заработали меньше 200к баксов в год, то платить ничего не надо.
2) Если больше 200к, то надо купить Unity pro (и больше ничего)
3) И только если вы заработали больше миллиона за год, вы использовали версию Юнити выпущенную после конца 2023 года и в вашу игру поиграло более миллиона человек(ваще пох как оно считается, потому что) вы должны будете Юнити не более 2,5% от вашего дохода.
Если я всё правильно понял «миллиарды записей» взялись из-за того, что для картинки используется не один хэш, а несколько(по хэшу на каждый фрагмент?). И это нужно для поиска обрезанных картинок. Так?
Если всё так то, моё никому не нужное мнение: и не надо искать «по отдельным фрагментам изображения». Тем более если это создаёт такие проблемы. Для большинства случаев достаточно одного хэша целой картинки для одного изображения. По крайней мере когда я пользовался существующим баянометром, он всё равно не находил ни обрезанный, ни отзеркаленный контент.
Там про перцептивный хэш 1 робкий коммент. Мне, честно говоря, сложновато понять из этого поста как работает его баянометр. Я вижу там какая-то проблема с поиском в большом количестве данных, но сложно понять как и что ищется. 7 миллионов картинок, но данные ищутся среди 3-4лярдов записей… непонятно.
Ну окей. В моём случае нужно из бд вытянуть по значению поля(хэшу) одну запись. Вы хотите сказать что это проблема из-за того что их 7 лямов? Тем более что это происходит редко - только при создании новых постов. Как-то это не серьёзно.

На самом деле я собирался "Сделать" и отписаться о работоспособности в отдельном посте. Но раз уж вы заговорили об этом, то ...ну хз, у меня могут руки не дойти, а вы, может, об этом не знали - поэтому решил поделиться.

К тому же этот хэш в идеале у вас в бд рядом с записью о картинке/видео/гифке храниться должен. Единственное что я могу - это проверить работоспособность.

Встроенный баянометр на самом деле очень нужен. Он облегчит жизнь существующим постерам и снизит порог вхождения для новых.
Мне не приходилось делать раньше баянометров, но несколько минут гугления (https://habr.com/ru/articles/120562/ ) намекают на то, что это не требует ни существенных серверных ресурсов, ни существенных затрат на реализацию.
В двух словах, вы просто считаете перцептивный хэш картинки при её добавлении на сайт и ищете среди существующих картинок этот хэш (выглядит как простой и быстрый запрос к бд).
К сожалению у меня сейчас нет возможности проверить насколько это хорошо работает. Поэтому извиняюсь, если там есть какие-то подводные камни - о них мне не известно.
Для гифок и видео можно хранить перцептивный хэш первого кадра.

А по-моему не стоит объединять гифки с видео. Тогда тега «со звуком» не понадобиться, т.к. по тегам webm/mp4 будет понятно что оно со звуком.

А вот для случая, когда «вся соль поста» в звуке, можно либо соответствующим специальным тегом обойтись, либо, например, плашку над видео показывать с текстом «включи звук», которая будет отображаться если у поста есть этот специальный тег(или выбрана такая опция при создании поста). Тут на самом деле можно много кастомных решений придумать, но в том, что звук не стоит вырезать из видео я убеждён. Да и звук можно по тычке на видео включать, чтобы не искать эту кнопку стандартную мелкую.

Что касается высоких видосов - они не напрягают. Но т.к. есть те, кого это напрягает, по-моему проще всего это сделать опциональным. Не обязательно даже как опцию в аккаунт добавлять. Можно, например, кастомной кнопкой на плеере, по нажатию на которую сохранить её значение на клиенте и считывать при отображении всех видосов. Ну т.е. это можно сделать без какого-то влияния на сервера.

"На глаз" - это вы имеете в виду синтаксис что ли?
Шарп язык более высокого уровня со всеми вытекающими. Как самый очевидный пример, в плюсах вручную за выделением и освобождением памяти следить надо, тогда как в шарпе это происходит автоматически. Или лучшая защита от ошибок компилятором. Чтобы сравнивать детально нужно в плюсах шарить. А моё знакомство с ним было очень коротким и неприятным 17 лет назад. Сам синтаксис - меньшая из проблем. Это другие библиотеки и фреймворки. Это решение заново старых задач, для которых ты уже нашёл решения раньше.
Курсы разработчиков? Это шутка такая? Стоимость курсов разработчиков ничто по сравнению с временем и усилиями, которые были потрачены разработчиками на освоение движка.
Мне сейчас стремно больше не из-за того, что они ввели эти неадекватные поборы, а из-за того, что они сейчас вообще могут слиться. Сказать, типа, «мы больше не можем терпеть убытки и не видим пути решения наших проблем, поэтому Юнити больше не существует». Я блин не вытяну переход на c++ и unreal в свои годы уже. И можно будет попрощаться с мечтой выпустить свою игру.
Мне кажется всё будет куда проще. Достаточно будет посмотреть куда и в каком виде юнити шлёт данные, и потом спамить этот эндпоинт с разным ключём (который они будут использовать для идентификации «новых» устройств). Ну т.е. достаточно будет воспользоваться одной специально написанной для этого программкой.