オープンソースを使用してMac OS X画面からビデオを録画する

プログラムのデモを記録する必要がある場合もありますが、適切なツールが手元にありません。 さらに、これらの目的のための無料のユーティリティはまったく見つけることができず、有料のユーティリティは正しく実行できるという事実ではありません。 コメントで修正したように、QuickTime Playerの通常バージョンは素晴らしいビデオを作成します。 さらに、オープンソースで珍しいソリューションのファンにのみ読むことをお勧めします。

私の場合、iPhoneとAndroidシミュレーターでゲームの動作を記録する必要がありました。 私の中のプログラマーはすぐに、iOS / Android、およびMac自体の両方のコードを書いて、OpenGLなどを介してフレームをダンプすることを提案しました。これらの衝動を止めて、既製の解決策を見つけて、ここにメモとして記事を書くことにしました。

前戯

フォーラムを検索したところ、同様のタスクを持つ人々は、キャプチャ機能を備えた特殊なプログラム（QuickTime Proなど）を購入する人と、同じプログラムのハッキング/試用版/ベータ版を使用する人の2つのカテゴリに分かれています。 もう少し掘り下げてみると、x11grabモジュールがffmpegに追加されて以来、Linux / Unixの世界ではそのような問題はまったくないことがわかりました。 このモジュールはXアプリケーションのバッファーをインターセプトし、ffmpegを介してビデオを中間形式（qtrle、raw、x264ロスレスなど）に圧縮します。 MacにもXサーバーがありますが、Linuxから移植されたプログラムのみが、Cocoa出力情報に適合していません。 これが私の実験の出発点でした。

ツール：ffmpeg + x11grab + Xvfb

ffmpegのMacPortsには、x11grabモジュールが基本的にありません。 最初の試行のソースからはずっとうまくいかなかったので、ffmpeg-develのポートファイルにパッチを適用することにしました。

/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/multimedia/ffmpeg-devel/Portfile





そこで、nonfree構成で、行--enable-x11grabおよび--enable-sharedを追加してx11grabをアクティブにしました。

先を見て、このメソッドには欠陥があったと言います。なぜなら、編集してポートファイルをアップロードするのではなく、参照のためにここで説明するだけだからです。



Xプログラムがセッション（ディスプレイ）に表示される場合：デフォルトでは0.0で、主に画面サイズ（iMacでは2560x1440）、およびおそらくグラフィックのレンダリングが原因で、ビデオ録画のフレームレートが小さくなります。小さな解像度の仮想ディスプレイのプログラム。 これは、ポートから簡単にインストールできるXvfbプロジェクトを通じて行われます。

ターミナルを介して非常に単純に開始します（マージンのあるサイズ）：

Xvfb :1 -screen 0 1024x800x15 -shmem







また、この仮想ffmpegディスプレイに接続するだけです。

ffmpeg -r 30 -s 1024x768 -f x11grab -i :1.0+0,20 -vcodec qtrle target.mov







この段階で、共有メモリオーバーフローのエラーを待っていました。これは、何らかの理由でOS Xでわいせつな値4mbに設定されていました。 サイズの一時的な増加については、 サーバーに関するAppleの推奨事項、および他の情報源で説明されています 。

sudo sysctl -w kern.sysv.shmmax=67108864

sudo sysctl -w kern.sysv.shmall=67108864

VirtualBoxセッションの記録

次のステップでは、Xサーバーを介して有用なものを出力することにしました。 最初の考えは、VirtualBoxのXバージョンを構築し、文字通りすべてを表示することでしたが、ポピーのVirtualBoxは行き止まりだったため、長い間Co​​coaに移行しました。 2番目の一般的な考えは、RDPを介して仮想マシンに接続し、rdesktopセッションを記録することでした。VirtualBoxの下でRDPをアクティブ化するのは非常に簡単ですが、公式サイトからExtension Packをインストールする必要があります。

画面出力付きのrdesktopの接続：0.1

DISPLAY=:1.0 rdesktop -xl localhost







これらの手順の後、ffmpegは.movファイルへのビデオの書き込みを正常に開始します。 私の場合、Android x86のアームで正常に検出されました。





残念ながら、ビデオはかなりぴくぴくしていることが判明し、RDP圧縮が影響します。そのため、アニメーションはそのように撮影するのにはあまり適していません。



次のステップでは、RDPからVNCに切り替えることにしました。 VirtualBoxにはVNCサーバーが組み込まれていますが、パブリックビルドではなく、ポートまたはソースコードからコンパイルされています。 ポートを操作する必要はありませんでした。virtualboxポートを作成した後、バージョン4.1.14を入手できました。







不快な瞬間は、VNCがインターフェイスを介してアクセスできず、ヘッドレスモードで起動した場合のみでした。

VBoxHeadless -startvm 'Android x86' -v on --vnc





このモードは、2番目のVNCセッションを介して、またはRDPを介して再度管理する必要がありますが、これはあまり便利ではありませんが、通常は許容範囲です。 VNCストリームをキャプチャするために、vncviewerが使用され、仮想Xディスプレイにリダイレクトされました。

vncviewer localhost -ViewOnly -display :1.0 -PreferredEncoding raw -FullColor







これらすべてのフリルの結果は、1024x768の解像度で正直な30 fpsの5分間のビデオでした。



（コンテンツの品質について事前に謝罪しますが、私はまだプロのプレーヤーではありません）



よく見ると、数秒間の一時停止が目立つことがあります。 残念ながら、この問題に打ち勝つことはできず、アプローチ自体はかなり厄介であることが判明しました。 Androidでのゲームの最も簡単なデモンストレーションでは、次のタスクであるiPhoneのビデオシミュレーターの撮影に切り替えたため、これで十分です。

