Does it support outputting the stream from a single camera to multiple Surface (OpengLViews) ?

[chenqinggang001]

Render the stream of one camera/screen to multiple Surfaces

[Mike-the-one]

I don't think so, if you call addMeidaCodecSurface it renders to that surface but it will use it's internal surface when you start streaming or recording.

@pedroSG94 wondering if you can support rendering to multiple surface? or expose the texture ID so that we can use?

[pedroSG94]

Hello,

Currently it is not supported but can be added.

Abut expose the texture, you don't need it.
With the actual code, using StreamBase classes, you can create a class similar to GlStreamInterface class that render multiple surfaces rendering the surface from getSurface method of that new class using startPreview method of StreamBase.
That surface content can be copied to all previews needed.

Other possibility that need modify the library code is modify GlStreamInterface to support multiple previews but I think that this way will do the code more complex and reduce the performance for users that don't need it.
I could try do the first way.

[chenqinggang001]

That’s great ~ I’m currently using PixelCopy.request for copying, but the performance overhead is quite high. Having this supported directly at the framework level would be really helpful.

[chenqinggang001]

I modified GlStreamInterface to support multiple previews with the following changes:

1. GlStreamInterface.kt

   Replaced the single preview manager with a multi-preview map:

   // Removed
   - private val surfaceManagerPreview = SurfaceManager()
   
   // Added
   + private val multiPreviewSurfaceManagers = ConcurrentHashMap<Surface, PreviewSurfaceInfo>()
   + private data class PreviewSurfaceInfo(
   +     val surfaceManager: SurfaceManager,
   +     val width: Int,
   +     val height: Int
   + )

   • Each Surface now has its own SurfaceManager, which manages an independent EGL context.
   • A ConcurrentHashMap is used to support dynamic addition and removal.
   • The maximum number of preview surfaces is limited to 4.

2. drawFrame

   // Iterate through all preview surfaces and render each one
   val previewSnapshot = multiPreviewSurfaceManagers.values.toList()
   previewSnapshot.forEach { info ->
       if (info.surfaceManager.makeCurrent()) {
           mainRender.drawScreenPreview(info.width, info.height, ...)
           info.surfaceManager.swapBuffer()
       }
   }

This change does not reduce performance for users who only use a single preview — they won’t bear any additional rendering cost.
@pedroSG94 Is this a reasonable improvement? If you think it looks good, I’ll go ahead and submit a pr.

[pedroSG94]

Hello,

Yes, this look interesting. You can create a PR for it

[Mike-the-one]

@pedroSG94 thanks! I saw the PR has been merged. Also you mentioned that you will make some minimal changes, just wondering has this been done? is it in a reease? Current release is 2.6.4, I am not sure when this was released.

So after the change, I can call addMeidaCodecSurface and my surface will be rendered even when I start the recording and/or streaming? With 2.6.4 my surface will stop receive frames as soon as I start the stream and/or reocrd.

[pedroSG94]

Hello,

addMeidaCodecSurface is used internally by the library to encode data for that reason all record/stream stop. You never should use it.
All changes are already done in master. I will create a release this week.

[Mike-the-one]

I'd like to implement a smooth transition when I pause and resume the recording. Without knowing that the addMeidaCodecSurface is for internal use, a few weeks ago, I tried to call this api (for a different purpose) to add my own surface and then feed into encoder, it worked - the problem with this is, my surface stop receiving any frames as soon as I start to stream or record.

So if this changes allows the frames to be sent to multiple surfaces, then I think I can still use it for my purpose?

The idea of the smooth transition for pause and start is, I want to get the raw frames, and keep them in a circular buffer, for example last 2 seconds, and when I resume the record, I add the first 2 seconds of raw frames on top of the last 2 seconds of raw frames, and fadeout last two and fade in first 2 seconds.

I can use record controller but the frame I received is encoded frames, I had to decode and then encode, performance probably is not ideal.

Or do you have any suggestions?

Thanks