http://permalink.gmane.org/gmane.comp.video.video4linux hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.video.video4linux/41327 Anything is better than a 1800 that I can get no support on for Analog, other than someone always saying "It works for me". I just picked one up on Newegg for $79 w/ free shipping. Hopefully it gets here soon. -Mark -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Mark Jenks 2008-12-04T03:17:35 http://permalink.gmane.org/gmane.comp.video.video4linux/41326 Mark, Just to manage expectations, you may want to read the ivtv-users and ivtv-driver mailing list archive for the past month or so. Some users have absolutely no problems. Others have noticed some audio or video playback annoyances with analog captures (which I am working to get resolved). Personally, I like my HVR-1600's and don't have problems with analog and digital tuner captures. I don't use S-Video or CVBS composite regularly. You will need to do buffered playback, which MythTV does always, and mplayer does when you use the '-cache 8192' commandline option. (I'm hoping to resolve the need for that too.) NewEgg or e-Bay. :) Regards, Andy -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Andy Walls 2008-12-04T02:50:12 http://permalink.gmane.org/gmane.comp.video.video4linux/41325 Hi Antonio, The problem comes from the availability of the application buffer. In the bulk_irq, there is: frame = gspca_get_i_frame(gspca_dev); if (!frame) { gspca_dev->last_packet_type = DISCARD_PACKET; } else { .. pkt_scan(..); } Then, you are not called and you cannot know how many bytes have been really received. As the buffer check exists in frame_add, I may call you each time with a valid frame pointer (see patch). In this case, you cannot count the image bytes with the data_end. You should have a counter in the sd structure. An other solution is to start and stop the transfer for each image as it was in the original driver, but it asks for a kernel thread. Anyway, if Jim may add a mark between the images, if will be the best... Cheers. Jean-Francois Moine 2008-12-03T19:17:20 http://permalink.gmane.org/gmane.comp.video.video4linux/41324 No, that does not matter, as long as you can catch a mpeg stream, it should work just fine. I already have 1394 channel changing working without a hitch. Time to hunt out a 1600. -Mark -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Mark Jenks 2008-12-04T01:12:18 http://permalink.gmane.org/gmane.comp.video.video4linux/41322 # HG changeset patch # User jim< at >jtan.com # Date 1228335450 18000 # Node ID ede2dd835a2086131584558f5ccb1e2170135b07 # Parent 61c8d2959dd6ad1b45e0d8bf12b3d5748fc6a568 ov534: frame transfer improvements The indirect registers at 0x1c/0x1d control frame settings. If we leave the values at 0x0a and 0x0b at their reset-time defaults, frame data from the camera matches the UVC payload format. This lets us better reassemble the data into frames and know when data was lost. This also lets us relax the bulk_size requirement from 600K to 2K, which should help systems on with limited RAM (like the PS3). Signed-off-by: Jim Paris <jim< at >jtan.com> diff -r 61c8d2959dd6 -r ede2dd835a20 linux/drivers/media/video/gspca/ov534.c --- a/linux/drivers/media/video/gspca/ov534.cWed Dec 03 15:07:30 2008 -0500 +++ b/linux/drivers/media/video/gspca/ov534.cWed Dec 03 15:17:30 2008 -0500 < at >< at > -166,10 +166,6 < at >< at > { 0xe2, 0x00 }, { 0xe7, 0x3e }, -{ 0x1c, 0x0a }, -{ 0x1d, 0x22 }, -{ 0x1d, 0x06 }, - { 0x96, 0x00 }, { 0x97, Jim Paris 2008-12-03T20:47:03 http://permalink.gmane.org/gmane.comp.video.video4linux/41321 # HG changeset patch # User jim< at >jtan.com # Date 1228334850 18000 # Node ID 61c8d2959dd6ad1b45e0d8bf12b3d5748fc6a568 # Parent 893107a5df87228bb6766f26226fcef8069e3fc8 ov534: Fix frame size so we don't miss the last pixel The frame size is too small, so we lose the last YUYV pixel. Fix the setup and remove the last_pixel hack. Signed-off-by: Jim Paris <jim< at >jtan.com> diff -r 893107a5df87 -r 61c8d2959dd6 linux/drivers/media/video/gspca/ov534.c --- a/linux/drivers/media/video/gspca/ov534.cWed Dec 03 15:06:54 2008 -0500 +++ b/linux/drivers/media/video/gspca/ov534.cWed Dec 03 15:07:30 2008 -0500 < at >< at > -198,9 +198,9 < at >< at > { 0x1d, 0x40 }, { 0x1d, 0x02 }, { 0x1d, 0x00 }, -{ 0x1d, 0x02 }, -{ 0x1d, 0x57 }, -{ 0x1d, 0xff }, +{ 0x1d, 0x02 }, /* frame size 0x025800 * 4 = 614400 */ +{ 0x1d, 0x58 }, /* frame size */ +{ 0x1d, 0x00 }, /* frame size */ { 0x8d, 0x1c }, { 0x8e, 0x80 }, < at >< at > -398,19 +398,12 < at >< at > static void sd_pkt_scan(struct gspca_dev *gspca_dev, struct gspca_frame *frame, __u8 *data, int len) Jim Paris 2008-12-03T20:47:02 http://permalink.gmane.org/gmane.comp.video.video4linux/41320 # HG changeset patch # User jim< at >jtan.com # Date 1228334704 18000 # Node ID fa4fcbdb237a065c4033bd51be28fa9da9016cef # Parent ee27d949bfa5e050f858b5bae4cc9a050ff5b119 ov534: don't check status twice sccb_reg_write already calls sccb_check_status, no need to do it again. Signed-off-by: Jim Paris <jim< at >jtan.com> diff -r ee27d949bfa5 -r fa4fcbdb237a linux/drivers/media/video/gspca/ov534.c --- a/linux/drivers/media/video/gspca/ov534.cTue Dec 02 19:00:57 2008 +0100 +++ b/linux/drivers/media/video/gspca/ov534.cWed Dec 03 15:05:04 2008 -0500 < at >< at > -369,31 +369,23 < at >< at > switch (sd->frame_rate) { case 50: sccb_reg_write(gspca_dev->dev, 0x11, 0x01); -sccb_check_status(gspca_dev->dev); sccb_reg_write(gspca_dev->dev, 0x0d, 0x41); -sccb_check_status(gspca_dev->dev); ov534_reg_verify_write(gspca_dev->dev, 0xe5, 0x02); break; case 40: sccb_reg_write(gspca_dev->dev, 0x11, 0x02); -sccb_check_status(gspca_dev->dev); sccb_reg_write(gspca_dev->dev, 0x0d, 0xc1); -sccb_check_status(gspca_dev->dev); Jim Paris 2008-12-03T20:47:00 http://permalink.gmane.org/gmane.comp.video.video4linux/41319 # HG changeset patch # User jim< at >jtan.com # Date 1228334814 18000 # Node ID 893107a5df87228bb6766f26226fcef8069e3fc8 # Parent fa4fcbdb237a065c4033bd51be28fa9da9016cef ov534: initialization cleanup Clean up bridge and sensor chip initialization by putting initial register values in arrays rather than open-coding calls to *_reg_write. Also remove ov534_reg_verify_write, as the verify step doesn't appear necessary. The order of some writes was rearranged and some duplicate writes were removed, but the camera behavior is unchanged. Signed-off-by: Jim Paris <jim< at >jtan.com> diff -r fa4fcbdb237a -r 893107a5df87 linux/drivers/media/video/gspca/ov534.c --- a/linux/drivers/media/video/gspca/ov534.cWed Dec 03 15:05:04 2008 -0500 +++ b/linux/drivers/media/video/gspca/ov534.cWed Dec 03 15:06:54 2008 -0500 < at >< at > -94,19 +94,6 < at >< at > return data; } -static void ov534_reg_verify_write(struct usb_device *udev, u16 reg, u16 val) -{ -u16 data; - -ov534_reg_write(udev, reg, val); -data = ov534_reg_read(udev, reg); -if (d Jim Paris 2008-12-03T20:47:01 http://permalink.gmane.org/gmane.comp.video.video4linux/41318 Hi, Here are some ov534 patches I've been working on. ov534: don't check status twice ov534: initialization cleanup ov534: Fix frame size so we don't miss the last pixel ov534: frame transfer improvements -jim -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Jim Paris 2008-12-03T20:46:59 http://permalink.gmane.org/gmane.comp.video.video4linux/41317 I run three of them using DCT700 set top boxes on Verizon FiOS. (Note: I use CommandIR II for control) via svideo and r/l minijack inputs. This is in SageTV though, if that matters. Brandon -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Brandon Jenkins 2008-12-03T20:45:05 http://permalink.gmane.org/gmane.comp.video.video4linux/41316 -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Antonio Ospite 2008-12-03T18:51:37 http://permalink.gmane.org/gmane.comp.video.video4linux/41315 -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Antonio Ospite 2008-12-03T18:44:26 http://permalink.gmane.org/gmane.comp.video.video4linux/41314 Mauro, Please pull from http://linuxtv.org/hg/~tlorenz/v4l-dvb for the following changeset: 01/01: Add USB ID for the Sil4701 radio from DealExtreme. http://linuxtv.org/hg/~tlorenz/v4l-dvb?cmd=changeset;node=42f57f457d9d3a91d5f3966b59bfa87679ecb1c7 Documentation/video4linux/si470x.txt | 1 + drivers/media/radio/radio-si470x.c | 4 ++++ 2 files changed, 5 insertions(+) Thanks, Tobias -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Tobias Lorenz 2008-12-03T18:29:12 http://permalink.gmane.org/gmane.comp.video.video4linux/41312 Hi Antonio, Antonio Ospite wrote: Such a large bulk_size is probably not a good idea on any system. The PS3 in particular is already memory constrained so it's definitely a good idea to break that up. ... If gspca decides to discard a frame with DISCARD_PACKET, I believe it won't start working again until you send another FIRST_PACKET. In your code, if DISCARD_PACKET ever happens, the frame->data pointers won't get updated so you'll never get to FIRST_PACKET? Hold off a bit on this work. There's a problem with breaking up the transfers, because we're not currently getting any header data from the bridge chip that lets us know when we really hit the end of a frame, and it's easy to get out of sync. Using (len < bulk_size) is a good trick if they're not a multiple, as you say, since the last payload will be shorter, but I have a better solution -- I found how to get the camera to add a UVC-format header on each payload. I'm finishing up the patch and will post it a bit later today once I iron out a f Jim Paris 2008-12-03T18:01:28 http://permalink.gmane.org/gmane.comp.video.video4linux/41311 -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Antonio Ospite 2008-12-03T16:45:28 http://permalink.gmane.org/gmane.comp.video.video4linux/41310 Hello people, I'm w/ a problem for capturing VBI data (closed caption) using a Pinnacle PCTV (worked w/ some older kernel). Using the sliced-vbi-test.c (inside v4l2-apps/test), I get the error in the following ioctl: ioctl(fh, VIDIOC_S_FMT, &fmt); vbi: Invalid argument What function handles that ioctl? I'm looking at linux/drivers/media/video/saa7134 directory, but I could not figure out what function takes care of the VIDIOC_S_FMT ioctl. Thanks, Rafael Diniz WiMobilis -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Rafael Diniz 2008-12-03T15:12:11 http://permalink.gmane.org/gmane.comp.video.video4linux/41309 About processing some frames from static void process_image (const void * p, unsigned int size) I did some conversion from const void * p TO char * to treat buffers. But I would like opinion about conversion from : const void * p TO int [] because I am using a JNI entry point for my V4L2 C and would like to compare values between 0-255 but if u do something like char 4 - char 5 this will not turn -1 this will turn 255. And inside java I don't want to cast values and prefer to work with proper int types. -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Jonathan Lafontaine 2008-12-03T13:43:33 http://permalink.gmane.org/gmane.comp.video.video4linux/41308 No, I don't need PCI, PCIe is just what I had room for and bought it. The Backend is sitting in a media closet, so it's a fullsize case. ;) So, with the 1600, Svideo in, w/ Audio interleaved in mpg format, you say it works? Can anyone verify this, before I go out and purchase this, or a PVR-250. -Mark -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Mark Jenks 2008-12-03T12:09:59 http://permalink.gmane.org/gmane.comp.video.video4linux/41306 Thanks, Vaibhav Hiremath [Hiremath, Vaibhav] yes, but the DSS2 library goes under arch/arm/plat-omap/dss/. The above files are belongs to the driver underneath. -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request< at >redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list Hiremath, Vaibhav 2008-12-03T09:37:38 http://permalink.gmane.org/gmane.comp.video.video4linux/41304 -----Original Message----- From: Thierry Merle [mailto:thierry.merle< at >free.fr] Sent: 03 December 2008 06:26 To: Chris Grove Cc: video4linux-list< at >redhat.com Subject: Re: Hauppauge WinTV USB Model 566 PAL-I Chris Grove a écrit : Argh yes, linux-2.6.21.3 is a quite old kernel; these options were not yet implemented. Can you run a more recent version of Geexbox? I saw on their site that the latest version includes 2.6.27.4 kernel. Otherwise you will need a recompilation of the driver. Thierry Eeek, I was trying not to upgrade to the next version of Geexbox as it still has many bugs and I don't really want to add X.org as I'm trying to keep processor down to a minimum. Recompiling the drivers sounds better as I've already managed to recompile the kernel a few times. Is there any chance you could give me instructions on upgrading the driver please?? I'm guessing it's not as easy as just copying the sources into the Usbvision folder, although I might be wrong. -- video4linux-list mailing list Unsubscribe mailt Chris Grove 2008-12-03T09:03:51 http://permalink.gmane.org/gmane.comp.video.video4linux/41303 Guennadi Liakhovetski wrote: Done. Signed-off-by: Mike Rapoport <mike< at >compulab.co.il> drivers/media/video/Kconfig | 4 ++-- drivers/media/video/mt9m111.c | 28 ++++++++++++++++------------ 2 files changed, 18 insertions(+), 14 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 47102c2..0848032 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig < at >< at > -725,10 +725,10 < at >< at > config MT9M001_PCA9536_SWITCH extender to switch between 8 and 10 bit datawidth modes config SOC_CAMERA_MT9M111 -tristate "mt9m111 support" +tristate "mt9m111 and mt9m112 support" depends on SOC_CAMERA && I2C help - This driver supports MT9M111 cameras from Micron + This driver supports MT9M111 and MT9M112 cameras from Micron config SOC_CAMERA_MT9V022 tristate "mt9v022 support" diff --git a/drivers/media/video/mt9m111.c b/drivers/media/video/mt9m111.c index da0b2d5..ac48001 100644 --- a/drivers/media/video/mt9m111.c +++ b/drivers/media/video/mt9m111.c < at > Mike Rapoport 2008-12-03T08:23:49 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.video.video4linux