From: Hans Verkuil <hverkuil@xs4all.nl>
To: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: [RFC ATTN] Cropping, composing, scaling and S_FMT
Date: Mon, 02 Jun 2014 10:28:18 +0200 [thread overview]
Message-ID: <538C35A2.8030307@xs4all.nl> (raw)
During the media mini-summit I went through all 8 combinations of cropping,
composing and scaling (i.e. none of these features is present, or only cropping,
only composing, etc.).
In particular I showed what I thought should happen if you change a crop rectangle,
compose rectangle or the format rectangle (VIDIOC_S_FMT).
In my proposal the format rectangle would increase in size if you attempt to set
the compose rectangle wholly or partially outside the current format rectangle.
Most (all?) of the developers present didn't like that and I was asked to take
another look at that.
After looking at this some more I realized that there was no need for this and
it is OK to constrain a compose rectangle to the current format rectangle. All
you need to do if you want to place the compose rectangle outside of the format
rectangle is to just change the format rectangle first. If the driver supports
composition then increasing the format rectangle will not change anything else,
so that is a safe operation without side-effects.
However, changing the crop rectangle *can* change the format rectangle. In the
simple case of hardware that just supports cropping this is obvious, since
the crop and format rectangles must always be of the same size, so changing
one will change the other. But if you throw in a scaler as well, you usually
still have such constraints based on the scaler capabilities.
So assuming a scaler that can only scale 4 times (or less) up or down in each
direction, then setting a crop rectangle of 240x160 will require that the
format rectangle has a width in the range of 240/4 - 240*4 (60-960) and a
height in the range of 160/4 - 160*4 (40-640). Anything outside of that will
have to be corrected.
In my opinion this is valid behavior, and the specification also clearly
specifies in the VIDIOC_S_CROP and VIDIOC_S_SELECTION documentation that the
format may change after changing the crop rectangle.
Note that for output streams the role of crop and compose is swapped. So for
output streams it is the crop rectangle that will always be constrained by
the format rectangle, and it is the compose rectangle that might change the
format rectangle based on scaler constraints.
I think this makes sense and unless there are comments this is what I plan
to implement in my vivi rewrite which supports all these crop/compose/scale
combinations.
Regards,
Hans
next reply other threads:[~2014-06-02 8:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-02 8:28 Hans Verkuil [this message]
2014-06-04 18:40 ` [RFC ATTN] Cropping, composing, scaling and S_FMT Mauro Carvalho Chehab
2014-06-05 7:20 ` Hans Verkuil
2014-06-05 11:06 ` Mauro Carvalho Chehab
2014-06-05 12:03 ` Hans Verkuil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=538C35A2.8030307@xs4all.nl \
--to=hverkuil@xs4all.nl \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox