Mari Mengkaji Mekanisma Pemampatan Video HEVC

Pada September 2012 kami ada menulis satu artikel pengenalan kepada H.265 ataupun nama penuhnya yang dikenali sebagai High Efficiency Video Coding (disingkatkan kepada HEVC, juga boleh dirujuk dengan nama H.265). HEVC merupakan generasi akan datang untuk piawaian video. Ketika artikel ini ditulis piawaian popular yang digunakan untuk memain-balik (playback) video ialah H.264, juga dikenali sebagai Advance Video Coding (AVC).

Kenapa kami menyatakan HEVC ini sebagai piawaian generasi akan datang? Ini kerana HEVC masih lagi dalam fasa eksperimen dan masih belum sesuai untuk digunakan dalam industri mahupun pengguna. Artikel ini turut membicarakan perbandingan antara HEVC dan AVC dari beberapa sudut, antaranya masa yang diperlukan untuk memproses video dalam dua piawaian berkenaan dan juga beberapa lagi aspek menarik yang berkaitan.

Penyelarasan Terma

Sebelum membaca artikel ini dengan lebih lanjut, wajarlah kiranya kami memperkenalkan terma-terma berkaitan terlebih dahulu. Untuk menghasilkan video berpiawaian AVC (H.264) ia memerlukan aplikasi x264. Untuk menghasilkan video berpiawaian HEVC (H.265) pula, ia memerlukan aplikasi x265. Ketika artikel ini ditulis, aplikasi x265 sedang dibangunkan (secara berasingan) oleh beberapa organisasi seperti MulticoreWare, Kvazaar, OpenHEVC, dan juga DivX (mungkin terdapat beberapa lagi organisasi, akan tetapi ini yang dapat kami jumpa setakat ini).

Namun di sini terdapat satu masalah. Untuk menggunakan aplikasi x264 dan x265 itu sendiri agak rumit, sebagai contoh kedua-dua aplikasi berkenaan hanya boleh encode video sahaja tanpa audio stream, dan memerlukan fail video yang spesifik. Sebahagian daripada pembaca mungkin biasa menggunakan aplikasi penukar format video seperti Freemake Video Converter.

Untuk menukar video kepada fail format MP4 seperti yang tertera dia atas, Freemake menyatakan bahawa ia menggunakan piawaian H.264, dan ini bermaksud Freemake menggunakan aplikasi x264 sebagai enjin untuk proses penukaran format (encode) berkenaan.

Seketika nanti kami akan menyertakan demonstrasi penukaran video daripada sumber asal kepada AVC dan HEVC dengan menggunakan aplikasi berasaskan command line iaitu FFmpeg. Kami memilih FFmpeg kerana ia memberikan lebih kuasa dan kebebasan kepada kami untuk melakukan dan memanipulasikan eksperimen ini.

Terma encode dan transcode merujuk kepada proses penukaran format fail video (juga popular dengan terma video converting). Sesetangah artikel di internet menggunakan terma transcode, sesetangah lagi menggunakan terma encode, dan kedua-duanya membawa maksud yang sama.

HEVC: Pengenalan Ringkas

Pada 26 Januari 2013, HEVC H.265 telahpun diluluskan penggunaannya untuk diimplementasikan secara meluas untuk pengguna. Fokus utama HEVC adalah untuk video dengan resolusi 4k pada saiz fail berpatutan (untuk tujuan penstriman secara terus tanpa wayar / internet).

HEVC dikatakan mampu menawarkan video pada resolusi yang tinggi dengan saiz fail yang kecil. Jika dilakukan perbandingan umum antara AVC dan HEVC; contohnya filem yang diproses (encode) dengan menggunakan AVC mempunyai saiz 700 MB dengan resolusi 720p, filem yang sama pada resolusi yang sama tetapi menggunakan HEVC mungkin mempunyai saiz 350 MB, ataupun lagi rendah.

Video yang sama pada kualiti yang sama tetapi pada saiz 50% lebih kecil. Menarik, kan?

Jika dirujuk daripada sejarah piawaian video, perkembangan daripada H.263 kepada H.264 menyaksikan bahawa H.264 mengurangkan saiz sebanyak 50% daripada video yang menggunakan piawaian H.263. Trend yang serupa dilihat pada perkembangan H.264 kepada H.265.

FFmpeg: Pengenalan Ringkas

Anda pernah dengar K-Lite Codec? Jika anda menggunakan komputer sejak zaman Windows XP lagi, dan anda merupakan peminat tegar filem ataupun anime, terdapat kebarangkalian yang tinggi bahawa anda pernah memasang K-Lite Codec ataupun Combined Community Codec Pack (CCCP).

