Canlı yayın kurarken karşınıza çıkan RTMP, SRT, WebRTC, WHIP, WHEP ve HLS gibi kısaltmalar ilk bakışta kafa karıştırır. Aslında hepsi aynı soruya farklı cevaplar verir: görüntü bir noktadan diğerine nasıl, ne kadar gecikmeyle ve ne kadar güvenilir şekilde taşınacak?
Bu yazıda her protokolün ne olduğunu, hangi gecikme sınıfında yer aldığını, kayıplı ağlarda nasıl davrandığını ve en önemlisi yayının hangi aşamasında (kodlayıcıdan sunucuya "ingest" mi, sunucudan izleyiciye "delivery" mi) kullanıldığını anlatıyoruz. OBS, YouTube ve Facebook tarafındaki desteği de bu platformların kendi belgelerine dayanarak özetliyoruz.
Önce iki kavram: ingest ve delivery
- Ingest (alım): Yayının kodlayıcıdan (OBS, vMix, donanım encoder) yayın sunucusuna veya platforma gönderilmesi. Tek bir bağlantıdır, kalite ve kararlılık önemlidir.
- Delivery (dağıtım): Sunucudan binlerce izleyiciye dağıtım. Ölçeklenebilirlik, CDN uyumu ve tarayıcı desteği önemlidir.
Bir protokolün ingest için harika olması, dağıtım için de uygun olduğu anlamına gelmez. Örneğin RTMP bugün neredeyse yalnızca ingest için kullanılır; izleyiciye ise çoğunlukla HLS ulaştırılır.
RTMP ve RTMPS
RTMP (Real-Time Messaging Protocol), Adobe tarafından Flash döneminde geliştirilmiş, TCP üzerinde çalışan bir protokoldür. Flash oynatıcılar ortadan kalktığı için izleyici tarafında artık kullanılmıyor; ama neredeyse her kodlayıcı ve platform tarafından desteklendiği için yayın göndermenin hâlâ en yaygın yoludur.
- RTMPS, RTMP'nin TLS ile şifrelenmiş hâlidir. YouTube geliştirici belgesine göre RTMPS bağlantısı 443 numaralı porta ve
rtmps://şemasıyla yapılır. - YouTube'un protokol karşılaştırma sayfası RTMP ve RTMPS'yi normal, düşük ve çok düşük gecikmeli yayınlar için uygun olarak gösteriyor.
- Klasik RTMP'nin codec desteği sınırlıydı. Veovera tarafından yayımlanan Enhanced RTMP (E-RTMP) belirtimi HEVC, VP9, AV1 gibi video codec'leri ve Opus, FLAC gibi ses codec'lerini, ayrıca çoklu iz (multitrack) desteğini ekliyor.
TCP kullandığı için RTMP'de kaybolan paketler yeniden gönderilir; görüntü bozulmaz ama bağlantı zayıfladığında yayın birikir, gecikir ve sonunda kopabilir. Bu yüzden RTMP kararlı, kablolu bağlantılarda en iyi sonucu verir.
SRT
SRT (Secure Reliable Transport), Haivision tarafından geliştirilen ve açık kaynak olarak yayımlanan bir aktarım protokolüdür (MPL-2.0 lisansı). Proje sayfası SRT'yi "çok düşük (saniye altı) gecikmeli canlı video ve ses aktarımı için bir aktarım protokolü" olarak tanımlıyor. UDP hızını kullanır ve kaybolan paketleri esas olarak ARQ (Automatic Repeat reQuest, otomatik yeniden gönderim isteği) ile kurtarır; FEC de desteklenir. İçerik 128/192/256 bit AES ile şifrelenebilir.
SRT'nin asıl gücü internet gibi kayıplı ve değişken ağlarda kendini göstermesidir: bir "latency" (gecikme tamponu) değeri belirlersiniz, protokol bu süre içinde kayıp paketleri yeniden ister. Tampon büyüdükçe dayanıklılık artar, gecikme de artar.
OBS'te SRT
OBS'in SRT Protocol Streaming Guide belgesine göre SRT ile yayın için Settings > Stream bölümünde Service olarak Custom seçilir, Server alanına SRT adresi yazılır ve Stream Key boş bırakılır. Adres biçimi srt://IP:port şeklindedir; sonuna FFmpeg'in desteklediği seçenekler eklenebilir. Kapsayıcı MPEG-TS'dir.
srt://yayin.ornek.com:9000?mode=caller&latency=1000000- latency mikrosaniye cinsindendir; varsayılan 120 ms (120000) değeridir. Belgeye göre bu değer, kodlayıcı ile sunucu arasındaki gidiş-dönüş süresinin (RTT) en az 2,5 katı olmalıdır. Yukarıdaki örnekteki 1000000 değeri 1 saniyeye karşılık gelir.
- mode:
caller(varsayılan) karşı tarafa bağlanır,listenergelen bağlantıyı bekler,rendezvousiki yönlü çalışır. - Port numarası ve ek parametreler (ör. stream id, şifre) sunucunuza göre değişir; sağlayıcınızın verdiği adresi kullanın.
WebRTC, WHIP ve WHEP
WebRTC, tarayıcıların eklentisiz gerçek zamanlı ses ve görüntü iletişimi kurması için geliştirilmiş teknolojiler bütünüdür; görüntülü görüşmelerin çoğu bunun üzerinde çalışır. Asıl gücü çok düşük gecikmedir; OBS'in WHIP rehberi WebRTC için yaklaşık 100 ms gecikmeden söz ediyor ve bunun izleyiciyle etkileşime uygun olduğunu belirtiyor.
WebRTC'nin yayın dünyasındaki eksiği, bağlantının nasıl kurulacağını (sinyalleşme) standart olarak tanımlamamasıydı. Bu boşluğu iki protokol dolduruyor:
| Protokol | Yön | Durum (Ekim 2026) | Nasıl çalışır |
|---|---|---|---|
| WHIP (WebRTC-HTTP Ingestion Protocol) | Ingest: kodlayıcıdan sunucuya | RFC 9725, Mart 2025, Proposed Standard | İstemci SDP teklifini HTTP POST ile gönderir; sunucu 201 Created, SDP cevabı ve oturum adresini (Location) döner. Oturum HTTP DELETE ile kapatılır. Bearer token ile kimlik doğrulama tanımlıdır. |
| WHEP (WebRTC-HTTP Egress Protocol) | Delivery: sunucudan izleyiciye | IETF taslağı (draft-ietf-wish-whep-05), henüz RFC değil | WHIP'in izleme tarafındaki karşılığı; oynatıcı SDP teklifini HTTP POST ile gönderir, oturumu DELETE ile kapatır. |
OBS'te WHIP
WHIP/WebRTC çıkışı OBS 30.0 sürümüyle eklendi. OBS'in WHIP Streaming Guide belgesine göre ayar şöyle yapılır: Settings > Stream bölümünde Service olarak WHIP seçilir, sağlayıcının verdiği adres Server alanına, sağlayıcının verdiği Bearer Token (WHIP'teki stream key karşılığı) aynı adlı alana yazılır.
- Belge, WHIP'in Ubuntu 24.04 PPA sürümünde desteklenmediğini ve Flatpak sürümünün kullanılabileceğini belirtiyor.
- Simulcast (1 ila 4 kalite katmanı göndermek) için OBS 32.1.0 veya üstü gerekiyor; örneğin 3 katmanda katmanlar ana ayarın %100, %66 ve %33'ü olarak gönderiliyor.
- Belgede WHIP kabul eden servislere örnek olarak Cloudflare, Twitch, Red5, Dolby OptiView, Tencent, Broadcast Box ve Stage TEN sayılıyor. Servisin WHIP desteğinin kapsamını kendi belgesinden doğrulayın.
HLS nerede duruyor?
HLS bir ingest protokolü olarak da kullanılabilse de asıl görevi dağıtımdır: sıradan HTTP dosyalarıyla çalıştığı için CDN'lerle kolay ölçeklenir ve Safari'de yerel, diğer tarayıcılarda hls.js ile oynatılır. Bedeli, segment yapısından kaynaklanan daha yüksek gecikmedir. LL-HLS bu gecikmeyi azaltır. Ayrıntılar için HLS nedir yazımıza bakın.
Karşılaştırma tablosu
| RTMP / RTMPS | SRT | WebRTC (WHIP/WHEP) | HLS / LL-HLS | |
|---|---|---|---|---|
| Taşıma | TCP (RTMPS: TCP + TLS) | UDP + ARQ | UDP tabanlı (ICE/DTLS) | HTTP |
| Gecikme sınıfı | Düşük; ağ zayıflarsa artar | Ayarlanabilir; latency tamponuna bağlı | En düşük (OBS belgesi: yaklaşık 100 ms) | Klasik HLS yüksek; LL-HLS daha düşük |
| Kayıplı ağda | Bekler, birikir, kopabilir | Tampon süresince kayıpları kurtarır | Gerçek zamanlılık için tasarlanmış | Oynatıcı tamponla telafi eder |
| Şifreleme | RTMPS ile | AES 128/192/256 | Var (DTLS) | HTTPS ve isteğe bağlı segment şifreleme |
| Tipik kullanım | Ingest | Ingest, sunucular arası, uzak yayın | WHIP ile ingest, WHEP ile etkileşimli izleme | Dağıtım |
| OBS | Var (Custom ve hazır servisler) | Var (Custom, srt:// adresi) | Var (Service: WHIP, OBS 30.0+) | Dağıtım protokolü; sunucu üretir |
YouTube ve Facebook hangi protokolleri kabul ediyor?
| Platform | Belgede geçen ingest protokolleri | Not |
|---|---|---|
| YouTube | RTMP, RTMPS, HLS, DASH | YouTube'un ingest protokol karşılaştırma sayfası (son güncelleme 15 Ekim 2026) bu dördünü listeliyor. RTMPS öneriliyor. HLS ve DASH, segment tabanlı oldukları için genellikle RTMP'den daha yüksek gecikme getiriyor ve çok düşük gecikmeye uygun değil. |
| Facebook (Meta) | RTMPS | Meta Live Video API referansı protokol olarak RTMPS yayınını belirtiyor; en iyi uygulamalar sayfası şifreleme için RTMPS adresini kullanmayı öneriyor. |
Bu iki platformun incelediğimiz resmî belgelerinde SRT veya WHIP ile ingest geçmiyor. Bir platforma SRT ya da WebRTC ile yayın göndermek istiyorsanız önce o platformun güncel belgesine bakın. Kendi sunucunuza SRT ile gönderip oradan platformlara RTMPS ile aktarmak (restream) da bir seçenektir; bkz. restream nedir.
Hangisini seçmeliyim?
- Stüdyodan, kablolu bağlantıyla web TV'nize veya YouTube'a yayın: RTMP veya mümkünse RTMPS. En yaygın ve en sorunsuz seçenek.
- Saha yayını, mobil bağlantı, uzak şehirden aktarım: Sunucunuz destekliyorsa SRT. Latency değerini bağlantının RTT'sine göre ayarlayın.
- İzleyiciyle anlık etkileşim (canlı açık artırma, soru-cevap, uzaktan konuk): WebRTC (WHIP/WHEP). Ölçek ve maliyet planlamasını sağlayıcınızla konuşun.
- Geniş kitleye, her cihaza dağıtım: HLS. Daha düşük gecikme gerekiyorsa LL-HLS.
Gecikmenin uçtan uca nereden kaynaklandığını ve nasıl düşürüleceğini canlı yayın gecikmesi yazımızda ayrıntılı ele aldık.
Sık Sorulan Sorular
RTMP eskidi mi, artık kullanılmamalı mı?
İzleyici tarafında (Flash ile oynatma) eskidi; ancak ingest için hâlâ en yaygın protokoldür. YouTube ve Meta belgeleri RTMP/RTMPS ile yayın almayı anlatmaya devam ediyor; Enhanced RTMP ile yeni codec'ler de ekleniyor.
SRT, RTMP'den her zaman daha mı iyidir?
Hayır. Kararlı bir kablolu bağlantıda RTMP yeterlidir ve her yerde desteklenir. SRT'nin farkı kayıplı ve değişken ağlarda ortaya çıkar. Ayrıca hedef sunucunun SRT kabul etmesi gerekir.
WHIP ile WHEP arasındaki fark nedir?
WHIP yayını sunucuya göndermek (ingest), WHEP ise sunucudan izlemek (egress) içindir. WHIP Mart 2025'te RFC 9725 olarak yayımlandı; WHEP Ekim 2026 itibarıyla hâlâ IETF taslağıdır.
RTMP hangi portu kullanır?
Sağlayıcınızın verdiği adreste port yazıyorsa onu kullanın; örneğin rtmp://sunucu:1935/uygulama biçiminde. YouTube'un RTMPS bağlantısı 443 portunu kullanır. Port ve güvenlik duvarı ayarları için port numaraları rehberi ve UFW rehberi yazılarımıza bakabilirsiniz.
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 · OBS ile canlı yayın · Canlı yayın gecikmesi · Restream nedir · İnternet ve ağ temelleri