v4l2: Clean up interlace support
authorSimon Farnsworth <simon.farnsworth@onelan.co.uk>
Thu, 30 Oct 2014 17:41:19 +0000 (17:41 +0000)
committerNicolas Dufresne <nicolas.dufresne@collabora.co.uk>
Sat, 1 Nov 2014 15:46:13 +0000 (11:46 -0400)
commit02040d507cc4a3d4d22fab15b8bdf1d3746ea26f
treecf0c6a02255e0a1e0867a45d155cf42810b73b98
parent130873c8fdb2a088fdff9b0b4592df728673c931
v4l2: Clean up interlace support

Rather than try and guess interlace support as part of checking supported
sizes, look for interlace support specifically in its own function.

As a cleanup, use V4L2_FIELD_ANY when probing sizes, which should result in
the driver doing the right thing.

With my capture setup, this gets me the following sample caps:

For 1080i resolution:
video/x-raw, format=(string)YUY2, width=(int)1920, height=(int)1080, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)interleaved, framerate=(fraction){ 25/1, 30/1 }

For 720p resolution:
video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)720, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, framerate=(fraction){ 50/1, 60/1 }

For 576i/p resolution (both possible at the point of query):
video/x-raw, format=(string)YUY2, width=(int)720, height=(int)576, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string){ progressive, interleaved }, framerate=(fraction){ 25/1, 50/1 }

This, in turn, makes 576i work correctly; with the old code,
the caps would be interlace-mode=progressive for interlaced video.

https://bugzilla.gnome.org/show_bug.cgi?id=726194
sys/v4l2/gstv4l2bufferpool.c
sys/v4l2/gstv4l2object.c
sys/v4l2/gstv4l2src.c