I Recorded 50 Hours of Screen Content with 8 Different Tools

# Tôi đã ghi lại 50 giờ nội dung màn hình với 8 công cụ khác nhau

50 giờ đã ghi, 8 công cụ đã thử nghiệm, 3 hệ điều hành. Kích thước tệp thay đổi từ 2GB đến 47GB cho cùng một nội dung. Sử dụng CPU từ 3% đến 40%.

Những con số đó cho bạn thấy mọi thứ về việc tại sao phần mềm ghi màn hình lại quan trọng hơn hầu hết các nhà sản xuất nội dung nhận ra. Tôi đã sản xuất các hướng dẫn kỹ thuật trong sáu năm, và chỉ riêng tháng trước, tôi đã ghi lại 53 giờ nội dung màn hình trên ba máy khác nhau. Khi một bản ghi bị hỏng ở phút 90, bạn không chỉ mất đi hình ảnh—bạn mất đi trạng thái tinh thần, phần giải thích hoàn hảo, sự rõ ràng tự phát đã làm cho phần ghi này trở nên đặc biệt.

Đây không phải là một bài đánh giá nơi tôi thử nghiệm mỗi công cụ trong hai mươi phút. Tôi đã sống cùng với những ứng dụng này qua các sự cố kernel panic, các bản cập nhật Windows reset cài đặt âm thanh, và các chuyển đổi máy chủ hiển thị Linux. Tôi đã ghi lại gameplay 4K, các phiên làm việc của terminal với đầu ra văn bản nhanh chóng, và quy trình làm việc đa màn hình nơi một màn hình hiển thị mã trong khi một màn hình khác hiển thị tài liệu. Mỗi công cụ đã làm tôi thất vọng theo những cách khác nhau, và một vài trong số đó chưa bao giờ gây thất bại.

Bối Cảnh: Tại Sao Tôi Ghi Lại Nhiều Nội Dung Như Thế

Ngày làm việc của tôi xoay quanh việc tạo các hướng dẫn cho nhà phát triển trên ba nền tảng khác nhau. Một khách hàng muốn nội dung cụ thể cho Windows hiển thị quy trình làm việc của Visual Studio. Một khác cần các hướng dẫn dòng lệnh đa nền tảng hoạt động giống nhau trên Mac và Linux. Cái thứ ba xuất bản nội dung phát triển trò chơi yêu cầu ghi hình với tốc độ cao của Unity và Unreal Engine.

Điều này có nghĩa là tôi không chỉ ghi lại—tôi ghi lại dưới sự ràng buộc. Một hướng dẫn 30 phút có thể yêu cầu 90 phút hình ảnh thô sau khi tính đến sai sót, giải thích lại và nhiều lần ghi lại các chuỗi phức tạp. Tôi cần ghi lại âm thanh hệ thống, đầu vào từ micro, và đôi khi cả hai cùng lúc. Tôi cần ghi lại khi mèo của tôi đi ngang qua bàn phím hoặc khi Windows quyết định cài đặt bản cập nhật.

Các yêu cầu kỹ thuật trở nên cụ thể rất nhanh. Khi tôi ghi lại các phiên làm việc của terminal, tôi cần mọi ký tự đều rõ ràng—không có hiện tượng nén biến `rm -rf` thành `rm -r#`. Khi tôi ghi lại các cửa sổ của engine game, tôi cần tối thiểu 60fps hoặc chuyển động sẽ trông bị giật trong phiên chỉnh sửa cuối cùng. Khi tôi hiển thị các công cụ dựa trên trình duyệt, tôi cần con trỏ hiển thị sắc nét, không phải như một đốm mờ mà làm cho không rõ ràng nút nào tôi đang nhấn.

Tôi đã bắt đầu theo dõi các chỉ số chi tiết cách đây sáu tháng sau một sự cố ghi hình thảm khốc. Tôi đã dành hai giờ để ghi lại một hướng dẫn mạng Docker phức tạp, giải thích về cấu hình subnet và các mẫu giao tiếp container. Việc ghi hình trông có vẻ thành công—phần mềm hiển thị một tệp 47GB. Khi tôi mở nó trong trình chỉnh sửa của mình, video đã bị hỏng không thể phục hồi. Mỗi khung hình sau dấu mốc 73 phút toàn là điểm màu xanh.

Sự cố đó đã khiến tôi trễ hạn và dạy tôi rằng "nó đã hoạt động trước đây" không phải là một phương pháp kiểm tra. Tôi cần dữ liệu về các công cụ thực sự đã sống sót qua các mô hình sử dụng thực tế, không chỉ là những công cụ có bản sao tiếp thị tốt nhất.

Ngày Mà Ba Công Cụ Đã Đồng Thời Gặp Sự Cố

Ngày 14 tháng 2. Tôi nhớ ngày này vì tôi đang cố gắng hoàn thành một dự án Ngày Valentine cho bạn đời của mình trong khi cũng phải đáp ứng một hạn chót của khách hàng. Tôi đã có ba ghi hình màn hình khác nhau đang chạy trên ba máy—một máy tính để bàn Windows ghi lại hình ảnh trò chơi, một MacBook Pro ghi lại quy trình thiết kế, và một trạm làm việc Linux hiển thị cấu hình máy chủ.

Cả ba ghi hình đều dự kiến sẽ chạy trong khoảng 45 phút. Tôi đã làm điều này trước đó mà không gặp vấn đề gì, sử dụng các công cụ mà tôi đã tin tưởng trong nhiều tháng. Tôi bắt đầu cả ba ghi hình, bắt đầu các bài thuyết trình của mình, và chìm vào trạng thái tập trung nơi nội dung hướng dẫn tốt xuất hiện.

