Hi,
On 03/05/2012 01:03 PM, Jean-Francois Moine wrote:
On Mon, 05 Mar 2012 09:33:18 +0100
Hans de Goede<hdego...@redhat.com> wrote:
I guess that motion is using the JPG compressed frames rather then
the i420 like special format these cameras also support, and it looks
like we don't reserve enoug space to buffer these frames. To fix this
we need to enlarge the size we reserve per frame in the sn9c20x driver,
edit sn9c20x.c and search for vga_mode, in that table you will
find a factor "4 / 8" (its in there 3 times), change all 3 occurences
to "5 / 8" and try again, then "6 / 8", etc.
Normally I would be suspicious about SOF / EOF detection when we
need such a factor, but the timestamps in your log exactly match 30
fps, so that seems to be fine. And in my experience with the USB bandwidth
stuff the sn9c20x does seem to compress less then other JPG cams, so
it makes sense that it needs bigger buffers to store the frames too.
Hi Hans,
The JPEG compression quality of the sn9c20x is 95%. That's why the
frames are so big. Then, if the quality is not settable, I wonder why
to use the JPEG format.
I think the quality is settable, and we are just not setting it to a very
useful value. I'm afraid I don't have time to work on this atm, but if you
are willing to take a shot at this, then I can test (I've such a camera).
I'll send you a private mail with info on how to set the compression
ratio.
BTW, I wonder also about the SN9C20X_I420: this format asks for a
buffer greater than the native image.
Yes, but then the data is ready to use, since most apps actuall want i420,
where as raw bayer needs a lot of CPU intensive processing before we get
useful data out of it.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html