背景

背景

背景

Docker コンテナ内で、Selenium によって制御され、Chrome 上で実行されている WebRTC Web アプリケーションへの入力を制御しようとしています。

これは、WebRTC アプリケーションの自動テストの一部です。

テストの一環として、制御されたオーディオと(できれば制御された)ビデオを Docker で実行されている Chrome に送信したいと考えています。

私は既に持っています偽のオーディオデバイスを使用した制御可能なオーディオ入力ただし、これを使用すると、Chrome に「実際の」マイクが存在することになり、偽のデバイス機能を使用してビデオ入力をエミュレートできなくなります。Chrome
の --use-file-for-fake-audio-capture 機能は、--use-fake-device-for-media-stream もアクティブな場合にのみ機能し、システムのマイク入力へのアクセスが無効になります。

問題

Chrome で WebRTC ビデオ通話に使用できるように、Docker コンテナ内でウェブカメラをエミュレートする方法が必要です。
理想的には、その偽のウェブカメラの画像も制御できる必要があります。

Docker コンテナでホスト システム上のウェブカメラ デバイス (偽物を含む) を使用することに成功したという投稿をいくつか目にしましたが、これはホスト上の 1 つのデバイスへのマッピングであり、同じホスト上で複数の Docker コンテナ (20 個以上) を実行し、それぞれに固有のウェブカメラ デバイスを持たせたいのです。

これを行う標準的な方法は v4l2loopback ドライバーを使用することですが、これはカーネル モジュールであり、Docker はホストのカーネルを使用するため、コンテナー内に独自のモジュールをロードすることはできません。

理論的には、ホスト上に複数の偽のウェブカメラ デバイスを作成し、それらをそれぞれ Docker コンテナーにマップすることは可能ですが、それはロジスティックス上の悪夢です (テストではコンテナーと通信するのではなく、ホスト上のカメラを制御する必要があります)。また、v4l2loopback はいずれにしても 8 つのデバイスに制限されています (理論的には、ドライバーを再コンパイルしてさらにサポートすることもできます)。

私が本当に探しているのは、カーネル空間ではなくユーザー空間でウェブカメラデバイスを偽装する方法のようです。
私は、ユーザー空間のウェブカメラドライバーを見つけました。紫外線4Lただし、これは Raspberry Pi (ARM アーキテクチャ) 用です。

質問

ユーザー空間で偽のキャプチャ デバイスを使用するか、他の手段を使用して、Docker コンテナー内の Chrome のキャプチャ デバイスへのビデオを制御する方法を知っている人はいますか?

関連情報