VHS to DVD - I have a PVR250, but considering something else. Thoughts??

[usually_quiet]

It seems that Theater 750 (Diamond Theater HD 750 USB version) does work well on USB interface with Lagarith. With Theater 650 should be the same thing. Uncompressed output is not RGB, is compressed in YUV2 color space, so require less bandwidth.
https://forum.videohelp.com/threads/313735-Capture-card-for-Laserdisc-and-VHS-Good-card...=1#post1959930

Unless the 750 is pre-compressing, the Lagarith compression comes after the USB transfer. Don't forget audio adds to the YUY2 video bitrate.

The Theater 750 USB tuner stick for which I posted the link has no hardware encoder, so it has to be sending uncompressed video via the USB connector when an analog source is captured. Unfortunately, it appears to be the only game in town for that chip in the US market. There doesn't seem to be a PCI-E card using the Theater 750 that is sold in the US.

Although, you may be right when you say the USB is at its limit. One of the user comments at NewEgg said the device worked best with no USB cable in between the tuner stick and the PC, or when using a thick, high quality cable instead of the thinner cable that comes with it.

[edDV]

I was just pointing out uncompressed over USB2 is getting near the limit with limited safety margin.

[sphinx99]

I've captured at least one hundred hours with the USB 750 dongle with zero issues so far. Under W7 x64 with the drivers off the ATI website, it works great through virtualdub collecting uncompressed and writing to Lagarith. (Note, this is a i7 920-based PC writing to a SSD stripe, so USB is the primary bottleneck.) As long as you have enough compute power to handle interrupt and wait overhead associated with USB transfers, USB 2.0 should be able to sustain 30+ MB/sec indefinitely.

Only glitch is that when I hit the capture button, Virtualdub consistently records 6 frames lost over the first 6 seconds. Then, no more losses. Nature or type of input doesn't matter. So I simply start capturing, then engage the source playback after 6 seconds. In this manner I've captured as much as 6 hours of continuous material without a single lost frame.

[edDV]

OK we bounded one extreme. Now do it with an Athlon 1800 to a USB2 hard drive and I'll feel more comfortable.

[vhelp]

I wouldn't mind testing that one for you but my Athlone XP 1800 only runs Windows 98 and my only USB2 non-hardware capture, pinnacle pctv pro stick only has winxp drivers, minimum.

I think that the underlying cause might have something to do with service pack levels. When I first installed xp home, and ran a quick test using the pinnacle pctv pro stick to an usb2 external, it did flawlessly. But, then later, when I installed SP2, forget it. It installed a bunch of hidden background (I call, trojans) and these all hog resources. Capturing seems to be affected by these service packs and what they install for their (ms) benefits. The sp2 I had installed put a permanent firewire on my resource and that gives me problems in my captures every now and then, but nothing for me to worry about. Not that it matters, but my current rig is: AMD 64 X2 3600+, ECS GeforceE6100SM-M w/ 1gig DDR RAM. I was thinking about giving it another go anyway, since I recently upgraded it a little more ram, etc. The way I see it, i'm usually the last one to upgrade and behind the times, and if it passes for me, then you know it has to pass further for others.

-vhelp 5343

[vhelp]

Ok, I managed to quickly reinstall my pctv pro drivers, connected the dong extension and connected to my vcr and proceeded to capture using various codecs.

I captured to my latest usb2 external hdd, a Toshiba 1TB, 7200RPM, it has eSata but I use the usb2 only.

70-100% cpu, zero frame drops - DV
60-100% cpu, zero frame drops - Arithyuv
10-045% cpu, zero frame drops - huffy
70-120% cpu, zero frame drops - lagarith
00-20% cpu, many frame drops - raw uncompressed

00-20% cpu, zero frame drops - however, when I sent the stream over to my internal hdd (has 3 partitions) I got initially 6 frame drops, and the rest were zero.

