Video Streaming için bant genişliği planlaması: net hesap

Video streaming projelerinde en sık yaşanan sorun, bant genişliği planının eksik yapılmasıdır. Yetersiz plan; donma, artan gecikme ve bazı CDN/limit politikalarında kesintilerle sonuçlanır. Bu rehberde, izleyici başına veri tüketimini (bit rate), eş zamanlı kullanıcıyı ve beklenmeyen artışları dikkate alarak net bant genişliği hesabını adım adım göreceksiniz. Ayrıca CDN (Content Delivery Network) ve depolama/oynatma mimarisi bant ihtiyacını nasıl etkiler, bunu somut senaryolarla netleştireceğiz.

1) Bant genişliği hesap mantığı: bit rate → saniyelik trafik

Video streaming’de bant ihtiyacı; izlediğiniz video kalitesi, oynatma davranışı ve yeniden tamponlama (rebuffering) gibi unsurlarla değişir. En temel yaklaşım şudur:

• Video bit rate (bit/s) neyse, saniyede tüketilen veri yaklaşık olarak bit rate üzerinden hesaplanır.
• Pik saatlerde eş zamanlı izleyici sayısı artar.
• CDN kullanımı, aynı içeriğin tekrar tekrar origin sunucuya yüklenmesini azaltır; ancak toplam internet çıkışı (ISP tarafı) açısından izleyici tarafından tüketilen veri yine de vardır.

Bit rate’i Mbps ve GB/saat’e çevirme

Aşağıdaki dönüşüm pratikte işinizi görür:

• 1 Mbps = saniyede ~0.125 MB
• 1 Mbps = saatte ~0.125 × 3600 = 450 MB/saat
• Daha pratik: 1 Mbps ≈ 0.5 GB/saat (yuvarlamalı olarak)

Hesabı netleştirmek için daha kesin bir format kullanalım:

• 8 bit = 1 byte olduğundan Mbps → MB/s:
• MB/s = (Mbps × 10^6) / 8 / 10^6 = Mbps/8
• MB/s → GB/saat:
• GB/saat ≈ (Mbps/8) × 3600 / 1024

Ancak planlama için “yaklaşık ama güvenli” bir yöntem çoğu zaman yeterlidir. Bu rehberde, karar vermeyi kolaylaştırmak için bit rate değerlerini GB/saat olarak da göstereceğiz.

2) “İzleyici başına” bant tüketimi: kaliteye göre net tablo

Aşağıdaki tablo, belirli bir videoyu sürekli izleyen tek bir kullanıcı için saatlik veri tüketimini (ortalama) gösterir. Gerçek kullanımda oynatma süresi, start/seek, rebuffering ve farklı cihaz profilleri etkiler; yine de planlama için başlangıç noktası bu tablodur.

Not: Bu değerler “ortalama oynatma” varsayımı içindir. 4K için kullanılan codec/bit rate profilleri (H.264/H.265/AV1) ve adaptif streaming (ABR) yüzünden kullanıcı tam olarak hep aynı kaliteyle oynamaz.

Adaptif streaming (HLS/DASH) etkisi

HLS/DASH adaptif streaming, izleyicinin bağlantısına göre kaliteyi değiştirir. Bu yüzden tek bir bit rate’e bağlı kalmak yerine “ortalama bit rate” kullanın.

Net yöntem: - Sunucu tarafında oynatılan master manifest içinde kalite setlerinizi kontrol edin (ör. 1080p 6 Mbps, 1080p 8 Mbps, 720p 3 Mbps). - Deneyde, aynı saat aralığında kullanıcıların ne kadarının hangi kaliteye düştüğünü izleyin. - Ortalama bit rate’i bu dağılıma göre hesaplayın.

3) Eş zamanlı kullanıcı → saatlik toplam trafik → bant genişliği

Şimdi asıl planlama adımı: “Eş zamanlı izleyici sayısı” ve “ortalama bit rate” ile toplam çıkışı bulun.

Temel formül

• Toplam saatlik veri = Eş zamanlı kullanıcı × GB/saat (tek izleyici)
• İhtiyacınız olan ortalama bant genişliği (Mbps) yaklaşık olarak:
• Ortalama Mbps ≈ (Toplam veri GB/saat × 1024 × 8) / 3600

Pratikte daha kolay bir yaklaşım daha var: - Tek izleyici için bit rate Mbps neyse, eş zamanlı kullanıcıyla çarpılır. - CDN origin üzerinden yük azalır; ama izleyicinin ISP tarafında tüketim aynı kalır.

Senaryo 1: Orta ölçekli HD streaming

Varsayımlar: - Ortalama bit rate: 5 Mbps - Pik eş zamanlı izleyici: 1.000 - Ortalama oynatma: pik saat boyunca izleyicilerin tamamı aynı süreyi “yakın” paylaşır.

Hesap: - Pik çıkış (izleyiciye giden toplam): 5 Mbps × 1.000 = 5.000 Mbps = 5 Gbps - Saatlik veri (yaklaşık): 1 izleyici ~2.25 GB/saat → 1.000 izleyici ~2.250 GB/saat = 2.25 TB/saat

Bant kapasitesi planı: - Origin sunucuya sadece segmentlerin bir kısmı geliyorsa CDN sayesinde origin tarafı düşer. - Ancak CDN cache hit oranı düşerse (ör. yeni yayınlanan içerik), origin çıkışı yaklaşabilir.

Senaryo 2: Daha yüksek kalite ve 4K ağırlık

Varsayımlar: - Ortalama bit rate: 10 Mbps (4K her zaman değil, ABR karışımıyla ortalama) - Pik eş zamanlı izleyici: 500

