VHS Capture Using PotPlay(for Editing): MP-4 and H264 vs. AVI and Huffyuv?

[Avagadro1]

..

[abolibibelot]

Of course capturing to a lossless format is much better than compressing on-the-fly to a highly compressed format like H.264, especially when the goal is to further edit the footage. That said Huffyuv is an old codec, there are more efficient and more versatile lossless codecs which shouldn't cause performance issues on a recent machine. From what I've read here, UT Video would seem like a good choice — there are codecs with a better compression ratio, like Lagarith, or FFV1, but UT reportedly has the "fastest scrubbing in editors".

[jagabo]

Note that some h.264 encoders support lossless, 4:2:2, interlaced, and very fast encoding too (x264 for example). It depends on the settings you use.

With lossless encoders the difference in file size usually isn't that big, especially with VHS caps. Use whatever works.

[Avagadro1]

..

[johnmeyer]

Before you change your entire workflow, and before you go back and re-do anything (if you are considering that), why not simply do a few tests and compare the results on your main viewing device? Twenty years ago, I was at the same point in my learning curve as you are now, and I must have done a hundred tests on every aspect of the capture, editing, and encoding process to find out what made a difference. Some things, like doing IVTC on material that was originally film but hard-coded with the telecine "baked in" made a massive difference. The bitrate made a huge difference, but I found there were quite a few "inflection points" where, if you got below a certain number, the results got really bad.

I also found that there was a massive difference between encoders. MPEG-2 from one company performed quite differently than MPEG-2 from another company. This is still true, and I found that the results from using the two h.264 encoders built into my semi-pro NLE (Vegas Pro) are awful compared to the open source h.264 encoder available in Handbrake and MeGUI.

The problem with the way you're asking the question here, and with the well-meaning responses, is that you end up with advice like "HuffYUV/Lagarith is 'always' going to be better than h.264." What I am saying is that given that you are starting with VHS (resolution and color issues that are an inescapable limitation of the format no matter how good your VCR or capture setup), you may find that you don't need to make that many changes to what you are already doing (your setup sounds pretty good).

But the only way to know for sure is for you to do your own tests.

[abolibibelot]

