Hauppauge PVR 150

[mredz]

The wiki reports that this card is now working.
I am using kernel 2.6.17.13 and ivtv 0.7. And i can't seem to get a stream from the card. It just hangs.
I am really keen to get zone minder set up. Is there a trick that I have'nt performed. I'm using zm 1.22.2

Regards to all

[jameswilson]

hi mtae never used so this so dont know, but check the kernel version. I have a yukon gigabit card built into my mobo and 2.6.16, 2.6.15 it wont work, but with 2.6.12 itr does. Known issue and should be fixed but thre might be other issues with newer kernels like your hardware wont work

[Adam Sulmicki]

I'll try to clear up the confusion here.

Basically There are two Hauppauge variants. One uses bttv driver, and the other uses ivtv driver. I'm kind of surprised that on ZM's wiki it says that PVR-150 is bttv based since
http://ivtvdriver.org/index.php/Supported_hardware seems to imply otherwise.

For reference if your lspci says that you got either:
Internext Compression Inc iTVC15 (CX23415) MPEG-2 Encoder
Internext Compression Inc iTVC16 (CX23416) MPEG-2 Encoder
then you go with ivtv driver.

Now onto ivtv based cars. They normally output mpeg2 stream. ZM at its current incarnation does not understand mpeg2. Fortunatelly there's "raw" output on ivtv cards. That is, normally video0 will be mpeg2 and raw will be video32.

Unfortunatelly it is not your "regular" YUV. Reading ivtv mailing list I found they call it as using one of the names listed below:

YUV420P/nv12/Hauppauge Macroblock/hm12/hme12/hmi

And the magic invocation to get mplayer to use it is :

mplayer /dev/video32 -demuxer rawvideo -rawvideo w=720:h=480:format=hm12:pal

the above will make mplayer to read raw output instead of the mpeg2. Note the little hm12 above -- it is important.

now the trick is to teach the zm to read the video32 output.

One issue would be slightly differnet raw video format, the other would be that zm wants to use shared memory and it seems ivtv does it somehow differently.

So the task is to grab mplayer code, see how it goes about ivtv raw mode and port that to zone minder.

volunters?

[Adam Sulmicki]

One more comment. As you may have noticed the 2.6.18 adds support for cx2341x which used to be in the ivtv driver (you still need ivtv stuff thought).

I have asked Hans Verkuil <hverkuil@xs4all.nl> about raw data and shared memory and this is the reply I got :

"
Shared memory is not supported, nor will it be supported any time soon.
It is technically possible of course, but the current driver is not
designed for something like that and changing it is not easy at all.

Only standard read/write operations are supported right now.
"

So I guess it is still the case that the easiest course is to look at mplayer sources and rip the appropriate part of code and add it to zone minder (just like I said in the post before).

[zoneminder]

ZM uses shared memory internally and not directly with drivers. So the image that ZM gets from a camera is put into shared memory by ZM and the drvier is not involved.

All ZM needs from a driver is a way to get the image data in the first place really, and preferably some way of telling what it is that has been got. The YUVfunnyformat should not be a problem if it is clearly defined somewhere.

[Adam Sulmicki]

ZM uses shared memory internally and not directly with drivers. So the image that ZM gets from a camera is put into shared memory by ZM and the drvier is not involved.

All ZM needs from a driver is a way to get the image data in the first place really, and preferably some way of telling what it is that has been got. The YUVfunnyformat should not be a problem if it is clearly defined somewhere.

As far as the YUVfunnyformat goes , you can find docs at two places

1) The README.hm12 which is scheduled to go into 2.6.19 kernel, but for now I posted a copy (courtesy Hans Verkuil) at the url : http://www.missl.cs.umd.edu/~adam/README.hm12

2) in mplayer sources look at : mplayer/libmpcodecs/vd_hmblck.c

As for as driver API goes, would following suffice? In Linux Kernel 2.6.18 go at:

