Diffusion simultanée du flux de la caméra

Android permet aux appareils de prendre en charge le streaming simultané des caméras. Par exemple, cela permet à un appareil d'utiliser simultanément les caméras avant et arrière. À partir d'Android 11, l'API Camera2 inclut les méthodes suivantes que les applications peuvent appeler pour déterminer si les caméras sont compatibles avec la diffusion simultanée et les configurations de flux compatibles.

• getConcurrentCameraIds : Obtient l'ensemble des combinaisons d'identifiants de caméras actuellement connectées qui permettent de configurer des sessions de caméras simultanément.
• isConcurrentSessionConfigurationSupported : Vérifie si l'ensemble fourni de périphériques de caméras et leurs configurations de session correspondantes peuvent être configurés simultanément.

Un ensemble de combinaisons de flux obligatoires qui doivent être prises en charge lors de la diffusion simultanée est inclus dans les caractéristiques de la caméra d'un appareil photo dans la propriété SCALER_MANDATORY_CONCURRENT_STREAM_COMBINATIONS.

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

Les appareils dotés de la fonctionnalité MONOCHROME (CameraCharacteristics#REQUEST_AVAILABLE_CAPABILITIES, y compris CameraMetadata#REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME) compatibles avec Y8 doivent permettre de remplacer les flux YUV par Y8 dans toutes les combinaisons de flux garanties.

s720p fait référence à la résolution 720p (1 280 x 720) ou à la résolution maximale acceptée pour le format spécifique renvoyé par StreamConfigurationMap.getOutputSizes(). s1440p fait référence à 1440p (1920 x 1440) ou à la résolution maximale acceptée pour le format spécifique renvoyé par StreamConfigurationMap.getOutputSizes(). Les appareils dont les fonctionnalités n'incluent pas ANDROID_REQUEST_AVAILABLE_CAPABILITIES_BACKWARD_COMPATIBLE doivent prendre en charge au moins un flux Y16, Dataspace::DEPTH avec une résolution sVGA, lors d'un fonctionnement simultané, où sVGA est la plus petite des deux 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 afin de déterminer si ses caméras sont compatibles avec le streaming simultané, implémentez l'interface HAL ICameraProvider@2.6, qui inclut les méthodes suivantes :

• getConcurrentStreamingCameraIds
• isConcurrentStreamCombinationSupported

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

Validation

Pour vérifier que votre implémentation de cette fonctionnalité fonctionne comme prévu, utilisez le test ConcurrentCameraTest.java du CTS. Testez également l'application à l'aide d'une application qui ouvre plusieurs caméras et les fait fonctionner simultanément.

Problèmes d'allocation de ressources

Si les HAL de caméras annoncent la prise en charge du fonctionnement simultané des appareils photo, ils peuvent rencontrer des problèmes d'allocation de ressources, en particulier dans le cas où le téléphone dispose de suffisamment de ressources de processeur de signal d'image (ISP) pour diffuser simultanément les caméras avant et arrière (ou d'autres), mais pas à leur pleine capacité. Dans ce cas, le HAL de l'appareil photo doit allouer des ressources matérielles limitées à chaque appareil photo.

Exemple de scénario

Le scénario suivant illustre ce problème.

Problème

L'appareil présente la configuration suivante :

• L'ID de caméra 0 est une caméra logique soutenue par une caméra grand-angle et une caméra ultra grand-angle, qui utilisent chacune une ressource ISP.
• L'ID de caméra 1 est une caméra qui utilise une ressource ISP.

L'appareil (téléphone) dispose de deux FAI. Si l'ID de caméra 0 est ouvert et qu'une session est configurée, il est possible que le HAL de la caméra réserve deux ISP en prévision de l'utilisation des caméras ultra grand-angle et grand-angle.

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

Solution

Pour résoudre ce problème, le framework peut ouvrir les ID de caméra 0 et 1 avant de configurer les sessions afin de fournir un indice au HAL de la caméra sur la façon d'allouer les ressources (car il s'attend désormais à un fonctionnement simultané des caméras). Toutefois, cela peut entraîner des capacités limitées. Par exemple, le zoom peut ne pas être en mesure de gérer le rapport de plage de zoom complet (car le changement d'ID de caméra physique peut être problématique).

Pour mettre en œuvre cette solution, apportez les modifications suivantes à provider@2.6::ICameraProvider::getConcurrentCameraStreamingCameraIds.

• Exigez que, pour le fonctionnement simultané des caméras, le framework de la caméra ouvre les périphériques de caméra (@3.2::ICameraDevice::open) avant de configurer des sessions sur les périphériques de caméra. Cela permet aux fournisseurs de caméras d'allouer les ressources en conséquence.

• Pour résoudre le problème d'impossibilité de gérer le rapport de plage de zoom complète, assurez-vous que les applications de caméras, lorsqu'elles utilisent des caméras simultanément, sont garanties d'utiliser le paramètre de contrôle ZOOM_RATIO uniquement entre 1x et MAX_DIGITAL_ZOOM au lieu de ZOOM_RATIO_RANGE complet (cela empêche le changement de caméras physiques en interne, ce qui nécessite potentiellement plus d'ISP).

Problème lié à testDualCameraPreview

Lorsque vous effectuez les modifications ci-dessus, cela peut créer un problème avec un comportement autorisé par le test MultiViewTest.java#testDualCameraPreview.

Le test testDualCameraPreview ne configure pas les sessions uniquement après l'ouverture de toutes les caméras. Voici la séquence à suivre :

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

Toutefois, il tolère les échecs d'ouverture de l'appareil photo avec ERROR_MAX_CAMERAS_IN_USE [1]. Il est possible que des applications tierces dépendent de ce comportement.

Étant donné que le HAL de l'appareil photo ne connaîtra pas l'ensemble complet d'ID d'appareil photo ouverts pour un fonctionnement simultané avant de configurer les sessions, il peut être difficile pour lui d'allouer des ressources matérielles (en supposant qu'il y ait une certaine concurrence pour elles).

Pour résoudre ce problème, en plus de maintenir la rétrocompatibilité et de prendre en charge le streaming simultané, les HAL de caméras doivent échouer les appels openCamera avec ERROR_MAX_CAMERAS_IN_USE s'ils ne peuvent pas prendre en charge la configuration complète du flux pour toutes les caméras fonctionnant simultanément.