From: Andy Walls <awalls@md.metrocast.net>
To: Jean-Francois Moine <moinejf@free.fr>
Cc: Ondrej Zary <linux@rainbow-software.org>, linux-media@vger.kernel.org
Subject: Re: SPCA1527A/SPCA1528 (micro)SD camera in webcam mode
Date: Sun, 30 May 2010 14:30:07 -0400 [thread overview]
Message-ID: <1275244207.2275.22.camel@localhost> (raw)
In-Reply-To: <20100530133455.489c4f46@tele>
On Sun, 2010-05-30 at 13:34 +0200, Jean-Francois Moine wrote:
> On Sat, 29 May 2010 21:32:07 +0200
> Ondrej Zary <linux@rainbow-software.org> wrote:
>
> > The Color Space/Compression reported by the driver is only one: RGB 24
> > The driver also uses these files which may (or may not) be related to
> > used compression: iyuv_32.dll, msh263.drv, msyuv.dll, tsbyuv.dll
> > In standalone mode, the camera records video in MJPEG format.
>
> Hello Ondrej,
>
> Bad news, the images are compressed by an unknown algorithm (unknown
> from Linux point of vue). The decompression function could be found in
> some part of the ms-win driver, but:
> - first, I have no time to search and disassemble this function,
> - then, I did have this problem with an other webcam (17a1:0118), and
> after searching for a long time, nobody could find the function, and
> the driver is in stand-by since 2 years,
> - eventually, is this legal?
>
> All I can do is to code the driver and let you or anyone find the
> decompression function...
I ran into this with my daughetr's cheap little Sakar webcam based on a
Jeilin chip. After some investigation about the chip and learning it
being only able to perform JPEG compression, it was rather easy to
figure out it was just sending MJPEG data with the headers stripped off.
This thread from last year tells most of the story
http://www.mail-archive.com/linux-media@vger.kernel.org/msg06766.html
(Many thanks to Theodore for doing the legwork on experiments and a new
GSPCA driver - jeilinj)
Since your camera records MJPEG in stand-alone mode (mine recorded MJPEG
in an AVI container in stand-alone mode), it stands to reason, your
camera may be doing the same sort of thing. The payload of MJPEG data
will look very random since the compressed data is Huffman (entropy)
encoded in the final step of encoding.
Regards,
Andy
prev parent reply other threads:[~2010-05-30 18:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-29 17:09 SPCA1527A/SPCA1528 (micro)SD camera in webcam mode Ondrej Zary
2010-05-29 18:24 ` Jean-Francois Moine
2010-05-29 19:32 ` Ondrej Zary
2010-05-30 11:34 ` Jean-Francois Moine
2010-05-30 17:55 ` Ondrej Zary
2010-05-30 18:13 ` Jean-Francois Moine
2010-05-31 2:36 ` Andy Walls
2010-05-31 3:15 ` Theodore Kilgore
2010-05-30 19:26 ` Andy Walls
2010-05-30 21:28 ` Ondrej Zary
2010-05-30 21:58 ` Andy Walls
2010-05-30 22:03 ` Ondrej Zary
2010-05-31 3:06 ` Theodore Kilgore
2010-05-31 7:19 ` Jean-Francois Moine
2010-05-31 7:56 ` Ondrej Zary
2010-05-31 12:43 ` Andy Walls
2010-05-30 18:30 ` Andy Walls [this message]
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=1275244207.2275.22.camel@localhost \
--to=awalls@md.metrocast.net \
--cc=linux-media@vger.kernel.org \
--cc=linux@rainbow-software.org \
--cc=moinejf@free.fr \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox