Open rued opened 10 years ago
In my timing, for individual images the creation of the CVImageBufferRef added more overhead than it was worth, and if you profiled it it still used glTexImage2D() internally on the first upload. For a single block of raw bytes that were constantly changing, the texture caches might still provide a performance boost, though.
I'm getting raw YUV420 frames, streamed from the net using a third party videoconference module that uses VP8 as encoding/decoding engine.
So it sounds like I can benefit from making some kind of hybrid between the GPUImageVideoCamera's conversion of YUV frames and GPUImageRawDataInput's handling of raw data.
What is the updated reason why GPUImageRawDataInput is using glTexImage2D?
In this post, it seems like it could be done faster: http://stackoverflow.com/questions/15721816/converting-raw-data-to-displayable-video-for-ios
However in this post, it seems like it was tested, and concluded that glTexImage2D is the better choice: https://github.com/BradLarson/GPUImage/issues/317
In the current release I can see that GPUImageVideoCamera, etc. uses CVOpenGLESTextureCacheCreateTextureFromImage, but it could be that these classes get their CVImageBufferRef "for free", where GPUImageRawDataInput would need to use a lot of time on both creating a valid CVImageBufferRef and updating it?