From: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Hans Verkuil <hansverk@cisco.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Hans Verkuil <hverkuil@xs4all.nl>,
Tomasz Stanislawski <t.stanislaws@samsung.com>,
linux-media@vger.kernel.org, m.szyprowski@samsung.com,
kyungmin.park@samsung.com,
sakari.ailus@maxwell.research.nokia.com
Subject: Re: [PATCH 0/2] V4L: Extended crop/compose API
Date: Wed, 18 May 2011 15:03:13 +0200 [thread overview]
Message-ID: <4DD3C391.3060407@samsung.com> (raw)
In-Reply-To: <201105181431.59580.hansverk@cisco.com>
On 05/18/2011 02:31 PM, Hans Verkuil wrote:
> On Wednesday, May 18, 2011 14:06:21 Sylwester Nawrocki wrote:
>> On 05/16/2011 09:21 AM, Laurent Pinchart wrote:
>> > On Saturday 14 May 2011 12:50:32 Hans Verkuil wrote:
>> >> On Friday, May 13, 2011 14:43:08 Laurent Pinchart wrote:
>> >>> On Saturday 07 May 2011 13:52:25 Hans Verkuil wrote:
>> >>>> On Thursday, May 05, 2011 11:39:54 Tomasz Stanislawski wrote:
>> >
>
>> > [snip]
>> ...
>
>> >>>>> * resolution of an image combined with support for
>
>> >>>>> VIDIOC_S_MULTISELECTION
>
>> >>>>>
>
>> >>>>> allows to pass a triple format/crop/compose sizes in a single
>
>> >>>>> ioctl
>
>> >>>>
>
>> >>>> I don't believe S_MULTISELECTION will solve anything. Specific
>
>> >>>> use-cases perhaps, but not the general problem of setting up a
>
>> >>>> pipeline. I feel another brainstorm session coming to solve that. We
>
>> >>>> never came to a solution for it in Warsaw.
>
>> >>>
>
>> >>> Pipelines are configured on subdev nodes, not on video nodes, so I'm also
>
>> >>> unsure whether multiselection support would really be useful.
>
>> >>>
>
>> >>> If we decide to implement multiselection support, we might as well use
>
>> >>> that only. We would need a multiselection target bitmask, so selection
>
>> >>> targets should all be < 32.
>
>> >>>
>
>> >>> Thinking some more about it, does it make sense to set both crop and
>
>> >>> compose on a single video device node (not talking about mem-to-mem,
>
>> >>> where you use the type to multiplex input/output devices on the same
>
>> >>> node) ? If so, what would the use cases be ?
>
>>
>
>> I can't think of any, one either use crop or compose.
>
>
> I can: you crop in the video receiver and compose it into a larger buffer.
>
> Actually quite a desirable feature.
Yes, right. Don't know why I imagined something different.
And we need it in Samsung capture capture interfaces as well. The H/W
is capable of cropping and composing with camera interface as a data source
similarly as it is done with memory buffers.
Regards,
--
Sylwester Nawrocki
Samsung Poland R&D Center
next prev parent reply other threads:[~2011-05-18 13:03 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-05 9:39 [PATCH 0/2] V4L: Extended crop/compose API Tomasz Stanislawski
2011-05-05 9:39 ` [PATCH 1/2] v4l: add support for extended " Tomasz Stanislawski
2011-05-05 9:39 ` [PATCH 2/2] v4l: simulate old crop API using " Tomasz Stanislawski
2011-05-09 6:23 ` Jonghun Han
2011-05-09 11:01 ` Tomasz Stanislawski
2011-05-07 11:52 ` [PATCH 0/2] V4L: Extended " Hans Verkuil
2011-05-13 12:43 ` Laurent Pinchart
2011-05-14 10:50 ` Hans Verkuil
2011-05-16 7:21 ` Laurent Pinchart
2011-05-18 12:06 ` Sylwester Nawrocki
[not found] ` <201105181431.59580.hansverk@cisco.com>
2011-05-18 13:03 ` Sylwester Nawrocki [this message]
2011-05-19 13:47 ` Laurent Pinchart
2011-05-19 14:05 ` Marek Szyprowski
2011-05-19 14:06 ` Tomasz Stanislawski
2011-05-19 14:12 ` Laurent Pinchart
2011-05-19 13:45 ` Laurent Pinchart
2011-05-18 16:55 ` Tomasz Stanislawski
2011-05-19 15:50 ` Tomasz Stanislawski
2011-05-23 21:29 ` Laurent Pinchart
2011-05-24 12:28 ` Tomasz Stanislawski
2011-05-25 13:43 ` Laurent Pinchart
2011-05-25 16:03 ` Tomasz Stanislawski
-- strict thread matches above, loose matches on Subject: below --
2011-03-28 15:19 Tomasz Stanislawski
2011-03-29 6:58 ` Hans Verkuil
2011-03-29 9:22 ` Tomasz Stanislawski
2011-03-29 9:50 ` Hans Verkuil
2011-03-29 10:38 ` Tomasz Stanislawski
2011-04-05 14:00 ` Laurent Pinchart
2011-04-05 14:14 ` Tomasz Stanislawski
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=4DD3C391.3060407@samsung.com \
--to=s.nawrocki@samsung.com \
--cc=hansverk@cisco.com \
--cc=hverkuil@xs4all.nl \
--cc=kyungmin.park@samsung.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=sakari.ailus@maxwell.research.nokia.com \
--cc=t.stanislaws@samsung.com \
/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