Codec video mana (tidak) yang digunakan browser untuk panggilan video?

Permintaan dukungan teknis khas Voximplant: "Mengapa panggilan video antara dua Chrome terlihat lebih baik daripada panggilan video antara MS Edge dan aplikasi iOS asli?" Kolega biasanya merespons netral - "karena codec." Tapi kami, orang-orang IT, penasaran. Sekalipun saya tidak mengembangkan Skype-for-web baru, membaca “browser apa yang bisa” dan bagaimana mereka membagi satu video menjadi beberapa aliran kualitas berbeda memperkaya gambaran dunia dan memberikan topik baru untuk diskusi di ruang merokok. Berhasil memunculkan artikel dari kalangan luas yang dikenal luas oleh Dr. Alex (dengan penjelasan terbaik tentang istilah "mesin media" dari semua yang saya lihat), sedikit pengalaman kami, beberapa malam di "Dial" - dan terjemahan yang disesuaikan untuk Habr menunggu di bawah potongan!

Codec dan Lebar Saluran

Ketika berbicara tentang video codec, paling sering mereka membahas keseimbangan kualitas dan lebar saluran yang digunakan. Dan mereka suka mengabaikan masalah beban prosesor dan cara mentransmisikan video secara teknis. Cukup masuk akal jika kita membahas encoding dari video yang sudah direkam.

Lagi pula, jika Anda memiliki video selesai, maka tidak ada banyak perbedaan, itu akan memampatkan beberapa menit, beberapa jam atau bahkan beberapa hari. Biaya prosesor dan memori apa pun akan dibenarkan, karena ini adalah investasi satu kali, dan kemudian Anda dapat mendistribusikan video ke jutaan pengguna. Codec video terbaik memampatkan video dalam beberapa lintasan:

1. Lulus # 1: Video dibagi menjadi beberapa bagian dengan fitur-fitur umum: aksi berlangsung pada latar yang sama, adegan cepat atau lambat, dan sejenisnya.
2. Pass # 2: Kumpulkan statistik untuk pengkodean dan informasi tentang bagaimana frame berubah dari waktu ke waktu (untuk mendapatkan informasi seperti itu, Anda memerlukan beberapa frame).
3. Lulus No. 3: Setiap bagian dikodekan dengan pengaturan codec sendiri dan menggunakan informasi yang diperoleh pada langkah kedua.

Streaming adalah masalah yang sangat berbeda. Tidak ada yang akan menunggu sampai akhir podcast, streaming, atau pertunjukan sebelum mulai menyandikan video. Enkode dan kirim segera. Ikutilah dan arahkan bahwa penundaan minimum menjadi yang terpenting.

Saat menggunakan media fisik, disk DVD atau Blu-ray, ukuran video tetap dan codec dihadapkan pada tugas untuk memastikan kualitas maksimum untuk ukuran yang diberikan. Jika video didistribusikan melalui jaringan, maka tugas codec adalah menyiapkan file tersebut untuk mendapatkan kualitas maksimum dengan lebar saluran tetap atau lebar saluran minimum dengan kualitas tetap, jika Anda perlu mengurangi harga. Dalam hal ini, keterlambatan jaringan dapat diabaikan dan disangga di sisi klien selama beberapa detik video yang diperlukan. Tetapi untuk streaming, tidak ada kebutuhan khusus untuk memperbaiki ukuran atau kualitas, codec memiliki tugas yang berbeda: untuk mengurangi penundaan dengan biaya berapa pun.

Akhirnya, pembuat codec untuk waktu yang lama hanya mengingat satu kasus penggunaan: pada komputer pengguna, satu dan hanya satu video diputar. Terlebih lagi, hampir selalu dapat diterjemahkan oleh kekuatan chip video. Lalu ada platform seluler. Dan kemudian WebRTC, untuk memastikan latensi minimum yang pengembang benar-benar ingin menggunakan server Unit Penerusan Selektif.

Penggunaan codec untuk panggilan video sangat berbeda dari penggunaan tradisional ketika memutar video yang membandingkan codec "langsung" menjadi sia-sia. Ketika VP8 dan H.264 dibandingkan pada awal WebRTC, salah satu diskusi terpanas adalah tentang pengaturan codec: menjadikannya "realistis" dengan jaringan yang tidak dapat diandalkan atau "ideal" untuk kualitas video maksimum. Para pejuang untuk "perbandingan bersih codec" berpendapat dalam semua keseriusan bahwa codec harus dibandingkan tanpa mempertimbangkan packet loss, jitter, dan masalah jaringan lainnya.

