Forem: Yayin

Canlı TV Platformu Geliştirirken Öğrendiğim Teknik Dersler: Streaming, Flussonic ve Performans

Yayin — Sat, 23 May 2026 18:24:54 +0000

Canlı yayın projelerinde zamanla fark ettiğim şey şu oldu:

Video oynatıcı eklemek işin en kolay kısmı.

Asıl zorluk, akışı güvenilir şekilde ölçekleyebilmek.

Bu yazıda canlı TV ve streaming altyapıları geliştirirken karşılaştığım teknik dersleri paylaşacağım.

*1. Video Oynatıcı Aslında Sistemin Küçük Bir Parçası
*
Başlangıçta sistem oldukça basitti:
<video controls autoplay> <source src="stream.m3u8"> </video>
İlk testlerde çalışıyordu.

Fakat gerçek kullanıcı trafiğinde sorunlar ortaya çıktı:

kullanıcılar farklı internet hızlarına sahipti
mobil cihazlar değişiyordu
tarayıcı davranışları farklıydı
yayın kalitesi değişiyordu

Bu noktada yalnızca video etiketi yeterli olmamaya başladı.

Canlı yayın sistemleri düşündüğümden daha fazla katmana sahipti.

*2. HLS Yayınları Beklediğimden Daha Karmaşık Çıktı
*
Başta tek video dosyası mantığıyla düşünüyordum.

Ancak canlı yayın dünyasında yapı farklı.

Bir HLS akışı tipik olarak şöyle görünüyordu:
`master.m3u8

720p.m3u8
480p.m3u8
360p.m3u8

segment001.ts
segment002.ts
segment003.ts`

Bu yapı ilk başta gereksiz görünmüştü.

Sonradan fark ettim:

Kullanıcının bağlantısı değiştikçe kalite de değişiyor.

Bu sayede:

düşük internet hızında takılmalar azalıyor
mobil kullanıcılar daha stabil izliyor
veri kullanımı optimize oluyor

Adaptive bitrate sistemi canlı yayın tarafında ciddi fark oluşturuyor.

*3. Flussonic Kullanırken Asıl Sorun Kurulum Değil Trafik Yönetimi Oldu
*
İlk testlerde Flussonic kurulumu beklediğimden kolaydı.

Temel bir yayın tanımı:

`stream canal1 {

input udp://239.1.1.1:1234;

}veyastream canal1 {

input http://example.com/live.m3u8;

}`
Yayın birkaç dakika içinde çalışmaya başladı.

Ancak kullanıcı sayısı yükseldikçe yeni sorunlar çıktı:

aynı anda binlerce bağlantı
yüksek RAM kullanımı
yoğun CPU tüketimi
çıkış trafiği maliyetleri

Asıl zorluk Flussonic kurmak değil, yayın dağıtım mimarisi oldu.

*4. Tek Sunucu Mantığı Hızlıca Sınıra Ulaşıyor
*
İlk sistem:
`Kullanıcı

↓

Web Sunucu

↓

Streaming Sunucu`
Başlangıç için yeterliydi.

Fakat eş zamanlı kullanıcı sayısı arttıkça darboğaz oluşmaya başladı.

Daha sonra yapı ayrıldı:
`Load Balancer

↓

Web Sunucuları

↓

Streaming Node

↓

CDN`

Bu yaklaşım:

yük dağılımını iyileştirdi
kesinti riskini azalttı
ölçeklenebilirliği artırdı

Canlı yayın projelerinde mimari düşündüğümden daha önemli çıktı.

En Büyük Sorun CPU Değil Transcoding Olabiliyor

Başlangıçta sunucu yükünün web tarafında oluşacağını düşünüyordum.

Gerçekte en büyük yük:

video dönüştürme işlemleri oldu.

Örnek:
ffmpeg -i source.ts \ -c:v libx264 \ -b:v 3000k \ -hls_time 4 \ output.m3u8
Birden fazla kalite üretmeye başladığınızda:

1080p
720p
480p
360p

CPU kullanımı hızla yükselmeye başlayabiliyor.

Özellikle eş zamanlı kanal sayısı arttığında video işleme tarafı ciddi kaynak tüketebiliyor.

Oynatıcı Seçimi Beklediğimden Daha Kritik Çıktı

İlk denemelerde standart video oynatıcı kullanıyordum.

Daha sonra HLS tarafında farklı çözümler denedim:

hls.js
Video.js
Shaka Player

