Canlı yayın gecikmesi (latency) nedir, nasıl düşürülür?

Gecikme nereden gelir?

Gecikme tek bir yerde oluşmaz, yayının geçtiği her aşama kendi payını ekler:

OBS'in WHIP rehberi de, yayını sunucuda yeniden kodlamak yerine kodlayıcıda birden çok kalite üretmenin (simulcast) dönüştürme ihtiyacını ortadan kaldırarak gecikmeyi azalttığını belirtir.

HLS'te gecikmenin matematiği

HLS'te yayın küçük dosyalara (segment) bölünür ve bir .m3u8 playlist'te listelenir. RFC 8216'ya göre EXT-X-TARGETDURATION etiketi azami segment süresini belirtir. Gecikmeyi asıl belirleyen kural ise oynatıcının başlangıç noktasıdır: RFC 8216, playlist'te bitiş etiketi olmayan (yani canlı) bir yayında istemcinin playlist sonuna üç hedef süreden daha yakın başlayan bir segmenti seçmemesi gerektiğini (SHOULD NOT) söyler. hls.js de buna uygun olarak liveSyncDurationCount değerini varsayılan 3 kullanır, yani oynatmaya son segmentin 3 segment gerisinden başlar.

Bu tablo yalnızca oynatıcının bilinçli olarak geride durmasından kaynaklanan payı gösterir; kodlama, yükleme ve segmentin tamamlanmasını bekleme süresi bunun üzerine eklenir. Apple'ın HLS yazım şartnamesi hedef sürenin 6 saniye olmasını (SHOULD), segmentlerin hedef süreyi 0,5 saniyeden fazla aşmamasını (MUST) ister. Daha kısa segment teknik olarak mümkündür ama oynatıcının daha sık playlist yenilemesi ve daha çok dosya indirmesi gerekir; RFC 8216'ya göre istemci playlist'i yeniden yüklemeden önce en az bir hedef süre beklemelidir.

Keyframe aralığı segment süresini sınırlar

Apple şartnamesine göre her video segmenti bir IDR (keyframe) ile başlamalıdır (MUST) ve keyframe'ler iki saniyede bir bulunmalıdır (SHOULD). YouTube da keyframe'leri 2 saniyede bir göndermenizi önerir. Pratik sonuç: segmentler ancak keyframe noktalarında kesilebildiği için keyframe aralığınız 4 saniyeyse 2 saniyelik segment elde edemezsiniz. OBS'te bu ayar çıkış ayarlarındaki Keyframe Interval (0=auto) alanıdır; 2 yazmanız çoğu senaryoda doğru başlangıçtır. Ayrıntılar için bitrate ve çözünürlük ayarları rehberimize bakın.

nginx-rtmp ile segment süresini ayarlama

Kendi sunucunuzda nginx-rtmp-module kullanıyorsanız Directives wikisine göre hls_fragment varsayılan olarak 5 saniye, hls_playlist_length 30 saniyedir. Örneğin 2 saniyelik segment için:

application live {
    live on;
    hls on;
    hls_path /tmp/hls;
    hls_fragment 2s;
    hls_playlist_length 12s;
}

Playlist dosyasını CDN veya tarayıcının uzun süre önbelleğe almaması gerekir; nginx-rtmp README'sindeki HLS örneği bu yüzden add_header Cache-Control no-cache; kullanır. CDN kullanıyorsanız playlist ve segmentler için farklı önbellek kuralları tanımlamak gerekir; bkz. CDN nedir.

LL-HLS: HLS'i bozmadan gecikmeyi düşürmek

Low-Latency HLS (LL-HLS), HLS'in güncel sürüm taslağında (draft-pantos-hls-rfc8216bis) tanımlanan ek özelliklerdir. hls.js README'si desteklediği LL-HLS özelliklerini şöyle sıralar: Partial Segments (kısmi segmentler), Blocking Playlist Reload (engelleyici playlist yenileme), Playlist Delta Updates ve Rendition Reports. Temel fikir, segment tamamlanmadan önce onun küçük parçalarını (part) yayımlamak ve oynatıcının yeni parçayı beklemeden haber almasını sağlamaktır.

• Apple şartnamesi önerilen Part Target Duration değerini 1 saniye olarak verir; bu değer istemcilerin yüzde 95'inin gördüğü gidiş-dönüş süresinin (P95 RTT) en az kendisi olmalı (MUST), tercihen en az üç katı olmalıdır (SHOULD).
• Apple'a göre PART-HOLD-BACK en az parça süresinin üç katı olmalıdır; 1 saniyelik parça için bu en az 3 saniye eder (3 x 1).
• Karşılaştırma için klasik HOLD-BACK değeri taslağa göre en az hedef sürenin üç katıdır; 6 saniyelik segmentte en az 18 saniye.
• hls.js'te lowLatencyMode varsayılan olarak açıktır; oynatıcı canlı yayına HOLD-BACK yerine PART-HOLD-BACK noktasından başlar.

LL-HLS'in çalışması için sunucunun ve (varsa) CDN'in bu özellikleri desteklemesi gerekir; yalnızca oynatıcıyı değiştirmek yetmez. Kavramsal ayrıntılar için HLS ve LL-HLS rehberi yazımıza bakabilirsiniz.