フルスクリーンVNCキャプチャ

OS Xには、ARDとVNCの2つのプロトコルで同時に動作する組み込みのリモートアクセスがあります。 Lion 10.7のリリース前は、システム設定で画面共有を有効にして、VNCクライアントで現在のセッションに接続できました。 10.7から、重大な変更が始まりました：ZRLEを除くすべてのタイプの圧縮がスローされ、すべてのクライアントが接続できるわけではなく、接続後に灰色のログイン画面が表示され、ユーザーパスワードを入力した後にのみセッションに接続します。 これは管理者にとっては素晴らしいことですが、私の仕事にとっては、それどころか、障害物を作成しただけです。 最新バージョンのvncviewerプログラム（別名RealVNC）はOS Xへの接続方法を既に知っていますが、ユーザーパスワードの入力方法を知らないため、このパスも行き止まりになりました。

別の方法として、TestPlant（osxvncおよびVine）から無料のVNCサーバーを取得しました。 sourceforgeを備えたバージョン3.0は非推奨です。そのため、ソースから新しいバージョンをビルドするか、 TestPlant Webサイトから取得する必要があります。



このサーバーの取るに足らないバグは、「不明なメッセージタイプ131」というエラーでクライアントが時々消えることです。 サーバーを再起動することで処理されます。



ffmpeg + x11grab + Xvfbおよびvncviewerがすでに確立されているため、iPhoneシミュレーターが実行されている現在のOS Xセッションのフルスクリーンビデオを撮影することが判明しました。





私が選んだ仮想バッファのサイズは、左上隅を撮影するために画面解像度より明らかに低かった。 結果は非常に価値がありましたが、残念ながら、FPSが低く、ゲーム内のアニメーションは率直に遅くなりました。 さらに、VirtualBoxの回路図では非常にまれであった一時停止が、より顕著になりました。

この段階で、いくつかの実験を行い、VNCサーバーとクライアントをソースから再構築し、最小画面解像度を設定しましたが、それでも良い結果は得られませんでした。 数時間後、サーバー自体が少し遅れてフレームを送信していることが明らかになりました。 コードを掘り下げた後、画面の更新の間にサーバーが意図的に一時停止することがわかりました。

  /* OK, now, to save bandwidth, wait a little while for more updates to come along. */ /* REDSTONE - Lets send it right away if no rfbDeferUpdateTime */ if (rfbDeferUpdateTime > 0 && !cl->immediateUpdate && !cl->needNewScreenSize) { pthread_mutex_unlock(&cl->updateMutex); usleep(rfbDeferUpdateTime * 1000); pthread_mutex_lock(&cl->updateMutex); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

rfbDeferUpdateTime変数の初期値は40ミリ秒ですが、これは非常に制御可能であり、コマンドラインで設定されます。 Vine Server自体には、これに関する別のフィールドがあります。



マージンを15に設定すると、最大フレームレートは66 fpsになります。 その後、遅延は停止しましたが、ビデオには顕著な休止がありました。 理論的には、そのようなビデオからそれらをカットし、受け入れられるものを組み立てることができますが、より普遍的なソリューションが必要でした。

スリーブアップ：vnc2flv

今、私は優れた品質のvnc形式のビデオストリームを手に入れました。それはファイルに書き込むだけでした。 私は再び、独自のダンパーを作成するという元のプログラミングの欲求を抑制し、インターネットの腸でvnc2swfプロジェクトを見つけ、その後継のvnc2flvを見つけました 。 Pythonのグラバーに対する懐疑的な態度は、最初の結果の直後に通過しました-プログラムは、15 + fpsでロスレス品質とWQHD解像度でビデオストリームを記録します！ Xvfbで倒錯せずに起動し、VNCサーバーに直接接続します。

flvrec.py -r 30 127.0.0.1







fpsを上げるには、解像度を1280x720に下げるだけです。 興味深いことに、Vine VNCを再起動すると、現在の画面解像度がキャプチャされ、ネイティブ解像度に安全に切り替えて記録を有効にできます。

vnc2flvのインストールは非常に簡単で、サイトで説明されています。ここには特別な落とし穴はありません。

完成したビデオは、お気に入りのビデオエディターで処理し、余分な部分をトリミングして、目的の形式に変換できます。 私はワインの下で実行されているVirtualDubを使用していますが、これはすでに習慣の問題です。





この叙事詩全体の結果は次のとおりです。



ビデオは、ぎくしゃくせずに非常に鮮明です。 アニメーションは正常に記録されました。 私に関しては、Mac OS画面の文字通り何でも使用して記録することができます。 文字通り、カーソルだけが欠落していますが、とにかく生き残ることができます。

あとがき：行き止まりの枝

誰かが自分のメソッドを検索する場合に備えて、ここで私が出会った行き止まりと熊手をリストします。



VLC Player -OS X 10.7以降では、画面からビデオを録画できません

CaptureMe-クラッシュし、空のビデオを書き込みます

iPhoneシミュレーター用のSIMBLプラグイン -コード内のシミュレーターバージョンの変更と再構築が必要で、iPadビデオを書き込まず、通常はまったく機能しませんでした

osxvnc 3.0 with SourceForge-10.7でクラッシュ

RealVNC Server-ライセンスキーが必要です

VirtualBox、ビデオ録画モード -3年前に亡くなりましたが、サポートされておらず動作しません

ffmpeg + x11grab-有望で柔軟性がありますが、ビデオで不治の休止を与えます。 ここに、私がこのアイデアを取り入れたブログへのリンクがあります。

Apple HTTPライブストリーミング -ストリーミングツールなし