I Recorded 50 Hours of Screen Content with 8 Different Tools

# Saya Merekam 50 Jam Konten Layar dengan 8 Alat yang Berbeda

50 jam direkam, 8 alat diuji, 3 sistem operasi. Ukuran file berkisar dari 2GB hingga 47GB untuk konten yang identik. Penggunaan CPU dari 3% hingga 40%.

Angka-angka tersebut memberikan informasi tentang mengapa perangkat lunak perekaman layar lebih penting daripada yang disadari oleh sebagian besar pembuat konten. Saya telah memproduksi tutorial teknis selama enam tahun, dan bulan lalu saja saya menangkap 53 jam konten layar di tiga mesin yang berbeda. Ketika perekaman rusak pada tanda 90 menit, Anda tidak hanya kehilangan rekaman—Anda kehilangan kondisi mental, penjelasan yang sempurna, kejernihan spontan yang membuat pengambilan itu istimewa.

Ini bukan ulasan di mana saya menguji setiap alat selama dua puluh menit. Saya telah mengalami aplikasi ini melalui panic kernel, pembaruan Windows yang mengatur ulang pengaturan audio, dan migrasi server tampilan Linux. Saya telah merekam gameplay 4K, sesi terminal dengan output teks yang cepat, dan alur kerja multi-monitor di mana satu layar menunjukkan kode sementara layar lainnya menampilkan dokumentasi. Setiap alat gagal dengan cara yang berbeda, dan beberapa tidak pernah gagal sama sekali.

Latar Belakang: Mengapa Saya Merekam Konten Sebanyak Ini

Hari kerja saya berputar di sekitar pembuatan tutorial pengembang untuk tiga platform yang berbeda. Satu klien ingin konten spesifik Windows yang menunjukkan alur kerja Visual Studio. Yang lain membutuhkan tutorial baris perintah lintas platform yang berfungsi identik di Mac dan Linux. Ketiga menerbitkan konten pengembangan game yang memerlukan tangkapan ber-framerate tinggi dari Unity dan Unreal Engine.

Ini berarti saya tidak hanya merekam—saya merekam di bawah batasan. Tutorial berdurasi 30 menit mungkin memerlukan 90 menit rekaman mentah setelah memperhitungkan kesalahan, penjelasan ulang, dan beberapa pengambilan dari urutan yang kompleks. Saya perlu menangkap audio sistem, masukan mikrofon, dan kadang-kadang keduanya secara bersamaan. Saya perlu perekaman bertahan jika kucing saya berjalan melintasi keyboard atau jika Windows memutuskan untuk menginstal pembaruan.

Persyaratan teknis cepat menjadi spesifik. Ketika saya merekam sesi terminal, saya perlu setiap karakter terlihat—tidak ada artefak kompresi yang mengubah `rm -rf` menjadi `rm -r#`. Ketika saya menangkap viewport mesin game, saya perlu 60fps minimal atau gerakan terlihat tersendat di edit akhir. Ketika saya menunjukkan alat berbasis browser, saya perlu kursor muncul dengan jelas, bukan sebagai blob buram yang membuat tidak jelas tombol mana yang saya klik.

Saya mulai melacak metrik rinci enam bulan yang lalu setelah kegagalan perekaman yang katastropik. Saya telah menghabiskan dua jam merekam tutorial jaringan Docker yang kompleks, menjelaskan konfigurasi subnet dan pola komunikasi kontainer. Perekaman tampak berhasil—perangkat lunak menunjukkan file 47GB. Ketika saya membukanya di editor saya, video itu rusak tidak bisa diperbaiki. Setiap frame setelah tanda 73 menit adalah piksel hijau.

Kegagalan itu membuat saya kehilangan tenggat waktu dan mengajarkan saya bahwa "itu berhasil sebelumnya" bukanlah metodologi pengujian. Saya membutuhkan data tentang alat mana yang sebenarnya bertahan dalam pola penggunaan dunia nyata, bukan hanya yang memiliki salinan pemasaran terbaik.

Hari Tiga Alat Gagal Secara Bersamaan

14 Februari. Saya ingat tanggalnya karena saya sedang berusaha menyelesaikan proyek Hari Kasih Sayang untuk pasangan saya sambil juga memenuhi tenggat waktu klien. Saya memiliki tiga perekaman layar yang berbeda berjalan di tiga mesin—desktop Windows menangkap footage game, MacBook Pro merekam alur kerja desain, dan workstation Linux menunjukkan konfigurasi server.

Ketiga rekaman seharusnya berjalan selama sekitar 45 menit. Saya telah melakukan ini sebelumnya tanpa masalah, menggunakan alat yang saya percayai selama berbulan-bulan. Saya mulai semua tiga rekaman, memulai presentasi saya, dan masuk ke dalam keadaan fokus di mana konten tutorial yang baik terjadi.

