Bölüm 73: Uyarlanır Video Akışı

İstemci. 17. bölümde DASH’in fikrini görmüştün: sunucu videoyu birkaç saniyelik parçalara bölüyor, her parçayı birkaç farklı hızda kodluyor ve bir listede yayımlıyor. Hangi parçanın hangi hızda ve ne zaman isteneceğine oynatıcı karar veriyor.

O kararın içine girmek için üç şeyi bilmek gerekiyor. Video neden bu kadar sıkıştırılabiliyor, oynatıcının elindeki tampon nasıl doluyor ve boşalıyor, karar veren algoritma neye bakıyor? Sonunda canlı yayının neden hep birkaç saniye geriden geldiğine de bakacağız.

Önce ölçek. Sıkıştırılmamış bir film saniyede kaç bit tutuyor?

Ham görüntü, sıkışmış görüntü

1920×1080 çözünürlükte, piksel başına 24 bit renk ve saniyede 60 kare: 1.920 × 1.080 × 24 × 60, yani saniyede yaklaşık 3 gigabit. Aşağıda göreceğin gerçek bir yayın listesi aynı görüntüyü saniyede 5 ile 8 megabit arasında gönderiyor. Arada yaklaşık 370 ile 600 katlık bir sıkıştırma var.

Bu oran iki tekrardan geliyor. Birincisi karenin içindeki tekrar: gökyüzünün bir parçası yanındaki parçaya benziyor ve kodlayıcı bu benzerliği bir dönüşümle birkaç sayıya indiriyor. İkincisi kareler arasındaki tekrar ve asıl kazanç orada. Saniyede 60 kare çekilen bir sahnede ardışık iki kare neredeyse aynı; değişen şey birkaç nesnenin konumu. Kodlayıcı ikinci kareyi baştan yazmak yerine “birinci karenin şu bloğu şu kadar sağa kaydı” diyor.

Bu yüzden kareler üç türe ayrılıyor:

B karesi sezgiye ters bir sonuç doğuruyor: bir kareyi çözmek için gelecekteki bir kareye ihtiyaç var. Bu yüzden kareler ekranda gösterildikleri sırayla değil, çözülecekleri sırayla gönderiliyor. Gelecekteki kare önce geliyor, arada kalan B kareleri sonra.

Bir I karesinden bir sonrakine kadarki kare grubuna GOP deniyor. Bir oynatıcı yayına ancak bir I karesinden katılabiliyor, çünkü ondan önceki her kare bir öncekine dayanıyor. Akış açısından bundan çıkan kural kesin: her parça, kendinden öncekilere hiç dayanmayan bir I karesiyle başlamak zorunda. Oynatıcı ancak böylece parça sınırında bir hızdan ötekine geçebiliyor.

Kodlayıcı kuşakları aynı işi giderek daha az bitle yapıyor. 2003’te çıkan H.264 bugün hâlâ en yaygını. 2013’te gelen H.265, yani HEVC, aynı kaliteyi yaklaşık yarı bit hızıyla veriyor ama patent lisansları karmaşık. 2018’de dondurulan AV1’i ise büyük teknoloji şirketlerinin kurduğu bir birlik telifsiz olsun diye tasarladı. Her yeni kuşak bit kazandırıyor, karşılığında kodlama tarafında çok daha fazla işlem istiyor.

Bir merdiven, birçok basamak

Apple’ın geliştiricilere örnek olarak yayımladığı bir yayının ana listesi şöyle başlıyor (satırlar kısaltıldı):

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-STREAM-INF:BANDWIDTH=2177116,CODECS="avc1.640020,mp4a.40.2",RESOLUTION=960x540,FRAME-RATE=60.000
v5/prog_index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=8001098,CODECS="avc1.64002a,mp4a.40.2",RESOLUTION=1920x1080,FRAME-RATE=60.000
v9/prog_index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=6312875,CODECS="avc1.64002a,mp4a.40.2",RESOLUTION=1920x1080,FRAME-RATE=60.000
v8/prog_index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=4943747,CODECS="avc1.64002a,mp4a.40.2",RESOLUTION=1920x1080,FRAME-RATE=60.000
v7/prog_index.m3u8
...
#EXT-X-STREAM-INF:BANDWIDTH=541052,CODECS="avc1.640015,mp4a.40.2",RESOLUTION=480x270,FRAME-RATE=30.000
v2/prog_index.m3u8

