IPTV restream nedir?
Restream, bir yayının kaynak akışının alınıp başka bir sisteme, genellikle de bir dağıtım platformuna yeniden iletilmesidir. Bireysel IPTV hizmetinde son kullanıcı yayını bir oynatıcı uygulamasıyla izler. Restream'de ise karşı taraf bir izleyici değil, bir sistemdir: otel televizyon altyapısı, bir kablo veya IPTV operatörünün başlık sistemi (headend), bir OTT platformunun yayın sunucuları ya da bir bayi ağının merkezi altyapısı.
Kaynak yayın satışı da aynı ihtiyacın ticari adıdır. Alıcı, kendi platformunda yayınlamak üzere temiz, kararlı ve teknik olarak kendi sistemine uygun formatta bir akış talep eder. Bu akışın kalitesi, alıcının kendi müşterilerine sunacağı hizmetin kalitesini doğrudan belirler.
Kısaca: Restream, yayının izleyiciye değil, izleyiciye yayın dağıtan bir sisteme teslim edilmesidir.
Detaylı bilgi ve fiyat için WhatsApp üzerinden iletişime geçin.
Önce lisans: hizmetin temel şartı
Bu hizmet yalnızca alıcının yeniden dağıtım hakkına sahip olduğu içerikler için verilir. Bir yayını kendi platformunuzda sunabilmeniz için ilgili hak sahiplerinden alınmış, yeniden dağıtımı kapsayan bir lisansa veya yazılı izne sahip olmanız gerekir. Bu şart, sürecin en başında ve pazarlığa kapalı biçimde uygulanır.
- Talep aşamasında hangi içerikler için akış istendiği ayrıntılı olarak belirlenir.
- Bu içeriklere ilişkin yeniden dağıtım haklarını gösteren lisans belgeleri talep edilir.
- Belgeler incelenmeden test yayını veya teklif aşamasına geçilmez.
- Lisansın kapsamı (bölge, süre, platform türü) teknik yapılandırmaya da yansıtılır; örneğin lisans yalnızca belirli bir platform türünü kapsıyorsa akış buna göre planlanır.
- Lisans süresi sona erdiğinde veya kapsam değiştiğinde hizmet buna uygun olarak güncellenir.
Bu yaklaşım hem sizi hem de bizi korur. Yeniden dağıtım hakkı belgelenemeyen içerikler için restream talebi kabul edilmez.
Restream kimler için uygundur?
Restream, bireysel kullanıcılar için değil, yayını kendi müşterilerine veya misafirlerine dağıtan kurumlar için tasarlanmıştır. Tipik alıcı profilleri şunlardır:
- Kablo ve IPTV operatörleri: Kendi başlık sistemlerine ek kaynak akışı beslemek isteyen yerel veya bölgesel operatörler.
- Oteller ve konaklama tesisleri: Oda televizyonlarına Türkçe yayın sunmak isteyen, misafir profilinde Türkçe konuşan kesim bulunan oteller.
- OTT platformları: Kendi uygulaması üzerinden canlı yayın sunan ve kaynak akışa ihtiyaç duyan dijital platformlar.
- Bayi ağları: Belirli bir ölçeğe ulaşmış ve kendi altyapısını kurmak isteyen dağıtım ağları.
- Kurumsal yapılar: Hastaneler, yurtlar veya kamusal alanlar gibi kapalı devre yayın dağıtımı yapan kurumlar.
Ortak nokta şudur: bu kurumların hepsi yayını kendi markası, kendi altyapısı ve kendi müşteri ilişkisi üzerinden sunar. Bizim rolümüz, lisansı belgelenmiş içerikler için akışı teknik olarak kararlı, izlenebilir ve alıcı sistemle uyumlu biçimde teslim etmektir. Alıcının kendi izleyicisine karşı yükümlülükleri ise kendi sorumluluğundadır.
Son kullanıcıya hesap satmak istiyorsanız restream yerine bayilik modelini incelemenizi öneririz; teknik ve lisans gereksinimleri çok daha sadedir.
Detaylı bilgi ve fiyat için WhatsApp üzerinden iletişime geçin.
Teknik çerçeve: protokoller
Kaynak akışın hangi protokolle teslim edileceği, alıcı sistemin mimarisine bağlıdır. Her protokolün güçlü olduğu bir senaryo vardır:
| Protokol | Genel özellik | Tipik kullanım alanı |
|---|---|---|
| HLS | HTTP üzerinden parçalı (segment) teslim; geniş cihaz ve CDN uyumu | OTT platformları, web ve mobil oynatıcılar |
| RTMP | Uzun süredir kullanılan, yaygın desteklenen bir besleme protokolü | Yayın sunucusuna veya medya sunucusuna giriş (ingest) |
| SRT | Paket kaybına karşı dayanıklı, şifreleme destekleyen düşük gecikmeli taşıma | Değişken kaliteli internet hatları üzerinden noktadan noktaya teslim |
| MPEG-TS / UDP | Klasik yayıncılık dünyasının taşıma akışı; multicast ağlarla uyumlu | Operatör başlık sistemleri, otel ve kapalı devre ağlar |
Hangi protokolün seçileceği; alıcı sistemin desteklediği girişlere, ağ koşullarına, gecikme beklentisine ve güvenlik gereksinimlerine göre ihtiyaç analizinde birlikte belirlenir.
Transcoding profilleri ve bitrate merdiveni
Kaynak akış her zaman alıcının ihtiyacı olan formatta gelmez. Transcoding, akışın codec, çözünürlük, kare hızı veya bitrate açısından hedef sisteme uygun hâle getirilmesidir. Örneğin bir otel altyapısı yalnızca belirli bir codec'i destekliyorsa akış o codec'e dönüştürülür.
Bitrate merdiveni neden gerekir?
OTT platformlarında izleyiciler çok farklı hızlardaki bağlantılarla izler. Bu durumda tek bir kalite yerine birden fazla kalite basamağından oluşan bir bitrate merdiveni hazırlanır: örneğin bir 4K veya Full HD basamağı, bir HD basamağı ve düşük hızlar için daha hafif bir basamak. İzleyicinin oynatıcısı, o anki hızına göre uygun basamağı seçer. Merdivenin kaç basamaktan oluşacağı ve her basamağın değerleri, hedef kitlenin cihaz ve hat profiline göre planlanır.
Codec seçimi
H.264 en geniş uyumluluğu sunar; H.265 (HEVC) aynı görüntüyü daha verimli taşır ancak alıcı tarafta donanım desteği gerektirir. Ses tarafında da hedef cihazların desteklediği formatlar dikkate alınır. Profil seçimi, uyumluluk ile verimlilik arasındaki dengeye göre yapılır.
Yedeklilik ve izleme
Kurumsal yayında tek bir arıza noktası kabul edilemez. Bu nedenle restream mimarisinde yedeklilik baştan tasarlanır:
- Kaynak yedekliliği: Ana kaynakta sorun olduğunda yedek kaynağa geçiş planlanır.
- Sunucu yedekliliği: Akış birden fazla sunucu üzerinden sağlanabilir; bir sunucu devre dışı kalırsa diğeri devreye girer.
- Ağ yolu çeşitliliği: Mümkün olduğunda teslim farklı ağ yolları üzerinden yapılandırılır.
İzleme tarafında akışların durumu sürekli takip edilir: akışın kesilmesi, bitrate düşüşü, ses kaybı veya donmuş görüntü gibi belirtiler için uyarı mekanizmaları kurulur. Alıcı tarafla, bir sorun fark edildiğinde nasıl haberleşileceği de sürecin başında belirlenir. Belirli bir erişilebilirlik yüzdesi vaat etmek yerine, yedekli mimari ve şeffaf iletişimle riskleri en aza indirmeyi hedefleriz.
Detaylı bilgi ve fiyat için WhatsApp üzerinden iletişime geçin.
Güvenlik ve erişim kontrolü
Kaynak akışın yalnızca yetkili alıcıya ulaşması, hem lisans yükümlülüklerinin hem de ticari ilişkinin bir parçasıdır. Teslim yapılandırmasında şu yöntemler ihtiyaca göre birlikte kullanılabilir:
- IP kısıtlaması: Akış yalnızca alıcının bildirdiği sunucu adreslerinden çekilebilir.
- Kimlik doğrulama ve imzalı bağlantılar: HLS gibi HTTP tabanlı teslimlerde süreli ve imzalı adresler kullanılabilir.
- Taşıma şifrelemesi: SRT gibi protokollerde akış, parola tabanlı şifrelemeyle taşınabilir.
- Erişim kayıtları: Akışa yapılan bağlantılar kayıt altına alınır, olağandışı erişimler incelenir.
Bu önlemler, lisansın kapsadığı bölge ve platform sınırlarının teknik olarak da korunmasına yardımcı olur.
İki örnek senaryo
Senaryo A: Türkçe konuşan misafirleri olan bir otel
Otelin oda televizyonları kapalı devre bir ağ üzerinden yayın alıyor ve sistem MPEG-TS/UDP multicast girişini destekliyor. İhtiyaç analizinde hangi içerikler için lisans bulunduğu, kaç akış gerektiği ve otelin yayın sunucusunun hangi codec'i işleyebildiği netleştirilir. Lisans belgeleri doğrulandıktan sonra otelin teknik ekibiyle birlikte bir test akışı kurulur; görüntü ve ses birkaç farklı oda televizyonunda kontrol edilir. Test başarılı olduğunda teklif hazırlanır ve sistem canlıya alınır.
Senaryo B: Kendi uygulamasını yayınlayan bir OTT platformu
Platform, izleyicilerine web, mobil ve Smart TV uygulamaları üzerinden canlı yayın sunuyor. Burada akış genellikle SRT veya RTMP ile platformun giriş sunucusuna teslim edilir, platform kendi tarafında HLS paketleme ve CDN dağıtımını yapar. Alternatif olarak transcoding ve bitrate merdiveni bizim tarafta hazırlanıp HLS olarak teslim edilebilir. Hangi yolun seçileceği, platformun mevcut altyapısına ve operasyon tercihlerine bağlıdır.
Kapasite planlaması
Restream projesinde kapasite, yalnızca bugünkü ihtiyaca göre değil, büyüme senaryolarına göre de planlanır. Değerlendirilen başlıca konular şunlardır:
- Akış sayısı: Kaç ayrı kaynak akışına ihtiyaç duyulduğu.
- Profil sayısı: Her akış için kaç farklı transcoding profili gerektiği.
- Toplam bant genişliği: Akış ve profil sayısının birlikte oluşturduğu çıkış trafiği.
- Yoğun saat davranışı: Alıcının izleyici profiline göre trafiğin hangi saatlerde zirve yaptığı.
- Büyüme payı: Yeni içerik veya yeni bölgeler eklendiğinde sistemin nasıl ölçekleneceği.
Bu başlıklar netleşmeden verilen her teklif tahmine dayalı kalır. Bu nedenle fiyatlandırma, ihtiyaç analizi ve test yayını sonrasında yapılır. Altyapı mantığımızı genel hatlarıyla merak ediyorsanız sunucu altyapısı yazımıza göz atabilirsiniz.
Gecikme ve senkronizasyon beklentileri
Canlı yayında gecikme, kaynaktaki an ile izleyicinin ekranındaki an arasındaki farktır. Bu fark; kullanılan protokole, transcoding adımlarına, segment uzunluklarına ve alıcı taraftaki tampon ayarlarına göre değişir. HLS gibi segment tabanlı teslimler genellikle daha yüksek gecikmeyle çalışırken SRT veya UDP tabanlı teslimler daha düşük gecikme sağlayabilir. Ancak düşük gecikme, ağ dalgalanmalarına karşı daha az tolerans demektir. Bu nedenle sabit bir gecikme değeri vaat etmek yerine, alıcının önceliğine göre denge kurarız: canlı spor yayınları gibi zamanlamanın önemli olduğu kullanımlarda düşük gecikme, geniş kitleli OTT dağıtımında ise kararlılık öne çıkarılır.
Ses ve görüntü senkronizasyonu, altyazı ve çoklu ses kanalı gibi ayrıntılar da ihtiyaç analizinde ele alınır ve test yayınında doğrulanır.
Süreç: talepten canlı yayına
Restream projeleri adım adım ilerler. Her aşamanın bir amacı ve bir çıktısı vardır:
| Aşama | Ne yapılır? | Çıktı |
|---|---|---|
| 1. Talep | WhatsApp veya e-posta ile kurum, faaliyet alanı ve ihtiyaç kısaca iletilir. | İlk değerlendirme |
| 2. İhtiyaç analizi | Akış sayısı, protokol, codec, profil, teslim noktası ve izleme beklentileri belirlenir. | Teknik ihtiyaç özeti |
| 3. Lisans doğrulama | Talep edilen içerikler için yeniden dağıtım haklarını gösteren belgeler incelenir. | Onay veya ek belge talebi |
| 4. Test yayını | Belirlenen yapılandırmayla sınırlı süreli test akışı sağlanır, alıcı sistemde doğrulanır. | Teknik uyum onayı |
| 5. Teklif | Analiz ve test sonuçlarına göre kapsam ve fiyat yazılı olarak sunulur. | Yazılı teklif |
| 6. Canlıya alma | Akışlar üretim ortamına alınır, izleme ve iletişim süreçleri devreye girer. | Canlı hizmet |
Süreç boyunca tüm teknik ve ticari yazışmalar Türkçe yürütülür; gerektiğinde teknik ekiplerinizle doğrudan çalışırız.
Talep ederken hazırlamanız gerekenler
İlk görüşmenin verimli geçmesi için şu bilgileri önceden derlemenizi öneririz:
- Kurumunuzun adı, faaliyet alanı ve bulunduğu ülke
- Akış talep ettiğiniz içerikler ve bu içeriklere ait lisans belgeleri
- Alıcı sisteminizin desteklediği protokoller ve codec'ler
- Hedef çözünürlükler ve gerekiyorsa bitrate merdiveni beklentisi
- Teslim noktası: sunucu adresi, ağ bilgisi veya CDN girişi
- Tahmini başlangıç tarihi ve büyüme planı
Eksik bilgiler süreç içinde birlikte tamamlanabilir; ancak lisans belgeleri olmadan teknik aşamalara geçilmediğini hatırlatırız.
Sık yapılan yanlış anlamalar
"Restream, toplu hesap almakla aynı şeydir"
Değildir. Toplu hesap, son kullanıcıların oynatıcı uygulamalarıyla izlediği bireysel erişimdir. Restream ise kendi sisteminize beslenen kaynak akıştır ve yeniden dağıtım hakkı gerektirir.
"Teknik altyapı yeterliyse lisans ikinci plandadır"
Tam tersi geçerlidir. Lisans, sürecin ilk şartıdır; teknik çalışma ancak lisans doğrulandıktan sonra başlar.
"Fiyat önceden sabit bir listeden belirlenir"
Restream projeleri akış sayısına, profillere, teslim yöntemine ve yedeklilik ihtiyacına göre farklılaştığından sabit bir fiyat listesi yoktur. Teklif, analiz ve test yayınından sonra hazırlanır.
Restream kavramını daha geniş ele aldığımız IPTV restream nedir yazısını da okuyabilirsiniz. Bireysel kullanım için paketler, iletişim kanallarımız için iletişim sayfasına bakabilirsiniz.
Detaylı bilgi ve fiyat için WhatsApp üzerinden iletişime geçin.