Re: Sakar 57379 USB Digital Video Camera...
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. 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 thi
Re: Sakar 57379 USB Digital Video Camera...
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 > -- To unsubscribe from this list: send the line "uns
Re: Sakar 57379 USB Digital Video Camera...
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sakar 57379 USB Digital Video Camera...
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sakar 57379 USB Digital Video Camera...
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sakar 57379 USB Digital Video Camera...
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sakar 57379 USB Digital Video Camera...
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:
> >
> > 0d0: 7374 7264 ac00 4a65 696c strdJeil
> > 0e0: 696e 2020 5465 6368 6e6f 6c6f 6779 2043 in Technology C
> > 0f0: 6f2e 2c20 4c74 642e 4a4c 3230 3038 5632 o., Ltd.JL2008V2
> > 100: 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 4.avi | grep -E ' 303[0-2] ((646)|(776))'
> >
> > 1f0: 14fe 0c00 6d6f 7669 3031 7762 401f movi0...@... <--
> > audio
> > 0002140: 3032 6462 0041 ffe2 55aa 0500 02db.AU. <--
> > video
> > 0006250: 3032 6462 0041 ffe2 55aa 0500 0001 02db.AU. <--
> > video
> > 000a360: 3032 6462 0041 ffe2 55aa 0500 0002 02db.AU. <--
> > video
> > 000e470: 3032 6462 0041 ffe2 55aa 0500 0003 02db.AU. <--
> > video
> > 0012580: 3032 6462 0041 ffe2 55aa 0500 0004 02db.AU. <--
> > video
> > 0016690: 3030 6463 281c ffd8 ffe0 0016 4156 00dc(.AV <--
> > compressed video
> > 00182c0: 3030 6463 e81b ffd8 ffe0 0016 4156 00dc..AV <--
> > compressed video
> > 0019eb0: 3030 6463 c81b 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:
> >
> > 00d: 6964 7831 4005 i...@...
> > 00d0010: 3031 7762 0400 401f 01wb@...
> > 00d0020: 3030 6463 1000 9c64 0100 281c 00dc.d..(...
> > 00d0030: 3030 6463 1000 cc80 0100 e81b 00dc
> > 00d0040: 3030 6463 1000 bc9c 0100 c81b 00dc
> > 00d0050: 3030 6463 1000 8cb8 0100 f81b 00dc
> > 00d0060: 3030 6463 1000 8cd4 0100 581c 00dcX...
> >
> >
> > 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 ..=,@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 5
Re: Sakar 57379 USB Digital Video Camera...
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.creverse hexdump Copyright (c) 1996 by Andreas Leitgeb (AvL) 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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sakar 57379 USB Digital Video Camera...
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. : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00 : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00 : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00 : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00 : 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: : 71 81 : 70 05 : 95 70 : 00 : 71 81 : 70 04 : 95 70 : 00 : 71 00 : 70 08 : 95 70 : 00 : 94 02 : de 24 : 94 02 : dd f0 : 94 02 : e3 22 <--- different : 94 02 : e4 00 : 94 02 : e5 00 <--- not repeated like in the sequence above : 94 02 : e6 22 <--- different : 94 03 : aa 01 <--- different : 71 1e : 70 06 : 71 80 : 70 07 And here's the terminal sequence: : 71 00 : 70 09 : 71 80 : 70 05 They look amazingly similar to yours. Here are the buffers with the supposed SOF marker: : ff ff ff ff 00 00 18 43 1e 00 0d fa 00 00 00 00 : ff ff ff ff 00 00 18 26 1e 00 0d 00 00 00 00 00 : ff ff ff ff 00 00 17 fa 1e 00 0c 01 00 00 00 00 : ff ff ff ff 00 00 18 4e 1e 00 0d 02 00 00 00 00 : ff ff ff ff 00 00 18 91 1e 00 0d 03 00 00 00 00 : ff ff ff ff 00 00 18 90 1e 00 0d 04 00 00 00 00 : ff ff ff ff 00 00 18 4b 1e 00 0d 05 00 00 00 00 : 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: 0d0: 7374 7264 ac00 4a65 696c strdJeil 0e0: 696e 2020 5465 6368 6e6f 6c6f 6779 2043 in Technology C 0f0: 6f2e 2c20 4c74 642e 4a4c 3230 3038 5632 o., Ltd.JL2008V2 100: 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 4.avi | grep -E ' 303[0-2] ((646)|(776))' 1f0: 14fe 0c00 6d6f 7669 3031 7762 401f movi0...@... <-- audio 0002140: 3032 6462 0041 ffe2 55aa 0500 02db.AU. <-- video 0006250: 3032 6462 0041 ffe2 55aa 0500 0001 02db.AU. <-- video 000a360: 3032 6462 0041 ffe2 55aa 0500 0002 02db.AU. <-- video 000e470: 3032 6462 0041 ffe2 55aa 0500 0003 02db.AU. <-- video 0012580: 3032 6462 0041 ffe2 55aa 0500 0004 02db.AU. <-- video 0016690: 3030 6463 281c ffd8 ffe
Re: Sakar 57379 USB Digital Video Camera...
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. > >>> > >>> : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00 > >>> : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00 > >>> : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00 > >>> : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00 > >>> : 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: > > > > : 71 81 > > : 70 05 > > : 95 70 > > : 00 > > : 71 81 > > : 70 04 > > : 95 70 > > : 00 > > : 71 00 > > : 70 08 > > : 95 70 > > : 00 > > : 94 02 > > : de 24 > > : 94 02 > > : dd f0 > > : 94 02 > > : e3 22 <--- different > > : 94 02 > > : e4 00 > > : 94 02 > > : e5 00 <--- not repeated like in the sequence above > > : 94 02 > > : e6 22 <--- different > > : 94 03 > > : aa 01 <--- different > > : 71 1e > > : 70 06 > > : 71 80 > > : 70 07 > > > > And here's the terminal sequence: > > > > : 71 00 > > : 70 09 > > : 71 80 > > : 70 05 > > > > They look amazingly similar to yours. > > > > Here are the buffers with the supposed SOF marker: > > > > : ff ff ff ff 00 00 18 43 1e 00 0d fa 00 00 00 00 > > : ff ff ff ff 00 00 18 26 1e 00 0d 00 00 00 00 00 > > : ff ff ff ff 00 00 17 fa 1e 00 0c 01 00 00 00 00 > > : ff ff ff ff 00 00 18 4e 1e 00 0d 02 00 00 00 00 > > : ff ff ff ff 00 00 18 91 1e 00 0d 03 00 00 00 00 > > : ff ff ff ff 00 00 18 90 1e 00 0d 04 00 00 00 00 > > : ff ff ff ff 00 00 18 4b 1e 00 0d 05 00 00 00 00 > > : 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: 0d0: 7374 7264 ac00 4a65 696c strdJeil 0e0: 696e 2020 5465 6368 6e6f 6c6f 6779 2043 in Technology C 0f0: 6f2e 2c20 4c74 642e 4a4c 3230 3038 5632 o., Ltd.JL2008V2 100: 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 4.avi | grep -E ' 303[0-2] ((646)|(776))' 1f0: 14fe 0c00 6d6f 7669 3031 7762 401f movi0...@... <-- audio 0002140: 3032 6462 0041 ffe2 55aa 0500 02db.AU. <-- video
Re: Sakar 57379 USB Digital Video Camera...
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. H. 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 : 71 81 : 70 05 : 95 70 : 00 (all the 00 are responses) : 71 81 : 70 04 : 95 70 : 00 : 71 00 : 70 08 : 95 70 : 00 : 94 02 : de 24 : 94 02 : dd f0 : 94 02 : e3 2c : 94 02 : e4 00 : 94 02 : e5 00 : e5 00 : 94 02 : e6 2c : 94 03 : aa 00 : 71 1e : 70 06 : 71 80 : 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. : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00 : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00 : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00 : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00 : 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. : 71 00 : 70 09 : 71 80 : 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 c
Re: Sakar 57379 USB Digital Video Camera...
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. > > > > > > H. 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 > > >> > > >> : 71 81 > > >> : 70 05 > > >> : 95 70 > > >> : 00(all the 00 are responses) > > >> : 71 81 > > >> : 70 04 > > >> : 95 70 > > >> : 00 > > >> : 71 00 > > >> : 70 08 > > >> : 95 70 > > >> : 00 > > >> : 94 02 > > >> : de 24 > > >> : 94 02 > > >> : dd f0 > > >> : 94 02 > > >> : e3 2c > > >> : 94 02 > > >> : e4 00 > > >> : 94 02 > > >> : e5 00 > > >> : e5 00 > > >> : 94 02 > > >> : e6 2c > > >> : 94 03 > > >> : aa 00 > > >> : 71 1e > > >> : 70 06 > > >> : 71 80 > > >> : 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. > > > > : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00 > > : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00 > > : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00 > > : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00 > > : 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 p
Re: Sakar 57379 USB Digital Video Camera...
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. H. 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. 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. : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00 : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00 : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00 : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00 : ff ff ff ff 00 00 35 84 1e 00 1b 09 00 00 00 00
Re: Sakar 57379 USB Digital Video Camera...
On Fri, 2009-06-19 at 23:38 -0500, Theodore Kilgore wrote: > >> > >> Now it is using the other pair of endpoints, 0x03 and 0x84. > > > > H. 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 > >> > >> : 71 81 > >> : 70 05 > >> : 95 70 > >> : 00 (all the 00 are responses) > >> : 71 81 > >> : 70 04 > >> : 95 70 > >> : 00 > >> : 71 00 > >> : 70 08 > >> : 95 70 > >> : 00 > >> : 94 02 > >> : de 24 > >> : 94 02 > >> : dd f0 > >> : 94 02 > >> : e3 2c > >> : 94 02 > >> : e4 00 > >> : 94 02 > >> : e5 00 > >> : e5 00 > >> : 94 02 > >> : e6 2c > >> : 94 03 > >> : aa 00 > >> : 71 1e > >> : 70 06 > >> : 71 80 > >> : 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. > > : ff ff ff ff 00 00 1c 70 3c 00 0f 01 00 00 00 00 > : ff ff ff ff 00 00 34 59 1e 00 1b 06 00 00 00 00 > : ff ff ff ff 00 00 36 89 1e 00 1c 07 00 00 00 00 > : ff ff ff ff 00 00 35 fc 1e 00 1b 08 00 00 00 00 > : 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. > >> > >> : 71 00 > >> : 70 09 > >> : 71 80 > >> : 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 a
Re: Sakar 57379 USB Digital Video Camera...
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 * 1.jpg: JPEG image data, EXIF standard 2.2 2.jpg: JPEG image data, EXIF standard 2.2 3.jpg: JPEG image data, EXIF standard 2.2 4.avi: RIFF (little-endian) data, AVI, 320 x 240, 20.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 8000 Hz) 5.jpg: JPEG image data, EXIF standard 2.2 6.jpg: JPEG image data, EXIF standard 2.2 7.jpg: JPEG image data, EXIF standard 2.2 8.jpg: JPEG image data, EXIF standard 2.2 9.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 b
Re: Sakar 57379 USB Digital Video Camera...
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 * 1.jpg: JPEG image data, EXIF standard 2.2 2.jpg: JPEG image data, EXIF standard 2.2 3.jpg: JPEG image data, EXIF standard 2.2 4.avi: RIFF (little-endian) data, AVI, 320 x 240, 20.00 fps, video: Motion JPEG, audio: uncompressed PCM (mono, 8000 Hz) 5.jpg: JPEG image data, EXIF standard 2.2 6.jpg: JPEG image data, EXIF standard 2.2 7.jpg: JPEG image data, EXIF standard 2.2 8.jpg: JPEG image data, EXIF standard 2.2 9.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 #Cfg
Re: Sakar 57379 USB Digital Video Camera...
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 : 71 81 : 70 05 : 95 70 : 00(all the 00 are responses) : 71 81 : 70 04 : 95 70 : 00 : 71 00 : 70 08 : 95 70 : 00 : 94 02 : de 24 : 94 02 : dd f0 : 94 02 : e3 2c : 94 02 : e4 00 : 94 02 : e5 00 : e5 00 : 94 02 : e6 2c : 94 03 : aa 00 : 71 1e : 70 06 : 71 80 : 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 : 71 00 : 70 09 : 71 80 : 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
Re: Sakar 57379 USB Digital Video Camera...
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at htt
Re: Sakar 57379 USB Digital Video Camera...
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sakar 57379 USB Digital Video Camera...
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sakar 57379 USB Digital Video Camera...
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Sakar 57379 USB Digital Video Camera...
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: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0979 Jeilin Technology Corp., Ltd idProduct 0x0371 bcdDevice1.00 iManufacturer 1 Jeilin iProduct2 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 bInterfaceNumber0 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 bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 0 Device Status: 0x (Bus Powered) Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0979 Jeilin Technology Corp., Ltd idProduct 0x0280 bcdDevice1.00 iManufacturer 1 Jeilin iProduct2 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 bInterfaceNumber0 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 bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0
Sakar 57379 USB Digital Video Camera...
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: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0979 Jeilin Technology Corp., Ltd idProduct 0x0371 bcdDevice1.00 iManufacturer 1 Jeilin iProduct2 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 bInterfaceNumber0 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 bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 0 Device Status: 0x (Bus Powered) Webcam mode: Bus 003 Device 005: ID 0979:0280 Jeilin Technology Corp., Ltd Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x0979 Jeilin Technology Corp., Ltd idProduct 0x0280 bcdDevice1.00 iManufacturer 1 Jeilin iProduct2 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 bInterfaceNumber0 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 bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type
