Author Topic: PV-149 - 4 port video capture card (120FPS)  (Read 2708 times)

ccoudsi

  • Guru
  • ****
  • Posts: 244
    • View Profile
PV-149 - 4 port video capture card (120FPS)
« on: March 19, 2009, 06:07:19 am »
I just installed this Bluecherry capture card in my Hybrid 7.10 "PV-149 - 4 port video capture card (120FPS)" from "http://store.bluecherry.net/Provideo_PV_149_p/pv-149.htm" reading this wiki page "http://wiki.linuxmce.org/index.php/Bluecherry_PV-149" it suppose to be "plug and play with the mentioned Linux kernels" but it is not, the Hybrid did not recognize this card, any ideas how to install this card !!!!

Here's my "lspci" output:
================
06:08.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
06:08.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
06:09.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
06:09.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
06:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
06:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
06:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
06:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
============================

Thanks in advance for your comments.
Charlie  :)

Cheers |[BEER]
Charlie,

bulek

  • Administrator
  • wants to work for LinuxMCE
  • *****
  • Posts: 884
  • Living with LMCE
    • View Profile
Re: PV-149 - 4 port video capture card (120FPS)
« Reply #1 on: March 19, 2009, 07:49:30 am »
Hi,

I think this card should be well supported. Take a look at :
dmesg | grep video

kernel should prepare 4 video devices for you. Those can be set up for cameras under Motion wrapper :
http://wiki.linuxmce.org/index.php/Monitor_surveillance_cameras
http://wiki.linuxmce.org/index.php/Analog_cameras
http://wiki.linuxmce.org/index.php/Motion

HTH,

regards,

Bulek.
Thanks in advance,

regards,

Bulek.

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5495
  • DOES work for LinuxMCE.
    • View Profile
Re: PV-149 - 4 port video capture card (120FPS)
« Reply #2 on: March 19, 2009, 07:54:56 pm »
Why doesn't somebody make a device template to add plug and play support for this card?

-Thom

ccoudsi

  • Guru
  • ****
  • Posts: 244
    • View Profile
Re: PV-149 - 4 port video capture card (120FPS)
« Reply #3 on: March 20, 2009, 05:18:15 am »
Bulek & Thom,

Thanks for getting back to me quickly, I followed the instructions that Bulek sent me and I'm able to see my 3 analog cameras, I was expecting per the wiki page (plug n play) as soon I reboot the system, I will get the wizard screen!!!
The device and port settings were a bit confusing at first, but I figured it out, just setting the device to (0,1,2,3) and leaving the port set to 0, the setup  worked right away.
One more question I have Dlink-DCS-5300W set for 704x480, I'm able to see the picture but not very clear and tiny compare to the Analog cameras, do you have any clues for that???


Cheers, :)
« Last Edit: March 20, 2009, 03:06:08 pm by ccoudsi »
Cheers |[BEER]
Charlie,

huh

  • Guru
  • ****
  • Posts: 235
    • View Profile
Re: PV-149 - 4 port video capture card (120FPS)
« Reply #4 on: November 16, 2009, 07:04:31 am »
Why doesn't somebody make a device template to add plug and play support for this card?

-Thom



I know nothing on how to do this, but hope to present my progress and pray for some guidance.   I bought a PV-149 and want to get it plug and play...

"lspci -nn -v" in a terminal spits out a lot, to me the relevant parts seem to be:

Quote
05:07.0 PCI bridge [0604]: Hint Corp HB6 Universal PCI-PCI bridge (non-transparent mode) [3388:0021] (rev 11)
   Flags: bus master, medium devsel, latency 64
   Bus: primary=05, secondary=06, subordinate=00, sec-latency=64
   Prefetchable memory behind bridge: faf00000-faffffff
   Capabilities: [80] Power Management version 2
   Capabilities: [90] CompactPCI hot-swap <?>
   Kernel modules: shpchp

06:08.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 Video Capture [109e:036e] (rev 11)
   Subsystem: Device [aa00:1460]
   Flags: bus master, medium devsel, latency 64, IRQ 21
   Memory at fafff000 (32-bit, prefetchable) [size=4K]
   Capabilities: [44] Vital Product Data <?>
   Capabilities: [4c] Power Management version 2
   Kernel driver in use: bttv
   Kernel modules: bttv

06:08.1 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio Capture [109e:0878] (rev 11)
   Subsystem: Device [aa00:1460]
   Flags: bus master, medium devsel, latency 64, IRQ 10
   Memory at faffe000 (32-bit, prefetchable) [size=4K]
   Capabilities: [44] Vital Product Data <?>
   Capabilities: [4c] Power Management version 2