Her STREAM-INF satırı merdivenin bir basamağı. BANDWIDTH o basamağın tepe bit hızı, CODECS içindeki avc1 H.264 görüntüyü, mp4a.40.2 AAC sesi gösteriyor. Listede sekiz basamak var: 480×270’te 0,54 Mbit/s’den 1080p’de 8 Mbit/s’ye. Dikkat çeken ayrıntı, aynı 1920×1080 çözünürlüğün üç ayrı basamakta durması. Çözünürlük kalitenin tamamı değil; aynı piksel sayısı daha az bitle daha bulanık, daha çok bitle daha net kodlanabiliyor.

Basamaklardan birinin kendi listesine girince parçalar görünüyor (bazı satırlar çıkarıldı):

#EXTM3U
#EXT-X-TARGETDURATION:6
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MAP:URI="main.mp4",BYTERANGE="719@0"
#EXTINF:6.00000,
#EXT-X-BYTERANGE:1508000@719
main.mp4
#EXTINF:6.00000,
#EXT-X-BYTERANGE:1510244@1508719
main.mp4

Her parça 6 saniye; bu listede 100 tane var, yani on dakikalık bir video. Sürpriz şurada: parçalar ayrı dosyalar bile değil. Hepsi tek bir main.mp4 dosyasının içinde duruyor ve BYTERANGE satırı hangi bayt aralığının istenmesi gerektiğini söylüyor. Oynatıcı her parça için aynı dosyadan bir aralık isteği gönderiyor. İlk satırdaki 719 baytlık parça ise görüntüyü çözmeye yetecek ayarları taşıyan başlangıç bölümü. Parça başına yaklaşık 1,5 MB, 6 saniyeye bölünce saniyede 2 megabite yakın; ana listedeki 2,17 Mbit/s’lik basamakla tutarlı.

Merdivenin basamaklarını kim ve neye göre seçiyor? Netflix 2010’da bütün kataloğu için tek bir merdiven kullanıyordu: 235 kbit/s’den 5.800 kbit/s’ye on basamak, her birine sabit bir çözünürlük. 2015’te bunu bıraktı. Çizgi film gibi sade bir görüntü 1080p’de 1,5 Mbit/s ile iyi görünürken, film greniyle dolu bir sahne 5,8 Mbit/s’de bile bloklaşıyordu. Artık her yapımın merdiveni kendi karmaşıklığına göre çıkarılıyor. Doğru bit hızı içeriğe bağlı.

Tampon: ağ ile ekran arasındaki depo

Oynatıcı, parçaları indirdikçe bir tampona koyuyor ve tamponu gerçek zamanlı hızla boşaltarak oynatıyor. Ağın dalgalanmasını ekrandan saklayan şey bu depo.

Hesabı bir kez yapmak her şeyi açıklıyor. Parçalar 4 saniyelik ve oynatıcı 5 Mbit/s’lik basamağı seçmiş olsun. Bir parça 20 megabit.

• Hat 8 Mbit/s veriyorsa bir parça 2,5 saniyede iniyor. Tampona 4 saniye giriyor, bu sırada 2,5 saniye oynatılıyor: her parçada tampon 1,5 saniye büyüyor.
• Hat 4 Mbit/s’ye düşerse aynı parça 5 saniyede iniyor. Tampona yine 4 saniye giriyor ama 5 saniye oynatılıyor: her parçada tampon 1 saniye eriyor. 20 saniyelik bir tampon 20 parça, yani yaklaşık 100 saniye sonra biter ve görüntü donar.

