Android MediaCodec y la cámara: ¿cómo lograr una mayor velocidad de fotogramas para obtener datos de marco de la cámara?
El ejemplo de CameraToMpegTest.java en bigflake.com, o "Show + capture camera" en Grafika, utiliza la cámara.preview para obtener los datos del marco. Los experimentos muestran que (Nexus 4, Android 4.4.2) la velocidad de fotogramas es de 10 fps. Esto no es tan alto como se esperaba.
Si usamos el mismo dispositivo (Nexus 4, Android 4.4.2) para grabar un video usando la cámara, la velocidad de fotogramas es de 30 fps.
- Cómo utilizar MediaCodec sin MediaExtractor para H264
- Codificación de vídeo en Android mediante cv :: Mat y MediaCodec
- Cómo reducir la latencia en la decodificación de video / avc de MediaCodec
- Cómo proporcionar datos de audio y datos de vídeo a MediaMux
- Codificación de audio AAC utilizando AudioRecord y MediaCodec en Android
Así que supongo que la tasa de fotogramas más baja utilizando camera.preview reside en el método (método de vista previa). Una vez leí un post, diciendo que el método de previsualización de la cámara tiene una tasa de fotogramas más baja.
Por lo tanto, parece que la solución consiste en utilizar datos de marco sin procesar directamente del hardware de la cámara. ¿Como hacer eso? Tengo una impresión de iOS tiene procesamiento de vídeo API para hacer eso, directamente obtener los datos en bruto marco de la cámara. (Pero no sé cuál es su velocidad de fotogramas).
- Android Camera onPreviewFrame frame rate no es coherente
- Android MediaCodec codifica y decodifica en modo asíncrono
- Decodificación h264 ByteStream en Android siempre obtiene INFO_TRY_AGAIN_LATER de dequeueOutputBuffer ()
- ¿Cómo acceder a EGL Image directamente desde Android Surface para su uso en el decodificador de video MediaCodec?
- Causa del codificador en Adreno GPU mientras se codifica desde Surface
- Mp3 a conversión wav android
- Imágenes a Video usando MediaCodec y MediaMuxer
- El vídeo codificado con la cámara2 está al revés en los dispositivos nexus (5x, 6p)
La API de la cámara tiene dos parámetros diferentes para controlar la velocidad de fotogramas: setPreviewFrameRate , que toma un valor de frecuencia de fotogramas único y está obsoleto, y setPreviewFpsRange , que toma un rango de valores FPS y es el control actualmente recomendado.
La razón por la que el control de ajuste de un solo FPS no es suficiente es que a veces quieres que la cámara disminuya su velocidad de fotogramas en condiciones oscuras para mantener el visor brillante (este es el caso de un visor de cámara) y, a veces, Para mantener un 30fps constante no importa qué (en caso de grabación de vídeo). Un solo valor no puede capturar lo que prefiere.
Por lo tanto, la solución ideal es llamar a getSupportedPreviewFpsRange para obtener una lista de rangos de FPS válidos que admite la cámara y elegir la que mejor se adapte a su caso de uso. Si usted está buscando la operación constante de 30fps, usted quisiera (30, 30) como la gama.
Desafortunadamente, el conjunto de rangos FPS soportados no está tan bien probado como debería ser, y no está garantizado que (30, 30) esté en la lista. En ese caso, una alternativa es probar el control de FPS único obsoleto con un parámetro de 30, y activar el parámetro de pista de grabación . Este parámetro le dice al dispositivo de la cámara que está haciendo una operación similar a la grabación, lo que puede cambiarlo a una velocidad de fotogramas constante de 30. Desafortunadamente eso no está garantizado, ya que es sólo una pista.
Así que en resumen, para obtener una operación estable de 30fps:
- Consulta getSupportedPreviewFpsRange
- Si (30,30) aparece en la lista, use setPreviewFpsRange (30, 30). Esto debería ser suficiente para garantizar una velocidad de fotogramas constante.
- Si no es así, consulta getSupportedPreviewFrameRates (30 siempre se debe enumerar aquí, pero es mejor comprobarlo)
- Utilice setPreviewFrameRate (30) y setRecordingHint (true). Esto maximiza la probabilidad de ver la operación de 30fps. Pero algunos dispositivos pueden todavía no hacer lo que usted desea, desafortunadamente.
En adelante, esperamos añadir un requisito de que (30, 30) siempre está listado como un rango soportado, para simplificar esto y garantizar el funcionamiento en estado estacionario.