It can also be argued the other way around : since VHS quality is low to begin with, and if it's worth converting at all, the native quality should be preserved as much as possible, within the constraints of available budget (and time). Good capture hardware can be expensive (increasingly so it would seem), so settling for a decent device rather than the top of the line can be a reasonable compromise if it allows to go through with the task rather than idling it for years. But the choice of a lossless codec for the capture step is a part of the setup that costs nothing (all required tools are free), except some time to get up to speed with new methods, but there are good guides out there and it shouldn't be more complicated than learning the current method was, so if it improves the end result ever-so-slightly (and it probably improves it way more in the eyes of someone with experience{*} than someone just starting out, so doing hundreds of tests as a beginner in such a tricky field isn't even guaranteed to provide a conclusive and/or wise answer), it's a, what's the word ? a no-brainer.

{*} Ask Mr. lordsmurf what he thinks about capturing straight to H.264...

is it likely that a near-lossless, only slightly compressed format will make a difference when I'm done editing?

Lossless is lossless, not "near lossless". Of course analog to digital conversion is not lossless by its very nature, but a lossless codec preserves 100% of the acquired information, and then each time losslessly encoded footage is edited then re-exported as lossless, the native quality is preserved (except for things like colorspace conversions). Whereas, each time footage encoded in a lossy format is edited and re-exported in a lossy format (even if it's the same format at the same bitrate) some of the native quality is lost, and if several such operations are performed the losses are compounded.

[johnmeyer]

But the choice of a lossless codec for the capture step is a part of the setup that costs nothing (all required tools are free), except some time to get up to speed with new methods, but there are good guides out there and it shouldn't be more complicated than learning the current method was, so if it improves the end result ever-so-slightly (and it probably improves it way more in the eyes of someone with experience{*} than someone just starting out, so doing hundreds of tests as a beginner in such a tricky field isn't even guaranteed to provide a conclusive and/or wise answer), it's a, what's the word ? a no-brainer.

I have to disagree that having a "newbie" do their own tests is a bad idea. It is exactly the opposite; its a good idea for two reasons.

First, it will help them learn "by doing" so that they understand what the heck they are seeing. Once they start learning, they will better be able to sort through the sometimes conflicting advice given in this, and other, forums. I've seen a lot of very bad advice given, and then taken, to people just starting out. However, once they have done the tests themselves, they will begin to know what to look for and better be able to sort out the good ideas from the bad ones.

I remember being a newbie 20+ years ago and I remember doing tests on MPEG-1 encodes for VCDs using TMPGEnc. I quickly learned what sort of compression artifacts it created and therefore what to look for. When I graduated to MPEG-2 for SVCD (and eventually DVD), I learned about what bitrates gave me satisfactory results. Then, when I purchased several professional MPEG-2 encoders (Mainconcept and Canoupus Procoder), I found out the difference between poor encoders and good ones, and also found out what a difference multi-pass encoding actually made.

The second reason gets to the heart of so many disagreements in this, and other, forums and that is, what looks good? You would think this is something that could be answered objectively, but it can not. This is because some people are very sensitive to certain things, and others are not. A good example are the debates about front view projectors over at the AVS Forum: some people hate DLP projectors because they claim they see rainbows around fast moving objects. Other people claim they've never seen them. Since DLP projectors have other visual advantages, if you can't see the rainbows, you'll probably end up happier with that technology, but if you can see the rainbows, you'll never be happy with DLP.

Finally, the only "no-brainer" here is that the OP should never use uncompressed for anything, especially capture, since it is very difficult to sustain the data transfer rate without dropping frames, and instead should use a lossless codec, if they can do so without dropping frames. The frame dropping issue is a big deal, given the hundreds of posts I read every year about a newbie capture that has duplicate frames which is what newbies usually notice first. Those dups are caused by the capture software dropping a frame and then inserting a dup a few frames later in order to keep the sound in sync. This should never happen in any capture setup, but the higher the bitrate used, the more susceptible the capture becomes to this problem in any computer that has a compromised disk subsystem. This compromise can easily happen, especially if you have lousy anti-virus software. It inserts itself into the read/write operations and can bring a PC to its knees. I've serviced dozens of "client" computers that have this problem. In the old (IDE) days, messed up DMA was a sure recipe for dropped frames.

So, do your own tests, based on advice you receive because its the only way you can know if you are actually getting a better result.

[Avagadro1]

..

[davexnet]

Thank you all for your thoughtful additions.

Based on all of this, a couple of hours ago I downloaded VurtualDub and the Huffyuv codec. Installing Huffyuv on my Windows 7-64bit machine was a bitch, notwithstanding the guides and tutorials, but I finally got it installed. I have read that Huffyuv, while still very good, hasn't been further developed in many years. The suggestion is that since I am learning everything from scratch --- no significant legacy issues to contend with --- consider using the more modern and more efficient UT Video codec instead of Huffyyuv.

In light of the truth of my having to learn everything from scratch, and if it's correct that UT Video codec is now the better codec, would you agree that I should focus on learning to capture from VHS using it, rather than Huffyuv? By interesting contrast, for my intended purposes --- capturing VHS --- it does not appear that there is a new/better/more-highly recommended utility than VirtualDub . . . at least that I have thus far found.

Again, thank you all for your comments.

Virtualdub capture works for some but not for others, main problem being audio/video sync.
The settings used by one person may not work for the next person, etc,etc.

Those that give up on Virtualdub usually switch to AmarecTV or IUvcr.

You'll have to try it and see

[abolibibelot]

I have to disagree that having a "newbie" do their own tests is a bad idea. It is exactly the opposite; its a good idea for two reasons.

It's not that it's a bad idea per se, rather that the subjective impressions one can get with little experience, not knowing exactly what to look for, can be misleading when it comes to choosing a method / workflow with many moving parts and intricacies. It reminds me of that phrase from Mark Twain once quoted in Dexter (when it was still a good show, that was a long time ago) : “You can't depend on your eyes when your imagination is out of focus.” In this particular case, doing tests thorough enough to see the end result (after capturing, editing, rendering, encoding) with several combinations of methods would take quite some time, a time that might be best used learning the “tried and true” method.

First, it will help them learn "by doing" so that they understand what the heck they are seeing. Once they start learning, they will better be able to sort through the sometimes conflicting advice given in this, and other, forums. I've seen a lot of very bad advice given, and then taken, to people just starting out. However, once they have done the tests themselves, they will begin to know what to look for and better be able to sort out the good ideas from the bad ones.

They can also be sorted out based on how logically argued they seem to be.

I remember being a newbie 20+ years ago...

But you became quite an expert, creating advanced scripts and all... Some people wouldn't reach that level in 100 years, possibly because they lack the required dedication, but possibly also because it requires some innate skills, like quickly learning what to look for and being able to spot subtle differences that most people simply don't see.

[data transfer and duplicated frames]
Is it still an issue with current technology, i.e. large and fast HDDs (plugged internally or through USB3) and CPUs vastly more powerful than what's needed for capturing SD footage ?

but the higher the bitrate used, the more susceptible the capture becomes to this problem in any computer that has a compromised disk subsystem. This compromise can easily happen, especially if you have lousy anti-virus software. It inserts itself into the read/write operations and can bring a PC to its knees.

Interesting observation but that's an abnormal behaviour which should be fixed as it can have many other adverse effects.

[johnmeyer]

Interesting observation but that's an abnormal behaviour which should be fixed as it can have many other adverse effects.

I would guess that out of several dozen computers I've had to fix for other people, pretty much every one of them had massive problems caused by Norton, McAfee, and even Avast. These were not subtle. The worst was one computer which, when I tried to run Microsoft Word, took over two minutes before the app came up. I hate anti-virus software and don't have it on any of my dozen computers. I even turn off Windows Defender. Again, based on experience helping other people, the malware they get does NOT result from some hacker breaking into the their computer but is, in my experience, 100% the result of falling prey to a phishing attack. And boy do I have stories to tell about how intelligent people have gotten sucked into doing really stupid stuff that no watchdog software (i.e., anti-virus software) could ever stop.

[data transfer and duplicated frames]
Is it still an issue with current technology, i.e. large and fast HDDs (plugged internally or through USB3) and CPUs vastly more powerful than what's needed for capturing SD footage ?

As for capture being less of a problem because computers now are better than in the past, in actual fact computers have not gotten faster in over a decade: clock speeds stalled out at about 3.5 GHz for stock computers because of laws of physics relating to electron speed through copper. All performance improvements have come from parallelism which is great for things like rendering which can be split up into a dozen or more pieces and worked on simultaneously, but for something like capture, there is no benefit. As a result, many of the capture issues that plagued us many years ago are still with us today. Just look at all the sick puppies presented on this forum where the video has dropped frames.

[poisondeathray]

As for capture being less of a problem because computers now are better than in the past, in actual fact computers have not gotten faster in over a decade: clock speeds stalled out at about 3.5 GHz for stock computers because of laws of physics relating to electron speed through copper. All performance improvements have come from parallelism which is great for things like rendering which can be split up into a dozen or more pieces and worked on simultaneously, but for something like capture, there is no benefit. As a result, many of the capture issues that plagued us many years ago are still with us today. Just look at all the sick puppies presented on this forum where the video has dropped frames.

Computers have gotten much faster, and it's not just from parallelism

There is a concept called Instructions per Clock, (IPC)

At the same clock speed, operations are completed faster on newer architectures and generations of computers - Even if you discount CPU tasks that have optimizations or SIMD that older CPU's did not, like SSE2, AVX2 . If you include those , with tasks that can benefit (e.g. some encoders), they are much faster at the same clock speed

SD Frame drops are rarely from inadequate CPU these days. Look for other reasons. If the person hovers around 95-100% CPU usage , then you might consider it a factor, but on a modern computer capturing SD, you're usually far below that