* Sakar 57379 USB Digital Video Camera...
@ 2009-06-19 1:40 Andy Walls
2009-06-19 2:43 ` Theodore Kilgore
0 siblings, 1 reply; 23+ messages in thread
From: Andy Walls @ 2009-06-19 1:40 UTC (permalink / raw)
To: Linux Media Mailing List; +Cc: Theodore Kilgore
My daughter just got one of these toy digital video recorder & webcam
unit.
It normally shows up as a mass storage drive.
If I hold down the shutter button while connecting the USB cable, the
camera LCD show a "webcam mode" icon and it shows up as a different USB
device.
Any chance of this working as a webcam under linux?
Regards,
Andy
lsusb -vvv output:
Mass storage mode:
Bus 003 Device 003: ID 0979:0371 Jeilin Technology Corp., Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0979 Jeilin Technology Corp., Ltd
idProduct 0x0371
bcdDevice 1.00
iManufacturer 1 Jeilin
iProduct 2 USB 1.1 Device
iSerial 3 09790
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 46
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 4 SMC CF SD
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
Webcam mode:
Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0979 Jeilin Technology Corp., Ltd
idProduct 0x0280
bcdDevice 1.00
iManufacturer 1 Jeilin
iProduct 2 USB 1.1 Device
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 46
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 0 (Defined at Interface level)
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 4 SMC CF SD
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-19 1:40 Sakar 57379 USB Digital Video Camera Andy Walls
@ 2009-06-19 2:43 ` Theodore Kilgore
2009-06-19 4:40 ` Andy Walls
0 siblings, 1 reply; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-19 2:43 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
On Thu, 18 Jun 2009, Andy Walls wrote:
> My daughter just got one of these toy digital video recorder & webcam
> unit.
>
> It normally shows up as a mass storage drive.
>
> If I hold down the shutter button while connecting the USB cable, the
> camera LCD show a "webcam mode" icon and it shows up as a different USB
> device.
>
> Any chance of this working as a webcam under linux?
>
> Regards,
> Andy
>
>
> lsusb -vvv output:
>
> Mass storage mode:
>
> Bus 003 Device 003: ID 0979:0371 Jeilin Technology Corp., Ltd
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 1.10
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 8
> idVendor 0x0979 Jeilin Technology Corp., Ltd
> idProduct 0x0371
> bcdDevice 1.00
> iManufacturer 1 Jeilin
> iProduct 2 USB 1.1 Device
> iSerial 3 09790
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 46
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0x80
> (Bus Powered)
> MaxPower 500mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 4
> bInterfaceClass 8 Mass Storage
> bInterfaceSubClass 6 SCSI
> bInterfaceProtocol 80 Bulk (Zip)
> iInterface 4 SMC CF SD
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x01 EP 1 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0008 1x 8 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0008 1x 8 bytes
> bInterval 0
> Device Status: 0x0000
> (Bus Powered)
>
>
>
> Webcam mode:
>
> Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 1.10
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 8
> idVendor 0x0979 Jeilin Technology Corp., Ltd
> idProduct 0x0280
> bcdDevice 1.00
> iManufacturer 1 Jeilin
> iProduct 2 USB 1.1 Device
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 46
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0x80
> (Bus Powered)
> MaxPower 500mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 4
> bInterfaceClass 0 (Defined at Interface level)
> bInterfaceSubClass 0
> bInterfaceProtocol 0
> iInterface 4 SMC CF SD
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x01 EP 1 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82 EP 2 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03 EP 3 OUT
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0008 1x 8 bytes
> bInterval 0
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x84 EP 4 IN
> bmAttributes 2
> Transfer Type Bulk
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0008 1x 8 bytes
> bInterval 0
> Device Status: 0x0000
> (Bus Powered)
>
>
>
Interesting. To answer your question, I have no idea off the top of my
head. I do have what seems to be a similar camera. It is
Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd
and the rest of the lsusb output looks quite similar. I do not know,
though, if it has any chance of working as a webcam. Somehow, the thought
never occurred to me back when I got the thing. I would have to hunt some
stuff down even to know if it is claimed to work as a webcam.
You did say that it comes up as a different USB device when it is a
webcam? You mean, a different product ID or so?
Some history about my camera, which will perhaps make you smile:
I got it a couple of years ago, at about the same time that someone in
Germany got a similar camera, and he wanted to get it supported. He wanted
to stick it on a model airplane, IIRC, and take pictures. Well, it says it
is a mass storage device. But it wouldn't work with the mass storage
driver. So I got on the mass-storage mailing list about the camera. Alan
Stern was the one who figured out first what was the problem. I was right
behind him, and it made me feel stupid that I was slower than he was. But
you do have to be mighty good to keep up with Alan, so I really don't feel
bad. What was the problem? Well, notice that there are two pairs of bulk
endpoints. The camera uses one pair for data, and the other pair for
commands. But which pair? Well, the mass storage driver at the time was
choosing the wrong pair. And it was the camera which was in spec, not the
mass storage stack. Needless to say, that got fixed, pronto. And all
because of one of these pesky cameras.
Another general comment about Jeilin is probably not relevant here,
but I will make it anyway:
Some of their cameras (the 0979:0227 cameras) use a really nasty
compression algorithm. These are also dual-mode still and web cams. There
is no hope of supporting them unless the compression is figured out. I
hope some clever guy reads this comment.
Probably what is happening with your camera is, it is using something like
JPEG in stillcam mode? If so, it might possibly send down JPEG frames in
webcam mode, too. Perhaps with the use of SnoopyPro or such, it is
possible to find out?
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-19 2:43 ` Theodore Kilgore
@ 2009-06-19 4:40 ` Andy Walls
2009-06-19 17:47 ` Theodore Kilgore
0 siblings, 1 reply; 23+ messages in thread
From: Andy Walls @ 2009-06-19 4:40 UTC (permalink / raw)
To: Theodore Kilgore; +Cc: Linux Media Mailing List
On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote:
>
> On Thu, 18 Jun 2009, Andy Walls wrote:
> >
> >
> >
>
> Interesting. To answer your question, I have no idea off the top of my
> head. I do have what seems to be a similar camera. It is
>
> Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd
>
> and the rest of the lsusb output looks quite similar. I do not know,
> though, if it has any chance of working as a webcam. Somehow, the thought
> never occurred to me back when I got the thing. I would have to hunt some
> stuff down even to know if it is claimed to work as a webcam.
The packaging that mine came in claims "3-in-1":
digital video camcorder (with microphone)
digital camera
web cam
> You did say that it comes up as a different USB device when it is a
> webcam? You mean, a different product ID or so?
Yes
Look for this in the original lsusb output I provided
:
> > Webcam mode:
> >
> > Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd
> > Device Descriptor:
Regards,
Andy
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-19 4:40 ` Andy Walls
@ 2009-06-19 17:47 ` Theodore Kilgore
2009-06-19 18:16 ` Andy Walls
0 siblings, 1 reply; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-19 17:47 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
On Fri, 19 Jun 2009, Andy Walls wrote:
> On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote:
>>
>> On Thu, 18 Jun 2009, Andy Walls wrote:
>>>
>>>
>>>
>>
>> Interesting. To answer your question, I have no idea off the top of my
>> head. I do have what seems to be a similar camera. It is
>>
>> Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd
>>
>> and the rest of the lsusb output looks quite similar. I do not know,
>> though, if it has any chance of working as a webcam. Somehow, the thought
>> never occurred to me back when I got the thing. I would have to hunt some
>> stuff down even to know if it is claimed to work as a webcam.
>
> The packaging that mine came in claims "3-in-1":
>
> digital video camcorder (with microphone)
> digital camera
> web cam
>
>
>> You did say that it comes up as a different USB device when it is a
>> webcam? You mean, a different product ID or so?
>
> Yes
>
> Look for this in the original lsusb output I provided
> :
>>> Webcam mode:
>>>
>>> Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd
>>> Device Descriptor:
Oops, right you are. Blame it on my old eyes. They are the same age as the
rest of me, but sometimes they feel older.
Another thing I could not see in front of me when I looked at my Jeilin
Mass Storage camera, was what is written on it. It says there it is a
Cobra DMC300, and it says
"Digital Video & Camera"
I never paid any attention to that before, because for years my priorities
were still cameras. But now, just in case I have lost the driver CD, I
went out to Google and found what claims to be a driver for it. I hope
that, with such a long idleness just sitting on a back corner of the desk,
the battery has not died in the camera. If I get some time in the next few
days to try to fight Windows, I will make some logs of my own. Then we can
compare notes and see if the two cameras are similar, or not. What I am
hoping for, obviously, is that both cameras are downloading JPEG frames,
and use similar methods to do that. If that is true (we don't know that,
of course) then the only problem I can imagine is that both of them are
reported, even in webcam mode, as Mass Storage Bulk Transport devices. If
so, then the camera(s) would need to be blacklisted by mass-storage when
set up as webcams.
Now that I got the supposed driver, I should go out on the web and get the
supposed manual for my camera. Then perhaps I can know how it is supposed
to be used as a webcam and get the needed sniffs. Meanwhile, I hope that
you will do the same.
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-19 17:47 ` Theodore Kilgore
@ 2009-06-19 18:16 ` Andy Walls
2009-06-19 20:09 ` Theodore Kilgore
2009-06-20 0:26 ` Theodore Kilgore
0 siblings, 2 replies; 23+ messages in thread
From: Andy Walls @ 2009-06-19 18:16 UTC (permalink / raw)
To: Theodore Kilgore; +Cc: Linux Media Mailing List
On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote:
>
> On Fri, 19 Jun 2009, Andy Walls wrote:
>
> > On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote:
> >>
> >> On Thu, 18 Jun 2009, Andy Walls wrote:
> >>>
> >>>
> >>>
> >>
> >> Interesting. To answer your question, I have no idea off the top of my
> >> head. I do have what seems to be a similar camera. It is
> >>
> >> Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd
> >>
> >> and the rest of the lsusb output looks quite similar. I do not know,
> >> though, if it has any chance of working as a webcam. Somehow, the thought
> >> never occurred to me back when I got the thing. I would have to hunt some
> >> stuff down even to know if it is claimed to work as a webcam.
> >
> > The packaging that mine came in claims "3-in-1":
> >
> > digital video camcorder (with microphone)
> > digital camera
> > web cam
> >
> >
> >> You did say that it comes up as a different USB device when it is a
> >> webcam? You mean, a different product ID or so?
> >
> > Yes
> >
> > Look for this in the original lsusb output I provided
> > :
> >>> Webcam mode:
> >>>
> >>> Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd
> >>> Device Descriptor:
>
> Oops, right you are. Blame it on my old eyes. They are the same age as the
> rest of me, but sometimes they feel older.
>
> Another thing I could not see in front of me when I looked at my Jeilin
> Mass Storage camera, was what is written on it. It says there it is a
> Cobra DMC300, and it says
>
> "Digital Video & Camera"
>
> I never paid any attention to that before, because for years my priorities
> were still cameras. But now, just in case I have lost the driver CD, I
> went out to Google and found what claims to be a driver for it. I hope
> that, with such a long idleness just sitting on a back corner of the desk,
> the battery has not died in the camera. If I get some time in the next few
> days to try to fight Windows, I will make some logs of my own. Then we can
> compare notes and see if the two cameras are similar, or not. What I am
> hoping for, obviously, is that both cameras are downloading JPEG frames,
> and use similar methods to do that. If that is true (we don't know that,
> of course) then the only problem I can imagine is that both of them are
> reported, even in webcam mode, as Mass Storage Bulk Transport devices. If
> so, then the camera(s) would need to be blacklisted by mass-storage when
> set up as webcams.
>
> Now that I got the supposed driver, I should go out on the web and get the
> supposed manual for my camera. Then perhaps I can know how it is supposed
> to be used as a webcam and get the needed sniffs. Meanwhile, I hope that
> you will do the same.
OK. I have two steps to take:
1. Installing the driver and software on my sole remaining Windows
machine. It already has snoopy.
2. Getting the camera away from my daughter for more than 2 minutes.
It's like the thing is glued to her hand. :)
Regards,
Andy
> Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-19 18:16 ` Andy Walls
@ 2009-06-19 20:09 ` Theodore Kilgore
2009-06-20 0:26 ` Theodore Kilgore
1 sibling, 0 replies; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-19 20:09 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
On Fri, 19 Jun 2009, Andy Walls wrote:
> On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote:
>>
>> On Fri, 19 Jun 2009, Andy Walls wrote:
>>
>>> On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote:
>>>>
>>>> On Thu, 18 Jun 2009, Andy Walls wrote:
>>>>>
>>>>>
>>>>>
>>>>
>>>> Interesting. To answer your question, I have no idea off the top of my
>>>> head. I do have what seems to be a similar camera. It is
>>>>
>>>> Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd
>>>>
>>>> and the rest of the lsusb output looks quite similar. I do not know,
>>>> though, if it has any chance of working as a webcam. Somehow, the thought
>>>> never occurred to me back when I got the thing. I would have to hunt some
>>>> stuff down even to know if it is claimed to work as a webcam.
>>>
>>> The packaging that mine came in claims "3-in-1":
>>>
>>> digital video camcorder (with microphone)
>>> digital camera
>>> web cam
>>>
>>>
>>>> You did say that it comes up as a different USB device when it is a
>>>> webcam? You mean, a different product ID or so?
>>>
>>> Yes
>>>
>>> Look for this in the original lsusb output I provided
>>> :
>>>>> Webcam mode:
>>>>>
>>>>> Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd
>>>>> Device Descriptor:
>>
>> Oops, right you are. Blame it on my old eyes. They are the same age as the
>> rest of me, but sometimes they feel older.
>>
>> Another thing I could not see in front of me when I looked at my Jeilin
>> Mass Storage camera, was what is written on it. It says there it is a
>> Cobra DMC300, and it says
>>
>> "Digital Video & Camera"
>>
>> I never paid any attention to that before, because for years my priorities
>> were still cameras. But now, just in case I have lost the driver CD, I
>> went out to Google and found what claims to be a driver for it. I hope
>> that, with such a long idleness just sitting on a back corner of the desk,
>> the battery has not died in the camera. If I get some time in the next few
>> days to try to fight Windows, I will make some logs of my own. Then we can
>> compare notes and see if the two cameras are similar, or not. What I am
>> hoping for, obviously, is that both cameras are downloading JPEG frames,
>> and use similar methods to do that. If that is true (we don't know that,
>> of course) then the only problem I can imagine is that both of them are
>> reported, even in webcam mode, as Mass Storage Bulk Transport devices. If
>> so, then the camera(s) would need to be blacklisted by mass-storage when
>> set up as webcams.
>>
>> Now that I got the supposed driver, I should go out on the web and get the
>> supposed manual for my camera. Then perhaps I can know how it is supposed
>> to be used as a webcam and get the needed sniffs. Meanwhile, I hope that
>> you will do the same.
>
> OK. I have two steps to take:
>
> 1. Installing the driver and software on my sole remaining Windows
> machine. It already has snoopy.
Great.
>
> 2. Getting the camera away from my daughter for more than 2 minutes.
> It's like the thing is glued to her hand. :)
>
Oops. Not so good. Luck to you with that. But I hope that your daughter is
suitably impressed with the idea of making things work in Linux, and
suitably impressed with her father's skills about that kind of thing.
I should mention. Mine has a microphone, too. Let us hope that the two are
essentially identical except for things like packaging. And let us hope
that the webcam functionality is not using some kind of weird compression
algorithm. But yours, like mine, is using JPEG in still mode, right? So if
it is using some weirdo scheme in webcam mode that will be both unpleasant
and surprising.
The only other things which might interfere are the following:
1. I am teaching in summer school. I just gave a test and I have to grade
it over the weekend. The final exam is next Friday, so I will be
similarly engaged.
2. We are going on vacation on July 7 and returning on July 23. My wife
says that we will spend our spare time this weekend in planning. Because
of this and because of item 1, I do not know whether or not I will be able
to do the OEM install over here, or not, before next week.
3. Still working to finish expanding the mr97310a driver to support all
known cameras with that chip in them. Believe it or not, some of those
which have the chip and share a common Vendor:Product number work
differently. So, ad-hoc methods needed to be figured out to classify them.
This has been done, and all known cameras now work. There are four
different initialization sequences to be taken into account. They all
work. What is left to do now is to figure out how to apply the needed
control sequences for things like brightness, gamma, white balance, and so
forth and so on.
So I am busy, but at the same time I am very much interested in taking
this project on, too, because it involves something I have worked on in
the past, myself. So let us see how it appears to come out. If I can get
your log file, it will probably give a good start.
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-19 18:16 ` Andy Walls
2009-06-19 20:09 ` Theodore Kilgore
@ 2009-06-20 0:26 ` Theodore Kilgore
2009-06-20 1:54 ` Andy Walls
1 sibling, 1 reply; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-20 0:26 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
On Fri, 19 Jun 2009, Andy Walls wrote:
> On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote:
>>
>> On Fri, 19 Jun 2009, Andy Walls wrote:
>>
>>> On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote:
>>>>
>>>> On Thu, 18 Jun 2009, Andy Walls wrote:
>>>>>
>>>>>
>>>>>
>>>>
>>>> Interesting. To answer your question, I have no idea off the top of my
>>>> head. I do have what seems to be a similar camera. It is
>>>>
>>>> Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd
>>>>
>>>> and the rest of the lsusb output looks quite similar. I do not know,
>>>> though, if it has any chance of working as a webcam. Somehow, the thought
>>>> never occurred to me back when I got the thing. I would have to hunt some
>>>> stuff down even to know if it is claimed to work as a webcam.
>>>
>>> The packaging that mine came in claims "3-in-1":
>>>
>>> digital video camcorder (with microphone)
>>> digital camera
>>> web cam
>>>
>>>
>>>> You did say that it comes up as a different USB device when it is a
>>>> webcam? You mean, a different product ID or so?
>>>
>>> Yes
>>>
>>> Look for this in the original lsusb output I provided
>>> :
>>>>> Webcam mode:
>>>>>
>>>>> Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd
>>>>> Device Descriptor:
>>
>> Oops, right you are. Blame it on my old eyes. They are the same age as the
>> rest of me, but sometimes they feel older.
And the upshot is that we may have the same camera, at least as a webcam,
perhaps with a different name. I finally made mine to work in webcam mode.
On mine, one has to press down a button labelled "DV" at the same time as
pressing down the button with the picture of a camera beside it, to turn
on the webcam mode. As opposed to just pressing the "camera" button to
turn on the camera to shoot a picture.
> OK. I have two steps to take:
>
> 1. Installing the driver and software on my sole remaining Windows
> machine. It already has snoopy.
>
> 2. Getting the camera away from my daughter for more than 2 minutes.
> It's like the thing is glued to her hand. :)
I hope that you can still manage to do these things. I did get a snoop log
of my own, but it would be nice to have some confirmation, too, that the
cameras really are acting the same way. That may look like a stupid thing
to say until one realizes that things which have the same USB
Vendor:Product number do _not_ necessarily act the same way.
Well, here are some of the things I learned:
As a stillcam, it is confirmed that my cam is a standard mass storage
device, transparent SCSI, bulk. It uses outep 0x01 and inep 0x82 (the
first pair of endpoints).
Here it is as a mass storage device.
T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0979 ProdID=0371 Rev= 1.00
S: Manufacturer=Jeilin
S: Product=USB 1.1 Device
S: SerialNumber=09790
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 4 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms
and here it is as a webcam.
T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 16 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0979 ProdID=0280 Rev= 1.00
S: Manufacturer=Jeilin
S: Product=USB 1.1 Device
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 4 Cls=00(>ifc ) Sub=00 Prot=00 Driver=(none)
E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms
Now it is using the other pair of endpoints, 0x03 and 0x84.
There is a sequence of init commands
00000000: 71 81
00000000: 70 05
00000000: 95 70
00000000: 00 (all the 00 are responses)
00000000: 71 81
00000000: 70 04
00000000: 95 70
00000000: 00
00000000: 71 00
00000000: 70 08
00000000: 95 70
00000000: 00
00000000: 94 02
00000000: de 24
00000000: 94 02
00000000: dd f0
00000000: 94 02
00000000: e3 2c
00000000: 94 02
00000000: e4 00
00000000: 94 02
00000000: e5 00
00000000: e5 00
00000000: 94 02
00000000: e6 2c
00000000: 94 03
00000000: aa 00
00000000: 71 1e
00000000: 70 06
00000000: 71 80
00000000: 70 07
and then it starts to stream. The stream downloads 0x200 (512) bytes at a
time. It appears that there is an SOF marker consisting of
ff ff ff ff
followed by at least two zeroes. These seem to occur only at the
beginnings of some of the downloaded 0x200-sized blocks.
There is a closing sequence at the end which is similar to the init
sequence
00000000: 71 00
00000000: 70 09
00000000: 71 80
00000000: 70 05
It would be interesting to see your log file and to compare. I could also
send you this one if you are curious, but it is 5,760,902 bytes so I
should ask that if you want to see it then how to send it? Me, I suspect
that if you have one of similar size and bz2 it and send it to me as an
attachment, then it is not any problem.
Now, having found an excuse not to finish grading those papers today, I
will probably have to pay more concentrated attention to grading and
travel planning tomorrow. But do send the log along anyway if you can get
it done.
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-20 0:26 ` Theodore Kilgore
@ 2009-06-20 1:54 ` Andy Walls
2009-06-20 4:38 ` Theodore Kilgore
0 siblings, 1 reply; 23+ messages in thread
From: Andy Walls @ 2009-06-20 1:54 UTC (permalink / raw)
To: Theodore Kilgore; +Cc: Linux Media Mailing List
On Fri, 2009-06-19 at 19:26 -0500, Theodore Kilgore wrote:
>
> On Fri, 19 Jun 2009, Andy Walls wrote:
>
> > On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote:
> >>
> >> On Fri, 19 Jun 2009, Andy Walls wrote:
> >>
> >>> On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote:
> >>>>
> >>>> On Thu, 18 Jun 2009, Andy Walls wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> Interesting. To answer your question, I have no idea off the top of my
> >>>> head. I do have what seems to be a similar camera. It is
> >>>>
> >>>> Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd
> >>>>
> >>>> and the rest of the lsusb output looks quite similar. I do not know,
> >>>> though, if it has any chance of working as a webcam. Somehow, the thought
> >>>> never occurred to me back when I got the thing. I would have to hunt some
> >>>> stuff down even to know if it is claimed to work as a webcam.
> >>>
> >>> The packaging that mine came in claims "3-in-1":
> >>>
> >>> digital video camcorder (with microphone)
> >>> digital camera
> >>> web cam
> >>>
> >>>
> >>>> You did say that it comes up as a different USB device when it is a
> >>>> webcam? You mean, a different product ID or so?
> >>>
> >>> Yes
> >>>
> >>> Look for this in the original lsusb output I provided
> >>> :
> >>>>> Webcam mode:
> >>>>>
> >>>>> Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd
> >>>>> Device Descriptor:
> >>
> >> Oops, right you are. Blame it on my old eyes. They are the same age as the
> >> rest of me, but sometimes they feel older.
>
> And the upshot is that we may have the same camera, at least as a webcam,
> perhaps with a different name. I finally made mine to work in webcam mode.
> On mine, one has to press down a button labelled "DV" at the same time as
> pressing down the button with the picture of a camera beside it, to turn
> on the webcam mode. As opposed to just pressing the "camera" button to
> turn on the camera to shoot a picture.
Ah, very nice. The secret handshake that only the manual (usually lost)
can tell you.
> > OK. I have two steps to take:
> >
> > 1. Installing the driver and software on my sole remaining Windows
> > machine. It already has snoopy.
> >
> > 2. Getting the camera away from my daughter for more than 2 minutes.
> > It's like the thing is glued to her hand. :)
>
> I hope that you can still manage to do these things. I did get a snoop log
> of my own, but it would be nice to have some confirmation, too, that the
> cameras really are acting the same way. That may look like a stupid thing
> to say until one realizes that things which have the same USB
> Vendor:Product number do _not_ necessarily act the same way.
Yes. I might need a little time. This weekend is Father's day, and I
got to go see family tomorrow and will be hosting more family on
Saturday evening and Sunday. I doubt I'll have time to look at this
before Sunday night (and by then I suspect I'll be drinking beer. :))
I did let gThumb import some files from my daughter's camera (Ireally
should have pulled them over myself from the "mass storage drive").
Here's how they ended up:
$ file *
00001.jpg: JPEG image data, EXIF standard 2.2
00002.jpg: JPEG image data, EXIF standard 2.2
00003.jpg: JPEG image data, EXIF standard 2.2
00004.avi: RIFF (little-endian) data, AVI, 320 x 240, 20.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 8000 Hz)
00005.jpg: JPEG image data, EXIF standard 2.2
00006.jpg: JPEG image data, EXIF standard 2.2
00007.jpg: JPEG image data, EXIF standard 2.2
00008.jpg: JPEG image data, EXIF standard 2.2
00009.jpg: JPEG image data, EXIF standard 2.2
00010.jpg: JPEG image data, EXIF standard 2.2
All the photos were JPEGs and the movie was playable. Totem/gstreamer
did a much better job of playing back the audio in the movie than
mplayer. Surprising to me, but 8 ksps mono is just awful anyway.
> Well, here are some of the things I learned:
>
> As a stillcam, it is confirmed that my cam is a standard mass storage
> device, transparent SCSI, bulk. It uses outep 0x01 and inep 0x82 (the
> first pair of endpoints).
>
> Here it is as a mass storage device.
>
>
> T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
> P: Vendor=0979 ProdID=0371 Rev= 1.00
> S: Manufacturer=Jeilin
> S: Product=USB 1.1 Device
> S: SerialNumber=09790
^^^^^
So much for a unique serial number. I haven't checked mine yet, but I
bet it's the same.
> C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 4 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
> E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=03(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms
> E: Ad=84(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms
>
> and here it is as a webcam.
>
>
> T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 16 Spd=12 MxCh= 0
> D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
> P: Vendor=0979 ProdID=0280 Rev= 1.00
> S: Manufacturer=Jeilin
> S: Product=USB 1.1 Device
> C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
> I:* If#= 0 Alt= 0 #EPs= 4 Cls=00(>ifc ) Sub=00 Prot=00 Driver=(none)
> E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
> E: Ad=03(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms
> E: Ad=84(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms
>
> Now it is using the other pair of endpoints, 0x03 and 0x84.
Hmmmm. I wonder if we can use them anyway, without being connected in
"webcam" mode.
> There is a sequence of init commands
>
> 00000000: 71 81
> 00000000: 70 05
> 00000000: 95 70
> 00000000: 00 (all the 00 are responses)
> 00000000: 71 81
> 00000000: 70 04
> 00000000: 95 70
> 00000000: 00
> 00000000: 71 00
> 00000000: 70 08
> 00000000: 95 70
> 00000000: 00
> 00000000: 94 02
> 00000000: de 24
> 00000000: 94 02
> 00000000: dd f0
> 00000000: 94 02
> 00000000: e3 2c
> 00000000: 94 02
> 00000000: e4 00
> 00000000: 94 02
> 00000000: e5 00
> 00000000: e5 00
> 00000000: 94 02
> 00000000: e6 2c
> 00000000: 94 03
> 00000000: aa 00
> 00000000: 71 1e
> 00000000: 70 06
> 00000000: 71 80
> 00000000: 70 07
>
> and then it starts to stream. The stream downloads 0x200 (512) bytes at a
> time. It appears that there is an SOF marker consisting of
>
> ff ff ff ff
>
> followed by at least two zeroes. These seem to occur only at the
> beginnings of some of the downloaded 0x200-sized blocks.
Given that the AVI file is 320x240 @ 20 fps Motion JPEG, maybe the
streaming mode uses something similar.
Assuming 6 bit RGB values at 320x240 @ 20 fps:
(320*240) * 24 bpp * 20 fps = 36.864 Mbps
Since this USB 1.1, I'm guessing the stream has to be compressed.
> There is a closing sequence at the end which is similar to the init
> sequence
>
> 00000000: 71 00
> 00000000: 70 09
> 00000000: 71 80
> 00000000: 70 05
>
> It would be interesting to see your log file and to compare. I could also
> send you this one if you are curious, but it is 5,760,902 bytes so I
> should ask that if you want to see it then how to send it? Me, I suspect
> that if you have one of similar size and bz2 it and send it to me as an
> attachment, then it is not any problem.
You could send it to me via email (my ISP bounces *really* big incoming
emails but at least 6 MB email can make it through). However, without
the "source" of the image, it might be a little hard to decode the dump.
I was going to get a stream of:
1) a white sheet of paper
2) a blue sheet of paper
3) a red sheet of paper
4) a green sheet of paper
5) a black sheet of paper
6) a half-white, half black target with the regions separated vertically
7) a half-white, half black target with the regions separated diagonally
and maybe some other test patterns. There's no shortage of construction
paper, crayons, and colored markers in my house.
> Now, having found an excuse not to finish grading those papers today, I
> will probably have to pay more concentrated attention to grading and
> travel planning tomorrow. But do send the log along anyway if you can get
> it done.
The most interesting tasks are the ones we're not required to do. :)
I probably can't send logs until Monday, but I will when I get the
chance.
Regards,
Andy
> Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-20 1:54 ` Andy Walls
@ 2009-06-20 4:38 ` Theodore Kilgore
2009-06-20 19:23 ` Andy Walls
0 siblings, 1 reply; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-20 4:38 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
On Fri, 19 Jun 2009, Andy Walls wrote:
> On Fri, 2009-06-19 at 19:26 -0500, Theodore Kilgore wrote:
>>
>> On Fri, 19 Jun 2009, Andy Walls wrote:
>>
>>> On Fri, 2009-06-19 at 12:47 -0500, Theodore Kilgore wrote:
>>>>
>>>> On Fri, 19 Jun 2009, Andy Walls wrote:
>>>>
>>>>> On Thu, 2009-06-18 at 21:43 -0500, Theodore Kilgore wrote:
>>>>>>
>>>>>> On Thu, 18 Jun 2009, Andy Walls wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Interesting. To answer your question, I have no idea off the top of my
>>>>>> head. I do have what seems to be a similar camera. It is
>>>>>>
>>>>>> Bus 005 Device 006: ID 0979:0371 Jeilin Technology Corp., Ltd
>>>>>>
>>>>>> and the rest of the lsusb output looks quite similar. I do not know,
>>>>>> though, if it has any chance of working as a webcam. Somehow, the thought
>>>>>> never occurred to me back when I got the thing. I would have to hunt some
>>>>>> stuff down even to know if it is claimed to work as a webcam.
>>>>>
>>>>> The packaging that mine came in claims "3-in-1":
>>>>>
>>>>> digital video camcorder (with microphone)
>>>>> digital camera
>>>>> web cam
>>>>>
>>>>>
>>>>>> You did say that it comes up as a different USB device when it is a
>>>>>> webcam? You mean, a different product ID or so?
>>>>>
>>>>> Yes
>>>>>
>>>>> Look for this in the original lsusb output I provided
>>>>> :
>>>>>>> Webcam mode:
>>>>>>>
>>>>>>> Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd
>>>>>>> Device Descriptor:
>>>>
>>>> Oops, right you are. Blame it on my old eyes. They are the same age as the
>>>> rest of me, but sometimes they feel older.
>>
>> And the upshot is that we may have the same camera, at least as a webcam,
>> perhaps with a different name. I finally made mine to work in webcam mode.
>> On mine, one has to press down a button labelled "DV" at the same time as
>> pressing down the button with the picture of a camera beside it, to turn
>> on the webcam mode. As opposed to just pressing the "camera" button to
>> turn on the camera to shoot a picture.
>
> Ah, very nice. The secret handshake that only the manual (usually lost)
> can tell you.
>
There is no longer any manual out there on the web. I looked.
>
>
>>> OK. I have two steps to take:
>>>
>>> 1. Installing the driver and software on my sole remaining Windows
>>> machine. It already has snoopy.
>>>
>>> 2. Getting the camera away from my daughter for more than 2 minutes.
>>> It's like the thing is glued to her hand. :)
>>
>> I hope that you can still manage to do these things. I did get a snoop log
>> of my own, but it would be nice to have some confirmation, too, that the
>> cameras really are acting the same way. That may look like a stupid thing
>> to say until one realizes that things which have the same USB
>> Vendor:Product number do _not_ necessarily act the same way.
>
> Yes. I might need a little time. This weekend is Father's day, and I
> got to go see family tomorrow and will be hosting more family on
> Saturday evening and Sunday. I doubt I'll have time to look at this
> before Sunday night (and by then I suspect I'll be drinking beer. :))
>
> I did let gThumb import some files from my daughter's camera (Ireally
> should have pulled them over myself from the "mass storage drive").
Easily done. No problem with that at all.
> Here's how they ended up:
>
> $ file *
> 00001.jpg: JPEG image data, EXIF standard 2.2
> 00002.jpg: JPEG image data, EXIF standard 2.2
> 00003.jpg: JPEG image data, EXIF standard 2.2
> 00004.avi: RIFF (little-endian) data, AVI, 320 x 240, 20.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 8000 Hz)
> 00005.jpg: JPEG image data, EXIF standard 2.2
> 00006.jpg: JPEG image data, EXIF standard 2.2
> 00007.jpg: JPEG image data, EXIF standard 2.2
> 00008.jpg: JPEG image data, EXIF standard 2.2
> 00009.jpg: JPEG image data, EXIF standard 2.2
> 00010.jpg: JPEG image data, EXIF standard 2.2
>
> All the photos were JPEGs and the movie was playable. Totem/gstreamer
> did a much better job of playing back the audio in the movie than
> mplayer. Surprising to me, but 8 ksps mono is just awful anyway.
>
Yes. The camera works perfectly in stilcam mode, as a mass storage device.
Just mount it and treat it like a thumb drive. I tried the sound today,
too, and the sound file is a .wav file. As far as my cam is concerned, I
already knew all of this, but the camera has been gathering dust since
2005. Oh, it is convenient to take on a trip. So that has happened a
couple of times. But otherwise it was not a very interesting camera. There
is no challenge in a mass storage camera so I more or less forgot about
it.
>
>
>> Well, here are some of the things I learned:
>>
>> As a stillcam, it is confirmed that my cam is a standard mass storage
>> device, transparent SCSI, bulk. It uses outep 0x01 and inep 0x82 (the
>> first pair of endpoints).
>>
As I said, I was aware of this but did not remember the details, so this
was all double-checking in order to clear up foggy memories.
>> Here it is as a mass storage device.
>>
>>
>> T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0
>> D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
>> P: Vendor=0979 ProdID=0371 Rev= 1.00
>> S: Manufacturer=Jeilin
>> S: Product=USB 1.1 Device
>> S: SerialNumber=09790
> ^^^^^
> So much for a unique serial number. I haven't checked mine yet, but I
> bet it's the same.
Well, lots of devices leave the serial number blank. And sometimes one
even encounters an (otherwise standard) mass storage device for which the
Vendor and Product numbers have been left blank, too! Lots of weird stuff
goes on. Be surprised at nothing.
>
>> C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
>> I:* If#= 0 Alt= 0 #EPs= 4 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
>> E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
>> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
>> E: Ad=03(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms
>> E: Ad=84(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms
>>
>> and here it is as a webcam.
>>
>>
>> T: Bus=05 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 16 Spd=12 MxCh= 0
>> D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
>> P: Vendor=0979 ProdID=0280 Rev= 1.00
>> S: Manufacturer=Jeilin
>> S: Product=USB 1.1 Device
>> C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
>> I:* If#= 0 Alt= 0 #EPs= 4 Cls=00(>ifc ) Sub=00 Prot=00 Driver=(none)
>> E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
>> E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
>> E: Ad=03(O) Atr=02(Bulk) MxPS= 8 Ivl=0ms
>> E: Ad=84(I) Atr=02(Bulk) MxPS= 8 Ivl=0ms
>>
>> Now it is using the other pair of endpoints, 0x03 and 0x84.
>
> Hmmmm. I wonder if we can use them anyway, without being connected in
> "webcam" mode.
Nope. That was the previously mentioned bug in the Linux mass storage
driver. Namely the spec calls for using the first pair of endpoints
encountered. The bug consisted of the mass storage driver looking for the
last pair of endpoints encountered, instead. This was back around kernel
2.6.18 or so when the problem got fixed.
The second pair of endpoints appears to be very much disconnected in mass
storage mode. The attempt to use them will result only in a string of
error messages. How well I remember. As to whether the first pair can be
used in webcam mode, I clearly have not tried to use them, but I would
have strong doubts whether it is even worth trying. Even if they would
work, what on earth would they be good for?
>
>
>
>> There is a sequence of init commands
>>
>> 00000000: 71 81
>> 00000000: 70 05
>> 00000000: 95 70
>> 00000000: 00 (all the 00 are responses)
>> 00000000: 71 81
>> 00000000: 70 04
>> 00000000: 95 70
>> 00000000: 00
>> 00000000: 71 00
>> 00000000: 70 08
>> 00000000: 95 70
>> 00000000: 00
>> 00000000: 94 02
>> 00000000: de 24
>> 00000000: 94 02
>> 00000000: dd f0
>> 00000000: 94 02
>> 00000000: e3 2c
>> 00000000: 94 02
>> 00000000: e4 00
>> 00000000: 94 02
>> 00000000: e5 00
>> 00000000: e5 00
>> 00000000: 94 02
>> 00000000: e6 2c
>> 00000000: 94 03
>> 00000000: aa 00
>> 00000000: 71 1e
>> 00000000: 70 06
>> 00000000: 71 80
>> 00000000: 70 07
>>
>> and then it starts to stream. The stream downloads 0x200 (512) bytes at a
>> time. It appears that there is an SOF marker consisting of
>>
>> ff ff ff ff
>>
>> followed by at least two zeroes. These seem to occur only at the
>> beginnings of some of the downloaded 0x200-sized blocks.
>
> Given that the AVI file is 320x240 @ 20 fps Motion JPEG, maybe the
> streaming mode uses something similar.
>
> Assuming 6 bit RGB values at 320x240 @ 20 fps:
>
> (320*240) * 24 bpp * 20 fps = 36.864 Mbps
>
> Since this USB 1.1, I'm guessing the stream has to be compressed.
Sure looks that way. I took a closer look at the lines starting with ff ff
ff ff strings, and I found a couple more things. Here are several lines
from an extract from that snoop, consisting of what appear to be
consecutive SOF lines.
00000000: ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00
00000000: ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00
00000000: ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00
00000000: ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00
00000000: ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00
The last non-zero byte is a frame counter. Presumably, the gap between the
01 and the 06 occurs because the camera was just then starting up and
things were a bit chaotic. The rest of the lines in the file are
completely consistent, counting consecutively from 09 to 49 (hex, of
course) at which point I killed the stream.
The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives
the number of 0x200-byte blocks in that frame, before the next marker
comes along. So if we start from the frame labeled "06" then from there on
the frames are approximately the same size, but not identical. For example
the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes.
I am not sure what the other numbers mean. Perhaps you have better guesses
than I do.
>
>
>
>> There is a closing sequence at the end which is similar to the init
>> sequence
>>
>> 00000000: 71 00
>> 00000000: 70 09
>> 00000000: 71 80
>> 00000000: 70 05
>>
>> It would be interesting to see your log file and to compare. I could also
>> send you this one if you are curious, but it is 5,760,902 bytes so I
>> should ask that if you want to see it then how to send it? Me, I suspect
>> that if you have one of similar size and bz2 it and send it to me as an
>> attachment, then it is not any problem.
>
> You could send it to me via email (my ISP bounces *really* big incoming
> emails but at least 6 MB email can make it through). However, without
> the "source" of the image, it might be a little hard to decode the dump.
>
I was not pointing the camera at anything in particular. Unless perhaps at
the laptop screen? Not sure.
> I was going to get a stream of:
>
> 1) a white sheet of paper
> 2) a blue sheet of paper
> 3) a red sheet of paper
> 4) a green sheet of paper
> 5) a black sheet of paper
>
> 6) a half-white, half black target with the regions separated vertically
> 7) a half-white, half black target with the regions separated diagonally
>
> and maybe some other test patterns. There's no shortage of construction
> paper, crayons, and colored markers in my house.
>
These are all good. Also I have found out it is sometimes helpful to point
a camera at a monitor screen, once I have learned to make raw files, and
to do things like xsetroot -solid c0/00/00 and then repeat for 00/c0/00
and again for 00/00/c0. and then take a picture of a "flag" by leaving a
white xterm sticking out into the picture in one corner.
>
>> Now, having found an excuse not to finish grading those papers today, I
>> will probably have to pay more concentrated attention to grading and
>> travel planning tomorrow. But do send the log along anyway if you can get
>> it done.
>
> The most interesting tasks are the ones we're not required to do. :)
Very true. Mark Twain said that work is what we have to do and anything
we don't have to do is play.
>
> I probably can't send logs until Monday, but I will when I get the
> chance.
OK.
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-20 4:38 ` Theodore Kilgore
@ 2009-06-20 19:23 ` Andy Walls
2009-06-20 22:48 ` Theodore Kilgore
2009-06-20 22:51 ` Andy Walls
0 siblings, 2 replies; 23+ messages in thread
From: Andy Walls @ 2009-06-20 19:23 UTC (permalink / raw)
To: Theodore Kilgore; +Cc: Linux Media Mailing List
On Fri, 2009-06-19 at 23:38 -0500, Theodore Kilgore wrote:
> >>
> >> Now it is using the other pair of endpoints, 0x03 and 0x84.
> >
> > Hmmmm. I wonder if we can use them anyway, without being connected in
> > "webcam" mode.
>
> Nope. That was the previously mentioned bug in the Linux mass storage
> driver. Namely the spec calls for using the first pair of endpoints
> encountered. The bug consisted of the mass storage driver looking for the
> last pair of endpoints encountered, instead. This was back around kernel
> 2.6.18 or so when the problem got fixed.
>
> The second pair of endpoints appears to be very much disconnected in mass
> storage mode. The attempt to use them will result only in a string of
> error messages. How well I remember. As to whether the first pair can be
> used in webcam mode, I clearly have not tried to use them, but I would
> have strong doubts whether it is even worth trying. Even if they would
> work, what on earth would they be good for?
Just not having to disconnect the cam to get at the files on it. It'll
probably be too much for the cheap device to deal with though.
It is interesting to note that the transfer logic of the the device
seems to be oriented around a 512 byte block size - the defacto disk
block size.
> >> There is a sequence of init commands
> >>
> >> 00000000: 71 81
> >> 00000000: 70 05
> >> 00000000: 95 70
> >> 00000000: 00 (all the 00 are responses)
> >> 00000000: 71 81
> >> 00000000: 70 04
> >> 00000000: 95 70
> >> 00000000: 00
> >> 00000000: 71 00
> >> 00000000: 70 08
> >> 00000000: 95 70
> >> 00000000: 00
> >> 00000000: 94 02
> >> 00000000: de 24
> >> 00000000: 94 02
> >> 00000000: dd f0
> >> 00000000: 94 02
> >> 00000000: e3 2c
> >> 00000000: 94 02
> >> 00000000: e4 00
> >> 00000000: 94 02
> >> 00000000: e5 00
> >> 00000000: e5 00
> >> 00000000: 94 02
> >> 00000000: e6 2c
> >> 00000000: 94 03
> >> 00000000: aa 00
> >> 00000000: 71 1e
> >> 00000000: 70 06
> >> 00000000: 71 80
> >> 00000000: 70 07
> >>
> >> and then it starts to stream. The stream downloads 0x200 (512) bytes at a
> >> time. It appears that there is an SOF marker consisting of
> >>
> >> ff ff ff ff
> >>
> >> followed by at least two zeroes. These seem to occur only at the
> >> beginnings of some of the downloaded 0x200-sized blocks.
> >
> > Given that the AVI file is 320x240 @ 20 fps Motion JPEG, maybe the
> > streaming mode uses something similar.
> >
> > Assuming 6 bit RGB values at 320x240 @ 20 fps:
> >
> > (320*240) * 24 bpp * 20 fps = 36.864 Mbps
> >
> > Since this USB 1.1, I'm guessing the stream has to be compressed.
>
> Sure looks that way. I took a closer look at the lines starting with ff ff
> ff ff strings, and I found a couple more things. Here are several lines
> from an extract from that snoop, consisting of what appear to be
> consecutive SOF lines.
>
> 00000000: ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00
> 00000000: ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00
> 00000000: ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00
> 00000000: ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00
> 00000000: ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00
>
> The last non-zero byte is a frame counter. Presumably, the gap between the
> 01 and the 06 occurs because the camera was just then starting up and
> things were a bit chaotic. The rest of the lines in the file are
> completely consistent, counting consecutively from 09 to 49 (hex, of
> course) at which point I killed the stream.
>
> The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives
> the number of 0x200-byte blocks in that frame, before the next marker
> comes along. So if we start from the frame labeled "06" then from there on
> the frames are approximately the same size, but not identical. For example
> the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes.
>
> I am not sure what the other numbers mean. Perhaps you have better guesses
> than I do.
The first few become easy given your observations. They are the actaul
payload size:
ceil(0x1c70/0x200) = ceil(0x0e.380) = 0x0f
ceil(0x3549/0x200) = ceil(0x1a.a48) = 0x1b
ceil(0x3689/0x200) = ceil(0x1b.448) = 0x1c
ceil(0x35fc/0x200) = ceil(0x1a.fe0) = 0x1b
ceil(0x3584/0x200) = ceil(0x1a.c20) = 0x1b
The lone 0x3c and the 0x1e's are not so easy:
0x3c = 60
0x1e = 30
Maybe an inidcation of frame rate?
I'll try and think about them a little more.
> >>
> >> 00000000: 71 00
> >> 00000000: 70 09
> >> 00000000: 71 80
> >> 00000000: 70 05
> >>
> >> It would be interesting to see your log file and to compare. I could also
> >> send you this one if you are curious, but it is 5,760,902 bytes so I
> >> should ask that if you want to see it then how to send it? Me, I suspect
> >> that if you have one of similar size and bz2 it and send it to me as an
> >> attachment, then it is not any problem.
> >
> > You could send it to me via email (my ISP bounces *really* big incoming
> > emails but at least 6 MB email can make it through). However, without
> > the "source" of the image, it might be a little hard to decode the dump.
> >
>
> I was not pointing the camera at anything in particular. Unless perhaps at
> the laptop screen? Not sure.
>
> > I was going to get a stream of:
> >
> > 1) a white sheet of paper
> > 2) a blue sheet of paper
> > 3) a red sheet of paper
> > 4) a green sheet of paper
> > 5) a black sheet of paper
> >
> > 6) a half-white, half black target with the regions separated vertically
> > 7) a half-white, half black target with the regions separated diagonally
> >
> > and maybe some other test patterns. There's no shortage of construction
> > paper, crayons, and colored markers in my house.
> >
>
> These are all good. Also I have found out it is sometimes helpful to point
> a camera at a monitor screen, once I have learned to make raw files, and
> to do things like xsetroot -solid c0/00/00 and then repeat for 00/c0/00
> and again for 00/00/c0. and then take a picture of a "flag" by leaving a
> white xterm sticking out into the picture in one corner.
Ah. That is convenient.
I'm booting over to Windows now, to grab some dumps.
Regards,
Andy
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-20 19:23 ` Andy Walls
@ 2009-06-20 22:48 ` Theodore Kilgore
2009-06-20 22:51 ` Andy Walls
1 sibling, 0 replies; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-20 22:48 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
On Sat, 20 Jun 2009, Andy Walls wrote:
> On Fri, 2009-06-19 at 23:38 -0500, Theodore Kilgore wrote:
>
>>>>
>>>> Now it is using the other pair of endpoints, 0x03 and 0x84.
>>>
>>> Hmmmm. I wonder if we can use them anyway, without being connected in
>>> "webcam" mode.
>>
>> Nope. That was the previously mentioned bug in the Linux mass storage
>> driver. Namely the spec calls for using the first pair of endpoints
>> encountered. The bug consisted of the mass storage driver looking for the
>> last pair of endpoints encountered, instead. This was back around kernel
>> 2.6.18 or so when the problem got fixed.
>>
>> The second pair of endpoints appears to be very much disconnected in mass
>> storage mode. The attempt to use them will result only in a string of
>> error messages. How well I remember. As to whether the first pair can be
>> used in webcam mode, I clearly have not tried to use them, but I would
>> have strong doubts whether it is even worth trying. Even if they would
>> work, what on earth would they be good for?
>
> Just not having to disconnect the cam to get at the files on it. It'll
> probably be too much for the cheap device to deal with though.
>
Well, I do not see any way around that. If you want to use it as a webcam,
it needs a webcam support module. If you want to use it as a still cam,
then it needs the mass storage module. Even if it were possible for the
hardware to come up set in the webcam mode and use those two endpoints for
something or other, then just how would it be possible to do the mass
storage stuff? Actually, the producers of the camera were being very good
citizens about that. They have the camera come up with two different
Product numbers and two different Class-subclass-protocol IDs, depending
on the way the camera has been set. One cannot ask for more. And the
devices which do not act thus are a real pain in the neck.
This brings up another topic, not immediately relevant to the question of
supporting your/my camera, but extremely relevant for this list:
Think about a camera which needs, say, libgphoto2 for stillcam support but
needs a module in order to emit a stream. Then there is the issue of a
userspace program to access the camera through libusb, and a kernel module
to access it for streaming. Until something recently was done for a
partial solution of this problem, then this implied the kernel module must
be blacklisted, else the camera could never be used as a still camera.
The current solution to this userspace-kernelspace conundrum is only a
halfway solution. Nowadays, libusb disables the kernel module if called,
and if you want to use the camera as a webcam after that, you must replug.
This causes problems, too, because of some distros which have the
too-bright idea of associating the camera, through libusb, to HAL and
fixing it so that a program pops up immediately for the purpose of
downloading the pictures on it. Those distros want to make things "easy"
for their users. But then, what happens? Well, as soon as the camera is
plugged in, its module gets loaded automatically, so that it can stream.
Then immediately the module has been disabled, because the camera is
automatically accessed from userspace. If the user wants to stream instead
of downloading pictures from it, then the user is screwed. To replug the
camera is no solution, because then the cycle merely gets repeated.
Therefore, I submit that this problem is still not solved. The great
difficulty is, of course, that the problem raises some very difficult
issues, which strike at the heart of the Linux security model. A better
solution needs to be sought.
Returning to the issue on the table, I would say simply to be glad that
the camera comes up as two different devices, depending on its switch
settings, and does not use the same pair of endpoints for its two
different functionalities, either.
>
> It is interesting to note that the transfer logic of the the device
> seems to be oriented around a 512 byte block size - the defacto disk
> block size.
>
Yes, but in view of the mass-storage nature of the camera's alter ego,
that seems to me natural. Also, all the other Jeilin cameras I know of,
both supported and unsupported, count the allocation for the photos in
blocks. Some of them use a smaller blocksize, but many of their purely
proprietary cameras do also use this "standard" blocksize. In other words,
this approach seems to me to be somewhat standard for Jeilin.
<snip>
>> Sure looks that way. I took a closer look at the lines starting with ff ff
>> ff ff strings, and I found a couple more things. Here are several lines
>> from an extract from that snoop, consisting of what appear to be
>> consecutive SOF lines.
>>
>> 00000000: ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00
>> 00000000: ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00
>> 00000000: ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00
>> 00000000: ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00
>> 00000000: ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00
>>
>> The last non-zero byte is a frame counter. Presumably, the gap between the
>> 01 and the 06 occurs because the camera was just then starting up and
>> things were a bit chaotic. The rest of the lines in the file are
>> completely consistent, counting consecutively from 09 to 49 (hex, of
>> course) at which point I killed the stream.
>>
>> The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives
>> the number of 0x200-byte blocks in that frame, before the next marker
>> comes along. So if we start from the frame labeled "06" then from there on
>> the frames are approximately the same size, but not identical. For example
>> the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes.
>>
>> I am not sure what the other numbers mean. Perhaps you have better guesses
>> than I do.
>
> The first few become easy given your observations. They are the actaul
> payload size:
>
> ceil(0x1c70/0x200) = ceil(0x0e.380) = 0x0f
> ceil(0x3549/0x200) = ceil(0x1a.a48) = 0x1b
> ceil(0x3689/0x200) = ceil(0x1b.448) = 0x1c
> ceil(0x35fc/0x200) = ceil(0x1a.fe0) = 0x1b
> ceil(0x3584/0x200) = ceil(0x1a.c20) = 0x1b
>
Yes, it looks as though you are right. And furthermore I have seen this
kind of thing before, too, with other cams. Some of them do not provide
this information but oblige you to calculate it, instead, but some
others actually do provide the information. So, that settles that.
BTW, where do you have something that does floating point arithmetic in
hex? That is interesting, but seems rather heavy, too. Everything I have
over here does only integer arithmetic, not that it is insufficient for
answering similar questions. Actually, for most of this kind of thing I
use an integer-arithmetic onscreen calculator which is a modernized and
debugged version of DJ Delorie's hcalc. It is a nice little lightweight
program which is only good for what it is good for. It will do integer
arithmetic, base conversions, and the bitwise logic operations and the
shift operations (and nothing else). You can get a copy of it at
<www.auburn.edu/~kilgota> if you are curious. (end of shameless plug)
> The lone 0x3c and the 0x1e's are not so easy:
>
> 0x3c = 60
> 0x1e = 30
>
> Maybe an inidcation of frame rate?
>
That looks like as good an explanation as any other that will come up.
Camera starts to stream at a (default?) 60 fps and some frames are
dropped, so camera goes down to 30 fps, which seems to work.
> I'll try and think about them a little more.
It looks to me as if you have nailed it.
<snip>
(got your other mail, that you successfully received my log file)
>>> However, without
>>> the "source" of the image, it might be a little hard to decode the dump.
Unless it is already in JPEG format (and it is only needed to supply the
missing header) you are probably right about that. What I fear at this
point is that the camera is using the same proprietary compression
algorithm in this mode as the JL2005B and C and D cameras. I learned long
ago how to get the data out of those, and such would obviously also not be
difficult here, either. The problem is what do do with that data
afterwards. I have made no tangible progress on that one for a couple of
years. So I hope that either this one is not so difficult or we will have
better luck working together.
>
> I'm booting over to Windows now, to grab some dumps.
OK.
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-20 19:23 ` Andy Walls
2009-06-20 22:48 ` Theodore Kilgore
@ 2009-06-20 22:51 ` Andy Walls
2009-06-21 1:04 ` Theodore Kilgore
1 sibling, 1 reply; 23+ messages in thread
From: Andy Walls @ 2009-06-20 22:51 UTC (permalink / raw)
To: Theodore Kilgore; +Cc: Linux Media Mailing List
On Sat, 2009-06-20 at 15:23 -0400, Andy Walls wrote:
> On Fri, 2009-06-19 at 23:38 -0500, Theodore Kilgore wrote:
>
> > >>
> > >> Now it is using the other pair of endpoints, 0x03 and 0x84.
> > >
> > > Hmmmm. I wonder if we can use them anyway, without being connected in
> > > "webcam" mode.
> >
> > Nope. That was the previously mentioned bug in the Linux mass storage
> > driver. Namely the spec calls for using the first pair of endpoints
> > encountered. The bug consisted of the mass storage driver looking for the
> > last pair of endpoints encountered, instead. This was back around kernel
> > 2.6.18 or so when the problem got fixed.
> >
> > The second pair of endpoints appears to be very much disconnected in mass
> > storage mode. The attempt to use them will result only in a string of
> > error messages. How well I remember. As to whether the first pair can be
> > used in webcam mode, I clearly have not tried to use them, but I would
> > have strong doubts whether it is even worth trying. Even if they would
> > work, what on earth would they be good for?
>
> Just not having to disconnect the cam to get at the files on it. It'll
> probably be too much for the cheap device to deal with though.
>
>
> It is interesting to note that the transfer logic of the the device
> seems to be oriented around a 512 byte block size - the defacto disk
> block size.
>
>
> > >> There is a sequence of init commands
> > >>
> > >> 00000000: 71 81
> > >> 00000000: 70 05
> > >> 00000000: 95 70
> > >> 00000000: 00 (all the 00 are responses)
> > >> 00000000: 71 81
> > >> 00000000: 70 04
> > >> 00000000: 95 70
> > >> 00000000: 00
> > >> 00000000: 71 00
> > >> 00000000: 70 08
> > >> 00000000: 95 70
> > >> 00000000: 00
> > >> 00000000: 94 02
> > >> 00000000: de 24
> > >> 00000000: 94 02
> > >> 00000000: dd f0
> > >> 00000000: 94 02
> > >> 00000000: e3 2c
> > >> 00000000: 94 02
> > >> 00000000: e4 00
> > >> 00000000: 94 02
> > >> 00000000: e5 00
> > >> 00000000: e5 00
> > >> 00000000: 94 02
> > >> 00000000: e6 2c
> > >> 00000000: 94 03
> > >> 00000000: aa 00
> > >> 00000000: 71 1e
> > >> 00000000: 70 06
> > >> 00000000: 71 80
> > >> 00000000: 70 07
> > >>
> > >> and then it starts to stream. The stream downloads 0x200 (512) bytes at a
> > >> time. It appears that there is an SOF marker consisting of
> > >>
> > >> ff ff ff ff
> > >>
> > >> followed by at least two zeroes. These seem to occur only at the
> > >> beginnings of some of the downloaded 0x200-sized blocks.
> > >
> > > Given that the AVI file is 320x240 @ 20 fps Motion JPEG, maybe the
> > > streaming mode uses something similar.
> > >
> > > Assuming 6 bit RGB values at 320x240 @ 20 fps:
> > >
> > > (320*240) * 24 bpp * 20 fps = 36.864 Mbps
> > >
> > > Since this USB 1.1, I'm guessing the stream has to be compressed.
> >
> > Sure looks that way. I took a closer look at the lines starting with ff ff
> > ff ff strings, and I found a couple more things. Here are several lines
> > from an extract from that snoop, consisting of what appear to be
> > consecutive SOF lines.
> >
> > 00000000: ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00
> > 00000000: ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00
> > 00000000: ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00
> > 00000000: ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00
> > 00000000: ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00
> >
> > The last non-zero byte is a frame counter. Presumably, the gap between the
> > 01 and the 06 occurs because the camera was just then starting up and
> > things were a bit chaotic. The rest of the lines in the file are
> > completely consistent, counting consecutively from 09 to 49 (hex, of
> > course) at which point I killed the stream.
> >
> > The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives
> > the number of 0x200-byte blocks in that frame, before the next marker
> > comes along. So if we start from the frame labeled "06" then from there on
> > the frames are approximately the same size, but not identical. For example
> > the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes.
> >
> > I am not sure what the other numbers mean. Perhaps you have better guesses
> > than I do.
>
> The first few become easy given your observations. They are the actaul
> payload size:
>
> ceil(0x1c70/0x200) = ceil(0x0e.380) = 0x0f
> ceil(0x3549/0x200) = ceil(0x1a.a48) = 0x1b
> ceil(0x3689/0x200) = ceil(0x1b.448) = 0x1c
> ceil(0x35fc/0x200) = ceil(0x1a.fe0) = 0x1b
> ceil(0x3584/0x200) = ceil(0x1a.c20) = 0x1b
>
> The lone 0x3c and the 0x1e's are not so easy:
>
> 0x3c = 60
> 0x1e = 30
>
> Maybe an inidcation of frame rate?
>
> I'll try and think about them a little more.
For your camera, these numbers appear to indicate a frequency and can be
decoded into a time period like this:
1000/0x1e00 = 130 ms
1000/0x3c00 = 65 ms
I'm assuming it's some sort of presentation frame rate.
> > >>
> > >> 00000000: 71 00
> > >> 00000000: 70 09
> > >> 00000000: 71 80
> > >> 00000000: 70 05
> > >>
> > >> It would be interesting to see your log file and to compare. I could also
> > >> send you this one if you are curious, but it is 5,760,902 bytes so I
> > >> should ask that if you want to see it then how to send it? Me, I suspect
> > >> that if you have one of similar size and bz2 it and send it to me as an
> > >> attachment, then it is not any problem.
> > >
> > > You could send it to me via email (my ISP bounces *really* big incoming
> > > emails but at least 6 MB email can make it through). However, without
> > > the "source" of the image, it might be a little hard to decode the dump.
> > >
Here's the init for my camera:
0000: 71 81
0000: 70 05
0000: 95 70
0000: 00
0000: 71 81
0000: 70 04
0000: 95 70
0000: 00
0000: 71 00
0000: 70 08
0000: 95 70
0000: 00
0000: 94 02
0000: de 24
0000: 94 02
0000: dd f0
0000: 94 02
0000: e3 22 <--- different
0000: 94 02
0000: e4 00
0000: 94 02
0000: e5 00 <--- not repeated like in the sequence above
0000: 94 02
0000: e6 22 <--- different
0000: 94 03
0000: aa 01 <--- different
0000: 71 1e
0000: 70 06
0000: 71 80
0000: 70 07
And here's the terminal sequence:
0000: 71 00
0000: 70 09
0000: 71 80
0000: 70 05
They look amazingly similar to yours.
Here are the buffers with the supposed SOF marker:
0000: ff ff ff ff 00 00 18 43 1e 00 0d fa 00 00 00 00
0000: ff ff ff ff 00 00 18 26 1e 00 0d 00 00 00 00 00
0000: ff ff ff ff 00 00 17 fa 1e 00 0c 01 00 00 00 00
0000: ff ff ff ff 00 00 18 4e 1e 00 0d 02 00 00 00 00
0000: ff ff ff ff 00 00 18 91 1e 00 0d 03 00 00 00 00
0000: ff ff ff ff 00 00 18 90 1e 00 0d 04 00 00 00 00
0000: ff ff ff ff 00 00 18 4b 1e 00 0d 05 00 00 00 00
0000: ff ff ff ff 00 00 18 8a 1e 00 0d 06 00 00 00 00
Again very similar. I had the camera pointed at a mostly white test
target with some large blue numbers printed on it, so the sammler
buffers probably just indicate how simple the test target was.
The frames from my camera were coming at 100 ms intervals instead of 130
ms intervals. So maybe some scaling constant has changed with my
supposed frame presentation frequency field that contains 0x1e00.
I will send you a text capture of the data from SnoopyPro in a private
email.
Regards,
Andy
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-20 22:51 ` Andy Walls
@ 2009-06-21 1:04 ` Theodore Kilgore
2009-06-21 4:19 ` Andy Walls
0 siblings, 1 reply; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-21 1:04 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
On Sat, 20 Jun 2009, Andy Walls wrote:
> On Sat, 2009-06-20 at 15:23 -0400, Andy Walls wrote:
>> On Fri, 2009-06-19 at 23:38 -0500, Theodore Kilgore wrote:
>>
>>>>>
>>>>> Now it is using the other pair of endpoints, 0x03 and 0x84.
>>>>
>>>> Hmmmm. I wonder if we can use them anyway, without being connected in
>>>> "webcam" mode.
>>>
>>> Nope. That was the previously mentioned bug in the Linux mass storage
>>> driver. Namely the spec calls for using the first pair of endpoints
>>> encountered. The bug consisted of the mass storage driver looking for the
>>> last pair of endpoints encountered, instead. This was back around kernel
>>> 2.6.18 or so when the problem got fixed.
>>>
>>> The second pair of endpoints appears to be very much disconnected in mass
>>> storage mode. The attempt to use them will result only in a string of
>>> error messages. How well I remember. As to whether the first pair can be
>>> used in webcam mode, I clearly have not tried to use them, but I would
>>> have strong doubts whether it is even worth trying. Even if they would
>>> work, what on earth would they be good for?
>>
>> Just not having to disconnect the cam to get at the files on it. It'll
>> probably be too much for the cheap device to deal with though.
>>
>>
>> It is interesting to note that the transfer logic of the the device
>> seems to be oriented around a 512 byte block size - the defacto disk
>> block size.
>>
>>
>>>>> There is a sequence of init commands
>>>>>
>>>>> 00000000: 71 81
>>>>> 00000000: 70 05
>>>>> 00000000: 95 70
>>>>> 00000000: 00 (all the 00 are responses)
>>>>> 00000000: 71 81
>>>>> 00000000: 70 04
>>>>> 00000000: 95 70
>>>>> 00000000: 00
>>>>> 00000000: 71 00
>>>>> 00000000: 70 08
>>>>> 00000000: 95 70
>>>>> 00000000: 00
>>>>> 00000000: 94 02
>>>>> 00000000: de 24
>>>>> 00000000: 94 02
>>>>> 00000000: dd f0
>>>>> 00000000: 94 02
>>>>> 00000000: e3 2c
>>>>> 00000000: 94 02
>>>>> 00000000: e4 00
>>>>> 00000000: 94 02
>>>>> 00000000: e5 00
>>>>> 00000000: e5 00
>>>>> 00000000: 94 02
>>>>> 00000000: e6 2c
>>>>> 00000000: 94 03
>>>>> 00000000: aa 00
>>>>> 00000000: 71 1e
>>>>> 00000000: 70 06
>>>>> 00000000: 71 80
>>>>> 00000000: 70 07
>>>>>
>>>>> and then it starts to stream. The stream downloads 0x200 (512) bytes at a
>>>>> time. It appears that there is an SOF marker consisting of
>>>>>
>>>>> ff ff ff ff
>>>>>
>>>>> followed by at least two zeroes. These seem to occur only at the
>>>>> beginnings of some of the downloaded 0x200-sized blocks.
>>>>
>>>> Given that the AVI file is 320x240 @ 20 fps Motion JPEG, maybe the
>>>> streaming mode uses something similar.
>>>>
>>>> Assuming 6 bit RGB values at 320x240 @ 20 fps:
>>>>
>>>> (320*240) * 24 bpp * 20 fps = 36.864 Mbps
>>>>
>>>> Since this USB 1.1, I'm guessing the stream has to be compressed.
>>>
>>> Sure looks that way. I took a closer look at the lines starting with ff ff
>>> ff ff strings, and I found a couple more things. Here are several lines
>>> from an extract from that snoop, consisting of what appear to be
>>> consecutive SOF lines.
>>>
>>> 00000000: ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00
>>> 00000000: ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00
>>> 00000000: ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00
>>> 00000000: ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00
>>> 00000000: ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00
>>>
>>> The last non-zero byte is a frame counter. Presumably, the gap between the
>>> 01 and the 06 occurs because the camera was just then starting up and
>>> things were a bit chaotic. The rest of the lines in the file are
>>> completely consistent, counting consecutively from 09 to 49 (hex, of
>>> course) at which point I killed the stream.
>>>
>>> The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives
>>> the number of 0x200-byte blocks in that frame, before the next marker
>>> comes along. So if we start from the frame labeled "06" then from there on
>>> the frames are approximately the same size, but not identical. For example
>>> the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes.
>>>
>>> I am not sure what the other numbers mean. Perhaps you have better guesses
>>> than I do.
>>
>> The first few become easy given your observations. They are the actaul
>> payload size:
>>
>> ceil(0x1c70/0x200) = ceil(0x0e.380) = 0x0f
>> ceil(0x3549/0x200) = ceil(0x1a.a48) = 0x1b
>> ceil(0x3689/0x200) = ceil(0x1b.448) = 0x1c
>> ceil(0x35fc/0x200) = ceil(0x1a.fe0) = 0x1b
>> ceil(0x3584/0x200) = ceil(0x1a.c20) = 0x1b
>>
>> The lone 0x3c and the 0x1e's are not so easy:
>>
>> 0x3c = 60
>> 0x1e = 30
>>
>> Maybe an inidcation of frame rate?
>>
>> I'll try and think about them a little more.
>
> For your camera, these numbers appear to indicate a frequency and can be
> decoded into a time period like this:
>
> 1000/0x1e00 = 130 ms
> 1000/0x3c00 = 65 ms
>
> I'm assuming it's some sort of presentation frame rate.
>
>
>
>>>>>
>>>>> 00000000: 71 00
>>>>> 00000000: 70 09
>>>>> 00000000: 71 80
>>>>> 00000000: 70 05
>>>>>
>>>>> It would be interesting to see your log file and to compare. I could also
>>>>> send you this one if you are curious, but it is 5,760,902 bytes so I
>>>>> should ask that if you want to see it then how to send it? Me, I suspect
>>>>> that if you have one of similar size and bz2 it and send it to me as an
>>>>> attachment, then it is not any problem.
>>>>
>>>> You could send it to me via email (my ISP bounces *really* big incoming
>>>> emails but at least 6 MB email can make it through). However, without
>>>> the "source" of the image, it might be a little hard to decode the dump.
>>>>
>
> Here's the init for my camera:
>
> 0000: 71 81
> 0000: 70 05
> 0000: 95 70
> 0000: 00
> 0000: 71 81
> 0000: 70 04
> 0000: 95 70
> 0000: 00
> 0000: 71 00
> 0000: 70 08
> 0000: 95 70
> 0000: 00
> 0000: 94 02
> 0000: de 24
> 0000: 94 02
> 0000: dd f0
> 0000: 94 02
> 0000: e3 22 <--- different
> 0000: 94 02
> 0000: e4 00
> 0000: 94 02
> 0000: e5 00 <--- not repeated like in the sequence above
> 0000: 94 02
> 0000: e6 22 <--- different
> 0000: 94 03
> 0000: aa 01 <--- different
> 0000: 71 1e
> 0000: 70 06
> 0000: 71 80
> 0000: 70 07
>
> And here's the terminal sequence:
>
> 0000: 71 00
> 0000: 70 09
> 0000: 71 80
> 0000: 70 05
>
> They look amazingly similar to yours.
>
> Here are the buffers with the supposed SOF marker:
>
> 0000: ff ff ff ff 00 00 18 43 1e 00 0d fa 00 00 00 00
> 0000: ff ff ff ff 00 00 18 26 1e 00 0d 00 00 00 00 00
> 0000: ff ff ff ff 00 00 17 fa 1e 00 0c 01 00 00 00 00
> 0000: ff ff ff ff 00 00 18 4e 1e 00 0d 02 00 00 00 00
> 0000: ff ff ff ff 00 00 18 91 1e 00 0d 03 00 00 00 00
> 0000: ff ff ff ff 00 00 18 90 1e 00 0d 04 00 00 00 00
> 0000: ff ff ff ff 00 00 18 4b 1e 00 0d 05 00 00 00 00
> 0000: ff ff ff ff 00 00 18 8a 1e 00 0d 06 00 00 00 00
>
> Again very similar. I had the camera pointed at a mostly white test
> target with some large blue numbers printed on it, so the sammler
> buffers probably just indicate how simple the test target was.
>
> The frames from my camera were coming at 100 ms intervals instead of 130
> ms intervals. So maybe some scaling constant has changed with my
> supposed frame presentation frequency field that contains 0x1e00.
>
> I will send you a text capture of the data from SnoopyPro in a private
> email.
>
> Regards,
> Andy
>
>
This looks quite similar. The differences in the init sequence may be
significant, but more likely I would speculate that they are
insubstantial. Probably the little differences are due to who actually
wrote the camera driver. Those guys over there also put their pants on one
leg at a time just like the rest of us, after all. I think they do things
like hiring students to write their drivers. If so, they might possibly
get the same kind of results that could be expected over here from similar
arrangements.
As to
> 0000: e5 00 <--- not repeated like in the sequence above
that was a transcription error on my part, committed by using the mouse to
copy something in two pieces that was too long to copy at once. Check the
log I sent along. But I think it is not really there.
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-21 1:04 ` Theodore Kilgore
@ 2009-06-21 4:19 ` Andy Walls
2009-06-21 15:42 ` Theodore Kilgore
2009-06-21 17:12 ` Theodore Kilgore
0 siblings, 2 replies; 23+ messages in thread
From: Andy Walls @ 2009-06-21 4:19 UTC (permalink / raw)
To: Theodore Kilgore; +Cc: Linux Media Mailing List
On Sat, 2009-06-20 at 20:04 -0500, Theodore Kilgore wrote:
>
> >>> Sure looks that way. I took a closer look at the lines starting with ff ff
> >>> ff ff strings, and I found a couple more things. Here are several lines
> >>> from an extract from that snoop, consisting of what appear to be
> >>> consecutive SOF lines.
> >>>
> >>> 00000000: ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00
> >>> 00000000: ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00
> >>> 00000000: ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00
> >>> 00000000: ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00
> >>> 00000000: ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00
> >>>
> >>> The last non-zero byte is a frame counter. Presumably, the gap between the
> >>> 01 and the 06 occurs because the camera was just then starting up and
> >>> things were a bit chaotic. The rest of the lines in the file are
> >>> completely consistent, counting consecutively from 09 to 49 (hex, of
> >>> course) at which point I killed the stream.
> >>>
> >>> The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives
> >>> the number of 0x200-byte blocks in that frame, before the next marker
> >>> comes along. So if we start from the frame labeled "06" then from there on
> >>> the frames are approximately the same size, but not identical. For example
> >>> the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes.
> >
> > Here's the init for my camera:
> >
> > 0000: 71 81
> > 0000: 70 05
> > 0000: 95 70
> > 0000: 00
> > 0000: 71 81
> > 0000: 70 04
> > 0000: 95 70
> > 0000: 00
> > 0000: 71 00
> > 0000: 70 08
> > 0000: 95 70
> > 0000: 00
> > 0000: 94 02
> > 0000: de 24
> > 0000: 94 02
> > 0000: dd f0
> > 0000: 94 02
> > 0000: e3 22 <--- different
> > 0000: 94 02
> > 0000: e4 00
> > 0000: 94 02
> > 0000: e5 00 <--- not repeated like in the sequence above
> > 0000: 94 02
> > 0000: e6 22 <--- different
> > 0000: 94 03
> > 0000: aa 01 <--- different
> > 0000: 71 1e
> > 0000: 70 06
> > 0000: 71 80
> > 0000: 70 07
> >
> > And here's the terminal sequence:
> >
> > 0000: 71 00
> > 0000: 70 09
> > 0000: 71 80
> > 0000: 70 05
> >
> > They look amazingly similar to yours.
> >
> > Here are the buffers with the supposed SOF marker:
> >
> > 0000: ff ff ff ff 00 00 18 43 1e 00 0d fa 00 00 00 00
> > 0000: ff ff ff ff 00 00 18 26 1e 00 0d 00 00 00 00 00
> > 0000: ff ff ff ff 00 00 17 fa 1e 00 0c 01 00 00 00 00
> > 0000: ff ff ff ff 00 00 18 4e 1e 00 0d 02 00 00 00 00
> > 0000: ff ff ff ff 00 00 18 91 1e 00 0d 03 00 00 00 00
> > 0000: ff ff ff ff 00 00 18 90 1e 00 0d 04 00 00 00 00
> > 0000: ff ff ff ff 00 00 18 4b 1e 00 0d 05 00 00 00 00
> > 0000: ff ff ff ff 00 00 18 8a 1e 00 0d 06 00 00 00 00
> >
> > Again very similar. I had the camera pointed at a mostly white test
> > target with some large blue numbers printed on it, so the sammler
> > buffers probably just indicate how simple the test target was.
> >
> > The frames from my camera were coming at 100 ms intervals instead of 130
> > ms intervals. So maybe some scaling constant has changed with my
> > supposed frame presentation frequency field that contains 0x1e00.
>
> This looks quite similar. The differences in the init sequence may be
> significant, but more likely I would speculate that they are
> insubstantial. Probably the little differences are due to who actually
> wrote the camera driver. Those guys over there also put their pants on one
> leg at a time just like the rest of us, after all. I think they do things
> like hiring students to write their drivers. If so, they might possibly
> get the same kind of results that could be expected over here from similar
> arrangements.
Agree.
The more I dig into this, the more I think (hope or wish?) the stuff in
the usb snoop logs looks MJPEG.
I started looking at an AVI file that I recorded with the camera. It
looks like a DV AVI Type-2 file.
In the AVI file header, my camera reports:
00000d0: 0000 0000 7374 7264 ac00 0000 4a65 696c ....strd....Jeil
00000e0: 696e 2020 5465 6368 6e6f 6c6f 6779 2043 in Technology C
00000f0: 6f2e 2c20 4c74 642e 4a4c 3230 3038 5632 o., Ltd.JL2008V2
0000100: 4330 3037 3030 3130 2020 2020 2020 2020 C0070010
So looking up the JL2008A datasheet, my camera's capabilities match the
data sheet very well.
http://jeilin.com.tw/eng/product_detail.php?p_id=5
http://jeilin.com.tw/mana_php/Download/File/JL2008A%20v1.3.pdf
The only video compression that is mentioned on the webpage and in the
datasheet is JPEG.
Trying to learn about DV AVI Type 2 files I've found roughly how
individual chunk headers look. They each have a stream fourcc that
starts 'nnxx' in ASCII, where nn is the stream number and xx is
db - uncompressed video frame
dc - compressed video frame
wb - audio data
$ xxd 00004.avi | grep -E ' 303[0-2] ((646)|(776))'
00001f0: 14fe 0c00 6d6f 7669 3031 7762 401f 0000 ....movi01wb@... <-- audio
0002140: 3032 6462 0041 0000 ffe2 55aa 0500 0000 02db.A....U..... <-- video
0006250: 3032 6462 0041 0000 ffe2 55aa 0500 0001 02db.A....U..... <-- video
000a360: 3032 6462 0041 0000 ffe2 55aa 0500 0002 02db.A....U..... <-- video
000e470: 3032 6462 0041 0000 ffe2 55aa 0500 0003 02db.A....U..... <-- video
0012580: 3032 6462 0041 0000 ffe2 55aa 0500 0004 02db.A....U..... <-- video
0016690: 3030 6463 281c 0000 ffd8 ffe0 0016 4156 00dc(.........AV <-- compressed video
00182c0: 3030 6463 e81b 0000 ffd8 ffe0 0016 4156 00dc..........AV <-- compressed video
0019eb0: 3030 6463 c81b 0000 ffd8 ffe0 0016 4156 00dc..........AV <-- compressed video
>From the AVI header and from the compressed video chunk headers, the
compressed video stream is MJPEG.
I don't know what the uncompressed video (02db) chunks are. The AVI
header doesn't mention a third stream (stream 02). The length of each
chunk of this third stream is 0x4100 = 0x20 * 0x200 and each one has an
incrementing sequence number in the header.
Doing some math:
320 * 240 = 76800 = 0x12c00
0x12c00 / 0x4100 = 0x4.9d = 4.61
so 5 chunks of 0x4100 bytes would be needed for one uncompressed 320x240
frame at 8 bits/pixel. Those uncompressed video chunks always come in
groups of 5 in the AVI file.
The idx section at the end of the AVI file only indexes the compressed
video (00dc) and audio (01wb) chunks:
00d0000: 0000 0000 0000 0000 6964 7831 4005 0000 ........idx1@...
00d0010: 3031 7762 0000 0000 0400 0000 401f 0000 01wb........@...
00d0020: 3030 6463 1000 0000 9c64 0100 281c 0000 00dc.....d..(...
00d0030: 3030 6463 1000 0000 cc80 0100 e81b 0000 00dc............
00d0040: 3030 6463 1000 0000 bc9c 0100 c81b 0000 00dc............
00d0050: 3030 6463 1000 0000 8cb8 0100 f81b 0000 00dc............
00d0060: 3030 6463 1000 0000 8cd4 0100 581c 0000 00dc........X...
My tired eyes are telling me the AVI file's MJPEG compressed video
stream (00dc) looks like what comes out of the camera in webcam mode
than the AVI file's uncompressed video stream.
The first 0x110 bytes of the MJPEG stream (00dc) chunks in the AVI file
remain invariant, except for 3, 32 bit values related to length: The AVI
stream 00dc chunk length and the MJPEG AVI1 App's field size and padded
field size (I think).
0099560: 30 30 64 63 78 0e 00 00 ff d8 ff e0 00 16 41 56 00dcx.........AV
^^^^^^^^^^^--- Chunk/padded length
0099570: 49 31 00 00 78 0e 00 00 71 0e 00 00 00 00 00 00 I1..x...q.......
^^^^^^^^^^^ ^^^^^^^^^^^ --- actual length
0099580: 00 00 ff dd 00 04 00 00 ff db 00 c5 00 14 0e 0f ................
0099590: 12 0f 0d 14 12 10 12 17 15 14 18 1e 32 21 1e 1c ............2!..
00995a0: 1c 1e 3d 2c 2e 24 32 49 40 4c 4b 47 40 46 45 50 ..=,.$2I@LKG@FEP
00995b0: 5a 73 62 50 55 6d 56 45 46 64 88 65 6d 77 7b 81 ZsbPUmVEFd.emw{.
00995c0: 82 81 4e 60 8d 97 8c 7d 96 73 7e 81 7c 01 15 17 ..N`...}.s~.|...
00995d0: 17 1e 1a 1e 3b 21 21 3b 7c 53 46 53 7c 7c 7c 7c ....;!!;|SFS||||
00995e0: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
00995f0: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
0099600: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 02 15 ||||||||||||||..
0099610: 17 17 1e 1a 1e 3b 21 21 3b 7c 53 46 53 7c 7c 7c .....;!!;|SFS|||
0099620: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
0099630: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
0099640: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ff |||||||||||||||.
0099650: c0 00 11 08 00 f0 01 40 03 01 22 00 02 11 01 03 .......@..".....
0099660: 11 02 ff da 00 0c 03 01 00 02 11 03 11 00 3f 00 ..............?.
(end of the invariant portion of an MJPEG chunk in an AVI file)
0099670: a1 46 73 d3 f9 51 ce 3e b4 77 e6 82 ec 02 83 e9 .Fs..Q.>.w......
0099680: 8a 3b d1 d3 a5 2b 88 07 4a 4e a4 d1 da 97 de 90 .;...+..JN......
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
First 32 bytes of the MJPEG chunk payload data that varies.
The invariant, MJPEG header portion contains some quantization tables, a
SOS marker, and SOF marker etc.
The payload after the SOS marker (ff da 00 0c 03 01 00 02 11 03 11 00 3f 00)
reminds me a lot of what the camera puts out in webcam mode.
I suppose if you've seen one blob of Huffman coded data, you've seen
them all, so the webcam mode could be putting out something wildly
different from MJPEG data. However, I'm betting that the webcam uses an
implicit MJPEG header and only sends the encoded data.
> As to
>
> > 0000: e5 00 <--- not repeated like in the sequence above
>
> that was a transcription error on my part, committed by using the mouse to
> copy something in two pieces that was too long to copy at once. Check the
> log I sent along. But I think it is not really there.
OK. I'm not too concerned about this at the moment.
Regards,
Andy
> Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-21 4:19 ` Andy Walls
@ 2009-06-21 15:42 ` Theodore Kilgore
2009-06-22 1:37 ` Andy Walls
2009-06-21 17:12 ` Theodore Kilgore
1 sibling, 1 reply; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-21 15:42 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
On Sun, 21 Jun 2009, Andy Walls wrote:
> On Sat, 2009-06-20 at 20:04 -0500, Theodore Kilgore wrote:
>>
>
>>>>> Sure looks that way. I took a closer look at the lines starting with ff ff
>>>>> ff ff strings, and I found a couple more things. Here are several lines
>>>>> from an extract from that snoop, consisting of what appear to be
>>>>> consecutive SOF lines.
>>>>>
>>>>> 00000000: ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00
>>>>> 00000000: ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00
>>>>> 00000000: ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00
>>>>> 00000000: ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00
>>>>> 00000000: ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00
>>>>>
>>>>> The last non-zero byte is a frame counter. Presumably, the gap between the
>>>>> 01 and the 06 occurs because the camera was just then starting up and
>>>>> things were a bit chaotic. The rest of the lines in the file are
>>>>> completely consistent, counting consecutively from 09 to 49 (hex, of
>>>>> course) at which point I killed the stream.
>>>>>
>>>>> The byte previous to that one (reading downwards 0f 1b 1c 1b 1b ...) gives
>>>>> the number of 0x200-byte blocks in that frame, before the next marker
>>>>> comes along. So if we start from the frame labeled "06" then from there on
>>>>> the frames are approximately the same size, but not identical. For example
>>>>> the size of frame 06 is 0x1b*0x200. That is, 27*512 bytes.
>>>
>>> Here's the init for my camera:
>>>
>>> 0000: 71 81
>>> 0000: 70 05
>>> 0000: 95 70
>>> 0000: 00
>>> 0000: 71 81
>>> 0000: 70 04
>>> 0000: 95 70
>>> 0000: 00
>>> 0000: 71 00
>>> 0000: 70 08
>>> 0000: 95 70
>>> 0000: 00
>>> 0000: 94 02
>>> 0000: de 24
>>> 0000: 94 02
>>> 0000: dd f0
>>> 0000: 94 02
>>> 0000: e3 22 <--- different
>>> 0000: 94 02
>>> 0000: e4 00
>>> 0000: 94 02
>>> 0000: e5 00 <--- not repeated like in the sequence above
>>> 0000: 94 02
>>> 0000: e6 22 <--- different
>>> 0000: 94 03
>>> 0000: aa 01 <--- different
>>> 0000: 71 1e
>>> 0000: 70 06
>>> 0000: 71 80
>>> 0000: 70 07
>>>
>>> And here's the terminal sequence:
>>>
>>> 0000: 71 00
>>> 0000: 70 09
>>> 0000: 71 80
>>> 0000: 70 05
>>>
>>> They look amazingly similar to yours.
>>>
>>> Here are the buffers with the supposed SOF marker:
>>>
>>> 0000: ff ff ff ff 00 00 18 43 1e 00 0d fa 00 00 00 00
>>> 0000: ff ff ff ff 00 00 18 26 1e 00 0d 00 00 00 00 00
>>> 0000: ff ff ff ff 00 00 17 fa 1e 00 0c 01 00 00 00 00
>>> 0000: ff ff ff ff 00 00 18 4e 1e 00 0d 02 00 00 00 00
>>> 0000: ff ff ff ff 00 00 18 91 1e 00 0d 03 00 00 00 00
>>> 0000: ff ff ff ff 00 00 18 90 1e 00 0d 04 00 00 00 00
>>> 0000: ff ff ff ff 00 00 18 4b 1e 00 0d 05 00 00 00 00
>>> 0000: ff ff ff ff 00 00 18 8a 1e 00 0d 06 00 00 00 00
>>>
>>> Again very similar. I had the camera pointed at a mostly white test
>>> target with some large blue numbers printed on it, so the sammler
>>> buffers probably just indicate how simple the test target was.
>>>
>>> The frames from my camera were coming at 100 ms intervals instead of 130
>>> ms intervals. So maybe some scaling constant has changed with my
>>> supposed frame presentation frequency field that contains 0x1e00.
>
>>
>> This looks quite similar. The differences in the init sequence may be
>> significant, but more likely I would speculate that they are
>> insubstantial. Probably the little differences are due to who actually
>> wrote the camera driver. Those guys over there also put their pants on one
>> leg at a time just like the rest of us, after all. I think they do things
>> like hiring students to write their drivers. If so, they might possibly
>> get the same kind of results that could be expected over here from similar
>> arrangements.
>
> Agree.
>
> The more I dig into this, the more I think (hope or wish?) the stuff in
> the usb snoop logs looks MJPEG.
>
> I started looking at an AVI file that I recorded with the camera. It
> looks like a DV AVI Type-2 file.
>
> In the AVI file header, my camera reports:
>
> 00000d0: 0000 0000 7374 7264 ac00 0000 4a65 696c ....strd....Jeil
> 00000e0: 696e 2020 5465 6368 6e6f 6c6f 6779 2043 in Technology C
> 00000f0: 6f2e 2c20 4c74 642e 4a4c 3230 3038 5632 o., Ltd.JL2008V2
> 0000100: 4330 3037 3030 3130 2020 2020 2020 2020 C0070010
>
> So looking up the JL2008A datasheet, my camera's capabilities match the
> data sheet very well.
>
> http://jeilin.com.tw/eng/product_detail.php?p_id=5
> http://jeilin.com.tw/mana_php/Download/File/JL2008A%20v1.3.pdf
>
> The only video compression that is mentioned on the webpage and in the
> datasheet is JPEG.
>
> Trying to learn about DV AVI Type 2 files I've found roughly how
> individual chunk headers look. They each have a stream fourcc that
> starts 'nnxx' in ASCII, where nn is the stream number and xx is
>
> db - uncompressed video frame
> dc - compressed video frame
> wb - audio data
>
> $ xxd 00004.avi | grep -E ' 303[0-2] ((646)|(776))'
>
> 00001f0: 14fe 0c00 6d6f 7669 3031 7762 401f 0000 ....movi01wb@... <-- audio
> 0002140: 3032 6462 0041 0000 ffe2 55aa 0500 0000 02db.A....U..... <-- video
> 0006250: 3032 6462 0041 0000 ffe2 55aa 0500 0001 02db.A....U..... <-- video
> 000a360: 3032 6462 0041 0000 ffe2 55aa 0500 0002 02db.A....U..... <-- video
> 000e470: 3032 6462 0041 0000 ffe2 55aa 0500 0003 02db.A....U..... <-- video
> 0012580: 3032 6462 0041 0000 ffe2 55aa 0500 0004 02db.A....U..... <-- video
> 0016690: 3030 6463 281c 0000 ffd8 ffe0 0016 4156 00dc(.........AV <-- compressed video
> 00182c0: 3030 6463 e81b 0000 ffd8 ffe0 0016 4156 00dc..........AV <-- compressed video
> 0019eb0: 3030 6463 c81b 0000 ffd8 ffe0 0016 4156 00dc..........AV <-- compressed video
>
>> From the AVI header and from the compressed video chunk headers, the
> compressed video stream is MJPEG.
>
> I don't know what the uncompressed video (02db) chunks are. The AVI
> header doesn't mention a third stream (stream 02). The length of each
> chunk of this third stream is 0x4100 = 0x20 * 0x200 and each one has an
> incrementing sequence number in the header.
>
> Doing some math:
>
> 320 * 240 = 76800 = 0x12c00
>
> 0x12c00 / 0x4100 = 0x4.9d = 4.61
>
> so 5 chunks of 0x4100 bytes would be needed for one uncompressed 320x240
> frame at 8 bits/pixel. Those uncompressed video chunks always come in
> groups of 5 in the AVI file.
>
>
> The idx section at the end of the AVI file only indexes the compressed
> video (00dc) and audio (01wb) chunks:
>
> 00d0000: 0000 0000 0000 0000 6964 7831 4005 0000 ........idx1@...
> 00d0010: 3031 7762 0000 0000 0400 0000 401f 0000 01wb........@...
> 00d0020: 3030 6463 1000 0000 9c64 0100 281c 0000 00dc.....d..(...
> 00d0030: 3030 6463 1000 0000 cc80 0100 e81b 0000 00dc............
> 00d0040: 3030 6463 1000 0000 bc9c 0100 c81b 0000 00dc............
> 00d0050: 3030 6463 1000 0000 8cb8 0100 f81b 0000 00dc............
> 00d0060: 3030 6463 1000 0000 8cd4 0100 581c 0000 00dc........X...
>
>
> My tired eyes are telling me the AVI file's MJPEG compressed video
> stream (00dc) looks like what comes out of the camera in webcam mode
> than the AVI file's uncompressed video stream.
>
> The first 0x110 bytes of the MJPEG stream (00dc) chunks in the AVI file
> remain invariant, except for 3, 32 bit values related to length: The AVI
> stream 00dc chunk length and the MJPEG AVI1 App's field size and padded
> field size (I think).
>
> 0099560: 30 30 64 63 78 0e 00 00 ff d8 ff e0 00 16 41 56 00dcx.........AV
> ^^^^^^^^^^^--- Chunk/padded length
> 0099570: 49 31 00 00 78 0e 00 00 71 0e 00 00 00 00 00 00 I1..x...q.......
> ^^^^^^^^^^^ ^^^^^^^^^^^ --- actual length
> 0099580: 00 00 ff dd 00 04 00 00 ff db 00 c5 00 14 0e 0f ................
> 0099590: 12 0f 0d 14 12 10 12 17 15 14 18 1e 32 21 1e 1c ............2!..
> 00995a0: 1c 1e 3d 2c 2e 24 32 49 40 4c 4b 47 40 46 45 50 ..=,.$2I@LKG@FEP
> 00995b0: 5a 73 62 50 55 6d 56 45 46 64 88 65 6d 77 7b 81 ZsbPUmVEFd.emw{.
> 00995c0: 82 81 4e 60 8d 97 8c 7d 96 73 7e 81 7c 01 15 17 ..N`...}.s~.|...
> 00995d0: 17 1e 1a 1e 3b 21 21 3b 7c 53 46 53 7c 7c 7c 7c ....;!!;|SFS||||
> 00995e0: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
> 00995f0: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
> 0099600: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 02 15 ||||||||||||||..
> 0099610: 17 17 1e 1a 1e 3b 21 21 3b 7c 53 46 53 7c 7c 7c .....;!!;|SFS|||
> 0099620: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
> 0099630: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
> 0099640: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ff |||||||||||||||.
> 0099650: c0 00 11 08 00 f0 01 40 03 01 22 00 02 11 01 03 .......@..".....
> 0099660: 11 02 ff da 00 0c 03 01 00 02 11 03 11 00 3f 00 ..............?.
> (end of the invariant portion of an MJPEG chunk in an AVI file)
>
> 0099670: a1 46 73 d3 f9 51 ce 3e b4 77 e6 82 ec 02 83 e9 .Fs..Q.>.w......
> 0099680: 8a 3b d1 d3 a5 2b 88 07 4a 4e a4 d1 da 97 de 90 .;...+..JN......
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> |
> First 32 bytes of the MJPEG chunk payload data that varies.
>
>
> The invariant, MJPEG header portion contains some quantization tables, a
> SOS marker, and SOF marker etc.
>
> The payload after the SOS marker (ff da 00 0c 03 01 00 02 11 03 11 00 3f 00)
> reminds me a lot of what the camera puts out in webcam mode.
>
> I suppose if you've seen one blob of Huffman coded data, you've seen
> them all, so the webcam mode could be putting out something wildly
> different from MJPEG data. However, I'm betting that the webcam uses an
> implicit MJPEG header and only sends the encoded data.
>
>
>> As to
>>
>>> 0000: e5 00 <--- not repeated like in the sequence above
>>
>> that was a transcription error on my part, committed by using the mouse to
>> copy something in two pieces that was too long to copy at once. Check the
>> log I sent along. But I think it is not really there.
>
> OK. I'm not too concerned about this at the moment.
Well, it appears that there are a couple of ways to go:
1. Get busy and write a driver that will get the raw data out, so that it
can be inspected. Once that is done, then, quoting the White Knight
in Lewis Carroll, "Either it brings tears to your eyes, or it doesn't."
2. Take some of the snoop log output and convert it by hand to a binary
file, so that it can actually be looked at with hexdump to see if similar
clues are present. I have a few tools that, while not making this
automatic, do make the job not too too unpleasant.
As far as the log output or raw data is concerned, one can look of course
for JPEG headers. But (admittedly only after a cursory glance) I am
suspecting that they are not yet present in the raw data from the camera.
Clearly, it would be nice to be wrong.
As to what MJPEG output looks like, in fact I have no experience with it
at all. I also do not know how to make my camera to do an AVI file. It
is a standard capability for many of these cheap dual-mode cameras, to do
a short "movie clip," but I have misplaced the manual and would have to
guess about how to press the magic sequence of buttons to make the camera
do that. And I am also not sure what I will learn if I do make it work,
which is relevant to the somewhat different functionality of streaming. It
will be interesting if I can pull up a header like yours. We would
actually know, then, that Jeilin says we have the same camera under the
hood.
I can try to look into some of these things.
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-21 4:19 ` Andy Walls
2009-06-21 15:42 ` Theodore Kilgore
@ 2009-06-21 17:12 ` Theodore Kilgore
1 sibling, 0 replies; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-21 17:12 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
I mentioned in my last message a couple of things to try in order to make
further progress. One of those was
2. Take some of the snoop log output and convert it by hand to a binary
file, so that it can actually be looked at with hexdump to see if similar
clues are present. I have a few tools that, while not making this
automatic, do make the job not too too unpleasant.
So, I have implemented this one. That is, I have removed everything other
than frame data from your log file, and from mine. After that, I have
converted said frame data to binary, using a program called "hex2bin"
that I found several years ago (see footnote).
After that, I have done hexdump -C to the result in order to see if any
interesting text becomes visible.
What I have to report is:
No detectable text patterns, neither in the raw data output from your
camera, nor from mine. It appears to me that we have nothing there but raw
data and the camera-specific frame headers which we have already figured
out are there.
(footnote)
The program was in source form, and carries the following notice
/*
hex2bin.c reverse hexdump
Copyright (c) 1996 by Andreas Leitgeb (AvL) <avl@logic.tuwien.ac.at>
Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appear in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation.
*/
Probably nobody on a list like this one needs a thing like this, but just
in case that anyone does, I just checked with Google for hex2bin.c and
this one comes up as the second hit. I have used it on previous occasions,
and it seems to work nicely.
(end footnote)
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-21 15:42 ` Theodore Kilgore
@ 2009-06-22 1:37 ` Andy Walls
2009-06-22 3:39 ` Theodore Kilgore
0 siblings, 1 reply; 23+ messages in thread
From: Andy Walls @ 2009-06-22 1:37 UTC (permalink / raw)
To: Theodore Kilgore; +Cc: Linux Media Mailing List
On Sun, 2009-06-21 at 10:42 -0500, Theodore Kilgore wrote:
>
> On Sun, 21 Jun 2009, Andy Walls wrote:
> > The more I dig into this, the more I think (hope or wish?) the stuff in
> > the usb snoop logs looks MJPEG.
> >
> > I started looking at an AVI file that I recorded with the camera. It
> > looks like a DV AVI Type-2 file.
> >
> > In the AVI file header, my camera reports:
> >
> > 00000d0: 0000 0000 7374 7264 ac00 0000 4a65 696c ....strd....Jeil
> > 00000e0: 696e 2020 5465 6368 6e6f 6c6f 6779 2043 in Technology C
> > 00000f0: 6f2e 2c20 4c74 642e 4a4c 3230 3038 5632 o., Ltd.JL2008V2
> > 0000100: 4330 3037 3030 3130 2020 2020 2020 2020 C0070010
> >
> > So looking up the JL2008A datasheet, my camera's capabilities match the
> > data sheet very well.
> >
> > http://jeilin.com.tw/eng/product_detail.php?p_id=5
> > http://jeilin.com.tw/mana_php/Download/File/JL2008A%20v1.3.pdf
> >
> > The only video compression that is mentioned on the webpage and in the
> > datasheet is JPEG.
> >
> > Trying to learn about DV AVI Type 2 files I've found roughly how
> > individual chunk headers look. They each have a stream fourcc that
> > starts 'nnxx' in ASCII, where nn is the stream number and xx is
> >
> > db - uncompressed video frame
> > dc - compressed video frame
> > wb - audio data
> >
> > $ xxd 00004.avi | grep -E ' 303[0-2] ((646)|(776))'
> >
> > 00001f0: 14fe 0c00 6d6f 7669 3031 7762 401f 0000 ....movi01wb@... <-- audio
> > 0002140: 3032 6462 0041 0000 ffe2 55aa 0500 0000 02db.A....U..... <-- video
> > 0006250: 3032 6462 0041 0000 ffe2 55aa 0500 0001 02db.A....U..... <-- video
> > 000a360: 3032 6462 0041 0000 ffe2 55aa 0500 0002 02db.A....U..... <-- video
> > 000e470: 3032 6462 0041 0000 ffe2 55aa 0500 0003 02db.A....U..... <-- video
> > 0012580: 3032 6462 0041 0000 ffe2 55aa 0500 0004 02db.A....U..... <-- video
> > 0016690: 3030 6463 281c 0000 ffd8 ffe0 0016 4156 00dc(.........AV <-- compressed video
> > 00182c0: 3030 6463 e81b 0000 ffd8 ffe0 0016 4156 00dc..........AV <-- compressed video
> > 0019eb0: 3030 6463 c81b 0000 ffd8 ffe0 0016 4156 00dc..........AV <-- compressed video
> >
> >> From the AVI header and from the compressed video chunk headers, the
> > compressed video stream is MJPEG.
> >
> > I don't know what the uncompressed video (02db) chunks are. The AVI
> > header doesn't mention a third stream (stream 02). The length of each
> > chunk of this third stream is 0x4100 = 0x20 * 0x200 and each one has an
> > incrementing sequence number in the header.
> >
> > Doing some math:
> >
> > 320 * 240 = 76800 = 0x12c00
> >
> > 0x12c00 / 0x4100 = 0x4.9d = 4.61
> >
> > so 5 chunks of 0x4100 bytes would be needed for one uncompressed 320x240
> > frame at 8 bits/pixel. Those uncompressed video chunks always come in
> > groups of 5 in the AVI file.
> >
> >
> > The idx section at the end of the AVI file only indexes the compressed
> > video (00dc) and audio (01wb) chunks:
> >
> > 00d0000: 0000 0000 0000 0000 6964 7831 4005 0000 ........idx1@...
> > 00d0010: 3031 7762 0000 0000 0400 0000 401f 0000 01wb........@...
> > 00d0020: 3030 6463 1000 0000 9c64 0100 281c 0000 00dc.....d..(...
> > 00d0030: 3030 6463 1000 0000 cc80 0100 e81b 0000 00dc............
> > 00d0040: 3030 6463 1000 0000 bc9c 0100 c81b 0000 00dc............
> > 00d0050: 3030 6463 1000 0000 8cb8 0100 f81b 0000 00dc............
> > 00d0060: 3030 6463 1000 0000 8cd4 0100 581c 0000 00dc........X...
> >
> >
> > My tired eyes are telling me the AVI file's MJPEG compressed video
> > stream (00dc) looks like what comes out of the camera in webcam mode
> > than the AVI file's uncompressed video stream.
> >
> > The first 0x110 bytes of the MJPEG stream (00dc) chunks in the AVI file
> > remain invariant, except for 3, 32 bit values related to length: The AVI
> > stream 00dc chunk length and the MJPEG AVI1 App's field size and padded
> > field size (I think).
> >
> > 0099560: 30 30 64 63 78 0e 00 00 ff d8 ff e0 00 16 41 56 00dcx.........AV
> > ^^^^^^^^^^^--- Chunk/padded length
> > 0099570: 49 31 00 00 78 0e 00 00 71 0e 00 00 00 00 00 00 I1..x...q.......
> > ^^^^^^^^^^^ ^^^^^^^^^^^ --- actual length
> > 0099580: 00 00 ff dd 00 04 00 00 ff db 00 c5 00 14 0e 0f ................
> > 0099590: 12 0f 0d 14 12 10 12 17 15 14 18 1e 32 21 1e 1c ............2!..
> > 00995a0: 1c 1e 3d 2c 2e 24 32 49 40 4c 4b 47 40 46 45 50 ..=,.$2I@LKG@FEP
> > 00995b0: 5a 73 62 50 55 6d 56 45 46 64 88 65 6d 77 7b 81 ZsbPUmVEFd.emw{.
> > 00995c0: 82 81 4e 60 8d 97 8c 7d 96 73 7e 81 7c 01 15 17 ..N`...}.s~.|...
> > 00995d0: 17 1e 1a 1e 3b 21 21 3b 7c 53 46 53 7c 7c 7c 7c ....;!!;|SFS||||
> > 00995e0: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
> > 00995f0: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
> > 0099600: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 02 15 ||||||||||||||..
> > 0099610: 17 17 1e 1a 1e 3b 21 21 3b 7c 53 46 53 7c 7c 7c .....;!!;|SFS|||
> > 0099620: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
> > 0099630: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
> > 0099640: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ff |||||||||||||||.
> > 0099650: c0 00 11 08 00 f0 01 40 03 01 22 00 02 11 01 03 .......@..".....
> > 0099660: 11 02 ff da 00 0c 03 01 00 02 11 03 11 00 3f 00 ..............?.
> > (end of the invariant portion of an MJPEG chunk in an AVI file)
> >
> > 0099670: a1 46 73 d3 f9 51 ce 3e b4 77 e6 82 ec 02 83 e9 .Fs..Q.>.w......
> > 0099680: 8a 3b d1 d3 a5 2b 88 07 4a 4e a4 d1 da 97 de 90 .;...+..JN......
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > |
> > First 32 bytes of the MJPEG chunk payload data that varies.
> >
> >
> > The invariant, MJPEG header portion contains some quantization tables, a
> > SOS marker, and SOF marker etc.
> >
> > The payload after the SOS marker (ff da 00 0c 03 01 00 02 11 03 11 00 3f 00)
> > reminds me a lot of what the camera puts out in webcam mode.
> >
> > I suppose if you've seen one blob of Huffman coded data, you've seen
> > them all, so the webcam mode could be putting out something wildly
> > different from MJPEG data. However, I'm betting that the webcam uses an
> > implicit MJPEG header and only sends the encoded data.
> >
> Well, it appears that there are a couple of ways to go:
>
> 1. Get busy and write a driver that will get the raw data out, so that it
> can be inspected. Once that is done, then, quoting the White Knight
> in Lewis Carroll, "Either it brings tears to your eyes, or it doesn't."
>
> 2. Take some of the snoop log output and convert it by hand to a binary
> file, so that it can actually be looked at with hexdump to see if similar
> clues are present. I have a few tools that, while not making this
> automatic, do make the job not too too unpleasant.
>
> As far as the log output or raw data is concerned, one can look of course
> for JPEG headers. But (admittedly only after a cursory glance) I am
> suspecting that they are not yet present in the raw data from the camera.
> Clearly, it would be nice to be wrong.
I suspect neither JPEG (JFIF, TIFF/JPEG, EXIF) nor MJPEG (Apple
QuickTime, MS AVI) headers are there. They should look very different
from the data payload we see.
A quick 'strings -a jl2008.sys' reveals 'JFIF' and 'MJPG' both appearing
once and 'vids' appearing several times. That leads me to suspect the
driver may be building JFIF JPEG stills or MS AVI MJPEG streams using
data from the device.
> As to what MJPEG output looks like, in fact I have no experience with it
> at all.
For the file formats, for which there is no real standard (except for
Motion JPEG 2000 which has an ISO/IEC document):
Some education and history:
http://www.digitalpreservation.gov/formats/fdd/video_fdd.shtml
http://www.digitalpreservation.gov/formats/fdd/fdd000060.shtml
http://www.digitalpreservation.gov/formats/fdd/fdd000089.shtml
http://en.wikipedia.org/wiki/MJPEG
http://en.wikipedia.org/wiki/Audio_Video_Interleave#DV_AVI
Some actual, but partial specification:
http://msdn.microsoft.com/en-us/library/ms779636.aspx
http://msdn.microsoft.com/en-us/library/ms783421(VS.85).aspx
http://developer.apple.com/documentation/QuickTime/QTFF/qtff.pdf
So looking at the above resources (especially the Apple doc), I can
decode a little of the above RIFF/AVI chunk that holds MJPEG data.
0099560: 30 30 64 63 78 0e 00 00 - RIFF/AVI chunk header, stream '00', 'dc' -> compressed video, chunk payload length 0xe78(?)
0099568: ff d8 - JPEG start of image marker
009956a: ff e0 00 16 41 56 49 31 00 00 78 0e 00 00 71 0e 00 00 00 00 00 00 00 00
MJPEG App0(?) marker, marker content length 0x16, App name 'AVI1', padded lenght 0xe78, actual length 0xe71
0099582: ff dd 00 04 00 00 - JPEG marker 0xff 0xdd, marker content length 4 (I don't know)
0099588: ff db 00 c5 - JPEG Quantization table marker, marker content length 0xc5
009958c: 00 - Y quantization table
009958d: 14 0e 0f 12 0f 0d 14 12 10 12 17 15 14 18 1e 32 21 1e 1c
00995a0: 1c 1e 3d 2c 2e 24 32 49 40 4c 4b 47 40 46 45 50
00995b0: 5a 73 62 50 55 6d 56 45 46 64 88 65 6d 77 7b 81
00995c0: 82 81 4e 60 8d 97 8c 7d 96 73 7e 81 7c
00995cd: 01 - Pr(?) quantization table
00995ce: 15 17 17 1e 1a 1e 3b 21 21 3b 7c 53 46 53 7c 7c 7c 7c
00995e0: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c
00995f0: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c
0099600: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c
>
009960e: 02 - Pb(?) qunatization table
009960f: 15 17 17 1e 1a 1e 3b 21 21 3b 7c 53 46 53 7c 7c 7c
0099620: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c
0099630: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c
0099640: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c
009964f: ff c0 00 11 08 00 f0 01 40 03 01 22 00 02 11 01 03 11 02
(M?)JPEG Start of Frame Marker, marker length 0x11, 8 bpp?, 0x00f0 x 0x0140 (240 by 320), ...
0099662: ff da 00 0c 03 01 00 02 11 03 11 00 3f 00
(M?)JPEG Start of Stream Marker, marker conten length 0xc, ....
0099670: a1 46 73 d3 f9 51 ce 3e b4 77 e6 82 ec 02 83 e9 .Fs..Q.>.w......
0099680: 8a 3b d1 d3 a5 2b 88 07 4a 4e a4 d1 da 97 de 90 .;...+..JN......
Beginning of entropy coded data....
Notice with MJPEG, there is no explicit Huffman table specified. It is
fixed and implicit. MJPEG decoders have to know to tack the proper
Huffman table in place before sending a frame to a JPEG decoder.
> I also do not know how to make my camera to do an AVI file. It
> is a standard capability for many of these cheap dual-mode cameras, to do
> a short "movie clip," but I have misplaced the manual and would have to
> guess about how to press the magic sequence of buttons to make the camera
> do that.
On my camera, when the USB cable is not connected, the "mode" button
switches between taking stills or videos. The videos show up on the
mass storage device as *.avi files.
> And I am also not sure what I will learn if I do make it work,
> which is relevant to the somewhat different functionality of streaming.
I'm not sure either. I tend to work problems with lots of unknowns with
two rules of thumb:
1. Use all the available information you can find.
2. If the answers aren't where you are looking, they must be somewhere
else.
I think the best information I gleaned from the AVI file was higher
confidence that I was looking at JPEG image data in the USB trace logs,
and that the usb trace was devoid of useful JPEG or MJPEG header
information.
The product information on the JL2008 let me know that the only realtime
compression engine on the chip is JPEG.
> It
> will be interesting if I can pull up a header like yours. We would
> actually know, then, that Jeilin says we have the same camera under the
> hood.
The EXIF header in the JPEG stills captured by the camera has this
identifier in it:
0000090: 0000 4a45 494c 494e 2054 4543 482e 5151 ..JEILIN TECH.QQ
00000a0: 2044 5630 344f b400 0000 0100 0000 b400 DV04O..........
00000b0: 0000 0100 0000 4330 3037 3030 3130 000c ......C0070010..
00000c0: 0200 9208 0200 9e1c 0200 b614 0200 d208 ................
00000d0: 0502 3230 3036 3a30 373a 3236 2031 313a ..2006:07:26 11:
00000e0: 3030 3a30 3000 2200 9a82 0500 0100 0000 00:00.".........
I love that I get a timestamp from a camera with no user accessable
clock. :)
I will send you a private email with a JPEG still and an AVI file taken
by the camera of the same test target (I think) that I used when
producing the usb snoop logs.
> I can try to look into some of these things.
Please do. I have time to research, but not too much time to do decent
coding. During research, I can easily recover from normal household
interruptions; during coding, not so well.
Regards,
Andy
> Theodore Kilgore
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-22 1:37 ` Andy Walls
@ 2009-06-22 3:39 ` Theodore Kilgore
2009-06-22 11:27 ` Andy Walls
0 siblings, 1 reply; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-22 3:39 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
Andy,
You are right. Your camera is emitting JPEG while streaming. I just
succeeded in creating an image which resembles your test picture by
extracting the frame data for one frame, tacking on a header, and running
hex2bin on the combined file. I did not get the thing quite right, because
your header is from your JPEG photo (640x480) and your stream is probably
320x240. But I got something out which is obviously recognizable.
Therefore with a little bit of further tweaking it will presumably come
out exactly so. Namely, I have to remember where to stick the two
dimensions into the header. As my students in courses like calculus say,
"Sir, it has been a long time since I studied that." Whereupon I reply,
"With my white hair, I wonder how far I could get with that excuse?"
I will send you a copy of the results for your amusement. It is obviously
the first attempt, so do not laugh at the fact that you get two copies of
3
x6
--
side by side, please.
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-22 3:39 ` Theodore Kilgore
@ 2009-06-22 11:27 ` Andy Walls
2009-06-22 15:51 ` Theodore Kilgore
2009-06-22 23:57 ` Theodore Kilgore
0 siblings, 2 replies; 23+ messages in thread
From: Andy Walls @ 2009-06-22 11:27 UTC (permalink / raw)
To: Theodore Kilgore; +Cc: Linux Media Mailing List
On Sun, 2009-06-21 at 22:39 -0500, Theodore Kilgore wrote:
> Andy,
>
> You are right. Your camera is emitting JPEG while streaming. I just
> succeeded in creating an image which resembles your test picture by
> extracting the frame data for one frame, tacking on a header, and running
> hex2bin on the combined file. I did not get the thing quite right, because
> your header is from your JPEG photo (640x480) and your stream is probably
> 320x240. But I got something out which is obviously recognizable.
Excellent. Going from "It may never work" to "something recognizable"
in one weekend is good progress.
> Therefore with a little bit of further tweaking it will presumably come
> out exactly so. Namely, I have to remember where to stick the two
> dimensions into the header.
Yes, as far as I'm concerned the problem is solved. The details are
left as an exercise for the reader. ;)
I'm not up to speed on Linux webcam kernel to userspace API details.
However, might I suggest going forward for testing at least, that when
one starts the webcam streaming, the driver emit the stream in the form
of an AVI. You'd need an AVI header declaring only an MJPEG 'vids'
stream - no 'auds' nor 'idx' - and a 'movi' section with RIFF/AVI chunks
that have MJPEG headers and the webcam payload.
I haven't seen evidence that audio comes from the webcam when it is
streaming, but I haven't looked very much either.
> As my students in courses like calculus say,
> "Sir, it has been a long time since I studied that." Whereupon I reply,
> "With my white hair, I wonder how far I could get with that excuse?"
:)
> I will send you a copy of the results for your amusement. It is obviously
> the first attempt, so do not laugh at the fact that you get two copies of
>
> 3
> x6
> --
>
> side by side, please.
In retrospect, I should have used the 6x7 (or 6x9) flash card, so the
answer would have been 42. :)
Regards,
Andy
> Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-22 11:27 ` Andy Walls
@ 2009-06-22 15:51 ` Theodore Kilgore
2009-06-23 10:37 ` Andy Walls
2009-06-22 23:57 ` Theodore Kilgore
1 sibling, 1 reply; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-22 15:51 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
On Mon, 22 Jun 2009, Andy Walls wrote:
> On Sun, 2009-06-21 at 22:39 -0500, Theodore Kilgore wrote:
>> Andy,
>>
>> You are right. Your camera is emitting JPEG while streaming. I just
>> succeeded in creating an image which resembles your test picture by
>> extracting the frame data for one frame, tacking on a header, and running
>> hex2bin on the combined file. I did not get the thing quite right, because
>> your header is from your JPEG photo (640x480) and your stream is probably
>> 320x240. But I got something out which is obviously recognizable.
>
> Excellent. Going from "It may never work" to "something recognizable"
> in one weekend is good progress.
Well, sometimes the easy and obvious just works, and one is lucky. If only
they were all that easy. Besides, as we well know, this list is a place
where geniuses hang out. So perhaps some of the pixie dust has rubbed off
on us.
>
>> Therefore with a little bit of further tweaking it will presumably come
>> out exactly so. Namely, I have to remember where to stick the two
>> dimensions into the header.
>
> Yes, as far as I'm concerned the problem is solved. The details are
> left as an exercise for the reader. ;)
>
I will try to get on it. There is nothing left but details, but there are
lots of those. The first one is to get the header exactly right. Then
there is the question, what is _my_ camera doing? I did not check that
yet. And so on. So it is an algorithm now, but many steps remain to be
completed.
>
> I'm not up to speed on Linux webcam kernel to userspace API details.
> However, might I suggest going forward for testing at least, that when
> one starts the webcam streaming, the driver emit the stream in the form
> of an AVI. You'd need an AVI header declaring only an MJPEG 'vids'
> stream - no 'auds' nor 'idx' - and a 'movi' section with RIFF/AVI chunks
> that have MJPEG headers and the webcam payload.
For all I know, it might be just a matter of following down a standard
path. Perhaps this is all handled already in libv4lconvert, and it is
merely a matter of plugging into that. I haven't checked yet, but that is
more or less what I expect right now.
>
> I haven't seen evidence that audio comes from the webcam when it is
> streaming, but I haven't looked very much either.
Same. Actually, my impression is that these cameras can not walk and chew
gum at the same time. I would suspect that the audio is an either/or kind
of thing. Either on, and it can record audio but not stream it, or off. I
would be very surprised if an el cheapo like the one I have could do more.
I could be wrong, of course. Perhaps both of us ought to check closely.
>
>
>
>> As my students in courses like calculus say,
>> "Sir, it has been a long time since I studied that." Whereupon I reply,
>> "With my white hair, I wonder how far I could get with that excuse?"
>
> :)
>
>> I will send you a copy of the results for your amusement. It is obviously
>> the first attempt, so do not laugh at the fact that you get two copies of
>>
>> 3
>> x6
>> --
>>
>> side by side, please.
>
> In retrospect, I should have used the 6x7 (or 6x9) flash card, so the
> answer would have been 42. :)
Well, then there would be no mysteries left, would there? We couldn't have
that.
This is Monday, and I have to go off to the salt mine. I may be able to
get back to this after coming home from the class.
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-22 11:27 ` Andy Walls
2009-06-22 15:51 ` Theodore Kilgore
@ 2009-06-22 23:57 ` Theodore Kilgore
1 sibling, 0 replies; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-22 23:57 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
<snip>
>> Therefore with a little bit of further tweaking it will presumably come
>> out exactly so. Namely, I have to remember where to stick the two
>> dimensions into the header.
Today's progress, so far:
1. I managed to look up where the width and height go, and indeed the
image comes out nicely when the dimensions are appropriately entered.
2. The same header that I peeled off from your JPEG image also works for
images from my cam. That is, I took your header, converted to text, and
corrected the dimensions. Then I took a frame extracted from the snoop log
of my camera, prepended it with your header, and I get a recognizable
image. I really should try the same with a header from my own camera, of
course. For one thing, the image was recognizable but not beautiful, and
it occurs to me as I write that there might be some problem other than,
perhaps, an unlucky choice of frame. But we do have a demonstration that
there is some high degree of compatibility.
Finally, I succeeded in creating a couple of AVI files. There is one
difference between the two AVI headers. Yours has
Jeilin Technology Co., Ltd.JL2008V2C0070010
and mine has only
Jeilin Technology Co.
So what is the version of my camera? They don't say, and therefore I still
don't know. We can hope it does not matter very much.
I will have a go at writing a module for them, and we can see what happens
after that.
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-22 15:51 ` Theodore Kilgore
@ 2009-06-23 10:37 ` Andy Walls
2009-06-23 16:14 ` Theodore Kilgore
0 siblings, 1 reply; 23+ messages in thread
From: Andy Walls @ 2009-06-23 10:37 UTC (permalink / raw)
To: Theodore Kilgore; +Cc: Linux Media Mailing List
On Mon, 2009-06-22 at 10:51 -0500, Theodore Kilgore wrote:
>
> On Mon, 22 Jun 2009, Andy Walls wrote:
>
> > On Sun, 2009-06-21 at 22:39 -0500, Theodore Kilgore wrote:
> >> Andy,
> >>
> >> You are right. Your camera is emitting JPEG while streaming. I just
> >> succeeded in creating an image which resembles your test picture by
> >> extracting the frame data for one frame, tacking on a header, and running
> >> hex2bin on the combined file. I did not get the thing quite right, because
> >> your header is from your JPEG photo (640x480) and your stream is probably
> >> 320x240. But I got something out which is obviously recognizable.
> >
> > Excellent. Going from "It may never work" to "something recognizable"
> > in one weekend is good progress.
>
> Well, sometimes the easy and obvious just works, and one is lucky. If only
> they were all that easy.
I'd contend most would be easy and obvious, as anything created by
people is usually easy to understand. People are generally lazy and
want to avoid what they perceive as extra effort. If you couple that
with management pressure on engineers to keep costs down and maintain
project schedules, you often end up with very simple solutions.
The data encoding used by the camera is indicative of that. For this
camera, the engineers decided to simply drop the (M)JPEG headers to save
USB communications bandwidth instead of using a different, better
compression algorithm; or a imlementing new USB 2.0 interface.
> Besides, as we well know, this list is a place
> where geniuses hang out. So perhaps some of the pixie dust has rubbed off
> on us.
I thought genius was inspiration and perspiration. Pixie dust - I knew
Edison wasn't telling the whole truth. ;)
> >
> >> Therefore with a little bit of further tweaking it will presumably come
> >> out exactly so. Namely, I have to remember where to stick the two
> >> dimensions into the header.
> >
> > Yes, as far as I'm concerned the problem is solved. The details are
> > left as an exercise for the reader. ;)
> >
>
> I will try to get on it. There is nothing left but details, but there are
> lots of those.
Yes, I agree. Getting those right is no small task.
> The first one is to get the header exactly right.
Well, given that the Windows driver has the AVI video stream FourCC
'vids' appearing four or five times, I suspect there is more than 1
header template that the Windows driver can tack on to the incoming
stream. I'm guessing that which one is used, depends on how the camera
stream is initialized.
There are probably all sorts of header permutations that will yield
viewable but suboptimal reconstruction. :(
Then again it's a cheap webcam, so by definition any image is probably
suboptimal.
> Then
> there is the question, what is _my_ camera doing? I did not check that
> yet. And so on. So it is an algorithm now, but many steps remain to be
> completed.
Yes. I agree.
>
> >
> > I'm not up to speed on Linux webcam kernel to userspace API details.
> > However, might I suggest going forward for testing at least, that when
> > one starts the webcam streaming, the driver emit the stream in the form
> > of an AVI. You'd need an AVI header declaring only an MJPEG 'vids'
> > stream - no 'auds' nor 'idx' - and a 'movi' section with RIFF/AVI chunks
> > that have MJPEG headers and the webcam payload.
>
> For all I know, it might be just a matter of following down a standard
> path. Perhaps this is all handled already in libv4lconvert, and it is
> merely a matter of plugging into that. I haven't checked yet, but that is
> more or less what I expect right now.
Ah, OK.
> >
> > I haven't seen evidence that audio comes from the webcam when it is
> > streaming, but I haven't looked very much either.
>
> Same. Actually, my impression is that these cameras can not walk and chew
> gum at the same time. I would suspect that the audio is an either/or kind
> of thing. Either on, and it can record audio but not stream it, or off. I
> would be very surprised if an el cheapo like the one I have could do more.
> I could be wrong, of course. Perhaps both of us ought to check closely.
I know it can simultaneously record audio and video to an AVI file in
it's local storage. I'm thinking it would not make sense to shovel over
audio in webcam mode anyway, as most computers have their own microphone
to collect sound.
> >
> > In retrospect, I should have used the 6x7 (or 6x9) flash card, so the
> > answer would have been 42. :)
>
> Well, then there would be no mysteries left, would there? We couldn't have
> that.
>
> This is Monday, and I have to go off to the salt mine. I may be able to
> get back to this after coming home from the class.
I have no timeline in mind. Having this webcam work will simply be a
"nice to have". I'm available for testing and any
investigation/research that you don't have time to do.
Regards,
Andy
> Theodore Kilgore
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Sakar 57379 USB Digital Video Camera...
2009-06-23 10:37 ` Andy Walls
@ 2009-06-23 16:14 ` Theodore Kilgore
0 siblings, 0 replies; 23+ messages in thread
From: Theodore Kilgore @ 2009-06-23 16:14 UTC (permalink / raw)
To: Andy Walls; +Cc: Linux Media Mailing List
On Tue, 23 Jun 2009, Andy Walls wrote:
> On Mon, 2009-06-22 at 10:51 -0500, Theodore Kilgore wrote:
>>
>> On Mon, 22 Jun 2009, Andy Walls wrote:
>>
>>> On Sun, 2009-06-21 at 22:39 -0500, Theodore Kilgore wrote:
>>>> Andy,
>>>>
>>>> You are right. Your camera is emitting JPEG while streaming. I just
>>>> succeeded in creating an image which resembles your test picture by
>>>> extracting the frame data for one frame, tacking on a header, and running
>>>> hex2bin on the combined file. I did not get the thing quite right, because
>>>> your header is from your JPEG photo (640x480) and your stream is probably
>>>> 320x240. But I got something out which is obviously recognizable.
>>>
>>> Excellent. Going from "It may never work" to "something recognizable"
>>> in one weekend is good progress.
>>
>> Well, sometimes the easy and obvious just works, and one is lucky. If only
>> they were all that easy.
>
> I'd contend most would be easy and obvious, as anything created by
> people is usually easy to understand. People are generally lazy and
> want to avoid what they perceive as extra effort. If you couple that
> with management pressure on engineers to keep costs down and maintain
> project schedules, you often end up with very simple solutions.
There is some truth to this, yes.
>
> The data encoding used by the camera is indicative of that. For this
> camera, the engineers decided to simply drop the (M)JPEG headers to save
> USB communications bandwidth instead of using a different, better
> compression algorithm; or a imlementing new USB 2.0 interface.
>
>
>> Besides, as we well know, this list is a place
>> where geniuses hang out. So perhaps some of the pixie dust has rubbed off
>> on us.
>
> I thought genius was inspiration and perspiration. Pixie dust - I knew
> Edison wasn't telling the whole truth. ;)
>
>
>
>>>
>>>> Therefore with a little bit of further tweaking it will presumably come
>>>> out exactly so. Namely, I have to remember where to stick the two
>>>> dimensions into the header.
Found that, as I said yesterday evening.
>>>
>>> Yes, as far as I'm concerned the problem is solved. The details are
>>> left as an exercise for the reader. ;)
>>>
>>
>> I will try to get on it. There is nothing left but details, but there are
>> lots of those.
>
> Yes, I agree. Getting those right is no small task.
>
>
>> The first one is to get the header exactly right.
>
> Well, given that the Windows driver has the AVI video stream FourCC
> 'vids' appearing four or five times, I suspect there is more than 1
> header template that the Windows driver can tack on to the incoming
> stream. I'm guessing that which one is used, depends on how the camera
> stream is initialized.
Sort of, yes. At least that is the way it looks over here. The sequence of
button-push steps for initializing my camera to do streaming is just
about the same as that for inducing it to shoot an AVI, and then the
question is whether you turned on capturing from the computer or not. If
you did, then you get a stream. If you didn't then it seems the camera
makes an AVI.
>
> There are probably all sorts of header permutations that will yield
> viewable but suboptimal reconstruction. :(
>
> Then again it's a cheap webcam, so by definition any image is probably
> suboptimal.
Well, interestingly, your header and mine, when affixed to my one frame,
are doing about equally well. But the two headers seem to differ from each
other.
<snip>
>>> I'm not up to speed on Linux webcam kernel to userspace API details.
>>> However, might I suggest going forward for testing at least, that when
>>> one starts the webcam streaming, the driver emit the stream in the form
>>> of an AVI. You'd need an AVI header declaring only an MJPEG 'vids'
>>> stream - no 'auds' nor 'idx' - and a 'movi' section with RIFF/AVI chunks
>>> that have MJPEG headers and the webcam payload.
>>
>> For all I know, it might be just a matter of following down a standard
>> path. Perhaps this is all handled already in libv4lconvert, and it is
>> merely a matter of plugging into that. I haven't checked yet, but that is
>> more or less what I expect right now.
>
>
> Ah, OK.
Revision:
It seems that some other drivers are providing the jpeg header. There is a
file gspca/jpeg.h from which to get it. So perhaps libv4lconvert is not
much involved after all. As I said, I have not yet looked seriously into
this. I spent yesterday evening trying to write a module, with which I
tried to grab a raw frame (no header, no nothing) and it did not succeed.
Clearly, my efforts need to be refined.
>
>>>
>>> I haven't seen evidence that audio comes from the webcam when it is
>>> streaming, but I haven't looked very much either.
>>
>> Same. Actually, my impression is that these cameras can not walk and chew
>> gum at the same time. I would suspect that the audio is an either/or kind
>> of thing. Either on, and it can record audio but not stream it, or off. I
>> would be very surprised if an el cheapo like the one I have could do more.
>> I could be wrong, of course. Perhaps both of us ought to check closely.
>
> I know it can simultaneously record audio and video to an AVI file in
> it's local storage. I'm thinking it would not make sense to shovel over
> audio in webcam mode anyway, as most computers have their own microphone
> to collect sound.
Hmmm. If your cam is working like mine (do the same things, basically, to
shoot an AVI and to stream, I mean), then it probably could do the same
thing while streaming. Could you look into that?
<snip>
>
> I have no timeline in mind. Having this webcam work will simply be a
> "nice to have". I'm available for testing and any
> investigation/research that you don't have time to do.
I don't know how long I can continue to spend so much time on this. There
is the end of the summer session this Friday, with a final exam and grades
to compute. Then as I said we are going on vacation on July 7. After we
are back again, well, then there is time again for this kind of thing.
Theodore Kilgore
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2009-06-23 15:59 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-19 1:40 Sakar 57379 USB Digital Video Camera Andy Walls
2009-06-19 2:43 ` Theodore Kilgore
2009-06-19 4:40 ` Andy Walls
2009-06-19 17:47 ` Theodore Kilgore
2009-06-19 18:16 ` Andy Walls
2009-06-19 20:09 ` Theodore Kilgore
2009-06-20 0:26 ` Theodore Kilgore
2009-06-20 1:54 ` Andy Walls
2009-06-20 4:38 ` Theodore Kilgore
2009-06-20 19:23 ` Andy Walls
2009-06-20 22:48 ` Theodore Kilgore
2009-06-20 22:51 ` Andy Walls
2009-06-21 1:04 ` Theodore Kilgore
2009-06-21 4:19 ` Andy Walls
2009-06-21 15:42 ` Theodore Kilgore
2009-06-22 1:37 ` Andy Walls
2009-06-22 3:39 ` Theodore Kilgore
2009-06-22 11:27 ` Andy Walls
2009-06-22 15:51 ` Theodore Kilgore
2009-06-23 10:37 ` Andy Walls
2009-06-23 16:14 ` Theodore Kilgore
2009-06-22 23:57 ` Theodore Kilgore
2009-06-21 17:12 ` Theodore Kilgore
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.