Тільки для спеціалістів з практичним досвідом та зразками робіт у рендерингу Lottie-json анімації! Ентузіастів з "походу розберемося" не розглядаю.
Бюджет обговорюваний, термін: до 7 днів.
Що потрібно зробити:
Реалізувати функцію/скрипт, який приймає анімовані Lottie JSON та текстові шари у веб-додатку (сайт) і генерує підсумковий відео-шар у форматі .webm (VP9 + alpha) з повною ідентичністю анімації та таймінгу з попереднім переглядом.
Контекст проекту:
Фронтенд: React (Vite), Бекенд: FastAPI, Сховище: MinIO (S3-сумісне), БД: PostgreSQL,
Контейнеризація: Docker, docker-compose, Для локальної розробки використовується docker-compose.yml (додається карта проекту)
Опис проблеми:
Поточний розробник намагався реалізувати дане завдання:
• через ffmpeg (не вдається відобразити коректні шрифти та кольори, параметри тексту з адмінки не застосовуються, Lottie JSON не виводиться, не вдається повторити ту ж анімацію, що на клієнті);
• через Remotion / Puppeteer (використовували remotion, puppeteer з записом через браузер, через ffmpeg, писали окреме api на nodejs. Результат або нульовий, або бачимо лише фрагменти тексту з артефактами - частково правильний шрифт і колір, але без таймінгів, без анімацій і сам Lottie JSON не підхоплюється).
Ітог: результат або порожній, або з артефактами, анімація відрізняється від попереднього перегляду, json-шари не запікаються.
Вимоги до реалізації:
Вивід: підсумковий файл формату webm (VP9 з альфа-каналом), частота - строго 30 FPS, роздільна здатність 1080х1920 px. Повна ідентичність попередньому перегляду (шрифти, кольори, таймінги) без втрати якості та ефектів анімації).
Процес: конвертація текстових та json-шарів повинна проводитися тільки після отримання веб-хука про оплату в онлайн-режимі без подальшого збереження на диску проміжних файлів (png-секвенцій та ін. супутніх матеріалів). Час конвертації не повинен перевищувати 20 секунд, очікувана вага файлу не більше 40 mb.
Місце збереження файлу: повинно задаватися параметром або змінною середовища, щоб його можна було перенастроїти без зміни коду.
Гнучкість: Код повинен бути написаний універсально: нові кастомні шрифти з підтримкою казахської кирилиці повинні підключатися автоматично без необхідності редагувати логіку рендеру. Система повинна брати JSON-анімації та текстові параметри динамічно, а не «вшивати» конкретний файл у код.
Перевірка результату: скрипт після підключення до бойового сайту буде тестуватися шляхом використання 5 різних шаблонів листівок, 5 діючих та 3 нових шрифтів, 5 варіантів довгого та короткого тексту з казахською кирилицею. Робота буде вважатися виконаною тільки після повного відповідності результату з вищезазначеними вимогами до реалізації.