M mesin Windows gagal pertama. Saya sudah 31 menit menjelaskan optimisasi tekstur di Unity ketika perangkat lunak perekaman crash. Tanpa peringatan, tanpa pesan kesalahan—hanya hilang. Aplikasi itu lenyap dari taskbar saya. Ketika saya membukanya kembali, tidak ada file pemulihan, tidak ada auto-save, tidak ada apa-apa. 31 menit penjelasan mendetail tentang kompresi normal map dan pembangkitan mipmap, hilang.

Saya belum tahu tentang kegagalan Windows itu karena saya fokus pada rekaman Mac. Rekaman itu berhasil sampai 38 menit sebelum bola pantai muncul. Perangkat lunak perekaman membeku. Penghitung waktu berhenti memperbarui. Saya masih bisa menggerakkan mouse dan beralih aplikasi, tetapi alat perekaman terkunci sepenuhnya. Saya memaksa menutupnya. File hasilnya rusak—itu memutar 12 menit pertama, lalu melompat ke frame beku yang berlangsung selama sisa waktu.

Perekaman Linux sebenarnya selesai. Saya menyelesaikan tutorial konfigurasi server 47 menit, berhenti merekam, dan perangkat lunak melaporkan berhasil. Ukuran file tampak benar pada 8.3GB. Saya menyalinnya ke NAS saya untuk cadangan. Ketika saya membukanya malam itu untuk mulai mengedit, saya mendapati audio sama sekali tidak sinkron. Mulainya baik, tetapi pada tanda 20 menit, suara saya menjelaskan hal-hal yang tidak akan muncul di layar selama 8 detik lagi. Di akhir, desinkronisasi lebih dari 15 detik.

Tiga rekaman, tiga mode kegagalan yang berbeda, tiga alat yang berbeda. Hari itu saya berhenti mempercayai satu solusi apa pun dan memulai proyek pengujian sistematis ini.

Data Kinerja: Angka yang Penting

Saya merekam segmen tutorial yang sama selama 30 menit delapan kali, sekali dengan setiap alat, pada perangkat keras yang identik. Kontennya adalah tutorial web scraping Python—banyak output terminal, interaksi browser, dan pengeditan kode. Berikut yang saya ukur:

Variasi ukuran file sangat tidak masuk akal. File 47.3GB milik Camtasia mengandung informasi visual identik dengan file 2.1GB dari Windows Game Bar. Keduanya adalah 1080p pada 30fps. Keduanya menangkap 30 menit konten yang sama. Perbedaannya? Camtasia merekam dalam format tanpa kompresi yang dirancang untuk pengeditan, sementara Game Bar menggunakan pengkodean H.264 yang dipercepat perangkat keras.

Penggunaan CPU menceritakan kisah yang berbeda. Penggunaan CPU 40% Kazam pada prosesor 6-inti berarti ia mengonsumsi lebih dari dua inti penuh hanya untuk merekam. Selama perekaman itu, saya dapat mendengar kipas laptop saya berputar. Sistem terasa lambat. Ketika saya mencoba mengompilasi kode saat merekam, kompilasi memakan waktu 3x lebih lama dari biasanya.

Penggunaan CPU Windows Game Bar sebesar 3% adalah hasil dari pengkodean perangkat keras. Pengkode video GPU khusus menangani kompresi, membebaskan CPU untuk tugas lain. Saya merekam tutorial yang sama itu sambil menjalankan pembangunan kontainer Docker di latar belakang—perekaman sempurna, dan pembangunan selesai dalam waktu normal.

Frame yang hilang adalah pembunuh diam-diam. Tiga frame yang hilang pada ShareX mungkin tidak terdengar signifikan, tetapi kehilangan tersebut terjadi selama output terminal yang cepat ketika saya mendemonstrasikan skrip yang mencetak ratusan baris. Frame yang hilang membuat teks tampak melompat, melewatkan beberapa baris sekaligus. Dalam video akhir, pemirsa tidak dapat membaca output dengan jelas.

127 frame yang hilang pada Kazam membuat perekaman tidak dapat digunakan. Video tersebut selalu terasa tersendat. Gerakan mouse tidak halus. Transisi jendela tampak kasar. Ini bukan kebetulan sekali—saya menguji Kazam tiga kali, dan itu kehilangan frame setiap kali.

Wawasan: Apa yang Tidak Ditunjukkan oleh Data

"Alat perekaman terbaik adalah yang menghilang. Anda harus lupa bahwa Anda merekam dalam waktu 30 detik setelah memulai."

Itulah wawasan yang mengubah cara saya mengevaluasi perangkat lunak perekaman layar. Angka-angka di tabel itu penting, tetapi tidak menangkap beban kognitif dari menggunakan setiap alat.

OBS Studio memiliki antarmuka yang paling kompleks. Ada adegan, sumber, filter, dan mixer audio. Pertama kali Anda membukanya, Anda dihadapkan pada layar kosong.