Nota o poufności: to case study jest celowo zanonimizowane. Pomija nazwę klienta, adres serwisu, nazwy produktów komercyjnych oraz wszelkie szczegóły funkcjonalne objęte NDA wykonawcy. Opisuje wyłącznie podejście, metodykę i wnioski inżynierskie.
Kontekst
Klient prowadzi polską platformę wideo działającą w modelu hybrydowym — transmisje na żywo połączone z VOD, dostępne zarówno w abonamencie, jak i w dostępie otwartym. Platforma jest zbudowana na popularnym CMS-ie rozszerzonym o dedykowane wtyczki.
Współpraca miała trzy cele:
- zastąpić istniejący webowy odtwarzacz nowoczesnym, wspierającym adaptacyjny streaming (HLS, MPEG-DASH)
- uniezależnić warstwę odtwarzania od aktualizacji CMS-a i szablonu — tak, by rutynowe aktualizacje wtyczek i szablonu nie wymagały ruszania odtwarzacza
- przygotować odtwarzacz pod DRM i wpiąć go w komercyjny system zarządzania kluczami (KMS)
Prace podzielono na dwa etapy:
- Etap 1 — warstwa odtwarzania, integracja z CMS-em, testy na wielu urządzeniach
- Etap 2 — pełna konfiguracja DRM
Wyzwania inżynierskie
1. Niezależność od warstwy CMS
„Kod niezależny od aktualizacji" brzmi jak trywialne wymaganie, ale w praktyce oznaczało zaprojektowanie odtwarzacza jako samodzielnego, wstrzykiwanego modułu JS/CSS, który komunikuje się z CMS-em wyłącznie przez zdefiniowany kontrakt — identyfikatory elementów DOM plus minimalna warstwa danych — nigdy przez hooki wtyczek. Cel: przetrwać nietkniętym refaktory szablonu i automatyczne aktualizacje wtyczek.
2. Jeden odtwarzacz do wielu źródeł treści
Odtwarzacz musiał jednolicie obsłużyć:
- pliki statyczne (MP4 i podobne)
- adaptacyjne strumienie HLS i MPEG-DASH
- wiele ścieżek audio (plik i strumień)
- wiele rozdzielczości / ABR
- napisy (sidecar oraz w manifeście)
- graficzny znak wodny (nakładka z logo)
- pełną matrycę przeglądarek: Chrome / Firefox / Edge / Safari × Windows / macOS / Android / iOS × smart TV / smartfon / tablet / desktop
Prawdziwą pułapką nie była funkcjonalność, tylko różnice w EME (Encrypted Media Extensions) i we wsparciu kodeków między przeglądarkami — szczególnie iOS/Safari kontra silniki oparte na Chromium.
3. Integracja z zewnętrznym KMS i migracje dostawców
Główny wątek etapu 2. W trakcie współpracy dostawca KMS był po stronie klienta zmieniany kilkukrotnie — każdy przychodził z innym modelem tokenizacji licencji, innymi wymaganiami CPIX, innym formatem parametrów w nagłówkach żądania licencji i innymi oczekiwaniami wobec ticket-auth. Każda zmiana dostawcy DRM wymuszała:
- przekonfigurowanie proxy licencji, które stoi między odtwarzaczem a KMS-em
- ponowne zmapowanie identyfikatorów zasobów na klucze DRM
- przebudowę warstwy uwierzytelniania żądań licencji
- ponowne przetestowanie ścieżek Widevine i PlayReady (oraz, w ustalonym zakresie, FairPlay dla Safari/iOS)
4. Zewnętrzny blocker poza kontrolą wykonawcy
Największym praktycznym problemem etapu 2 okazał się blocker infrastrukturalny po stronie klienta: moduł DRM użyty w stacku streamingowym klienta nie wspierał mechanizmu ticket-auth wymaganego przez wybrany KMS, a wsparcie techniczne zewnętrznego dostawcy przez kilka tygodni nie dostarczyło poprawki. Wszystko, co było do dostarczenia po mojej stronie (proxy DRM, konfiguracja KMS, ustawienie DRM w odtwarzaczu, testy API), było gotowe; integracja end-to-end zatrzymała się z przyczyn niezależnych od wykonawcy.
5. Prace spoza zakresu wchłonięte przez projekt
Po drodze doszły rzeczy spoza pierwotnego zakresu: poprawki skalowania obrazów
(object-fit), nachodzące na siebie warstwy z-index na poziomie menu,
popup logowania, blokada odtwarzania zależna od roli dla treści ograniczonych,
dynamiczne opisy pakietów abonamentowych i CTA kierujące użytkowników do zakupu
dostępu. Dostarczone w ramach dobrej woli, nierozliczane ponad stałe wynagrodzenie.
Podejście
- Odtwarzacz zbudowany na dojrzałej bibliotece open source z natywnym wsparciem MSE/EME, HLS i MPEG-DASH — co dało pełną kontrolę nad przepływem licencji i brak vendor lock-inu na samej warstwie odtwarzania.
- Warstwa proxy licencji — własny pośrednik normalizujący różnice między kolejnymi dostawcami KMS. Migracja dostawcy nie dotykała odtwarzacza; wymagała jedynie przekonfigurowania proxy.
- Rozdzielenie odpowiedzialności między CMS a warstwę odtwarzania — CMS dostarczał wyłącznie identyfikatory treści i metadane; cała logika odtwarzania, tokenów i licencji żyła poza nim.
- Matryca testów przeglądarkowych — systematyczne pokrycie głównych kombinacji przeglądarka × system × urządzenie, z osobną ścieżką testową dla urządzeń Apple (FairPlay).
- Dokumentacja zmian — każda zmiana dostawcy KMS była opisana w dedykowanym podsumowaniu, co pozwalało szybko odtworzyć kontekst po każdej przerwie w pracach.
Wnioski dla podobnych projektów
- Dostawcę DRM trzeba zamknąć przed startem prac integracyjnych. Zmiana dostawcy w trakcie projektu to częściowe przepisanie warstwy licencji — nie „drobna korekta konfiguracji".
- Zgodność serwera streamingowego z wybranym KMS trzeba zweryfikować empirycznie, a nie na podstawie marketingowej tabeli kompatybilności. Zwłaszcza uwierzytelnianie tokenem licencji bywa zaimplementowane w sposób, który de facto wyklucza pewne kombinacje.
- Zainwestuj w proxy licencji od pierwszego dnia — nawet startując z jednym KMS-em. Koszt napisania jest niewielki, a przy pierwszej migracji oszczędza tygodnie.
- Zakres, kryteria odbioru i ścieżkę eskalacji dla zewnętrznych blockerów trzeba spisać przed startem projektu. Projekt, którego krytyczna zależność (wtyczka DRM serwera streamingowego, czas reakcji wsparcia dostawcy) leży poza kontrolą wykonawcy, musi definiować mechanizm wstrzymania prac i przesunięcia terminów — inaczej ryzyko spływa asymetrycznie na wykonawcę.
- Matryca testów przeglądarkowych nie jest opcjonalna. Odtwarzacz działający bez zarzutu na Chrome/Windows potrafi zawieść w trzech różnych miejscach na Safari/iOS — od kodeka, przez zachowanie EME, po specyficzne dla WebKita dziwactwa pętli zdarzeń.
Efekt
- Nowy webowy odtwarzacz w pełni zastąpił poprzednie rozwiązanie z zachowaniem integracji z CMS-em i — dzięki konstrukcji samodzielnego modułu — bez konieczności interwencji po aktualizacjach CMS-a i wtyczek.
- Warstwa integracji DRM po stronie wykonawcy została przygotowana i przetestowana; domknięcie integracji end-to-end zablokowała zewnętrzna infrastruktura serwerowa po stronie klienta (wsparcie dostawcy, niezależne od wykonawcy).
- Po późniejszej zmianie warstwy streamingowej na inny stack po stronie klienta, projekt jest kontynuowany w ramach osobnego, nowego zakresu prac.
Opracowanie własne. Nie zawiera informacji objętych klauzulą poufności wobec klienta.