Bagaimana dengan codec sekarang?

• H.264 dan VP8 kurang lebih sama dalam hal rasio kualitas video dan lebar saluran yang digunakan;
• H.265 dan VP9 juga secara kasar saling bersesuaian, menunjukkan rata-rata hasil 30% lebih baik dibandingkan dengan codec generasi sebelumnya karena peningkatan beban prosesor sebesar 20%;
• codec AV1 baru, campuran eksplosif dari VP10, daala dan thor, lebih baik dari pada codec generasi sebelumnya sebanyak yang lebih baik dari pendahulunya.

Dan sekarang kejutan: semua orang tidak peduli tentang perbedaan-perbedaan ini ketika datang ke panggilan video dan konferensi video. Yang paling penting adalah bagaimana codec bermain dalam tim dengan seluruh infrastruktur. Pengembang prihatin dengan apa yang disebut dengan istilah media engine baru : bagaimana browser atau aplikasi seluler menangkap video, meng-encode / mendekodekannya, memecahnya menjadi paket RTP dan menangani masalah jaringan (ingat video dari pengalaman kami sebelumnya ? Jadi, media dibandingkan di sana mesin - catatan penerjemah). Jika encoder tidak dapat bekerja dengan penurunan tajam pada lebar saluran atau mempertahankan 20 frame per detik secara stabil, jika decoder tidak dapat bekerja dengan hilangnya satu paket jaringan, lalu apa bedanya seberapa baik codec memampatkan video? Sangat mudah untuk melihat mengapa Google mensponsori penelitian Stanford tentang interaksi terbaik antara codec dan jaringan. Ini adalah masa depan komunikasi video.

Codec dan mesin media: semuanya rumit

Panggilan video dan konferensi video memiliki tugas yang hampir sama dengan media konvensional. Hanya prioritasnya yang benar - benar berbeda:

1. Dibutuhkan 30 frame per detik (kecepatan codec).
2. Butuh 30 frame per detik dengan interaktivitas (penundaan minimum).

Kami juga memiliki internet di antara para peserta, yang kualitasnya hanya bisa kami tebak. Biasanya itu lebih buruk. Oleh karena itu:

1. Anda perlu mengalami perubahan kecil dalam lebar saluran saat pengunjung lain datang ke tempat kerja tersebut.
2. Anda harus setidaknya mengalami perubahan kuat dalam lebar saluran saat pengunjung ini mulai mengunduh torrent.
3. Anda perlu khawatir tentang jitter (penundaan acak antara paket yang diterima, karena mereka tidak bisa hanya menunda, tetapi tiba dengan urutan yang salah di mana mereka dikirim).
4. Perlu khawatir tentang kehilangan paket.

3.1. Tugas utama mesin media

Apa artinya "membutuhkan 30 frame per detik"? Ini berarti bahwa mesin media memiliki 33 milidetik untuk mengambil video dari kamera, suara mikrofon, kompres dengan codec, membaginya menjadi paket RTP, melindungi data yang ditransmisikan (SRTP = RTP + AES) dan mengirimkannya melalui jaringan (UDP atau TCP , dalam sebagian besar kasus, UDP). Semua ini ada di pihak pengirim. Dan di sisi penerima - ulangi dalam urutan terbalik. Karena pengodean biasanya lebih sulit daripada pengodean, sisi pengirim mengalami kesulitan.

Di sisi teknis, tujuan "30 frame per detik" dapat dicapai dengan penundaan. Dan semakin lama penundaan, semakin mudah untuk mencapai tujuan: jika Anda mengkodekan pada sisi pengiriman tidak beberapa frame, tetapi beberapa frame sekaligus, maka Anda dapat secara signifikan menghemat lebar saluran (codec kompres beberapa frame lebih baik dengan menganalisis perubahan di antara mereka semua, dan bukan hanya antara saat ini dan sebelumnya). Pada saat yang sama, penundaan antara menerima aliran video dari kamera dan pengiriman melalui jaringan meningkat secara proporsional dengan jumlah frame buffer, ditambah kompresi menjadi lebih lambat karena perhitungan tambahan. Banyak situs menggunakan trik ini, menyatakan waktu respons antara mengirim dan menerima paket jaringan antara peserta dalam panggilan video. Keterlambatan encoding dan decoding, mereka diam.

