hls.js'in ESM kurulumlarının çoğu worker'ı sessizce atlıyor ve transmux işlemini main thread üzerinde yapıyor

ESM build'i worker'ını ayrı olarak sunuyor

dev.to'da yayınlanan bir yazı, web'de en yaygın kullanılan HLS oynatma kütüphanelerinden biri olan hls.js'teki sessiz bir performans tuzağını ele alıyor. Yazıya göre kütüphanenin ESM build'i — hls.js 1.4 ile dist/hls.mjs olarak sunuldu — transmuxer worker'ını, eski build'lerin yaptığı gibi inline etmek yerine ayrı bir dosya olarak sunuyor. Bu nedenle bundler tabanlı bir projedeki düz bir import Hls from 'hls.js' ifadesi çoğu zaman workersız ESM build'ine çözümleniyor ve kütüphaneyi açıkça worker dosyasına yönlendirene kadar her demux ve remux işlemi main thread üzerinde çalışıyor. Yazar, bulguların hls.js 1.7.x ile doğrulandığını belirtiyor.

Varsayılan yapılandırma bunun gözden kaçmasını kolaylaştırıyor. enableWorker varsayılan olarak true ve worker oluşturulamadığında bile true olarak kalıyor; yani anlamı "varsa bir worker kullan" değil, "bir worker çalışıyor" değil. Yazı bunu, konuyla ilgili yanılgıya kapılmanın en büyük tek kaynağı olarak nitelendiriyor.

Gerçekte ne çalıştırdığınızı nasıl kontrol edebilirsiniz

Varsaymak yerine, yazı oynatma sırasında tarayıcıyı incelemenizi öneriyor. performance.getEntriesByType('resource') sonucunun "worker" içeren girdiler için filtrelenmesi worker scriptini ortaya çıkarmalıdır; boş bir sonuç, hiç worker dosyasının getirilmediği anlamına gelir. DevTools kullanıcıları Chrome'un Sources panelindeki Threads görünümüyle veya Firefox'un debugger'ındaki worker listesiyle çapraz kontrol yapabilir — yalnızca main thread görünüyorsa, transmuxing inline yapılıyor demektir. Kütüphaneye doğrudan da sorulabilir: hls.config.workerPath hiç ayarlanmadıysa null'dur.

Çözüm tek bir yapılandırma seçeneği

Çare, hls.js/dist/hls.worker.js için gerçek bir URL çözümlemek ve bunu workerPath olarak geçmektir; sözdizimi bundler'a göre değişir. Vite veya Rollup'da dosya, bir asset URL'si almak için ?url ekiyle içe aktarılabilir. Webpack 5 ve Next.js client component'lerinde new URL('hls.js/dist/hls.worker.js', import.meta.url).toString() eşdeğerini üretir. Yanlış bir yol sessizce başarısız olacağından, yazar MANIFEST_PARSED olayından sonra "hls.worker" içeren bir resource girdisinin gerçekten resource timing buffer'da göründüğünü doğrulamayı öneriyor.

Main thread takılmalarını ağ takılmalarından ayırt etmek

Bir buffer stall olayı size yalnızca oynatmanın tükendiğini söyler; baytların mı geç geldiğini yoksa thread'in mi meşgul olduğunu değil. Yazı, stall olaylarını longtask girdilerini izleyen bir PerformanceObserver ile eşleştiriyor; bu girdiler main thread'i 50ms'den uzun tutan task'ları raporlar. Son long task'ların kayan bir penceresini tutarak ve sürelerini toplayarak her stall, buffer uzunluğunun yanına bir engellenme-milisaniyesi değeriyle etiketlenebilir. Bir saniyeden fazla engellenme süresi ve boş bir bufferla gelen stall, aç kalmış bir main thread'e işaret eder; sıfır engellenme süresiyle gelen stall ağa işaret eder. Yazının deyişiyle, bunlar çoğu ekibin şu anda aynı kovaya dosyaladığı birbirinden tamamen farklı iki iş kaydıdır.

İki uyarıya değinmekte fayda var. Safari longtask girdi türünü desteklemiyor; bu yüzden yazı, PerformanceObserver.supportedEntryTypes ile özellik algılamayı ve requestAnimationFrame boşluklarını saymaya geri düşmeyi öneriyor. Yazar ayrıca araçları doğrulamak için main thread'i her 500ms'de bir bilerek 120ms engellemeyi, player'ı workerPath ile ve workersız çalıştırmayı ve DevTools'ta ağ yerine CPU'yu yavaşlatmayı öneriyor — çoğu player testi yalnızca ağı yavaşlatır ve bu sınıf hatanın üretime ulaşmasının nedeni de budur.

Worker'ın çözmediği şeyler

Worker yapılandırılmış olsa bile kapsamı sınırlıdır. Yazıya göre segment getirme ağ thread'inde yapılıyor ve demux ile remux worker'a taşınıyor; ancak MediaSource ve SourceBuffer.appendBuffer() çağrıları hâlâ main thread'de yaşıyor ve uygulama koduyla rekabet ediyor. Decode ve render ise tarayıcının medya pipeline'ında kalıyor.

Platform düzeyindeki çözüm, MediaSource'u adanmış bir worker içinde oluşturmaktır; Chromium bunu Chrome 108'de (Opera 94'ün ardından) varsayılan olarak etkinleştirdi. Firefox ve Safari bunu sunmuş değil ve yazı, bugün hiçbir ana akım HLS kütüphanesinin bunu uçtan uca kullanmadığını belirtiyor; dolayısıyla bu, mimari bir temel değil yalnızca Chromium'a özgü bir geliştirme olarak görülmeli. Yazı ayrıca hls.js 1.5.0'da eklenen preferManagedMediaSource'a değiniyor; bu seçenek, kütüphanenin ikisi de mevcutken ManagedMediaSource'u klasik MediaSource'a göre seçip seçmediğini kontrol ediyor ve false'a ayarlanması geleneksel yolu zorluyor.

Neden önemli

Video oynatma, bir web sayfasının yürütebileceği en ağır yinelenen iş yüklerinden biridir ve bu, kütüphanenin öngörülen optimizasyonunun en yaygın modern kurulumda sessizce yok olduğu bir durum. Transmuxing'i main thread'den geri taşımak tek satırlık bir yapılandırma değişikliği; ama neredeyse hiç kimse bunu yapmayı bilmiyor, çünkü config bayrağı zaten açık olduğunu söylüyor. Anında düzeltmenin ötesinde, yazının araç Yaklaşımının daha geniş bir değeri var: main thread takılmalarını ağ takılmalarından ayıran telemetri, belirsiz buffering şikayetlerini teşhis edilebilir ve doğru şekilde atanan olaylara dönüştürüyor.