Mengoptimalkan Video Untuk Ukuran Dan Kualitas

Selama beberapa tahun terakhir, semakin banyak proyek yang menggunakan video sebagai bagian integral dari aplikasi. Ini adalah arah yang bagus, karena video lebih menarik daripada foto diam (video dapat menggandakan tingkat konversi dan meningkatkan waktu yang dihabiskan di situs), dan dengan demikian, benar-benar dapat menarik pelanggan untuk menjelajahi detail tentang produk dan layanan. Namun, semuanya berjalan miring ketika ada masalah yang terkait dengan pemutaran video.

Masalah pemutaran video secara langsung terkait dengan ukuran dan kecepatan bit video. Video dengan dimensi besar atau kecepatan bit tinggi akan membutuhkan waktu lebih lama untuk diunduh dan akan membutuhkan jaringan berkecepatan lebih tinggi agar dapat diputar ulang dengan lancar. Hal ini menyebabkan waktu mulai yang lebih lama, dan jika jaringan tidak dapat memasok video dengan cukup cepat, video akan terhenti selama pemutaran video.

Ada solusi meskipun! Dengan menjalankan pengoptimalan dasar video kami sebelum menambahkannya ke situs web kami, kami dapat mencegah terjadinya masalah ini untuk selamanya — yah, sebagian besar dari mereka. Yang perlu kita lakukan hanyalah membuat file lebih kecil — dengan satu atau lain cara. Nah, sekarang triknya adalah: bagaimana caranya agar file tersebut menjadi lebih kecil tanpa mengurangi kualitasnya?

Dalam artikel ini, kami akan memandu Anda melalui alat dan beberapa langkah yang dapat Anda ambil untuk mengoptimalkan pemutaran video Anda — semuanya untuk menghindari kemacetan dan mengesankan pelanggan berharga Anda!

Data Dunia Nyata

Tidak jarang menemukan situs web dengan video yang sangat besar — ​​misalnya, digunakan sebagai video latar pahlawan. Dalam penelitian saya, saya mencari situs yang ditemukan di HTTPArchive seluler Desember 2020, dan tidak sulit untuk menemukan sejumlah besar situs yang memuat file video besar secara default, baik di seluler maupun di desktop.

Tentu saja diragukan bahwa Anda akan dapat mencapai penghematan yang sama yang akan saya tunjukkan di sini, tetapi Anda akan mendapatkan beberapa petunjuk dan tip yang berguna tentang hal-hal yang perlu diingat ketika berurusan dengan video. Faktanya, sangat mudah untuk secara tidak sengaja menempatkan video yang sangat besar di situs web Anda jika Anda tidak hati-hati, sehingga hampir tidak dapat digunakan oleh sebagian besar pelanggan Anda.

Kisah Labu Patch

Bayangkan saat itu pertengahan Oktober, dan Anda sedang mencari petak labu dan labirin jagung untuk menghabiskan sore akhir pekan bersama keluarga Anda. Dalam kenyamanan mesin desktop Anda, Anda mencari web untuk lokasi terdekat dan menemukan yang sempurna. Situs web terlihat indah, dengan video drone 4K yang indah dari bidang yang diputar di bagian atas halaman. Anda memilih URL dan mengirimkannya ke diri sendiri dan orang yang Anda cintai sehingga Anda bersama-sama dapat terus menjelajahi opsi ini saat bepergian.

Tetapi ketika Anda membuka halaman di ponsel Anda, Anda melihat ada kesalahan: video berusaha keras untuk diputar di ponsel Anda, tetapi sayangnya gagal melakukannya. Video terus terhenti dan dimulai ulang berulang kali , menjadi jauh lebih mengganggu dan mengganggu daripada di komputer Anda. Akhirnya Anda melanjutkan, mem-bookmark URL, dan melanjutkan rutinitas harian Anda.

Setelah hari berlumpur yang menyenangkan (well, saya baru-baru ini tinggal di Seattle dan Inggris, jadi tambalan labu berlumpur), Anda kembali ke komputer Anda: mungkin Anda berpikir lagi tentang video itu dan Anda bertanya-tanya mengapa itu tidak diputar baik di ponsel Anda. Nah, mari kita diagnosa apa yang terjadi.

Anda dapat memulai dengan membuka DevTools di browser Anda. Setelah halaman dimuat, kita dapat pindah ke tab Jaringan, dan memfilter menurut "media" untuk melihat semua file video:

