Canvassing for Linux support for Startech PEXHDCAP

Canvassing for Linux support for Startech PEXHDCAP

[Steve Cookson]

Hi People,

I just wrote an email to this group about the Hauppauge 01381. Really it 
was a fall-back choice.  If I can't get anything else then that might be 
my only option left.

But here is my preferred choice.  The Startech PEXHDCAP.

It costs about $100 here:

http://www.amazon.com/StarTech-com-Express-Video-Capture-1080p/dp/B007U5MGBE/ref=cm_cr_pr_product_top

Here is a review of it:

http://www.videogameperfection.com/av-gear/startech-pexhdcap-hdmirgbvgacomponent-capture-card-review/

Here is the spec:

http://www.startech.com/AV/Converters/Video/PCI-Express-HD-Video-Capture-Card-1080p-HDMI-DVI-VGA-Component~PEXHDCAP#tchspcs

But the main spec points (for me at least) are

- It's based on the Mstar MST3367CMK chip as are many similar cards,
- It's PCIe connection
- It has inputs of:
--- Component Video (YPbPr)
--- DVI-I   (plus a vga adaptor)
--- HDMI
--- Stereo Audio
- Maximum Digital Resolution: 1080p30
- TV input resolution: 1080i/p, 720p, 576i/p, 480i/p
- PC input resolution: 1920x1080, 1440x900, 1280x1024, 1280x960, 
1280x720, 1024x768, 800x600
- MPEG4/H.264 hardware compression.

But:

- OS Compatibility Windows®

There are already a number of positive reviews for this card around the 
place together with it's twin the Micomsoft SC-500N1.

I would like to ask for expressions of interest for putting together a 
group of like-minded interested people to build an open source v4l2 
driver and associated gstreamer bits and pieces, together with 
specifying any hardware that might be required.  I'd like to identify or 
specify any (cheap) converters, sync splitters and the like which would 
make it work for the full range of signals (eg Composite and S-video - 
that s-video-like mini-port in the picture is actually a YPbPr Component 
input).

I would be great for gaming, medical image capture, university and 
research purposes.

Please let me know what you think.

Regards

Steve.

Re: Canvassing for Linux support for Startech PEXHDCAP

[Devin Heitmueller]

On Mon, Sep 16, 2013 at 4:27 PM, Steve Cookson <it@sca-uk.com> wrote:
> Here is the spec:
>
> http://www.startech.com/AV/Converters/Video/PCI-Express-HD-Video-Capture-Card-1080p-HDMI-DVI-VGA-Component~PEXHDCAP#tchspcs
>
> But the main spec points (for me at least) are
>
> - It's based on the Mstar MST3367CMK chip as are many similar cards,
> - It's PCIe connection
> - It has inputs of:
> --- Component Video (YPbPr)
> --- DVI-I   (plus a vga adaptor)
> --- HDMI
> --- Stereo Audio
> - Maximum Digital Resolution: 1080p30
> - TV input resolution: 1080i/p, 720p, 576i/p, 480i/p
> - PC input resolution: 1920x1080, 1440x900, 1280x1024, 1280x960, 1280x720,
> 1024x768, 800x600
> - MPEG4/H.264 hardware compression.

To be clear, this card is a *raw* capture card.  It does not have any
hardware compression for H.264.  It's done entirely in software.

Aside from the mstar video decoder (for which there is no public
documentation), you would also need a driver for the saa7160 chip,
which there have been various half-baked drivers floating around but
nothing upstream, and none of them currently support HD capture
(AFAIK).

As always, a driver *can* be written, but it would be a rather large
project (probably several weeks of an engineer working full time on
it, assuming the engineer has experience in this area).  In this case
it's worse because a significant amount of reverse engineering would
be required.

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Canvassing for Linux support for Startech PEXHDCAP

[Steve Cookson]

On 16/09/2013 19:09, Devin Heitmueller wrote:
 > To be clear, this card is a *raw* capture card.  It does not have any
 > hardware compression for H.264.  It's done entirely in software.

Ok, well I misunderstood that.  And, in addition, I also thought that 
hardware encoding *reduced* latency, something you seem to indicate is 
not true.

