Ben Dale Curtis. Chromium'da medya oynatma için mühendislik yöneticisiyim. Ekibim, video oynatma için web'e yönelik API'lerden (ör. MSE ve WebCodecs) ve ses ile videonun kanallara ayrılması, kodunun çözülmesi ve oluşturulmasıyla ilgili platforma özgü dahili öğelerden sorumludur.
Bu makalede, Chromium'un video oluşturma mimarisini adım adım açıklayacağız. Genişletilebilirlikle ilgili bazı ayrıntılar muhtemelen Chromium'a özgü olsa da burada ele alınan 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 serinin ilk gönderisinde açıklanan başarı piramidi fikriyle başlamasak da sonunda benzer adımları izledik: güvenilirlik, performans ve ardından genişletilebilirlik.
Başlangıçta video oluşturma işlemi oldukça basitti. Sadece bir for döngüsü, video karelerinin kodunun çözülmesini sağlayarak bunları birleştiriciye gönderiyordu. Bu yöntem yıllarca yeterince güvenilirdi ancak web'in karmaşıklığı arttıkça daha fazla performans ve verimlilik ihtiyacı mimari değişikliklere yol açtı. Birçok iyileştirme, işletim sistemine özgü primitifler gerektiriyordu. Bu nedenle, Chromium'un tüm platformlarına ulaşmak için mimarimizin de daha genişletilebilir hale gelmesi gerekiyordu.
Video oluşturma işlemi iki adıma ayrılabilir: neyi sunacağınızı seçme ve bu bilgileri verimli bir şekilde sunma. Okunabilirliği artırmak için Chromium'un neyi yayınlayacağını nasıl seçtiğine geçmeden önce verimli yayınlamayı ele alacağım.
Bazı terimler ve düzen
Bu makale oluşturmaya odaklandığından, ardışık düzen çözme ve kod çözme özelliklerine yalnızca kısaca değineceğim.
Güvenlik bilinciyle hareket ettiğimiz modern dünyada kod çözme ve çoklu yayın çözme işlemleri oldukça dikkatli bir şekilde yapılmalıdır. İkili ayrıştırıcılar zengin hedef ortamlardır ve medya oynatma, ikili ayrıştırma ile doludur. Bu nedenle, medya ayrıştırıcılarındaki güvenlik sorunları son derece yaygındır.
Chromium, kullanıcılarımızın güvenlik sorunlarıyla karşılaşma riskini azaltmak için derinlemesine savunma uygular. Pratikte bu, çoklu akış ayırma ve yazılım kod çözme işlemlerinin her zaman düşük ayrıcalıklı bir işlemde gerçekleştiği, donanım kod çözme işleminin ise yalnızca sistemin GPU'suyla iletişim kurmaya yetecek kadar ayrıcalığa sahip bir işlemde gerçekleştiği anlamına gelir.
Chromium'un işlemler arası iletişim mekanizmasına Mojo adı verilir. Bu makalede Mojo'nun ayrıntılarına girmeyeceğiz. Ancak Mojo, işlemler arasındaki soyutlama katmanı olarak Chromium'un genişletilebilir medya ardışık düzeninin temel taşıdır. Medyayı almak, kod çözmek, kodlarını kaldırmak ve son olarak görüntülemek için etkileşimde bulunan işlemler arası bileşenlerin karmaşık orkestrasyonunu bilgilendirdiği için oynatma ardışık düzeninde ilerlerken bu durumun farkında olmak önemlidir.
Çok fazla bit
Günümüzde video oluşturma ardışık düzenlerini anlamak için videonun neden özel olduğunu (bant genişliği) bilmeniz gerekir. Saniyede 60 kare hızında 3840x2160 (4K) çözünürlükte oynatma, saniyede 9-12 gigabit bellek bant genişliği kullanır. Modern sistemlerin saniye başına yüzlerce gigabitlik tepe bant genişliği olsa da video oynatma, önemli bir kısmı hâlâ temsil etmektedir. Dikkatli olmazsanız GPU ile CPU belleği arasındaki kopyalar veya geziler nedeniyle toplam bant genişliği kolayca katlanabilir.
Verimliliği göz önünde bulunduran 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 işlemi büyük ölçüde Chromium'un ana oluşturma ardışık düzeninden ayrılmıştır. Özellikle ana oluşturma ardışık düzenimiz açısından video, yalnızca opaklığı sabit olan sabit boyutlu bir deliktir. Chromium bunu, her videonun doğrudan Viz ile iletişim kurduğu yüzeyler adlı bir kavram kullanarak başarır.
Mobil bilgi işlemin popülerliği nedeniyle, güç ve verimlilik mevcut nesilde önemli bir odak noktası haline geldi. Bunun sonucunda, kod çözme ve oluşturma işlemleri donanım düzeyinde her zamankinden daha fazla birbirine bağlanır. Bu da videonun işletim sistemi tarafından bile opaklığa sahip bir delik gibi görünmesine neden olur. Platform düzeyinde kod çözücüler genellikle yalnızca Chromium'un platform düzeyinde birleştirme sistemine yer paylaşımı biçiminde ilettiği opak arabellekler sağlar.
Her platformun, platform kod çözme API'lerinin uyumlu şekilde çalıştığı kendi yer paylaşımı biçimi vardır. Windows'ta Doğrudan Oluşturma ve Medya Vakfı Dönüşümleri, macOS'te CoreAnimation Katmanları ve VideoToolbox, Android'de SurfaceView ve MediaCodec, Linux'ta VASurfaces ve VA-API bulunur. Chromium'un bu kavramlar için soyutlamaları sırasıyla OverlayProcessor ve mojo::VideoDecoder arayüzleri tarafından işlenir.
Bazı durumlarda bu arabelleklerin sistem belleğine eşlenebilmesi mümkündür. Bu durumda, opak olmalarına bile gerek yoktur ve erişilene kadar bant genişliği tüketmezler. Chromium bu arabelleklere GpuMemoryBuffers adını verir. Windows'ta bunlar DXGI arabellekleriyle, macOS'te IOSurfaces ile, Android'de AHardwareBuffers ile ve Linux'ta DMA arabellekleriyle desteklenir. Video oynatma için genellikle bu erişime gerek olmasa da yakalama cihazı ile olası kodlayıcılar arasında minimum bant genişliği sağlamak amacıyla video yakalama için bu arabellekler önemlidir.
GPU genellikle hem kod çözme hem de görüntüleme işlemlerinden sorumlu olduğundan, bu (genellikle opak) arabelleklerin kullanılması, yüksek bant genişliğine sahip video verilerinin hiçbir zaman GPU'dan ayrılmamasını sağlar. Daha önce de belirttiğimiz gibi, verileri GPU'da tutmak, özellikle yüksek çözünürlüklerde ve kare hızlarında verimlilik açısından son derece önemlidir.
Yer paylaşımları ve GPU arabellekleri gibi OS primitiflerinden ne kadar çok yararlanabilirsek video baytlarını gereksiz yere aktarmak için o kadar az bant genişliği harcarız. Kod çözme işleminden oluşturmaya kadar her şeyi tek bir yerde tutmak, inanılmaz bir 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ı yarıya azaldı. Windows, Android ve ChromeOS gibi diğer platformlarda, tam ekran olmayan durumlarda bile yer paylaşımlarını kullanabiliriz. Bu sayede neredeyse her yerde% 50'ye varan oranda tasarruf sağlayabiliriz.
Oluşturma
Optimum yayınlama mekanizmalarını ele aldığımıza göre, Chromium'un neyi yayınlayacağını nasıl seçtiğinden bahsedebiliriz. Chromium'un oynatma yığınında "çekme" tabanlı bir mimari kullanılır. Bu, yığıntaki her bileşenin girişlerini hiyerarşik sırayla altındaki bileşenden istediği anlamına gelir. Yığının en üstünde ses ve video karelerinin oluşturulması, bir sonraki sırada kod çözme, ardından çoklu oynatma çözme ve son olarak G/Ç yer alır. Oluşturulan her ses karesi, bir sunum aralığıyla birlikte kullanıldığında oluşturma için video karelerini seçmek üzere kullanılan bir saati ileri götürür.
Her bir sunum aralığında (ekranın her yeniden yenilenmesi), daha önce bahsedilen SurfaceLayer'a bağlı bir CompositorFrameSink tarafından video oluşturma aracından video karesi sağlaması istenir. Kare hızı, görüntüleme hızından düşük olan içeriklerde aynı kare birden fazla kez gösterilir. Kare hızı görüntüleme hızından yüksekse bazı kareler hiç gösterilmez.
Ses ve videoyu izleyicilerin hoşuna gidecek şekilde senkronize etmenin çok daha fazla yolu vardır. Chromium'da optimum video akıcılığının nasıl sağlandığıyla ilgili daha ayrıntılı bir tartışma için Project Butter başlıklı makaleyi inceleyin. Video oluşturmanın, her bir karenin kaç kez gösterileceğini temsil eden ideal sekanslara nasıl bölünebileceğini açıklar. Örneğin: "Her görüntüleme aralığında 1 kare ([1], 60 Hz'de 60 fps)", "2 aralıkta 1 kare ([2], 60 Hz'de 30 fps)" veya birden fazla farklı kare ve görüntüleme aralığını kapsayan [2:3:2:3:2] (60 Hz'de 25 fps) gibi daha karmaşık desenler. Bir video oluşturma aracı bu ideal kalıba ne kadar yakınsa kullanıcının oynatmayı akıcı olarak algılama olasılığı o kadar yüksektir.
Çoğu Chromium platformu kare kare oluşturma işlemi gerçekleştirse de hepsi bunu yapmaz. Genişletilebilir mimarimiz toplu oluşturma işlemine de olanak tanır. Toplu oluşturma, OS düzeyindeki derleyiciye birden fazla karenin önceden bildirildiği ve bunların uygulama tarafından sağlanan bir zamanlama planında yayınlanmasını sağlayan bir verimlilik tekniğidir.
Gelecek şimdi mi?
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, temel video oynatma özelliğinin ötesine geçmek isteyen web siteleri ne olacak? Chromium'un yeni nesil web içeriklerini kullanıma sunmak için kullandığı güçlü temel öğeleri onlara sunabilir miyiz?
Cevap evet. Genişletilebilirlik, günümüzde web platformu hakkındaki düşüncelerimizin merkezinde yer alıyor. Web geliştiricilerin OS ile iletişim kurarken Chromium'un kullandığı temel öğeleri kullanabilmesi için WebGPU ve WebCodecs gibi yeni teknolojiler oluşturmak amacıyla diğer tarayıcılar ve geliştiricilerle birlikte çalışıyoruz. WebGPU, GPU arabellekleri için destek sağlar. WebCodecs ise yukarıda belirtilen yer paylaşımı ve GPU arabellek sistemleriyle uyumlu platform kod çözme ve kodlama primitifleri sunar.
Akış sonu
Bu e-postayı okuduğunuz için teşekkür ederiz. Modern oynatma sistemlerini ve Chromium'un her gün yüz milyonlarca saatlik izlenme süresini nasıl desteklediğini daha iyi anladığınızı umuyoruz. Kodekler ve modern web videoları hakkında daha fazla okumak istiyorsanız Sid Bala'nın H.264 is magic (H.264 Sihirlidir), Erica Beaves'in How Modern Video Players Work (Modern Video Oynatıcıların İşleyiş Şekli) ve Cyril Concolato'nun Packaging award-winning shows with award-winning technology (Ödüllü programları ödüllü teknolojiyle paketleme) kitaplarını öneririz.
Una Kravets tarafından çizilen bir resim (güzel olan!).