Kami melihat bahwa file MP4 sedang diunduh. File tidak datang melalui jaringan sebagai file mandiri; sebaliknya, layanan streaming harus memecah file menjadi beberapa segmen , sehingga Anda mungkin melihat beberapa permintaan 206 (konten sebagian) untuk file yang sama.

Melihat header respons untuk file ini, kami dapat melihat beberapa detail:

 accept-ranges: bytes access-control-allow-headers: x-test-header, Origin, X-Requested-With, Content-Type, Accept access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS Content-Length: 87690242 Content-Range: bytes 70025216-157715457/157715458 content-type: video/mp4 date: Fri, 22 Jan 2021 15:27:26 GMT last-modified: Mon, 24 Jun 2019 05:13:04 GMT server: Apache

Sekarang, beberapa dari angka-angka ini sedikit menakutkan karena ukurannya sedikit besar. Faktanya, mereka seringkali sangat besar sehingga saya terbiasa menambahkan koma, jadi saya bisa mendapatkan gambaran tentang seberapa besar file sebenarnya. Dalam hal ini, unduhan sebagian adalah 87 MB, dan seluruh file adalah 157.715.457 byte. Ya, benar, video ini 157MB, dan (mencoba) untuk memuat di ponsel saya lebih awal hari ini! Tidak heran itu tidak berhasil.

Jadi Ada Apa Dengan Video Ini?

Mari selami sedikit lebih dalam. Rupanya, video terlalu besar untuk diputar dengan lancar di ponsel dengan memori lebih rendah dan jaringan lebih lambat. Tapi apa yang kita butuhkan untuk memperbaikinya? Untuk mengetahui apa sebenarnya masalahnya, kita dapat menggunakan FFMPEG, yang open source dan gratis, dan terbukti menjadi salah satu alat paling andal untuk mengoptimalkan video . Kita dapat mengubah konfigurasi di FFMPEG tanpa henti, tetapi mari kita sentuh beberapa yang penting dalam artikel ini.

Jadi, mari kita mulai dengan alat diagnosis yang disebut FFprobe. FFprobe mengumpulkan informasi dari aliran multimedia, dan memberi Anda detail tentang cara video dikodekan dan cara pemutarannya. Ini adalah bagian dari paket FFMPEG, dan sebenarnya cukup mudah digunakan.

Lebih baik lagi: jika video Anda sudah online, ada ffprobe versi online yang dapat langsung kami buka. Jadi, mari kita masukkan URL ke dalam formulir, dan dapatkan detail tentang video sebagai balasannya (misalnya dimensi video, bitrate, dan sedikit metadata).

Ketika saya menambahkan URL MP4 dari pertanian labu, kami segera melihat salah satu masalah. Respons show_format dari ffprobe mengembalikan ringkasan: tampaknya, ada 2 aliran, dan durasinya 62 detik (yang semuanya terdengar cukup normal untuk tidak menimbulkan kecurigaan). Tetapi ketika kami mencapai ukuran dan bitrate , kami langsung melihat di mana video itu gagal.

Seperti disebutkan di atas, mungkin ada baiknya untuk membiasakan diri menambahkan koma ke angka besar ini. Ternyata, memang footage drone yang terbang di atas lapangan adalah 157MB, dan memiliki bitrate 20 MB per detik! Ini berarti bahwa agar video dapat diputar dengan mulus, jaringan harus dapat mengalirkan video dengan kecepatan lebih cepat dari 20 MBPS, itulah sebabnya mengapa itu terhenti di telepon.

Berapa bitrate pemutaran yang ideal?

Untuk menghindari kemacetan, kita perlu melakukan streaming video dengan kecepatan yang sesuai . Di situlah bitrate menjadi penting. Bitrate adalah kecepatan pemutaran video. Agar browser dapat memutar video dengan lancar, video harus diunduh lebih cepat daripada diputar ulang — artinya video hanya akan diputar ulang dengan lancar jika kecepatan jaringan di atas 20 MBPS. Ketika saya memikirkan kecepatan jaringan, saya cenderung mengandalkan profil lalu lintas WebPageTest:

Seperti yang dapat kami ketahui dari ikhtisar di atas, video mungkin diputar dengan baik pada "Koneksi Asli", dan pada koneksi FIOS kabel optik ultra-cepat (20 MBPS persis kecepatan yang dibutuhkan, jadi semoga tidak ada lagi yang perlu diunduh di Latar Belakang). Namun, semua koneksi lain memiliki kecepatan downlink yang jauh lebih rendah dari 20 MBPS . Jika video dimuat pada kecepatan ini, pemutar akan mencoba menggunakan video lebih cepat daripada yang dapat diunduh, dan video akan berhenti secara permanen.

