W ostatnim czasie uruchomiliśmy serwis vod.onet.pl. W chwili startu można było oglądać 1350 pozycji i liczba ta cały czas będzie rosła zarówno dzięki zamieszczaniu produkcji produkowanych przez Grupę TVN jak i dzięki pozyskiwaniu filmów zagranicznych producentów, jak np. Warner Bros.

Do korzystania z VOD Onet wystarczy przeglądarka internetowa. Nie ma potrzeby instalowania dodatkowych aplikacji. Dzięki temu serwis działa na platformach Windows i Mac. Wykorzystaliśmy najnowsze techniki Silverlight, Play-Ready i Smooth Streaming firmy Microsoft. To ostatnie rozwiązanie pozwala dostosowywać w czasie rzeczywistym jakość obrazu i dźwięku wyświetlanego na ekranie komputera do aktualnej przepustowości łącz użytkownika.

Microsoft Silverlight umożliwiaja wyświetlanie treści multimedialnych za pomocą przeglądarki. Podobnie jak w rozwiązaniu Flash, w Silverlight można przechwytywać zachowania (zdarzenia) myszy i klawiatury, wyświetlać pliki graficzne i obsługiwać dźwięki. Dodatkowo za pomocą Silverlight możliwe jest wyświetlanie standardowych plików video oraz tych w wysokiej rozdzielczości (HD). Możliwe jest również odtwarzanie plików muzycznych (MP3, WMA). Silverlight obsługuje DRM (Digital Rights Management) PlayReady. Ten ostatni jest następcą techniki Microsoft DRM, którą w roku 2006 DreamLab prekursorsko zastosował na dużą skalę w polskim Internecie – już wtedy pokazywaliśmy Ligę Mistrzów, później seriale TVN, koncerty itd.

Infrastruktura

Zaprojektowanie infrastruktury pod ten serwis było trudnym zadaniem: pierwszą barierą na którą napotkaliśmy było zaimportowanie treści – kodeki VC-1 i h.264 wykorzystywane w serwisie są dość ciężkie i przygotowanie dużej porcji materiałów do publikacji stało się wyzwaniem. Musieliśmy zbudować w tym celu rozproszony system zarządzania zadaniami transkodowania i zabezpieczania DRM publikowanych materiałów. Korzystaliśmy tu z doświadczeń z konstrukcji klastrów obliczeniowych, bo zagadnienie jest dość podobne – musimy zarządzać kolejką zadań, z których wykonanie każdego trwa dość dużo czasu, jednocześnie zarządzać priorytetami.

Jako enkodery wykorzystaliśmy farmę serwerów podających multimedia do użytkowników – enkoding jest operacją wymagającą wyłącznie procesora: odpowiednio obniżając priorytety procesów enkodujących uzyskaliśmy gwarancję że ten proces nie wpłynie negatywnie na podstawowe zadanie tych maszyn.

Gdy już udało nam się rozwiązać problem odpowiednio szybkiego wprowadzania materiałów do systemu, trzeba było wymyślić sposób na ich podawanie naszym użytkownikom. Mimo dotychczasowych doświadczeń ze streamingiem multimediów opartych o platformę Windows to było coś całkowicie nowego:

  • Miała się tam pojawić zupełnie inna treść – materiały wideo zakodowane z jakością HD, co jest poważnym zagadnieniem zarówno z punktu widzenia storage jak i sieci.
  • Zaczęliśmy korzystać z technologii Smooth Streaming – czegoś całkowicie odmiennego od protokołu RTSP używanego do tej pory.
  • Zmieniała się charakterystyka ruchu: bieżący ruch multimedialny w portalu ma zwykle kilka ognisk – najpopularniejszych materiałów, których podanie w dużej ilości nie nastręcza poważnych problemów (taki plik się doskonale cache’uje w pamięci – wystarczy tylko odpowiednio mocny serwer żeby poradził sobie z dużą ilością połączeń i odpowiednia karta sieciowa). Tym razem pojawił się tzw. długi ogon: oczywiste jest że kiedy użytkownicy mają do dyspozycji kilka tysięcy materiałów multimedialnych, to nie poprzestaną na obejrzeniu trzech, ale będą starali się oglądać inne. Skutkuje to sytuacją, kiedy większość materiałów jest jednakowo popularna i system musi sobie poradzić z odpowiednio wydajnym ich podawaniem.
  • Pojawił się nowy system zarządzania prawami do multimediów cyfrowych – PlayReady, który musieliśmy zaimplementować zachowując jednocześnie dotychczasowy Windows Media DRM 10.

Mając te czynniki na uwadze dostosowaliśmy do nowego zadania nasz system służący dotąd do podawania materiałów Windows Media. Cele które nam przyświecały przy budowie tego systemu to: zapewnienie maksymalnej skalowalności pionowej i poziomej oraz zatrzymanie jak największej części ruchu jak najbliżej użytkownika. Udało się to poprzez zastosowanie warstwowej struktury systemu podającego strumienie wideo z wyspecjalizowanymi cache’ami z przodu, oraz odpowiednio wydajnym systemem storage’owym z tyłu. Dodatkowo system który pracuje w portalu internetowym tej wielkości musi mieć możliwość działania w kilku lokalizacjach, z dołączonymi różnymi ISP. Musi mieć umiejętność reagowania na zmieniające się obciążenie łączy i zapewniać najwyższą możliwą jakość dla użytkownika końcowego.

