Flux vidéo simultané de la caméra

Android permet aux appareils de prendre en charge le streaming simultané des caméras. Pour par exemple, cela permet à un appareil de faire fonctionner à la fois les caméras avant et arrière en même temps. Sous Android 11, l'API Camera2 inclut les méthodes suivantes : que les applications peuvent appeler pour déterminer si les caméras prennent en charge les diffusions simultanées et les configurations de flux compatibles.

• getConcurrentCameraIds: Récupère l'ensemble des combinaisons de l'appareil photo actuellement connecté. permettant de configurer simultanément des sessions de caméra/appareil photo.
• isConcurrentSessionConfigurationSupported: Vérifie si l'ensemble de caméras fourni et les les configurations de session peuvent être configurées simultanément.

Un ensemble de combinaisons de flux obligatoires qui doivent être acceptées lors de la diffusion simultanée sont incluses dans les caractéristiques de la caméra d'une caméra SCALER_MANDATORY_CONCURRENT_STREAM_COMBINATIONS .

Chaque caméra annoncée via getConcurrentStreamingCameraIds() doit acceptent les configurations garanties suivantes pour les flux simultanés.

Cible 1		Cible 2
Type	Taille maximale	Type	Taille maximale	Exemples de cas d'utilisation
YUV	S1440p			Traitement des vidéos ou des images dans l'application
PRIV	S1440p			Analyse du viseur dans l'application
JPEG	S1440p			Pas de capture d'image fixe avec le viseur
YUV / PRIV	S720p	JPEG	S1440p	Imagerie fixe standard
YUV / PRIV	S720p	YUV / PRIV	S1440p	Vidéo ou traitement dans l'application avec aperçu

Appareils ayant la capacité MONOCHROME (CameraCharacteristics#REQUEST_AVAILABLE_CAPABILITIES). inclut CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME). la prise en charge de Y8 doit pouvoir remplacer les flux YUV par Y8 dans tous les cas des combinaisons de flux.

s720p fait référence à 720p (1 280 x 720) ou à la résolution maximale acceptée pour format particulier renvoyé par StreamConfigurationMap.getOutputSizes() s1440p fait référence à 1440p (1 920 x 1 440) ou à la résolution maximale acceptée pour le format particulier renvoyé par StreamConfigurationMap.getOutputSizes() Appareils dont les fonctionnalités n'incluent pas les fonctionnalités suivantes : ANDROID_REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE doit accepter au moins un flux Y16, Dataspace::DEPTH avec sVGA lors d'opérations simultanées, où sVGA est le plus petit des deux les résolutions suivantes:

• résolution de sortie maximale pour le format donné
• 640 x 480

Implémentation

Pour permettre aux applications d'interroger un appareil pour déterminer sont compatibles avec les flux simultanés, mettez en œuvre ICameraProvider@2.6 Interface HAL, qui comprend les méthodes suivantes:

• getConcurrentStreamingCameraIds
• isConcurrentStreamCombinationSupported

Pour obtenir une implémentation de référence de l'interface ICameraProvider@2.6HAL, consultez la bibliothèque HAL de la caméra émulée EmulatedCameraProviderHWLImpl.cpp

Validation

Pour tester l'implémentation de cette fonctionnalité comme prévu, utilisez la ConcurrentCameraTest.java Test CTS Effectuez également le test à l'aide d'une application qui ouvre plusieurs caméras et fonctionne simultanément.

Problèmes d'allocation des ressources

Si les HAL des caméras annoncent la prise en charge du fonctionnement simultané de ils peuvent rencontrer des problèmes d'allocation des ressources, en particulier lorsqu'il y a suffisamment de ressources de processeur de signal d'image (FAI) sur le téléphone pour diffuser simultanément le flux des caméras avant et arrière (ou d'autres), mais pas pour à pleine capacité. Dans ce cas, l'HAL de la caméra doit allouer des ressources ressources matérielles spécifiques à chaque appareil photo.

Exemple de scénario

Le scénario suivant illustre ce problème.

Problème

La configuration de l'appareil est la suivante:

• L'ID de l'appareil photo 0 est un appareil photo logique, doté d'un objectif grand angle et d'un ultra grand angle caméra, qui utilisent chacun une ressource FAI.
• L'ID d'appareil photo 1 est un appareil photo qui accepte une ressource FAI.

L'appareil (téléphone) est associé à deux FAI. Si l'ID d'appareil photo 0 est ouvert et qu'une session est il est possible que le HAL de la caméra réserve deux FAI à la fois l'objectif ultra grand angle et l'appareil photo grand angle.

Dans ce cas, sachez que la caméra avant (ID 1) ne peut pas en configurer flux car les deux FAI sont utilisés.

Solution

Pour résoudre ce problème, le framework peut ouvrir les ID d'appareil photo 0 et 1. avant de configurer des sessions pour indiquer au HAL de la caméra comment alloue des ressources (car il attend désormais un fonctionnement simultané des caméras). Toutefois, cela peut limiter les capacités, par exemple, le zoom n'est pas gérer tout le ratio de la plage de zoom (car le fait de changer d'appareil photo les identifiants peuvent poser problème.)

Pour implémenter cette solution, effectuez les mises à jour suivantes dans provider@2.6::ICameraProvider::getConcurrentCameraStreamingCameraIds

• exiger que, pour le fonctionnement simultané des caméras, le framework doit ouvrir les appareils photo (@3.2::ICameraDevice::open) avant la configuration des sessions sur les caméras. Cela permet à l'appareil photo d'allouer les ressources en conséquence.

• Pour résoudre le problème de ne pas pouvoir gérer l'intégralité rapport de zoom, assurez-vous que les applications d'appareil photo, lorsque vous les utilisez simultanément, sont assurés d'utiliser le paramètre de commande ZOOM_RATIO entre seulement 1x et MAX_DIGITAL_ZOOM au lieu du ZOOM_RATIO_RANGE complet (ce empêche le basculement des caméras physiques en interne, ce qui peut nécessite davantage de FAI).

Remarque :Les identifiants de caméra sont promus dans une combinaison via getConcurrenStreamingCameraIds ne doit pas entrer en conflit. Par exemple, si getConcurrentStreamingCameraIds fait la promotion des {0,1}, {2,1}, des identifiants d'appareil photo 0 et Les 2 sont autorisés à entrer en conflit, mais les ID de caméra 0 et 1, ainsi que 1 et 2 ne doivent pas entrer en conflit.

Problème avec testDualCameraPreview

Les mises à jour ci-dessus peuvent entraîner un problème avec un comportement autorisé. par le test MultiViewTest.java#testDualCameraPreview.

L'testDualCameraPreview de test ne configure pas les sessions uniquement après l'ouverture toutes les caméras. Elle se déroule comme suit:

for each camera  in cameraDevices :
  device = openCamera(camera)
     createCaptureSession(device);

En revanche, il tolère les défaillances d'ouverture de l'appareil photo ERROR_MAX_CAMERAS_IN_USE [1] Les applications tierces peuvent dépendre de ce comportement.

Parce que l'HAL de la caméra ne sait pas que tous les ID de caméra sont ouverts pour des opérations simultanées avant de configurer des sessions, il peut être difficile de allouent des ressources matérielles (en supposant qu'elles soient mises en concurrence).

Pour résoudre ce problème, maintenir la rétrocompatibilité en plus prenant en charge les flux simultanés, les HAL des caméras doivent échouer aux appels openCamera avec ERROR_MAX_CAMERAS_IN_USE s'ils ne peuvent pas prendre en charge la configuration de flux complet pour toutes les caméras fonctionnant en même temps.