1

This question is targeted to high-speed video sessions, and not normal video sessions.

Currently in Android Camera2 API, to resolve the optimal preview size I use a target video output size as reference, and compute from it the best preview size by using the list of size choices returned by:

// SurfaceTexture.class to get the preview sizes supported by the surface
StreamConfigurationMap.getOutputSizes(SurfaceTexture.class);

The video output size is selected from the list returned by: StreamConfigurationMap.getHighSpeedVideoSizes();

The preview size computation is done by selecting the size from the SurfaceTexture.class list, with the same aspect ratio as the video output size, and within the 1920x0180 size constrain, which is the max preview size to be guaranteed by the camera2 API.

Said all that, when using createHighSpeedRequestList, this method will fail if it finds that any of the surfaces passed to the session doesn't have a size from the supported high-speed sizes, and this applies also to the preview surface. See the source in: android.hardware.camera2.utils.SurfaceUtils.checkConstrainedHighSpeedSurfaces

The question is, what is the optimal way to get a valid preview size for high-speed video sessions? I can’t rely in the list of choices returned by SurfaceTexture.class since these are unrelated to a high-speed session.

My best guess is that I should iterate through all of them and just find one that is within the list of high-speed sizes returned by StreamConfigurationMap.getHighSpeedVideoSizes, but I want to know if there is a more solid reliable way, or a good example which I could look at.

PerracoLabs
  • 16,449
  • 15
  • 74
  • 127

1 Answers1

0

There is no need to call StreamConfigurationMap.getOutputSizes(SurfaceTexture.class) in your case. Any size in the list you get from StreamConfigurationMap.getHighSpeedVideoSizes() will satisfy the former condition. Note that if you choose some specific FPS, some sizes in the latter list may not be supported. Usually we prefer the largest of the available sizes, but if your requirements allow something smaller, go for it: this may significantly reduce battery consumption and improve device responsiveness.

Alex Cohn
  • 56,089
  • 9
  • 113
  • 307
  • 1
    My concern, and please let me know your thoughts, is about if while relying in getHighSpeedVideoSizes as the source to resolve the preview size, suddenly out of the blue a brand releases a new device with 4K slow motion, which then would mean a 4K the preview size. Although I think is unlikely to happen any time soon, putting this fact to a side, in a normal none-high-speed video session to record 4K with smaller display size devices isn't an issue, since the preview is resolved from SurfaceTexture.class and such size isn't tied to the video output, so it can be constrained to 1920x1080. – PerracoLabs Apr 21 '19 at 21:59
  • 1
    I empathize with your concern, but I can suggest a number of ways the problem can get resolved if when the high speed video at 4K will be introduced. First of all, the limitation that the preview surface for high speed capture *must be same size* as the recorder surface, this limitation is artificial and can be lifted for all or for custom platform. Second, the same device could provide a 4K screen, or more. Finally, they may say that capture at 120 FPS is not 'high speed' anymore, and will follow the rules for regular recording. – Alex Cohn Apr 22 '19 at 13:56