Hi Guennadi,
On Thursday 17 February 2011 17:46:15 Guennadi Liakhovetski wrote:
Hi all
Let me try to further elaborate on this topic. So far, I think, the
following provides the cleanest solution to our quick format-switching /
multiple video-queue problem:
On Wed, 16 Feb 2011, Guennadi
Hi Mauro,
On Thursday 17 February 2011 20:04:33 Mauro Carvalho Chehab wrote:
Em 16-02-2011 08:35, Guennadi Liakhovetski escreveu:
But from the point of view of the application it makes more sense to
actually have two video nodes. The only difference is that when one
starts streaming it
Hi Michal,
On Friday 18 February 2011 00:09:51 Michal Nazarewicz wrote:
On Thu, 17 Feb 2011, Mauro Carvalho Chehab wrote:
There's an additional problem with that: assume that streaming is
happening, and a S_FMT changing the resolution was sent. There's
no way to warrant that the very next
On Fri, 18 Feb 2011 11:31:30 +0100, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Michal,
On Friday 18 February 2011 00:09:51 Michal Nazarewicz wrote:
On Thu, 17 Feb 2011, Mauro Carvalho Chehab wrote:
There's an additional problem with that: assume that streaming is
Em 18-02-2011 08:31, Laurent Pinchart escreveu:
It's a trade-off between memory and speed. Preallocating still image capture
buffers will give you better snapshot performances, at the expense of memory.
The basic problems we have here is that taking snapshots is slow with the
current API
Hi Mauro,
On Friday 18 February 2011 13:33:12 Mauro Carvalho Chehab wrote:
Em 18-02-2011 08:31, Laurent Pinchart escreveu:
It's a trade-off between memory and speed. Preallocating still image
capture buffers will give you better snapshot performances, at the
expense of memory.
The
Em 18-02-2011 08:31, Laurent Pinchart escreveu:
It's a trade-off between memory and speed. Preallocating still image
capture buffers will give you better snapshot performances, at the
expense of memory.
The basic problems we have here is that taking snapshots is slow with
the current API if
Hi Michal,
On Friday 18 February 2011 12:37:24 Michal Nazarewicz wrote:
[snip]
What I'm trying to say is that it would be best if one could configure the
device in such a way that switching between modes would not require the
device to free buffers (even though in user space they could be
On Fri, 18 Feb 2011 13:57:25 +0100, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Michal,
On Friday 18 February 2011 12:37:24 Michal Nazarewicz wrote:
[snip]
What I'm trying to say is that it would be best if one could configure
the device in such a way that switching
Hi Michal,
On Friday 18 February 2011 14:19:44 Michal Nazarewicz wrote:
On Fri, 18 Feb 2011 13:57:25 +0100, Laurent Pinchart wrote:
On Friday 18 February 2011 12:37:24 Michal Nazarewicz wrote:
[snip]
What I'm trying to say is that it would be best if one could configure
the device
On Friday 18 February 2011 14:19:44 Michal Nazarewicz wrote:
Cache operations are always needed, aren't they? Whatever you do, you
will always have to handle cache coherency (in one way or another) so
there's nothing we can do about it, or is there?
On Fri, 18 Feb 2011 14:21:53 +0100, Laurent
Hi Michal,
On Friday 18 February 2011 15:05:42 Michal Nazarewicz wrote:
On Friday 18 February 2011 14:19:44 Michal Nazarewicz wrote:
Cache operations are always needed, aren't they? Whatever you do, you
will always have to handle cache coherency (in one way or another) so
there's nothing
Hi all
Let me try to further elaborate on this topic. So far, I think, the
following provides the cleanest solution to our quick format-switching /
multiple video-queue problem:
On Wed, 16 Feb 2011, Guennadi Liakhovetski wrote:
(2) cleanly separate setting video data format (S_FMT) from
Em 15-02-2011 15:33, Guennadi Liakhovetski escreveu:
Hi
This topic has been slightly discussed several times [1] before, but there
has been no conclusion, nor I'm aware of any implementation, suitably
resolving this problem. I've added to CC all involved in earlier
discussions, that I
Em 16-02-2011 08:35, Guennadi Liakhovetski escreveu:
But from the point of view of the application it makes more sense to
actually have two video nodes. The only difference is that when one
starts streaming it pre-empts the other.
Well, I don't think I like it all that much... One reason -
Hi Mauro
Thanks for your comments.
On Thu, 17 Feb 2011, Mauro Carvalho Chehab wrote:
Em 16-02-2011 08:35, Guennadi Liakhovetski escreveu:
[snip]
(2) cleanly separate setting video data format (S_FMT) from specifying the
allocated buffer size.
This would break existing applications.
Em 17-02-2011 17:26, Guennadi Liakhovetski escreveu:
Hi Mauro
Thanks for your comments.
On Thu, 17 Feb 2011, Mauro Carvalho Chehab wrote:
Em 16-02-2011 08:35, Guennadi Liakhovetski escreveu:
[snip]
(2) cleanly separate setting video data format (S_FMT) from specifying the
On Thu, 17 Feb 2011, Mauro Carvalho Chehab wrote:
Em 17-02-2011 17:26, Guennadi Liakhovetski escreveu:
Hi Mauro
Thanks for your comments.
On Thu, 17 Feb 2011, Mauro Carvalho Chehab wrote:
Em 16-02-2011 08:35, Guennadi Liakhovetski escreveu:
[snip]
(2) cleanly separate
On Thu, 17 Feb 2011, Mauro Carvalho Chehab wrote:
There's an additional problem with that: assume that streaming is
happening, and a S_FMT changing the resolution was sent. There's
no way to warrant that the very next frame will have the new
resolution. So, a meta-data with the frame
Hi Guennadi,
Here is my take on this:
On Wednesday, February 16, 2011 08:42:51 Guennadi Liakhovetski wrote:
Hi,
On Tue, 15 Feb 2011, Qing Xu wrote:
Please, don't top-post and use a proper quoting.
Hi,
I have a question that why we must check icf-vb_vidq.bufs[0] in
Hi Hans
Thanks for looking at it!
On Wed, 16 Feb 2011, Hans Verkuil wrote:
Hi Guennadi,
Here is my take on this:
On Wednesday, February 16, 2011 08:42:51 Guennadi Liakhovetski wrote:
[snip]
3. Not liking either of the above, it seems we need yet a new API for
this... How about
Hi Guennadi,
On Wednesday 16 February 2011 10:02:18 Guennadi Liakhovetski wrote:
On Wed, 16 Feb 2011, Hans Verkuil wrote:
On Wednesday, February 16, 2011 08:42:51 Guennadi Liakhovetski wrote:
[snip]
I definitely don't like solutions 1 and 2 either, so I'll only comment on 3.
3. Not
Hi Laurent
Thanks for commenting.
On Wed, 16 Feb 2011, Laurent Pinchart wrote:
Hi Guennadi,
On Wednesday 16 February 2011 10:02:18 Guennadi Liakhovetski wrote:
On Wed, 16 Feb 2011, Hans Verkuil wrote:
On Wednesday, February 16, 2011 08:42:51 Guennadi Liakhovetski wrote:
[snip]
I
Adding Manjunath Hadli to the list...
Murail
-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Tuesday, February 15, 2011 12:34 PM
To: Linux Media Mailing List
Cc: Qing Xu; Hans Verkuil; Neil Johnson; Robert Jarzmik; Uwe Taeubert;
Karicheri,
Hi,
I have a question that why we must check icf-vb_vidq.bufs[0] in
s_fmt_vid_cap()? The application mainly calling sequence at switching
fmt could be like this:
streamoff
s_fmt_vid_cap
request_buf
qbuf...qbuf
streamon
qbuf/dqbuf
...
The application should also aware that they are switching the
Hi,
On Tue, 15 Feb 2011, Qing Xu wrote:
Please, don't top-post and use a proper quoting.
Hi,
I have a question that why we must check icf-vb_vidq.bufs[0] in
s_fmt_vid_cap()? The application mainly calling sequence at switching
fmt could be like this:
streamoff
s_fmt_vid_cap
request_buf
26 matches
Mail list logo