hls.js ile oynatıcı tamponunu ayarlamak

hls.js API belgesi canlı yayın gecikmesiyle ilgili birkaç ayar sunar. Bunları düşürmek gecikmeyi azaltır ama belge, örneğin liveSyncDurationCount'u düşürmenin takılmalara yol açabileceği konusunda açıkça uyarır.

var hls = new Hls({
  lowLatencyMode: true,           // varsayilan: true
  liveSyncDurationCount: 3,       // canli uctan kac hedef sure geride baslanacagi (varsayilan 3)
  liveMaxLatencyDurationCount: 10, // bu kadar geride kalirsa ileri atla (varsayilan: Infinity)
  maxLiveSyncPlaybackRate: 1.5    // 1'den buyukse geride kalinca hizli oynatarak yetisir (varsayilan 1)
});

Belgeye göre liveMaxLatencyDurationCount ayarlanırsa liveSyncDurationCount'tan kesinlikle büyük olmalıdır; maxLiveSyncPlaybackRate en fazla 2 olabilir.

WebRTC ve saniyenin altında gecikme

Saniyenin altında gecikme gerekiyorsa (görüntülü konuşma, canlı müzayede, uzaktan kontrol) segment tabanlı HLS yerine WebRTC kullanılır. Yayını WebRTC ile bir servise göndermenin standart yolu WHIP'tir: Mart 2025'te yayımlanan RFC 9725, WebRTC tabanlı içeriğin yayın servislerine ve CDN'lere HTTP tabanlı basit bir protokolle aktarılmasını tanımlar ve hedeflerinden birini "mümkün olan en düşük gecikme" olarak koyar. OBS Studio'da Settings > Stream altında Service olarak WHIP seçilip sağlayıcının sunucu adresi ve Bearer Token (WHIP'te yayın anahtarının karşılığı) girilir; OBS rehberi WHIP için etkileşimli kullanımda yalnızca 100 ms gecikmeden söz eder.

Kodlayıcıdan sunucuya giden "ilk mil" için SRT de bir seçenektir; OBS'in SRT rehberine göre en önemli ayar mikrosaniye cinsinden latency değeridir, varsayılanı 120 ms'dir ve en az kodlayıcı ile ingest sunucusu arasındaki gidiş-dönüş süresinin 2,5 katı olmalıdır. Protokollerin karşılaştırması için RTMP, SRT ve WebRTC farkı yazımıza bakın.

YouTube'da gecikme ayarı

YouTube'da yayın yapıyorsanız segment süresini siz belirlemezsiniz, ama Canlı Yayın Kontrol Odası'nda üç gecikme seçeneği sunulur:

Hangi gecikmeyi seçmeli?

Altın kural: gecikme ile istikrar arasında her zaman bir takas vardır. Tampon küçüldükçe ağdaki her dalgalanma doğrudan izleyiciye takılma olarak yansır. Bu yüzden önce kodlayıcı ve ağ tarafını sağlamlaştırın (bkz. canlı yayın donması ve kopması çözümleri), sonra gecikmeyi kademeli olarak düşürün.

Gecikmeyi ölçme

En basit ölçüm: kameranın görüş alanına saniyeli bir saat (örneğin bilgisayar ekranında açık bir kronometre) koyun, yayını başka bir cihazda açın ve iki saat arasındaki farkı okuyun. Aynı testi farklı ağlarda ve tarayıcılarda tekrarlayın; tek bir ölçüm yanıltıcı olabilir.

Sık Sorulan Sorular

Canlı yayın gecikmesi neden 20-30 saniye oluyor?

Klasik HLS'te oynatıcı canlı ucun üç segment gerisinden başlar. 6 saniyelik segmentlerde bu tek başına 18 saniye eder; kodlama ve yükleme süreleri eklendiğinde 20-30 saniye görmek olağandır.

Segment süresini 1 saniyeye düşürmek iyi bir fikir mi?

Gecikmeyi azaltır ama oynatıcı çok daha sık istek yapar ve küçük bir ağ dalgalanması takılmaya dönüşebilir. Keyframe aralığınızın da segment süresine uygun olması gerekir. Çok düşük gecikme istiyorsanız LL-HLS daha kontrollü bir yoldur.

LL-HLS her tarayıcıda çalışır mı?

Safari HLS'i kendisi oynatır; diğer tarayıcılarda hls.js gibi LL-HLS destekleyen bir oynatıcı gerekir. Asıl şart sunucu ve CDN tarafının LL-HLS üretmesi ve doğru iletmesidir.

YouTube'da Ultra-low latency seçersem ne kaybederim?

YouTube'a göre 4K desteklenmez, izleyici tarafında takılma artabilir ve sizin taraftaki ingest sorunları izleyiciyi daha çok etkiler.

Yazılım ve platform adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen şirketlerle ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: HLS nedir · RTMP, SRT, WebRTC farkı · Bitrate ve çözünürlük ayarları · Web sitesine canlı yayın ekleme · Canlı yayın donması çözümleri · CDN nedir