Re: v4l-utils-0.8.3 and KVDR
KVDR has a number of different parameters including -xforce xv-mode on startup and disable overlay-mod -ddont switch modeline during xv with kernel 2.6.35 I run KVDR with -x as I have an NVIDIA graphics. Running on 2.6.38 KVDR -x doesn't produce any log. The display appears and immediately disappears although there is a process running. With KVDR -d I get a display window but no picture but the attached log is produced. I hope this helps Mike libv4l2: open: 4 request == VIDIOC_G_FMT pixelformat: BGR3 384x288 field: 0 bytesperline: 0 imagesize331776 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 0, description: RGB-8 (3-3-2) result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB1 48x32 field: 3 bytesperline: 48 imagesize1536 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB1 768x288 field: 3 bytesperline: 768 imagesize221184 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 1, description: RGB-16 (5/B-6/G-5/R) result == 0 request == VIDIOC_TRY_FMT pixelformat: RGBP 48x32 field: 3 bytesperline: 768 imagesize24576 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGBP 768x288 field: 3 bytesperline: 1536 imagesize442368 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 2, description: RGB-24 (B-G-R) result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR3 48x32 field: 3 bytesperline: 1536 imagesize49152 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR3 768x288 field: 3 bytesperline: 2304 imagesize663552 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 3, description: RGB-32 (B-G-R) result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR4 48x32 field: 3 bytesperline: 2304 imagesize73728 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: BGR4 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 4, description: RGB-32 (R-G-B) result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB4 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB4 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 5, description: Greyscale-8 result == 0 request == VIDIOC_TRY_FMT pixelformat: GREY 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: GREY 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 6, description: YUV 4:2:2 planar (Y-Cb-Cr) result == 0 request == VIDIOC_TRY_FMT pixelformat: 422P 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: 422P 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 7, description: YVU 4:2:0 planar (Y-Cb-Cr) result == 0 request == VIDIOC_TRY_FMT pixelformat: YV12 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: YV12 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 8, description: YUV 4:2:0 planar (Y-Cb-Cr) result == 0 request == VIDIOC_TRY_FMT pixelformat: YU12 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: YU12 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 9, description: YUV 4:2:2 (U-Y-V-Y) result == 0 request == VIDIOC_TRY_FMT pixelformat: UYVY 48x32 field: 3 bytesperline: 3072 imagesize98304 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: UYVY 768x288 field: 3 bytesperline: 3072 imagesize884736 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 10, description: RGB3 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB3 48x32 field: 3 bytesperline: 144 imagesize4608 colorspace: 0, priv: 0 result == 0 request == VIDIOC_TRY_FMT pixelformat: RGB3 768x288 field: 3 bytesperline: 2304 imagesize663552 colorspace: 0, priv: 0 result == 0 request == VIDIOC_ENUM_FMT index: 11, description: result == -1 (Invalid argument) request == VIDIOC_ENUMINPUT result == 0 request == VIDIOC_ENUMSTD result == 0 libv4l1: open: 4 request == VIDIOC_QUERYCAP result == 0 request == VIDIOC_G_FBUF result == 0 request == VIDIOC_S_FBUF result == 0 libv4l2: close: 4 libv4l1: close: 4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More
v4l-utils-0.8.3 and KVDR
My understanding of the wrapperscontained in this library is that v4l applications should work with kernels from 2.6.36 onwards if the compat.so is preloaded. I use KVDR for watching and controlling VDR on my TV. Xine and Xineliboutput or not options as they don't provide TV out and TV out fronm the video card is also not an option because of where things are in the house. KVDR fails with Xv-VIDIOCGCAP: Invalid argument Xv-VIDIOCGMBUF: Invalid argument works perfectly fine on linux-2.6.35 Anyone have any ideas Mike -- 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] [Patch] Correct Signal Strength values for STB0899
On Thu, 9 Sep 2010 03:51:06 you wrote: thx Goga and thx to dimka_9 for his great work. I hope those guys will include it in the driver regards Newsy --- Goga777 goga...@bk.ru schrieb am Mi, 8.9.2010: Von: Goga777 goga...@bk.ru Betreff: Re: [linux-dvb] [Patch] Correct Signal Strength values for STB0899 An: linux-...@linuxtv.org CC: linux-media@vger.kernel.org Datum: Mittwoch, 8. September, 2010 19:47 Uhr first of all I have to say that this patch is not from me. It's from rotor-0.1.4mh-v1.2.tar.gz Thx to the author of that patch and the modified rotor Plugin. I think he's a friend of Mike Booth I think it should be included into s2-liplianin. With this patch all dvb-s and dvb-s2 signal strength values are scaled correctly. FYI - this patch from Russian DVB VDR forum. Author is dimka_9 http://linuxdvb.org.ru/wbb/index.php?page=ThreadpostID=11883#post11883 Goga ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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 We ( Mark and I) have been using dmka_9s patch for some months now haviong included it in rotor. It works fine here and should be include inthe driver. PS has anyone been able to fix BER and UNC? Refard Mike -- 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: What ever happened to standardizing signal level?
On Saturday 29 May 2010 14:45:40 Konstantin Dimitrov wrote: at least in driver for the frontend found on TBS 6980 Dual DVB-S2 card i added options esno and dbm respectively for reporting SNR (actually C/N) in EsNo dB and signal strength in dBm, which is at least real statistics about the signal and not like almost meaningless percents. so, that's one way to go. some DVB-S/S2 demodulators use EsNo dB and other EbNo dB and so maybe step toward some standardization is routines for conversion between those two. also, maybe there will be common agreement how to convert signal strength in dBm to percents and SNR (C/N) in EsNo or EbNo dB to percents. i believe that will guarantee more standard way to give information about the signal, but it's just my opinion. On Sat, May 29, 2010 at 6:09 AM, VDR User user@gmail.com wrote: A lot of people were anticipating this happening but it seems to have stalled out. Does anyone know what the intentions are? Many users were also hoping to _finally_ get a good signal meter for linux as well. If anyone has any info, please share! -- 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 -- 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 i think someone is too concerned about being precisely accurate. So much so that no-one can see the woods for the trees any more. Its not important to me that accuracy is spot on. I only want to know that when tuning the dish I'm getting \better or worse. A mate has fixed this locally. So will we get a plethora of patches all trying to do the same thing. Mike -- 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: Details about DVB frontend API
On Friday 23 October 2009 06:13:30 Jean Delvare wrote: Hi folks, I am looking for details regarding the DVB frontend API. I've read linux-dvb-api-1.0.0.pdf, it roughly explains what the FE_READ_BER, FE_READ_SNR, FE_READ_SIGNAL_STRENGTH and FE_READ_UNCORRECTED_BLOCKS commands return, however it does not give any information about how the returned values should be interpreted (or, seen from the other end, how the frontend kernel drivers should encode these values.) If there documentation available that would explain this? For example, the signal strength. All I know so far is that this is a 16-bit value. But then what? Do greater values represent stronger signal or weaker signal? Are 0x and 0x special values? Is the returned value meaningful even when FE_HAS_SIGNAL is 0? When FE_HAS_LOCK is 0? Is the scale linear, or do some values have well-defined meanings, or is it arbitrary and each driver can have its own scale? What are the typical use cases by user-space application for this value? That's the kind of details I'd like to know, not only for the signal strength, but also for the SNR, BER and UB. Without this information, it seems a little difficult to have consistent frontend drivers. Thanks, I have tried on two occasions to engage the the author of my particular driver as to how to implement a patch and use femon with no response. Its good that there is some movement at last which might get a result. I've said before I don't really care too much about spot on accuracy but rather a scale that increases as you get closer to a lock. I can imagine there are loads of users out there who rely on the output of things like femon and vdr-rotor to tune their equipment and with S2 cards like both of mine they are knackered so to speak. Mike -- 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
SNR Signal Strength an d BER
I have the good fortune to be the 'lucky' owner of an stb0899/stb6100 based DVB card. Whilst the performance of the card is fine, at least as good as the two other s1 TT cards I have, I find it really frustrating that I can't use it in the way that I can the other two. I use them, together with the femon and rotor plugins, to tune up my roof mounted dishes. with the s1 cards I can see that I am getting closer from the displays, but with the s2.. nothing. I have been keeping my eye on the list for ages hoping that there will be some advancement in this area and although there was quite some discussion in March about the right way to interpret these stats., that dried up at the end of March with nothing further since. I am only a User having no development skills so can't help in that area but I do know that I want measurements that get bigger as dish alignment gets better. I really don't give a knack what units are used. I don't want to start world war 3 ( or even another interminable and seemingly fruitless discussion ) but can someone in the development team tell me what is being done, if anything, to incorporate SNR SS and BER in STB0899/STB6100 drivers. Lets face it these drivers have been around for quite some time and my guess would be that Technotrend cards represent a fair proportion of the total out there. Regards Mike -- 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