Kedua-dua aplikasi berkenaan dikenali sebagai video decoder (ringkasnya, codec). Mereka berfungsi sebagai penterjemah antara fail video kepada pemain video untuk sesetangah format video. Sebagai contoh, ketika MP4 diperkenalkan dulu, tidak banyak pemain video yang menyokong terus format MP4, dan proses memainkan video MP4 berkenaan memerlukan kepada codec sebagai penterjemah bagi membolehkan pemain video memahami (dan memainkan) fail video berkenaan.

Kedua-dua K-Lite Codec dan CCCP mempunyai enjin FFmpeg di dalamnya. FFmpeg merupakan satu aplikasi yang sangat berkuasa: ia boleh menjadi decoder engine dan juga encoder engine. Maksudnya ia boleh menjadi penterjemah untuk pemain video (decoder / codec), dan ia boleh melaksanakan proses penukaran format video (encoder).

Sebagai contoh, jika kami ingin menukarkan format video daripada AVI kepada MP4, kami boleh menggunakan FFmpeg tanpa bergantung kepada aplikasi seperti Freemake. Bahkan FFmpeg memberi lebih kuasa kepada kami untuk menetapkan bitrate, constant rate factor, serta video profiles.

 

Untuk eksperimen pertama, kami menggunakan sampel video YUI – Life daripada laman Jpopsuki (lagu penutup anime Bleach ke-5). Setelah menjalankan aplikasi MediaInfo untuk mendapatkan informasi mengenai video berkenaan, ia telah dikenal pasti menggunakan piawai MPEG-4 Version 2 (piawaian serasi H.263).

Eksperimen 1

Kami menggunakan FFmpeg Zeranoe (FFmpeg untuk Windows). Baris arahan di bawah ini digunakan untuk memulakan proses encode daripada video asal kepada H.265

ffmpeg.exe -i “YUI - Life.mp4” -c:v libx265 YUI-x265.mp4

Kami juga menggunakan baris arahan di bawah ini untuk memproses video asal kepada H.264

ffmpeg.exe -i “YUI - Life.mp4” -c:v libx264 YUI-x264.mp4

Setelah proses encode selesai, kami membandingkan saiz di antara video asal (MPEG-4 Ver. 2), hasil encode H.264, dan hasil encode H.265.

Anda boleh lihat sendiri saiz yang berjaya dikurangkan daripada video asal kepada H.264 dan juga H.265. Tetapi bagaimana pula dengan kualiti dan dimensi?

Dimensi video tidak berubah (kekal dengan 720×400), namun kami dapat mengesan pengurangan dari aspek kualiti warna.

Kedua-dua video berkenaan dimainkan dengan menggunakan pemain video FFplay (disertakan sekali dengan FFmpeg). Jika dilihat secara teliti, hasil encode H.265 sedikit kabur dan mempunyai tona warna yang sedikit suram jika dibandingkan dengan hasil encode H.264.

Memandangkan FFplay merupakan aplikasi berasaskan command line, kita dapat melihat bahawa FFplay mengalami sedikit kesukaran untuk memainkan video yang berdasarkan piawai H.265 tersebut (merujuk kepada warning output pada command prompt di belakang video YUI-x265.mp4).

Eksperimen 2

Tidak cukup dengan satu hasil kajian, kami melakukan eksperimen seterusnya dengan menggunakan MacBook Pro Mid-2012 yang menjalankan sistem operasi OS X Mavericks 10.9 (versi terkini).

Kali ini, kami menggunakan video daripada SciShow iaitu Why Do Flamingos Stand on One Leg. Ketika artikel ini ditulis, FFmpeg pada Mavericks 10.9 (dipasang menggunakan HomeBrew) tidak mempunyai sokongan penuh x265. Maka kami terpaksa menggunakan command line yang sedikit panjang seperti yang tertera pada gambar di bawah ini.

Di sebelah kiri Terminal merupakan sumber asal video berkenaan, bersaiz 10.2 MB. Setelah siap proses encode kepada H.265, kami ulang langkah yang sama iaitu memproses video asal kepada piawai H.264 untuk tujuan perbandingan.

Setelah kedua-dua proses encode selesai dijalankan, saiz ketiga-tiga video dibandingkan.

[info]Nota 1: Memandangkan FFmpeg yang dipasang menggunakan HomeBrew ini tidak mempunyai sokongan penuh x265, hasil encode tidak mempunyai audio stream di dalamnya (kerana tidak mempunyai data bunyi). Maka kami padamkan suara pada kedua-dua hasil encode H.264, H.265, dan juga pada video asal.[/info]

Perhatikan secara teliti pada latar belakang teaser di sebelah kiri yang bertajuk “The Chelyabinsk Meteor”. Hasil encode H.265 mempunyai warna yang lebih pudar dan tidak menyerlah berbanding dengan hasil encode H.264.

Eksperimen 3