So it seems that usb2 hdds is the bottleneck, even a fast 7200RPM have trouble, unless you incorporate an intermediate codec, huffy was least cpu intensive. Also, I should say that the test usb2 hdd I used was fairly full, about 3/4 full. Fragmentation was/is also part of the problem. For serious work it is best to reformat the long way (not the quick) to assure sequential writes from inner -to- outer sections. The quick format does not zero anything, it just sets a flag that the hdd is empty, and whereever the last sector flag is, it is used. That mean wherever the fragment was last, anywhere on the hdd.

EDIT: I just realized that I was testing over a hub, a 4 port hub, and all are full and in use..hdds, card reader, pctv pro, and it may not be plugged in so i'll have to check this out and report back later.

-vhelp 5344

[lordsmurf]

Use the "fast" HuffYUV settings, too.

[sphinx99]

I would not expect anything good from high-throughput capture from a USB capture card, writing to a USB mass storage device. Unfortunately operating systems don't gracefully handle concurrent I/O to different USB devices. Also, USB write buffering is an inexact and problematic science. Everyone here should know that already. I've never heard "I want to capture lossless huffyuv to a USB hard drive" before and somewhat surprised to read it here after years of all advice pointing in the opposite direction: capture to a fast IDE, SATA, SCSI or SAS mass storage system.

My point was that USB 2.0 should be fine as an input device. It should provide the bandwidth necessary to capture uncompressed SD data as long as you're reading directly from it. Not much headroom, but enough to work. I've verified with a dual-core 2GB RAM T8100 laptop with the same 750 USB dongle. Works great. Just don't do something silly like expect to capture the same amount of data to another USB device on another USB port on the same controller/hub, at the same time.

[vhelp]

Huffy was the least resource hog, it did very well. Raw uncompressed does best when internal hdd is used. But I was only testing this, yet again, because of this discussion. I have my own working rig and doing fine.

Actually, a usb2 capture device is not a bad alternative for cases of emergency or other strange reason. I was merely testing this alternative back when I was curious, and then reading this discussion, I got interested in the idea again just for a part2 test. It worked, but to my surprise, I was on a hub and the thing was even plugged in, so I was probably not getting the full 480 bandwidth. I moved the ac adaptor somewhere in my cleaning and can't find it at the moment. I may leave it for a weekend project.

As long as video source is clean and current, uncompressed should come out just about as good as my current rig, give or take a few features. I'm not saying composite or 3d comb or chipset here, just that it could be useful to some others looking for something cheap and posibly easy, and because it can be done if need be, or even myself. After all, this is a hobby of mine.

As I mentioned earlier, my system is old and outdated from most faulks here on this board. If I can get anything working on my rig, you can (or should) be sure you can on yours.

Roxio makes a dedicated usb2 capture stick for a low price, $49 I think, and i've been eying it for some time now, I may check it out--just because I'm curious and because its a hobby. I have more capture cards then I can count my fingers.

-vhelp 5345

[edDV]

I would not expect anything good from high-throughput capture from a USB capture card, writing to a USB mass storage device. Unfortunately operating systems don't gracefully handle concurrent I/O to different USB devices. Also, USB write buffering is an inexact and problematic science. Everyone here should know that already. I've never heard "I want to capture lossless huffyuv to a USB hard drive" before and somewhat surprised to read it here after years of all advice pointing in the opposite direction: capture to a fast IDE, SATA, SCSI or SAS mass storage system.

My point was that USB 2.0 should be fine as an input device. It should provide the bandwidth necessary to capture uncompressed SD data as long as you're reading directly from it. Not much headroom, but enough to work. I've verified with a dual-core 2GB RAM T8100 laptop with the same 750 USB dongle. Works great. Just don't do something silly like expect to capture the same amount of data to another USB device on another USB port on the same controller/hub, at the same time.

We are saying the same thing. Uncompressed SD YCbCr capture over USB2 is pushing the limits of USB2 transfer rate. I suggested a test to capture to a USB drive because that would be a worst case yet the typical laptop case where the internal drive isn't large enough to handle uncompressed, huffyuv or lagarith file sizes. A long capture to an internal laptop drive is also a difficult case due to OS interrupt contention for the single hard drive.

At ~24MB/s (200 Mb/s) a typical 5400 RPM laptop drive is also at sustained transfer limit particularly at the slow end of the drive. Adding to that the buffering required to handle real time huffyuv compression raises risk of frame loss. Were you real time compressing on that laptop test or just doing uncompressed capture? Were you monitoring?