Bitrate video Anda menetapkan kecepatan jaringan minimum yang dapat digunakan pelanggan Anda. Secara umum, kecepatan bit video Anda harus sekitar 80% dari throughput yang tersedia di jaringan. Jadi video 20 MBPS sangat membutuhkan throughput jaringan 24 MBPS untuk memutar video dengan mulus. Semua orang dengan koneksi yang lebih lambat akan memiliki pengalaman yang sangat buruk dan kemungkinan tidak dapat menonton video sama sekali. Lebih khusus lagi, ini berarti agar kami dapat bermain dengan lancar dan mulus di 4G, bitrate harus tetap di bawah 7,2 MBPS .

Bisakah Kami Menurunkan Bitrate Video Ini?

Ya! Mari kita lihat beberapa konfigurasi yang dapat kita gunakan untuk mengurangi bitrate video ini. Tapi pertama-tama, mari kita lihat data yang kita dapatkan dari FFprobe. Satu hal yang cukup mencolok adalah nilai r_frame_rate , yaitu jumlah frame per detik dalam video. Nilainya adalah 60000/1001. Artinya frame rate untuk video tersebut adalah 60 frame per detik. Namun, kecepatan bingkai biasa di web adalah 25–30, jadi hal pertama yang dapat kita lakukan adalah mengkodekan ulang video dengan kecepatan bit yang lebih rendah .

Hal lain yang perlu diingat adalah Constant Rate Factor . Dalam FFMPEG, tolok ukur kualitas/ukuran utama adalah kompresi Constant Rate Factor (CRF), dengan nilai berkisar dari 0 (tanpa kompresi) hingga 50 (kompresi tinggi). Nilai default untuk CRF di FFMPEG adalah 23 (jika Anda mengabaikan parameter CRF, video Anda dengan nilai itu). Dalam pengalaman pribadi saya, nilai dari 23-28 masih menghasilkan video berkualitas tinggi , terlihat bagus di web dan sangat mengecil dalam ukuran file.

Jadi mari kita mulai dari 30fps dan CRF 23 . Perintah Terminal akan terlihat seperti ini:

 ffmpeg -i input.mp4 -vcodec h264 -acodec aac -crf 23 -strict -2 :v fps=fps=30 output.mp4

Voila! Ini menghasilkan video 81,5 MB — sudah meningkat 48%. Tapi videonya masih sangat besar, dengan bitrate 10 MBPS. Jika kita menyetel CRF ke 28, file turun menjadi 35,4 MB, dengan bitrate 4,5 MBPS yang jauh lebih mungkin untuk diputar dengan baik pada koneksi 4G.

Ini adalah peningkatan lima kali dari video aslinya . Untuk membuat video ini lebih mudah diakses, kita dapat mengubah ukuran video menjadi lebih kecil. Itu adalah sesuatu yang akan kita bahas di bagian streaming di bawah ini.

Cerita Lapar Untuk Pizza

Bayangkan Anda berada di Los Angeles, mungkin berkunjung dari luar negeri dan menjelajahi ponsel Anda, dan tentu saja berpikir untuk mengambil sepotong pizza. Anda menemukan tempat pizza yang luar biasa di ponsel Anda, dan memutuskan untuk pergi ke sana. Anda mungkin telah memperhatikan beberapa video dan gambar pahlawan di halaman, tetapi sebenarnya, setiap tempat pizza terlihat sama, jadi Anda tidak perlu repot-repot menonton videonya. Anda menuju dan mengambil satu atau dua potong sebelum kembali ke hotel Anda.

Malam itu, Anda mendapatkan pesan dari operator bahwa Anda menggunakan lebih banyak data daripada yang Anda bayangkan (dan tentunya jauh lebih banyak dari yang Anda rencanakan!). Beberapa taksi, dan situs web pizza — seberapa mahal situs web pizza itu lagi?

Anda memasukkan situs web pizza ke WebPageTest dan memeriksanya di koneksi seluler:

44MB video . Dari mana asalnya? Bahkan lebih dari itu, ketika kita memeriksa sumber dan air terjun sedikit lebih detail, kita dapat melihat bahwa sebenarnya ada dua video! Untungnya (atau sayangnya?), tidak ada yang berhasil diunduh seluruhnya:

Hal ini menimbulkan beberapa kekhawatiran dan beberapa pertanyaan.

