Kebanyakan orang mengetahui dasar-dasar teori warna. Dengan menggabungkan kecerahan beberapa warna primer, Anda dapat membuat ulang warna apa pun yang terlihat oleh seseorang. Banyak orang tahu bahwa warna individu hanyalah panjang gelombang dari spektrum elektromagnetik. Namun yang tidak disadari banyak orang adalah betapa sulitnya situasi saat kita berusaha merekam dan mereproduksi warna secara akurat.
Ada banyak sistem yang terlibat dalam mengubah nilai triplet RGB ke panjang gelombang cahaya tertentu. Transformasi ini harus distandarisasi sehingga semua perangkat lunak, semua dekoder video, kartu video, dan monitor (bahkan dibuat oleh produsen yang berbeda dalam dekade yang berbeda) dapat menghasilkan hasil yang sama dari data input yang sama. Untuk memenuhi tantangan ini, standar warna telah dikembangkan. Namun, tampilan dan teknologi lainnya telah berkembang seiring waktu. Televisi menjadi digital, kompresi dimulai, dan kami membuang CRT demi LCD dan OLED. Peralatan baru ini mampu menampilkan lebih banyak warna pada kecerahan yang lebih tinggi, tetapi sinyal yang diterimanya masih disesuaikan dengan kemampuan tampilan lama.
Solusi untuk masalah ini adalah menciptakan "ruang warna" baru. Konten HD baru dapat diproduksi dalam ruang warna baru dan layar HD baru dapat menampilkannya. Dan jika ruang warna lama diubah menjadi yang baru sebelum ditampilkan, maka konten lama tidak akan kehilangan kompatibilitas.
Ini adalah solusi yang berfungsi, tetapi mempersulit proses pembuatan video. Pada setiap langkah dalam proses pengambilan, perekaman, pengeditan, penyandian, penguraian kode, pengomposisian, dan tampilan, Anda perlu mempertimbangkan ruang warna yang Anda gunakan. Dan jika setidaknya satu tahap proses menggunakan peralatan lama, atau ada bug perangkat lunak yang menyebabkan ruang warna tidak diperhitungkan, maka hasilnya mungkin gambar yang salah. Video masih dapat ditonton, tetapi warnanya mungkin tampak terlalu gelap atau pucat.
Saat ini, dua ruang warna yang paling populer adalah BT.601 (juga disebut smpte170m; saya akan menggunakan kedua nama ini dalam artikel ini), yang telah menjadi standar untuk konten SD, dan BT.709, yang telah menjadi standar untuk konten HD. Ada juga BT.2020, yang semakin populer berkat konten HDR dan UHD-nya. Perlu dicatat bahwa divisi HD / SD sedikit cacat di sini. Tidak ada batasan teknis, itu hanya pendekatan tradisional. Konten HD dapat dikodekan dalam BT.601 dan konten SD di BT.709. Jika Anda mengambil file video 1080p dan menguranginya menjadi 480p, ruang warna tidak akan berubah secara otomatis. Mengubah ruang warna merupakan langkah tambahan yang dilakukan sebagai bagian dari proses.
Apa yang terjadi jika suatu proses tidak dijalankan dengan benar? Mari kita lakukan percobaan.
Program ffmpeg adalah keajaiban nyata di zaman kita. Ini adalah alat video digital yang sangat populer, dan seluruh industri berhutang banyak kepada pengembangnya. Dalam percobaan saya, saya akan menggunakan alat ini untuk membuat dan memodifikasi file video.
Pertama, saya akan membuat file tes sederhana menggunakan ffmpeg:
ffmpeg -f rawvideo -s 320x240 -pix_fmt yuv420p -t 1 -i /dev/zero -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -color_range pc -y 601.mp4
Penjelasan singkat dari perintah ini:
ffmpeg
—
-f rawvideo
— ffmpeg, , .
-s 320x240
— . , . .
-pix_fmt yuv420p
— . Yuv420p — . , yuv(0,0,0) . RGB, , .
-t 1
— 1
-i /dev/zero
— . /dev/zero — , mac. , .
-an
— , .
-vcodec libx264
— libx264.
-profile:v baseline
— h.264. h.264, .
-preset:v placebo
— libx264, . , . , .
-color_range pc
— 0 255. 16-235. - , . ,pc
,tv
.
-crf 18
- opsi faktor laju konstan memberitahu libx264 untuk membuat file video berkualitas tinggi dan menggunakan bit sebanyak yang diperlukan untuk memastikan kualitas18
. Semakin rendah angkanya, semakin tinggi kualitasnya. 18 adalah kualitas yang sangat tinggi.
-y
- memberikan izin ffmpeg untuk menimpa file jika ada.
601.mp4
- nama file yang dihasilkan.
Perintah ini membuat file 601.mp4 berdurasi 1 detik, yang dapat dibuka dan diputar. Setelah menjalankan perintah ini, kami dapat memverifikasi bahwa ffmpeg tidak mendistorsi nilai piksel dengan menjalankan perintah berikut dan memeriksa hasilnya:
ffmpeg -i 601.mp4 -f rawvideo - | xxd
00000000: 0000 0000 0000 0000 0000 0000 0000 0000
00000010: 0000 0000 0000 0000 0000 0000 0000 0000
00000020: 0000 0000 0000 0000 0000 0000 0000 0000
00000030: 0000 0000 0000 0000 0000 0000 0000 0000
00000040: 0000 0000 0000 0000 0000 0000 0000 0000
00000050: 0000 0000 0000 0000 0000 0000 0000 0000
...
...
Data dalam heksadesimal ini menunjukkan bahwa semua nilai piksel setelah decoding adalah nol.
Saat merender video di Safari, kami mendapatkan tangkapan layar seperti ini:
Timbul pertanyaan: apa ruang warna ini? Saya menamai file 601.mp4, tetapi tidak ada dalam perintah yang saya tentukan ruang warna, jadi bagaimana Safari tahu warna hijau mana yang akan dirender? Bagaimana browser mengetahui bahwa yuv (0,0,0) harus sama dengan rgb (0,135,0)? Jelas, ada algoritma untuk menghitung nilai-nilai ini. Sebenarnya, ini adalah perkalian matriks sederhana. (Catatan: beberapa format piksel, termasuk yuv420p, memerlukan langkah pra dan pasca pemrosesan untuk mengonversi, tetapi dalam demo ini kami akan menghilangkan kehalusan tersebut.) Setiap ruang warna memiliki matriksnya sendiri. Karena kami tidak menentukan matriks ruang warna saat menyandikan video, Safari hanya membuat asumsi. Kami dapat mengulangi semua matriks, mengalikan semua nilai RGB dengan matriks terbalik dan melihat apa yang sesuai dengannya,tapi mari kita coba pendekatan yang lebih visual dan lihat apakah kita bisa mengetahui apa yang dilakukan Safari.
Untuk melakukan ini, saya akan memasukkan metadata ke dalam file sehingga Safari tahu ruang warna mana yang digunakan dan tidak perlu menebak.
ffmpeg -f rawvideo -s 320x240 -pix_fmt yuv420p -t 1 -i /dev/zero -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -colorspace smpte170m -color_primaries smpte170m -color_trc smpte170m -color_range pc -y 601vui.mp4
Perintah ffmpeg tetap hampir sama, tetapi saya telah menambahkan yang berikut:
-color_trc smpte170m
-colorspace smpte170m
-color_primaries smpte170m
Ini adalah metadata untuk ruang warna tempat file akan dikodekan. Saya tidak akan menjelaskan perbedaan antara opsi ini, karena ini akan membutuhkan artikel lain. Untuk saat ini, kami hanya mengatur semua ruang warna yang kami butuhkan. smpte170m sama dengan BT.601.
Menentukan ruang warna tidak memengaruhi cara file dikodekan, nilai piksel masih dikodekan sebagai yuv (0,0,0). Untuk memverifikasi ini, kita dapat menjalankan perintah pada file baru
ffmpeg -i zero.mp4 -f rawvideo - | xxd
. Bendera ruang warna tidak diabaikan, tetapi hanya ditulis dalam beberapa bit di dalam bagian "informasi kegunaan video" (VUI) di header aliran video. Dekoder sekarang akan mencari VUI dan menggunakannya untuk memuat matriks yang diinginkan.
Dan inilah hasilnya:
Baik dengan dan tanpa VUI, video dirender dengan warna yang sama. Mari kita coba file BT.709:
ffmpeg -i 601vui.mp4 -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -vf "colorspace=range=pc:all=bt709" -y 709.mp4
Opsi baru:
-i 601vui.mp4
— 601vui.mp4
-vf "colorspace=all=BT.709"
— ffmpeg, . yuv rgb, . «all» — color_primaries, colorspace color_trc.
Di sini kami mengambil video 601vui.mp4 dan menggunakan filter ruang warna untuk mengonversi ke BT.709. Filter ruang warna dapat membaca ruang warna dari data yang masuk dari file vui 601vui.mp4, jadi kita hanya perlu menentukan ruang warna yang ingin kita terima pada output. Dengan menjalankan
perintah untuk file ini
ffmpeg -i 709.mp4 -f rawvideo - | xxd
, kami mendapatkan setelah transformasi ruang warna nilai piksel yuv (93,67,68). Namun, saat merender file, seharusnyaterlihat sama. Perlu dicatat bahwa hasil akhir mungkin tidak sama karena kami terus menggunakan 24 bit untuk mengkodekan setiap piksel, dan BT.709 memiliki rentang warna yang sedikit lebih besar. Akibatnya, beberapa warna di BT.709 tidak dipetakan dengan tepat ke BT.601 dan sebaliknya.
Dengan melihat hasilnya, Anda dapat dengan jelas melihat bahwa ada sesuatu yang salah. File baru dirender dengan nilai rgb 0,157.0 - jauh lebih terang daripada file input.
Mari kita lihat lebih dekat properti file menggunakan aplikasi ffprobe:
ffprobe 601vui.mp4:
Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p(pc, smpte170m), 320x240, 9 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
DAN
ffprobe 709.mp4:
Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p(pc), 320x240, 5 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
Sebagian besar informasi di sini tidak penting bagi kami, tetapi kami akan melihat bahwa 601vui.mp4 berada dalam format piksel “yuvj420p (pc, smpte170m)”. Beginilah cara kami memahami bahwa file tersebut memiliki VUI yang benar. Tapi 709.mp4 hanya berisi "yuvj420p (pc)". Sepertinya metadata ruang warna tidak disertakan dalam file keluaran. Meskipun filter ruang warna dapat membaca ruang warna asli dan kami menentukan ruang baru secara eksplisit, ffmpeg tidak menulis vui yang benar ke file akhir.
Ini buruk ... Ffmpeg adalah alat konversi video paling populer. Dan itu kehilangan informasi warna. Ini mungkin alasan mengapa banyak video tidak berisi metadata ruang warna, dan oleh karena itu banyak video dirender dengan warna yang tidak serasi. Dalam pertahanan ffmpeg, ini adalah masalah yang rumit. Untuk menginisialisasi encoder, Anda perlu mengetahui ruang warna terlebih dahulu. Selain itu, ruang warna dapat diubah dengan filter video. Ini adalah masalah rumit untuk dipecahkan dalam kode, tetapi masih menyedihkan bahwa perilaku ini standar.
Anda dapat mengatasinya dengan menambahkan metadata ruang warna secara manual:
ffmpeg -i 601vui.mp4 -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -vf "colorspace=range=pc:all=bt709" -colorspace bt709 -color_primaries bt709 -color_trc bt709 -color_range pc -y 709vui.mp4
Akibatnya, nilai warna di 709vui.mp4 akan menjadi rgb (0.132.0). Kecerahan saluran hijau sedikit lebih rendah daripada di 601vui.mp4, tetapi karena konversi ruang warna terjadi dengan kehilangan, dan hasilnya cocok untuk saya, kami akan menyebutnya sukses.
Dari sini kita dapat menyimpulkan bahwa ketika tidak ada ruang warna yang ditentukan dalam file, Safari mengasumsikan bahwa itu adalah BT.601. Dan di sisi Safari, itu asumsi yang sangat bagus. Namun seperti yang disebutkan di atas, BT.601 adalah standar video SD dan BT.709 adalah standar video HD. Mari kita lihat video HD dengan dan tanpa VUI dan lihat bagaimana Safari merendernya. Saya menggunakan perintah ffmpeg yang sama, hanya mengubah resolusi menjadi 1920x1080.
Di SD dan HD, warnanya ditampilkan sama. Safari tidak mempertimbangkan resolusi saat membuat asumsi tentang ruang warna. Apple telah berada di ruang media dan penerbitan untuk waktu yang lama, jadi saya berharap produk perusahaan ini memberikan hasil yang layak. Tetapi bahkan jika semuanya sangat pintar di Safari, menarik bagaimana situasinya di browser lain.
Krom:
Chrome merender video 601 sedikit lebih gelap dari Safari, tetapi 709 terlihat sama. Saya menduga perbedaannya adalah karena optimasi kecepatan dalam perhitungan floating point, tetapi ini tidak relevan untuk pengujian kami.
Saya tahu dari pengalaman bahwa ketika akselerasi perangkat keras dinonaktifkan di pengaturan, Chrome merender secara berbeda:
Dengan memeriksa hasil ini, kita dapat melihat bahwa nilai pada 601 dirender sangat mirip dengan yang sebelumnya, tetapi file 709 dirender seolah-olah tidak memiliki VUI. Dari sini kita dapat menyimpulkan bahwa Chrome, dengan akselerasi perangkat keras dinonaktifkan, mengabaikan VUI dan membuat semua file seolah-olah dalam format 601. Ini berarti bahwa semua 709 file tidak akan diputar dengan benar.
Akhirnya, mari kita jelajahi Firefox:
Ada banyak hal yang bisa dilakukan di sini. Karena 709.mp4 dan 709vui.mp4 terlihat sama, Anda dapat menyimpulkan bahwa jika VUI tidak tersedia, Firefox akan menggunakan format BT.709. Merender 601vui.mp4 dengan benar berarti bahwa untuk konten BT.601 bagian VUI diperhitungkan. Namun, ketika file BT.601 tanpa VUI dirender sebagai 709, itu menjadi sangat gelap. Jelas, tidak mungkin untuk membuat gambar dengan benar tanpa semua informasi yang diperlukan, tetapi metode yang dipilih oleh Firefox mendistorsi warna lebih dari yang dipilih oleh browser Safari dan Chrome.
Seperti yang bisa kita lihat, situasi rendering warna video masih Wild West. Sayangnya, kami hanya membahas sebagian dari masalah. Kami belum mempelajari Windows. Mari kita lakukan itu.
Microsoft Edge:
Sepertinya Edge (setidaknya di komputer saya) mengabaikan VUI dan menjadikan semuanya sebagai 601.
Chrome (dengan akselerasi perangkat keras diaktifkan):
Situasinya tidak jauh berbeda dengan Mac. Jika ada VUI, ditangani dengan benar, tetapi jika tidak ada, dianggap BT.601 untuk konten SD dan BT.709 untuk konten HD. Ini adalah satu-satunya browser di mana saya telah melihat ini, tetapi ada logika tertentu untuk itu. Karena rendering dilakukan secara berbeda dari pada Mac, saya menduga bahwa masalahnya ada di OS atau, lebih mungkin, pada sesuatu di tingkat driver kartu video, dan pilihan ini tidak dibuat oleh tim pengembangan Chrome.
Firefox berperilaku seperti pada Mac.
Untuk Linux, iOS, Android, Roku, Fire TV, smart TV, konsol game, dll., saya akan meninggalkan ini sebagai latihan untuk pembaca.
Apa yang telah kita pelajari? Yang terpenting: selalusertakan metadata ruang warna dalam video Anda. Jika Anda menggunakan ffmpeg dan tidak menyetel flag warna, maka Anda tidak bekerja dengan benar. Kedua, sementara ffmpeg adalah program yang hebat, popularitasnya, kemudahan penggunaan, dan default yang dipilih dengan buruk telah merugikan. Anda tidak boleh berasumsi bahwa perangkat lunak cukup pintar untuk mengetahuinya sendiri. Manajer proyek di Ffmpeg, Google, Mozilla, Microsoft (dan mungkin Nvidia dan AMD) perlu berkumpul dan bekerja sama untuk menemukan satu cara. Saya mengerti bahwa tidak ada solusi yang baik di sini, tetapi buruk dan dapat diprediksi lebih baik daripada buruk dan acak. Secara pribadi, saya sarankan selalu mengasumsikan format BT.601 jika bagian VUI tidak ada. Ini menciptakan paling sedikit distorsi. Dapat dipilih untuk menyelaraskan standar FOMS ini , atau bahkan AOM , karena organisasi-organisasi ini cukup terwakili.
Last but not least, jika Anda memiliki video tanpa informasi warna dan perlu mengonversi atau merendernya, semoga berhasil!
Periklanan
VDSina menawarkan server murah dengan pembayaran harian. Saluran Internet untuk setiap server adalah 500 Megabit, perlindungan terhadap serangan DDoS termasuk dalam tarif, kemampuan untuk menginstal Windows, Linux atau OS secara umum dari gambar Anda, dan juga panel kontrol server berpemilik yang sangat nyaman . Saatnya mencoba ;)
Bergabunglah dengan obrolan kami di Telegram .