If this is stored in a file, somehow it needs to be encoded, I just 
imagined that metal was faster than code.

 > Aside from the Mstar video decoder (for which there is no public
 > documentation), you would also need a driver for the saa7160 chip,
 > which there have been various half-baked drivers floating around but
 > nothing upstream, and none of them currently support HD capture
 > (AFAIK).

Well the chip thing is confusing me.

1) I don't understand the difference between the MST3367CMK-LF-170 and 
the saa7160.  Is one analogue and one digital?  Or do they perform 
different steps in the process (like one does encoding and one does the 
DMA thing?

2) If you look here,

http://katocctv.en.alibaba.com/product/594834688-213880911/1080p_PCIe_Video_Grabber_Video_Capture_Card.html

You'll see a very similar card with an extra chip.  You can just see 
that it is produced by Gennum (but I can't see the number).  There is 
also another chip on the underside, maybe this is the saa7160? And maybe 
it's on the underside of the PEXHDCAP too.  This is actually the one I 
saw working.  As I say it was very fast and high quality, but under windows.

Scroll down and you see this:

     Operation System: WINDOWS XP /VISTA/ 7 Linux 2.6. 14 or higher 
(32-bit and 64-bit)

Drilling into this, it appeared the statement was more aspirational than 
actual, but that it *had* been compatible, but there was not yet an 
available driver.  They would need to recompile something to include the 
latest linux libraries before it would be possible to write the 
drivers.  I've no idea what this could mean.  Although 2 clients had 
indeed written gstreamer drivers, one was Cisco systems, but had kept 
the code to themselves.

 > and none of them currently support HD capture (AFAIK).

What does this mean?  No saa7160 drivers, or no drivers period?  I have 
the Intensity Pro doing full-screen 1080i capture with minimal latency, 
but I hate the decklinksrc module.  It just does nearly nothing.  Maybe 
it could be re-written for v4l2src, but anyway it only accepts YPbPr, as 
I said before.

 > As always, a driver *can* be written, but it would be a rather large
 > project (probably several weeks of an engineer working full time on
 > it, assuming the engineer has experience in this area).  In this case
 > it's worse because a significant amount of reverse engineering would
 > be required.

Kato Vision agreed with you.  They were saying a few months (maybe two 
or three).  They didn't offer to write it, but they offered technical 
support with the driver-writing.

Thanks for your input.

Regards

Steve

Re: Canvassing for Linux support for Startech PEXHDCAP

[Devin Heitmueller]

On Tue, Sep 17, 2013 at 11:15 AM, Steve Cookson <it@sca-uk.com> wrote:
> On 16/09/2013 19:09, Devin Heitmueller wrote:
>> To be clear, this card is a *raw* capture card.  It does not have any
>> hardware compression for H.264.  It's done entirely in software.
>
> Ok, well I misunderstood that.  And, in addition, I also thought that
> hardware encoding *reduced* latency, something you seem to indicate is not
> true.

Nope, the opposite.  In order to compress the video you need to store
enough context to look for repetition.  H.264 encoders can vary in
latency, and in fact some can be adjusted to reduce latency at the
cost of compression performance.  But they will always have more
latency than just reading the raw video as it comes in.

> If this is stored in a file, somehow it needs to be encoded, I just imagined
> that metal was faster than code.

If your intent is to store the video in a file, then you almost
certainly will need to encode it with a scheme such as H.264.  However
raw capture cards can be very useful for cases where you want to take
in the video, alter it somehow, and then put it back out to the
display (think digital signage).  Capturing raw video also allows the
consumer to have better control over the actual compression process
(since it's done in software), which is why it is preferred for
professional capture application (which is why BlackMagic doesn't make
any cards with hardware encoders).  Cost isn't a concern and those
sorts of customers are willing to have high end workstations to
actually work with the uncompressed video.

>> Aside from the Mstar video decoder (for which there is no public
>> documentation), you would also need a driver for the saa7160 chip,
>> which there have been various half-baked drivers floating around but
>> nothing upstream, and none of them currently support HD capture
>> (AFAIK).
>
> Well the chip thing is confusing me.
>
> 1) I don't understand the difference between the MST3367CMK-LF-170 and the
> saa7160.  Is one analogue and one digital?  Or do they perform different
> steps in the process (like one does encoding and one does the DMA thing?

The Mstar chip encodes the analog signal to a digital format.  The
saa7160 takes the resulting digital signal and makes it available to
the host via DMA.

> 2) If you look here,
>
> http://katocctv.en.alibaba.com/product/594834688-213880911/1080p_PCIe_Video_Grabber_Video_Capture_Card.html
>
> You'll see a very similar card with an extra chip.  You can just see that it
> is produced by Gennum (but I can't see the number).  There is also another
> chip on the underside, maybe this is the saa7160? And maybe it's on the
> underside of the PEXHDCAP too.  This is actually the one I saw working.  As
> I say it was very fast and high quality, but under windows.

The "extra" chip is for SDI capture, which isn't supported by the
lower cost mstar chip (which is designed for HDMI and component).  The
bridge is the chip nearest the PCIe connector, which can be a saa7160
or some other component.

> Scroll down and you see this:
>
>     Operation System: WINDOWS XP /VISTA/ 7 Linux 2.6. 14 or higher (32-bit
> and 64-bit)
>
> Drilling into this, it appeared the statement was more aspirational than
> actual, but that it *had* been compatible, but there was not yet an
> available driver.  They would need to recompile something to include the
> latest linux libraries before it would be possible to write the drivers.
> I've no idea what this could mean.  Although 2 clients had indeed written
> gstreamer drivers, one was Cisco systems, but had kept the code to
> themselves.

Who knows?  So much of that junk on alibaba is cut/pasted from other
products and isn't actually accurate.  Or maybe somebody does have a
driver.  There's nothing in the mainline kernel though.

>> and none of them currently support HD capture (AFAIK).
>
> What does this mean?  No saa7160 drivers, or no drivers period?  I have the
> Intensity Pro doing full-screen 1080i capture with minimal latency, but I
> hate the decklinksrc module.  It just does nearly nothing.  Maybe it could
> be re-written for v4l2src, but anyway it only accepts YPbPr, as I said
> before.

The Blackmagic boards are the only low cost boards out there which
have readily available drivers.  The downside is you have to deal with
their proprietary interface that isn't remotely V4L2 compatible (and
thus only works with their applications or if you're prepared to write
your own app).

We wrote open source drivers for a couple of the ViewCast boards which
do HDMI/DVI capture, but while the drivers are free the boards
themselves can cost a couple thousand dollars.

>> As always, a driver *can* be written, but it would be a rather large
>> project (probably several weeks of an engineer working full time on
>> it, assuming the engineer has experience in this area).  In this case
>> it's worse because a significant amount of reverse engineering would
>> be required.
>
> Kato Vision agreed with you.  They were saying a few months (maybe two or
> three).  They didn't offer to write it, but they offered technical support
> with the driver-writing.

Yup.  We've been through the exercise several times with various HD
capture boards.  Adjust the multiplier based on the level of
experience of the developer doing the work.  :-)

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Re: Canvassing for Linux support for Startech PEXHDCAP