Pertama, mengapa begitu banyak video yang diunduh padahal tidak diputar otomatis? Kami belum berhasil mengklik apa pun, tetapi sudah menggunakan hampir 40 MB data. Jawabannya, seperti biasa, terletak pada sumbernya. Nah, "lihat sumber", yaitu.

 <video class="video-js vjs-big-play-centered" controls preload="auto" width="1050" height="591" poster="assets/home_poster.jpg" data-setup='{"fluid": true}'>
  <source src="assets/home_1.mp4" type='video/mp4'> <source src="assets/home.webm" type='video/webm'>
  <p class="vjs-no-js">To view this video please enable JavaScript, and consider upgrading to a web browser that <a href="https://videojs.com/html5-video-support/" target="_blank">supports HTML5 video</a></p> </video>

Dari kelelawar, kita melihat setidaknya dua masalah:

• pramuat = "otomatis"
  Saat kami menyetel preload="auto" , kami mengesampingkan setelan default browser, memberlakukan pengunduhan video — baik pelanggan Anda telah menekan "Putar" atau tidak. Atribut preload default adalah metadata , dan akan menghasilkan beberapa unduhan 100KB. Memang, ini adalah hasil yang jauh lebih baik bagi pengunjung situs yang tidak akan pernah menonton video ini.
• Pesanan Video
  Jika Anda memiliki beberapa versi video (dalam hal ini: video yang disandikan h264 .mp4 dan VP8 .webm), browser akan memilih video pertama yang dapat diputar. Sekarang, setiap browser modern mendukung mp4, sementara sebagian besar browser modern juga mendukung webm (95,4% dukungan global, menurut CanIUse).

Salah satu trik yang saya suka gunakan adalah menyisipkan baris sumber video yang sesuai dengan Javascript. Dengan begitu, jika Anda memilih untuk tidak menayangkan video di layar tertentu, Anda hanya memiliki tag <video> kosong — dan tidak ada video yang dapat diunduh.

window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 992){ videoLocation.setAttribute("autoplay",""); }; }
window.onload = addAutoplay(); var videoLocation = document.getElementById("hero-video"); function addAutoplay() { if(window.innerWidth > 992){ videoLocation.setAttribute("autoplay",""); }; }

Jika sekarang kami menjalankan ffprobe pada kedua video ini, kami akan menemukan perbedaan ukuran yang signifikan:

Webm 90% lebih kecil, namun memiliki 0 tampilan , karena setiap browser mendukung mp4. Kedua video ini sama-sama berukuran 640×360, dan panjang 140-an. Menjalankan perintah ffmpeg dari atas pada mp4 menghasilkan video 12,4 MB, jadi kemungkinan pengembang mengikuti proses serupa untuk mengompresi dan menyandikan varian .webm juga. Mungkin memiliki preload="auto" untuk 12,5 MB tidak akan terlalu buruk.

Video kedua (rekaman drone di dalam restoran) difilmkan dalam Full HD (1080p), tetapi juga dikompresi dari 140MB menjadi 35 MB. Jadi, 120-an dengan FFMPEG dapat mengurangi bobot video di halaman ini dari 160 MB menjadi 57 MB. Membalik urutan webm/mp4 akan menghemat beberapa MB tambahan untuk 95% browser yang dapat mendukung format tersebut.

Bagaimana jika kita ingin melakukan yang lebih baik, mungkin membuat video responsif terhadap berbagai ukuran layar? Nah, mari kita buat video yang lebih kecil — dengan video responsif!

Tag <video> tidak mendukung kueri media untuk menyajikan file video yang berbeda ke layar yang berbeda, jadi kami memerlukan cara berbeda untuk menyediakan ukuran video untuk layar perangkat. Cara termudah untuk mencapainya adalah dengan menggunakan video streaming . Ini akan menambahkan beberapa Javascript dan aset lain untuk pemutar video yang akan diperlukan, tetapi penghematan video pasti akan menggantikan data ekstra ini.

Kita dapat membuat aliran video dengan FFMPEG (saya telah menggunakan skrip bash seperti ini di masa lalu), tetapi ini mengharuskan kita untuk mengetahui semua ukuran dan pengaturan yang ingin kita gunakan (dan seperti yang disebutkan sebelumnya, FFMPEG memiliki banyak pengaturan! ).

Untuk mempermudah streaming video, ada API (misalnya api.video dan Mux) tempat Anda mengunggah video, dan alat ini membuat streaming video dan menghosting video untuk Anda. Untuk pengungkapan penuh, saya bekerja di yang pertama, jadi untuk menyederhanakan saluran pemrosesan video saya, saya akan menggunakan api.video, untuk mentranskode dan meng-host video saya. Dengan API unggah, saya dapat mengunggah video apa pun, dan alat ini akan membuat versi streaming pada berbagai dimensi dan kecepatan bit (saat ini 240p, 360p, 480p, 720p, 1080p, dan 4K).

