Re: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34

Re: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34

[Andrew Morton]

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.

Re: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34

[Mauro Carvalho Chehab]

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.

Cheers,
Mauro.

Re: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34

[Bjørn Mork]

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:

General
Complete name                    : 2.6.33-02063303-generic #02063303.ogv
Format                           : OGG
File size                        : 672 KiB
Duration                         : 6s 331ms
Overall bit rate                 : 870 Kbps

Video
ID                               : 20423689 (0x137A409)
Format                           : Theora
Duration                         : 6s 333ms
Bit rate                         : 714 Kbps
Width                            : 320 pixels
Height                           : 240 pixels
Display aspect ratio             : 4:3
Frame rate                       : 30.000 fps
Bits/(Pixel*Frame)               : 0.310
Stream size                      : 552 KiB (82%)
Writing library                  : Xiph.Org libtheora 1.1 20090822 (Thusnelda)

Audio
ID                               : 1459180980 (0x56F955B4)
Format                           : Vorbis
Format settings, Floor           : 1
Duration                         : 6s 331ms
Bit rate mode                    : Constant
Bit rate                         : 112 Kbps
Channel(s)                       : 2 channels
Sampling rate                    : 44.1 KHz
Stream size                      : 86.6 KiB (13%)
Writing library                  : libVorbis 20090709 (UTC 2009-07-09)

General
Complete name                    : 2.6.34-999-generic #201005121008.ogv
Format                           : OGG
File size                        : 276 KiB
Duration                         : 15s 424ms
Overall bit rate                 : 146 Kbps

Video
ID                               : 12773534 (0xC2E89E)
Format                           : Theora
Duration                         : 15s 433ms
Bit rate                         : 19.8 Kbps
Width                            : 320 pixels
Height                           : 240 pixels
Display aspect ratio             : 4:3
Frame rate                       : 30.000 fps
Bits/(Pixel*Frame)               : 0.009
Stream size                      : 37.2 KiB (14%)
Writing library                  : Xiph.Org libtheora 1.1 20090822 (Thusnelda)

Audio
ID                               : 1010301390 (0x3C37F9CE)
Format                           : Vorbis
Format settings, Floor           : 1
Duration                         : 15s 424ms
Bit rate mode                    : Constant
Bit rate                         : 112 Kbps
Channel(s)                       : 2 channels
Sampling rate                    : 44.1 KHz
Stream size                      : 211 KiB (76%)
Writing library                  : libVorbis 20090709 (UTC 2009-07-09)


Bjørn

Re: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34

[Hans de Goede]

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

Re: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34

[Bjørn Mork]

Hans de Goede <hdegoede@redhat.com> writes:

> 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.

Sorry for the confusion, but this wasn't me.  I just read the bug report.


Bjørn