Untuk membuat panggilan video terlihat seperti komunikasi pribadi, pembuat layanan komunikasi menolak semua pengaturan dan profil codec yang dapat membuat penundaan. Ternyata degradasi seperti codec modern untuk kompresi frame-by-frame. Pada awalnya, situasi seperti itu memicu penolakan dan kritik dari pengembang codec. Tetapi zaman telah berubah, dan sekarang codec modern sebagai tambahan pada preset tradisional "ukuran minimum" dan "kualitas maksimum" telah menambahkan satu set pengaturan "waktu nyata". Dan pada saat yang sama, "berbagi layar" juga untuk panggilan video (memiliki spesifikasi sendiri - resolusi besar, gambar yang sedikit berubah, kebutuhan untuk kompresi lossless, jika tidak teks akan mengambang).

3.2. Mesin media dan jaringan publik

Perubahan kecil dalam lebar saluran

Sebelumnya, codec tidak dapat mengubah bitrate: pada awal kompresi, mereka mengambil bitrate target sebagai pengaturan dan kemudian mengeluarkan sejumlah megabyte video per menit. Di masa lalu, panggilan video dan konferensi video adalah banyak jaringan lokal dan bandwidth yang berlebihan. Dan jika ada masalah, nama administrator dipanggil, yang memperbaiki pemesanan lebar saluran di tsiska.

Perubahan evolusi pertama adalah teknologi "bit rate adaptif." Codec memiliki banyak pengaturan yang mempengaruhi bitrate: resolusi video, sedikit penurunan fps dari 30 menjadi 25 frame per detik, kuantisasi sinyal video. Yang terakhir dalam daftar ini adalah "pengerasan" transisi antara warna, sedikit perubahan yang hampir tidak terlihat oleh mata manusia. Lebih sering daripada tidak, "penyetelan" utama untuk bitrate adaptif justru kuantisasi. Dan mesin media memberi tahu codec tentang lebar saluran.

Perubahan besar dalam lebar saluran

Mekanisme bitrate adaptif membantu mesin media untuk melanjutkan penyiaran video dengan perubahan kecil pada lebar saluran. Tetapi jika kolega Anda mulai mengunduh torrent dan saluran yang tersedia dicelupkan dua atau tiga kali, maka bitrate adaptif tidak akan membantu. Resolusi dan frame rate yang menurun akan membantu. Yang terakhir lebih disukai, karena mata kita kurang sensitif terhadap jumlah bingkai per detik daripada resolusi video. Biasanya, codec mulai melewatkan satu atau dua frame, mengurangi frame rate dari 30 menjadi 15, atau bahkan 10.

Detail penting: mesin media akan melewatkan bingkai di sisi pengiriman. Jika kami memiliki konferensi video untuk beberapa peserta atau penyiaran, dan pengirim tidak memiliki masalah jaringan, maka satu "tautan lemah" akan memperburuk kualitas video untuk semua peserta. Dalam situasi ini, sekelompok simulcast membantu (sisi pengirim memberikan beberapa aliran video dengan kualitas yang berbeda sekaligus) dan SFU (Unit Penerusan Selektif, server memberikan setiap peserta konferensi video atau menyiarkan aliran kualitas yang diinginkan). Beberapa codec memiliki kemampuan untuk membuat beberapa streaming simulcast, SVC yang saling melengkapi: klien dengan saluran terlemah diberikan aliran kualitas minimum, klien dengan saluran yang lebih baik diberi aliran yang sama ditambah yang pertama kemudian "upgrade", klien dengan saluran yang lebih baik diberikan sudah dua aliran "upgrade" dan sebagainya. Metode ini memungkinkan Anda untuk tidak mentransfer data yang sama ke beberapa stream dan menyimpan sekitar 20% dari lalu lintas dibandingkan dengan encoding beberapa stream video yang lengkap. Ini juga menyederhanakan operasi server - tidak perlu beralih aliran, cukup untuk tidak mentransfer paket dengan "upgrade" ke klien. Namun demikian, setiap codec dapat digunakan untuk siaran langsung, itu adalah fitur dari mesin media dan organisasi paket RTP, bukan codec.

Jitter dan paket loss

