[Bug 693666] bayer: Caps for 16-bit Bayer

[GStreamer (GNOME Bugzilla)]

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

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas at ndufresne.ca

--- Comment #22 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(In reply to Edgar Thier from comment #21)
> Wouldn't it be possible to have a GstBufferPool that 'allocates' buffers in
> GPU memory? Unless I am missing something that way the src would simply fill
> the buffer, the gpu could do debayering and the rest can be left untouched.

GPU memory is not always mappable on host CPU. Though, if your source is v4l2,
then you can request DMABuf, which we support in the gl elements.

(In reply to Jan Schmidt from comment #20)
> The amount of code required to wedge it into glupload looked pretty bad at
> the time because the GL stack depends on GstVideoInfo heavily.
> 
> Locally, I have WIP patches that add 8-bit and 16-bit bayer formats to the
> GstVideoInfo set and do debayering in a GL element. That was a lot easier,
> but it does 'pollute' the format set. The other benefit of that path is that
> the frames then support GstVideoMeta for stride and mapping info easily.
> 
> Either way is a bit awkward.

My impression is that GstVideoInfo approach is less work overall. For the
format pollution, it's the documentation that should be improved in my opinion.
We should try and find a way to create format sections to help browse the
formats. Long term, it would even be nice to have per format (or group of
formats) documentation, to remove the confusion, a bit like linux-media doc
does. gtkdoc might be the bottleneck here.

For the pack/unpack, I'm wondering if there is a clean way to just not
implement it. We still want debayering to be done by GL or specific debayering
element I believe ? and do we care about bayering really ? What I mean, is that
I'm not sure it's useful to fit bayer format into videoconvert, specially that
a debayer element would have extra API for passing matrix (iirc gamma / color
balance, I'm not expert here).

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