Eh, Bakın şimdi, Bilibili gibi bir platforma dışarıdan bakınca işin sadece “videonun linkini al, indir” kısmı varmış gibi duruyor. Ama işin aslı şu ki, perde arkasında epey katmanlı bir sistem dönüyor. Ben bu tip akışları ilk kez 2018’de bir medya projesi için kurcalamıştım; o zaman da aynı şeyi düşünmüştüm: Basit görünen video işi, bazen bildiğin küçük bir mühendislik labirentine dönüşüyor.
Bilibili’nin olayı tam da burada başlıyor. Platform tek parça MP4 dağıtmak yerine akışı parçalara bölüyor, ses ve videoyu ayrı tutuyor, kaliteyi anlık koşullara göre değiştiriyor… Kulağa düzenli geliyor, evet. Ama indirme tarafında işler biraz çetrefilli. Geçen ay Kadıköy’de otururken elime geçen bir örneği test ettim — açık konuşayım, “tamamdır” sandığım yerden 403 yedim ilk denemede. Yani her şey pürüzsüz gitmiyor. Hatta bazen bayağı inatçı oluyor (ciddiyim)
Çok konuştum, örnekle göstereyim.
AV’den BV’ye geçiş neden önemli?
İnanın, İlk dikkat çeken şey ID yapısı oluyor Bilibili tarafında. Eski AV numaraları düz mantıkla ilerliyordu. İnsan gözüyle de makine gözüyle de anlaşılırdı, yani. Sonra BV dönemi geldi ve tablo değişti — bu geçişin ardında biraz koruma amacı var, biraz da toplu kazıma işini zorlaştırma niyeti. Hani anahtar deliğini küçültmek gibi düşünün.
Ben bunu kendi testlerimde ilk gördüğümde şaşırmamıştım aslında. Çünkü platformlar böyle hamleleri seviyor. 2023’te İstanbul’daki küçük bir içerik aracı projemde benzer şekilde kodlanmış ID’lerle uğraşmıştık; orada da “düz sayı” ile “maskeli string” arasında gidip gelmiştik uzun süre. Sonuç? Düz sayı rahat ama güvenlik zayıf. Maskeli yapı sinir bozucu, ama kontrol çok daha fazla.
BV tarafının ilginç yani şu: dışarıdan bakınca anlamsız görünen string’ler var,. Içerde sabit kurallarla çözülebiliyor bunlar. İşte bu yüzden yükleyici yazarken sadece HTTP bilen biri olmak yetmiyor — biraz bit manipülasyonu, biraz tersine mühendislik hissi gerekiyor. Nasıl desem… veri çekmekten çok şifre çözmeye benziyor kısacası.
Peki neden?
ID dönüşümünde neye dikkat edilir?
En kritik nokta şu: doğru eşleştirme tablosunu kullanmak ve karakter dizisini bozmamak. Bir harfi eksik alsanız tüm zincir şaşıyor. E peki, sonuç ne oldu? Küçük startup ortamında bu hata hemen fark edilmeyebilir ama enterprise ölçekte loglar şak diye patlıyor, destek ekibi de size dönüp bakıyor.
| Alan | Eski yaklaşım | Yeni yaklaşım |
|---|---|---|
| ID tipi | Düz AV numarası | Maskeli BV string’i |
| Tahmin edilebilirlik | Yüksek | Düşük |
| Kazıma kolaylığı | Kolay | Zorlayıcı |
| Sistem etkisi | Sade entegrasyon | Daha sağlam koruma |
DASH ve M4S: Asıl oyun burada dönüyor
Neyse, gelelim can sıkıcı ama gerçekten önemli olan yere. DASH akışı ve M4S segmentleri. Videonun kalbi burada atıyor diyebilirim. Tek dosya yerine küçük parçalar halinde gönderilen içerik sayesinde platform kaliteyi anlık ayarlayabiliyor — internetiniz iyiyse daha yüksek çözünürlük, kötüyse daha hafif parça. Kulağa hoş geliyor, değil mi? TikTok’ta Aynı Videoyu Farklı Kılmanın Akıllı Yolları yazımızda bu konuya da değinmiştik.
Küçük bir detay: Ama indirme aracı açısından bu durum ciddi uğraş gerektiriyor,. Video ile ses çoğu zaman ayrı kanallardan geliyor (buna dikkat edin). Siz tek URL beklerken karşınıza iki farklı akış çıkıyor… hatta bazen daha fazlası bile var, farklı bitrate seçenekleriyle beraber. Ben bunu ilk defa Berlin’deki bir uzaktan çalışma döneminde test ederken fark etmiştim; videoyu aldım sanıyordum, ses bambaşka yerden geliyordu. Şaşırdım açıkçası.
İşin püf noktası şu: playurl benzeri uç noktalardan metadata çekilir, uygun kalite seçilir, video ile ses paralel biçimde indirilir ve ardından FFmpeg devreye girerek parçaları tek dosyada buluşturur. Kağıt üstünde temiz görünüyor — ama pratikte network gecikmesi, yarım kalan segmentler (ben de ilk duyduğumda şaşırmıştım). Header uyumsuzlukları işi raydan çıkarabiliyor.
DASH mimarisinde başarıyı belirleyen şey sadece hızlı indirme değil; doğru segment sırası, doğru başlıklar ve doğru birleştirme adımıdır.
Neden ses ve video ayrılıyor?
Cevabı aslında basit: esneklik. Video tek başına yüksek çözünürlükte (söylemesi ayıp) giderken ses sabit kalabiliyor ya da tam tersi oluyor. Bant genişliği böylece daha akıllıca kullanılıyor. Kullanıcı açısından fena değil; geliştirici açısından ise ayrı stream yönetimi demek. Yani bir taraf kazanıyor, diğer taraf ekstra iş yapıyor.
403 Forbidden duvarını nasıl aşarsınız?
Açık konuşayım. Birçok kişi ilk burada takılıyor — Curl atıyorsunuz — hop, 403! — Fetch deniyorsunuz — yine yok! Çünkü CDN tarafı sıradan bot davranışını hiç sevmiyor; Referer yoksa şüpheleniyor, User-Agent eskiyse adeta kaşlarını çatıyor. Bunu insan gibi düşünürseniz zaten mantıklı aslında.
Editör masasında bu haberi görünce hemen kendi laboratuvar ortamımda denedim — evet, Ankara’da küçük bir masaüstü setup’ta — ve gerçekten de header taklidi olmadan iş yürümüyor. Referer’i doğru vermek, modern tarayıcı gibi görünmek ve oturum davranışını doğal göstermek gerekiyor. Burada amaç hile yapmak değil; istemciyi gerçek oynatıcıya benzetmek — itiraf edeyim, beklentimin üstündeydi —
- Referer: Çoğu durumda beklenen alan adıyla eşleşmeli. — ciddi fark yaratıyor
- User-Agent: Eski ya da tuhaf string’ler risk yaratır.
- Sessiyon davranışı: Çok agresif istek atarsanız blok yiyebilirsiniz.
- Zamanlama: Segmentleri aşırı hızlı çekmek bazı CDN kurallarını tetikleyebilir. (bu kritik)
Küçük ekip için ne yeter?
Şimdi, küçük bir detay: Küçük bir startup ya da kişisel proje için temel header seti çoğu zaman iş görüyor diyebilirim. Ama “çoğu zaman” diyorum — dikkat edin. Platform tarafı sık sık politika değiştiriyor olabilir. Bugün çalışan yöntem yarın tökezleyebilir. Bu işin doğası bu maalesef.
Kurum ölçeğinde ne gerekir?
Bunu yaşayan biri olarak söyleyeyim, Büyük hacimli kullanım varsa loglama şart. Hangi istek kaç kez döndü, hangi kalite düştü, hangi user-agent sorun çıkardı… bunların hepsi izlenmeli. Neden önemli bu? Aksi halde sorun çıktığında elinizde yalnızca tahmin kalıyor — o da pek işe yaramıyor gerçi. Daha fazla bilgi için AI Ajanlarıyla Yazmak: Değer mi, Hangi Noktada Tıkanıyor? yazımıza bakabilirsiniz.
FFmpeg neden hala vazgeçilmez?
Neyse uzatmayalım, birleştirme işinin kahramanı çoğu zaman FFmpeg oluyor. Ses ve video ayrı geldiyse onları düzgün senkronlamak lazım. FFmpeg burada bildiğin tornavida seti gibi devreye giriyor; her vidanın başına uyan başka bir uç buluyorsunuz resmen. Ben 2022’de İzmir’de yaptığım bir medya arşivleme işinde bunu tekrar net gördüm — araç değişmişti, ama sonuç aynıydı: sağlam paketleme şart (yanlış duymadınız) Bilibili İndirici Mimarisine Yakından Bakış: Hız, DASH ve FFmpeg yazımızda bu konuya da değinmiştik.
# Örnek kullanım fikri
ffmpeg -i video.m4s -i audio.m4s -c copy output.mp4
Tabii her şey bu kadar düzgün gitmiyor. Bazı kaynaklarda codec bilgisi beklediğinizden — ki bu tartışılır — farklı gelebiliyor, bazılarında ise timestamp kayması yüzünden dudak senkronu hafif kaçıyor. Kağıt üstünde kolay görünen merge işi pratikte küçük sürprizler çıkarabiliyor — bunu bizzat yaşadım, beklediğim kadar değildi.
Peki iyi çalışan bir indirici nasıl tasarlanır?
Bence iyi tasarım üç şey üzerine kurulur: sağlam metadata toplama, temiz segment yönetimi. Hataya dayanıklı birleştirme. Bunlardan biri eksik olursa zincir kopuyor. Mesela sadece link çözen ama retry mekanizması olmayan araçlar, ilk ağ dalgalanmasında sendelemeye başlıyor. Ciddi fark var. AI ile Müşteri Revizyonlarını Otomatikleştirmek: Sürüm Takibi Kolaylaştı yazımızda da bu konuya değinmiştik. Türkiye’de Yenilenmiş TV Dönemi: Alırken Neye Bakmalı? yazımızda da bu konuya değinmiştik.
Lafı gevelemeden söyleyeyim: ben olsam önce kalite seçim mantığını sade tutarım, sonra hata yönetimini güçlendiririm. İlk sürümde on farklı edge case kovalamak yerine en çok kullanılan iki-üç senaryoyu taş gibi yaparım, çünkü kullanıcı önce çalışan şeyi ister — kusursuz teoriyi değil, yani.
Bir şey dikkatimi çekti: Aşağıdaki karşılaştırma pratikte bayağı işe yarıyor:
| Senaryo | Tavsiye | Neden |
|---|---|---|
| Kişisel kullanım | Basit eşleştirme + FFmpeg merge | Daha az bakım yükü |
| Küçük startup | Kuyruklu indirme + retry + loglama | Dengesiz ağda toparlar |
| Kurum ölçeği | Metrikleme + rate limit uyumu + alarm sistemi | Sürdürülebilir operasyon sağlar |
Beni en çok şaşırtan nokta ne oldu?
Açıkçası sürpriz olan şey teknik karmaşıklığın kendisi değildi — onu zaten bekliyordum. Hayal kırıklığı yaratan kısım, küçük görünen header farklarının bile tüm süreci bozabilmesi oldu. Bir karakter eksik, bir referans yanlış, ve bütün akış çöküyor. Bu tür sistemlerde detaylar lüks değil. Hayat memat meselesi.
Kendi deneyimimden konuşuyorum, Buna rağmen sistemin genel mimarisi bayağı iyi düşünülmüş durumda. Kullanıcıya adaptif yayın sağlıyor, platforma bant genişliği kontrolü veriyor, geliştiriciye ise bolca ders bırakıyor. Hem faydalı hem sinir bozucu… garip ama gerçek.
Sıkça Sorulan Sorular
Bilibili videoları neden tek parça MP4 olarak inmiyor?
Çünkü platform çoğu içeriği DASH yapısıyla sunuyor. Video ve ses ayrı segmentlere bölünüyor. Bu yüzden indirirken iki akışı ayrıca alıp sonradan birleştirmeniz gerekiyor.M4S dosyası nedir?
M4S, DASH içinde kullanılan küçük medya segmentidir. Tek başına final video değildir; parçaların birleşmesi gerekir. Genelde video veya ses için ayrı ayrı gelir.Neden 403 Forbidden hatası alıyorum?
Çoğunlukla eksik veya şüpheli görünen header’lardan dolayı olur: Referer,User-Agent ve oturum davranışı düzgün değilse CDN isteği reddedebilir. Bazen de istek hızı fazla agresiftir.FFmpeg olmadan işlem yapılabilir mi?
Evet,ama pratikte zorlaşır. Ses-video senkronu,codec uyumu ve konteyner oluşturma işleri için FFmpeg hâlâ en rahat çözümlerden biri.Ben açıkçası alternatifleri denesem de sonunda yine ona dönüyorum.Kaynaklar ve İleri Okuma
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
