Seberapa Baik Perkongsian Skrin WebRTC, Betulkah? Saya Menguji 4 Codec

Saya sentiasa ingin tahu tentang bagaimana codec yang berbeza disusun apabila ia berkaitan dengan perkongsian skrin melalui WebRTC. Jadi, saya memutuskan untuk mengetahui sendiri dengan menguji empat yang paling biasa: VP8, VP9, H.264 dan AV1. Untuk memastikan keputusannya kukuh, saya menjalankan ujian merentasi pelbagai jenis kandungan dan keadaan rangkaian. Saya tidak hanya bergantung pada tera visual - saya menggunakan perbandingan bingkai demi bingkai, mengira Nisbah Isyarat-ke-Bunyi Puncak (PSNR) dan menarik statistik WebRTC terperinci untuk mendapatkan paparan dipacu data yang jelas. Untuk melangkah lebih jauh, saya juga membina pemalam Chrome tersuai yang menjejaki penggunaan CPU semasa pengekodan dan penyahkodan. Itu memberi saya pandangan yang baik tentang cara setiap codec mempengaruhi prestasi sistem - kerana kualitinya bagus, tetapi tidak jika komputer anda terbakar cuba untuk bersaing. Saya melihat metrik utama seperti kadar bit, kadar bingkai, resolusi, pengkuantitian (QP), PSNR dan beban CPU. Berdasarkan semua itu, saya menghasilkan beberapa cadangan praktikal untuk membantu sesiapa sahaja yang cuba mengoptimumkan perkongsian skrin WebRTC untuk kes penggunaan mereka sendiri. Mengenai percubaan Mengapa Perkongsian Skrin Tidak Semudah Yang Dilihat Jika anda pernah berkongsi skrin anda semasa panggilan video dan perasan kualiti menurun - atau video menjadi berombak - anda tidak bersendirian. Memastikan perkongsian skrin bersih dan lancar sebenarnya lebih rumit daripada yang kelihatan. Masalahnya? Ini semua tentang kepelbagaian. Sesetengah kandungan masih kekal, seperti dek slaid atau dokumen. Pada masa lain, anda berkongsi video bergerak tinggi. Jenis kandungan yang berbeza ini menuntut perkara yang sangat berbeza daripada codec. Sebagai contoh, video yang bergerak pantas memakan satu tan lebar jalur, manakala imej statik lebih sensitif kepada artifak mampatan yang boleh menjadikannya kelihatan kabur atau tersekat. Lemparkan isu internet dunia sebenar seperti kehilangan paket atau jalur lebar jatuh, dan keadaan menjadi lebih kucar-kacir. Itulah sebabnya memilih codec yang betul - dan memperhalusi cara ia berfungsi - sangat penting untuk menjadikan perkongsian skrin berkualiti tinggi dan responsif. Terdapat banyak penyelidikan di luar sana tentang prestasi codec video dalam senario penstriman umum. Tetapi perkongsian skrin mempunyai ciri tersendiri. Ia bukan hanya tentang menonton video - ia tentang berinteraksi dalam masa nyata dan jenis kandungan ada di mana-mana. Ini bermakna penyelidikan biasa tidak selalu digunakan. Perkara yang Saya Akan Lakukan Saya ingin menggali lebih dalam kes penggunaan khusus ini. Matlamat saya adalah untuk melihat prestasi codec yang berbeza apabila ia berkaitan dengan perkongsian skrin, terutamanya di bawah kekangan dunia sebenar seperti pelbagai jenis kandungan dan keadaan rangkaian yang tidak dapat diramalkan. Untuk melakukan itu, saya mereka kaedah untuk menilai kualiti perkongsian skrin setepat mungkin - bukan hanya berdasarkan rupa ia, tetapi disokong oleh metrik dan data yang kukuh. Sepanjang perjalanan, saya belajar banyak tentang codec yang paling sesuai dan cara memperhalusi sesuatu untuk prestasi yang lebih baik dalam aplikasi masa nyata. Satu perkara menjadi jelas dengan cepat: prestasi perkongsian skrin sangat bergantung pada yang anda kongsi. Video pantas berkelakuan sangat berbeza daripada dokumen statik atau tatal perlahan melalui halaman web. perkara Untuk memastikan perkara yang adil dan konsisten, saya memastikan bahawa setiap ujian dijalankan dengan keadaan yang sama - resolusi yang sama, titik permulaan yang sama dan tempoh yang sama. Dengan cara itu, saya boleh yakin hasilnya adalah mengenai prestasi codec, bukan pembolehubah yang tidak disengajakan. Saya mencipta dua kes ujian berbeza untuk mensimulasikan situasi perkongsian skrin kehidupan sebenar: - Ini adalah klip sebenar penunggang motosikal yang memandu laju melalui hutan. Banyak pergerakan pantas, pemandangan terperinci dan persekitaran visual yang sentiasa berubah - sesuai untuk menolak had pemampatan. Video gerakan tinggi - Saya membina halaman HTML ringkas dengan teks dan imej, kemudian menggunakan JavaScript untuk menatalnya pada kelajuan yang stabil. Ia meniru kes penggunaan biasa seperti berkongsi dokumen atau membaca daripada halaman web. Teks tatal automatik Kedua-dua jenis kandungan ini memberi saya gabungan yang baik untuk menguji cara setiap codec mengendalikan cabaran yang berbeza - daripada mengikuti pergerakan sehingga mengekalkan kejelasan dalam adegan yang lebih statik. Bagaimana Saya Sediakan Segala-galanya Untuk menguji codec dengan betul, saya memerlukan persediaan yang kukuh yang boleh menangkap - kedua-dua perkara yang dihantar dan apa yang diterima. Saya bermula dengan alat yang dipanggil (Dengan cara ini, anda boleh belajar tentang alat ini dan banyak lagi dalam catatan saya yang lain: " "), yang bagus untuk bermain-main dengan dalaman WebRTC. Saya akhirnya mengubahnya sedikit untuk mengendalikan perkongsian skrin dengan lebih baik dan memastikan saya boleh merakam kedua-dua strim video keluar dan masuk. Setiap ujian dijalankan memberi saya dua fail video - satu untuk apa yang dihantar dan satu untuk apa yang diterima - yang saya gunakan kemudian untuk analisis sebelah menyebelah. segala-galanya webrtc-sandbox Mempelajari WebRTC dalam Amalan: Alat dan Demo Terbaik Tetapi saya tidak berhenti pada video. Saya juga ingin menjejaki apa yang berlaku di bawah tudung. Untuk itu, saya menarik statistik WebRTC terperinci terus daripada penyemak imbas Chrome. Statistik ini memberi saya tetingkap tentang prestasi setiap codec dan cara rangkaian simulasi bertindak semasa setiap ujian. Satu bahagian besar teka-teki itu ialah - dan itu ternyata agak rumit. Versi biasa Chrome tidak membenarkan pemalam memantau beban CPU untuk tab individu, jadi saya menggunakan binaan pembangunan penyemak imbas dan menulis pemalam saya sendiri untuk mengatasinya. penggunaan CPU Saya secara khusus menumpukan pada mengukur penggunaan CPU daripada tab yang menghantar atau menerima bahagian skrin. Dengan cara itu, saya mengecualikan tugas pemaparan yang tidak berkaitan daripada bahagian lain penyemak imbas. Memandangkan kedua-dua penghantaran dan penerimaan berlaku dalam tab yang sama, nombor yang saya perolehi adalah paparan gabungan - tetapi masih agak hampir dengan perkara yang anda akan lihat dalam kes penggunaan dunia sebenar. (Spoiler: pengekodan biasanya memukul CPU lebih keras daripada penyahkodan.) Mengumpul Data: 157 Ujian Berlangsung Kemudian... Setelah persediaan telah sedia, tiba masanya untuk menjalankan percubaan sebenar - dan saya menjalankan banyak daripadanya. Saya mengulangi ujian pada mesin yang sama, berulang kali, menggunakan keadaan rangkaian dan tetapan codec yang berbeza untuk melihat bagaimana keadaan bertahan. Secara keseluruhan, saya mengumpul , memastikan setiap gabungan keadaan ujian diwakili dengan baik. 157 mata data Ini memberi saya set data yang kukuh untuk digunakan dan membenarkan beberapa analisis mendalam tentang cara perkongsian skrin berkelakuan dalam WebRTC di bawah senario yang berbeza. Inilah yang saya uji secara khusus: : Saya menggunakan dua jenis kandungan perkongsian skrin untuk menggambarkan kes penggunaan biasa: Jenis Video - Rakaman dunia sebenar dengan banyak piksel mengubah setiap bingkai. Video gerakan tinggi - Kebanyakannya visual statik, tetapi dengan piksel beralih kedudukan semasa teks menatal. Teks yang ditatal secara automatik : Saya menguji empat codec perkongsian skrin paling popular: Codec AV1 H.264 VP8 VP9 : Memandangkan lebar jalur memainkan peranan yang besar dalam kualiti video (terutamanya dalam panggilan video), saya mensimulasikan pelbagai keadaan rangkaian untuk melihat sejauh mana setiap codec mengendalikan lebar jalur yang ketat atau turun naik. Jalur Lebar Rangkaian Dengan mencampurkan dan memadankan pembolehubah ini secara berstruktur, saya dapat meniru senario perkongsian skrin dunia sebenar - jenis yang anda hadapi semasa panggilan video, semasa tunjuk cara langsung atau dalam sesi jauh kerjasama. Membetulkan Gangguan: Cara Saya Menjadikan Ujian Lebih Boleh Dipercayai Seperti kebanyakan percubaan, beberapa larian pertama tidak berjalan lancar seperti yang saya harapkan. Dua masalah utama timbul serta-merta: Pada mulanya, saya memulakan perkongsian skrin secara manual - secara literal mengklik butang untuk memulakan sesuatu. Masalahnya? Hampir mustahil untuk menyegerakkan permulaan rakaman dengan permulaan kandungan video. Ini bermakna setiap ujian dijalankan mempunyai masa yang sedikit berbeza, yang membuang perbandingan. Mula Manual = Masa Berantakan. Walaupun masanya tepat, video masa nyata mempunyai ciri tersendiri. Terima kasih kepada pengekodan, penyahkodan dan kelewatan rangkaian, strim yang dihantar dan diterima tidak pernah berbaris dengan sempurna. Ini menjadikan perbandingan kualiti bingkai demi bingkai hampir mustahil. Dihantar lwn. Diterima = Tidak Segerak. Untuk menyelesaikan isu ini, saya membuat beberapa penambahbaikan utama: : Daripada memulakan semuanya secara manual, saya menulis beberapa kod untuk menyegerakkan permulaan video atau teks menatal dengan proses rakaman. Dengan cara itu, setiap ujian dijalankan pada saat yang sama pada kedua-dua hujung - masalah diselesaikan. Penyegerakan Programmatik : Untuk isu nyahsegerak, saya menambahkan tindanan kod QR kecil pada video yang dikongsi. Penanda kecil ini bertindak seperti cap masa - ia membenarkan saya memadankan bingkai antara strim yang dihantar dan diterima dengan tepat. Tiba-tiba, analisis bingkai demi bingkai menjadi boleh dilakukan (dan lebih tepat). Padanan Bingkai Kod QR Terdapat satu lagi perkara yang perlu saya ambil kira: . Salah satu ciri hebat WebRTC ialah ia melaraskan kualiti video secara automatik berdasarkan lebar jalur yang tersedia. Tetapi pelarasan itu tidak berlaku serta-merta - ia mengambil masa beberapa saat untuk menjadi stabil. Jadi, saya menambah sedikit kelewatan sebelum memulakan rakaman sebenar. Ini memberi masa kepada sistem untuk menyelesaikan pada kadar bit sasaran, jadi hasilnya akan mencerminkan kualiti sebenar yang anda perolehi selepas keadaan menjadi sekata. Kadar bit adaptif WebRTC Perubahan ini menjadikan percubaan lebih dipercayai dan memberi saya keyakinan bahawa data yang saya kumpul sebenarnya menggambarkan cara perkongsian skrin berkelakuan di dunia nyata. Apa yang Saya Ukur (Dan Mengapa Ia Penting) Saya mengumpul banyak data semasa ujian ini, tetapi untuk memastikan perkara yang jelas dan mudah untuk dibandingkan, saya memfokuskan pada beberapa metrik teras yang benar-benar menceritakan kisah tentang prestasi setiap codec dalam senario perkongsian skrin. Inilah yang saya lihat: Kadar Bingkai Ini memberitahu saya bilangan bingkai sesaat yang sebenarnya dikodkan, dihantar dan diterima. Ini adalah penunjuk yang baik tentang kelancaran aliran video - kadar bingkai yang lebih tinggi biasanya bermakna pengalaman yang lebih lancar. Resolusi Resolusi adalah mengenai jumlah butiran visual yang dipelihara. Saya menjejaki bilangan piksel bagi setiap bingkai pada setiap peringkat (dihantar dan diterima) untuk melihat sama ada codec memegang pada kualiti imej atau menjatuhkannya untuk menjimatkan lebar jalur. Kualiti Video Saya menggunakan beberapa metrik utama di sini: – QP yang lebih rendah secara amnya bermaksud kualiti yang lebih baik. Parameter Pengkuantitian (QP) – Ini memberikan gambaran berangka sejauh mana video yang diterima berbeza daripada yang asal. Lebih tinggi = lebih baik. Nisbah Isyarat-ke-Bunyi Puncak (PSNR) Penggunaan CPU Prestasi codec bukan hanya tentang perkara yang anda lihat - ia juga tentang apa yang mesin anda lakukan di sebalik tabir. Saya mengukur berapa banyak kuasa CPU yang digunakan untuk pengekodan dan penyahkodan semasa setiap ujian, dinormalkan dari semasa ke semasa, untuk melihat codec yang ringan dan yang mana merupakan hogs sumber. Dengan memecahkan perkara-perkara dengan metrik ini, saya dapat membandingkan codec bukan sahaja pada kualiti, tetapi juga pada kelancaran, kecekapan dan betapa menuntutnya. Itu membantu mendedahkan di mana setiap codec bersinar - dan di mana ia bergelut - dalam keadaan perkongsian skrin dunia sebenar. Akhirnya sampai ke Keputusan Sejauh manakah Jenis Kandungan Penting? Lebih Banyak Daripada Yang Anda Fikirkan Salah satu perkara yang paling mengejutkan daripada percubaan saya ialah sejauh mana kandungan yang anda kongsi mempengaruhi prestasi perkongsian skrin - baik dari segi kualiti video dan penggunaan sumber. Dan ini benar untuk codec yang saya uji. jenis setiap Idea di sebaliknya agak mudah: apabila lebih banyak piksel berubah dari bingkai ke bingkai (seperti dalam video yang bergerak pantas), sistem perlu bekerja lebih keras. Ini bermakna lebih lebar jalur diperlukan, dan CPU anda perlu bergegas lebih untuk bersaing. Ambil , sebagai contoh. Apabila saya menggunakannya untuk berkongsi skrin 1.5 megapiksel, lebar jalur yang diperlukan berbeza-beza bergantung pada perkara yang dikongsi. Dalam satu kes, di mana kandungannya lebih dinamik, AV1 terpaksa menolak lebih banyak data dengan ketara untuk memastikan aliran lancar. Saya menangkap ini dalam , yang menunjukkan betapa drastik kerumitan kandungan memberi kesan kepada penggunaan lebar jalur. AV1 graf berikut Tetapi ia bukan hanya lebar jalur - perkakasan anda juga merasakannya. menunjukkan cara penggunaan CPU berubah berdasarkan kandungan yang dikongsi. Sekali lagi, menggunakan AV1 sebagai contoh, anda dapat melihat dengan jelas bahawa visual yang lebih kompleks memerlukan lebih banyak kuasa CPU untuk memastikan perkara berjalan pada kadar bingkai dan resolusi yang sama. Graf seterusnya Ini bukan hanya perkara AV1, sama ada. Semua codec bergantung pada prinsip asas yang sama untuk pengekodan dan penyahkodan video, jadi anda menjangkakan mereka menunjukkan tingkah laku yang serupa - tetapi data menceritakan kisah yang berbeza. Muatan CPU bukan sahaja berubah dengan kandungan, ia juga berubah berdasarkan yang anda gunakan. codec Untuk menjadikannya lebih mudah untuk dibandingkan, saya menyusun , yang menunjukkan jumlah CPU yang digunakan oleh setiap codec apabila menstrim video 1.5 megapiksel pada kira-kira 24 bingkai sesaat - persediaan yang agak tipikal untuk perkongsian skrin yang lancar. Hasilnya menyerlahkan beberapa perbezaan utama dalam keberkesanan setiap codec apabila menggunakan perkakasan anda. jadual berikut Codec/CPU AV1 H264 VP8 VP9 gerakan 287% 213% 270% 364% Teks 175% 130% 179% 198% Jadi, jika anda sedang membina atau mengoptimumkan sesuatu yang bergantung pada perkongsian skrin WebRTC, pengambilannya adalah jelas: kandungan anda dan pilihan codec anda penting. banyak. Codec Showdown: Kadar Bingkai, Muatan CPU dan Kos Kualiti Sebenar Apabila bercakap tentang perkongsian skrin, salah satu perkara pertama yang anda perhatikan ialah betapa lancar (atau tidak) video itu. Di situlah masuk. Jika anda berkongsi kandungan bergerak tinggi, seperti main balik video atau animasi, kadar bingkai yang lebih tinggi adalah penting untuk mengelakkan strim berombak dan sukar ditonton. kadar bingkai Untuk bahagian percubaan ini, saya menumpukan pada prestasi kadar bingkai merentas codec yang berbeza sambil memastikan semua yang lain tetap: resolusi yang sama (kira-kira 1.5 megapiksel) dan kandungan yang sama untuk setiap ujian. Saya menggunakan tetapan WebRTC untuk memastikan bahawa resolusi kekal terkunci di seluruh papan. contentHint Dalam , anda boleh melihat cara codec yang berbeza mengendalikan kandungan bergerak tinggi apabila lebar jalur meningkat. Pada paksi-x: kadar bit dalam Mbps. Pada paksi-y: kadar bingkai dalam bingkai sesaat (fps). imej berikut Inilah yang menonjol: dan maju ke hadapan apabila lebar jalur mencecah 2 Mbps atau lebih, kedua-duanya menyampaikan 20+ fps - pengalaman lancar yang boleh dicapai walaupun pada sambungan 3G yang baik. H.264 AV1 dan juga tidak mengikutinya. Mereka berlegar pada kira-kira separuh kadar bingkai di bawah keadaan yang sama, dan benar-benar memerlukan 4 Mbps atau lebih untuk berasa boleh digunakan - yang tidak selalu realistik pada rangkaian yang lebih rendah. VP8 VP9 Kemudian saya beralih kepada - halaman teks yang menatal perlahan - untuk melihat prestasi codec apabila tidak banyak yang berubah antara bingkai. kandungan gerak rendah Tidak mengejutkan, kedua-dua dan melakukan lebih baik dalam senario ini, dengan . Itu adalah terima kasih kepada ciri yang dipanggil , yang membolehkan AV1 melangkau bahagian pengekodan semula skrin yang tidak berubah. Ia amat berkesan untuk perkongsian skrin statik atau separa statik. H.264 AV1 AV1 muncul di atas Intra Block Copy Dalam , anda boleh melihat betapa cekapnya AV1 mengendalikan situasi gerakan rendah ini, mengekalkan penggunaan lebar jalur yang sangat rendah sambil mengekalkan kualiti visual yang tinggi. graf seterusnya Tetapi… ada pertukaran. AV1 mungkin memberi anda visual dan pemampatan yang lebih baik, tetapi . menunjukkan ini dengan jelas: Penggunaan CPU AV1 meningkat secara berterusan apabila kadar bit meningkat, mengatasi H.264 dengan pukulan panjang. H.264 mempunyai kelebihan besar di sini terima kasih kepada yang meluas , yang memastikan beban CPUnya rendah dan stabil. ia juga memakan lebih banyak CPU Imej seterusnya pecutan perkakasan , menariknya, menggunakan CPU daripada AV1 - mengikut arah aliran yang sama tetapi dengan puncak yang lebih tinggi. Kedua-dua VP9 dan AV1 bergantung pada algoritma yang kompleks untuk menyampaikan kualiti yang baik, tetapi ia memerlukan kos: ia adalah pemukul berat pada pemproses anda. VP9 lebih banyak Terdapat kelainan apabila saya menyemak semula . Kali ini, sebenarnya kelihatan agak cekap - menggunakan kurang CPU daripada AV1, seperti yang ditunjukkan dalam . kandungan gerak rendah VP8 dan VP9 graf seterusnya AV1, walaupun direka dengan mengambil kira perkongsian skrin, masih menggunakan CPU yang paling banyak. kenapa? Semua pengoptimuman yang membantunya memampatkan video bergerak tinggi juga menambah overhed - walaupun ketika tidak banyak yang berlaku pada skrin. Alasan besar untuk ini? . Walaupun penyahkodan agak ringan, pengekodan masih kebanyakannya dilakukan dalam perisian - dan itu adalah tugas intensif CPU, terutamanya dalam senario masa nyata seperti perkongsian skrin di mana pengekodan dan penyahkodan berlaku secara berterusan. AV1 masih kekurangan sokongan pengekodan perkakasan yang meluas Di sinilah perkara menjadi rumit untuk seperti komputer riba dan tablet. Tanpa pecutan perkakasan, codec seperti AV1 boleh mengalirkan kuasa dan sumber babi dengan cepat - tidak sesuai apabila anda dalam perjalanan. Sehingga sokongan perkakasan yang lebih baik menjadi lebih biasa, ciri lanjutan AV1 datang dengan kos prestasi yang agak ketara. peranti mudah alih Codec dan Resolusi: Apa yang Berlaku Apabila Anda Mengutamakan Kadar Bingkai? Setakat ini, keputusan yang saya kongsikan datang daripada ujian yang mengekalkan resolusi tetap. Apabila lebar jalur menjadi ketat, sistem akan bertindak balas dengan menurunkan - yang masuk akal untuk perkara seperti kandungan statik atau teks. Tetapi bagaimana jika matlamatnya adalah untuk , walaupun itu bermakna mengorbankan resolusi? kadar bingkai memastikan perkara berjalan lancar Untuk meneroka perkara ini, saya menjalankan satu set percubaan baharu di mana WebRTC telah dikonfigurasikan untuk mengutamakan sebaliknya. Ini dilakukan menggunakan tetapan dalam WebRTC, yang membolehkan anda memberitahu penyemak imbas perkara yang lebih penting - resolusi tinggi atau gerakan lancar. kadar bingkai contentHint Saya berhasrat untuk mengekalkan kadar bingkai pada yang konsisten, yang diiktiraf secara meluas sebagai tempat yang menarik untuk tontonan yang lancar dan selesa. Mendapatkan perkara itu secara konsisten adalah sukar - penstriman adaptif bermakna sentiasa ada sedikit turun naik - tetapi hasilnya menawarkan cerapan berharga tentang cara setiap codec mengendalikan pertukaran ini. 30 fps Untuk membantu menganalisis tingkah laku ini, saya memperkenalkan metrik baharu: Dihantar Piksel sesaat = Kadar Bingkai × Resolusi Ini memberikan gambaran yang lebih lengkap daripada hanya melihat FPS atau resolusi sahaja. Ia menunjukkan berapa banyak data visual yang sebenarnya dihantar oleh codec sesaat dalam keadaan berbeza. Untuk video bergerak tinggi, - dan dengan margin yang ketara. Walaupun pada kadar bit yang lebih rendah, ia berjaya menghantar lebih banyak piksel sesaat daripada mana-mana codec lain. Ini jelas menunjukkan sejauh mana AV1 mengendalikan kandungan dinamik apabila sistem berada di bawah tekanan untuk mengekalkan kadar bingkai yang tinggi. Sila lihat : AV1 sekali lagi muncul di atas graf berikut Apabila saya beralih kepada kandungan gerak rendah - seperti halaman web dengan teks menatal - medan permainan menjadi lebih tinggi. Prestasi semua codec menjadi lebih seragam seperti yang anda boleh temui pada . Walau bagaimanapun, , terutamanya pada kadar bit yang lebih tinggi. Pengoptimuman mampatannya membantunya mengekalkan daya pengeluaran yang kukuh tanpa meningkatkan penggunaan sumber dengan ketara. imej seterusnya AV1 masih mengekalkan pendahuluan Apakah maksud semua ini dalam amalan? Nah, jika kes penggunaan anda melibatkan visual yang dinamik dan bergerak tinggi - seperti panduan video, animasi langsung atau penstriman permainan - , dan AV1 terbukti sangat berkebolehan dalam persekitaran itu. mengutamakan kadar bingkai boleh membuat perbezaan yang besar Walaupun untuk kandungan yang bergerak lebih perlahan, AV1 terus menunjukkan kekuatan. Walaupun perbezaannya mungkin lebih kecil, ia secara konsisten berjaya menghantar lebih banyak data visual - bermakna kualiti yang lebih baik pada lebar jalur yang sama atau lebih rendah - terima kasih kepada strategi pemampatan lanjutannya. Dalam kedua-dua kes, metrik terbukti berguna untuk memahami cara codec mengimbangi resolusi dan kadar bingkai apabila lebar jalur adalah terhad. Dan prestasi AV1 di bawah keadaan ini mengukuhkan lagi ia sebagai pilihan yang paling berkebolehan - dengan syarat sistem anda boleh mengendalikan permintaan CPU tambahan. "piksel sesaat" Seberapa Bersih Imejnya? Mari Berbincang PSNR Di luar kadar bingkai, resolusi dan penggunaan CPU, terdapat satu lagi bahagian penting dalam teka-teki perkongsian skrin: Di situlah masuk. sejauh manakah imej yang diterima kelihatan kepada imej asal? Nisbah Isyarat-ke-Bunyi Puncak (PSNR) PSNR ialah metrik yang digunakan secara meluas untuk mengukur kualiti video mampat. Ia memberitahu anda berapa banyak herotan - atau "bunyi" - telah diperkenalkan semasa pengekodan. Ia diukur dalam , dan peraturannya mudah: . PSNR tinggi bermakna imej kelihatan hampir sama seperti yang asal; skor yang lebih rendah bermakna terdapat kemerosotan yang lebih ketara. desibel (dB) lebih tinggi, lebih baik Untuk meletakkan ini dalam konteks, saya menguji nilai PSNR merentas codec dalam dua senario berbeza: satu di mana adalah keutamaan dan satu lagi di mana mendahului. Kedua-dua ujian menggunakan yang sama untuk memastikan perkara itu konsisten. resolusi kadar bingkai kandungan video bergerak tinggi Dalam persediaan ini, di mana kejelasan menjadi tumpuan (walaupun jika video berakhir agak bergelora), , menyampaikan visual yang tajam dengan herotan yang minimum. Ia adalah pilihan yang kuat apabila kelancaran tidak begitu kritikal. H.264 berprestasi dengan baik sekali Apabila matlamat beralih kepada mengekalkan gerakan bendalir, , terutamanya pada kadar bit yang lebih tinggi. Ia berjaya mengekalkan kualiti imej walaupun semasa memampatkan secara agresif untuk mencapai sasaran kadar bingkai. AV1 muncul di hadapan Walaupun perbezaan dalam PSNR antara codec tidak selalunya dramatik, ia menyerlahkan yang anda buat semasa memilih codec. Ada yang mengutamakan ketajaman; yang lain bertujuan untuk gerakan lancar - dan bergantung pada kes penggunaan anda, satu mungkin lebih sesuai daripada yang lain. pertukaran Kemudian saya menjalankan ujian yang sama sekali lagi, kali ini menggunakan - sesuatu yang benar-benar menekankan kepentingan resolusi dan kejelasan. kandungan teks yang ditatal Apabila gerakan diutamakan, nilai PSNR merentas semua codec kelihatan agak serupa. Kandungan tidak banyak berubah, jadi perbezaan dalam strategi pemampatan tidak banyak memberi kesan kepada kualiti imej keseluruhan. Di sinilah perkara menjadi menarik. Dengan peleraian sebagai keutamaan, codec lain - terutamanya pada kadar bit yang lebih tinggi. Prestasinya di sini adalah luar biasa. AV1 mendahului kenapa? AV1 termasuk pengoptimuman khusus untuk mengendalikan kandungan statik dan berulang seperti teks. Ini membolehkannya mengekalkan , mengelakkan artifak dan memampatkan dengan lebih cekap. Itu menjadikan AV1 pilihan hebat untuk kes penggunaan seperti perkongsian dokumen atau panduan kod - di mana-mana sahaja . kesetiaan imej yang lebih tinggi butiran yang jelas dan boleh dibaca sangat penting Ringkasnya, PSNR membantu menyerlahkan dimensi kualiti perkongsian skrin yang halus tetapi penting. Sama ada anda mengutamakan pergerakan atau ketajaman, memahami cara codec berkelakuan di bawah kekangan yang berbeza membolehkan anda memilih yang sesuai untuk tugas itu. Apakah Perjanjian dengan QP? Memahami Mampatan lwn Kualiti Satu lagi faktor penting dalam kualiti perkongsian skrin ialah sesuatu yang dipanggil , atau . Jika anda pernah tertanya-tanya apa yang mengawal berapa banyak butiran yang hilang semasa pemampatan, ini dia. Parameter Kuantiti QP Secara ringkas, . QP memberitahu pengekod betapa agresifnya untuk memampatkan video bermakna kurang mampatan dan kualiti imej yang lebih baik. QP yang rendah bermakna lebih banyak pemampatan - yang menjimatkan lebar jalur, tetapi boleh menjadikan video kelihatan lebih teruk. QP yang tinggi Walaupun PSNR memberikan kami hasil - berapa banyak kualiti imej yang telah dipelihara - . Jadi, saya melihat kedua-duanya. QP memberitahu kami tujuan pengekod itu Dalam kajian ini: telah ditarik daripada metrik WebRTC standard. Nilai QP diukur selepas fakta dengan membandingkan setiap bingkai asal dengan versi yang diterima. PSNR Di sinilah perkara menjadi menarik. , bermakna ia mengekalkan kualiti imej yang terbaik - tetapi ia juga mempunyai daripada codec lain. Itu kelihatan bercanggah pada pandangan pertama. AV1 mempunyai skor PSNR terbaik nilai QP sehingga empat kali lebih tinggi Tetapi inilah tangkapannya: , jadi nilainya tidak dapat dibandingkan secara langsung. QP 50 dalam satu codec tidak semestinya bermaksud tahap mampatan yang sama seperti QP 50 dalam codec yang lain. setiap codec mentakrifkan dan mengendalikan QP secara berbeza Namun, aliran QP memberitahu kami sesuatu yang berguna. Merentasi semua codec, saya perhatikan bahawa . Itu masuk akal - dengan lebih banyak lebar jalur tersedia, codec mampu mengurangkan pemampatan dan meningkatkan kualiti imej. apabila lebar jalur meningkat, QP berkurangan Jadi, walaupun kami tidak boleh menyusun nombor QP bersebelahan merentas codec, ia masih menunjukkan cara setiap codec melaraskan pemampatan secara dinamik berdasarkan keadaan rangkaian yang tersedia. Intinya: . Tetapi menjejaki cara ia berubah dengan lebar jalur memberikan gambaran yang berguna tentang perkara yang dilakukan oleh pengekod di sebalik tabir. Dan digabungkan dengan PSNR, ia memberikan gambaran yang lebih lengkap tentang tingkah laku codec. QP bukan skor kualiti - ia tetapan Fikiran Akhir: Maksud Semua Ini untuk Perkongsian Skrin WebRTC Selepas menyelam lebih mendalam tentang prestasi WebRTC di bawah hud, satu perkara yang jelas: - dan pilihan terbaik benar-benar bergantung pada keutamaan dan persekitaran anda. tidak semua codec dicipta sama Berikut ialah pengambilan utama daripada eksperimen saya: AV1: Kualiti Terbaik, Kos Tertinggi AV1 secara konsisten menyampaikan , sama ada saya berkongsi video bergerak pantas atau teks menatal perlahan. Pemampatan dan pengoptimuman lanjutannya menjadikannya sangat cekap - tetapi itu datang dengan harga. AV1 , dan memandangkan sokongan perkakasan masih mengejar, ia tidak sesuai untuk peranti berkuasa rendah atau mudah alih . kualiti visual terbaik sangat laparkan CPU lagi H.264: Pepejal Serba Bulat Jika anda sedang mencari , H.264 masih merupakan pilihan yang bagus. Ia disokong secara meluas, dipercepatkan perkakasan pada kebanyakan platform, dan berfungsi dengan baik dalam hampir setiap senario - terutamanya apabila sumber sistem atau hayat bateri menjadi kebimbangan. keseimbangan antara prestasi dan kecekapan Kandungan Lebih Penting Daripada Yang Anda Fikirkan Jenis kandungan yang anda kongsi mempunyai terhadap prestasi. Video gerakan tinggi memerlukan lebih banyak daripada CPU dan lebar jalur anda daripada kandungan statik seperti dokumen atau teks. Memilih codec yang betul - dan tetapan yang betul - untuk kandungan anda boleh membuat perbezaan besar dalam kualiti dan penggunaan sumber. kesan yang besar Penggunaan CPU Bukan Sekadar Nota Kaki Terima kasih kepada pemalam Chrome tersuai yang saya bina, saya dapat mengukur penggunaan CPU dengan tepat semasa perkongsian skrin. Hasilnya menunjukkan , yang menjadi sangat penting pada peranti mudah alih atau dalam persekitaran sensitif tenaga. perbezaan besar dalam cara menuntut setiap codec Apa Seterusnya? Ke mana Penyelidikan Ini Boleh Pergi Percubaan ini membuka pintu kepada beberapa langkah seterusnya yang menarik. Di sinilah saya fikir kerja masa depan boleh memberi impak yang lebih besar: Pengujian pada Peranti Mudah Alih Setakat ini, semua ujian telah dilakukan pada desktop - tetapi perkongsian skrin adalah sama biasa (jika tidak lebih) pada . Menguji prestasi codec ini pada mudah alih akan memberikan gambaran yang lebih lengkap, terutamanya dari segi responsif dan penggunaan kuasa. telefon dan tablet Kecekapan Tenaga Bercakap tentang kuasa - codec bukan sahaja membakar CPU, mereka juga membakar . Penyelidikan masa depan harus meneroka codec yang , terutamanya untuk sesi perkongsian skrin panjang pada peranti mudah alih. hayat bateri paling cekap tenaga Penalaan Codec Dikuasakan AI Bayangkan jika WebRTC boleh melaraskan tetapan codec secara automatik berdasarkan kandungan semasa anda dan kelajuan rangkaian. , mencari keseimbangan sempurna antara kualiti dan prestasi secara dinamik dalam masa nyata. AI boleh menjadikannya mungkin Membungkusnya Pilihan codec lebih daripada sekadar keputusan teknikal - ia secara langsung mempengaruhi pengalaman perkongsian skrin anda. Sama ada anda sedang membina alat persidangan video, platform kerjasama atau hanya mengoptimumkan aliran kerja anda sendiri, memahami cara codec ini berkelakuan dalam keadaan berbeza boleh membantu anda membuat keputusan yang lebih bijak dan berkesan. kualiti, kelancaran dan penggunaan sumber Apabila WebRTC terus berkembang, begitu juga alat dan teknik di sekelilingnya. Saya harap penyelaman mendalam ini membantu orang lain memahami dengan lebih baik perkara yang berlaku di sebalik tabir - dan cara untuk memanfaatkan timbunan perkongsian skrin mereka sepenuhnya. Ingin Meneroka Data Sendiri? Jika anda ingin mengetahui dengan lebih mendalam keputusan atau menjalankan analisis anda sendiri, saya telah menyediakan set data penuh daripada kajian ini di sini: Muat turun set data pada Kaggle Ia termasuk metrik mentah untuk kadar bingkai, resolusi, PSNR, QP, penggunaan CPU dan banyak lagi - semuanya disusun mengikut codec, jenis kandungan dan keadaan lebar jalur. Jangan ragu untuk menggunakannya untuk percubaan anda sendiri, penanda aras atau hanya untuk meneroka cara WebRTC berkelakuan dalam senario yang berbeza.