I Recorded 50 Hours of Screen Content with 8 Different Tools

# 8種類のツールを使って50時間の画面コンテンツを録画しました

録画したのは50時間、テストしたのは8つのツール、使用したのは3つのオペレーティングシステム。ファイルサイズは同一のコンテンツで2GBから47GBまで様々でした。CPU使用率は3%から40%まで。

これらの数字は、スクリーン録画ソフトウェアが多くのクリエイターが理解している以上に重要である理由を教えてくれます。私は6年間技術チュートリアルを制作してきましたが、先月だけで3つの異なるマシンで53時間の画面コンテンツを録画しました。録画が90分の時点で破損すると、映像を失うだけでなく、心の状態、完璧な説明、そのテイクを特別にした自発的な明確さまで失うことになります。

これは、各ツールを20分テストしたレビューではありません。私は、カーネルパニック、オーディオ設定をリセットするWindowsの更新、Linuxのディスプレイサーバーの移行を通じてこれらのアプリケーションと共に生きてきました。4Kのゲームプレイ、迅速なテキスト出力を伴うターミナルセッション、ある画面にコードを表示し、別の画面に文書を表示するマルチモニターワークフローを録画しました。各ツールは異なる方法で私を裏切り、一部はまったく失敗しませんでした。

背景: なぜこれほど多くのコンテンツを録画しているのか

私の仕事は、3つの異なるプラットフォーム向けの開発者チュートリアルを作成することに集中しています。一人のクライアントはVisual Studioのワークフローを示すWindows特有のコンテンツを求めています。もう一人は、MacとLinuxで同じように動作するクロスプラットフォームのコマンドラインチュートリアルが必要です。三番目は、UnityとUnreal Engineの高フレームレートキャプチャが必要なゲーム開発コンテンツを公開しています。

これは私がただ録画しているのではなく、制約の下で録画していることを意味します。30分のチュートリアルには、間違いや再説明、複雑なシーケンスの複数のテイクを勘案すると、90分の生素材が必要になるかもしれません。システム音声、マイク入力、時には両方を同時にキャプチャする必要があります。猫がキーボードを横切ったり、Windowsが更新をインストールすることを決定した場合でも、録画が生き残る必要があります。

技術要件はすぐに具体的になります。ターミナルセッションを録画しているときは、すべての文字が見える必要があります。圧縮アーティファクトで「rm -rf」が「rm -r#」に変わっては困ります。ゲームエンジンのビューポートをキャプチャしているときは、60fps以上でなければ、最終編集で動きがカクカクしてしまいます。ブラウザベースのツールを示すときは、カーソルが鮮明に表示され、どのボタンをクリックしているのか不明確なぼんやりとした塊にならないようにする必要があります。

私は6ヶ月前に、壊滅的な録画失敗の後、詳細な指標の追跡を開始しました。複雑なDockerネットワークチュートリアルを2時間かけてキャプチャしていて、サブネット構成やコンテナ通信パターンを説明していました。録画は成功したように見えました—ソフトウェアは47GBのファイルを示しました。しかし、エディタで開くと、その映像は復元不能なほど破損していました。73分マーク以降のすべてのフレームは緑のピクセルでした。

その失敗は私に締め切りを失わせ、「以前はうまくいった」というのはテスト方法論ではないことを教えてくれました。本当に現実的な使用パターンで生き残ったツールに関するデータが必要でした。どのツールが最高のマーケティングコピーを持っているかではなく。

3つのツールが同時に失敗した日

2月14日。この日付を覚えているのは、パートナーのためのバレンタインデーのプロジェクトを完成させようとしていたからで、クライアントの締め切りもあったからです。私は、ゲーム映像をキャプチャするWindowsデスクトップ、デザインワークフローを録画するMacBook Pro、サーバー構成を示すLinuxワークステーションで、3つの異なる画面録画を実行していました。

すべての録画は約45分間実行されるはずでした。私は数ヶ月間信頼していたツールを使って、以前にも問題なく実行していました。すべての録画を開始し、プレゼンテーションを始め、良いチュートリアルコンテンツが生まれる集中状態に入っていました。

