All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: linux-media@vger.kernel.org
Subject: Re: V4L-DVB Summit Day 1
Date: Thu, 24 Sep 2009 20:07:27 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0909242000240.4913@axis700.grange> (raw)
In-Reply-To: <200909232239.20105.hverkuil@xs4all.nl>

Hi Hans

Thanks for keeping us updated. One comment:

On Wed, 23 Sep 2009, Hans Verkuil wrote:

> In the afternoon we discussed the proposed timings API. There was no 
> opposition to this API. The idea I had to also use this for sensor setup 
> turned out to be based on a misconception on how the S_FMT relates to sensors. 
> ENUM_FRAMESIZES basically gives you the possible resolutions that the scaler 
> hidden inside the bridge can scale the native sensor resolution. It does not 
> enumerate the various native sensor resolutions, since there is only one. So 
> S_FMT really sets up the scaler.

Just as Jinlu Yu noticed in his email, this doesn't reflect the real 
situation, I am afraid. You can use binning and skipping on the sensor to 
scale the image, and you can also use the bridge to do the scaling, as you 
say. Worth than that, there's also a case, where there _several_ ways to 
perform scaling on the sensor, among which one can freely choose, and the 
host can scale too. And indeed it makes sense to scale on the source to 
save the bandwidth and thus increase the framerate. So, what I'm currently 
doing on sh-mobile, I try to scale on the client - in the best possible 
way. And then use bridge scaling to provide the exact result.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

  parent reply	other threads:[~2009-09-24 18:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-24  5:39 V4L-DVB Summit Day 1 Hans Verkuil
2009-09-24 11:52 ` Yu, Jinlu
2009-09-24 18:07 ` Guennadi Liakhovetski [this message]
2009-09-26  8:40   ` Dongsoo, Nathaniel Kim
2009-09-26  9:32     ` Guennadi Liakhovetski
2009-09-26 13:06       ` Dongsoo, Nathaniel Kim
2009-09-26 19:31         ` 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=Pine.LNX.4.64.0909242000240.4913@axis700.grange \
    --to=g.liakhovetski@gmx.de \
    --cc=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 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.