Ben Dale Curtis, Chromium'da medya oynatma bölümünün mühendisim. Ekibim video oynatma için web'e yönelik API'lerden (ör. MSE ve WebCodecs) ve ses ile videonun kodunu çözme, çözme ve oluşturma ile ilgili, platforma özel dahili öğelerden sorumludur.
Bu makalede, Chromium'un video oluşturma mimarisini adım adım göstereceğim. Genişletilebilirlikle ilgili bazı ayrıntılar muhtemelen Chromium'a özgü olsa da burada tartışılan kavram ve tasarımların çoğu diğer oluşturma motorları ve hatta yerel oynatma uygulamaları için geçerlidir.
Chromium'un oynatma mimarisi yıllar içinde önemli ölçüde değişti. Bu dizinin ilk gönderisinde açıklandığı gibi başarı piramidi fikriyle başlamamış olsak da sonunda benzer adımlar izledik: güvenilirlik, performans ve ardından genişletilebilirlik.
Başlangıçta video oluşturma oldukça basitti. Yalnızca bir döngü şeklinde, şifresini çözen video karelerinin hangi yazılımın birleştiriciye gönderileceğini seçiyordu. Bu sistem yıllarca güvenilir oldu. Ancak web'in karmaşıklığı arttıkça daha fazla performans ve verimliliğe duyulan ihtiyaç, mimari değişikliklere yol açtı. Birçok iyileştirme işletim sistemine özel temel öğeler gerektiriyordu. Bu nedenle, Chromium'un tüm platformlarına erişebilmek için mimarimizin de daha genişletilebilir olması gerekiyordu.
Video oluşturma işlemi iki adıma ayrılabilir: Neyin yayınlanacağını seçme ve bu bilgileri verimli bir şekilde sunma. Okunabilirlik açısından Chrome'un neyi sunacağını nasıl seçtiğini açıklamadan önce etkili teslimden bahsedeceğim.
Bazı şartlar ve düzen
Bu makale, oluşturmaya odaklandığı için ardışık düzenin çalıştırma ve kodunu çözme konularına kısaca değineceğim.
Güvenlik bilincine sahip modern dünyamızda kodu çözmek ve bu kodu çözmek için belirli bir özen gösterilmesi gerekir. İkili ayrıştırıcılar, zengin hedef ortamlardır ve medya oynatma ikili ayrıştırma işlemiyle doludur. Bu nedenle, medya ayrıştırıcılardaki güvenlik sorunları son derece yaygındır.
Chromium, kullanıcılarımızın güvenlik sorunu yaşaması riskini azaltmak için derinlemesine savunma uygulamaktadır. Pratik bir şekilde açıklamak gerekirse bu, mükerrer kaldırma ve yazılım kodu çözme işlemlerinin her zaman düşük ayrıcalıklı bir süreçte gerçekleştiği anlamına gelir. Donanım kodu çözme ise sistemin GPU'su ile konuşmak için yeterli ayrıcalıklara sahip bir işlemde gerçekleşir.
Chromium'un işlemler arası iletişim mekanizmasının adı Mojo'dur. Bu makalede Mojo'nun ayrıntılarına girmeyecek olsak da süreçler arasındaki soyutlama katmanı olarak buradaki Mojo, Chromium'un genişletilebilir medya hattının temel taşlarından biridir. Oynatma ardışık düzeninde adım adım ilerlerken bunun farkında olmak önemlidir. Çünkü bu; medya almak, ayrıştırmak, kodunu çözmek ve son olarak görüntülemek için etkileşime giren çapraz işlem bileşenlerinin karmaşık şekilde düzenlenmesini sağlar.
Çok sayıda bit
Günümüzün video oluşturma kanallarını anlamak için videonun neden özel olduğunu, yani bant genişliğini bilmeniz gerekir. Saniyede 60 kare hızında 3840x2160 (4K) çözünürlükte oynatma, 9-12 gigabit/saniye bellek bant genişliği kullanır. Modern sistemlerde bant genişliğinin saniyede yüzlerce gigabitle zirveye ulaşması mümkün olsa da video oynatmanın hâlâ önemli bir kısmını oluşturuyor. Toplam bant genişliği, bakım gerektirmeden GPU ile CPU belleği arasındaki kopyalar veya takılmalar nedeniyle kolayca çoğalabilir.
Verimliliği göz önünde bulundurularak tüm modern video oynatma motorlarının amacı, kod çözücü ile son oluşturma adımı arasındaki bant genişliğini en aza indirmektir. Bu nedenle video oluşturma, Chromium'un ana oluşturma hattından büyük ölçüde ayrılır. Özellikle ana oluşturma ardışık düzenimiz açısından, video sadece opaklığa sahip sabit boyutlu bir deliktir. Chromium bunu, her videonun doğrudan Viz'e bahsettiği surfaces adlı bir kavram kullanarak yapar.
Mobil bilişimin popülerliği nedeniyle, güç ve verimlilik mevcut nesilde önemli bir odak olmuştur. Bunun sonucunda kod çözme ve oluşturma donanım düzeyinde hiç olmadığı kadar fazla çalışır. Bu sayede video, işletim sisteminin kendisinde bile opaklığa sahip bir delik gibi görünür. Platform düzeyinde kod çözücüler, genellikle Chromium'un platform düzeyindeki birleştirme sistemine ilettiği opak arabellekleri genellikle yer paylaşımları biçiminde sağlar.
Her platformun, platform kod çözme API'lerinin uyum içinde çalıştığı kendi yer paylaşımı biçimleri vardır. Windows'da Direct Composition ve Media Foundation Transforms, macOS'te CoreAnimation Katmanları ve VideoToolbox, Android'de SurfaceView ve MediaCodec, Linux'ta VASurfaces ve VA-API bulunur. Chromium'un bu kavramlarla ilgili soyutlamaları, sırasıyla OverlayProcessor ve mojo::VideoDecoder arayüzleri tarafından işlenir.
Bazı durumlarda bu arabelleklerin sistem belleğine eşlenebilir olması mümkündür. Bu nedenle, opak olmalarına ve erişilene kadar bant genişliğini kullanmalarına bile gerek yoktur. Chromium bunlara GpuMemoryBuffers adını verir. Windows'da bunlar DXGI arabellekleri, macOS IOSurfaces, Android AHardwareBuffers ve Linux DMA arabellekleri'nde desteklenir. Video oynatma genellikle bu erişime ihtiyaç duymasa da bu arabellekler, görüntü yakalama cihazı ile nihai kodlayıcılar arasında minimum bant genişliği sağlamak açısından video yakalama açısından önemlidir.
GPU, genellikle kod çözme ve görüntüleme işlemlerinden sorumlu olduğundan bu (ayrıca sıklıkla) opak arabelleklerin kullanılması, yüksek bant genişliğine sahip video verilerinin GPU'dan hiçbir zaman dışarı çıkmamasını sağlar. Daha önce de konuştuğumuz gibi, özellikle yüksek çözünürlüklerde ve kare hızlarında verimlilik için verilerin GPU'da tutulması çok önemlidir.
Yer paylaşımları ve GPU arabellekleri gibi temel işletim sistemi öğelerinden ne kadar çok yararlanabilirsek video baytlarını gereksiz yere karıştırmak için o kadar az bant genişliği harcanır. Kod çözme işleminden oluşturma işlemine kadar her şeyi tek bir yerde tutmak, olağanüstü güç verimliliği sağlayabilir. Örneğin, Chromium macOS'te yer paylaşımlarını etkinleştirdiğinde, tam ekran video oynatma sırasında güç tüketimi yarıya indi! Windows, Android ve ChromeOS gibi diğer platformlarda tam ekran olmayan durumlarda bile yer paylaşımlarını kullanabiliyor, böylece neredeyse her yerde% 50'ye varan tasarruf sağlıyoruz.
Oluşturma
Optimum yayınlama mekanizmalarını işlediğimize göre şimdi Chromium’un neyi sunacağını nasıl seçtiğini tartışabiliriz. Chromium'un oynatma yığını, "çekme" tabanlı bir mimari kullanır. Yani yığındaki her bileşen, girişlerini hiyerarşik sırada bir alttakinden ister. Yığının en üstünde ses ve video kareleri oluşturma, sonraki alt kısımda kod çözme, ardından demuxing ve son olarak G/Ç yer alır. Oluşturulan her ses karesi, bir sunu aralığıyla birleştirildiğinde oluşturma yapılacak video karelerini seçmek için kullanılan bir saat ilerler.
Her sunum aralığında (görüntünün her yenilenmesi) video oluşturucudan, daha önce bahsedilen SurfaceLayer'a eklenmiş bir CompositorFrameSink tarafından bir video karesi sağlaması istenir. Kare hızı, görüntüleme hızından düşük olan içeriklerde aynı karenin birden fazla kez gösterilmesi anlamına gelir. Öte yandan, kare hızı görüntüleme hızından büyükse bazı kareler hiçbir zaman gösterilmez.
Sesi ve videoyu görüntüleyenleri memnun edecek şekilde senkronize etmenin çok daha fazlası var. Chromium'da optimum video akıcılığının nasıl sağlandığı hakkında daha uzun bir tartışma için Butter Projesi'ne bakın. Video oluşturmanın, her karenin kaç kez gösterilmesi gerektiğini temsil eden ideal adım sıralarına nasıl ayrılabileceğini açıklar. Örneğin: "Her görüntüleme aralığında 1 kare ([1], 60 Hz'de 60 fps)", "2 aralıkta bir 1 kare ([2], 60 Hz'de 30 fps)" veya farklı ve 60 Hz kare görüntüleme aralıklarında [2:3:2:3:2] (25 fps) gibi daha karmaşık kalıplar. Video oluşturucu bu ideal kalıba ne kadar yaklaşırsa, kullanıcının bir oynatmayı sorunsuz olarak algılama olasılığı o kadar yüksek olur.
Çoğu Chromium platformu kare kare oluştursa da tümü çalışmaz. Genişletilebilir mimarimiz, toplu işleme de olanak tanır. Toplu oluşturma, işletim sistemi düzeyindeki birleştiriciye birden fazla karenin önceden bildirildiği ve bunları, uygulama tarafından sağlanan bir zamanlama programında serbest bırakan bir verimlilik tekniğidir.
Gelecek şimdi var mı?
Chromium'un, sınıfının en iyisi oynatma deneyimi sunmak için işletim sistemi temel öğelerinden nasıl yararlandığına odaklandık. Peki ya temel video oynatmanın ötesine geçmek isteyen web siteleri? Onlara, Chromium'un kendisinin yeni nesil web içeriği sağlamak için kullandığı güçlü temel öğelerin aynısını sunabilir miyiz?
Cevabın evet olduğunu düşünüyoruz! Bugünlerde web platformu düşüncemizin temelinde genişletilebilirlik yer alıyor. WebGPU ve WebCodecs gibi yeni teknolojiler oluşturmak için diğer tarayıcılar ve geliştiricilerle birlikte çalışıyoruz. Böylece web geliştiricileri, Chromium'un işletim sistemiyle konuşurken kullandığı temel öğeleri kullanabiliyor. WebGPU, GPU arabellekleri için destek sunar. WebCodecs, daha önce bahsedilen yer paylaşımı ve GPU arabellek sistemleriyle uyumlu olan temel platform kodlarını çözme ve temel kodlama işlemleri sağlar.
Yayın sonu
Okuduğunuz için teşekkür ederiz! Umarım modern oynatma sistemlerini ve Chromium'un her gün birkaç yüz milyon saatlik izlenme süresini nasıl desteklediğini daha iyi anlamışsınızdır. Codec'ler ve modern web videosu hakkında daha fazla bilgi edinmek istiyorsanız Sid Bala'nın H.264 is hedefli kitabını, Erica Beaves'in How Modern Video Players Works'ü ve Cyril Concolato'nun ödüllü teknolojiyle ödüllü şovlarını sunma'yı okumanızı öneririz.
Una Kravets'ten bir çizim (güzel resim).