Saya Dale Curtis, pemimpin teknik untuk pemutaran media di Chromium. Tim kami bertanggung jawab atas API antarmuka web untuk pemutaran video seperti MSE dan WebCodecs, serta internal khusus platform yang terlibat dalam demuxing, decoding, serta rendering audio dan video.
Dalam artikel ini, saya akan menjelaskan arsitektur rendering video Chromium. Meskipun beberapa detail seputar ekstensibilitas kemungkinan khusus untuk Chromium, sebagian besar konsep dan desain yang dibahas di sini berlaku untuk mesin rendering lain dan bahkan aplikasi pemutaran native.
Arsitektur pemutaran Chromium telah berubah secara signifikan dari tahun ke tahun. Meskipun kami tidak memulai dengan ide piramida kesuksesan seperti yang dijelaskan dalam postingan pertama dalam rangkaian ini, kami akhirnya mengikuti langkah-langkah yang serupa: keandalan, performa, lalu ekstensibilitas.
Pada awal, rendering video cukup sederhana—hanya loop for yang memilih software yang mendekode frame video yang akan dikirim ke compositor. Selama bertahun-tahun, performa dan efisiensi ini cukup dapat diandalkan, tetapi seiring dengan semakin kompleksnya web, kebutuhan akan performa dan efisiensi yang lebih tinggi menyebabkan perubahan arsitektur. Banyak peningkatan memerlukan primitif khusus OS; sehingga, arsitektur kami juga harus lebih diperluas untuk menjangkau semua platform Chromium.
Rendering video dapat dibagi menjadi dua langkah: memilih apa yang akan dikirimkan dan mengirim informasi tersebut secara efisien. Agar mudah dibaca, saya akan membahas penayangan yang efisien sebelum mendalami cara Chromium memilih konten yang akan ditayangkan.
Beberapa istilah dan tata letak
Karena artikel ini berfokus pada rendering, saya hanya akan sedikit membahas aspek demuxing dan decoding pipeline.
Proses decoding dan demuxing di dunia modern yang sadar akan keamanan memerlukan sedikit kehati-hatian. Parser biner adalah lingkungan target yang lengkap, dan pemutaran media penuh dengan penguraian biner. Dengan demikian, masalah keamanan di parser media sangat umum terjadi.
Chromium mempraktikkan pertahanan secara mendalam untuk mengurangi risiko masalah keamanan bagi pengguna kami. Dalam praktiknya, hal ini berarti demuxing dan decoding software selalu terjadi dalam proses dengan hak istimewa rendah, sedangkan decoding hardware terjadi dalam proses yang hanya memiliki cukup hak istimewa untuk berkomunikasi dengan GPU sistem.
Mekanisme komunikasi lintas proses Chromium disebut Mojo. Meskipun kami tidak akan membahas detail Mojo dalam artikel ini, sebagai lapisan abstraksi di antara proses, mojo adalah landasan pipeline media yang dapat diperluas Chromium. Penting untuk mengetahui hal ini saat kita berjalan melalui pipeline pemutaran karena menginformasikan orkestrasi kompleks komponen lintas proses yang berinteraksi untuk menerima, demux, mendekode, dan akhirnya menampilkan media.
Begitu banyak bit
Untuk memahami pipeline rendering video saat ini, diperlukan pengetahuan tentang alasan video itu istimewa: bandwidth. Pemutaran beresolusi 3840x2160 (4K) pada kecepatan 60 frame per detik menggunakan bandwidth memori antara 9-12 gigabit/detik. Meskipun sistem modern memiliki bandwidth puncak hingga ratusan gigabit per detik, pemutaran video masih cukup banyak dilakukan. Tanpa hati-hati, total bandwidth dapat dengan mudah berlipat ganda karena adanya salinan atau perjalanan antara memori GPU dan CPU.
Tujuan mesin pemutaran video modern apa pun dengan mempertimbangkan efisiensi adalah untuk meminimalkan bandwidth antara decoder dan langkah rendering akhir. Karena alasan ini, rendering video sebagian besar dipisahkan dari pipeline rendering utama Chromium. Secara khusus, dari perspektif pipeline rendering utama, video hanyalah lubang berukuran tetap dengan opasitas. Chromium mencapai hal ini menggunakan konsep yang disebut platform—di mana setiap video berkomunikasi langsung dengan Viz.
Karena komputasi seluler populer, daya dan efisiensi telah menjadi fokus yang signifikan pada generasi saat ini. Akibatnya, decoding dan rendering kini makin terkoneksi pada level hardware, sehingga video terlihat seperti lubang dengan opasitas, bahkan pada OS itu sendiri. Decoder tingkat platform sering kali hanya menyediakan buffer buram yang diteruskan Chromium ke sistem komposisi tingkat platform dalam bentuk overlay.
Setiap platform memiliki bentuk overlay sendiri yang digunakan bersama API decoding platform mereka. Windows memiliki Direct Composition dan Media Foundation Transforms, macOS memiliki CoreAnimation Layers dan VideoToolbox, Android memiliki SurfaceView dan MediaCodec, serta Linux memiliki VASurfaces dan VA-API. Abstraksi Chromium untuk konsep ini ditangani oleh antarmuka OverlayProcessor dan mojo::VideoDecoder.
Dalam beberapa kasus, buffer ini dapat dipetakan ke dalam memori sistem, sehingga tidak perlu menjadi buram dan tidak menghabiskan bandwidth apa pun hingga diakses—Chromium memanggil GpuMemoryBuffers ini. Di Windows, buffer ini didukung oleh buffer DXGI, IOSurfaces macOS, AHardwareBuffers Android, dan buffer DMA Linux. Meskipun pemutaran video umumnya tidak memerlukan akses ini, buffer ini penting untuk perekaman video guna memastikan bandwidth yang minimal antara perangkat perekam dan encoder akhir.
Karena GPU sering kali bertanggung jawab atas decoding dan penayangan, penggunaan buffer buram (yang juga sering kali) ini memastikan bahwa data video bandwidth tinggi tidak pernah benar-benar keluar dari GPU. Seperti yang telah kita bahas sebelumnya, menyimpan data di GPU sangat penting untuk efisiensi; terutama pada resolusi dan kecepatan frame tinggi.
Semakin banyak kita memanfaatkan primitif OS seperti overlay dan buffer GPU, semakin sedikit bandwidth yang digunakan untuk mengacak byte video yang tidak perlu. Menyimpan semuanya di satu tempat mulai dari mendekode hingga proses rendering dapat menghasilkan efisiensi daya yang luar biasa. Misalnya, saat Chromium mengaktifkan overlay di macOS, konsumsi daya selama pemutaran video layar penuh akan berkurang setengahnya. Di platform lain seperti Windows, Android, dan ChromeOS, kita dapat menggunakan overlay bahkan dalam kasus yang bukan layar penuh, sehingga menghemat hingga 50% hampir di mana saja.
Rendering
Setelah membahas mekanisme penayangan yang optimal, kita dapat membahas cara Chromium memilih konten yang akan ditayangkan. Stack pemutaran Chromium menggunakan arsitektur berbasis "pull", yang berarti setiap komponen dalam stack meminta inputnya dari komponen di bawahnya dalam urutan hierarki. Bagian atas stack adalah rendering frame audio dan video, yang berikutnya adalah decoding, diikuti dengan demuxing, dan terakhir I/O. Setiap frame audio yang dirender memajukan jam yang digunakan untuk memilih frame video untuk rendering jika digabungkan dengan interval presentasi.
Di setiap interval presentasi (setiap pembaruan layar), perender video diminta untuk memberikan frame video oleh CompositorFrameSink yang dilampirkan ke SurfaceLayer yang disebutkan sebelumnya. Untuk konten dengan kecepatan frame kurang dari kecepatan tampilan, itu berarti menampilkan frame yang sama lebih dari sekali, sedangkan jika kecepatan frame lebih besar dari kecepatan tampilan, beberapa frame tidak akan pernah ditampilkan.
Masih banyak lagi yang dapat dilakukan terkait sinkronisasi audio dan video dengan cara yang menyenangkan bagi pemirsa. Lihat Project Butter untuk diskusi lebih panjang tentang cara mengoptimalkan kelancaran video di Chromium. Bagian ini menjelaskan bagaimana rendering video dapat dipecah menjadi urutan ideal yang menggambarkan berapa kali setiap frame harus ditampilkan. Misalnya: "1 frame setiap interval tampilan ([1], 60 fps dalam 60 Hz)", "1 frame setiap 2 interval ([2], 30 fps dalam 60 Hz)", atau pola yang lebih rumit seperti [2:3:2:3:2] (25 fps dalam 60 Hz) yang mencakup beberapa frame dan interval tampilan yang berbeda. Semakin dekat perender video sesuai dengan pola ideal ini, semakin besar kemungkinan pengguna menganggap pemutaran berjalan lancar.
Meskipun sebagian besar platform Chromium merender per frame, tidak semuanya melakukannya. Arsitektur kami yang dapat diperluas juga memungkinkan rendering dalam batch. Rendering batch adalah teknik efisiensi dengan compositor tingkat OS diberi tahu tentang beberapa frame di awal dan menangani rilis pada jadwal waktu yang disediakan aplikasi.
Masa depan itu sekarang?
Kami telah berfokus pada cara Chromium memanfaatkan OS primitif untuk memberikan pengalaman pemutaran terbaik di kelasnya. Namun, bagaimana dengan situs web yang ingin melakukan lebih dari sekadar pemutaran video biasa? Bisakah kita menawarkan kepada mereka primitif canggih yang sama dengan yang digunakan Chromium untuk mengantarkan konten web generasi berikutnya?
Menurut kami jawabannya adalah ya! Ekstensibilitas adalah inti pandangan kami tentang platform web saat ini. Kami telah bekerja sama dengan browser dan developer lain untuk membuat teknologi baru seperti WebGPU dan WebCodecs sehingga developer web dapat menggunakan versi dasar yang sama seperti Chromium saat berkomunikasi dengan OS. WebGPU menghadirkan dukungan untuk buffer GPU dan WebCodecs menghadirkan primitif encoding dan decoding platform yang kompatibel dengan sistem buffer GPU dan overlay yang disebutkan di atas.
Akhir streaming
Terima kasih sudah membaca. Semoga Anda telah mendapatkan pemahaman yang lebih baik tentang sistem pemutaran modern dan bagaimana Chromium mendukung ratusan juta jam waktu tonton setiap hari. Jika Anda mencari bacaan lebih lanjut tentang codec dan video web modern, sebaiknya H.264 is magic oleh Sid Bala, How Modern Video Players Work oleh Erica Beaves, dan Mengemas acara pemenang penghargaan dengan teknologi pemenang penghargaan oleh Cyril Concolato.
Satu ilustrasi (yang indah!) oleh Una Kravets.