Hi Laurent,
On 09/27/2011 01:17 PM, Laurent Pinchart wrote:
Hi Tomasz,
On Friday 23 September 2011 17:22:27 Tomasz Stanislawski wrote:
On 09/23/2011 03:13 PM, Laurent Pinchart wrote:
[snip]
I have to ideas to add subpixels to selection API.
1. Introduce struct v4l2_frect similar to struct v4l2_rect. All its
fields' type would be struct v4l2_fract.
2. Add field denominator to v4l2_selection as one of reserved fields.
All selection coordinates would be divided by this number.
The 2nd proposal could added in the future update to selection API.
The second solution seems the simplest. Drivers will likely not support
arbitrary denominators, so we also need a way to report the acceptable
value(s) to userspace.
The driver could set denominator to zero for G_SELECTION to indicate
that no subpixel resolutions are supported. Moreover it is easy to
convert fractional value to integers because rounding would be
controlled by the constraints flags. This operation could be done by new
helper function from V4L2 kernel API.
[snip]
How would an application remove them ?
The application may use memset if it recognizes fourcc. The idea of
padding target was to provide information about artifacts introduced the
hardware. If the image is decoded directly to framebuffer then the
application could remove artifacts. We could introduce some V4L2
control to inform if the padding are is filled with zeros to avoid
redundant memset.
What do you think?
OK, I understand this better now. I'm still not sure how applications
will be able to cope with that. memset'ing the garbage area won't look
good on the screen.
The memset is just a simple and usually fast solution. The application
could fill the padding area with any pattern or background color.
Does your hardware have different compose and padding rectangles ?
I assume that you mean active and padded targets for composing, right?
The answer is yes. The MFC inserts data to the image that dimensions are
multiples of 128x32. The movie inside could be any size that fits to the
buffer. The area that contains the movie frame is the active rectangle.
The padded is filled with zeros. For MFC the bounds and padded rectangle
are the same.
Hmm...
Does it violate 'no margin requirement', doesn't it?
Seems so :-)
For S5P MFC is it not possible to satisfy 'no margin' requirement in all
cases. The default rectangle is not equal to the bound rectangle in all
cases. BTW, the MFC is mem2mem device so its API may change.
To sum up for MFC following inequalities are satisfied:
active <= padded == bound
Do you think that 'no margin' requirement should be downgraded to a
recommendation status?
[snip]
I think the driver should always return the best-hit rectangle, regardless of
whether we use hints or not.
The problem is that when the VIDIOC_S_SELECTION fails (could not satisfy
constraints) then the ioctl'a parameters are not copied to the
userspace. So no best-hit rectangle can be returned. On the other hand,
if the ioctl would not fail in this case then the configuration is
applied, causing pipeline messing. We have no-win situation.
If the application accepts all rectangles then it should never use the
constraint flags in the first place. Moreover, the application can
always remove the constraints flags and try again. At least, the fall
back is done explicitly in that case.
The VIDIOC_TRY_SELECTION could be added to cope with more complex
negotiations.
Best regards,
Tomasz Stanislawski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