linux-2.6.18/Documentation/video4linux/cx2341x/*

Now that I think about it and give your comment that shared memory is used internally only I guess it is time to play with 2.6.18 and see how far ZM can get with it, after all most of it should be standard v4l2 api. Really not sure as right now I'm using Linux 2.6.17-1.2187_FC5.

[jameswilson]

i have no idea on helping but as far as i know zm uses v4l 1 not 2

[Adam Sulmicki]

ok, now I'm running 2.6.18

As before zmc will fail at ZoneMinder-1.22.2/src/zm_local_camera.cpp on

Code: Select all

        if ( ioctl(m_videohandle, VIDIOCGMBUF, &m_vmb) < 0 )
        {
                Error(( "Failed to setup memory: %s", strerror(errno) ));
                exit(-1);
        }

with error

zmc_dvideo32[4525]: ERR [Failed to setup memory: Invalid argument]

The web pages below seems to be a good reference on both mmap and read operations.
http://www.linuxtv.org/downloads/video4 ... /v4l2.html
http://linux.bytesex.org/v4l2/API.html

Finally there's code in linux-2.6.18/Documentation/video4linux/v4lgrab.c
which is simple/sample driver using read() operations.

I have tested it on /dev/video32 and it seems to return what is the image before hm12 conversion. However, even though it seems to work, that's still v4l1 and not v4l2.

[Adam Sulmicki]

All ZM needs from a driver is a way to get the image data in the first place really, and preferably some way of telling what it is that has been got. The YUVfunnyformat should not be a problem if it is clearly defined somewhere.

This should not be very difficult. It goes something like (settings must be *exactly* like this):

Source Type : File
File Path : /dev/video32
File Colours : 24 bit colour
Capture Width : 720
Capture Height : 576

And that will get the image in HM12 format into zm's memory. It needs them be converted into something what ZM understand. For example the README.hm12 mentioned before in this thread will convert it into YUV420p (NV12)

Applying the patch below (untested) will make the above work. However, I'm lost as to what's best way to to make the ZM understand the data it just had read. Comments?

Code: Select all

--- zm_file_camera.cpp  2006/10/21 16:14:26     1.1
+++ zm_file_camera.cpp  2006/10/21 16:21:34
@@ -73,6 +73,8 @@
                return( -1 );
        }
 
+       isdevice = S_ISCHR (statbuf.st_mode);
+
        while ( (time( 0 ) - statbuf.st_mtime) < 1 )
        {
                usleep( 100000 );
@@ -82,5 +84,11 @@
 
 int FileCamera::PostCapture( Image &image )
 {
-       return( image.ReadJpeg( path )?0:-1 );
+       int r;
+       if (isdevice)
+               r = image.ReadRaw( path )?0:-1;
+       else
+               r = image.ReadJpeg( path )?0:-1;
+
+       return r;
 }
--- zm_file_camera.h    2006/10/21 16:13:07     1.1
+++ zm_file_camera.h    2006/10/21 16:14:20
@@ -38,6 +38,7 @@
        ~FileCamera();
 
        const char *Path() const { return( path ); }
+       bool isdevice;
 
        void Initialise();
        void Terminate();
--- zm_image.cpp        2006/10/21 16:30:29     1.1
+++ zm_image.cpp        2006/10/21 16:37:42
@@ -141,9 +141,9 @@
                return( false );
        }
 
-       if ( statbuf.st_size  != size )
+       if ( ! S_ISCHR (statbuf.st_mode) && (statbuf.st_size != size)  )
        {
-               Error(( "Raw file size mismatch, expected %d bytes, found %d", s
ize, statbuf.st_size ));
+               Error(( "Raw file size mismatch, expected %d bytes, found %d", s
ize, (int)statbuf.st_size ));
                return( false );
        }

[mredz]

Great to see some progress on this.
Please let me know if I can be of any assitance with testing at all.

[cordel]

@ mredz
The PV-150 works fine in my setup>
FC5 Kernel 2.6.18-2200.fc5 x86_64

cx2388x alsa driver version 0.0.6 loaded
cx2388x v4l2 driver version 0.0.6 loaded
GSI 19 sharing vector 0xC1 and IRQ 19
ACPI: PCI Interrupt 0000:00:0b.1[A] -> GSI 16 (level, low) -> IRQ 193
CORE cx88[0]: subsystem: 0070:2801, board: Hauppauge WinTV 28xxx (Roslyn) models [card=24,autodetected]
TV tuner -1 at 0x1fe, Radio tuner -1 at 0x1fe
cx2388x dvb driver version 0.0.6 loaded
tveeprom 1-0050: Hauppauge model 28552, rev C158, serial# 7383002
tveeprom 1-0050: tuner model is Philips FM1236 MK3 (idx 58, type 43)
tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
tveeprom 1-0050: audio processor is CX880 (idx 30)
tveeprom 1-0050: has radio
cx88[0]: hauppauge eeprom: model=28552
cx88[0]/1: CX88x/0: ALSA support for cx2388x boards
ACPI: PCI Interrupt 0000:00:0b.0[A] -> GSI 16 (level, low) -> IRQ 193
cx88[0]/0: found at 0000:00:0b.0, rev: 5, irq: 193, latency: 64, mmio: 0xf7000000
tuner 1-0043: chip found @ 0x86 (cx88[0])
tda9887 1-0043: tda988[5/6/7] found @ 0x43 (tuner)
tuner 1-0061: chip found @ 0xc2 (cx88[0])
tuner 1-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
cx88[0]/0: registered device video0 [v4l2]
cx88[0]/0: registered device vbi0
cx88[0]/0: registered device radio0

[snip]

cx2388x blackbird driver version 0.0.6 loaded
ACPI: PCI Interrupt 0000:00:0b.2[A] -> GSI 16 (level, low) -> IRQ 193
cx88[0]/2: found at 0000:00:0b.2, rev: 5, irq: 193, latency: 64, mmio: 0xf9000000
cx88[0]/2: cx23416 based mpeg encoder (blackbird reference design)
cx88[0]/2: registered device video1 [mpeg]
cannot find the slot for index 0 (range 0-0)

Nothing was done to make the card function (with the exception of adding the blackbird driver for the card maybe but I don't recall having to do so... ) check your errors and see if it's looking for the driver unless you alreay installed ivtv, but... Diff distros might disable certain drivers when they build like blackbird

Works fine for me though.

Regards,
Corey

[Adam Sulmicki]

cordel,

Your card is based on cx2388x chip. True it also has the cx2341x, but this second chip serves merely as mpeg encoder (and sometimes decoder).

As stated on http://www.linuxtv.org/v4lwiki/index.php/Cx88_devices "The cx2388x chip is the successor to the bt87x chip", this is why I said that it is bttv class card even if it also has the mpeg encoder. Upon reflection it probably would be better to call it the 3rd class of card. After all it has its own set of drivers.

I don't know what said on box of your card, but as it says in the dmesg you posted, your card is called "[0070:2801]: Hauppauge WinTV 28xxx (Roslyn) models [card=24]".

For example if I do dmesg then it will say : "Hauppauge WinTV PVR-250 card (cx23416 based)". Cards like those will work only with ivtv drivers.

Does this helps?

[cordel]

That makes perfectly good since, I'd just wanted to post a quick blerb since I posted the pvr-150/160 compatibility and get the correct info posted. You are right and the box was labled pvr-160 (had some extra goodies) but said that it contained a pvr-150 card. I should have posted more card info... so I'll add that now:

pci bus 0x0000 cardnum 0x0b function 0x00: vendor 0x14f1 device 0x8800
Conexant CX23880/1/2/3 PCI Video and Audio Decoder
CardVendor 0x0070 card 0x2801 (Hauppauge computer works Inc. Hauppauge WinTV 28xxx (Roslyn) models)
STATUS 0x0290 COMMAND 0x0116
CLASS 0x04 0x00 0x00 REVISION 0x05
BIST 0x00 HEADER 0x80 LATENCY 0x40 CACHE 0x10
BASE0 0xf7000000 addr 0xf7000000 MEM
MAX_LAT 0x37 MIN_GNT 0x14 INT_PIN 0x01 INT_LINE 0x0b
BYTE_0 0x30 BYTE_1 0x1f BYTE_2 0x1f BYTE_3 0x07

pci bus 0x0000 cardnum 0x0b function 0x01: vendor 0x14f1 device 0x8801
Conexant CX23880/1/2/3 PCI Video and Audio Decoder [Audio Port]
CardVendor 0x0070 card 0x2801 (Hauppauge computer works Inc. Hauppauge WinTV 28xxx (Roslyn) models)
STATUS 0x0290 COMMAND 0x0116
CLASS 0x04 0x80 0x00 REVISION 0x05
BIST 0x00 HEADER 0x80 LATENCY 0x40 CACHE 0x10
BASE0 0xf8000000 addr 0xf8000000 MEM
MAX_LAT 0xff MIN_GNT 0x04 INT_PIN 0x01 INT_LINE 0x0b
BYTE_0 0x30 BYTE_1 0x1f BYTE_2 0x1f BYTE_3 0x07

pci bus 0x0000 cardnum 0x0b function 0x02: vendor 0x14f1 device 0x8802
Conexant CX23880/1/2/3 PCI Video and Audio Decoder [MPEG Port]
CardVendor 0x0070 card 0x2801 (Hauppauge computer works Inc. Hauppauge WinTV 28xxx (Roslyn) models)
STATUS 0x0290 COMMAND 0x0116
CLASS 0x04 0x80 0x00 REVISION 0x05
BIST 0x00 HEADER 0x80 LATENCY 0x40 CACHE 0x10
BASE0 0xf9000000 addr 0xf9000000 MEM
MAX_LAT 0x58 MIN_GNT 0x06 INT_PIN 0x01 INT_LINE 0x0b
BYTE_0 0x30 BYTE_1 0x1f BYTE_2 0x1f BYTE_3 0x07

I just haven't had the time to put in the research, but wanted to get what was known out here
It's bad enough that I haven't had time lately just to keep the code up along with keeping current on the hardware and drivers
I'll have to do some research so I can revise the Wiki and get some good info in there.
Expect to see more activity though

Regards,
Corey

[Adam Sulmicki]

Fyi,

This thread is continued at User Contribiutions Forum under :

http://www.zoneminder.com/forums/viewtopic.php?t=7075

Adam