Donmanın adı yeniden tamponlama ve izleyicinin en az affettiği şey o. 2011’de büyük video sağlayıcılarının milyonlarca oturumunu inceleyen bir çalışma, tamponda geçen süre oranının bütün içerik türlerinde izleme süresini en çok etkileyen ölçüt olduğunu gösterdi. En sert etki canlı yayındaydı: 90 dakikalık canlı bir etkinlikte tamponlama oranındaki %1’lik artış, izleme süresini üç dakikadan fazla kısaltıyordu.

Tamponun bir üst sınırı da var. Dolduğunda oynatıcı indirmeyi durduruyor, biraz boşalınca yeniden başlıyor. Bağlantı böylece bir açık bir kapalı çalışıyor ve 17. bölümün sonunda anlatılan sorun burada doğuyor: aynı hattaki iki oynatıcı birbirinin sessiz anlarını boş kapasite sanıyor.

Kararı veren algoritma

Oynatıcı her parçadan önce aynı soruyu soruyor: sıradaki parçayı hangi basamaktan isteyeyim? Bu kararı veren mantığa ABR (adaptive bitrate) deniyor ve üç ana yaklaşım var.

Hıza bakan. Son birkaç parçanın ne hızla indiğini ölç, bir güvenlik payı düş ve o hızın altındaki en yüksek basamağı seç. Sezgisel, ama ölçüm yanıltıcı olabiliyor. Açık-kapalı çalışan bir bağlantıda her parça bir sessizlikten sonra başlıyor. Linux varsayılan olarak (net.ipv4.tcp_slow_start_after_idle = 1) bir yeniden gönderim zaman aşımından uzun bekleyen bağlantının tıkanıklık penceresini küçültüyor. Her parçanın başında hız 68. bölümdeki yavaş başlangıçtan yeniden tırmanıyor. Kısa parçalarda ölçülen hız, hattın gerçek kapasitesinin altında kalıyor.

Tampona bakan. Netflix’in 2014’te yayımladığı çalışma soruyu tersine çevirdi: kapasiteyi tahmin etmek zorunda mıyız? Tampon doluysa yüksek basamak seç, boşalıyorsa düşük; aradaki bölgede tampon doluluğunu doğrudan bir bit hızına eşle. Mayıs ile Eylül 2013 arasında milyonlarca gerçek kullanıcıyla yapılan deneylerde yeniden tamponlama, şirketin o günkü algoritmasına göre %10 ile %20 azaldı; ortalama görüntü hızı ise aynı kaldı. Tek istisna açılış anı: tampon boşken bakılacak bir şey olmadığından orada hız tahmini hâlâ gerekiyor.

İkisini birlikte tartan. Birkaç parça sonrasını öngörüp en iyi planı seçen denetim kuramı yaklaşımları geliştirildi. 2016’da yayımlanan BOLA bunlardan biri; yalnızca tampona bakıyor ama seçimini kalite ile donma riskini tartan bir optimizasyonla yapıyor ve DASH’in açık kaynak başvuru oynatıcısına girdi. 2017’de ise karar mantığını pekiştirmeli öğrenmeyle kendisi öğrenen denemeler geldi.

Tampona bakan bir kuralın basit bir hâli, yukarıdaki merdivenle şöyle olabilir:

Alt bölge bir güvenlik deposu: orada tek amaç donmamak. Üst bölgede ise kaybedecek bir şey yok, en iyi görüntü isteniyor.

HLS, DASH ve ortak parça biçimi

Yukarıdaki listeler HLS biçiminde. Apple 2009’da başlattı ve 2017’de RFC 8216 olarak yayımlandı. DASH ise 2012’de ISO standardı oldu ve aynı bilgiyi XML biçimli bir tanım dosyasıyla veriyor. Uzun süre aynı video iki kez paketlenip iki kez saklandı: bir kez HLS için, bir kez DASH için. 2018’de standartlaşan CMAF parçaların biçimini ortaklaştırdı. Artık aynı parça dosyaları iki listeden de işaret edilebiliyor. Kenar sunucuları her parçayı bir kez önbelleğe alıyor.

Canlı yayın neden geriden gelir?