最初に故障したのはWindowsのマシンでした。私はUnityでのテクスチャ最適化を説明する31分目に、録画ソフトがクラッシュしました。警告もエラーメッセージもありません—ただ消えてしまったのです。アプリケーションはタスクバーから消えました。再度開くと、回復ファイルも自動保存も何もありません。ノーマルマップの圧縮とミップマップ生成についての詳細な説明が31分分失われました。

私がまだWindowsの故障について知らなかったのは、Macの録画に集中していたからです。それは38分まで続き、ビーチボールが現れました。録画ソフトはフリーズしました。タイマーの更新が止まりました。マウスを動かしたりアプリケーションを切り替えたりすることはできましたが、録画ツールは完全にロックされていました。私は強制終了しました。結果として得られたファイルは破損しており—最初の12分を再生した後、残りの時間はフリーズしたフレームに飛びました。

Linuxの録画は実際に完了しました。47分のサーバー構成チュートリアルを完了し、録画を停止し、ソフトウェアは成功を報告しました。ファイルサイズは8.3GBと正しかったです。バックアップのためにNASにコピーしました。でも、その晩編集を開始しようと開いたとき、音声が完全に同期していないことに気づきました。最初はうまくいきましたが、20分の時点では、私の声が画面に現れないもう8秒間を説明していました。最後には、ずれが15秒以上になっていました。

3つの録画、3つの異なる失敗モード、3つの異なるツール。それが私が単一のソリューションを信頼するのをやめ、この体系的なテストプロジェクトを始めた日でした。

パフォーマンスデータ: 重要な数字

私は同じ30分のチュートリアルセグメントを、各ツールを1回ずつ、同一のハードウェアで8回録画しました。コンテンツはPythonのウェブスクレイピングチュートリアルで—ターミナル出力が多く、ブラウザとのインタラクションやコード編集も含まれました。私は次のようなことを測定しました:

ファイルサイズの変動は異常です。Camtasiaの47.3GBのファイルは、Windows Game Barの2.1GBのファイルと同じ視覚情報を含んでいました。両方とも30fpsで1080pでした。同じ30分のコンテンツをキャプチャしました。違いは、Camtasiaが編集用に設計された非圧縮フォーマットで録画しているのに対し、Game Barはハードウェア加速H.264エンコーディングを使用していることです。

CPU使用率は異なる物語を語ります。6コアプロセッサ上のKazamの40%のCPU使用率は、録画だけで2つのフルコア以上を消費していることを意味しました。その録画中、私はノートパソコンのファンが回り始めるのを聞くことができました。システムは重く感じました。録画しながらコードをコンパイルしようとしたとき、コンパイルに通常の3倍の時間がかかりました。

Windows Game Barの3%のCPU使用率は、ハードウェアエンコーディングの結果です。GPUの専用ビデオエンコーダーが圧縮を処理し、CPUは他のタスクのために確保されています。私はそのチュートリアルを録画している間にバックグラウンドでDockerコンテナビルドを実行していましたが—録画は完璧で、ビルドは正常な時間で完了しました。

ドロップフレームは静かな殺し屋です。ShareXの3つのドロップフレームはそれほど重要ではないように思えるかもしれませんが、それは高速なターミナル出力の中で、何百行も印刷するスクリプトをデモしているときに起こりました。ドロップフレームのため、テキストは跳ねるように見え、数行を一度にスキップしました。最終的な映像では、視聴者は出力を明確に読むことができませんでした。

Kazamの127のドロップフレームは、録画を使い物にできなくしました。ビデオは常にカクカクしていました。マウスの動きはスムーズではありませんでした。ウィンドウの切り替えがぎこちなく見えました。これは一度だけの誤りではありませんでした—私はKazamを3回テストしましたが、毎回フレームを落としました。

インサイト: データが示さないこと

"最高の録画ツールは、消えるツールです。録画を開始して30秒を過ぎたら、録画を忘れるべきです。"

これは、私がスクリーン録画ソフトウェアを評価する方法を変えたインサイトです。テーブルの数字は重要ですが、各ツールを使用する際の認知負荷を捉えてはいません。

OBS Studioは最も複雑なインターフェースを持っています。シーン、ソース、フィルター、オーディオミキサーがあります。最初に開いたときは、空白のキャンバスに直面します。