A desktop system with a separate capture drive would be able to separate OS and capture processes through PCI bus mastering.

[lordsmurf]

You can't capture to an external USB hard drive, no.

[jagabo]

You can't? Then what was it vhelp did?

[vhelp]

Jagabo, I think LS was refering to the slower systems like p3's or p4's and am xp's, of that group, etc. or maybe was thinking usb1, gosh But, you can capture uncompress to a codec, a lossless one, like huffy or lagarith. Because these codecs are Assembley/SSE optimized, they can do things inside a core, like number crunching, etc., w/out much interuption in cpu resources, but an uncompressed data stream is huge and throttles the ports beyond or near their limits, thus when usb2 is utilized:

uncompressed -> avi = low cpu, but tons of frame drops

while

uncompressed -> codec -> lossless avi = low cpu, zero frame drops

I use my current AMD 64 X2 3600+, ECS GeforceE6100SM-M w/ 2gig DDR RAM and a over usb2 on a 4-port hub. In my opinion, my system is pretty slow, probably the slowest on this forum board.

Tomorrow, i'll pick up the Roxio package, and give that one a test run--maybe i'll start another thread on this. I find that the best route for analog captures when using non compatible devices like this is to use the generic tools, like virtualdub. These are the hard-hats of utilities to always keep in your tool box. Anyway. I'll post a few short clips I made with this setup, shortly, if no one objects. I'm trying to find the card I wrote the info on, i think i left it at work, or maybe fell out of my pocket in my car or something, sheesh.

-vhelp 5346

[jagabo]

I was just being sarcastic about smurf's half-true response with no qualifications.

[vhelp]

-- pctv pro stick clips from vhs demonstration --



Here are a couple of demo clips, one short and large. This one was a first pass capture w/out any attention to settings, audio was engaged during capturing but had not connectors at the time, encode w/ done w/out audio, both clips, color space/levels was not accounted for but on 2nd clip i did adjust the brightness by few tics, seems to look better.

I encoded to h246 (avc) with x264, used a template I was working on from another source type, so params may not be the best, i set for 3k bitrate, but all looked ok to me in these clips. I have to say, quality results are far better than my mpeg-2 versions..no noticable pixelations like in mpeg-2 clips i do. This is truely the better way, bar none.

I especially like the quickness in the setup of things for usb2 capturing. Just plug the gizmo in the port, connect your leads (composite or svideo) and press start to capture--it was that simple, true plug n go.

demo clip 1

demo clip 2

-vhelp 5347

[mjvgiese]

I know this thread has been dead for a few weeks, but I haven't really made any decisions yet. Today I stumbled upon a great deal for the Diamond ATI TV Wonder 650 card that was discussed earlier in this thread. ($30 after rebate, free shipping, & free remote) from newegg.
http://www.newegg.com/Product/Product.aspx?Item=N82E16815306020&Tpk=ATI%20TV%20W onder%20HD%20650

This looks to be the same card as the one at Fry's that was linked to previously, except the model number on the one from Fry's has a 2 on the end (TVW650PCIEV2) and the one from newegg (TVW650PCIEV) doesn't. Is there a difference between the two?

I'm seriously thinking of picking up this card and fiddling around with it, seeing what my results are. However, I just want to double check that this card from newegg is capable of capturing uncompressed or huffy (or similar) video, correct? If I understand correctly, this is done through VirtualDub, right?

[usually_quiet]

I have been tracking prices and reviews for that card at Newegg. It is the same card, possibly with updated packaging, since one of the Newegg reviewers claims that his box had the Windows 7 Logo printed on it. The box for the one Fry's sent me didn't have it.

The remote is a good deal if you do not plan to use the card with PVR scheduling software to record from a cable box line out. The included IR receiver doesn't support the use of an IR blaster.

[Edit]I am not using it for uncompressed capture. (I wanted to be able to use hardware encoding to time-shift TV shows). However, using the right software to bypass hardware encoding, it is possible to do what you want to do.