[v2,0/1] Make Gstreamer prefer non-raw caps
mbox series

Message ID 20260720115144.4392-1-david.plowman@raspberrypi.com
Headers show
Series
  • Make Gstreamer prefer non-raw caps
Related show

Message

David Plowman July 20, 2026, 11:10 a.m. UTC
Hi

Here's a version 2 which incorporates some suggestions from Nicolas
which I agree makes things a bit clearer.

1. Raw monochrome formats are identified by being video/x-raw with 1
component, matching the existing bare_structure_from_format function
in this file.

2. The comparison is rearranged to use a sorted list, as some other
components do. This keeps all the logic in one place and makes it
easier to understand.

Actually, on point 1 above I do have some misgivings. Treating
video/x-raw with 1 component as "monochrome raw" seems a bit
controversial as we can't distinguish "raw" greyscale from "processed"
greyscale. I wonder a little bit if bare_structure_from_format should
categorise the greyscale formats as video/x-bayer but with a format
set to something like "mono"? Is that possible?

That feels like it's a bit above my pay grade at this point, but in
any case could be something for a subsequent commit.

Thanks

David


David Plowman (1):
  gstreamer: Prefer non-raw (i.e. non-Bayer) formats in caps negotiation

 src/gstreamer/gstlibcamera-utils.cpp | 125 ++++++++++++++++++++-------
 src/gstreamer/gstlibcamera-utils.h   |   2 +-
 src/gstreamer/gstlibcamerasrc.cpp    |   3 +-
 3 files changed, 97 insertions(+), 33 deletions(-)

Comments

Nicolas Dufresne July 20, 2026, 3:14 p.m. UTC | #1
Le lundi 20 juillet 2026 à 12:10 +0100, David Plowman a écrit :
> Hi
> 
> Here's a version 2 which incorporates some suggestions from Nicolas
> which I agree makes things a bit clearer.
> 
> 1. Raw monochrome formats are identified by being video/x-raw with 1
> component, matching the existing bare_structure_from_format function
> in this file.
> 
> 2. The comparison is rearranged to use a sorted list, as some other
> components do. This keeps all the logic in one place and makes it
> easier to understand.
> 
> Actually, on point 1 above I do have some misgivings. Treating
> video/x-raw with 1 component as "monochrome raw" seems a bit
> controversial as we can't distinguish "raw" greyscale from "processed"
> greyscale. I wonder a little bit if bare_structure_from_format should
> categorise the greyscale formats as video/x-bayer but with a format
> set to something like "mono"? Is that possible?

In GStreamer, we only have bayer patterns with the RGB trio so far. In general,
calling bayer a single component format seems odd, so I would stay away from
that.

GStreamer utilization of the term raw matches the idea that its not compressed.
So in that sense, bayer and x-raw are both raw.

> 
> That feels like it's a bit above my pay grade at this point, but in
> any case could be something for a subsequent commit.

I think the answer to how to distinguished unprocessed gray will fall into color
coding category. We probably don't have to care right now.

Nicolas

> 
> Thanks
> 
> David
> 
> 
> David Plowman (1):
>   gstreamer: Prefer non-raw (i.e. non-Bayer) formats in caps negotiation
> 
>  src/gstreamer/gstlibcamera-utils.cpp | 125 ++++++++++++++++++++-------
>  src/gstreamer/gstlibcamera-utils.h   |   2 +-
>  src/gstreamer/gstlibcamerasrc.cpp    |   3 +-
>  3 files changed, 97 insertions(+), 33 deletions(-)
David Plowman July 23, 2026, 12:34 p.m. UTC | #2
Hi Nicolas

Thanks for the comments.

On Mon, 20 Jul 2026 at 16:14, Nicolas Dufresne <nicolas@ndufresne.ca> wrote:
>
> Le lundi 20 juillet 2026 à 12:10 +0100, David Plowman a écrit :
> > Hi
> >
> > Here's a version 2 which incorporates some suggestions from Nicolas
> > which I agree makes things a bit clearer.
> >
> > 1. Raw monochrome formats are identified by being video/x-raw with 1
> > component, matching the existing bare_structure_from_format function
> > in this file.
> >
> > 2. The comparison is rearranged to use a sorted list, as some other
> > components do. This keeps all the logic in one place and makes it
> > easier to understand.
> >
> > Actually, on point 1 above I do have some misgivings. Treating
> > video/x-raw with 1 component as "monochrome raw" seems a bit
> > controversial as we can't distinguish "raw" greyscale from "processed"
> > greyscale. I wonder a little bit if bare_structure_from_format should
> > categorise the greyscale formats as video/x-bayer but with a format
> > set to something like "mono"? Is that possible?
>
> In GStreamer, we only have bayer patterns with the RGB trio so far. In general,
> calling bayer a single component format seems odd, so I would stay away from
> that.
>
> GStreamer utilization of the term raw matches the idea that its not compressed.
> So in that sense, bayer and x-raw are both raw.
>
> >
> > That feels like it's a bit above my pay grade at this point, but in
> > any case could be something for a subsequent commit.
>
> I think the answer to how to distinguished unprocessed gray will fall into color
> coding category. We probably don't have to care right now.

I'm happy to leave all this be for the moment. In my crystal ball I
see us probably coming back to this when someone tries one of our mono
sensors with gstreamer, but I don't think the patch here will make it
behave (= break, probably) any differently. Perhaps we can do some
background thinking on the matter until then...

Thanks!

David

>
> Nicolas
>
> >
> > Thanks
> >
> > David
> >
> >
> > David Plowman (1):
> >   gstreamer: Prefer non-raw (i.e. non-Bayer) formats in caps negotiation
> >
> >  src/gstreamer/gstlibcamera-utils.cpp | 125 ++++++++++++++++++++-------
> >  src/gstreamer/gstlibcamera-utils.h   |   2 +-
> >  src/gstreamer/gstlibcamerasrc.cpp    |   3 +-
> >  3 files changed, 97 insertions(+), 33 deletions(-)