Media i streaming w rozwoju mobilnym: co to jest, jakie protokoły i jak działa

Protokoły HLS i DASH

HTTP Live Streaming (HLS) to protokół do streamingu w aplikacjach mobilnych opracowany przez Apple. Dzieli wideo na małe segmenty (zwykle 6–10 sekund) i przesyła je przez zwykły HTTP. Odtwarzacz pobiera listę odtwarzania (.m3u8) i sekwencyjnie ładuje segmenty, dostosowując jakość do prędkości połączenia. HLS zapewnia niezawodny streaming w aplikacjach mobilnych na wszystkich urządzeniach Apple i jest de facto standardem dla iOS.

HLS vs DASH

DASH (Dynamic Adaptive Streaming over HTTP) to otwarty standard MPEG do dostarczania mediów do aplikacji mobilnych. W przeciwieństwie do HLS, DASH używa formatu MP4 dla segmentów i manifestu XML (MPD) zamiast .m3u8. DASH daje większą kontrolę nad kodekami i obsługuje więcej formatów. Wybór między HLS a DASH to kluczowa decyzja przy opracowywaniu streamingu dla urządzeń mobilnych. Porównanie protokołów przedstawiono w poniższej tabeli.

W praktyce aplikacje iOS wybierają HLS — AVPlayer działa z nim natywnie. Dla Android preferowany jest DASH dzięki ExoPlayer. Oba protokoły nadają się do streamingu mediów na urządzeniach mobilnych. W IT Sectr używamy obu technologii i zalecamy wybór protokołu na podstawie docelowej platformy.

Adaptacyjna przepływność i kodeki

Adaptive Bitrate (ABR) to mechanizm, w którym odtwarzacz automatycznie wybiera jakość wideo na podstawie prędkości połączenia. Strumień jest kodowany w wielu przepływnościach (360p, 720p, 1080p, 4K). Odtwarzacz przełącza się między nimi bez przerw. Kodeki: H.264 (AVC) — podstawowy, H.265 (HEVC) — 50% wydajniejszy, VP9 i AV1 — otwarte alternatywy dla Android.

Do dekodowania sprzętowego w aplikacjach mobilnych ważny jest wybór odpowiedniego kodeka. Hardware Decoding wykorzystuje GPU/procesor wideo urządzenia i zużywa mniej baterii. Software Decoding działa na CPU — używany, gdy dekodowanie sprzętowe jest niedostępne. IT Sectr zaleca zawsze sprawdzać obsługę kodeków przez MediaCodec (Android) lub AVAssetTrack (iOS) w celu optymalnego odtwarzania mediów na urządzeniach mobilnych.

Odtwarzacze: ExoPlayer i AVPlayer

ExoPlayer to odtwarzacz multimedialny Google dla Android, zoptymalizowany do odtwarzania mediów w aplikacjach mobilnych. W przeciwieństwie do MediaPlayer, ExoPlayer nie jest związany z dekodowaniem sprzętowym i obsługuje niestandardowe schematy przez moduły rozszerzeń. Działa z HLS, DASH, SmoothStreaming i RTSP. ExoPlayer to główny odtwarzacz YouTube, Google TV i Android TV.

ExoPlayer vs AVPlayerViewController

AVPlayer i AVPlayerViewController to odtwarzacze Apple dla iOS, macOS, tvOS. AVPlayer to niskopoziomowe API, AVPlayerViewController to gotowy interfejs UI z PiP i AirPlay. Główne różnice: ExoPlayer daje pełną kontrolę nad buforowaniem i renderowaniem, AVPlayerViewController oferuje szybką integrację z minimalnym kodem. Wybór odtwarzacza bezpośrednio wpływa na jakość streamingu w aplikacjach mobilnych.

// ExoPlayer — podstawowa konfiguracja odtwarzacza na Android
val player = ExoPlayer.Builder(this)
    .setMediaSource(ProgressiveMediaSource.Factory(DefaultHttpDataSource.Factory()))
    .build()
val mediaItem = MediaItem.fromUri("https://example.com/stream.m3u8")
player.setMediaItem(mediaItem)
player.prepare()
player.playWhenReady = true

Kod pokazuje minimalną inicjalizację ExoPlayer: utworzenie instancji, ustawienie elementu multimedialnego i rozpoczęcie odtwarzania. ExoPlayer automatycznie obsługuje cykl życia Activity przez player.release() w onStop. Dla Android TV lub PiP wymagana jest dodatkowa obsługa cyklu życia przez PlayerView — jest to szczególnie ważne przy konfiguracji streamingu dla aplikacji mobilnych.