Opierając się na tych założeniach, zbudowaliśmy system który potrafił podawać multimedia zarówno przy użyciu Windows Media Services, jak i IIS Smooth Streaming.
Całość udostępniliśmy na świat na tydzień przed planowaną oficjalną premierą usługi, co pozwoliło nam na obserwację i ostateczne dostrojenie systemu pod rzeczywistym (choć relatywnie niewielkim) ruchem.

Smooth Streaming

Ideą działania tego zintegrowanego z Internet Information Services (IIS) 7.0 systemu,  jest możliwość dynamicznego dopasowania wielkości strumienia do bieżących warunków sieciowych i zajętości procesora występujących u klienta.

Podstawą działania jest stworzenie kliku plików na dysku w formacie MPEG-4 Part 14 (ISO/IEC 14496-12). Każdy jest przygotowany dla innej jakości strumienia i podzielony na małe kawałki (nazywane chunk/GOP) o czasie trwania rzędu 2-4 sekund. Żądanie od klienta dotyczy zawsze określonego fragmentu filmu i serwer dynamicznie wybiera z którego pliku (jakiej jakości) podać odpowiedź. Oznacza to, że końcowy strumień może się składać z połączonych kawałków różnej jakości.

Format został wybrany (w porównaniu z asf) ze względu na: mniejszy narzut nagłówka, łatwość przetwarzania w .NET, szersze zastosowanie przez inne firmy, w tym wsparcie dla standardu H.264 i fragmentacji materiału.

Na dysku serwera znajduje się kilka plików o rozszerzeniu .ismv, każdy zawierający jeden strumień audiowizyjny dopasowany do określonej przepustowości łącza (na podstawie najczęściej występujących w Polsce). Oprócz plików ze strumieniami tworzone są pliki manifestów (rozszerzenia .ism oraz .ismc) w formacie XML (SMIL 2.0), opisujące strumienie, ich ilość bitów na sekundę, rozdzielczości, zastosowane kodeki, itp. Manifest dla klienta (.ismc) jest pierwszym plikiem wysyłanym do oprogramowania klienckiego i na podstawie informacji tam zawartych tworzone są zapytania o kolejne fragmenty strumienia audio i wideo zgodnie z protokołem REST. Żądania zawierają wybraną stopę bitową oraz miejsce początku fragmentu klipu (podanego w setkach nanosekund).

Podstawą działania techniki łagodnego (smooth) strumieniowania jest użycie tego samego źródła do stworzenia plików zawierających filmy różnej jakości oraz idealna synchronizacja pomiędzy nimi. W każdym kawałku znajdują ramki kodowane niezależnie (kluczowe) oraz zależne. Istotny jest również brak powiązań pomiędzy ramkami z różnych fragmentów (brak powiązanych kluczowych ramek referencyjnych w innym fragmencie).

PlayReady DRM

Zabezpieczanie treści multimedialnych w systemie PlayReady DRM polega na zaszyfrowaniu plików. W ten sposób nie ma potrzeby ukrywania plików i mogą one być dowolnie przenoszone czy kopiowane. Taka akcja nie musi oznaczać, że prawa pierwszego użytkownika są dziedziczone przez tego, który otrzymał plik, gdyż są one związane z przydzieloną licencją. Posiada ona zapis praw i ograniczeń (np. możliwość odtworzenia bez nagrania na CD przez cały marzec 2010). Licencja może być przywiązana zarówno do określonego urządzenia, jak i całej domeny. W ten sposób dowolny użytkownik domeny może ją wykorzystać po oznaczeniu tego faktu w serwerze licencji. Istnieje również możliwość dołączenia licencji do zaszyfrowanego pliku, co jest szczególnie przydatne w przypadku braku dostępu do sieci Internet.

System PlayReady pozwala zabezpieczyć różnego rodzaju treści, m.in.: gry, obrazki, dzwonki, muzykę i filmy w formatach: WMA, WMV, AAC, AAC+, H.263, H.264.

Udostępnianie treści może odbywać się w różnych modelach. Są to:

  • subskrypcja – płatność za dostęp do katalogu z wieloma materiałami w określonym przedziale czasowym z ewentualnie limitowaną liczbą odtworzeń, otrzymując jedną licencję na wszystkie materiały,
  • zakup – opłata za ściągnięcie na swój dysk pojedynczych utworów,
  • PPV – (pay per view) – opłata za jednorazowe oglądnięcie (odsłuchanie),
  • wypożyczenie – wielokrotne odtworzenie utworu w zadanym czasie (np. w ciągu 30 dni i 24 godziny od pierwszego odtworzenia),
  • prezent – zakup dla innego użytkownika.

