Quote:
Originally Posted by theodore1
Now the details, I am running 1.9 for one capture and 10.5 versions separately with another.
|
10.5? You mean 1.10.5? I thought 1.10.4 was the current stable release. At any rate, 1.10.x has known issues, both with capture, and some internal filters (like resize). It's not suggested, causes problems. As always, you can try, and may find success, but just remember 1.9.x is more stable for capture. Far fewer people have issues at VirtualDun capture with 1.9.x.
Quote:
I have windows 10 and found that with this windows version I cannot preview one capture(the 1.9 but i can preview with 10.5. Not a big deal breaker but its ok.
|
The issue is likely related to overlay/preview modes, both the selection, and the advanced settings. While
VirtualDub often works at default settings, not every system complies. I do often encode multiple files, with preview function fine on each. Just not capture multiples. "Preview" mode runs at application layer, not graphics layer like "overlay", which in theory is should be fine for multiples. But it doesn't always work that way real-world.
Quote:
I save as AVI file of course, and import into TMPEG for color correction chroma key etc because I am not savvy with avisynth. (I paid for the mastering and authoring tools, works for what I need it to do.)
|
I've not been overly fond of TMPGEnc for years now, aside from the Smart Renderer for H264 sync and edit needs. It has reduced quality in some areas, but it works. It's not bad, just not as good as some other options. You'll be fine.
Quote:
its processing at 8 cores 16 threads, 32gig Ram and an ati 1060 (a little over kill) but hey i can surf the net too while these captures are going.
|
It doesn't matter. Video needs maybe 1gb worth, and 32-bit capture drivers/apps only understand limited cores and RAM. In this situation, I don't like the term "overkill", sort of like "overqualified". It's simply very adequate to complete the somewhat simpler resource-use task. Video mostly needs I/O, so fast HDD or SSD. Big files.
Quote:
I have also tried encoding as well with TMPEG while the capture was in process and there was still no loss in my opinion. (if i am thinking of video loss/loss of frame correctly)
|
This is usually unwise. I/O and CPU. While the system may have dedicated cores to each task, a CPU spike in a core can adversely affect the task in a neighboring core, when it requires realtime processing like with video capture. CPU cores are never truly 100% isolated. Core isolation requires virtualization, and capture cannot run virtualized.
Quote:
What are your guys thoughts on running multiple captures through one PC?
|
This is usually a bad idea, specifically due to preview. Graphics modes are selfish, and want to hog the entire overlay mode. When you try to run multiples, problems can happen (visual corruption, BSOD/reboot), or it'll outright refuse to work. Usually the latter, refusal to work. For that reason alone, you have no idea what's happening on the video. You need to monitor video captures, at least every 5-10 minutes.
Quote:
I am inclined to push this further and will probably get another workflow to add on top of this.
|
But, that said, computers now are quite a bit more advanced than the capture system we built 10-15 years ago. If you're able to preview each capture, and the system is holding with no reported drops, then you can certainly try this. Personally, I would not do this.
Quote:
Originally Posted by sanlyn
Given your workflow, I'd say that this is extremely doubtful.
|
Why?
workflow = JVC S-VHS + DataVideo TBC + good capture card + using
VirtualDub/lossless