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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.