Slashdot Mirror

Actually, the driver issues have been sorted and the HVR-1600 now works fine with both ATSC and NTSC. I've been using mine with MythTV for a few months now, and it works quite well.

FWIW, I'm using Debian testing, kernel 2.6.24 and the MythTV packages from debian-multimedia.org.

-lee

When it comes to the remote control, I tried. Trust me. It just did not work. I know about lirc. I tinkered all I could but it did not work! There is community support for the WinTV-PVR-150 at http://ivtvdriver.org/ and I can tell you that it did not work for me. By the way, I am no Linux newbie but I must admit I failed on this.

What you describe isn't unusual within Linux at all. If you have a problem with a module, you can often visit a developer's page, and fairly often get a later version of the driver which is still compatible with the kernel version you're running (e.g. IVTV). Then you either patch your kernel tree or compile the modules outside the kernel tree (for instance the pcmcia subsystem) and load it in. As for competing subsystems, think about oss vs alsa, or ipfwadm vs ipchains vs iptables, or udev vs devfs. It's just that all this is usually left to distro maintainers, because most people don't care. Maybe what you think you want is rock-steady kernel interfaces so a given driver is compatible with more versions of the kernel - but then you can kiss progress goodbye. I think Linux has it right: support the current way of doing things, plus the outmoded way of doing the same thing for a year or two, then get rid of it. Otherwise you're going to replicate the 20 year transition period it took Microsoft to get from DOS to XP.

I just finished doing exactly this sort of thing, so I'll describe what I did, how, and why.

Some caveats: 1) I like working from the command line. 2) This was not a project for which I wanted ultra high quality - "good enough" was good enough for me.

I have a Hauppauge PVR-500 (a hardware MPEG encoder/TV tuner card - basically, this card is a pair of PVR-250's on one PCI card). This card is well-supported on Linux by the IVTV drivers. I decided to use its composite and audio inputs to convert some old VHS porn (gotta love that 80's-era stuff) to modern digital file formats so I could finally toss out the old VHS video tapes, some of which were quite degraded (they were formerly rental tapes, and some were nearly 20 years old). I used an old-but-decent-quality Sony VCR as the video source and fed its outputs straight into the PVR-500's first set of inputs. Capturing video was as simple as:

cat /dev/video0 >filename.mpg

How's that for simple? Heh... I "retensioned" the tape beforehand (fast forward all the way to the end, then rewind all the way to the beginnig) and made note of how long the tape was. I used a kitchen timer to let me know when the tape was nearly finished playing so I could stop the capture at the approprite time.

After the capture was finished, I used mplayer to find the exact end point (just after the credits faded to black, for example) and to find where to crop the video (most analog captures will end up with black bars on the left/right sides, and old tapes often have distortion at the top or bottom). mplayer's "cropdetect" feature was invaluable for that. I would play the file with a command like this:

gmplayer -vf cropdetect filename.mpg

To use cropdetect, you have to fast-forward into a part of the video where the picture doesn't have any black at the edges (no dark scenes, transition fades, etc.) Then you just look at the terminal window to see what cropping parameters to use (it spits them out continuously). I found that sometimes the default setting wasn't sufficient to eliminate the black bars completely, so I would occasionally use cropdetect=50 to make it a little less conservative about what it detected. That value of 50 was chosen by experimentation, so feel free to experiment yourself. 50 seemed to consistently work well for me. There are no units on that number, it's just a scale from 0 to 255. In the end, I'd have a set of cropping parameters that looked like this:

-vf crop=704:476:12:0

Those numbers are: X dimension, Y dimension, X offset, Y offset. Offsets are measured in pixels from the upper left corner.

Cropping the distorted crap at the top and bottom isn't quite so easy. It's not all black, so cropdetect doesn't detect it. So I had to manually adjust the parameters. The tricky part is the way mencoder/mplayer wants its dimensions specified. It would be much simpler if it used a format of startx:starty:endx:endy rather than the size/offset described above. As it is, if you want to crop pixels off the top or left side, you have to shorten the appropriate dimension by N pixels and then add N pixels to the offset. This sounds like a pain in the ass, but in practice it's not so bad. You get used to it very quickly.

Now that I had my crop values, I'd use mencoder to resize, deinterlace, and transcode the whole thing into h.264 video and variable bitrate MP3 audio. I experimented with AAC audio, but for some reason I kept having much better results with VBR MP3. I think the FAAC codec (the one bundled with Ubuntu Dapper) I have is just too old to be efficient. When Feisty comes out this month and I get around to upgrading, I'll try AAC again. Anyway, this is a complex command line, so I wrapped it in a script:


#!/bin/bash

# Bit rate at which to encode
# Formula for h.264: X * Y * FPS * 0.125
# Common

They may not have been intentionally misleading you. I have a video capture card and if someone asked me if it worked under linux then I would say yes. Then if it later came out that there were different versions of that card being sold under the same name I suppose you could say I was misleading you. But it would be more accurate to say the manufacturer was misleading you by saying that your card was the same as my card when it wasn't.

Not sure why you'd blame Linux for lying to you when it was the manufacturer that lied to you. If I say that linux supports widget-2000 and then someone makes a completely different product named widget-2000 that isn't supportted by linux, does that make me a lier? I'd say the manufacturer is lying by claiming their product is a widget-2000 when it isn't.

Just checking the the ivtv supported hardware page there appears to be four different PVR-250s that they say will work. Is your card one of those? If you've tried to get it working recently or if your card is a different version from the ones they have listed maybe you could let them know so they can update the page.

RTFM http://ivtvdriver.org/index.php/Supported_hardware

don't cry me a sob story and be immature and accuse other people of being dishonest because you didn't RTFM

PS: the firmware is loaded by the drivers (both linux and windows) when the driver is loaded - the IVTV documentation even COVERS that and provides you links to the best-known firmware.

I tend to prefer the Hauppauge PVR 150/250/350 or 500 cards. They're easily available and have good quality. They all do MPEG encoding on-board.

You can find a databases and software at:
www.mythtv.org
www.freevo.org
http://linux.bytesex.org/v4l2/bttv.html
http://ivtvdriver.org/index.php/Main_Page