Masih lagi dalam mood “belum berpuas hati”, kami menjalankan sekali lagi proses encode untuk kali ke-3. Kali ini kami menggunakan video Mingguan Amanz – Heartbleed, Windows XP Tamat, Dropbox Carousel. Masih lagi pada platform Mavericks 10.9, kami menjalankan proses yang sama seperti Eksperimen 2.

Seperti biasa, perbandingan saiz:

Juga seperti biasa, perbandingan kualiti:

Jika dilihat dengan sangat teliti, tentu para pembaca dapat mengesan sedikit pengurangan kualiti pada hasil encode H.265 jika dibandingkan dengan H.264 (lihat gambar pada saiz penuh di sini).

Penggunaan CPU

Kami agak skeptik terhadap sebarang teknologi baru seperti H.265 ini kerana kuasa pemampatan saiz yang ditawarkan olehnya. Sebelum kita bergerak lebih jauh kami rasa anda perlu tahu bahawa proses untuk encode video dengan menggunakan sebarang aplikasi (sebagai contoh, FFmpeg) sangat memerlukan kepada kuasa pemprosesan yang tinggi.

Imbas kembali sekitar tahun 2011. Pada ketika itu, beberapa kumpulan anime encoders (peminat anime yang mengeluarkan video anime kepada umum, biasanya diekstrak daripada siaran TV, DVD, ataupun Bluray) melakukan eksperimen terhadap satu fungsi pada aplikasi x264 ketika itu yang dinamakan sebagai Profil Kedalaman 10-bit (10-bit depth x264 profile).

Tetapan asal aplikasi x264 ialah 8-bit, dan profil 10-bit dikatakan mampu menjadikan video tersebut 10% hingga 20% lebih kecil saiznya berbanding video yang menggunakan profil 8-bit pada kualiti dan resolusi yang sama. Namun penggunaan 10-bit terdapat beberapa kesan negatif, antaranya video yang menggunakan profil 10-bit menggunakan lebih kuasa CPU untuk dimainkan.

Mengikut pengalaman kami pula, ketika itu (tahun 2011) hanya pemain video tertentu sahaja menyokong video yang menggunakan profil 10-bit. Bahkan ketika artikel ini ditulis, mungkin masih ada lagi pemain video yang tidak menyokongnya, contohnya pada 26 Januari 2014 yang lalu kemaskini terbaru MPlayerX akhirnya menyertakan kemaskini untuk menyokong penuh profil 10-bit.

[info]Nota 2: x265 juga mempunyai 2 profil ketika artikel ini ditulis, iaitu 8-bit (default) dan 16-bit.[/info]

Kita berbalik semua kepada H.265 HEVC. Berdasarkan cerita yang kami sajikan sebentar tadi diharapkan para pembaca faham nilai skeptik kami terhadap impak negatif H.265 terhadap penggunaan kuasa pemprosesan.

Dengan memainkan video “Mingguan Amanz” dan “Why Do Flamingo” yang telah kami encode pada Eksperimen 2 dan Eksperimen 3, kami cuba untuk mendapatkan gambaran kasar kuasa pemprosesan ketika CPU tidak menerima apa-apa bebanan kerja, ketika memainkan video H.264 (dengan profil 10-bit), dan ketika memainkan video H.265.

Eksperimen 1

Eksperimen 2

Kesemua video dimainkan dengan menggunakan FFplay, dan paparan skrin di atas diambil pada saat ke-10 ketika video dimainkan, dan kesemua video dimainkan ketika semua aplikasi aktif ditutup, dan kesemua video dimainkan secara berasingan.

Kedua-dua eksperimen memberikan bacaan penggunaan CPU yang agak menarik: kedua-duanya tidak menunjukkan perbezaan yang sangat ketara, namun apa yang menarik minat kami ialah video yang menggunakan H.265 menunjukkan penggunaan CPU yang lebih rata terhadap kesemua teras manakala video yang menggunakan H.264 menunjukkan penggunaan teras CPU yang tidak begitu rata seperti mana H.265.

Persoalannya, adakah H.265 lebih mesra CPU yang berbilang teras? Kami tidak mampu menjawab soalan ini kerana H.265 masih lagi dalam fasa eksperimen.

Sepantas lalu sejarah HTML5 Video dan piawaian video

Kami teringin untuk bercerita mengenai H.264 serta kaitannya dengan HTML5, Google, format video WebM, dan isu royalti H.264 serta implementasi H.264 dalam pelayar web sumber terbuka seperti Mozilla Firefox.

Ketika draf HTML5 Video diumumkan, industri besar Internet ketika itu sukar untuk mencapai kata sepakat untuk memilih format manakah yang perlu menjadi piawai utama, dan ketika itu video disebarkan di internet berdasarkan kepada format Flash Video, memerlukan pelayar web memasang pemalam (plug-in) tambahan seperti Adobe Flash Player.

