Apple documentation says:

  While clients can call VTCompressionSessionGetPixelBufferPool once
  and retain the resulting pool, the call is cheap enough that it's OK 
  to call it once per frame.  If a change of session properties causes 
  the compressor's pixel buffer attributes to change, it's possible that
  VTCompressionSessionGetPixelBufferPool might return a different pool.

Therefore, a possible model:

typedef CVPixelBufferPoolRef (GstCoreVideoGetPixelBufferFunc *)(CFTypeRef);

gst_core_video_buffer_pool_init (GstCoreVideoGetPixelBufferFunc getPixelBufferPool, CFTypeRef context):

   e.g. called with (VTCompressionSessionGetPixelBufferPool, session)

   a) retain the context

gst_core_video_buffer_pool_acquire_buffer:

   a) get a CV pool with getPixelBufferPool
   a) get a new CVPixelBuffer from that CV pool
   b) add it as meta to GstBuffer (from pool)
   c) add GstCoreVideoMemory objects ("wrap the CVPixelBuffer")

gst_core_video_buffer_pool_reset_buffer:

   a) remove the GstCoreVideoMemory objects
   b) remove the CVPixelBuffer meta
   c) release the CVPixelBuffer

However, it's also possible that our VT session doesn't change too often, and that we'll send another propose_allocation in this case. In such case:

 - We'll retain the CVPixelBufferPool itself.

 - The CVPixelBuffers will remain attached to the GstBuffers, and therefore would never be truly released back the the CVPixelBufferPool -- instead, our own buffer pool will decide the min_buffers/max_buffers policy. (Though, on buffers above the max, CVPixelBufferPool's policy might still be applied.)

- -

Just some thoughts. Requesting comments :)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/244.