Optimizasyon Durumu
Özet: Web Player'lar Arasındaki Fark Nedir?
Basit Anlatım
Spotify Web ve YouTube Music Web de tıpkı Muzibu gibi tarayıcıda çalışıyor. Yani aynı kısıtlamalara tabi: aynı bellek limiti, aynı JavaScript motoru, aynı tarayıcı kuralları.
Fark mimaride: Onlar tek bir çalar kullanıp şarkı değişince sadece kaynağı değiştirirken, Muzibu her şarkıda yeni çalar oluşturup eskisini çöpe atıyor.
Benzetme: Spotify her şarkıda kaseti değiştiriyor. Muzibu ise her şarkıda teybi çöpe atıp yenisini alıyor.
Teknik Özet
Web Player Mimarisi Karşılaştırması
Spotify Web
open.spotify.com- Widevine EME - Tarayıcı DRM (donanım hızlandırmalı)
- DASH + MSE - Media Source Extensions ile akış
- Tek player instance - Hiç destroy/recreate yok
- ~30sn forward buffer - Minimal bellek kullanımı
- Ogg Vorbis 256kbps - Verimli codec
YouTube Music Web
music.youtube.com- Widevine EME - Aynı DRM altyapısı
- DASH + MSE - Adaptive bitrate streaming
- Tek player instance - Video/audio element reuse
- ~20-30sn adaptive buffer - Ağa göre ayarlanır
- AAC/Opus codec - Çok verimli sıkıştırma
Muzibu
muzibu.com- HLS + AES-128 - Yazılım tabanlı şifreleme
- HLS.js + MSE - Aynı MSE altyapısı
- Çoklu HLS instance - Her şarkıda new/destroy
- 20sn forward, 5sn back - Spotify seviyesi
- AAC 128kbps (HLS) - Standart kalite
DRM/Şifreleme Farkı (Web Player'lar)
Basit Anlatım
Spotify/YouTube: Tarayıcının kendi kilit sistemi (Widevine). Müzik şifreleme/çözme işi tarayıcının derinlerinde, hatta bazı cihazlarda donanımda yapılıyor. JavaScript'e hiç dokunmuyor.
Muzibu: Kendi kilit sistemi (AES-128). Her parçayı JavaScript ile çözüyor. Bu CPU'da ekstra iş demek, ama güvenlik açısından yeterli ve bağımsız çalışıyor.
Benzetme: Spotify kapıyı parmak iziyle açıyor (donanım). Muzibu ise her seferinde anahtarla açıyor (yazılım). İkisi de güvenli, biri daha hızlı.
Teknik Detay
navigator.requestMediaKeySystemAccess('com.widevine.alpha')
Tarayıcı CDM modülü ile decrypt. JS thread'i meşgul etmez.
HLS.js → fetch(key) → crypto.subtle.decrypt(segment)
Her segment için JS'de AES decrypt. CPU kullanır ama SubtleCrypto ile optimize.
Not: Web Crypto API (SubtleCrypto) kullanıldığında AES decrypt oldukça hızlı. Asıl performans farkı DRM'de değil, instance yönetiminde.
Bellek Yönetimi Karşılaştırması (Web Player)
| Özellik | Spotify Web | YouTube Web | Muzibu (Güncel) |
|---|---|---|---|
| Memory Limit | Browser heap (~2GB) | Browser heap (~2GB) | Browser heap (~2GB) |
| Garbage Collection | Browser V8 GC | Browser V8 GC | Browser V8 GC |
| Buffer Stratejisi | ~30sn forward, 0 back | 20-30sn adaptive | 20sn forward, 5sn back |
| Max Buffer Size | ~30-50MB | ~50MB | 30MB |
| Instance Yönetimi | Tek player, reuse | Tek player, reuse | Çoklu HLS instance |
| Şarkı Değişiminde | Source swap | Source swap | Cleanup aktif |
Buffer Optimizasyonu Tamamlandı
Buffer ayarları artık Spotify/YouTube seviyesinde:
maxBufferSize: 30MB,
backBufferLength: 5sn,
maxBufferLength: 20sn.
Kalan tek fark: HLS instance yönetimi (Madde 5).
HLS.js Ayarları: Eski → Güncel → Hedef
Eski Ayarlar (v1)
new Hls({
maxBufferLength: 30,
maxMaxBufferLength: 60,
maxBufferSize: 200MB,
backBufferLength: 30,
});Güncel Ayarlar (Şu An)
new Hls({
maxBufferLength: 20,
maxMaxBufferLength: 30,
maxBufferSize: 30MB,
backBufferLength: 5,
enableWorker: false,
});
// Preload: 1sn buffer
// + Madde 6 cleanupHedef (Madde 5 Sonrası)
// Başlangıçta 2 tane oluştur
hlsA = new Hls({...});
hlsB = new Hls({...});
// Şarkı değişince:
hlsA.stopLoad();
hlsA.detachMedia();
hlsA.loadSource(newUrl);
hlsA.attachMedia(audio);
// destroy yok!Audio Pipeline Karşılaştırması (Web)
Spotify Web Player Pipeline
DRM decrypt tarayıcı CDM'de, JS thread meşgul olmaz
YouTube Music Web Pipeline
Aynı Widevine altyapısı, video + audio birlikte
Muzibu Web Pipeline
HLS.js manifest parse + AES decrypt (SubtleCrypto ile hızlı). Asıl fark: her şarkıda yeni instance
Adil Karşılaştırma
Web player'da Spotify/YouTube ile Muzibu arasındaki pipeline farkı native app'teki kadar büyük değil. Hepsi aynı tarayıcıda, aynı MSE API'sini kullanıyor. Widevine decrypt biraz daha hızlı ama asıl performans farkını yaratan instance yönetimi: onlar tek player reuse ederken, Muzibu her şarkıda yeni HLS instance oluşturuyor.
Çözüm Önerileri: Yapılanlar ve Kalanlar
Tamamlanan Optimizasyonlar
-
Buffer Size: 200MB → 30MB
Spotify seviyesine indirildi
-
Back Buffer: 30sn → 5sn
Geri sarma nadiren kullanılır
-
Agresif Cleanup (Madde 6)
Şarkı değişiminde eski audio DOM'dan kaldırılıyor
-
Preload Buffer Optimize
Preload: 1sn buffer / 5MB (sadece ilk segment)
Kalan: Madde 5 - HLS Instance Reuse
Her şarkıda new Hls() + hls.destroy() yapılıyor. Bu:
- • Bellek ayırma/serbest bırakma overhead'i
- • Event listener sızıntı riski
- • GC baskısı (her destroy = çöp toplama tetikler)
- • SourceBuffer oluşturma/silme maliyeti
2 adet HLS instance (A ve B) başlangıçta oluştur, sonsuza kadar reuse et:
- • A çalarken B preload eder
- • Geçişte swap: B çalar, A preload eder
- • Asla destroy/new yok
- • Spotify/YouTube web ile aynı yaklaşım
Sabit bellek kullanımı, GC baskısı sıfır, geçişler anlık.
Uzun Vadeli Çözümler (Gelecek)
Offline playback, daha iyi caching, arka plan oynatma. Spotify Web de PWA desteği sunuyor.
Yeni tarayıcı API'si, hardware decode imkanı. Chrome 94+ destekli, Safari henüz kısıtlı.
Düşük RAM'li mobillerde HLS yerine direkt MP3 stream. HLS.js overhead'i sıfırlanır.
Gerçek çözüm ama büyük yatırım. Uzun vadede değerlendirilebilir.
Mevcut ve Beklenen İyileşme
Zaten Sağlanan
Madde 5 Sonrası Beklenen
Web player karşılaştırmasında: Buffer ayarları zaten Spotify/YouTube seviyesinde. Madde 5 (HLS reuse) tamamlandığında, Muzibu web player'ı Spotify Web Player ile neredeyse aynı performans profiline sahip olacak. Kalan tek fark DRM yaklaşımı (Widevine vs AES-128) olacak ki bu küçük bir fark.
Kaynaklar
Versiyon Geçmişi
v1 (18 Şubat 2026): İlk rapor - Native app karşılaştırması, eski buffer değerleri
v2 (18 Şubat 2026): Web player odaklı güncelleme, yapılan optimizasyonlar işaretlendi, güncel değerler yansıtıldı