[Steve Cookson]

On 17/09/2013 12:38, Devin Heitmueller wrote:

 > Nope, the opposite.  In order to compress the video you need to store
 > enough context to look for repetition.

Ok, quite intuitive, once you know what to look for.

 > Yup. We've been through the exercise several times with various HD 
capture boards. Adjust the multiplier based on the level of experience 
of the developer doing the work.

So it is do-able.  That's good to know.

If I want to capture 480i/576i and 1080i analogue my alternatives seem 
to be:

- Something like Dazzle, $50 (480i/576i only - s-video and composite),
- Intensity Pro, $200 (480i in s-video and composite, plus, 480i/576i & 
1080i in Component but YPbPr only).  S-Video and Component in 480i/576i 
seem to have very similar picture quality.

Which leaves me with how to capture RGBS 1080i composite synch.

What do you think of Epiphan VGA2USB (with the internal PCIe mounting 
kit)?  The basic model at $299 doesn't cover RGBS, but it does do 
1080i.  Maybe I could use a sync splitter and inverter, like the 
LS1881n, to make the RGBS composite synch fit the VGA H+V pins. The LR 
at $799 doesn't seem to capture 1080i.  I thought it did, but now I look 
at the website again, I can't see it.  Have you used it?   If not those 
then there is only the HR at $1,600 :(

But Epiphan appears to support v4l2 and gstreamer.  Is it fast?  I guess 
it doesn't do S-Video and Composite.

If not Epiphan then what?  The Epixinc PIXCI® A310?

It seems quite a hard problem.

Regards

Steve.