Máy tính Windows đã gặp sự cố trước tiên. Tôi đã 31 phút vào bài giải thích tối ưu hóa kết cấu trong Unity khi phần mềm ghi hình bị sập. Không có cảnh báo, không có thông báo lỗi—chỉ đơn giản là biến mất. Ứng dụng đã biến mất khỏi thanh tác vụ của tôi. Khi tôi mở lại, không có tệp phục hồi, không tự lưu, không gì cả. 31 phút giải thích chi tiết về nén bản đồ bình thường và tạo mipmap, đã mất.

Tôi chưa biết về sự cố Windows vì tôi đang tập trung vào ghi hình Mac. Cái này đã đạt 38 phút trước khi vòng tròn xoay xuất hiện. Phần mềm ghi hình đã bị treo. Bộ đếm thời gian không cập nhật nữa. Tôi vẫn có thể di chuyển chuột và chuyển đổi ứng dụng, nhưng công cụ ghi hình đã bị khóa hoàn toàn. Tôi đã buộc phải thoát. Tệp tạo ra đã bị hỏng—nó phát lại 12 phút đầu tiên, rồi nhảy đến một khung hình bị đông lại kéo dài trong thời gian còn lại.

Ghi hình trên Linux thực sự đã hoàn thành. Tôi đã hoàn thành hướng dẫn cấu hình máy chủ dài 47 phút, dừng ghi hình, và phần mềm báo cáo thành công. Kích thước tệp trông đúng là 8.3GB. Tôi đã sao chép nó vào NAS của mình để sao lưu. Khi tôi mở nó vào buổi tối để bắt đầu chỉnh sửa, tôi phát hiện âm thanh hoàn toàn không đồng bộ. Nó bắt đầu tốt, nhưng đến phút 20, giọng nói của tôi đang mô tả những điều không xuất hiện trên màn hình trong 8 giây tiếp theo. Cuối cùng, độ lệch đã vượt qua 15 giây.

Ba ghi hình, ba chế độ thất bại khác nhau, ba công cụ khác nhau. Đó là ngày tôi ngừng tin tưởng vào bất kỳ giải pháp đơn lẻ nào và bắt đầu dự án thử nghiệm hệ thống này.

Dữ Liệu Hiệu Suất: Những Con Số Quan Trọng

Tôi đã ghi lại cùng một đoạn hướng dẫn dài 30 phút tám lần, một lần với mỗi công cụ, trên phần cứng giống nhau. Nội dung là một hướng dẫn thu thập dữ liệu web bằng Python—nhiều đầu ra terminal, tương tác trình duyệt, và chỉnh sửa mã. Đây là những gì tôi đã đo:

Sự thay đổi kích thước tệp là vô lý. Tệp 47.3GB của Camtasia chứa thông tin hình ảnh giống hệt như tệp 2.1GB của Windows Game Bar. Cả hai đều ở độ phân giải 1080p và 30fps. Cả hai đều ghi lại cùng 30 phút nội dung. Sự khác biệt? Camtasia đang ghi lại ở định dạng không nén dành cho chỉnh sửa, trong khi Game Bar đang sử dụng mã hóa H.264 tăng tốc phần cứng.

Sử dụng CPU cho một câu chuyện khác. Sử dụng CPU 40% của Kazam trên một bộ xử lý 6 lõi có nghĩa là nó tiêu tốn hơn hai lõi đầy đủ chỉ để ghi lại. Trong khi ghi hình đó, tôi có thể nghe thấy quạt của laptop quay mạnh. Hệ thống cảm thấy chậm chạp. Khi tôi cố gắng biên dịch mã trong khi ghi hình, thời gian biên dịch mất gấp 3 lần bình thường.

Sử dụng CPU 3% của Windows Game Bar là kết quả của mã hóa phần cứng. Bộ mã hóa video chuyên dụng của GPU xử lý quá trình nén, để lại CPU tự do cho các tác vụ khác. Tôi đã ghi lại hướng dẫn đó trong khi chạy một phiên xây dựng container Docker ở nền—việc ghi hình hoàn hảo, và quá trình xây dựng hoàn tất trong thời gian bình thường.

Các khung hình bị bỏ qua là kẻ giết người thầm lặng. 3 khung hình bị bỏ qua của ShareX có thể không nghe có vẻ quan trọng, nhưng những lần bỏ lỡ đó xảy ra trong quá trình đầu ra terminal nhanh chóng khi tôi đang minh họa một kịch bản in ra hàng trăm dòng. Các khung hình bị bỏ qua khiến văn bản trông như đang nhảy, bỏ qua nhiều dòng cùng một lúc. Trong video cuối cùng, người xem không thể đọc đầu ra một cách rõ ràng.

127 khung hình bị bỏ qua của Kazam đã làm cho việc ghi hình trở nên vô dụng. Video luôn bị giật. Các chuyển động chuột không mượt mà. Các chuyển đổi cửa sổ trông bị cắt khúc. Đây không phải là một sự cố một lần—tôi đã thử nghiệm Kazam ba lần, và nó đã bỏ khung hình mỗi lần.

Nhận Thức: Những Gì Dữ Liệu Không Cho Thấy

"Công cụ ghi hình tốt nhất là công cụ mà bạn quên đi đang ghi." Bạn nên quên rằng bạn đang ghi sau 30 giây kể từ khi bắt đầu."

Đó là nhận thức đã thay đổi cách tôi đánh giá phần mềm ghi hình. Các con số trong bảng đó quan trọng, nhưng chúng không thể hiện được khối lượng nhận thức khi sử dụng từng công cụ.

OBS Studio có giao diện phức tạp nhất. Có các cảnh, nguồn, bộ lọc và mixer âm thanh. Lần đầu tiên bạn mở nó, bạn sẽ gặp phải một màn hình trắng trống.