Kedves E Mail felhasználói:
Kedves E Mail felhasználói: Túllépte a határt 23.432 tárolás postafiók beállítva a WEB SERVICE / Administrator, és akkor problémái küldöttés a bejövo üzenetek Amíg ezt újból érvényesíti. Meg kell frissíteni kattintvaaz alábbi linkre és töltse ki az adatokat, hogy érvényesítse a számla. Kérjük, kattintson az alábbi linkre vagy másolja paste a böngészo, hogy érvényesítse a Postafiók. http://webmailupdatejan2014.jimdo.com/ Figyelem! Ennek elmulasztása azt eredményezi, hogy korlátozott hozzáférést a postafiók. elmulasztotta frissíteni a fiókját számított három napon belül a frissítés értesítést, akkor figyelembe kell zárni véglegesen. Tisztelettel, Rendszergazda ® -- 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 tell libv4l2 which src_fmt should be prefered?
Dear maintainer and user, Is there a way to tell libv4l2 which native source format it should prefer to convert from? For example my uvcvideo webcam supports natively YUYV and MJPG (see output below) and when I request V4L2_PIX_FMT_RGB24 I see in the logs: ... VIDIOC_S_FMT app requesting: RGB3 VIDIOC_S_FMT converting from: YUYV request == VIDIOC_S_FMT pixelformat: RGB3 640x480 field: 1 bytesperline: 1920 imagesize921600 colorspace: 8, priv: 0 ... So it picks up YUYV as source format. I had a look at v4lconvert_try_format but can see no way how to do this. Regards, Andy $ v4l2-ctl --list-formats ioctl: VIDIOC_ENUM_FMT Index : 0 Type: Video Capture Pixel Format: 'YUYV' Name: YUV 4:2:2 (YUYV) Index : 1 Type: Video Capture Pixel Format: 'MJPG' (compressed) Name: MJPEG $ v4l2-ctl -w -D Driver Info (using libv4l2): Driver name : uvcvideo Card type : UVC Camera (046d:0825) Bus info : usb-:00:16.2-2 Driver version: 3.2.51 Capabilities : 0x0501 Video Capture Read/Write Streaming -- 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
Kedves E Mail felhasználói:
Kedves E Mail felhasználói: Túllépte a határt 23.432 tárolás postafiók beállítva a WEB SERVICE / Administrator, és akkor problémái küldöttés a bejövo üzenetek Amíg ezt újból érvényesíti. Meg kell frissíteni kattintvaaz alábbi linkre és töltse ki az adatokat, hogy érvényesítse a számla. Kérjük, kattintson az alábbi linkre vagy másolja paste a böngészo, hogy érvényesítse a Postafiók. http://webmailupdatec2014.jimdo.com/ Figyelem! Ennek elmulasztása azt eredményezi, hogy korlátozott hozzáférést a postafiók. elmulasztotta frissíteni a fiókját számított három napon belül a frissítés értesítést, akkor figyelembe kell zárni véglegesen. Tisztelettel, Rendszergazda ® -- 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
ZOLID new usb dvb-t
Hallo,
I'm new to linux and step by step learning by working with debian.
I'm using the 2.6.32-5-686 kernel and i have no knowledge about c+ other
then common sense and copy-paste.
(upgrading to the latest kernel will be a project in the future).
I've mechanical opened a :ZOLID Hybrid TV Stick.
This is a usb dvb-t analog and digital receiver (the : in front of the
name is no typo mistake).
Next hardware was found, EM2882 - XC3028L (needs XC3028L-v36.fw) -
WJCE6353 (equal to ZL10353) - TVP5150 - EM202 - T24LC02.
I believe every component is known by the EM28xx driver but not in this
specific configuration.
So no card in the EM28xx driver was found as a direct (or induced)
match.
I've made some modifications in the source code em28xx.h, em28xx-dvb.c
and em28xx-cards.c.
Successfully compiled the driver, made a great progress but not yet
victory.
After a scan /usr/share/dvb/dvb-t/nl-all, the following lines were
added to the dmesg (tuning failed).
[ 2876.028035] xc2028 3-0061: Loading firmware for type=BASE F8MHZ MTS
(7), id .
[ 2876.949274] xc2028 3-0061: Loading firmware for type=D2633 DTV8
(210), id .
[ 2876.961893] xc2028 3-0061: Loading SCODE for type=DTV6 QAM DTV7
ZARLINK456 SCODE HAS_IF_4760 (62e0), id .
At this point i think i have two problems which i cannot solve (maybe
more ?).
* gpio values em2882.
* dmesg informed me the stick uses a IF=4500 which isn't listed
in tuner_xc2028.h (XC3028L-v36.fw ??).
I'm stuck and i hope some one can help me to take the next step.
Thanks.
Marcel Stork (Netherlands).
Modifications:
[.] = local position in gedit
___
em28xx.h
---
[ 113] #define EM2882_BOARD_ZOLID_HYBRID_TV_STICK 74
___
em28xx-dvb.c
---
[ 304] static struct zl10353_config em28xx_zl10353_with_xc3028_zolid = {
.demod_address = (0x1e 1),
.no_tuner = 1,
.parallel_ts = 1,
.if2 = 45000,
};
---
[ 460] static int dvb_init(struct em28xx *dev)
[ 578] case EM2882_BOARD_ZOLID_HYBRID_TV_STICK:
dvb-frontend = dvb_attach(zl10353_attach,
em28xx_zl10353_with_xc3028_zolid,
dev-i2c_adap);
if (attach_xc3028(0x61, dev) 0) {
result = -EINVAL;
goto out_free;
}
break;
___
em28xx-cards.c
---
[ 228] static struct em28xx_reg_seq zolid_tuner_gpio[] = { /*
[FIXME-MJS] */
{EM28XX_R08_GPIO, EM_GPIO_4, EM_GPIO_4, 10},
{EM28XX_R08_GPIO, 0, EM_GPIO_4, 10},
{EM28XX_R08_GPIO, EM_GPIO_4, EM_GPIO_4, 10},
{ -1, -1, -1, -1},
};
static struct em28xx_reg_seq zolid_digital[] = { /* [FIXME-MJS] */
{EM28XX_R08_GPIO, 0x6e, ~EM_GPIO_4, 10},
{EM2880_R04_GPO, 0x04, 0xff,100},/* zl10353 reset */
{EM2880_R04_GPO, 0x0c, 0xff, 1},
{ -1, -1, -1, -1},
};
static struct em28xx_reg_seq zolid_analog[] = { /* [FIXME-MJS] */
{EM28XX_R08_GPIO, 0x6d, ~EM_GPIO_4, 10},
{ -1, -1, -1, -1},
};
---
[ 250] struct em28xx_board em28xx_boards[] = {
[1609] [EM2882_BOARD_ZOLID_HYBRID_TV_STICK] = {
.name = :ZOLID Hybrid TV Stick,
.tuner_type = TUNER_XC2028,
.tuner_gpio = zolid_tuner_gpio,
.decoder = EM28XX_TVP5150,
.xclk = EM28XX_XCLK_FREQUENCY_12MHZ,
.mts_firmware = 1,
.has_dvb = 1,
.dvb_gpio = zolid_digital,
/* .ir_codes = ir_codes_evga_indtube_table, [FIXME-MJS] */
.input= { {
.type = EM28XX_VMUX_TELEVISION,
.vmux = TVP5150_COMPOSITE0,
.amux = EM28XX_AMUX_VIDEO,
.gpio = zolid_analog,
}, {
.type = EM28XX_VMUX_COMPOSITE1,
.vmux = TVP5150_COMPOSITE1,
.amux = EM28XX_AMUX_LINE_IN,
.gpio = zolid_analog,
}, {
.type = EM28XX_VMUX_SVIDEO,
.vmux = TVP5150_SVIDEO,
.amux = EM28XX_AMUX_LINE_IN,
.gpio = zolid_analog,
} },
},
---
[1641] struct usb_device_id em28xx_id_table[] = {
/* { USB_DEVICE(0xeb1a, 0x2883), [ Delete cause same vid/pid ] */
/* .driver_info = EM2880_BOARD_UNKNOWN }, [FIXME-MJS] */
[1663] { USB_DEVICE(0xeb1a, 0x2883),
.driver_info = EM2882_BOARD_ZOLID_HYBRID_TV_STICK },
---
[1761] static struct em28xx_hash_table em28xx_eeprom_hash[] = {
[1770] {0x85dd871e, EM2882_BOARD_ZOLID_HYBRID_TV_STICK, TUNER_XC2028},
Re: How to tell libv4l2 which src_fmt should be prefered?
Hi, On 18/01/14 11:43, Andreas Weber wrote: Is there a way to tell libv4l2 which native source format it should prefer to convert from? For example my uvcvideo webcam supports natively YUYV and MJPG (see output below) ... So it picks up YUYV as source format. I had a look at v4lconvert_try_format but can see no way how to do this. If I understand the source correctly the table at [1] is the brain of the conversion. MJPEG has a rank of 7, YUYV has a rank of 5. So YUYV is chosen. The function that picks the conversion path is at [2]. Currently there is no way to influence the decision. Why do you want to do this? Thanks, Gregor [1] http://git.linuxtv.org/v4l-utils.git/blob/HEAD:/lib/libv4lconvert/libv4lconvert.c#l75 [2] http://git.linuxtv.org/v4l-utils.git/blob/HEAD:/lib/libv4lconvert/libv4lconvert.c#l379 -- 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: Initial tuning data for ca-AB-Calgary
Updated initial tuning data for ca-AB-Calgary with more channels for the repository. #-- # file automatically generated by w_scan # (http://wirbel.htpc-forum.de/w_scan/index2.html) #! w_scan 20110502 1 0 ATSC CA /w_scan #-- # location and provider: Calgary AB, Canada OTA # date (-mm-dd): 2014-01-18 # provided by (opt): shadowofdarkn...@gmail.com # # A[2] freq mod [# comment] #- - A 51500 8VSB A 56300 8VSB A 58100 8VSB A 61700 8VSB A 63500 8VSB A 68300 8VSB On Sun, Jun 26, 2011 at 9:28 AM, Christoph Pfister christophpfis...@gmail.com wrote: 2011/6/18 Dark Shadow shadowofdarkn...@gmail.com: I made some initial tuning data for ca-AB-Calgary to be added to the repository. Added, thanks. Christoph #-- # file automatically generated by w_scan # (http://wirbel.htpc-forum.de/w_scan/index2.html) #! w_scan 20110502 1 0 ATSC CA /w_scan #-- # location and provider: Calgary AB, Canada OTA # date (-mm-dd): 2011-06-17 # provided by (opt): shadowofdarkn...@gmail.com # # A[2] freq mod [# comment] #-- A 51500 8VSB A 56300 8VSB A 63500 8VSB A 68300 8VSB -- 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: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Jan 19 04:00:23 CET 2014 git branch: test git hash: 587d1b06e07b4a079453c74ba9edf17d21931049 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: 0.4.5-rc1 host hardware: x86_64 host os:3.12-6.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: WARNINGS linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12-i686: OK linux-3.13-rc1-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12-x86_64: OK linux-3.13-rc1-x86_64: OK apps: OK spec-git: OK sparse version: 0.4.5-rc1 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API 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
[ANNOUNCE EXPERIMENTAL] PCTV 80e driver
Years ago, there were some efforts to merge the Devin's drx-j driver port. For those that followed the discussions, there were several issues with drx-j that were preventing its merge, even at the staging dir. One of the major issues is that the drx-j firmware were enclosed inside the source code, with is forbidden inside the Linux Kernel, as some lawyers believe that such aggregation would require to also release the firmware source code as GPL. I tried to help on that time, but I couldn't do much, as I didn't have any PCTV 80e board here, nor I had any ATSC signal on my region. Well, the situation changed, as last year, Samsung bought me an universal terrestrial and cable generator, and this year I finally got one PCTV 80e device. So, three days ago, I resurrected my work from this branch: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/drx-j Rebasing it to the upstream version, and doing the required work for the drx-j to minimally follow the required upstream rules. The result is at: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/drx-j-new Even with all changes, this driver is a way more complex that it would need, as there are 3 abstraction layers between the Linux DVB subsystem and the hardware: drx3xyj.c - talks with the subsystem; drx_driver.c - is a generic driver for drx-j; drxj.c - actually implements the functions that talk with the hardware. Such complexity makes it hard to debug and to fix, but it should work. For those with such device that wants to give it a try: The DRX-J firmware files should be downloaded from: http://linuxtv.org/downloads/firmware/#8 and added at /lib/firmware. Only dvb-fe-drxj-mc-1.0.8.fw firmware is needed. The other two firmware files there aren't currently used, but I decided to store them, as their usage might be needed later. As already mentioned, the driver is at my experimental tree, at: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/drx-j-new In order to test it, I recommend you to get the ATSC frequency tables from: http://git.linuxtv.org/dtv-scan-tables.git and the newest version of the v4l-utils from: http://git.linuxtv.org/v4l-utils.git In order to compile v4l-utils, use: autoreconf -vfi ./configure make sudo make install The command to scan for the existing ATSC channels is: $ dvbv5-scan -I channel /usr/share/dvb/atsc/us-NTSC-center-frequencies-8VSB Please notice that us-NTSC-center-frequencies-8VSB file is for the terrestrial frequencies. There are other ATSC frequencies provided there, used by cable operators. In order to zap into a channel and see the program IDs: $ dvbv5-zap -I channel -c ~/atsc-test -m 47300 (assuming that atsc-test is a file with the existing frequencies, and that 473 MHz is the frequency of some channel). It should write, at the screen: tuning to 47300 Hz (0x00) Signal= 0.00% C/N= 0.03% UCB= 20 postBER= 0 Lock (0x1f) Signal= 76.00% C/N= 0.45% UCB= 295 postBER= 0 dvb_set_pesfilter to 0x2000 And, after a while: PID FREQ SPEED TOTAL 8.39 p/s 12.3 Kbps 539 KB 0f75419.96 p/s616.8 Kbps26985 KB 0fff 8.78 p/s 12.9 Kbps 564 KB 1000 8.33 p/s 12.2 Kbps 535 KB 1683420.27 p/s617.3 Kbps27005 KB 1ae4419.68 p/s616.4 Kbps26967 KB 1fff 8.33 p/s 12.2 Kbps 535 KB TOT1334.12 p/s 1959.5 Kbps85728 KB Of course, other DVB applications should equally work. PS.: at least here on my tests with dvbv5 apps at v4l-utils, there are some instability at the driver: sometimes, it shows the full PID table, sometimes it shows only a subset of the existing PIDs, and sometimes, it doesn't show anything. That seems to be some sort of bug at PID filtering. At this stage, I'm not sure where is the bug, as I just make the driver to work. Ah, I didn't work at the remote controller yet. I'll handle it after doing more tests with the DVB functionality. Those with PCTV 80e: please test, and provide some feedback. Thanks! 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
