Tylko dla specjalistów z praktycznym doświadczeniem i próbkami prac w renderowaniu animacji Lottie-json! Entuzjastów z "po drodze się dowiemy" nie rozważam.
Budżet do uzgodnienia, termin: do 7 dni.
Co należy zrobić:
Zrealizować funkcję/skrypt, który przyjmuje animowane Lottie JSON i warstwy tekstowe w aplikacji webowej (strona) i generuje końcową warstwę wideo w formacie .webm (VP9 + alpha) z pełną tożsamością animacji i timingu z podglądem.
Kontekst projektu:
Frontend: React (Vite), Backend: FastAPI, Magazyn: MinIO (zgodne z S3), Baza danych: PostgreSQL,
Konteneryzacja: Docker, docker-compose, Do lokalnego rozwoju używany jest docker-compose.yml (załączona mapa projektu)
Opis problemu:
Aktualny deweloper próbował zrealizować to zadanie:
• przez ffmpeg (nie udaje się wyświetlić poprawnych czcionek i kolorów, parametry tekstu z panelu administracyjnego nie są stosowane, Lottie JSON nie jest wyświetlany, nie udaje się powtórzyć tej samej animacji, co na kliencie);
• przez Remotion / Puppeteer (używali remotion, puppeteer z nagrywaniem przez przeglądarkę, przez ffmpeg, pisali osobne api na nodejs. Wynik jest albo zerowy, albo widzimy tylko fragmenty tekstu z artefaktami - częściowo poprawna czcionka i kolor, ale bez timingu, bez animacji i sam Lottie JSON nie jest ładowany).
Wynik: wynik jest albo pusty, albo z artefaktami, animacja różni się od podglądu, warstwy json nie są zapiekane.
Wymagania dotyczące realizacji:
Wyjście: końcowy plik formatu webm (VP9 z kanałem alfa), częstotliwość - ściśle 30 FPS, rozdzielczość 1080x1920 px. Pełna tożsamość z podglądem (czcionki, kolory, timingi) bez utraty jakości i efektów animacji).
Proces: konwersja warstw tekstowych i json powinna odbywać się tylko po otrzymaniu webhooka o płatności w trybie online bez późniejszego zapisywania na dysku plików pośrednich (sekwencji png i innych materiałów towarzyszących). Czas konwersji nie powinien przekraczać 20 sekund, oczekiwana waga pliku nie większa niż 40 mb.
Miejsce zapisu pliku: powinno być określane parametrem lub zmienną środowiskową, aby można je było skonfigurować bez zmiany kodu.
Elastyczność: Kod powinien być napisany uniwersalnie: nowe niestandardowe czcionki z obsługą kazachskiej cyrylicy powinny być automatycznie podłączane bez potrzeby modyfikacji logiki renderowania. System powinien dynamicznie pobierać animacje JSON i parametry tekstowe, a nie „wbudowywać” konkretny plik w kod.
Sprawdzanie wyniku: skrypt po podłączeniu do strony produkcyjnej będzie testowany przy użyciu 5 różnych szablonów kartek, 5 działających i 3 nowych czcionek, 5 wariantów długiego i krótkiego tekstu z kazachską cyrylicą. Praca będzie uznawana za wykonaną tylko po pełnym spełnieniu wyników z powyższymi wymaganiami dotyczącymi realizacji.