Ze względu na możliwe sposoby dostarczania treści do odbiorcy można wyróżnić:

  • ściąganie pliku podstawowe (oglądanie po zakończeniu) lub progresywne (start po otrzymaniu określonej porcji danych),
  • strumieniowanie to odtwarzanie materiału z sieci bez zapisu na lokalnym dysku,
  • synchronizacja urządzenia mobilnego z komputerem,
  • bezpośrednie pozyskiwanie licencji przez sieć bezprzewodową,
  • super-dystrybucja – dzielenie się materiałami z innymi użytkownikami (w tym kupowanie prezentów).

Silverlight

Klient Silverlight jest stworzony na platformie .NET i zawiera moduły do przetwarzania formatu MPEG-4, obsługi protokołu HTTP oraz logikę przełączania pomiędzy strumieniami. Dzięki takiemu podejściu, programiści rozwijający aplikacje bazujące na tej technice mogą dopasowywać oprogramowanie klienckie Silverlight do aktualnych potrzeb. Kryteriami branymi pod uwagę powinny być między innymi możliwości obliczeniowe procesora, aktualna rozdzielczość monitora (w tym minimalizacja przeglądarki), wielkość bufora dla materiału wizyjnego, możliwość przełączania między różnymi klipami (reklamy, filmy właściwe).

Rozruch

Nadeszła walentynkowa niedziela 14 lutego 2010… Muszę przyznać że niedzielne wydanie „Dzień dobry TVN” oglądaliśmy z niepokojem – teoretycznie system przeszedł wszystkie testy i tygodniowe działanie jako publicznie dostępna beta, ale wieloletnia praktyka (i prawa Murphy’ego) nakazywała spodziewać się różnych rzeczy, zwłaszcza że start był obserwowany dosłownie przez wszystkich wtajemniczonych. Program w TV się toczył według własnego scenariusza, aż na ekranie pojawili się oprócz Prowadzących, prezes Łukasz Wejchert i dyrektor Edward Miszczak. Panowie opowiadali o rewolucji jaka się właśnie dokonuje w polskim Internecie. Gdy padło oczekiwane „vod.onet.pl” – zaczęło się…
Mieliśmy już doświadczenia ze skutecznością reklam telewizyjnych, ale tym razem efekt przeszedł najśmielsze przewidywania – ruch wystrzelił w górę niczym rakieta kosmiczna. W ciągu każdej minuty, do naszego systemu dołączały się i zaczynały oglądać filmy tysiące ludzi.

Dysponowaliśmy zestawionym połączeniem konferencyjnym w obrębie teamu uruchamiającego usługę. Zespół zawierał reprezentantów wszystkich stron zaangażowanych w uruchomienie usługi. Obserwując systemy monitoringu wymienialiśmy tylko uwagi dotyczące skali ruchu, bo całość po prostu zadziałała od razu i obsłużyła wszystkich użytkowników którzy się podłączyli. Dalej niedziela mogła być już tylko spokojniejsza…

Po tym jak całość ruszyła, w poniedziałek nadszedł czas na analizę wydarzeń niedzielnych – pojawiło się kilka sygnałów o dziwnym zachowaniu odtwarzacza, który potrafił wpaść w niestabilny stan. Było to spowodowane błędem w bibliotekach odpowiedzialnych za implementację protokołu SmoothStreaming i udało się nam obejść programowo.
Przez kilka kolejnych tygodni wyjątkowo intensywnej promocji serwisu wyłapaliśmy jeszcze kilka niedociągnięć, dostroiliśmy konfigurację systemu, co zaowocowało docelowo stabilną, wydajną i skalowalną konfiguracją która zapewnia maksymalną jakość świadczonej usługi. Nauczyliśmy się lepiej monitorować jakość dostarczania usługi użytkownikom końcowym, potrafimy w razie konieczności zejść do poziomu pojedynczej sesji odtwarzania i zanalizować jej jakość. Poznaliśmy też pewne aspekty działania protokołu SmoothStreaming o których nie ma śladu w dokumentacji, a które w pierwszej chwili mogą być nieoczywiste.

Przy okazji dostarczyło nam to mnóstwo satysfakcji – takie chwile są jedną z najlepszych nagród jakie można dostać za miesiące pracy nad projektem tej klasy.

Podsumowanie

Praca przy tym projekcie była dla nas prawdziwym wyzwaniem z powodu nowatorskiego stosowania różnych rozwiązań. Każde z osobna było już wcześniej wykorzystywane komercyjnie przez innych, lecz ich integracja przez nas jest innowacyjna, gdyż techniczna możliwość pojawiła się już w trakcie trwania projektu i wymagała praktycznie ciągłego dopasowywania do nowych wymagań. Przy okazji dostarczyło nam to mnóstwo satysfakcji – takie chwile są jedną z najlepszych nagród jakie można dostać za miesiące pracy nad projektem tej klasy.
Czytelników zainteresownanych dalszymi szczegółami zastosowanych technologii zapraszamy na strony:

Krzysztof Juszkiewicz
starszy programista
Marcin Kaptur
starszy projektant systemów informatycznych