[Bug 743186] v4l2object: set colorspace in caps for capture devices

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=743186
  GStreamer | gst-plugins-good | git master

Nicolas Dufresne (stormer) <nicolas.dufresne> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk
     Ever Confirmed|0                           |1

--- Comment #4 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> 2015-01-19 17:58:46 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> However, I agree with the fact that I'm maybe too aggressive with an error :)
> for a thing we can live without.
> So what do you think of a warning or debug message instead (warning will also
> spam)

I would opt of debug message and no colorimetry field in the caps seems fine to
me.


> > 
> > @@ +2308,3 @@
> >          pixelformat);
> >      gst_v4l2_object_add_aspect_ratio (v4l2object, tmp);
> > +    gst_v4l2_object_add_colorspace (v4l2object, tmp, max_w, max_h,
> > pixelformat);
> > 
> > I think this is a case where just checking the max may really lead to wrong
> > result. We probably want to check min and max, if if different, put both in the
> > caps.
> 
> Not a bad reflection, I don't know if the size matter or not, it could depend
> of the driver I think. But in this case we would know for sure the colorspace
> when the format is negotiatied, ie after final S_FMT.
> I think if some drivers do this, checking min and max could not be enough. For
> instance, I think of a device which can output SD with associated colorspace
> smtpe170m, HD in rec709 and UHD in bt2020.

Fair, maybe we can leave it this way for now and add a comment. There is an
evident solution in the driver, which is to implement enumeration.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.