[Bug 762529] v4l2src produces wrong colorimetry info for NV12

[GStreamer (GNOME Bugzilla)]

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

--- Comment #10 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Josep Torra Valles from comment #8)
> Created attachment 322908 [details] [review]
> Use V4L2 macros to deal with default values on colorimetry related attributes
> 
> Cleaned switch as per review request.
> 
> But I'm not sure if for V4L2_COLORSPACE_RAW we should directly return in the
> case.

RAW is special case, as we have an explicit representation for that in
GStreamer. While in V4L2 macros, it simply guesses something.

> 
> Also the value V4L2_COLORSPACE_DEFAULT isn't handled in the switch case
> explicitly which might be wrong. In the header there's the following macro
> and I'm not sure if we should use it or replicate the behaviour. 

The behaviour is to not set anything in the caps, so GStreamer will do a guess
base on the color format and resolution. This guess is well tested.

> 
> /*
>  * Determine how COLORSPACE_DEFAULT should map to a proper colorspace.
>  * This depends on whether this is a SDTV image (use SMPTE 170M), an
>  * HDTV image (use Rec. 709), or something else (use sRGB).
>  */
> #define V4L2_MAP_COLORSPACE_DEFAULT(is_sdtv, is_hdtv) \
>         ((is_sdtv) ? V4L2_COLORSPACE_SMPTE170M : \
>          ((is_hdtv) ? V4L2_COLORSPACE_REC709 : V4L2_COLORSPACE_SRGB))
> 
> This logic seems a bit wrong to me, what happens with UDTV ?

I do believe that UDTV should result with is_hdtv to be set, but you'd have to
ask Hans. Colorwhise, I doubt there is a difference with HD and UD. Maybe we
should have just updated the switch cases to match the macro behaviour in the
end, with the missing hints. At least it made it simple to understand what will
be the result. The macros makes things a bit obscure in my opinion (sorry for
changing my mind).

Sebastian, I'd like to get this one right, so I'm not in a rush, if we get that
for 1.8.1, I'm fine.

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