Bitrate untuk video yang lebih kecil sangat berkurang, karena dimensi video berkurang. Ini berarti bahwa video akan membutuhkan lebih sedikit kapasitas jaringan pada layar yang lebih kecil dan akan diputar di jaringan yang lebih lambat.

Untuk singkatnya, kami hanya akan menguji video patch Labu. Saya telah menerima hasil yang serupa dengan video drone (video pizza lainnya hanya 360p, jadi tidak terlalu diuntungkan dari ukuran yang lebih kecil).

Catatan : Harap diingat bahwa video ini saat ini adalah video mp4 1080p pada 60fps, dan beratnya 157 MB untuk semua pengunjung.

Dengan beberapa pengoptimalan (CRF 28 dan mengurangi kecepatan bingkai menjadi 30fps), video dikurangi menjadi 35,7 MB . Menggunakan DevTools, kita dapat mengemulasi perangkat untuk melihat berapa banyak data yang digunakan untuk pemutaran video streaming video pada layar berukuran berbeda.

Tabel di bawah ini menunjukkan jumlah total lalu lintas yang digunakan. Dengan video HLS, ada pemutar JavaScript, CSS, font, dll. yang menambahkan sekitar 1 MB overhead tambahan. Ini termasuk dalam total di bawah ini:

Pada 1080p, ada sekitar 4MB aset tambahan yang diunduh untuk streaming, tetapi untuk setiap ukuran lainnya, ada penghematan data yang signifikan tanpa kehilangan kualitas video. Video tidak hanya akan berukuran dengan benar untuk perangkat , tetapi juga lebih kecil kemungkinannya untuk macet, karena bitrate berkurang untuk perangkat yang kemungkinan besar berada pada koneksi seluler yang lebih lambat.

Streaming video menangani masalah framerate, ukuran video, dan kualitas — memastikan pemutaran cepat pada layar ukuran apa pun, dan jaringan kecepatan apa pun.

“

Keuntungan lain dari streaming video: jika jaringan lambat (atau tiba-tiba menjadi lebih lambat), pemutar dapat menyesuaikan video yang ditampilkan, dan memutar versi video dengan kualitas lebih rendah — memastikan pemutaran di perangkat — bahkan dalam kondisi jaringan yang buruk. (Anda dapat menguji berbagai video dengan StreamOrNot, sebuah proyek open source kecil yang telah saya rilis beberapa waktu lalu.

Sekarang, bukankah itu sedikit terlalu banyak di atas kepala? Tidak bisakah kita melakukan hal yang sama (lebih cepat) dengan YouTube atau Vimeo? Kami pasti bisa, tetapi kemudian kami tidak akan dapat sepenuhnya menghapus branding atau iklan dari video, belum lagi overhead skrip yang dimuat dalam iframe pemutar video. Plus, terkadang Anda mungkin ingin menggunakan video sebagai video latar belakang di halaman produk Anda, dan menghindari segala jenis pencitraan merek eksternal sama sekali.

Kesimpulan

Kami tidak menyebarkan gambar dari kamera kami langsung ke web, tetapi kami mengompres dan mengubah ukurannya untuk menyeimbangkan kualitas dan kinerja web. Hal yang sama harus dilakukan untuk file video juga. Video yang lebih kecil mulai diputar lebih cepat dan lebih jarang berhenti, meningkatkan pengalaman pengguna situs web.

Dalam artikel ini, kami telah melakukan beberapa langkah sederhana untuk mengoptimalkan video kami, misalnya dengan menurunkan kualitas dan framerate-nya. Kami juga melihat bagaimana streaming video memungkinkan kami membangun pengalaman video yang lebih responsif untuk web — secara otomatis menayangkan video dengan ukuran yang sesuai untuk layar perangkat.

Terima kasih telah membaca, dan jika Anda ingin mempelajari lebih lanjut, Anda mungkin ingin membaca lebih lanjut tentang praktik terbaik video di sini, di Majalah Smashing, dan di blog saya:

• Pemutaran Video Di Web: Keadaan Video Saat Ini (Bagian 1)
• Pemutaran Video Di Web: Praktik Terbaik Pengiriman Video (Bagian 2)
• Menyembunyikan Video Di Web Seluler