On 09/07/2018 11:40 PM, Satish Nagireddy wrote: > Hi, > > I am working on interlaced capture devices. There is some confusion in > handling height parameter between application and driver. > > Capture device is able to produce 1920x1080i, where one field > (top/bottom) resolution is 1920x540. > > Query 1: > What should be the height passed by application to driver to capture > 1920x1080i resolution? > According to v4l2 specification: > https://www.kernel.org/doc/html/v4.16/media/uapi/v4l/pixfmt-v4l2.html > > Image height in pixels. If field is one of V4L2_FIELD_TOP, > V4L2_FIELD_BOTTOM or V4L2_FIELD_ALTERNATE then height refers to > > the number of lines in the field, otherwise it refers to the number of > lines in the frame (which is twice the field height for interlaced > formats). Assuming that the HDMI receiver uses FIELD_ALTERNATE (i.e. it delivers first the top field, then the bottom field), then height is 540. > > Query 2: > I can think of 4 possible cases here: > > i) If application calling VIDIOC_TRY_FMT with filed as > V4L2_FIELD_ALTERNATE and capture hardware supports same > > ii) If application calling VIDIOC_TRY_FMT with filed as > V4L2_FIELD_NONE and capture hardware supports same > > iii) If application calling VIDIOC_TRY_FMT with field as > V4L2_FIELD_NONE (progressive) and capture hardware supports > V4L2_FIELD_ALTERNATE > > iv) If application calling VIDIOC_TRY_FMT with field as > V4L2_FIELD_ALTERNATE (progressive) and capture hardware supports > V4L2_FIELD_NONE > > The first 2 cases are straightforward. What should be the driver > behavior for iii and iv ? Should it alter height passed by the > application accordingly? > > I see some of the capture drivers are dividing height by 2 if field is > V4L2_FIELD_ALTERNATE. Is this the right behavior? Yes. What the driver does depends on the digital video timings (i.e. what VIDIOC_G_DV_TIMINGS gives you). If that is progressive, then the driver will set field to NONE and height to the frame height, regardless of what the application asks for. If that is interlaced, then the driver will set field to ALTERNATE and height to the frame height, again regardless of what the application asks for. Things can get more complicated if the driver can scale and/or de-interlace. If that's the case we can go into more detail. Check the vivid driver: it can emulate an HDMI input and 1080i. That driver does the right thing. Make sure you implement the DV_TIMINGS ioctls correctly. Check with other drivers how to do that. The most common mistake is trying to autodetect when the received video timings change and automatically reconfigure the receiver for the new resolution. This is wrong: the driver should send the V4L2_EVENT_SOURCE_CHANGE event, userspace will call QUERY_DV_TIMINGS upon receipt of the event, and reconfigure the pipeline according to the result. Regards, Hans