Kesukaran ini berpunca kerana tidak semua pelayar web mempunyai sokongan untuk memainkan format video tertentu, sebagai contoh ketika draf itu diumumkan pelayar web Firefox tidak menyokong format H.264, tetapi menyokong format Ogg Theora.

Kenapa Firefox tidak menyokong H.264? Kerana H.264 merupakan teknologi berpaten, sedangkan Firefox merupakan pelayar web sumber terbuka. Oleh kerana itulah Firefox menyokong format Ogg Theora kerana ia merupakan format yang terbuka.

Untuk pengetahuan pembaca, format Ogg Theora dibangunkan berdasarkan codec library VP3 yang mempunyai hak milik (proprietary library). VP3 ini dibangunkan oleh syarikat yang bernama On2 Technologies.

Apa yang menarik dalam cerita ini adalah pada tahun 2010, Google membeli On2 Technologies pada nilai yang agak tinggi iaitu $124.6 juta dolar. Dengan pembelian ini, Google mendapat hak milik ke atas teknologi terbaru yang dibangunkan oleh On2 Technologies iaitu codec library VP8. Sejurus selepas itu, Google menjadikan VP8 sebagai teknologi bebas royalti sekaligus membolehkan industri sumber terbuka memanfaatkan VP8 sebagai alternatif kepada H.264.

Google tidak berhenti setakat itu sahaja, bahkan mereka mula membangunkan format video yang dikenali sebagai WebM. Sama seperti H.264, VP8 hanyalah teknologi untuk video stream sahaja. Anda boleh fikirkan WebM ini sebagai alternatif kepada fail video MP4. Lazimnya dalam fail video MP4, ia mempunyai video stream dalam format H.264 (patented technology) dan audio stream dalam format AAC (juga patented technology). Manakala bagi fail video WebM, ia menggunakan video stream VP8 (bebas royalti) dan audio stream Vorbis (sumber terbuka, dibangunkan oleh pembangun Ogg Theora).

Usaha Google membangunkan WebM ini dipuji oleh gerakan pencinta sumber terbuka serta mendapat sokongan daripada Free Software Foundation. Kami tidak melepaskan peluang untuk mencuba prestasi VP8, dan hasil ujikaji singkat kami mendapati prestasi VP8 pada tahap yang hampir sama seperti H.264 (8-bit) pada pandangan kasar (kualiti dan saiz).

[info]Nota 3: Google juga ada membangunkan alternatif untuk fail gambar iaitu WebP.[/info]

Pada Oktober 2013, Cisco telah mendapatkan hak ke atas H.264 lalu menjadikan ia sebagai format bebas royalti (anda boleh fikirkan ia seperti Cisco membeli H.264 lalu menjadikan ia sebagai sumber terbuka). Ini membolehkan pelayar web Firefox untuk menambah sokongan H.264 pada pelayar web tersebut tanpa perlu membayar royalti kepada pemilik asal H.264.

H.264, Ogg Theora, dan WebM menjadi alternatif kepada Flash Video pada hari ini.Hasilnya pada hari ini, terdapat tiga format video utama yang boleh digunakan bersama-sama HTML5 Video iaitu H.264, Ogg Theora, dan juga WebM sebagai alternatif kepada Flash Video. Kami ingin berbicara mengenai YouTube dan teknologi MPEG-DASH, namun ia akan menyebabkan artikel ini lebih panjang dan lebih teknikal, kami kongsikan sahaja artikel ringkas mengenai MPEG-DASH yang ditulis oleh saya sendiri.

Kesimpulan

Apakah pula kaitan antara cerita di atas dengan H.265?

H.265 bakal menjadi piawaian pilihan utama pada masa akan datang kerana ia mampu mengurangkan saiz video pada kualiti dan dimensi yang sama, sekaligus ia akan menjimatkan kos penghantaran data daripada pelayan kepada pengguna (sebagai contoh, data bulanan anda tidak akan susut dengan laju jika anda menonton YouTube pada telefon anda). Namun H.265 merupakan patented technology, maka industri sumber terbuka akan menghadapi masalah untuk mengaplikasikannya.

Apa-apapun, kita tunggu sahaja sehingga VP9 siap dibangunkan. Kami difahamkan bahawa VP9 juga mempunyai prestasi yang hampir sama dengan H.265 iaitu pengurangan saiz sehingga 50% berbanding versi sebelumnya (VP8).

Sebagai pengguna biasa, adakah H.265 (dan juga VP9) akan memberi impak yang besar kepada kehidupan harian anda? Kami di Amanz turut teringin untuk mendengar pandangan anda.

[info]Jangan lupa baca nota penulis ketika proses menulis artikel ini.[/info]