06:09.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 Video Capture [109e:036e] (rev 11)
   Subsystem: Device [aa01:1461]
   Flags: bus master, medium devsel, latency 64, IRQ 22
   Memory at faffd000 (32-bit, prefetchable) [size=4K]
   Capabilities: [44] Vital Product Data <?>
   Capabilities: [4c] Power Management version 2
   Kernel driver in use: bttv
   Kernel modules: bttv

06:09.1 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio Capture [109e:0878] (rev 11)
   Subsystem: Device [aa01:1461]
   Flags: bus master, medium devsel, latency 64, IRQ 10
   Memory at faffc000 (32-bit, prefetchable) [size=4K]
   Capabilities: [44] Vital Product Data <?>
   Capabilities: [4c] Power Management version 2

06:0a.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 Video Capture [109e:036e] (rev 11)
   Subsystem: Device [aa02:1462]
   Flags: bus master, medium devsel, latency 64, IRQ 23
   Memory at faffb000 (32-bit, prefetchable) [size=4K]
   Capabilities: [44] Vital Product Data <?>
   Capabilities: [4c] Power Management version 2
   Kernel driver in use: bttv
   Kernel modules: bttv

06:0a.1 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio Capture [109e:0878] (rev 11)
   Subsystem: Device [aa02:1462]
   Flags: bus master, medium devsel, latency 64, IRQ 10
   Memory at faffa000 (32-bit, prefetchable) [size=4K]
   Capabilities: [44] Vital Product Data <?>
   Capabilities: [4c] Power Management version 2

06:0b.0 Multimedia video controller [0400]: Brooktree Corporation Bt878 Video Capture [109e:036e] (rev 11)
   Subsystem: Device [aa03:1463]
   Flags: bus master, medium devsel, latency 64, IRQ 20
   Memory at faff9000 (32-bit, prefetchable) [size=4K]
   Capabilities: [44] Vital Product Data <?>
   Capabilities: [4c] Power Management version 2
   Kernel driver in use: bttv
   Kernel modules: bttv

06:0b.1 Multimedia controller [0480]: Brooktree Corporation Bt878 Audio Capture [109e:0878] (rev 11)
   Subsystem: Device [aa03:1463]
   Flags: bus master, medium devsel, latency 64, IRQ 10
   Memory at faff8000 (32-bit, prefetchable) [size=4K]
   Capabilities: [44] Vital Product Data <?>
   Capabilities: [4c] Power Management version 2


I think the top line (05:07.0 may be part of my PVR-150, but don't know that for sure).

So having this, I went to the admin pages -> Advanced -> Configuration -> Device Templates and created a "Bluecherry" manufacturer (by click on "Add manufacturer" and selected "Surveillance Video Interfaces < Interfaces" as the Device Category.  I think clicked on "Add device template" at the bottom and got to the next screen.

Couple questions:
1) Are the 06:**.* lines from above the lines I should use and ignore the 05:07.0?
2) Should I use Surveillance Video Interfaces < Interfaces as the device category or something else?  Can this be easily changed later if it becomes apparent that another device category should be used/created?
3) Based on this http://wiki.linuxmce.org/index.php/Does_the_device_Implement_DCE%3F it looks like this device will "Implement DCE".  Is this correct?
4) I'm trying to follow this: http://wiki.linuxmce.org/index.php/Edit_Device_Template.  Is this correct?  Or is there more to creating a device template than filling out the boxes on the Device Template screen? 
5) Probably a continuation of 4, but once created how does it make it into SVN?  Doing a search on svn.linuxmce.org, it looks like Pos implemented a way to export these from the webadmin pages.  If/When I get that far, would I create a ticket on svn and upload whatever file was exported in the admin pages?
6) Other questions that I know will come up.  This card captures from a max of 4 cameras- how do I allow LMCE to see all four connected cameras?  Is there a command under "Capture Card Commands" or elsewhere where I can specify the number of inputs?

I set the comm method to "PCI" as that this is a PCI based card.  At some point, then after hitting "Save" at the bottom, the greyed out boxes for "Audio/Video Device", "Is PlugIn", etc were selectable and "Is Embedded" already had a check mark next to it.

7) Is this an audio/video Device?

I'm using the first one above that I think applies to get the Vendor Model ID:  109e036eaa001460
I left the PNP Protocol blank, as suggested in the wiki linked above
Under Params I typed in 175|pci also as suggested in the wiki

Then I clicked "Save" at the bottom.  When I went to add my newly created device template, after filtering by the Bluecherry manufacturer and the "Surveillance..." Device Category, my "PV-149" was not an option under "Device Template".


Any guidance would be appreciated.