Hesap: - Pik çıkış: 10 Mbps × 500 = 5.000 Mbps = 5 Gbps - Saatlik veri: tek izleyici ~4.5 GB/saat → 500 izleyici ~2.25 TB/saat

Gözlem: - 4K’a geçiş “bit rate’i katlamak” yerine ABR ile dengelenebilir; yine de pikte kapasite hesabı değişir.

Senaryo 3: “Gün içinde dalgalı” trafik

Streaming’de bant genişliği sabit değildir. Akışın dalgalı olduğu senaryolarda net plan için iki katman düşünün:

1) Ortalama bant: gün geneli tüketim 2) Pik bant: kısa süreli kapasite

Net yaklaşım: - En az 30 günlük istatistikte saatlik tepeyi bulun (promosyon günü/viral içerik dahil). - Pik değerle kapasite belirleyin. - Origin sunucu için CDN ile tepeyi düşürün, ancak ani içerik lansmanlarında cache ısınması (warm-up) gerektiğini kabul edin.

4) CDN, origin ve “gerçek” bant genişliği ayrımı

Bant genişliği planlarken iki farklı kavramı ayırın:

• İzleyici tarafındaki toplam trafik: İnternette tüketilen veri; genelde değişmez (oynatma bit rate’ine bağlı)
• Origin sunucu/billing noktası: Sunucunuzdan çıkan/hesaplanan veri (CDN, caching, segment tekrarları burada belirleyicidir)

CDN hangi durumda origin trafiğini düşürür?

Aşağıdaki durumlarda origin trafiği ciddi azalır: - Aynı içerik/segmentler sık tekrar izleniyorsa (yüksek cache hit) - Segment süreleri (ör. 2-6 saniye) ve GOP yapısı cache verimliliğini olumlu etkiliyorsa - Manifest ve segment URL’leri değişmiyorsa

Aşağıdaki durumlarda origin trafiği yükselir: - Yeni içerik lansmanı: cache ısınması henüz yoktur - Çok farklı cihaz ve bit rate kombinasyonları nedeniyle cache parçalanması oluşuyorsa - Tokenlı/özel URL politikasında her istek farklıysa cache hit düşer

Net karar: Origin için banttan ziyade “içerik sunumu tasarımı”

Origin sunucu/bant limitini aşmamak için yalnız “ne kadar GB çeker” hesabı yetmez. Net tasarım adımları:

• Segmentleri doğru boyutta üretin (çok kısa segment = daha fazla HTTP isteği, çok uzun segment = daha fazla yeniden indirme etkisi)
• Manifest URL’lerinin ve segment URL’lerinin cache dostu olmasına dikkat edin
• Cache TTL (time-to-live) ve revalidation politikalarını net tanımlayın
• Origin’de egress maliyetleri yüksekse CDN üzerinden çıkışı sabitleyin

5) Limitler, FUP ve kapasite tamponu: “yetmezse ne olur?”

Hosting ve bulut sağlayıcılarında bant genişliği bazen doğrudan “sınırsız” görünür; ancak FUP (Fair Usage Policy) veya gizli limitler uygulanır. Streaming planında hedef şu olmalıdır:

• Planladığınız pik bant genişliği × güvenlik çarpanı

Net güvenlik çarpanı önerisi: - Küçük ölçek (ilk 4-8 hafta): 1.3–1.5× - Trafik dalgalı ve belirsizse: 1.5–1.8× - CDN cache oturmuş ve düzenli izleniyorsa: 1.2–1.3×

Neden güvenlik çarpanı şart?

• Kullanıcılar sadece izlemekle kalmaz: seek/geri sarma yeniden segment istemini artırır.
• Adaptif streaming kalite geçişleri kısa süreli ek segment trafiği üretir.
• Ani kampanya/duyuru saatlerinde eş zamanlı izleyici tepe yapar.

6) Hesaplayıp seçimi netleştirme: kontrol listesi

Aşağıdaki listeyi kullanarak herhangi bir hosting/CDN kombinasyonu için bant planınızı sağlamlaştırın.

6.1. Doğru metrikleri toplayın

• Ortalama bit rate (ABR sonrası) — tek bir kalite varsaymayın
• Pik eş zamanlı izleyici (en az 30 gün)
• Ortalama izleme süresi (kullanıcılar “tam süre” izliyor mu?)
• Segment formatı: HLS/DASH, codec setleri

6.2. Origin için kapasiteyi “yönetilebilir” kılın

• CDN ile origin çıkışını düşürün
• Origin’de yeniden oynatma/segment üretim yükünü değil, önbellekten gelen tüketimi hedefleyin
• Origin için otomatik ölçekleme kullanıyorsanız, scale süresini test edin (dakika ölçeğinde gecikme bant kadar önemlidir)

6.3. İzleme (monitoring) kurun

Net uygulama: - Saatlik egress/transfer metriğini (ve mümkünse bölgesel dağılımı) izleyin - 4xx/5xx oranını izleyin (limit aşımı çoğu zaman hataya yansır) - Segment fetch latency ve rebuffer olaylarını AB test ile gözleyin

Sonuç: Net bir planla pikte kesintiyi önleyin

Video streaming’de bant genişliği planı; bit rate tablosu + eş zamanlı kullanıcı + pik güvenlik tamponu üçlüsüyle netleşir. Önce 3 kalite profili için (ör. SD/HD/4K karışım) ortalama bit rate’i belirleyin, ardından pik eş zamanlı izleyiciyle toplam Mbps/GB/saat hesabını çıkarın. Son adım olarak origin tarafını CDN ile cache hit üzerinden yönetip sağlayıcının FUP/limit mantığını göz önünde bulundurun. Eğer mevcut altyapınız yoksa, ilk lansman öncesi en az 1-2 haftalık testle ABR dağılımını doğrulayın ve kapasiteyi 1.3–1.5× tamponla güvene alın.