問題タブ [grafika]

Google の Grafika リポジトリに依存するライブ ストリーミング API を使用しています。私は Grafika EGLSurfaceBase の saveFrame メソッドを使用して、ユーザーがストリーミング中にビデオの静止画をキャプチャできるようにしています。

https://github.com/google/grafika/blob/master/src/com/android/grafika/gles/EglSurfaceBase.java

実際のキャプチャは機能しますが、一部のカメラの向きでは明らかに画像が反転します。

OpenGL テクスチャから取得した反転ビットマップに関連する多くの質問を見つけましたが、ほとんどは描画された画像を参照し、次のいずれかに依存しているようです。

a) OpenG でテクスチャを反転します。しかし、私の場合、ライブ ストリーミング API を使用しているため、テクスチャを反転して画像をキャプチャすると、実際にはビデオ ストリームでも画像キャプチャが反転する可能性があります。

また

b) リソースに基づいて生成された後にビットマップを反転する。私の場合、リソースがありません。バイトバッファからビットマップを作成しているので、複製して反転させたくありません。

API が持つ基本的な EGLSurfaceBase メソッドは次のとおりです。カメラの向きをそれに渡しますが、私の質問は次のとおりです。

私の好ましい解決策は、BMP.createbitmap の前に (または同時に) 画像を反転する方法を見つけることです。たとえば、マトリックスを使用して、ピクセルの読み取り値を glReadPixels で反転できますか?

別のメモ/考え: 作成後にビットマップを反転するコストは些細なことかもしれません。これはユーザーの操作に依存しているため、メモリ エラーが発生するほど頻繁に発生しないからです。

ビデオにいくつかの効果を適用するために OpenGl を使用しています。これは 2 つの場所で発生します。1 つはビデオの再生中、もう 1 つはこのビデオを別のファイルとして保存中に発生します。プレビュー部分 (ビデオの再生) は正常に動作しますが、ビデオの保存部分ではシェーダーが作成されません。

シェーダー作成呼び出し、

ほとんどの場合 0 を返し、ときどきシェーダーを作成します。

私は OpenGl を初めて使用しますが、私の理解では、シェーダーを作成するための依存関係はないと思います。誰かがこれで私を助けてくれませんか。

MediaCodec と Muxer を使用して GLSurfaceView に GL レンダリングを記録するアプリの記録コンポーネントを開発しています。fadden ( bigflakeや Grafika など... fadden に感謝)による素敵な例のセットを見つけて、それらを試してみました。私たちのアプリは GLSurfaceView を使用してレンダリングを行ったため、Android Breakout のゲーム記録モデルに基づいてレコーダーを作成しました。

私のNexus 7（2013年4.4.2および5.0.2）ではうまく機能しているように見えました。レンダリングされた画面を記録することができ、それらのエンコードされた MP4 は他のデバイスでうまく再生されました。ただし、もう少し複雑なレンダリングが必要になると、フレームがドロップし始めました。フレームのレンダリングには約 4 ミリ秒しかかからないため、それほど複雑ではありません。だから、私は問題の原因を特定しようとしてきました。

私の疑似コードは、Android Breakout Recorder と非常によく似ています。OnDrawFrame() は次のようになります。

行ごとの呼び出しのパフォーマンスを測定しようとしたところ、Nexus 7 でrecorder.swapBuffers() に約 10 ミリ秒かかることがわかりました。バッファーの移動にはそれだけの時間がかかる可能性がありますが、これは妥当だと思います。もう 1 つは、recorder.makeCurrent() で、予想よりも時間がかかりました。これにはさらに 10 ミリ秒かかります。

また、onDrawFrame() の呼び出し間隔を測定しようとしていました。記録がオフのとき (recordThisFrame() 設定を false に設定)、一貫して 16.7 ～ 17 ミリ秒でした。これは予想どおりです。recordThisFrame() が true と false を交互に切り替えて 1 フレームおきに記録するように設定されている場合、約 22 ～ 25 ミリ秒 (記録時) と 4 ～ 10 ミリ秒になります。drawFrame() 呼び出しを単純な glclear() に変更した後でも、同じ結果が得られました。これを Android Breakout Recorder (fadden のオリジナル コード) で試したところ、同じ結果が得られました。

Grafika で「FBO を使用して GL アプリを記録する」アクティビティを試していたところ、記録でも 16 ～ 17 ミリ秒の間隔がより一貫していることがわかりました。Grafika の Record GL アプリのように、GLSurfaceView を SurfaceView に置き換えたいと思いましたが、その変更は今のところ実行可能なオプションではないようです。

makeCurrent() 呼び出しはそれほどコストがかかるのですか? 同様の間隔の問題が発生している人はいますか? 任意の考えをいただければ幸いです。

OpenGL を使用してビデオに視覚効果を適用しています。エフェクトは、 Grafika、CameraCaptureActivityで機能するのと同じように、ビデオ プレビューとファイルに保存される部分に別々に適用されます。

これは Nexus 5 では問題
なく動作します。一方、Moto G2 ではプレビューは問題なく動作しますが、保存されたビデオには黒いフレームしかありません。
各フレームの OpenGL 効果適用部分は、プレビューと保存の両方で共通のクラスで発生し ます (これらは別のオブジェクトですが)。

OpenGL プログラムに送信されているデータを確認しましたが、有効なデータが含まれているようです。

誰もそのような問題に遭遇しましたか?

私の目標は、複数のビデオ ファイルからビデオ フラグメントを接合することです。フラグメントは、任意の開始時間と終了時間によって定義されます。最初は mp4parser のようなライブラリを使用して実行したかったのですが、同期 (IFRAME) ポイントでしかストリームをカットできませんが、より高い精度が必要です。

私のシナリオは、ファイルからエンコードされたストリームを抽出する->デコード->エンコード->結果をmp4ファイルに多重化することです。現在、一般的にコードは機能しますが、結果のビデオはホワイト ノイズです。Nexus-S および Galaxy-S3 でテスト済み。私のコードは、いくつかの例を組み合わせたものです。

• MoviePlayer.java に基づいて以前に記録されたファイルを読み取る
• デコード-エンコード: DecodeEditEncodeTest.java
• ビデオ ストリームを mp4 に多重化する - さらに別の例ですが、ここでは関係ありません

途中でフレームを処理する必要がないため、例を単純化したいと思います。Surface を介さずに、デコーダー出力からエンコーダー入力にバッファーを供給しようとしました。全体的なプロセスは、コードが完了するまで実行され、再生可能なビデオ ファイルが生成されるという意味で機能しました。ただし、ファイルの内容はホワイト ノイズです。

これは、フレームをデコーダーからエンコーダーに送るコードのスニペットです。何が間違っていて、それを機能させる方法は?