colinjones

  • Alumni
  • LinuxMCE God
  • *
  • Posts: 3003
    • View Profile
Re: PV-149 - 4 port video capture card (120FPS)
« Reply #5 on: November 16, 2009, 09:47:09 pm »
I can't really answer your other questions, but I can give you some feedback on one of them.

It is unlikely you will want to make this device a DCE device unless you intend to write the code to make it so. A DCE device is a combination of a device template and the DCE driver code itself. Essentially, you are writing a piece of C++ code that will connect to the DCERouter via TCP/IP and be able to send and receive DCE messages to the rest of the LinuxMCE system. This device is usually responsible for converting LinuxMCE's DCE messages into actions for a particular physical device or other piece of non-LinuxMCE software. An intermediary if you will.

For instance, if you had an amplifier connected to your core via RS232, you might want to write a device that receives DCE Volume messages (Up Down, Mute, for a simple example) from LinuxMCE and converts them into data sent to the serial port to control the actual device. Similarly if the user hits Mute on the amp, you would want the device you write to send that info back to LinuxMCE so that it knows the volume is muted. In practice, such simple applications are usually not necessary as you can use the GSD (Generic Serial Device) - this is a "framework" type device that already has the complex bits of connecting to the DCE network implemented, and sends/receives DCE messages for you, then based on which message will trigger a snippet of Ruby code to do the task needed. That way you don't need to have a dev environment or write any C++, you can just insert the right Ruby snippets into the web admin.

An example of a DCE device controlling software would be the Squeezebox system. Someone wrote a DCE device that connects to the DCE system via TCP/IP and also to the SqueezeCenter software via TCP/IP (SqueezeCenter offers a TCP/IP control interface as well as the normal web interface for exactly this purpose). It then passes commands back and forward between the two.

One of the purposes of DCE is this abstraction, so that LinuxMCE can send generic commands like volume up/down, play media, etc to non-LinuxMCE systems without having to know how those commands are actually implemented. The responsible DCE device has all that information.

In your case, the hardware in question is low level and probably doesn't need to interact directly with LinuxMCE through DCE. There are many device types that do not implement DCE because they are merely children devices types of other device types that do the interaction. Imagine them like "placeholder" containers of configuration data, rather than actual do-ers!

So why do you create a device template for your card if not to communicate through DCE? Well in this case I see 2 reasons. First it allows you to configure LinuxMCE's pnp system, so that when it sees the device you can "do stuff" to ensure that the card is configured correctly for us. eg install any drivers, setup configuration options in the driver's .conf files etc. This will allow your card to be autoconfigured for LinuxMCE as it is detected.

Second, to store critical configuration data (Device Data) that the rest of the LinuxMCE can use to communicate with the card. Specifically, I am thinking Motion as an example.

As I understand it, the Motion_Wrapper is the main security DCE device for capture cards. I've never done this, but I assume that you configure your device template to be a child device of the Motion device. Motion does all the DCE communication with LinuxMCE, and I assume it just looks for its children to find the actual video, by interrogating their Device Data. Not sure if it looks for a URL or a /dev device file in the Device Data, but probably one or the other, then uses that to do the actual reading of video.

In summary, you could write a whole DCE device just to control this card, but that is a big job and reinventing the wheel. I believe you can create a non-DCE device, that is configured to be a child of a real DCE device like Motion, so that once detected LinuxMCE knows where to add the device in the system. Then configure the pnp section of your new device so that any setup/configuration that the card needs, is done. Finally, add any Device Data necessary so that the parent DCE device can access your card.

The "principles" stuff above is broadly correct, as I understand it. But most of the video/security/motion stuff is assumption - someone will correct as necessary I'm sure. Your best bet is to look carefully at other similar devices... Establish what they are configured to be children of, to verify my assumption. Investigate what types of tasks their pnp configuration does (usually a script is run). And determine what Device Data they set, so that Motion can access them.

hth

ps. remember that LinuxMCE's pnp system is quite separate from the underlying Linux pnp. The kernel's pnp system will do the actual hardware detection, and for instance, based on the PCI ID (vendor/product) may well install the necessary kernel device driver necessary for the hardware. The hardware is now installed and working, but LinuxMCE knows nothing about it. LinuxMCE's pnp system hooks into the kernel pnp system by receiving events through the HAL. So once the kernel has done its bit, the LinuxMCE pnp system is triggered and passed pieces of information like the PCI vendor/product number, and goes about triggering the necessary Device Template based on that number to install itself (if it isn't already), so there are 2 pnps, you mostly need to worry about the LinuxMCE one, as long as the kernel successfully does its bit.
« Last Edit: November 16, 2009, 09:58:19 pm by colinjones »