Cara menghindari roda mouse yang tersendat dan laju bingkai tidak rata di rekaman guliran

Roda mouse standar berputar per takik, dan setiap takik meminta halaman bergerak sejauh jarak tetap. Browser menghaluskan setiap langkah dengan animasi singkat, sehingga putaran roda yang terus-menerus menjadi rangkaian gerakan kecil yang melaju lalu berhenti. Di layar, mata memakluminya. Di video yang diputar di layar besar, itu terlihat tersendat.

• Solusi terbaik: jangan pakai roda mouse. Biarkan skrip menggulir halaman dengan kecepatan tetap; panduan gulir otomatis punya skrip yang bisa disalin.
• Jika terpaksa menggulir manual: roda yang berputar bebas atau trackpad yang diseret pelan dan stabil lebih baik daripada roda bertakik, tetapi tidak ada tangan yang bisa menjaga kecepatan selama dua puluh detik.

Banyak perekam bawaan, termasuk bilah alat tangkapan layar macOS dan QuickTime, hanya menulis bingkai saat ada yang berubah di layar. Itu menghemat ruang, tetapi jarak antarbingkai jadi tidak seragam, dan editor video serta sebagian pemutar menanganinya dengan buruk: bingkai digandakan atau dibuang agar pas dengan linimasa yang tetap, dan guliran pun bergetar.

• Rekam dengan alat yang menulis laju bingkai konstan, seperti OBS Studio, diatur ke 60 fps.
• Jika kamu sudah punya berkas dengan laju bingkai variabel, ubah ke laju konstan sebelum menyunting. Opsi “Constant Framerate” di HandBrake bisa melakukannya.

Guliran menggerakkan setiap piksel di setiap bingkai. Pada 30 fps, setiap bingkai melompat dua kali lebih jauh daripada pada 60, dan di halaman yang penuh teks lompatan itu terlihat oleh mata. 24 fps adalah laju film dan cocok untuk film; untuk halaman yang bergulir pada kecepatan berapa pun, laju ini terlihat paling tidak mulus di antara ketiganya.

Rekam dan ekspor pada 60 fps jika gerakannya yang utama. Turunkan ke 30 hanya demi berkas yang lebih kecil, dan perlambat guliran jika melakukannya. Sebagian besar alat membatasi laju bingkai GIF cukup rendah, jadi buat guliran GIF tetap pendek dan pelan.

Jika layarmu menyegarkan gambar pada 120 atau 144 Hz dan kamu merekam pada 60 fps, perekam hanya menyimpan kira-kira satu dari setiap dua bingkai, dan pada layar dengan refresh rate variabel bahkan tidak merata. Mengatur layar ke 60 Hz selama merekam membuat bingkai layar dan rekaman cocok satu lawan satu. Di Mac dengan ProMotion, setelan itu ada di Displays, Refresh Rate.

• Gambar yang dimuat belakangan didekode tepat saat masuk ke layar, dan pekerjaan itu mencuri bingkai. Gulir ke bawah lalu kembali sebelum merekam agar semuanya sudah termuat.
• Halaman dengan skrip berat yang terkait guliran, latar video, atau efek WebGL membebani komputer dengan keras. Tutup aplikasi dan tab browser lain.
• Merekam dan meng-encode sekaligus berebut CPU dengan halaman. Pakai encoder perangkat keras milik perekam jika tersedia.

Semua penyebab di atas berasal dari merekam gerakan secara real time di layar sungguhan. Renderer tidak melakukan keduanya. Website Scroll Video membaca halaman sekali, menunggu gambar dan font, lalu menghitung posisi halaman di setiap bingkai dan menggambarnya. Tidak ada roda yang bergerak bertahap, tidak ada laju layar yang harus dicocokkan, dan tidak ada tenggat yang bisa terlewat oleh sebuah bingkai, jadi hasilnya tetap terkunci di 24, 30, atau 60 fps, sepanjang atau seberat apa pun halamannya.