Kerugian adalah yang paling sulit dihadapi. Jitter sedikit lebih sederhana - buat buffer di sisi penerima untuk mengumpulkan paket yang terlambat dan bingung. Buffer tidak terlalu besar, jika tidak, Anda dapat merusak realtime dan menjadi video YouTube penyangga.

Paket loss biasanya diperjuangkan dengan re-forwarding (RTX). Jika pengirim memiliki komunikasi yang baik dengan SFU, maka server dapat meminta paket yang hilang, mengambilnya dan masih memenuhi 33 milidetik. Jika koneksi jaringan tidak dapat diandalkan (kehilangan paket lebih dari 0,01%), maka kita membutuhkan algoritme kerja loss yang kompleks, seperti FEC .

Solusi terbaik sejauh ini adalah menggunakan codec SVC. Dalam hal ini, untuk menerima setidaknya beberapa video, hanya paket "referensi" dengan aliran kualitas minimum yang diperlukan, paket ini lebih sedikit, oleh karena itu lebih mudah untuk mengirimnya kembali, ini cukup untuk "bertahan" bahkan dengan jaringan yang sangat buruk (lebih dari 1% kehilangan paket). Jika Simulcast + SFU memungkinkan Anda menangani penurunan saluran, maka Simulcast dengan bantuan SVC codec + SFU memecahkan masalah lebar saluran dan paket yang hilang.

Apa yang didukung browser sekarang

Firefox dan Safari menggunakan Mesin Media Google dan memperbarui libwebrtc dari waktu ke waktu. Mereka melakukannya jauh lebih jarang daripada Chrome, versi baru yang dirilis setiap 6 minggu. Dari waktu ke waktu, mereka mulai jauh tertinggal, tetapi kemudian melakukan sinkronisasi lagi. Dengan pengecualian dukungan untuk codec VP8 di Safari. Jangan tanya.

Sebelum kat, meja dengan perbandingan lengkap tentang siapa yang mendukung apa, tetapi secara umum, semuanya cukup sederhana. Edge biasanya diabaikan oleh semua orang. Pilihannya adalah antara mendukung versi seluler Safari dan kualitas video yang bagus. iOS Safari hanya mendukung codec video H.264, sementara libwebrtc hanya memungkinkan simulcast dengan codec VP8 (stream berbeda dengan frame rate berbeda) dan VP9 (dukungan SVC). Tetapi Anda dapat membaca dan menggunakan libwebrtc di iOS dengan membuat aplikasi asli. Kemudian, dengan siaran langsung, semuanya akan baik-baik saja dan pengguna akan menerima kualitas video setinggi mungkin dengan koneksi internet yang tidak stabil. Beberapa contoh:

• Highfive - aplikasi desktop pada Electron (Chromium) dengan H.264 simulcast (libwebrtc) dan codec suara dari Dolby;
• Attlasian - Sebuah solusi menarik oleh klien pada React Native dan libwebrtc untuk simulcast;
• Symphony - Elektron untuk desktop, React Native untuk perangkat mobile, dan simulcast didukung di sana dan di sana + fitur keamanan tambahan yang kompatibel dengan apa yang diinginkan bank;
• Tokbox - VP8 dengan simulcast di SDK seluler, gunakan versi tambalan libvpx di libwebrtc.

Masa depan

Sudah jelas bahwa tidak akan ada VP8 dan VP9 di Safari (tidak seperti Edge, yang didukung VP8).

Meskipun Apple mendukung dimasukkannya H.265 di WebRTC, berita terbaru dan sejumlah tanda tidak langsung menunjuk ke AV1 sebagai "hal besar berikutnya". Tidak seperti artikel lainnya, ini adalah pendapat pribadi saya. Spesifikasi untuk transmisi data AV1 sudah siap, tetapi pekerjaan masih berlangsung pada codec. Sekarang implementasi referensi dari encoder menunjukkan 0,3 frame sedih per detik. Ini bukan masalah saat memutar konten pra-kompresi, tetapi belum berlaku untuk Komunikasi Realtime. Sementara itu, Anda dapat mencoba memutar video AV1 di Firefox, meskipun ini tidak terkait dengan RTC. Implementasi dari tim bitmovin, yang mengembangkan MPEG-DASH dan menerima 30 juta investasi dalam penciptaan infrastruktur generasi berikutnya untuk bekerja dengan video.