Bir video indirme aracına bakıp “Bu iş bu kadar mı zor?” diyebilirsiniz. Açık konuşayım — Bilibili tarafında cevap hiç kısa değil (ben de ilk duyduğumda şaşırmıştım). Çünkü ortada tek bir dosya yok; ayrı ayrı akan ses, görüntü, bazen de sinir bozucu header kontrolleri var. Ama işte tam bu karmaşa, doğru yaklaşımla ele alındığında bayağı öğretici bir mühendislik dersine dönüşüyor aslında.
Geçen yıl Kasım 2025’te İstanbul’da bir editör masasında benzer bir akış çözmeye çalışırken aynı hissi yaşamıştım. Dosya var sanıyorsun, meğer parça parça servis ediliyor. Hani marketten hazır yemek alırsın da evde üstünü tamamlamak gerekir ya… tam öyle. Bilibili’de de mantık biraz bu: metadatası ayrı, video segmentleri ayrı, audio ayrı. Güzel değil mi? Tabii değil.
AV’den BV’ye geçiş neden önemli?
Açık konuşayım, Bilibili’nin en ilginç taraflarından biri kimlik yapısı. Eskiden AV numarası vardı; düz, sayısal, okunması kolay bir sistemdi (yanlış duymadınız). Sonra BV formatı geldi ve iş biraz maskeli baloya döndü. Dışarıdan bakınca anlamsız gibi görünen bu değişim, aslında platformun içerik takibini zorlaştırma ve ekosistemi daha kontrollü yönetme hamlesi olarak okunuyor — en azından ben öyle okuyorum.
Bunu ilk kez 2024 baharında Ankara’da kendi not defterime işlerken fark ettim. “Bir ID’yi çevirmek niye bu kadar uğraştırıyor?” dedim kendi kendime. Cevap şu oldu: çünkü basit görünen şeyler çoğu zaman en çok kontrol isteyen şeylerdir, hani (inanın bana). BV dönüşümü de öyle; sadece string oynatmak değil, karakter tablosu, XOR mantığı. Yer değiştirme kurallarıyla küçük bir şifreleme oyunu gibi çalışıyor — “biraz regex atayım bitti” diyemezsin.
Bir dakika — bununla bitmedi.
ID dönüşümünün pratik etkisi
Geliştirici açısından mesele net aslında. Kullanıcı sana AV numarası da verebilir, BV linki de atabilir; eğer araç ikisini de tanımıyorsa iş yarıda kalır ve kullanıcı haklı olarak “bu ne biçim indirici” der. Haklı da olur. O yüzden sunucu tarafında iki formatı da çözen bir katman kurmak şart oluyor.
Burada hoşuma giden şu: sistem tasarımı ile kullanıcı deneyimi birbirinden kopuk değil. Arka planda karmaşık dönüşüm bir düşüneyim… yaparsın ama önde kullanıcı tek kutuya URL yapıştırır, gerisini düşünmez. İyi yazılım dediğin şey biraz da budur zaten — arka tarafta terlersin, ön tarafta kullanıcı rahat eder. Basit ama doğru.
DASH akışı neden klasik indirmeden farklı?
Klasik medya indirmede çoğu zaman tek URL görürsün ve dosyayı çekersin biter. DASH ise başka bir dünya. Video parçalara ayrılır, ses ayrı akar, kalite seviyesi — hatta bazen cihaz davranışı bile — buna göre şekillenir. Bilibili’de asıl teknik zorluk burada başlıyor, çünkü senin indiricinin iki farklı nehri aynı kovada buluşturması gerekiyor. Kolay değil bu.
Çok konuştum, örnekle göstereyim.
Dur bir saniye — önce şunu söyleyeyim: DASH sadece “segmentli video” demek değil, aynı zamanda adaptif yayın demek. Yani ağ kötüleşirse sistem kendini toparlıyor, kalite düşürüyor ama oynatma devam ediyor. Kullanıcı için bu harika; downloader içinse ufak bir kabus. Bu konuyla ilgili Discord Botu ile Rakip Paylaşımlarını Anında Yakala yazımıza da göz atmanızı tavsiye ederim. Türkiye’nin BYD Dosyası: Ceza, Fabrika ve Piyasa Gerilimi yazımızda bu konuya da değinmiştik.
Video ve sesin ayrı akması ne getiriyor?
Şöyle söyleyeyim, Artısı belli: esneklik. Bir mobil kullanıcı için düşük bitrate yeterliyken masaüstünde yüksek çözünürlük sunabilirsin. Ama eksi tarafı da net — son aşamada bu iki akışı yeniden eşleştirmek zorundasın. Atlatma yok.
Bunu geçen ay İzmir’de test ettiğim küçük bir yan projede açıkça gördüm. Video akışı geldi ama ses segmentleri gecikti; çıktı dosyası oynuyordu fakat sessizdi (şaşırtıcı ama gerçek). İşte o an anladım ki muxing kısmı “olsa iyi olur” değil, ürünün bel kemiği.
| Yaklaşım | Avantaj | Zayıf Nokta |
|---|---|---|
| Tek dosya çekmek | Sade ve hızlı | DASH olan yerde çoğu zaman işe yaramaz |
| Ayrı stream çekip mux etmek | Yüksek kaliteyi korur | Daha fazla işlem gerekir |
| Sadece metadata almak | Hafif yük oluşturur | Kullanıcıya dosya vermezsin |
FFmpeg ile birleştirme kısmı neden kritik?
Muxing deyince kulağa süslü geliyor. Özünde yapılan şey net: video ile sesi evlendirmek. Üstelik yeniden kodlamadan yapmak istiyorsun ki kalite bozulmasın ve CPU boş yere yanmasın. FFmpeg’in gücü tam burada ortaya çıkıyor; doğru bayraklarla kullanırsan ham veriyi olduğu gibi taşır, hiç ellemiyor.
Durun, bir saniye.
ffmpeg -i video.m4s -i audio.m4s -c copy -map 0:v:0 -map 1:a:0 output.mp4
Vallahi, `-c copy` kısmını ilk kez üretimde kullandığımda baya şaşırmıştım, çünkü beklediğimden çok daha hızlıydı (bizzat test ettim). Ciddi fark var. Kurumsal ölçekte çalışan bir sistemde bu önem kazanıyor — gereksiz transcode yaptığında sunucu kaynakları şişiyor, kuyruk uzuyor. Herkes birbirine bakmaya başlıyor. Gülünç ama gerçek. Bu konuyla ilgili Easter Phishing Tuzağı: Bir Operasyonu Söküp Atmak yazımıza da göz atmanızı tavsiye ederim.
Küçük startup ile enterprise arasında fark ne?
Küçük startup’ta öncelik hız olur. İki kişi kullanacaksa ekstra optimizasyonları sonra yaparsın; önce çalışan sürüm lazım, o kadar.
Kurumsal projede tablo değişir — loglama isterler, hata ayıklama isterler, tekrar deneme mekanizması isterler, hatta bazen FFmpeg sürümü bile sorun çıkarır. Neyse uzatmayalım: aynı komut iki ortamda aynı değeri taşımıyor, bu kadar basit.
E tabi burada kalite kadar dayanıklılık da önemli. Segmentlerden biri eksik gelirse ne olacak? Sistemin çökmesi mi lazım yoksa kuyruğa geri mi atmalı? Ben olsam ikinci yolu seçerim — çünkü gerçek dünyada her istek temiz gelmiyor, bazen CDN nazlanıyor, bazen paket kaybolup gidiyor.
Referer kontrolü ve anti-scraping duvarları
İlginç olan şu ki, Bilibili gibi platformlarda asıl can sıkan nokta çoğu zaman içerik değil erişim politikası. 403 hatasını görünce insan önce kendi kodundan şüphe ediyor. Sonra header’lara dönüyorsun, bir Referer eksikmiş meğer. Bu kadar basit ama etkisi büyük. Platformlar bunu boşuna yapmıyor tabii; bot trafiğini azaltmak istiyorlar ve açıkçası haksız da sayılmazlar.
“İyi çalışan bir downloader’ın sırrı sadece veri çekmek değildir; doğru zamanda doğru isteği göndermek ve platformu gereksiz yere rahatsız etmemektir.”
- Referer: Doğru kök adres olmadan istekler kolayca reddedilebilir.
- Kuki yönetimi: Oturum bilgisi olmadan bazı yüksek kaliteli akışlara ulaşamazsın.
- Sınırlama kontrolü: Aynı anda çok fazla istek atmak kısa vadede hız verir gibi görünür ama uzun vadede kapıyı kapattırır.
Editör olarak bazen şöyle düşünüyorum: “Bu kadar savunma mekanizması gerekli mi?” Açıkçası evet. Çünkü ölçüsüz scraping hem etik açıdan sıkıntılı hem de teknik olarak sürdürülemez. Bir sistemi anlamak başka şeydir; onu sömürmeden kullanmak başka şey. Aradaki çizgi ince ama önemli. Hyundai IONIQ 6 N, yılın performans otomobili oldu: İşte perde arkası yazımızda da bu konuya değinmiştik. AI Kodunda Güvenlik Tuzağı: Node.js İçin Sert Kurallar yazımızda da bu konuya değinmiştik.
Mimaride neler iyi çalışıyor?
İnanın, Böyle araçlarda arka uç mimarisi her şeyi belirliyor. Python/Django tercih edilmesi bana mantıklı geliyor — API orkestrasyonu için yeterince rahat, httpx + asyncio ikilisi ise I/O ağırlıklı işler için gayet sağlam duruyor. Kendi testimde Şubat 2026’da birkaç paralel istek açtığımda süreçlerin birbirini beklemeden ilerlemesi ciddi fark yarattı, şaşırdım açıkçası.
Bence burada asıl başarı “çok hızlı olmak” değil — yük altında dağılmadan devam edebilmek. Mesela metadata alma işiyle stream çözümleme işi paralel yürüyorsa kullanıcı bekleme süresi düşüyor. Üstüne sonuçlar cache’lenirse daha da iyi. Ama cache’i körlemesine açarsan eski linklerle uğraşırsın… yani her nimet biraz bedel istiyor. Hep böyle.
Neler işe yarar?
- Ayrık görev kuyruğu kullanmak
- Lokal testte farklı çözünürlükleri denemek
- Muxing öncesi stream bütünlüğünü doğrulamak
- Error loglarını sade tutmak
- Kullanıcıya anlaşılır hata mesajı göstermek
Peki nerede tökezlenir? En sık gördüğüm problem ağ gecikmesi değil — yanlış varsayım. Yani geliştirici videonun hep tam geleceğini sanıyor, ses yolunun hep açık olacağını sanıyor… sonra gerçek hayat tokadı geliyor. Maalesef.
Kullanıcı deneyimi niye hafife alınmamalı?
Bak şimdi, Bazen teknik ekip şöyle düşünür: “Aracı çalıştırdık mı tamam.” Hayır efendim, tam değil. Kullanıcı ekranına bakınca üç saniyede anlayamıyorsa orada eksik vardır, nokta.
Ha bu arada — responsive tasarım konusu da boş laf değil. Mobilde sayfa ağır açılıyorsa en iyi backend bile gölgede kalır. Bunu geçen hafta Kadıköy’de telefonumdan test ederken yine gördüm: masaüstünde pürüzsüz olan arayüz telefonda hantallaşabiliyor. Sinir bozucu ama öyle.
- Sade JavaScript yaklaşımı hafiflik sağlar.
- Grid/Flexbox düzeni kırılganlığı azaltır.
- Dil desteği global kullanım için değer katar. — ciddi fark yaratıyor
- Anlık durum mesajları kullanıcı güvenini artırır.
- Tam sessizlik yerine ilerleme göstergesi vermek her zaman daha iyidir.
Sistemden alınacak ders ne?
Dürüst olmak gerekirse, Bana göre bu tür projelerin asıl değeri yalnızca medya indirmek değil. Asıl kazanç şu: streaming mimarisini, header oyunlarını, async işleyişi ve muxing mantığını bir arada görmek. Hepsi ayrı ders. Bir araya gelince ise epey güçlü bir mühendislik resmi çıkıyor karşına.
İtiraf edeyim, Şöyle düşün: küçük ölçekte başlayan proje, bir süre sonra rate limit, proxy, queue, cache, loglama gibi konulara dokunmaya başlıyor. Başlangıçta basit görünen iş zamanla mini platforma dönüyor. Tanıdık geliyor mu? Bana çok tanıdık geliyor.
Vallahi, Bence bunun en öğretici tarafı şu — gerçek internet, temiz laboratuvar koşullarında çalışmıyor. Bazen paket gelir, bazen gecikir, bazen referer yüzünden geri döner… ve sen neredeyse tüm bunlara rağmen sağlam sistem kurmaya çalışırsın. Tam da öyle.
Yazıyı bitirirken şunu söyleyeyim: eğer böyle bir araç geliştiriyorsanız, önce doğruluğu oturtun, sonra performansı, en son cilayı yapın. Ters sırayla giderseniz parlak görünen ama dayanıksız yapı çıkabiliyor. Defalarca gördüm.
Teknik borcu erken görmeyen araçlar, canlı ortamda pahalıya patlar. Hele bir de medya işlerinde, küçük hata hemen göz önüne serilir.
Sıkça Sorulan Sorular
Bilibili videosu neden tek dosya halinde inmiyor?
{font}
? No need to include invalid characters?
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.