Örnek
`

const video =
document.getElementById("player");

const hls=new Hls();

hls.loadSource(
"stream.m3u8"
);

hls.attachMedia(video);

Bazı cihazlar yerel HLS desteği sunarken bazıları JavaScript tarafında işlenmesini gerektiriyordu.

Tarayıcı farklılıkları düşündüğümden daha büyük etki oluşturdu.

*7. Fazla Özellik Her Zaman Daha İyi Sonuç Vermiyor
*
Başlangıçta şunları eklemeyi düşünüyordum:

otomatik kalite değiştirme panelleri
canlı sayaçlar
animasyonlu kanal geçişleri
gerçek zamanlı istatistikler

Ancak kullanıcı davranışları farklıydı.

Çoğu kullanıcı yalnızca:

hızlı açılan yayın
düşük gecikme
kesintisiz izleme

istiyordu.

Bazen daha sade sistem daha iyi sonuç verebiliyor.

Sonuç

Canlı TV platformları ilk bakışta basit görünse de ölçek büyüdüğünde iş tamamen değişiyor.

Gerçek zorluk:

video dağıtımı
gecikme yönetimi
ağ maliyetleri
transcoding
ölçeklenebilirlik
streaming mimarisi

tarafında ortaya çıkıyor.

Bir video oynatıcısı eklemek birkaç dakika sürebiliyor.

Kesintisiz çalışan canlı yayın sistemi kurmak ise bambaşka bir konu.

Kullanılan Kaynaklar:

• Flussonic Documentation: https://flussonic.com/doc
• FFmpeg Documentation: https://ffmpeg.org/documentation.html
• HLS Specification: https://datatracker.ietf.org/doc/html/rfc8216
• Örnek: Canlı TV
• Video.js Documentation: https://videojs.com

Trafik Cezaları Platformları Geliştirirken Öğrendiğim Teknik Dersler

Yayin — Sat, 23 May 2026 18:14:56 +0000

İlk bakışta trafik denetimleri ve trafik kameraları üzerine bir platform geliştirmek oldukça basit görünüyor:

Kamera noktaları
Denetim bilgileri
Konum verileri
Yol bilgileri
Kullanıcıya hızlı erişim

Ancak işin teknik tarafına girildiğinde veri hacmi ve sürekli değişen bilgiler düşündüğümden daha karmaşık hale geldi.

Özellikle konum bazlı sistemler, performans optimizasyonları ve mobil kullanıcı davranışları birleşince küçük görünen proje farklı bir boyuta taşındı.

Bu yazıda trafik denetimleri, kamera noktaları ve canlı veri odaklı projelerde karşılaştığım teknik konuları paylaşacağım.

*1. Konum Verileri Beklediğimden Daha Dinamikti
*
Başlangıçta verileri basit bir liste olarak düşünmüştüm:

[
 {
   "city":"İstanbul",
   "location":"E-5",
   "camera":"Aktif"
 }
]

Ancak zamanla veriler büyüdü:

yeni denetim noktaları
değişen lokasyonlar
geçici kontroller
farklı kamera türleri
yol bazlı güncellemeler

Statik veri modeli kısa sürede yetersiz kalmaya başladı.

Daha sonra verileri yapılandırılmış alanlara ayırdım:

{
"id":124,
"city":"İstanbul",
"lat":41.0082,
"lng":28.9784,
"type":"mobese",
"status":"active"
}

Bu yapı filtreleme ve performans tarafında ciddi avantaj sağladı.

*2. Haritalar Sayfa Performansını Beklenenden Fazla Etkiliyor
*
İlk sürümde bütün kamera noktalarını aynı anda yüklemeyi denedim.

Mantık basitti:

locations.forEach(location=>{

new Marker(location);

});

Başlangıçta çalışıyordu.

Fakat veri arttıkça:

yüksek bellek kullanımı
uzun ilk yükleme süresi
mobil cihazlarda takılmalar
harita gecikmeleri

ortaya çıkmaya başladı.

Sonrasında yalnızca görünür alandaki verileri yüklemeye başladım:

const visibleLocations =
allLocations.filter(item=>{

return mapBounds.contains(item);

});

Kullanıcının görmediği verileri işlememek ciddi performans kazancı sağladı.

*3. Mobil Kullanıcılar Beklediğimden Daha Baskındı
*
Trafik içerikleri çoğunlukla hareket halindeki kullanıcılar tarafından ziyaret ediliyor.

Bu yüzden masaüstü düşünerek geliştirilen birçok çözüm mobilde bekleneni vermedi.

Örneğin:

ağır haritalar
yüksek boyutlu görseller
büyük JavaScript paketleri
gereksiz animasyonlar

ilk yükleme süresini artırdı.

Basit optimizasyon:

<img
loading="lazy"
src="kamera.jpg"
alt="trafik kamera noktası">

Küçük görünmesine rağmen toplam yükü ciddi şekilde azaltabildi.

*4. Çok Fazla DOM Öğesi Gizli Bir Sorun Oluşturabiliyor
*
Bir şehirde yüzlerce kamera veya kontrol noktası olabiliyor.

İlk yaklaşım:

<div class="camera">
Kamera Noktası
</div>

<div class="camera">
Kamera Noktası
</div>

<div class="camera">
Kamera Noktası
</div>

Veri arttıkça DOM büyümeye başladı.

Sonrasında yalnızca gerekli öğeleri oluşturdum:

const visibleItems=
items.slice(start,end);

Bu yaklaşım özellikle mobil cihazlarda daha akıcı bir deneyim sağladı.

*5. SEO Tarafında Konum Verileri Ayrı Yaklaşım Gerektiriyor
*
Konum tabanlı projelerde kullanıcı niyeti çok değişiyor.

Örnek:

"Trafik kamerası"

"Yakınımdaki trafik denetimi"

aynı arama davranışı değil.

Bu yüzden:

anlamlı URL yapıları
şehir bazlı içerik yapısı
yapılandırılmış veri kullanımı
hızlı yükleme süreleri

önemli hale geldi.

Örnek:

<script type="application/ld+json">
{
"@context":"https://schema.org",
"@type":"Place",
"name":"Trafik Denetim Noktası"
}
</script>

Yapısal veri küçük görünse de arama motorlarına içerik hakkında daha net sinyal gönderebiliyor.

*6. Bazen Daha Az Özellik Daha İyi Sonuç Veriyor
*
Başta daha fazla özellik eklemenin kullanıcı deneyimini artıracağını düşünmüştüm:

canlı sayaçlar
animasyonlar
karmaşık filtreler
detaylı paneller

Fakat çoğu kullanıcı yalnızca hızlı bilgi istiyordu.

Sonrasında sade yapı daha iyi sonuç verdi:

daha az JavaScript
daha az DOM
daha düşük ağ yükü
daha hızlı açılış

özellikle mobil tarafta fark oluşturdu.

Sonuç

Trafik denetimi ve kamera odaklı projeler ilk bakışta veri listesi gibi görünse de ölçek büyüdüğünde farklı sorunlar ortaya çıkabiliyor:

performans
harita yönetimi
konum verileri
mobil optimizasyon
SEO

Küçük görünen sistemler bazen düşündüğümden daha fazla optimizasyon gerektirebiliyor.

*Kullanılan Kaynaklar:
*
• OpenStreetMap Documentation: https://wiki.openstreetmap.org/wiki/Main_Page
• Leaflet Documentation: https://leafletjs.com/reference.html
• Örnek Çalışma: Trafik Cezaları
• Schema.org — Place: https://schema.org/Place

TV Yayın Akışı Sitesi Geliştirirken Öğrendiğim Teknik Dersler

Yayin — Fri, 22 May 2026 14:54:33 +0000

Televizyon yayın akışı sitesi geliştirmeye başladığımda bunun basit bir içerik projesi olacağını düşünmüştüm. İlk bakışta mantık oldukça düz görünüyordu:

Kanal listesi
Yayın saatleri
Program başlıkları
Kullanıcıya hızlı erişim

Fakat iş geliştirme tarafına geçince durum farklılaştı.

Özellikle mobil trafik, performans, SEO ve sürekli güncellenen veriler bir araya gelince küçük görünen bir proje zamanla ciddi optimizasyon gerektiren bir sisteme dönüştü.

Bu yazıda TV yayın akışı projesi geliştirirken karşılaştığım teknik sorunları ve uyguladığım çözümleri paylaşacağım.

Sürekli Değişen Veri Yapısı Beklediğimden Zor Çıktı

Yayın akışları statik içerik değil.

Her gün:

yeni programlar ekleniyor
saatler değişiyor
özel yayınlar geliyor
içerikler güncelleniyor

Başta verileri doğrudan HTML içine yazmayı denedim. Fakat kısa sürede yönetilemez hale geldi.

İlk yaklaşım:

<div class="program">
   <span>20:00</span>
   <span>Ana Haber</span>
</div>

<div class="program">
   <span>22:00</span>
   <span>Film Kuşağı</span>
</div>

Bu yöntem küçük ölçek için çalışıyor ancak kanal sayısı arttığında bakım zorlaşıyor.

Daha sürdürülebilir yapı JSON tabanlı veri modeli oldu:

[ { "time":"20:00", "title":"Ana Haber" }, { "time":"22:00", "title":"Film Kuşağı" } ]

Frontend tarafında:

schedule.forEach(item=>{

container.innerHTML += `
<div class="program">

