[Bug 747216] applemedia: implement GstCoreVideoMemory

[GStreamer (GNOME Bugzilla)]

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

--- Comment #12 from Ilya Konstantinov <ilya.konstantinov at gmail.com> ---
In my patch, I wrap the CVPixelBufferRef in a GstCoreVideoPixelBuffer. One
might ask why I can't simply retain the CVPixelBufferRef?

The reasons are basically:
 a) planar video
 b) CVPixelBuffer(Un)LockBaseAddress

Remember that for planar video, each GstCoreVideoMemory can represent a
separate plane. While they're locking the same pixel buffer, they're getting
different base addresses through CVPixelBufferGetBaseAddressOfPlane.

It comes to mind that GstMemory has a hierarchical design, where planes can be
offsets into a bigger block, and have the common GstMemory as the 'parent'. But
nothing in the Apple docs gives me guarantees that "planes" are offsets into a
bigger common block. (We can test this empirically, but I didn't.)

Onwards, to the details: 

1) CVPixelBufferLockBaseAddress only decides upon locking mode upon first call.
This was established through testing; Apple docs do not elaborate :(

When buffer is locked, additional locks only increase a counter, but otherwise
they're no-ops. Even error checking is not done -- i.e.

  status = CVPixelBufferLockBaseAddress (pixbuf, kCVPixelBufferLock_ReadOnly);
  assert (status == noErr);
  status = CVPixelBufferLockBaseAddress (pixbuf, 0); /* r/w */
  assert (status == noErr);

CVPixelBufferUnlockBaseAddress should be called a matching number of times, of
course. All calls except for the last call are also no-ops.

By keeping the lock status, I can refuse to r/w-lock a pixbuf that was
previously r/o-locked (instead of blindly ignoring the error).

2) mem_unmap does not get flags but CVPixelBufferUnlockBaseAddress wants the
original lockFlags.

I could theoretically make the GstCoreVideoMemory (e.g. for each plane) store
its own flags, but again, what about:

  1) first plane is mapped with GST_MAP_READ
  2) second plane is mapped with GST_MAP_READWRITE --> no-op
  3) first plane is unmapped --> CVPixelBufferLockBaseAddress(pixbuf,
kCVPixelBufferLock_ReadOnly) is a no-op
  4) second plane is unmapped --> CVPixelBufferLockBaseAddress(pixbuf, 0) is an
CV error, since we're unlocking a ReadOnly-pixbuf with ReadWrite-lockFlags

...



So yeah, I'd really rather not wrap CVPixelBuffer in another layer of
refcounting, but I didn't feel like I have a choice if I want it to be solid.

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