Golü ekranda görmeden önce komşunun sevinç çığlığını duyduysan sebebi bu bölümde. Canlı bir yayında görüntünün kameradan ekrana varması birkaç aşamadan geçiyor ve her biri bekletiyor:

1. Kodlama ve paketleme. Kodlayıcı bir parçayı tamamlamadan yayımlayamıyor; 6 saniyelik parçada ilk kare en az 6 saniye bekliyor.
2. Dağıtım. Parça kaynaktan kenar sunucularına yayılıyor.
3. Oynatıcı tamponu. HLS belirtimi, oynatıcıya canlı listenin sonundan en az üç hedef süre geriden başlamasını söylüyor. 6 saniyelik parçalarla bu tek başına 18 saniye.

Toplamda klasik bir canlı yayın ekrana onlarca saniye geç varabiliyor. Apple’ın 2019’da duyurduğu düşük gecikmeli HLS bu zinciri kısaltıyor. Parçalar birer saniyenin altındaki alt parçalar hâlinde yayımlanıyor ve oynatıcı listenin yeni sürümünü sunucuda bekleyerek alıyor, tekrar tekrar sormuyor. Apple halka açık ağlarda iki saniyenin altında gecikme hedefliyor. Aynı fikrin DASH tarafındaki karşılığı da CMAF parçalarını, tamamlanmalarını beklemeden küçük parçalar hâlinde göndermek.

Bir saniyenin altına ise bu mimari inemiyor; orada 74. bölümdeki gerçek zamanlı protokoller devreye giriyor.

Taşıma: TCP’den QUIC’e

Video trafiği taşımanın değişiminden en çok etkilenenlerden biri. Google 2017’de yayımladığı ölçümlerde YouTube’u 15. bölümdeki QUIC üstüne taşımanın etkisini gösterdi. Yeniden tamponlama oranı masaüstünde %18,0, mobilde %15,3 düştü. Kazancın bir kısmı bağlantı kurulumundan, bir kısmı kayıp kurtarmadaki iyileştirmelerden geliyor. Masaüstü bağlantıların yaklaşık %88’i sıfır turla kuruluyordu.

Parçaların nereden geldiği de en az taşıma kadar önemli. 16. bölümde gördüğün kenar sunucuları video için özel bir biçim de aldı. Netflix 2012’den beri kendi önbellek cihazlarını doğrudan internet servis sağlayıcılarının ağlarına yerleştiriyor. Popüler bir dizinin parçaları, izleyicinin bağlı olduğu operatörün içinden, birkaç sekme öteden geliyor.

Özet

• Sıkıştırma kareler arasındaki tekrardan gelir: I karesi kendi başına çözülür, P ve B kareleri başka karelere dayanır. Her parça, oynatıcının basamak değiştirebilmesi için bağımsız bir I karesiyle başlar.
• Merdiven içeriğe göre kurulur: aynı çözünürlük farklı bit hızlarında durabilir, sade bir görüntü yüksek çözünürlüğü daha az bitle taşır.
• Tampon ağın dalgasını emer: hat seçilen hızın altına düşerse tampon her parçada erir ve biterse görüntü donar. İzleyicinin en az affettiği şey donmadır.
• ABR kararı iki şeye bakar: ölçülen hıza ya da tamponun doluluğuna. Tampona bakan yaklaşım Netflix’te donmaları %10 ile %20 azalttı.
• Canlı yayının gecikmesi parçadan gelir: tamamlanmadan yayımlanamayan parçalar ve birkaç parçalık oynatıcı tamponu onlarca saniye tutar. Düşük gecikmeli HLS bunu iki saniyenin altına indirmeyi hedefliyor.

Canlı yayında bile birkaç saniyelik gecikmeye razı olabiliyorsun; golü geç görsen de maç aynı maç. Karşında konuşan biri varsa durum değişiyor. Sen sözünü bitirdiğinde cevabı yarım saniye gecikirse konuşma birbirinin üstüne biniyor. Gecikmenin yüz milisaniyeler içinde kalması gerekiyorsa ağ neden vazgeçiyor?