<span>${item.time}</span>

<span>${item.title}</span>

</div>
`

});

Arayüzü veriden ayırmak bakım sürecini ciddi şekilde kolaylaştırdı.

Mobilde Yatay Kaydırma Beklediğimden Fazla Maliyet Oluşturdu

TV projelerinde genelde çok sayıda kanal logosu bulunuyor.

İlk çözüm klasik yatay kaydırma alanıydı:

.channels{
overflow-x:auto;
white-space:nowrap;
}

Başlangıçta çalışıyordu fakat kanal sayısı büyüdükçe mobil cihazlarda bazı sorunlar ortaya çıktı:

fazla DOM yükü
kaydırma takılmaları
düşük FPS
gereksiz render işlemleri

Sonrasında görünmeyen öğeleri yüklememeye başladım.

Örnek:

const visibleItems = channels.slice(start,end);
Basit görünse de özellikle düşük donanımlı cihazlarda fark hissedildi.

Lazy Loading Olmadan Sayfa Ağırlığı Hızla Artıyor

Kanal sitelerinde logo sayısı çok yüksek olabiliyor.

İlk sürüm:

<img src="kanal-logo.png">
Yüzlerce logo yüklenmeye başladığında ağ yükü hızla arttı.

Daha sonra:

<img loading="lazy" src="kanal-logo.png" alt="kanal logosu">

Tarayıcının yerleşik lazy loading desteği ciddi fayda sağladı.

Ekstra JavaScript kullanmadan ilk yükleme süresi azaldı.

Tekrarlanan HTML Yerine Bileşen Mantığı Daha Temiz Oldu

İlk sürümlerde her kanal kartı manuel yazılıyordu:

<div class="channel">
<img src="kanald-logo.png">
<h3>Kanal D</h3>
</div>

Bir süre sonra yüzlerce tekrar oluştu.

Daha sonra yapı fonksiyonlaştırıldı:

function channelCard(channel) {
  return `
    <div class="channel">
      <img src="kanald-logo.png">
      <h3>Kanal D</h3>
    </div>
  `;
}

Bu yaklaşım:

kod tekrarını azalttı
bakım sürecini kolaylaştırdı
ölçeklenebilirliği artırdı

Ayrıca Dev.to editöründe bazı template literal örneklerinin sorun çıkarabildiğini fark ettim. Bu yüzden örnek kodlarda sade yapı kullanmak daha güvenli olabiliyor.

SEO Tarafında En Büyük Sorun Dinamik İçerik Oldu

Yayın akışı siteleri her gün değişiyor.

Burada temel soru şuydu:

Arama motorları sürekli güncellenen içeriği ne kadar sağlıklı algılıyor?

Bazı çözümler:

anlamlı URL yapıları
yapılandırılmış veriler
sitemap güncellemeleri
hızlı sayfa yüklenmesi
gereksiz JavaScript azaltılması

Örnek:

<script type="application/ld+json"> { "@context":"https://schema.org", "@type":"TVSeries", "name":"Örnek Program" } </script>

Yapısal veriler küçük görünse de arama motorlarının içeriği anlamasında yardımcı olabiliyor.

Fazla JavaScript Her Zaman Çözüm Değil

Bir noktada fark ettiğim önemli şeylerden biri:

Sorunların çoğu daha fazla JavaScript eklenerek çözülmüyor.

Bazen:

daha az DOM
daha az istek
daha küçük CSS
daha sade yapı

çok daha iyi sonuç verebiliyor.

Özellikle mobil ağırlıklı projelerde hafiflik önemli hale geliyor.

Sonuç

TV yayın akışı sitesi ilk bakışta basit görünüyor.

Ancak kullanıcı sayısı ve veri miktarı arttığında:

performans
veri yönetimi
SEO
mobil optimizasyon
ölçeklenebilirlik

bir anda projenin merkezine yerleşiyor.

Küçük görünen projeler bazen büyük sistemlerden daha fazla optimizasyon gerektirebiliyor.

Kullanılan Kaynaklar:

• Schema.org — BroadcastService: https://schema.org/BroadcastService
• Schema.org — TelevisionChannel: https://schema.org/TelevisionChannel
• Örnek Çalışma - TV Yayın Akışı
• Google Search Central — Video Structured Data: https://developers.google.com/search/docs/appearance/structured-data/video