問題タブ [grafika]

MAX_LENGTH設定できる値があります。その値は録音をほぼ制限します..時々、最大で2倍になることがあります。の値MAX_LENGTHを 15 に設定してアプリを起動し、記録を開始すると、その制限を超えて 30 になることがあります。その制限メカニズムは壊れています..それを超えないようにハード制限する方法はありますMAX_LENGTHか? ありがとう

適用されたエフェクトのライブ プレビューを表示しながら、CameraCaptureActivity がビデオを記録するデモアプリGrafika について言及しています。

CameraCaptureActivity での記録中に、カメラからのフレームに適用される効果は 2 回実行されます。
プレビュー用に 1 回、ビデオをファイルに保存するときに 1 回。

プレビューされている同じフレームがファイルに保存されるため、これを 1 回だけ行うことができれば、多くの処理を節約できます。

フレームのレンダリングは、2 つのサーフェスで直接行われます。1 つは GLSurfaceView (プレビュー用) で、もう 1 つは MediaCodec (保存部分) です。

OpenGL 効果を一度だけレンダリングする方法はありますか?

1 つのサーフェスの内容を別のサーフェスにコピーできれば、それは素晴らしいことです。
これを行う方法はありますか？

2 つのビデオを同時にデコードして再生したいと考えています。私のコードはそれほど複雑ではありません。以下のデコーダー構成部分を見ることができます。google/grafikaの MoviePlayerに基づいています。

これは 1080p までのビデオでは問題なく動作しましたが、4K ビデオを再生しようとすると、2 番目のデコーダがエラーで構成できませんでした:

デコーダーを1つだけ残せば、4K動画でも問題なく動作します。この質問でいくつかの議論を見つけましたが、それが私の問題に関連しているかどうかはわかりません。これが Samsung Galaxy S6 と Samsung Galaxy Note 4 で発生することを確認できます

。2 つのデコーダーを 4K ビデオで動作させる方法はありますか?

最近、Android 5.0.2 (API 21) で奇妙な問題が発生しました。私のアプリケーションは、SurfaceTexture を使用してビデオを表示しています。再生メカニズムは主にgoogle/grafikaの CameraCaptureAvtivity に基づいていますが、ビデオ ソースはカメラではなく .mp4 ムービー ファイルにデコードされます。このアプリケーションは、Android 5.0.2 を搭載した Galaxy S6 で実行するまで問題なく動作していました (それ以前は、4.4.2 および 4.4.4 のデバイスを正常に使用していました)。問題は、SurfaceTexture からタイムスタンプを取得しようとするたびにgetTimestamp()、メソッドが 0 を返すことですが、再生は問題ありません。タイムスタンプが正しい前に言及した他のデバイスでは。
これが Android のバグであるかどうか教えてもらえますか? それを回避する方法はありますか？

Grafika の ContinuousCaptureActivity を参考に、MediaCodec で動画を録画するデモを実装しました。ほとんどの場合、デモは正常に動作しましたが、戻るキーを押すと GT-I9500 デバイスでクラッシュしました(アクティビティが破棄されたと仮定したため、このクラッシュは検出できませんでした。「adb shell ps」を使用してデモ プロセスの存在を確認しました)。その後、ソース コードを繰り返しチェックしたところ、コードが grafika の ContinuousCaptureActivity とほぼ同じであることがわかりました。そこで、次のことを行いました。

1. GT-I9500 デバイスに grafika の apk をインストールし、ContinuousCaptureActivity を起動してから、携帯電話の戻るキーを押しましたが、アプリケーションはクラッシュせず、grafika が正常に動作することがわかりました。

2. コードをもう一度確認しましたが、疑わしいものは何も見つかりませんでした。

3. 新しい Android プロジェクトを作成し、Grafika から ContinuousCaptureActivity.java と AndroidManifest.xml、activity_continuous_capture.xml などのその他の必要なファイルを新しいプロジェクトにコピーしました。AndroidManifest.xml を変更して、ContinuousCaptureActivity をメイン アクティビティにしました。コードをコンパイルし、APK を GT-I9500 デバイスにインストールしました。同じことが起こりました。戻るキーを押した後、アプリケーションがクラッシュしました!!!

私はこの問題に本当に困惑しています。なぜ grafika は正常に動作したのに、新しいプロジェクトの同じコードがクラッシュしたのですか? とにかく、grafika が正常に動作したため、デモのクラッシュに対する解決策があると思います。誰かアドバイスをくれませんか？

私が提供できる情報は次のとおりです。

1. アプリケーションをデバッグし、クラッシュの原因となった正確なコードを見つけました。コードはhttps://github.com/google/grafika/blob/master/src/com/android/grafika/gles/EglCore.java#L191です

2. クラッシュは非常にひどいもので、tombstone ファイルは生成されず、adb ログは制限されていました。

06-15 14:39:33.853 I/ActivityManager( 771): プロセス com.example.grafikaaa (pid 13138) (adj 1) が停止しました。

06-15 14:39:33.853 W/ActivityManager( 771): 強制的に ActivityRecord を削除します{42a876c8 u0 com.example.grafikaaa/.ContinuousCaptureActivity}: アプリが停止し、状態が保存されていません .... ....

06-15 14:39:33.903 D/Zygote (209): プロセス 13138 がシグナルによって終了しました (11)

3. grafika の GlesInfoActivity で表示される自分のデバイスの情報は次のとおりです。

4:3カメラのプレビュー比率をではなく に設定すると、同じ距離でより大きなプレビュー フィールドが得られることがわかって16:9います。詳細は次のとおりです。

Android Camera API - 奇妙なズーム効果

しかし、opengl で Android カメラ プレビューを使用しているときに問題が発生しました。これは、以下で説明する 2 番目の方法です。

カメラ プレビューを実装するには、次の 2 つの方法があります。

1. OpenGL を使用しない従来の方法で、Camera.setPreviewTexture(SurfaceTexture texture)またはを使用するだけです。Camera.setPreviewDisplay(SurfaceHolder holder)
2. ContinuousCaptureActivityopenglの使い方は、プレビュー画像を A​​PI でレンダリングしますswapBuffers()。

最初の方法で問題ありません。プレビューの比率を 16:9 から 4:3 に変更すると、プレビュー フィールドが大きくなります。

ただし、2 番目の方法は一部の Android フォンでは問題があり、プレビューの比率が変更されてもプレビュー フィールドは同じままで、プレビュー フィールドは比率 4:3 で最初の方法よりも小さくなります。これはエラーだと主張します。この問題を解決したいのですが、どなたかアドバイスをいただけますか?

MediaExtractor を使用した正確なシークに苦労していseekTo()ます。問題なくフレームの同期を求めることができますが、特定の時間を求めたいと思います。この質問により、これを行う方法をいくつか考えましたが、それらが有効かどうかはわかりません。advance()基本的に、ターゲット時間に達するまで、最も近い前の同期フレームを探してからエクストラクタを探す必要があります。処理中のすべてのフレーム、つまり最初の I フレームと残りの P フレームがデコーダに供給されます。これは関連するコード スニペットです ( google/grafikaの MoviePlayer に基づく):

ご想像のとおり、通常は大量のフレームをキューに入れていますが、今のところ、メモリ消費や最終的な遅延は問題ありません。問題は、dequeueInputBuffer()メソッドがループ内でしばらくの間しか機能せず、最終的に -1 を返すことでスタックすることです。これは、ドキュメントによると、バッファーが利用できないことを意味します。を に変更するTIMEOUT_USECと-1、無限ループになります。

このアプローチが正しいかどうか、またはある時点でアクセスできない理由を教えてくださいinputBuffer。