Re: libv4l2 library problem
On Fri, 13 Feb 2009 13:57:45 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Hans, I've developed a converter for the HM12 format (produced by Conexant MPEG encoders as used in the ivtv and cx18 drivers). But libv4l2 has a problem in its implementation of v4l2_read: it assumes that the driver can always do streaming. However, that is not the case for some drivers, including cx18 and ivtv. These drivers only implement read() functionality and no streaming. Can you as a minimum modify libv4l2 so that it will check for this case? The best solution would be that libv4l2 can read HM12 from the driver and convert it on the fly. But currently it tries to convert HM12 by starting to stream, and that produces an error. This bug needs to be fixed first before I can contribute my HM12 converter. Hans Verkuil, I think it would be valuable if you could convert the drivers to use videobuf. There's currently a videobuf variation for devices that don't support scatter/gather dma transfers. By using videobuf, the mmap() methods (and also overlay, if you want) will be supported. Cheers, Mauro -- 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: RFC: Finalizing the V4L2 RDS interface
On Saturday 14 February 2009 01:42:31 Trent Piepho wrote: On Fri, 13 Feb 2009, Hans Verkuil wrote: On Friday 13 February 2009 22:15:45 Mauro Carvalho Chehab wrote: On Fri, 13 Feb 2009 09:55:19 +0100 The V4L API defines its RDS API as follows. From radio devices supporting it, RDS data can be read with the read() function. The data is packed in groups of three, as follows: First Octet: Least Significant Byte of RDS Block Second Octet: Most Significant Byte of RDS Block Third Octet: Bit 7: Error bit. Indicates that an uncorrectable error occurred during reception of this block. Bit 6: Corrected bit. Indicates that an error was corrected for this data block. Bits 5-3: Received Offset. Indicates the offset received by the sync system. Bits 2-0: Offset Name. Indicates the offset applied to this data. What device file does one read from, the radio device or is there another one for RDS data? The radio device. If the radio device, then maybe it should handle (S|G|TRY)_FMT ioctls, so that one can select the format. Since the drivers probably already use v4l2_ioctl, this should be easy enough to do. Some hardware might produce at a higher or lower level in the decoding stack that just doesn't fit this format. For instance, the common cx88 chip has some sort of RDS decoding ability. I think it returns 36 kHz 16 bit I/Q data from the RDS carrier that something like gnuradio would need to demodulate. That's a completely different format that this one. Though I think it might make more sense to use ALSA to get data in this format. Hmm, basically raw RDS data. Interesting. I'll look into this. It certainly makes it a lot more future-proof by using the FMT ioctls. And we can add support to select RDS/RDBS by using one of the reserved fields: __u8rds_type; __u8rds_signal; /* RDS signal strength quality, 0-255 */ __u8rds_reserved[2]; __u32 reserved[3]; Do any devices support returning signal strength or quality? If so, can we get real units from them? The saa6588 support has a register containing the signal quality, but there are no units attached to that. Just a value 0-15. And rds_type is: V4L2_TUNER_RDS_TYPE_RDS 0x00 V4L2_TUNER_RDS_TYPE_RBDS 0x01 Is it necessary to make a distinction between RDS and RBDS? I need to do a bit more research, but I'm fairly confident that the answer is yes. The saa6588 requires you to set it, the si470x seems to handle only the RDS subset of RBDS (no support for block E as far as I could see). Note that I modified the types to: V4L2_TUNER_RDS_TYPE_NONE 0x00 V4L2_TUNER_RDS_TYPE_RDS 0x01 V4L2_TUNER_RDS_TYPE_RBDS 0x02 This field is currently always 0, so that should indicate no RDS. In addition, it might be useful to have the option to turn off RDS decoding to save resources if you do not need it. Finally I would prefer to have the requirement that the driver will buffer at least 10 seconds worth of data (comes to 1200 bytes). Why? IMO, this seems to be something that should be a requirement at user side, not at kernel side: After changing from one station to another, and start receiving RDS/RBDS, wait for some time before output the data. Or perhaps we should add a field that reports the maximum number of buffered packets? E.g. __u16 rds_buf_size. This might be more generic and you can even allow this to be set with VIDIOC_S_TUNER (although drivers can ignore it). Why to spend 16 bits for it? It seems easier to check for for the amount of received packets on userspace. I think we should avoid to waste those reserved bytes. Hmm, I'm too creative here, I agree. Let's keep it simple. It would nice if there was a way to flush the buffer. When changing channels, I imaging software would like to be sure that it does not receive stale data from the previous channel. Maybe just define that changing frequencies empties the buffer? Keep in mind, there could be data sitting in an on card buffer waiting for DMA, or DMAed data waiting for the IRQ handler to processes it. So just calling read() could easily not give you all data received prior to calling read(). Good point. Changing frequencies or input should flush any internal buffers. I think that it is overkill to add an option to explicitly flush buffers. It can always be added later if needed. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [linux-dvb] Mantis Update was Re: Twinhan DTV Ter-CI (3030 Mantis) ???
Carl Oscar Ejwertz wrote: Sad to say that I still get the same error after a fresh clone and compile. Is there any info that I can supply that can help getting this card working? What's the error that you see ? Did a quick test on the following cards: VP-1041, VP-2033, VP-3030 The logs look as follows, do you see any different ? Regards, Manu found a VP-1041 PCI DSS/DVB-S/DVB-S2 device on (04:04.0), ACPI: PCI Interrupt :04:04.0[A] - GSI 22 (level, low) - IRQ 22 Mantis Rev 1 [1822:0031], irq: 22, latency: 32 memory: 0x0, mmio: 0xf93aa000 mantis_stream_control (0): Set stream to HIF mantis_i2c_init (0): Initializing I2C .. mantis_i2c_init (0): Disabling I2C interrupt mantis_i2c_xfer (0): Messages:2 mantis_i2c_write: Address=[0x50] W[ 08 ] mantis_i2c_read: Address=[0x50] R[ 00 08 ca 1c 42 c9 ] MAC Address=[00:08:ca:1c:42:c9] mantis_dma_init (0): Mantis DMA init mantis_alloc_buffers (0): DMA=0x325c cpu=0xf25c size=65536 mantis_alloc_buffers (0): RISC=0x32463000 cpu=0xf2463000 size=1000 mantis_calc_lines (0): Mantis RISC block bytes=[4096], line bytes=[2048], line count=[32] mantis_dvb_init (0): dvb_register_adapter DVB: registering new adapter (Mantis DVB adapter) mantis_dvb_init (0): dvb_dmx_init mantis_dvb_init (0): dvb_dmxdev_init mantis_frontend_power (0): Power ON gpio_set_bits (0): Set Bit 12 to 1 gpio_set_bits (0): GPIO Value 1000 gpio_set_bits (0): Set Bit 12 to 1 gpio_set_bits (0): GPIO Value 1000 mantis_frontend_soft_reset (0): Frontend RESET gpio_set_bits (0): Set Bit 13 to 0 gpio_set_bits (0): GPIO Value 1000 gpio_set_bits (0): Set Bit 13 to 0 gpio_set_bits (0): GPIO Value 1000 gpio_set_bits (0): Set Bit 13 to 1 gpio_set_bits (0): GPIO Value 3000 gpio_set_bits (0): Set Bit 13 to 1 gpio_set_bits (0): GPIO Value 3000 stb0899_write_regs [0xf1b6]: 02 mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f1 b6 02 ] stb0899_write_regs [0xf1c2]: 00 mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f1 c2 00 ] stb0899_write_regs [0xf1c3]: 00 mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f1 c3 00 ] mantis_i2c_xfer (0): Messages:2 mantis_i2c_write: Address=[0x68] W[ f0 00 ] mantis_i2c_read: Address=[0x68] R[ 82 ] _stb0899_read_reg: Reg=[0xf000], data=82 stb0899_get_dev_id: ID reg=[0x82] stb0899_get_dev_id: Device ID=[8], Release=[2] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f3 fc 00 04 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f3 34 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 31 44 4d 44 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f3 34 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 31 44 4d 44 ] _stb0899_read_s2reg Device=[0xf3fc], Base address=[0x0400], Offset=[0xf334], Data=[0x444d4431] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f3 fc 00 04 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f3 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 01 00 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ f3 3c ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 01 00 00 00 ] _stb0899_read_s2reg Device=[0xf3fc], Base address=[0x0400], Offset=[0xf33c], Data=[0x0001] stb0899_get_dev_id: Demodulator Core ID=[DMD1], Version=[1] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ fa fc 00 08 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ fa 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 4c 00 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ fa 2c ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 31 43 45 46 ] _stb0899_read_s2reg Device=[0xfafc], Base address=[0x0800], Offset=[0xfa2c], Data=[0x46454331] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ fa fc 00 08 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ fa 34 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 01 00 00 00 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x68] W[ fa 34 ] mantis_i2c_xfer (0): Messages:1 mantis_i2c_read: Address=[0x68] R[ 01 00 00 00 ] _stb0899_read_s2reg Device=[0xfafc], Base address=[0x0800], Offset=[0xfa34], Data=[0x0001] stb0899_get_dev_id: FEC Core ID=[FEC1], Version=[1] stb0899_attach: Attaching STB0899 vp1041_frontend_init (0): found STB0899 DVB-S/DVB-S2 frontend @0x68 stb6100_attach: Attaching STB6100 mantis_i2c_xfer (0): Messages:1 mantis_i2c_write: Address=[0x08] W[ 40 ] vp1041_frontend_init (0): Done! DVB: registering frontend 0 (STB0899
Re: libv4l2 library problem
On Sat, 14 Feb 2009 10:08:31 +0100 Hans Verkuil hverk...@xs4all.nl wrote: On Saturday 14 February 2009 09:52:06 Mauro Carvalho Chehab wrote: On Fri, 13 Feb 2009 13:57:45 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Hans, I've developed a converter for the HM12 format (produced by Conexant MPEG encoders as used in the ivtv and cx18 drivers). But libv4l2 has a problem in its implementation of v4l2_read: it assumes that the driver can always do streaming. However, that is not the case for some drivers, including cx18 and ivtv. These drivers only implement read() functionality and no streaming. Can you as a minimum modify libv4l2 so that it will check for this case? The best solution would be that libv4l2 can read HM12 from the driver and convert it on the fly. But currently it tries to convert HM12 by starting to stream, and that produces an error. This bug needs to be fixed first before I can contribute my HM12 converter. Hans Verkuil, I think it would be valuable if you could convert the drivers to use videobuf. There's currently a videobuf variation for devices that don't support scatter/gather dma transfers. By using videobuf, the mmap() methods (and also overlay, if you want) will be supported. It's been on my todo list for ages, but I don't see it happening anytime soon. It will be difficult to do and the simple fact of the matter is that the read() interface is much more suitable for MPEG streams than mmap, and almost nobody is using the raw video streams where mmap would make sense. The only reason for doing this would be to make the driver consistent with the other drivers in V4L2. Which is a valid argument, but as long as we still have V4L1 drivers to convert I'd argue that this is definitely a low prio task. I suspect that the only two drivers that don't support mmap() are ivtv and cx18. All other drivers support it, including other drivers that also provides compressed data (like jpeg webcams). In a matter of fact, most applications work only with mmap() interface (being mythtv and mplayer capable of supporting both read() and mmap()). So, by providing mmap(), other applications will benefit of it. Also, there is a sort of chicken and egg trouble: almost nobody uses raw formats, since it uses a non-standard format that it is not supported by userspace apps. The libv4l2 is the proper way for handling it, but only works with mmap(). The usage of read() for raw formats is possible, but, read() method doesn't provide any meta-data info. For example, there's no timestamp that would be useful for syncing audio and video and detect frame losses. Also, if, for some reason, you loose a half frame, the result would be a disaster if you're using the read() method. So, IMO, adding read() support to libv4l2 would be just a hack and will likely cause more troubles than benefits. This is just my 2 cents. BTW, it would help if someone would actually document videobuf. Documentation should be much more important than it currently is. Videobuf usage is not that complicate. You just need to provide ops for four handlers: q-ops-buf_setup - calculates the size of the video buffers and avoid they to waste more than some maximum limit of RAM; q-ops-buf_prepare - fills the video buffer structs and calls videobuf_iolock() to alloc and prepare mmaped memory; q-ops-buf_queue - advices the driver that another buffer were requested (by read() or by QBUF); q-ops-buf_release - frees any buffer that were allocated. In order to use it, the driver need to have a code (generally called at interrupt context) that will properly handle the buffer request lists, announcing that a new buffer were filled. There are a number of videobuf methods that practically matches the video buffer ioctls. for example videobuf_streamon() should be called for streaming the video on (VIDIOC_STREAMON). The better way to understand it is to take a look at vivi driver. Anyway, I just documented it, from the driver authors POV: http://linuxtv.org/hg/v4l-dvb/rev/6f4cff0e7f16 Cheers, Mauro -- 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: libv4l2 library problem
On Saturday 14 February 2009 11:32:06 Mauro Carvalho Chehab wrote: On Sat, 14 Feb 2009 10:08:31 +0100 Hans Verkuil hverk...@xs4all.nl wrote: On Saturday 14 February 2009 09:52:06 Mauro Carvalho Chehab wrote: On Fri, 13 Feb 2009 13:57:45 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Hans, I've developed a converter for the HM12 format (produced by Conexant MPEG encoders as used in the ivtv and cx18 drivers). But libv4l2 has a problem in its implementation of v4l2_read: it assumes that the driver can always do streaming. However, that is not the case for some drivers, including cx18 and ivtv. These drivers only implement read() functionality and no streaming. Can you as a minimum modify libv4l2 so that it will check for this case? The best solution would be that libv4l2 can read HM12 from the driver and convert it on the fly. But currently it tries to convert HM12 by starting to stream, and that produces an error. This bug needs to be fixed first before I can contribute my HM12 converter. Hans Verkuil, I think it would be valuable if you could convert the drivers to use videobuf. There's currently a videobuf variation for devices that don't support scatter/gather dma transfers. By using videobuf, the mmap() methods (and also overlay, if you want) will be supported. It's been on my todo list for ages, but I don't see it happening anytime soon. It will be difficult to do and the simple fact of the matter is that the read() interface is much more suitable for MPEG streams than mmap, and almost nobody is using the raw video streams where mmap would make sense. The only reason for doing this would be to make the driver consistent with the other drivers in V4L2. Which is a valid argument, but as long as we still have V4L1 drivers to convert I'd argue that this is definitely a low prio task. I suspect that the only two drivers that don't support mmap() are ivtv and cx18. All other drivers support it, including other drivers that also provides compressed data (like jpeg webcams). In a matter of fact, most applications work only with mmap() interface (being mythtv and mplayer capable of supporting both read() and mmap()). So, by providing mmap(), other applications will benefit of it. Also, there is a sort of chicken and egg trouble: almost nobody uses raw formats, since it uses a non-standard format that it is not supported by userspace apps. The libv4l2 is the proper way for handling it, but only works with mmap(). I'd be happy if libv4l2 would just check whether mmap is supported, and if not then disable adding the extra pixelformats. That's easy to do there, and would make it possible to add hm12 for use with libv4lconvert. While it would be nice from my point of view if libv4l2's read() could convert without using mmap, I have to agree that that is probably overkill. And nobody really cares about raw video with ivtv and cx18. Really. I've had perhaps 3-4 queries about this in all the years that I've been maintaining ivtv. Anyway, it will only be useful if we also add a proper alsa driver for the audio. Bottom line is: no time on my side and no pressure whatsoever from the users of cx18 and ivtv. There are also additional complications with respect to splicing the sliced VBI data into the MPEG stream that will make a videobuf conversion much more complicated than you think. It will mean a substantial and risky overhaul of the driver that requires probably weeks of work. Yes, I do want to do this, but unless someone else steps in it won't be anytime soon. Regards, Hans The usage of read() for raw formats is possible, but, read() method doesn't provide any meta-data info. For example, there's no timestamp that would be useful for syncing audio and video and detect frame losses. Also, if, for some reason, you loose a half frame, the result would be a disaster if you're using the read() method. So, IMO, adding read() support to libv4l2 would be just a hack and will likely cause more troubles than benefits. This is just my 2 cents. BTW, it would help if someone would actually document videobuf. Documentation should be much more important than it currently is. Videobuf usage is not that complicate. You just need to provide ops for four handlers: q-ops-buf_setup - calculates the size of the video buffers and avoid they to waste more than some maximum limit of RAM; q-ops-buf_prepare - fills the video buffer structs and calls videobuf_iolock() to alloc and prepare mmaped memory; q-ops-buf_queue - advices the driver that another buffer were requested (by read() or by QBUF); q-ops-buf_release - frees any buffer that were allocated. In order to use it, the driver need to have a code (generally called at interrupt context) that will properly handle the buffer request lists, announcing that a
Re: libv4l2 library problem
On Sat, 2009-02-14 at 12:06 +0100, Hans Verkuil wrote: On Saturday 14 February 2009 11:32:06 Mauro Carvalho Chehab wrote: On Sat, 14 Feb 2009 10:08:31 +0100 Hans Verkuil hverk...@xs4all.nl wrote: On Saturday 14 February 2009 09:52:06 Mauro Carvalho Chehab wrote: On Fri, 13 Feb 2009 13:57:45 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Hans, I've developed a converter for the HM12 format (produced by Conexant MPEG encoders as used in the ivtv and cx18 drivers). But libv4l2 has a problem in its implementation of v4l2_read: it assumes that the driver can always do streaming. However, that is not the case for some drivers, including cx18 and ivtv. These drivers only implement read() functionality and no streaming. I suspect that the only two drivers that don't support mmap() are ivtv and cx18. All other drivers support it, including other drivers that also provides compressed data (like jpeg webcams). In a matter of fact, most applications work only with mmap() interface (being mythtv and mplayer capable of supporting both read() and mmap()). So, by providing mmap(), other applications will benefit of it. Also, there is a sort of chicken and egg trouble: almost nobody uses raw formats, since it uses a non-standard format that it is not supported by userspace apps. The libv4l2 is the proper way for handling it, but only works with mmap(). I'd be happy if libv4l2 would just check whether mmap is supported, and if not then disable adding the extra pixelformats. That's easy to do there, and would make it possible to add hm12 for use with libv4lconvert. While it would be nice from my point of view if libv4l2's read() could convert without using mmap, I have to agree that that is probably overkill. And nobody really cares about raw video with ivtv and cx18. Really. I've had perhaps 3-4 queries about this in all the years that I've been maintaining ivtv. Anyway, it will only be useful if we also add a proper alsa driver for the audio. Bottom line is: no time on my side and no pressure whatsoever from the users of cx18 and ivtv. There are also additional complications with respect to splicing the sliced VBI data into the MPEG stream that will make a videobuf conversion much more complicated than you think. It will mean a substantial and risky overhaul of the driver that requires probably weeks of work. Yes, I do want to do this, but unless someone else steps in it won't be anytime soon. I can convert cx18 if someone really cares, but *no one* has ever directly enquired about the YUV (HM12) data from cx18. (I think there was quite a long time when it actually may not have been wokring - nobody cared.) When someone has paid the extra money for the encoder hardware, raw formats are really just a nice to have. There is cheaper hardware for raw formats. Anyway, such a conversion to mmap and/or videobuf is very far down on my TODO list. Whatever I do for cx18 may not translate directly to usable code for ivtv, the buffer handling is slightly different and simpler since there's no MPEG decoder to worry about. Again, it's not impossible, just a matter of time and demand. I have little time and I have no demand, aside from Hans Verkuil's desire to get an HM12 converter into the library. I haven't done any research, but I'm surprised that no other supported chip offers this format. I guess maybe that has something to do with the CX23415's origins from Internext Compression Inc. 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: VIDIOC_G_REGISTER question
On Sat, 2009-02-14 at 10:51 +0100, Hans Verkuil wrote: On Saturday 14 February 2009 02:26:14 Andy Walls wrote: I'm treating the CX23418 A/V Core as a non-I2C host chip. Am I allowed to modify the register value passed in to a VIDIOC_G_REGISTER ioctl() like below? The spec doesn't say if this feedback is expected or not. Good point. The short answer is no, because no other driver does that AFAIK. The long answer is that perhaps we should do this, but that requires going through all drivers and updating them, and it requires changing the API for s_register (currently that has a const argument) and requiring drivers to update reg in s_register as well. But I do not really see much of an advantage in doing this. It would also make it impossible to have a for-loop on the reg field when iterating over registers (for the record: v4l2-dbg doesn't do that). Yeah. I thought better of it. The g/s_register now returns -EINVAL if the input address is not 4 byte aligned. I figured that was a reasonable simplification that only impacts the expert user. Nice idea, BTW, making the analog front end addr 1 on the host. Well, since I was logicaly treating it like a second chip (and not the host) and the V4L2 Spec said to use MATCH_HOST with a non-0 address for the Nth non-host, non-I2C, chip on the board, that is what fell out. (I was surpirsed to see the explicit AC97 chip match option. It seemed out of place when looking at the V4L2 spec.) Really I just wanted a convenient alias to the CX18-AV register set. Using register addresses like 0x404 is alot easier on my memory than addresses like 0x2c40404. I suppose I could do something similar for all the functionally different register space partitions on the chip, but that's just overkill. Honestly the v4l2_device/v4l2_subdev framework looks like it can let a driver writer do all sorts of abstractions along this lines. For the chip revision I would suggest looking at various revision registers in the analog front end: regs 0x, 0x0004, 0x000c and 0x0100 all have some sort of a version/revision ID in them. The 0x0100 should match the revision as used in the cx2584x. I never really looked at these regs, so I don't know which makes the most sense. I believe the internal device *always* claims to be an '843 when you look at the register. I don't think the minor rev of this internal digitizer core is going to matter given the host chip revision. I was more worried about confusion with a real CX25843, which has 1 byte alignment, and this AV decoder, which has 4 byte alignment. The '418 revision number is a cheap hack to make sure external apps know the difference without having to squirrel away the host chip id.. If that's the wrong thing, I can give it a new real ID in the CX25840 block of the id enumeration and provide the real revision. Just FYI, once all drivers are using v4l2_subdev I'm going to simplify the chip_ident and s/g_register functions by integrating it into v4l2_subdev. The idea is to put ident and revision into the v4l2_subdev struct, and have a dbg_match op in v4l2_subdev that is used to do the matching for g_chip_ident and g/s_register. For i2c devices this will be a standard function in v4l2-common.h. So g_chip_ident will disappear and g/s_register no longer needs to do any matching. Excellent. Regards, Andy Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
TwinHan PCI-Sat Card Problem
Hallo, my configuration is * Fujitsu Siemens HTPC * MythDora 5.0(FC 8) * TwinHan PCI-Sat * Technisat Multytenne(4 Satelite positions 13.0 19.2,23.5, 28) dual This mulitytenne is once connected to a technisat receiver and once to the HTPC. I can watch on the receiver, but I did not success with my htpc so far. The card is recognized in mythtv-setup, but it cant determine its parameters, so I tried to use it manually, first. I got installed 2 tv cards in my HTPC, I am concentrating on the Twinhan Vision Plus DVB In my /etc/modprobe.conf there is not yet anything mentioned about my dvb card ls /dev/dvb/adapter0/ shows ca0 demux0 dvr0 frontend0 net0 I successfully generated a channels.conf with valid and real channels. When I run [myt...@localhost szap]$ ./szap -a 0 -r N24 reading channels from file '/home/mythtv/.szap/channels.conf' zapping to 17 'N24': sat 0, frequency = 12640 MHz V, symbolrate 2200, vpid = 0x03ff, apid = 0x0400 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' FE_SET_VOLTAGE failed: Input/output error status 1f | signal fffe | snr fffe | ber fffe | unc fffe | FE_HAS_LOCK status 1f | signal fffe | snr 22ef | ber fffe | unc fffe | FE_HAS_LOCK status 1f | signal 3d00 | snr 22f3 | ber fffe | unc fffe | FE_HAS_LOCK ... The error message about FE_SET_VOLTAGE does sometimes appear if i try then/during mplayer /dev/dvb/adapter0/dvr0 I get nothing, dvr does not output any byte Relevant modules loaded are saa7134_alsa 14689 1 tda1004x 17477 1 saa7134_dvb1 0 videobuf_dvb8517 1 saa7134_dvb dst_ca 14913 1 tuner_simple 15953 2 tuner_types17857 1 tuner_simple tda988713509 1 tda829015685 0 dst27593 2 dst_ca dvb_bt8xx 17605 0 dvb_core 68673 5 saa7134_dvb,videobuf_dvb,dst_ca,dst,dvb_bt8xx saa7134 128789 2 saa7134_alsa,saa7134_dvb bt878 12793 2 dst,dvb_bt8xx tuner 26249 0 bttv 152661 2 dvb_bt8xx,bt878 videodev 31425 3 saa7134,tuner,bttv The important passages of dmesg look like bttv: driver version 0.9.17 loaded bttv: using 8 buffers with 2080k (520 pages) each for capture bttv: Bt8xx card found (0). ACPI: PCI Interrupt :01:0b.0[A] - GSI 16 (level, low) - IRQ 16 bttv0: Bt878 (rev 17) at :01:0b.0, irq: 16, latency: 32, mmio: 0xfdcff000 bttv0: detected: Twinhan VisionPlus DVB [card=113], PCI subsystem ID is 1822:0001 bttv0: using: Twinhan DST + clones [card=113,autodetected] bttv0: gpio: en=, out= in=00f5fffd [init] input: i2c IR (Hauppauge) as /class/input/input8 ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-1/1-001a/ir0 [bt878 #0 [hw]] bttv0: tuner absent bttv0: add subdevice dvb0 bt878: AUDIO driver version 0.0.0 loaded bt878: Bt878 AUDIO function found (0). ACPI: PCI Interrupt :01:0b.1[A] - GSI 16 (level, low) - IRQ 16 bt878_probe: card id=[0x11822],[ Twinhan VisionPlus DVB ] has DVB functions. bt878(0): Bt878 (rev 17) at 01:0b.1, irq: 16, latency: 32, memory: 0xfdcfe000 saa7130/34: v4l2 driver version 0.2.14 loaded ACPI: PCI Interrupt :01:04.0[A] - GSI 19 (level, low) - IRQ 19 saa7134[0]: found at :01:04.0, rev: 1, irq: 19, latency: 32, mmio: 0xfddff000 saa7134[0]: subsystem: 021a:0001, board: Medion 7134 [card=12,insmod option] saa7134[0]: board init: gpio is 0 DVB: registering new adapter (bttv0) tuner' 2-0043: chip found @ 0x86 (saa7134[0]) tda9887 2-0043: creating new instance tda9887 2-0043: tda988[5/6/7] found tuner' 2-0061: chip found @ 0xc2 (saa7134[0]) saa7134[0]: i2c eeprom 00: a0 12 02 00 54 20 08 00 43 43 28 0c 00 52 20 12 saa7134[0]: i2c eeprom 10: 00 87 82 0f ff 20 2a 00 00 50 12 00 00 18 0a 10 saa7134[0]: i2c eeprom 20: 01 00 00 02 02 03 01 00 06 ad 00 10 02 51 00 08 saa7134[0]: i2c eeprom 30: 01 18 48 07 03 00 00 0c d2 00 00 10 00 00 12 3c saa7134[0]: i2c eeprom 40: 60 00 00 c0 82 10 00 00 00 00 01 58 40 1b 02 8d saa7134[0]: i2c eeprom 50: 7d 56 65 3f 00 5b 06 02 00 00 04 00 0c 00 04 00 saa7134[0]: i2c eeprom 60: 2b a6 7d 38 2b d4 d3 5b 3a 51 e5 5e c6 87 f2 ff saa7134[0]: i2c eeprom 70: ff a6 2a 58 3a 5b 13 86 b2 58 1a d4 d3 58 5a 5d saa7134[0]: i2c eeprom 80: 02 22 50 1f 21 8f 80 87 bf 5b fb 5b 3f ad 28 50 saa7134[0]: i2c eeprom 90: 16 7d 28 1c 41 18 48 87 f3 00 01 8d f3 00 01 50 saa7134[0]: i2c eeprom a0: 22 58 12 7f 60 00 91 5e 18 ff ff a6 7d da d8 79 saa7134[0]: i2c eeprom b0: 29 52 96 d4 d3 5b 3a ad 2b 41 84 22 a6 58 66 00 saa7134[0]: i2c eeprom c0: 93 26 29 a6 2a 58 3a 5b 13 a6 29 58 1a 61 2b d4 saa7134[0]: i2c eeprom d0: d3 49 82 8f ba 49 82 8f f2 00 01 5d 12 22 7e 1f saa7134[0]: i2c eeprom e0: 21 8f 80 87 bf 5b fb 5b 3f ad 28 50 16 7d 28 1c saa7134[0]: i2c eeprom f0: 41 18 48 87 f3 00 01 8d f3 00 01 50 22 60 29 7f saa7134[0] Cant determine tuner type 1000 from EEPROM saa7134[0] Tuner type is 63 tuner-simple
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l2-dev: remove limit of 32 devices per driver in get_index() - vivi: update comment to reflect that vivi can now create more than 32 devs. - v4l2-device: allow a NULL parent device when registering. - v4l2-subdev: rename dev field to v4l2_dev - vivi: introduce v4l2_device and do several cleanups - vivi: controls are per-device, not global. vivi needs more cleanup (multiple opens should be allowed, the selected format should be stored in vivi_dev instead of vivi_fh), but it is a start. Thanks, Hans diffstat: Documentation/video4linux/v4l2-framework.txt | 60 ++--- drivers/media/video/v4l2-dev.c | 25 +- drivers/media/video/v4l2-device.c| 49 ++-- drivers/media/video/vivi.c | 307 +-- include/media/v4l2-device.h | 31 +- include/media/v4l2-subdev.h |4 6 files changed, 249 insertions(+), 227 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: libv4l2 library problem
On Sat, 14 Feb 2009 15:11:13 +0100 Hans Verkuil hverk...@xs4all.nl wrote: On Saturday 14 February 2009 15:05:14 Andy Walls wrote: On Sat, 2009-02-14 at 12:06 +0100, Hans Verkuil wrote: On Saturday 14 February 2009 11:32:06 Mauro Carvalho Chehab wrote: On Sat, 14 Feb 2009 10:08:31 +0100 Hans Verkuil hverk...@xs4all.nl wrote: On Saturday 14 February 2009 09:52:06 Mauro Carvalho Chehab wrote: On Fri, 13 Feb 2009 13:57:45 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Hi Hans, I've developed a converter for the HM12 format (produced by Conexant MPEG encoders as used in the ivtv and cx18 drivers). But libv4l2 has a problem in its implementation of v4l2_read: it assumes that the driver can always do streaming. However, that is not the case for some drivers, including cx18 and ivtv. These drivers only implement read() functionality and no streaming. I suspect that the only two drivers that don't support mmap() are ivtv and cx18. All other drivers support it, including other drivers that also provides compressed data (like jpeg webcams). In a matter of fact, most applications work only with mmap() interface (being mythtv and mplayer capable of supporting both read() and mmap()). So, by providing mmap(), other applications will benefit of it. Also, there is a sort of chicken and egg trouble: almost nobody uses raw formats, since it uses a non-standard format that it is not supported by userspace apps. The libv4l2 is the proper way for handling it, but only works with mmap(). I'd be happy if libv4l2 would just check whether mmap is supported, and if not then disable adding the extra pixelformats. That's easy to do there, and would make it possible to add hm12 for use with libv4lconvert. While it would be nice from my point of view if libv4l2's read() could convert without using mmap, I have to agree that that is probably overkill. And nobody really cares about raw video with ivtv and cx18. Really. I've had perhaps 3-4 queries about this in all the years that I've been maintaining ivtv. Anyway, it will only be useful if we also add a proper alsa driver for the audio. Bottom line is: no time on my side and no pressure whatsoever from the users of cx18 and ivtv. There are also additional complications with respect to splicing the sliced VBI data into the MPEG stream that will make a videobuf conversion much more complicated than you think. It will mean a substantial and risky overhaul of the driver that requires probably weeks of work. Yes, I do want to do this, but unless someone else steps in it won't be anytime soon. I can convert cx18 if someone really cares, but *no one* has ever directly enquired about the YUV (HM12) data from cx18. (I think there was quite a long time when it actually may not have been wokring - nobody cared.) When someone has paid the extra money for the encoder hardware, raw formats are really just a nice to have. There is cheaper hardware for raw formats. Anyway, such a conversion to mmap and/or videobuf is very far down on my TODO list. Whatever I do for cx18 may not translate directly to usable code for ivtv, the buffer handling is slightly different and simpler since there's no MPEG decoder to worry about. Again, it's not impossible, just a matter of time and demand. I have little time and I have no demand, aside from Hans Verkuil's desire to get an HM12 converter into the library. I haven't done any research, but I'm surprised that no other supported chip offers this format. I guess maybe that has something to do with the CX23415's origins from Internext Compression Inc. It's a macroblock format where all Y and UV bytes are organized in 8x8 blocks. I believe it is a by-product of the MPEG encoding process that is made available by the firmware as a bonus feature. It is clearly meant as the source format for the actual MPEG encoder. Pretty much specific to the cx2341x devices. Hans and Andy, I understand that this have low priority. The only practical usage is if someone wants to do a better encoding for some video above the limits that cx2341x provides (for example, encoding with the same rate, but with MPEG 4, to have a higher quality). What I'm trying to say is that I don't see much value to change libv4l2 to support read() method and HM12, since using read() method for a stream without a metadata doesn't work very well (sync issues, etc), but this is just my 2 cents. With respect with ivtv-alsa and cx18-alsa, I think that, once having the driver ported to videobuf, it shouldn't be hard to use cx88-alsa as a reference for writing those drivers. About the efforts to port it, only you can evaluate it. In the case of em28xx, once having a videobuf driver for usb, it weren't hard to port it to videobuf
[cron job] WARNINGS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below.) Results of the daily build of v4l-dvb: date:Sat Feb 14 19:00:08 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10571:12a10f808bfd gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc5-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc5-armv5-omap2: OK linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc5-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc5-m32r: OK linux-2.6.16.61-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc5-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc5-powerpc64: WARNINGS linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-rc5-x86_64: WARNINGS fw/apps: OK spec: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc5): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html -- 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: [PULL] bttv driver improvements
On Sat, 14 Feb 2009, VDR User wrote: On Fri, Feb 13, 2009 at 5:07 PM, Trent Piepho xy...@speakeasy.org wrote: I tested it on my bttv card. I assume Mauro was able to test it too. Have you found a problem? Didn't you say in your original post that you _haven't_ tested the code because of a conflict with your sata driver? It's not safe to I was able to test it later by getting a different sata card. -- 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: libv4l2 library problem
On Sat, 2009-02-14 at 15:11 +0100, Hans Verkuil wrote: On Saturday 14 February 2009 15:05:14 Andy Walls wrote: On Sat, 2009-02-14 at 12:06 +0100, Hans Verkuil wrote: On Saturday 14 February 2009 11:32:06 Mauro Carvalho Chehab wrote: On Sat, 14 Feb 2009 10:08:31 +0100 Hans Verkuil hverk...@xs4all.nl wrote: On Saturday 14 February 2009 09:52:06 Mauro Carvalho Chehab wrote: It's a macroblock format where all Y and UV bytes are organized in 8x8 blocks. I believe it is a by-product of the MPEG encoding process that is made available by the firmware as a bonus feature. It is clearly meant as the source format for the actual MPEG encoder. Pretty much specific to the cx2341x devices. That's interesting. I guess,it's a useful thing to have, if I were working on a software implementation of an MPEG (not MPEG-2) or MJPEG encoder, or something else that did DCT or Wavelet Transforms on macroblocks. I was also musing that the raw VBI capture of the chip's API could be abused to extract the entire active raster of UYVY samples for each frame (first field followed by second field). It even sends a per frame PTS with this raw raster data. But there's lot of pain with that: wasted bus bandwidth, stripping out all the SAV sequences, and, not surprisingly, the cx18 driver is not structured top provide a video capture stream via the VBI streams. ;) Regards, Andy Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Adding a control for Sensor Orientation
Hi all, Hans Verkuil put forward a convincing argument that sensor orientation shouldn't be part of the buffer flags as then it would be unavailable to clients that use read() so it looks like implementing a read only control is the only appropriate option. It seems that Sensor Orientation is an attribute that many cameras may want to expose so it shouldn't be a private control. Olivier Lorin's example patch created a new CAMERA_PROPERTIES class. I'm not sure that a new class is really justified so would like to hear other views on where the control should live (and also if everyone is happy with Hans Verkuil's suggested name of SENSOR_ORIENTATION which I prefer to Olivier Lorin's SENSOR_UPSIDE_DOWN as we want to represent HFLIP and VFLIP as well as upside down (which as currently implemented means 180 degree rotation.)) Assuming that it is considered inappropriate to add a new control as an Old-style 'user' control then it is also, I presume, necessary to extend gspca to support VIDIOC_G_EXT_CTRLS as at the moment it requires all control access to use VIDIOC_G_CTRL. Would doing this conflict with anything anyone else may be working on such as conversion to use v4l2_device. Thoughts please. Adam Baker -- 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 : [linux-dvb] Re : Technotrend Budget S2-3200 Digital artefacts on HDchannels
On Fri, Feb 6, 2009 at 3:22 PM, Manu eall...@gmail.com wrote: Can you please send me a complete trace with the stb6100 and stb0899 modules loaded with verbose=5 for the 30MSPS transponder what you are trying ? One simple szap would be enough (no scan please) based on the http://jusst.de/hg/v4l-dvb tree. Before you start testing, start clean from a cold boot after a powerdown. This makes it a bit more easier identify things. OK I did just that with latest multiproto on a 11495 MHz trnaposnder, DVB-S2, 30MS/s, FEC 5/6 which works using the provider's STB . I put the log in attachement. You will observe a lock is acquired really briefly and then nothing. Obtained using: szap2 -t 2 I hope this can give you some data. Let me know if you need more info (like putting some more printksin the source). Bye Manu Sorry for the late reply, but the new list confuses the hell out of me and I missed this message, somehow... Attached is a log file with the results of dvb-apps/szap on a 3 3/4 channel using a http://jusst.de/hg/v4l-dvb clean compile and cold boot as recommended. Also loaded stb6100 and stb0899 with verbose=5 Command line used and result: r...@vdr:/usr/local/src/v4l-dvb_multi/dvb-apps/util/szap# ./szap -c /video/channels.conf -n 7 reading channels from file '/video/channels.conf' zapping to 7 '[006b]': sat 0, frequency = 12012 MHz H, symbolrate 3000, vpid = 0x1031, apid = 0x1032 sid = 0x1004 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal 7fb2 | snr | ber | unc fffe | status 00 | signal 7fb2 | snr | ber | unc fffe | [...] status 00 | signal 7fb2 | snr | ber | unc fffe | status 00 | signal 7fb2 | snr | ber | unc fffe | After that szapping to that problematic channel, I tried a DVB-S channel, which locks without problems. r...@vdr:/usr/local/src/v4l-dvb_multi/dvb-apps/util/szap# ./szap -c /video/channels.conf -H -n 33 reading channels from file '/video/channels.conf' zapping to 33 'FOX': sat 0, frequency = 11617 MHz V, symbolrate 2750, vpid = 0x1b30, apid = 0x1b31 sid = 0x using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal 49% | snr 0% | ber 0 | unc -2 | status 1e | signal 0% | snr 0% | ber 0 | unc -2 | FE_HAS_LOCK Going to test your the same multiproto tree _with_ both patches you mentioned early on this thread. BTW, I can see all those channels just fine using a DM800 and the provider original decoder with my subscription card. I'm positive that dish/lnb/connections aren't the problem. Thanks for taking the time to address this particular issue. Chris v4l-dvb-multiproto_s2-3200_no_patch_test_log.txt.tar.bz2 Description: BZip2 compressed data
saa7134-alsa does not compile (BUG?)
Hi, I upgraded my kernel and recompiled v4l-dvb to match the new kernel. Now the saa7134-alsa kernel module is no more. What did I do wrong? Regards Jakob Sundberg -- 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 : [linux-dvb] Re : Technotrend Budget S2-3200 Digital artefacts on HDchannels
On Sat, Feb 14, 2009 at 10:34 PM, Chris Silva 2manybi...@gmail.com wrote: On Fri, Feb 6, 2009 at 3:22 PM, Manu eall...@gmail.com wrote: Can you please send me a complete trace with the stb6100 and stb0899 modules loaded with verbose=5 for the 30MSPS transponder what you are trying ? One simple szap would be enough (no scan please) based on the http://jusst.de/hg/v4l-dvb tree. Before you start testing, start clean from a cold boot after a powerdown. This makes it a bit more easier identify things. OK I did just that with latest multiproto on a 11495 MHz trnaposnder, DVB-S2, 30MS/s, FEC 5/6 which works using the provider's STB . I put the log in attachement. You will observe a lock is acquired really briefly and then nothing. Obtained using: szap2 -t 2 I hope this can give you some data. Let me know if you need more info (like putting some more printksin the source). Bye Manu Sorry for the late reply, but the new list confuses the hell out of me and I missed this message, somehow... Attached is a log file with the results of dvb-apps/szap on a 3 3/4 channel using a http://jusst.de/hg/v4l-dvb clean compile and cold boot as recommended. Also loaded stb6100 and stb0899 with verbose=5 Command line used and result: r...@vdr:/usr/local/src/v4l-dvb_multi/dvb-apps/util/szap# ./szap -c /video/channels.conf -n 7 reading channels from file '/video/channels.conf' zapping to 7 '[006b]': sat 0, frequency = 12012 MHz H, symbolrate 3000, vpid = 0x1031, apid = 0x1032 sid = 0x1004 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal 7fb2 | snr | ber | unc fffe | status 00 | signal 7fb2 | snr | ber | unc fffe | [...] status 00 | signal 7fb2 | snr | ber | unc fffe | status 00 | signal 7fb2 | snr | ber | unc fffe | After that szapping to that problematic channel, I tried a DVB-S channel, which locks without problems. r...@vdr:/usr/local/src/v4l-dvb_multi/dvb-apps/util/szap# ./szap -c /video/channels.conf -H -n 33 reading channels from file '/video/channels.conf' zapping to 33 'FOX': sat 0, frequency = 11617 MHz V, symbolrate 2750, vpid = 0x1b30, apid = 0x1b31 sid = 0x using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal 49% | snr 0% | ber 0 | unc -2 | status 1e | signal 0% | snr 0% | ber 0 | unc -2 | FE_HAS_LOCK Going to test your the same multiproto tree _with_ both patches you mentioned early on this thread. BTW, I can see all those channels just fine using a DM800 and the provider original decoder with my subscription card. I'm positive that dish/lnb/connections aren't the problem. Thanks for taking the time to address this particular issue. Chris As promised, a log with the exact same conditions described above, but with increase_timeout.patch and fix_iterations.patch applied, referred to on this same thread. Chris v4l-dvb-multiproto_s2-3200_with_patches_test_log.txt.tar.bz2 Description: BZip2 compressed data
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ivtv
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-ivtv for the following: - ivtv: fix decoder crash regression This is a high prio bug fix for 2.6.29 that fixes a regression that was introduced in kernel 2.6.27. Mike, can you queue this fix for inclusion in the stable series of 2.6.27 (if still possible) and 2.6.28? Thanks to han...@linus.priv.at for testing and helping me track this one down! Regards, Hans diffstat: ivtv-ioctl.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: libv4l2 library problem
Hi Hans, On Friday 13 February 2009 13:57:45 Hans Verkuil wrote: Hi Hans, I've developed a converter for the HM12 format (produced by Conexant MPEG encoders as used in the ivtv and cx18 drivers). But libv4l2 has a problem in its implementation of v4l2_read: it assumes that the driver can always do streaming. However, that is not the case for some drivers, including cx18 and ivtv. These drivers only implement read() functionality and no streaming. Can you as a minimum modify libv4l2 so that it will check for this case? The best solution would be that libv4l2 can read HM12 from the driver and convert it on the fly. But currently it tries to convert HM12 by starting to stream, and that produces an error. This bug needs to be fixed first before I can contribute my HM12 converter. My sincere apologies: I looked at the libv4l2 code again and it was clear that it did in fact test for this case. I retested my own code and everything seems to work as it should. So libv4l2 is fine, and I will prepare a tree tomorrow containing the hm12 support for libv4lconvert. Sorry about this, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: [PULL] bttv driver improvements
On Sat, 14 Feb 2009, VDR User wrote: On Sat, Feb 14, 2009 at 11:54 AM, Trent Piepho xy...@speakeasy.org wrote: Didn't you say in your original post that you _haven't_ tested the code because of a conflict with your sata driver? It's not safe to I was able to test it later by getting a different sata card. Ahh, gotcha. Just curious, which card/drivers were you using that conflicted with bttv? It's a sil3124 PCI-X SATA II card that is extemely fussy. I can only get to work if I have every other PCI card in my computer in a few specific configurations. If I add the bt848 card, it won't work. If I *remove* my sound card it won't work. If I put the SATA card in another slot it won't work. If I move my cx88 HD-5500 card to another slot it won't work. If I install the cx88 HD-3000 card in place of the HD-5500 it won't work. Only problem with the cheap VIA PCI SATA I card I'm using is that it has much lower performance than the sil card when it works. I just need a new computer, keeping this dual athlon system from 2001 working is getting too hard. Faster Athlon-MP CPUs are insanely expensive on ebay. No PCI-E slots for modern SATA or graphics cards. Doesn't work with AGP 8x. Won't boot unless I go through a magic sequence of turning it on and off in quick sequence. And I'm sick of messing with the closed source nvidia driver that keeps getting worse and worse with each revision. -- 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
