[Bug 748503] vtenc: support VT buffer pool

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=748503

--- Comment #1 from Ilya Konstantinov <ilya.konstantinov at gmail.com> ---
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 :)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.