From: Hans de Goede <hdegoede@redhat.com>
To: "Bjørn Mork" <bjorn@mork.no>
Cc: linux-media@vger.kernel.org
Subject: Re: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34
Date: Thu, 03 Jun 2010 10:41:57 +0200 [thread overview]
Message-ID: <4C076AD5.2090909@redhat.com> (raw)
In-Reply-To: <87r5kod2dm.fsf@nemi.mork.no>
Hi,
On 06/03/2010 09:03 AM, Bjørn Mork wrote:
> Mauro Carvalho Chehab<mchehab@infradead.org> writes:
>> Em 02-06-2010 18:09, Andrew Morton escreveu:
>>> On Sun, 30 May 2010 14:29:55 GMT
>>> bugzilla-daemon@bugzilla.kernel.org wrote:
>>>
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=16077
>>>
>>> 2.6.33 -> 2.6.34 performance regression in dvb webcam frame rates.
>>
>> I don't think this is a regression. Probably, the new code is allowing a higher
>> resolution. As the maximum bandwidth from the sensor to the USB bridge doesn't
>> change, and a change from QVGA to VGA implies on 4x more pixels per frame, as
>> consequence, the number of frames per second will likely reduce by a factor of 4x.
>>
>> I've asked the reporter to confirm what resolutions he is setting on 2.6.33
>> and on 2.6.34, just to double check if my thesis is correct.
>
> Well, the two video clips attached to the bug shows the same resolution
> but a much, much lower video (and overall) bitrate in 2.6.34. Output
> from mediainfo:
>
I notice in the original bug report that you claim that the lower framerate
clip with 2.6.34 has "much better quality", could you define this a bit better.
I think that what is happening is the code for the new (correct) sensor is
setting a higher exposure value (and thus a lighter / less dark image), but
setting a higher exposure value comes at the cost of framerate. As the framerate
can never be higher then 1 / exposure_time_for_1_frame.
2 things:
1) Go the preferences in cheese, and see which resolutions you can select, and
make sure you are using the same resolution in 2.6.34 and 2.6.33
2) Start a v4l2 control panel applet, like v4l2ucp or gtk-v4l, and try playing
around with the controls (note the controls inside cheese are software not
hardware controls so don't use those).
Regards,
Hans
next prev parent reply other threads:[~2010-06-03 8:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-16077-10286@https.bugzilla.kernel.org/>
2010-06-02 21:09 ` [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34 Andrew Morton
2010-06-03 3:41 ` Mauro Carvalho Chehab
2010-06-03 7:03 ` Bjørn Mork
2010-06-03 8:41 ` Hans de Goede [this message]
2010-06-03 8:51 ` Bjørn Mork
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=4C076AD5.2090909@redhat.com \
--to=hdegoede@redhat.com \
--cc=bjorn@mork.no \
--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.