Re: [RFC] dvb-apps ported for ISDB-T
Em 24-12-2009 00:17, Mauro Carvalho Chehab escreveu: > I wrote several patches those days in order to allow dvb-apps to properly > parse ISDB-T channel.conf. > > On ISDB-T, there are several new parameters, so the parsing is more complex > than all the other currently supported video standards. > > I've added the changes at: > > http://linuxtv.org/hg/~mchehab/dvb-apps-isdbt/ > > I've merged there Patrick's dvb-apps-isdbt tree. > > While there, I fixed a few bugs I noticed on the parser and converted it > to work with the DVB API v5 headers that are bundled together with dvb-apps. > This helps to avoid adding lots of extra #if DVB_ABI_VERSION tests. The ones > there can now be removed. > > TODO: > = > > The new ISDB-T parameters are parsed, but I haven't add yet a code to make > them to be used; > > There are 3 optional parameters with ISDB-T, related to 1seg/3seg: the > segment parameters. Currently, the parser will fail if those parameters are > found. > > gnutv is still reporting ISDB-T as "DVB-T". > I've just fixed the issues on the TODO list. The DVB v5 code is now working fine for ISDB-T. Pending stuff (patches are welcome): - Implement v5 calls for other video standards; - Remove the duplicated DVBv5 code on /util/scan/scan.c (the code for calling DVBv5 is now at /lib/libdvbapi/v5api.c); - Test/use the functions to retrieve values via DVBv5 API. The function is already there, but I haven't tested. With the DVBv5 API implementation, zap is now working properly with ISDB-T. gnutv also works (although some outputs - like decoder - may need some changes, in order to work with mpeg4/AAC video/audio codecs). Have fun! 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
How to know which camera is /dev/videoX
Dear Guennadi Now my board (EcoVec) can use 2 soc-camera (mt9t112 / tw9910), and mt9t112 can attach/detach. If mt9t112 is attached, /dev/video0 = mt9t112 /dev/video1 = tw9910 But if mt9t112 is detached, it will /dev/video0 = tw9910 Now I would like to know which camera is /dev/video0. my /dev/video0 is > ls -l /dev/video0 > crw--w 1 root 1000 81, 0 Jun 9 2009 /dev/video0 I cheked 81:0 's name > cat /sys/dev/char/81\:0/name > sh_mobile_ceu.1 Above name is host of soc-camera for me. Are there any way to know camera name (mt9t112/tw9910) ? Best regards -- Kuninori Morimoto -- 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
Dev help
Hi All, I'm just wondering if someone can point me in the direction of maybe either some documents or a good driver code to look at to understand how to write the drivers for cards etc. As some might have seen as playing with the terratec cinergy 2400i which has an old driver and am gonna have a play and see if i can get it working. Not sure if my coding would be good enough to submit to yourselves at the moment, but if there is a document to read, as current I dont understand how the PCI-e bridge loads and then loads the demod module and tuner and how it all links together... So any documents and maybe an example modules that loads a bridge / demod then tuner so i can understand would be great. Cheers for any help. -- 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
Bad image/sound quality with Medion MD 95700
Hi, I tried a Medion MD 95700 with kernel 2.6.32 (for tests: 2.6.30.9) and have a very bad image and sound quality. Right now I'm using 2.6.32 with V4L/DVB from SVN (v4l-dvb-4506e2d54126) Here is an example: http://img200.imageshack.us/img200/3950/dvbtlinux.png and another: http://img130.imageshack.us/img130/6278/dvbt2.png The DVB-T stream seems to be good: femon FE: Conexant CX22702 DVB-T (DVBT) status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK (it's a bit bad right now, normally the signal is around 50%) under windows XP the image and sound is perfect. P.S. this is the output from mplayer after looking DVB-T for a few seconds: mplayer "dvb://ProSieben(ProSiebenSat.1)" MPlayer SVN-r29796-4.4.2 (C) 2000-2009 MPlayer Team Spiele dvb://ProSieben(ProSiebenSat.1). dvb_tune Freq: 69000 TS-Dateiformat erkannt! VIDEO MPEG2(pid=511) AUDIO MPA(pid=512) NO SUBS (yet)! PROGRAM N. 0 VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 15000.0 kbps (1875.0 kbyte/s) == Öffne Videodecoder: [mpegpes] MPEG 1/2 Video passthrough Konnte keinen passenden Farbraum finden - neuer Versuch mit '-vf scale'... Öffne Videofilter: [scale] Der ausgewählte Videoausgabetreiber ist nicht kompatibel mit diesem Codec. Versuche den scale-Filter zu deiner Filterliste hinzuzufügen, z.B. mit -vf spp,scale an Stelle von -vf spp. Initialisierung des Videodecoders fehlgeschlagen :( Öffne Videodecoder: [ffmpeg] FFmpeg's libavcodec codec family Unsupported PixelFormat -1 Ausgewählter Videocodec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2) == == Öffne Audiodecoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000) Ausgewählter Audiocodec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) == AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starte Wiedergabe... Film-Aspekt ist 1,78:1 - Vorskalierung zur Korrektur der Seitenverhältnisse. VO: [xv] 720x576 => 1024x576 Planar YV12 [mpeg2video @ 0xc62be0]ac-tex damaged at 23 4 [mpeg2video @ 0xc62be0]ac-tex damaged at 14 9 [mpeg2video @ 0xc62be0]skipped MB in I frame at 40 10 [mpeg2video @ 0xc62be0]invalid mb type in I Frame at 29 15 [mpeg2video @ 0xc62be0]skipped MB in I frame at 32 19 [mpeg2video @ 0xc62be0]ac-tex damaged at 34 33 [mpeg2video @ 0xc62be0]Warning MVs not available [mpeg2video @ 0xc62be0]concealing 319 DC, 319 AC, 319 MV errors [mpeg2video @ 0xc62be0]concealing 319 DC, 319 AC, 319 MV errors?% 0 0 [mpeg2video @ 0xc62be0]concealing 319 DC, 319 AC, 319 MV errors% 0 0 [mpeg2video @ 0xc62be0]mb incr damaged,008 3/ 3 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]00 motion_type at 27 17 [mpeg2video @ 0xc62be0]Warning MVs not available [mpeg2video @ 0xc62be0]concealing 98 DC, 98 AC, 98 MV errors [mpeg2video @ 0xc62be0]00 motion_type at 34 54/ 4 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]Warning MVs not available [mpeg2video @ 0xc62be0]concealing 90 DC, 90 AC, 90 MV errors [mpeg2video @ 0xc62be0]00 motion_type at 35 95/ 5 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]concealing 90 DC, 90 AC, 90 MV errors [mpeg2video @ 0xc62be0]ac-tex damaged at 36 86/ 6 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]invalid cbp at 25 13 [mpeg2video @ 0xc62be0]ac-tex damaged at 4 23 [mpeg2video @ 0xc62be0]concealing 157 DC, 157 AC, 157 MV errors [mpeg2video @ 0xc62be0]00 motion_type at 8 8 7/ 7 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]concealing 90 DC, 90 AC, 90 MV errors [mpeg2video @ 0xc62be0]concealing 50 DC, 50 AC, 50 MV errors?,?% 0 0 Bindung für Taste 'c' nicht gefunden. ?% 0 0 [mpeg2video @ 0xc62be0]invalid mb type in P Frame at 4 16 [mpeg2video @ 0xc62be0]concealing 45 DC, 45 AC, 45 MV errors [mpeg2video @ 0xc62be0]invalid mb type in B Frame at 0 31% ??,?% 0 0 [mpeg2video @ 0xc62be0]concealing 225 DC, 225 AC, 225 MV errors [mpeg2video @ 0xc62be0]mb incr damaged,040 11/ 11 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]invalid cbp at 28 30 [mpeg2video @ 0xc62be0]concealing 203 DC, 203 AC, 203 MV errors [mpeg2video @ 0xc62be0]ac-tex damaged at 24 72/ 12 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]skipped MB in I frame at 6 12 [mpeg2video @ 0xc62be0]skipped MB in I frame at 1 19 [mpeg2video @ 0xc62be0]skipped MB in I frame at 23 25 [mpeg2video @ 0xc62be0]conce
Feature Request: virtual /dev/videoX for low budget DVB cards
What about a virtual /dev/videoX for low budget DVB cards? The idea behind is to provide a device set with every type of card (low budget, full featured) so that for example tvtime works with every type of card. The virtual device could be made by the following way: kernel driver (low budget, DVB-Decoded) -> kernel/userspace linker -> userspace decoder -> kernel/userspace linker -> kernel-driver (low budget, DVB-Encoded) I'm not a developer so (maybe) that's just a stupid idea. -- 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
Bad image quality with Medion MD 95700
Hi, I tried a Medion MD 95700 with kernel 2.6.32 (for tests: 2.6.30.9) and have a very bad image and sound quality. Right now I'm using 2.6.32 with V4L/DVB from SVN (v4l-dvb-4506e2d54126) Here is an example: http://img200.imageshack.us/img200/3950/dvbtlinux.png and another: http://img130.imageshack.us/img130/6278/dvbt2.png The DVB-T stream seems to be good: femon FE: Conexant CX22702 DVB-T (DVBT) status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK status SCVYL | signal 6565 | snr | ber | unc | FE_HAS_LOCK (it's a bit bad right now, normally the signal is around 50%) under windows XP the image and sound is perfect. P.S. this is the output from mplayer after looking DVB-T for a few seconds: mplayer "dvb://ProSieben(ProSiebenSat.1)" MPlayer SVN-r29796-4.4.2 (C) 2000-2009 MPlayer Team Spiele dvb://ProSieben(ProSiebenSat.1). dvb_tune Freq: 69000 TS-Dateiformat erkannt! VIDEO MPEG2(pid=511) AUDIO MPA(pid=512) NO SUBS (yet)! PROGRAM N. 0 VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 15000.0 kbps (1875.0 kbyte/s) == Öffne Videodecoder: [mpegpes] MPEG 1/2 Video passthrough Konnte keinen passenden Farbraum finden - neuer Versuch mit '-vf scale'... Öffne Videofilter: [scale] Der ausgewählte Videoausgabetreiber ist nicht kompatibel mit diesem Codec. Versuche den scale-Filter zu deiner Filterliste hinzuzufügen, z.B. mit -vf spp,scale an Stelle von -vf spp. Initialisierung des Videodecoders fehlgeschlagen :( Öffne Videodecoder: [ffmpeg] FFmpeg's libavcodec codec family Unsupported PixelFormat -1 Ausgewählter Videocodec: [ffmpeg2] vfm: ffmpeg (FFmpeg MPEG-2) == == Öffne Audiodecoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000) Ausgewählter Audiocodec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) == AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample) Starte Wiedergabe... Film-Aspekt ist 1,78:1 - Vorskalierung zur Korrektur der Seitenverhältnisse. VO: [xv] 720x576 => 1024x576 Planar YV12 [mpeg2video @ 0xc62be0]ac-tex damaged at 23 4 [mpeg2video @ 0xc62be0]ac-tex damaged at 14 9 [mpeg2video @ 0xc62be0]skipped MB in I frame at 40 10 [mpeg2video @ 0xc62be0]invalid mb type in I Frame at 29 15 [mpeg2video @ 0xc62be0]skipped MB in I frame at 32 19 [mpeg2video @ 0xc62be0]ac-tex damaged at 34 33 [mpeg2video @ 0xc62be0]Warning MVs not available [mpeg2video @ 0xc62be0]concealing 319 DC, 319 AC, 319 MV errors [mpeg2video @ 0xc62be0]concealing 319 DC, 319 AC, 319 MV errors?% 0 0 [mpeg2video @ 0xc62be0]concealing 319 DC, 319 AC, 319 MV errors% 0 0 [mpeg2video @ 0xc62be0]mb incr damaged,008 3/ 3 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]00 motion_type at 27 17 [mpeg2video @ 0xc62be0]Warning MVs not available [mpeg2video @ 0xc62be0]concealing 98 DC, 98 AC, 98 MV errors [mpeg2video @ 0xc62be0]00 motion_type at 34 54/ 4 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]Warning MVs not available [mpeg2video @ 0xc62be0]concealing 90 DC, 90 AC, 90 MV errors [mpeg2video @ 0xc62be0]00 motion_type at 35 95/ 5 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]concealing 90 DC, 90 AC, 90 MV errors [mpeg2video @ 0xc62be0]ac-tex damaged at 36 86/ 6 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]invalid cbp at 25 13 [mpeg2video @ 0xc62be0]ac-tex damaged at 4 23 [mpeg2video @ 0xc62be0]concealing 157 DC, 157 AC, 157 MV errors [mpeg2video @ 0xc62be0]00 motion_type at 8 8 7/ 7 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]concealing 90 DC, 90 AC, 90 MV errors [mpeg2video @ 0xc62be0]concealing 50 DC, 50 AC, 50 MV errors?,?% 0 0 Bindung für Taste 'c' nicht gefunden. ?% 0 0 [mpeg2video @ 0xc62be0]invalid mb type in P Frame at 4 16 [mpeg2video @ 0xc62be0]concealing 45 DC, 45 AC, 45 MV errors [mpeg2video @ 0xc62be0]invalid mb type in B Frame at 0 31% ??,?% 0 0 [mpeg2video @ 0xc62be0]concealing 225 DC, 225 AC, 225 MV errors [mpeg2video @ 0xc62be0]mb incr damaged,040 11/ 11 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]invalid cbp at 28 30 [mpeg2video @ 0xc62be0]concealing 203 DC, 203 AC, 203 MV errors [mpeg2video @ 0xc62be0]ac-tex damaged at 24 72/ 12 ??% ??% ??,?% 0 0 [mpeg2video @ 0xc62be0]skipped MB in I frame at 6 12 [mpeg2video @ 0xc62be0]skipped MB in I frame at 1 19 [mpeg2video @ 0xc62be0]skipped MB in I frame at 23 25 [mpeg2video @ 0xc62be0]concea
Re: [ivtv-devel] PVR150 Tinny/fuzzy audio w/ patch?
Hi everybody and Merry Christmas, Andy Walls wrote: > I have a version of the change for the ivtv/PVR-150 tinny audio fix at > > http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix > http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix/rev/7753cdcebd28 > > > It separates out the enable/disable of audio & video streaming from each > other for the cx25840 module. Then the ivtv driver can set them > independently to avoid both the unpredictable PCI hang and the tinny > audio in a very generic way. Please test when you can. @ Andy: now we have a second 300ms delay in ivtv-streams.c 2.6/* Initialize Digitizer for Capture */ 2.7 + /* Avoid tinny audio problem - ensure audio clocks are going */ 2.8 + v4l2_subdev_call(itv->sd_audio, audio, s_stream, 1); 2.9 + /* Avoid unpredictable PCI bus hang - disable video clocks */ 2.10v4l2_subdev_call(itv->sd_video, video, s_stream, 0); 2.11ivtv_msleep_timeout(300, 1); 2.12ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0); 2.13v4l2_subdev_call(itv->sd_video, video, s_stream, 1); 2.14 + ivtv_msleep_timeout(300, 1); This would increase the time for channel switching (using encoder stop/start) noticeable. My suggestion was to move the 300ms sleep at the point after the stream is re-enabled, so we don't need the first msleep. I have not tested your code, hope I can do this during the next days. > > Mike, > > I had to add another subdev call to pvrusb2 to get the same end result > of s_stream calls to the cx25840 module. > @ Mike: do you remember my posting in the pvrusb2 list about sporadic black screen after starting a stream? We had the same problem in ivtv, and the 300ms sleep after disabling the digitizer solved the problem. I implemented this in a similary way in the pvrusb2 driver and the problem never appeared again: --- v4l-dvb-309f16461cf4-orig/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c 2009-12-05 13:34:21.0 +0100 +++ v4l-dvb-309f16461cf4-patched/linux/drivers/media/video/pvrusb2/pvrusb2- hdw.c 2009-12-24 22:42:49.746899065 +0100 @@ -4689,6 +4689,7 @@ del_timer_sync(&hdw->quiescent_timer); if (hdw->flag_decoder_missed) return 0; if (pvr2_decoder_enable(hdw,!0) < 0) return 0; + msleep(300); hdw->state_decoder_quiescent = 0; hdw->state_decoder_run = !0; } My initial idea was to avoid disabling/enabling the digitizer for devices with cx2584x-digitizer. Channel changing (using encoder stop/start) with a PVR150 and HVR1900 took always about a second longer than with saa7115-based devices. Without disabling/enabling the digitizer around the CX2341X_ENC_INITIALIZE_INPUT call it speeds up noticeable. So this is the alternate patch for the pvrusb2 driver (similar code for ivtv was in my last posting which Andy had in his mail): --- v4l-dvb-309f16461cf4-orig/linux/drivers/media/video/pvrusb2/pvrusb2-hdw.c 2009-12-05 13:34:21.0 +0100 +++ v4l-dvb-309f16461cf4-patched/linux/drivers/media/video/pvrusb2/pvrusb2- hdw.c 2009-12-24 22:48:03.481899379 +0100 @@ -4646,9 +4646,9 @@ !hdw->state_pipeline_pause && hdw->state_pathway_ok) return 0; } - if (!hdw->flag_decoder_missed) { - pvr2_decoder_enable(hdw,0); - } +if (hdw->decoder_client_id != PVR2_CLIENT_ID_CX25840 && !hdw- >flag_decoder_missed) { + pvr2_decoder_enable(hdw,0); +} hdw->state_decoder_quiescent = 0; hdw->state_decoder_run = 0; /* paranoia - solve race if timer just completed */ @@ -4688,7 +4688,10 @@ !hdw->state_encoder_ok) return 0; del_timer_sync(&hdw->quiescent_timer); if (hdw->flag_decoder_missed) return 0; - if (pvr2_decoder_enable(hdw,!0) < 0) return 0; +if (hdw->decoder_client_id != PVR2_CLIENT_ID_CX25840) { + if (pvr2_decoder_enable(hdw,!0) < 0) return 0; +msleep(300); +} hdw->state_decoder_quiescent = 0; hdw->state_decoder_run = !0; } It works fine with a HVR 1900, but should be tested with a PVRUSB2 model 24xxx. Greets, Martin -- 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
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:Thu Dec 24 19:00:07 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13842:4506e2d54126 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.32-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: ERRORS linux-2.6.28-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30-i686: ERRORS linux-2.6.31-i686: ERRORS linux-2.6.32-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS spec: OK sparse (linux-2.6.32): ERRORS linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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: Which modules for the VP-2033? Where is the module "mantis.ko"?
On čet, 2009-12-24 at 17:45 +0100, Ruediger Dohmhardt wrote: > Aljaž, thanks for the "reply". As Manu said above there was a build problem. > As said already in this Thread, I downloaded version 2315248f648c, which > compiles fine and > has all modules for the 2033 DVB-C. I have the same version and it doesn't work for me. I have a 2040 module. -- 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: Which modules for the VP-2033? Where is the module "mantis.ko"?
Aljaž Prusnik schrieb: > On sre, 2009-12-23 at 23:24 +0400, Manu Abraham wrote: > >>> Aljaz, do you have the module mantis.ko? >>> >> There was a build issue when i posted the link originally, but it had >> been fixed.. >> >> m...@manu-04:/stor/work/merge/v4l-dvb/v4l> ls *.ko |grep mantis >> mantis_core.ko >> mantis.ko >> >> > > Yup, I have both of them. I just compiled http://jusst.de/hg/v4l-dvb > again and the result is (depmode -a was run): > > - ir-common.ko is under drivers/media/common (not drivers/media/IR like > Igor suggested but that is probably because it's a different > repository). > - mantis.ko and mantis_core.ko are under drivers/media/dvb/mantis > > Aljaž, thanks for the "reply". As Manu said above there was a build problem. As said already in this Thread, I downloaded version 2315248f648c, which compiles fine and has all modules for the 2033 DVB-C. Rüdiger -- 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: [ivtv-devel] PVR150 Tinny/fuzzy audio w/ patch?
Martin, (Moving discussion to the linux-media list since the ivtv-devel list was unresponsive/dead recently.) On Sun, 2009-12-06 at 19:44 +0100, Martin Dauskardt wrote: > > From: Andy Walls > > Martin, > > > > It is not "turning the digitizer on/off" but really "enable/disable the > > clock output pins of the digitizer". The cause of the tinny audio is > > likely that the clock pins from the CX2584x are floating. > > > > This call makes sure the clock output enables are turned on and the pins > > are not floating. I suspect no where else are they explciity enabled in > > the driver before the first capture (I can go back and verify). > > > > > I am only a hobbyist, so please forgive me if there is an error ... > > > > No that's fine too; as long as *somewhere* in the ivtv driver we turn on > > the CX2584x's output enables before the first capture. > > > > It really seems that no where else the clock output pins are enabled. I did > not find another s_stream call to the digitizer. But amazing: Even I comment > out the line > v4l2_subdev_call(itv->sd_video, video, s_stream, 1); > the stream starts most of the time (but fails occasionally). > > You wrote "I suspect that these signals floating cause the CX23416 to make > some bad guesses about audio sample rate when CX2341X_ENC_INTIALIZE_INPUT is > called. " > Then we have to enable the digitizer before CX2341X_ENC_INTIALIZE_INPUT. > > But the first patch from Argus -which helped him to solve the problem- does > not enable the output. So this is either not necessary or the real problem is > something else. (I made a lot of testing with a PVR150 and an unpatched > driver > and had never any audio problems) > > Unfortunately there was a mistake in my last code. The if-statement has to be > in additionally brackets, otherwise it is never true and the digitizer is not > disabled for saa7115-based card. > > I tested this code now with PVR150 and PVR350: > > if (atomic_read(&itv->capturing) == 0) { > /* Clear all Pending Interrupts */ > ivtv_set_irq_mask(itv, IVTV_IRQ_MASK_CAPTURE); > > clear_bit(IVTV_F_I_EOS, &itv->i_flags); > > /* Turn off non-cx25840 digitizer to avoid flickering */ > if (!(itv->sd_video->grp_id & IVTV_HW_CX25840)) { > v4l2_subdev_call(itv->sd_video, video, s_stream, 0); > } > else { > /* make sure the cx25840 clock output pins are enabled and > not > floating */ > v4l2_subdev_call(itv->sd_video, video, s_stream, 1); > } > > ivtv_vapi(itv, CX2341X_ENC_INITIALIZE_INPUT, 0); > > /* Turn on non-cx25840 digitizer and allow clock >output of the digitizer to stabilize before starting > capture */ > if (!(itv->sd_video->grp_id & IVTV_HW_CX25840)) { > v4l2_subdev_call(itv->sd_video, video, s_stream, 1); > ivtv_msleep_timeout(300, 1); > } > } > > You mentioned that the 300ms sleep is probably needed for the clock output of > the digitizer to stabilize. For me it seems more logical if this is done > after ***enabling*** the digitizer output, so I moved this. It seems to work > fine. > > I made a similar test with the pvrusb2 driver (which has a black video > problem > and currently no timeout sleep after the digitizer switches). There it works > better when we place the sleep after re-enabling the digitizer. So I think > the > above solution should be right. > > I also tested if we can avoid disabling the digitizer for saa7115. Both > pvrusb2 (old model 29xxx) and PVR350 show disturbance (sync problems) when > stopping/starting a stream. This leads to flickering with cx23415 (PVR350). > The cx23416 has no flickering problem, but it is annoying to see sync > problems > during channel switches. > The cx25840 devices (PVR150 and the pvrusb2-based HVR1900) do not show these > problems. The connection to the cx23416 must be different - the new stream > appears always without any snc issues. > > Suggestion: > We need more testers to see if a driver change like above is safe for > everybody. Even if it turns out that it is no reliable fix against tinny > audio, it improves the speed for encoder stop/start on cx25840 devices. > I don't know if Myth is stopping/starting the stream for every channel > switch, > but for vdr (pvrinput-plugin) we are doing this. And there I recognize that > channel switching is faster now with cx25840 devices. > > And we shouldn't do anything without hearing Hans Hans, where are you? > > Greets, > Martin I have a version of the change for the ivtv/PVR-150 tinny audio fix at http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix http://linuxtv.org/hg/~awalls/v4l-dvb-bugfix/rev/7753cdcebd28 It separates out the enable/disabl
Cx88 ( Hauppauge WinTV-HVR-4000 ): can't do zapping.
Hi all, I've a Hauppauge WinTV-HVR-4000 (http://www.hauppauge.co.uk/site/products/data_hvr4000.html http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000), and i use it mainly for DVB-T through vlc and kaffeine in a Gentoo x86_64 and x86 box. The first one is a bit faster in tuning but both have a problem: if i'm watching something i can't change channel directly without stopping the one i'm watching. This also happens with a tzap's based script (http://www.linuxtv.org/wiki/index.php/Testing_reception_quality) which tests signal quality. So i think it is a driver problem (i'm using kernel's one): uname -a : Linux P4 2.6.31-gentoo-r6 #3 SMP PREEMPT Sun Dec 20 09:53:55 CET 2009 x86_64 Intel(R) Pentium(R) 4 CPU 3.00GHz GenuineIntel GNU/Linux lspci -vnn : 02:00.0 Multimedia video controller [0400]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [14f1:8800] (rev 05) Subsystem: Hauppauge computer works Inc. Device [0070:6902] Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at f400 (32-bit, non-prefetchable) [size=16M] Capabilities: [44] Vital Product Data Capabilities: [4c] Power Management version 2 Kernel driver in use: cx8800 Kernel modules: cx8800 02:00.1 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port] [14f1:8801] (rev 05) Subsystem: Hauppauge computer works Inc. Device [0070:6902] Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at f500 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Kernel driver in use: cx88_audio Kernel modules: cx88-alsa 02:00.2 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port] [14f1:8802] (rev 05) Subsystem: Hauppauge computer works Inc. Device [0070:6902] Flags: bus master, medium devsel, latency 32, IRQ 20 Memory at f600 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 Kernel driver in use: cx88-mpeg driver manager Kernel modules: cx8802 02:00.4 Multimedia controller [0480]: Conexant Systems, Inc. CX23880/1/2/3 PCI Video and Audio Decoder [IR Port] [14f1:8804] (rev 05) Subsystem: Hauppauge computer works Inc. Device [0070:6902] Flags: bus master, medium devsel, latency 32, IRQ 9 Memory at f700 (32-bit, non-prefetchable) [size=16M] Capabilities: [4c] Power Management version 2 dmesg: [5.269734] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded [5.269934] cx88[0]: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68,autodetected], frontend(s): 2 [5.269939] cx88[0]: TV tuner type 63, Radio tuner type -1 [5.286188] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded [5.296136] cx2388x alsa driver version 0.0.7 loaded [5.384144] cx88[0]: i2c init: enabling analog demod on HVR1300/3000/4000 tuner [5.837300] tuner 1-0043: chip found @ 0x86 (cx88[0]) [5.837306] tda9887 1-0043: creating new instance [5.837309] tda9887 1-0043: tda988[5/6/7] found [5.843180] tuner 1-0061: chip found @ 0xc2 (cx88[0]) [5.886173] tveeprom 1-0050: Hauppauge model 69009, rev B4D3, serial# 6520465 [5.886180] tveeprom 1-0050: MAC address is 00-0D-FE-63-7E-91 [5.886185] tveeprom 1-0050: tuner model is Philips FMD1216MEX (idx 133, type 78) [5.886190] tveeprom 1-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4) [5.886195] tveeprom 1-0050: audio processor is CX880 (idx 30) [5.886199] tveeprom 1-0050: decoder processor is CX880 (idx 20) [5.886203] tveeprom 1-0050: has radio, has IR receiver, has no IR transmitter [5.886206] cx88[0]: hauppauge eeprom: model=69009 [5.886692] tuner-simple 1-0061: creating new instance [5.886697] tuner-simple 1-0061: type set to 78 (Philips FMD1216MEX MK3 Hybrid Tuner) [5.891595] input: cx88 IR (Hauppauge WinTV-HVR400 as /devices/pci:00/:00:1e.0/:02:00.2/input/input4 [5.891726] cx88[0]/2: cx2388x 8802 Driver Manager [5.891748] cx88-mpeg driver manager :02:00.2: PCI INT A -> GSI 20 (level, low) -> IRQ 20 [5.891760] cx88[0]/2: found at :02:00.2, rev: 5, irq: 20, latency: 32, mmio: 0xf600 [5.891768] IRQ 20/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs [5.891821] cx8800 :02:00.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20 [5.891830] cx88[0]/0: found at :02:00.0, rev: 5, irq: 20, latency: 32, mmio: 0xf400 [5.891841] IRQ 20/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs [5.963166] wm8775 1-001b: chip found @ 0x36 (cx88[0]) [5.970089] cx88[0]/0: registered device video0 [v4l2] [5.970137] cx88[0]/0: registered device vbi0 [5.970184] cx88[0]/0: registered device radio0 [5.986679] cx88_audio :02:00.1: PC
[PATCH] soc-camera: adjust coding style to match V4L preferences
Signed-off-by: Guennadi Liakhovetski --- drivers/media/video/soc_mediabus.c | 45 1 files changed, 30 insertions(+), 15 deletions(-) diff --git a/drivers/media/video/soc_mediabus.c b/drivers/media/video/soc_mediabus.c index f8d5c87..0149290 100644 --- a/drivers/media/video/soc_mediabus.c +++ b/drivers/media/video/soc_mediabus.c @@ -24,91 +24,106 @@ static const struct soc_mbus_pixelfmt mbus_fmt[] = { .bits_per_sample= 8, .packing= SOC_MBUS_PACKING_2X8_PADHI, .order = SOC_MBUS_ORDER_LE, - }, [MBUS_IDX(YVYU8_2X8_LE)] = { + }, + [MBUS_IDX(YVYU8_2X8_LE)] = { .fourcc = V4L2_PIX_FMT_YVYU, .name = "YVYU", .bits_per_sample= 8, .packing= SOC_MBUS_PACKING_2X8_PADHI, .order = SOC_MBUS_ORDER_LE, - }, [MBUS_IDX(YUYV8_2X8_BE)] = { + }, + [MBUS_IDX(YUYV8_2X8_BE)] = { .fourcc = V4L2_PIX_FMT_UYVY, .name = "UYVY", .bits_per_sample= 8, .packing= SOC_MBUS_PACKING_2X8_PADHI, .order = SOC_MBUS_ORDER_LE, - }, [MBUS_IDX(YVYU8_2X8_BE)] = { + }, + [MBUS_IDX(YVYU8_2X8_BE)] = { .fourcc = V4L2_PIX_FMT_VYUY, .name = "VYUY", .bits_per_sample= 8, .packing= SOC_MBUS_PACKING_2X8_PADHI, .order = SOC_MBUS_ORDER_LE, - }, [MBUS_IDX(RGB555_2X8_PADHI_LE)] = { + }, + [MBUS_IDX(RGB555_2X8_PADHI_LE)] = { .fourcc = V4L2_PIX_FMT_RGB555, .name = "RGB555", .bits_per_sample= 8, .packing= SOC_MBUS_PACKING_2X8_PADHI, .order = SOC_MBUS_ORDER_LE, - }, [MBUS_IDX(RGB555_2X8_PADHI_BE)] = { + }, + [MBUS_IDX(RGB555_2X8_PADHI_BE)] = { .fourcc = V4L2_PIX_FMT_RGB555X, .name = "RGB555X", .bits_per_sample= 8, .packing= SOC_MBUS_PACKING_2X8_PADHI, .order = SOC_MBUS_ORDER_LE, - }, [MBUS_IDX(RGB565_2X8_LE)] = { + }, + [MBUS_IDX(RGB565_2X8_LE)] = { .fourcc = V4L2_PIX_FMT_RGB565, .name = "RGB565", .bits_per_sample= 8, .packing= SOC_MBUS_PACKING_2X8_PADHI, .order = SOC_MBUS_ORDER_LE, - }, [MBUS_IDX(RGB565_2X8_BE)] = { + }, + [MBUS_IDX(RGB565_2X8_BE)] = { .fourcc = V4L2_PIX_FMT_RGB565X, .name = "RGB565X", .bits_per_sample= 8, .packing= SOC_MBUS_PACKING_2X8_PADHI, .order = SOC_MBUS_ORDER_LE, - }, [MBUS_IDX(SBGGR8_1X8)] = { + }, + [MBUS_IDX(SBGGR8_1X8)] = { .fourcc = V4L2_PIX_FMT_SBGGR8, .name = "Bayer 8 BGGR", .bits_per_sample= 8, .packing= SOC_MBUS_PACKING_NONE, .order = SOC_MBUS_ORDER_LE, - }, [MBUS_IDX(SBGGR10_1X10)] = { + }, + [MBUS_IDX(SBGGR10_1X10)] = { .fourcc = V4L2_PIX_FMT_SBGGR10, .name = "Bayer 10 BGGR", .bits_per_sample= 10, .packing= SOC_MBUS_PACKING_EXTEND16, .order = SOC_MBUS_ORDER_LE, - }, [MBUS_IDX(GREY8_1X8)] = { + }, + [MBUS_IDX(GREY8_1X8)] = { .fourcc = V4L2_PIX_FMT_GREY, .name = "Grey", .bits_per_sample= 8, .packing= SOC_MBUS_PACKING_NONE, .order = SOC_MBUS_ORDER_LE, - }, [MBUS_IDX(Y10_1X10)] = { + }, + [MBUS_IDX(Y10_1X10)] = { .fourcc = V4L2_PIX_FMT_Y10, .name = "Grey 10bit", .bits_per_sample= 10, .packing= SOC_MBUS_PACKING_EXTEND16, .order = SOC_MBUS_ORDER_LE, - }, [MBUS_IDX(SBGGR10_2X8_PADHI_LE)] = { + }, + [MBUS_IDX(SBGGR10_2X8_PADHI_LE)] = { .fourcc = V4L2_PIX_FMT_SBGGR10, .name
Re: [PULL] soc-camera and mediabus
Hi Mauro On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote: > Guennadi Liakhovetski wrote: > > > > So, is the doc patch, that I've sent to the list ok? Ok, the hunk for the > > automatically (in hg) generated file will get dropped, and otherwise does > > it look correct? > > It looks correctly on my eyes. The only thing I noticed is that you've added > emacs headers at the end of the new patches: > > + > + > > Please remove those tags when submitting the final version. I tried to just through away the media-specs/media-entities.tmpl hunk, as that file should be auto-generated, but the new version doesn't include the new formats either. What am I doing wrong? The patch attached below. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ # HG changeset patch # User Guennadi Liakhovetski # Date 1261648434 -3600 # Node ID 52e14d4799279a860fe158e8bf4f1993d6c6 # Parent 4506e2d541265bfa0c0fd5187c6a39d39a456559 document new pixel formats Document all four 10-bit Bayer formats, 10-bit monochrome and a missing 8-bit Bayer formats. Signed-off-by: Guennadi Liakhovetski diff -r 4506e2d54126 -r 52e14d479927 linux/Documentation/DocBook/v4l/pixfmt-srggb10.xml --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/linux/Documentation/DocBook/v4l/pixfmt-srggb10.xmlThu Dec 24 10:53:54 2009 +0100 @@ -0,0 +1,90 @@ + + + V4L2_PIX_FMT_SRGGB10 ('RG10'), +V4L2_PIX_FMT_SGRBG10 ('BA10'), +V4L2_PIX_FMT_SGBRG10 ('GB10'), +V4L2_PIX_FMT_SBGGR10 ('BG10'), + + &manvol; + + + V4L2_PIX_FMT_SRGGB10 + V4L2_PIX_FMT_SGRBG10 + V4L2_PIX_FMT_SGBRG10 + V4L2_PIX_FMT_SBGGR10 + 10-bit Bayer formats expanded to 16 bits + + + Description + + The following four pixel formats are raw sRGB / Bayer formats with +10 bits per colour. Each colour component is stored in a 16-bit word, with 6 +unused high bits filled with zeros. Each n-pixel row contains n/2 green samples +and n/2 blue or red samples, with alternating red and blue rows. Bytes are +stored in memory in little endian order. They are conventionally described +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these +formats + + + V4L2_PIX_FMT_SBGGR10 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte, high 6 bits in high bytes are 0. + + + + + + start + 0: + B00low + B00high + G01low + G01high + B02low + B02high + G03low + G03high + + + start + 8: + G10low + G10high + R11low + R11high + G12low + G12high + R13low + R13high + + + start + 16: + B20low + B20high + G21low + G21high + B22low + B22high + G23low + G23high + + + start + 24: + G30low + G30high + R31low + R31high + G32low + G32high + R33low + R33high + + + + + + + + + diff -r 4506e2d54126 -r 52e14d479927 linux/Documentation/DocBook/v4l/pixfmt-srggb8.xml --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/linux/Documentation/DocBook/v4l/pixfmt-srggb8.xml Thu Dec 24 10:53:54 2009 +0100 @@ -0,0 +1,67 @@ + + + V4L2_PIX_FMT_SRGGB8 ('RGGB') + &manvol; + + + V4L2_PIX_FMT_SRGGB8 + Bayer RGB format + + + Description + + This is commonly the native format of digital cameras, +reflecting the arrangement of sensors on the CCD device. Only one red, +green or blue value is given for each pixel. Missing components must +be interpolated from neighbouring pixels. From left to right the first +row consists of a red and green value, the second row of a green and +blue value. This scheme repeats to the right and down for every two +columns and rows. + + + V4L2_PIX_FMT_SRGGB8 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + R00 + G01 + R02 + G03 + + + start + 4: + G10 + B11 +