Transkodowanie i przetwarzanie wideo

Transcoding to konwersja wideo z jednego formatu na inny. Służy do optymalizacji strumieni mediów dla różnych urządzeń mobilnych (np. H.264 → H.265). Na urządzeniach mobilnych transkodowanie jest możliwe przez MediaCodec (Android) lub AVAssetExportSession (iOS). Transkodowanie jest zasobożerne i rozładowuje baterię — wykonuj je w tle przez WorkManager lub BGTaskScheduler.

DRM: Widevine, FairPlay i PlayReady

Digital Rights Management (DRM) to systemy ochrony treści multimedialnych przed nieautoryzowanym kopiowaniem. Do streamingu mediów premium w aplikacjach mobilnych używane są trzy główne technologie: Widevine (Google), FairPlay (Apple) i PlayReady (Microsoft). Bez DRM usługi premium (Netflix, Spotify, Disney+) nie mogą dystrybuować treści.

Porównanie systemów DRM

Widevine to standard ochrony DRM dla Android, dostępny w trzech poziomach: L3 (szyfrowanie programowe), L2, L1 (szyfrowanie sprzętowe, tylko Trusted Execution Environment). FairPlay to ekskluzywny system Apple, wykorzystuje SVP (Secure Video Pipeline) na poziomie chipa. PlayReady to system Microsoft, rozpowszechniony na urządzeniach Xbox i Windows.

Multi-DRM to podejście, w którym używasz jednej platformy do zarządzania wszystkimi kluczami DRM. Przykład: EZDRM lub Verimatrix. Wydają one licencje Widevine, FairPlay i PlayReady przez ujednolicone API. Multi-DRM jest szczególnie istotny dla mediów premium na urządzeniach mobilnych. W IT Sectr wdrażamy multi-DRM przez agregatorów — oszczędza to czas i pieniądze w porównaniu z integracją każdego DRM osobno.

Odtwarzanie dźwięku: Audio Focus i Audio Session

Audio Focus (Android) to system zarządzania strumieniami audio do odtwarzania mediów w aplikacjach mobilnych. Gdy Twoja aplikacja żąda Audio Focus, inne aplikacje (muzyka, podcasty) wstrzymują się lub zmniejszają głośność (ducking). Bez Audio Focus dwie aplikacje grałyby jednocześnie, powodując hałas.

Audio Focus na Android

Android dzieli strumienie audio na typy: MUSIC, VOICE_CALL, ALARM, NOTIFICATION. Dla odtwarzacza multimedialnego musisz zażądać AudioManager.AUDIOFOCUS_GAIN. Po utracie fokusu (połączenie przychodzące) należy wstrzymać odtwarzanie multimediów i wznowić po powrocie fokusu. Implementacja przez AudioManager.OnAudioFocusChangeListener.

Audio Session na iOS

Audio Session (iOS) to odpowiednik Audio Focus dla aplikacji multimedialnych na urządzeniach mobilnych Apple. Jest konfigurowany przez AVAudioSession.sharedInstance(). Kategorie: .playback (wymagane dla wideo), .soloAmbient (domyślne, cisza przy blokadzie), .playAndRecord (do nagrywania). Do streamingu używaj .playback z opcją .allowAirPlay.

PiP i AirPlay

Picture-in-Picture (PiP) to tryb, w którym treści multimedialne są nadal odtwarzane w małym, pływającym oknie po zminimalizowaniu aplikacji lub przejściu do innego ekranu. PiP stał się standardem dla aplikacji multimedialnych na urządzeniach mobilnych — iOS (od iPadOS 13) i Android (od Android 8.0).

PiP na Android

Na Android PiP jest włączany przez Activity.isInPictureInPictureMode() i PictureInPictureParams.Builder. Aplikacja musi być w trybie wielu okien. MediaSession jest wymagany do sterowania odtwarzaniem multimediów z okna PiP. W manifeście określ android:supportsPictureInPicture="true".

AirPlay i Chromecast

AirPlay to protokół Apple do strumieniowania multimediów na Apple TV, HomePod i kompatybilne Smart TV. Na iOS jest implementowany przez AVRoutePickerView lub MPNowPlayingInfoCenter. Na Android odpowiednikiem jest Google Cast SDK (Chromecast). Obie technologie wymagają konfiguracji w pliku binarnym i wsparcia w odtwarzaczu. Wysokiej jakości streaming w aplikacjach mobilnych jest niemożliwy bez jednej z nich.