I am using Video Studio 8 (just upgraded) and have the necessary patches etc. I have a good Sony digital camcorder plugged into a pretty kick-arse system via Firewire – BUT I CANNOT SOLVE THIS CAPTURING PROBLEM. After about 5 minutes of capturing it has to ‘flush the transcode buffer’ – which halts capturing for extended periods of time. If I want to capture several hours of stuff, I have to stop and start DOZENS of times. Very, very frustrating! I have just seen a couple of other posts on the issue and am beginning to learn more, but still think I could improve things a bit.
REASONS WHY I SHOULD CAPTURE SEAMLESSLY:
1. Pentium 4, 2.8Ghz with hyperthreading & 512mb of RAM
2. Two 40G hard drives (D: used solely for capturing)
3. ALL other programs and several processes terminated.
4. DMA enabled & write-behind caching disabled (as recommended)
5. Several earnest prayer sessions to the PC Gods
REASONS WHY I DON’T:
1. ?????
Can somebody please help me and I will bear their children. I am male, but I will find a way! I capture as DVD (Mpeg-2) – should I do it as AVI? Will more RAM improve things much? The strangest thing is that AFTER the software upgrade and AFTER points 3 and 4 were even adopted, the problem has gotten WORSE.
Please help a brother out and prevent some unnecessary violence.
Aziz
CAPTURING – can someone help me PLEASE!
Moderator: Ken Berry
-
Steve__A
Aziz:
With a digital camcorder plugged into a firewire port you would normally want to capture the video in AV format. Capturing it in MPEG-2 format requires that it be compressed and converted, which can be CPU-intensive.
Captures in MPEG-2 format usually work better if the compression/conversion is done in hardware, with a capture box or board, since there isn't a big hit to the CPU.
The downside to AV captures is that they do require about 5 times the hard drive space as MPEG-2 captures, and you can figure on many hours to render your edited AV for DVD output. But on the positive side, you should be rewarded with higher quality results and sharp edits (MPEG-2 was designed for delivering video, not editing it!
)
Steve A.
P.S. I think I'll pass on the offer to bear my children...
With a digital camcorder plugged into a firewire port you would normally want to capture the video in AV format. Capturing it in MPEG-2 format requires that it be compressed and converted, which can be CPU-intensive.
Captures in MPEG-2 format usually work better if the compression/conversion is done in hardware, with a capture box or board, since there isn't a big hit to the CPU.
The downside to AV captures is that they do require about 5 times the hard drive space as MPEG-2 captures, and you can figure on many hours to render your edited AV for DVD output. But on the positive side, you should be rewarded with higher quality results and sharp edits (MPEG-2 was designed for delivering video, not editing it!
) Steve A.
P.S. I think I'll pass on the offer to bear my children...
-
jchunter_2
-
rwindeyer
I agree with Steve_A - mpeg capture can be a hassle. In theory your equipment should be up to the task; if you wish to continue in that direction maybe others on the board can help you out. But for some reason it isn't - the flushing transcode buffer thing means that the avi-to-mpeg process is taking time and the computer has to stop capture to let itself catch up.
I confess to personal bias here; I always capture to DV format. There is no processing required on the way in, so no chance of the problems that are bedevilling you right now. Also, mpeg is a lossy format like jpeg; my brain thinks it makes more sense to keep the data in full while editing, adding transitions and sound tracks etc etc. When I am finally happy with the product, the completed project is transcoded to mpeg and burned to DVD.
(jchunter2 has presented lots of evidence that re-rendering mpegs multiple times does not degrade quality; coalman has presented some contrary evidence. Believe what you like; theoretically there could be some quality loss and I choose to go this way.)
The only downside is space usage (13 Gb per hour of video) and the whole transcoding process may take a little longer. Worth it for quality IMHO.
I confess to personal bias here; I always capture to DV format. There is no processing required on the way in, so no chance of the problems that are bedevilling you right now. Also, mpeg is a lossy format like jpeg; my brain thinks it makes more sense to keep the data in full while editing, adding transitions and sound tracks etc etc. When I am finally happy with the product, the completed project is transcoded to mpeg and burned to DVD.
(jchunter2 has presented lots of evidence that re-rendering mpegs multiple times does not degrade quality; coalman has presented some contrary evidence. Believe what you like; theoretically there could be some quality loss and I choose to go this way.)
The only downside is space usage (13 Gb per hour of video) and the whole transcoding process may take a little longer. Worth it for quality IMHO.
-
thecoalman
That just may be it, I'm pretty sure all Ulead products use the Mainconcept encoder. There was just a recent upgrade to MSP which I'm guessing updated the encoder as it enabled 2-pass VBR encoding. Possiblty the encoder on VS8 was updated and it's a litte slower???Aziz wrote: The strangest thing is that AFTER the software upgrade and
Anyhow IMO use AVI for capture and editing.
We did some benchmarking tests on another board I'm a member of, it was pretty straight forward. Same source file, same encoder (TMPGenc), same settings. Disabling HT improved encoding times in all cases but just slightly, nothing to write home about. For HT to have an affect the application has to be designed to take advantage of it.jchunter_2 wrote: Is hyperthreading really enabled? (You should see two performance graphs in the Task Manager)
John
You can find the benchmarking tests in the coputer forum here http://www.videohelp.com I'd list the exact URL but it appears my IP has been blocked again, nothing to do with me mind you just another computer in my IP range hitting the server a couple thousand times a minute which gets me blocked
I had the same problem captureing from firewire to MPEG in VS8, I read somewhere that there are capture boards that use a MPEG hardware encoding chip to encode MPEGs, this takes the load off the processer and memory.
About two years ago I purchased a Hauppauge PVR-250 Capture board (hardware MPEG encoding), and am very happy with the results.
With the PVR-250 you have to use s-video or composite inputs but I can not see any difference between the MPEGs and AVI files after they have ben rendered and put on DVD.
The reason I use the PVR-250 is that it saves time converting AVIs to MPEGs, a large amount of time.
You might want to try the Hauppauge PVR-250 USB version, that way you can have a portable capture solution.
About two years ago I purchased a Hauppauge PVR-250 Capture board (hardware MPEG encoding), and am very happy with the results.
With the PVR-250 you have to use s-video or composite inputs but I can not see any difference between the MPEGs and AVI files after they have ben rendered and put on DVD.
The reason I use the PVR-250 is that it saves time converting AVIs to MPEGs, a large amount of time.
You might want to try the Hauppauge PVR-250 USB version, that way you can have a portable capture solution.
-
Aziz
I capture @ 6000mbps in full PAL (25fps / 720x576 I think). For the 5 minutes or so that it works, the results are great and edit from there without any problems - I just don't like having to monitor it so much during capture phase.jchunter_2 wrote:Aziz,
Please post your detailed capture properties.
Also, how much free space do you have in each drive?
Have you monitored memory and CPU usage while capturing?
Is hyperthreading really enabled? (You should see two performance graphs in the Task Manager)
John
I would typically have a 30 or 40 GB free on the D: drive.
I don't really know if hyperthreading is enabled? I assumed it would be automatically. How is this done? Is it actually worth doing?
I think I just have to bite the bullet and capture AVI - probably need to get a couple of bigger HDD's.
Thanks for the replies everyone!
Aziz
-
grosgras
HauppaugePVR250
I Use The PVR 250 PCI It's Great .
I record at DVD Standard (1 hour) with the card software.
But when I edit the movie in Video Studio and create a video file, Same as project settings and Smart render, that's fast, but
my Titles and Transitions looks ugly.
So I have to re-render the movie, that's not fast about 3 x times,
or I dont use titles or transitions in the movie.
I record at DVD Standard (1 hour) with the card software.
But when I edit the movie in Video Studio and create a video file, Same as project settings and Smart render, that's fast, but
my Titles and Transitions looks ugly.
So I have to re-render the movie, that's not fast about 3 x times,
or I dont use titles or transitions in the movie.
-
jchunter
Aziz,
How much free space is on the C drive? This is where the swap file is built. Where is the transcode buffer? I think Torsten Hoff has looked into VS temp files. Torsten? Your system could be choking here.
I have not done tests of the effectiveness of hyperthreading but I did notice lower CPU-Busy readings while capturing digital video to mpeg2. It may, at least, offer additional headroom for other processes that are competing for attention. This is pure speculation.
BTW. Hyperthreading is enabled in the bios. If it is enabled, you should see two performance graphs in the Task Manager.
How much free space is on the C drive? This is where the swap file is built. Where is the transcode buffer? I think Torsten Hoff has looked into VS temp files. Torsten? Your system could be choking here.
I have not done tests of the effectiveness of hyperthreading but I did notice lower CPU-Busy readings while capturing digital video to mpeg2. It may, at least, offer additional headroom for other processes that are competing for attention. This is pure speculation.
BTW. Hyperthreading is enabled in the bios. If it is enabled, you should see two performance graphs in the Task Manager.
-
Aziz
Capturing & flushing the transcode buffer
I usually have over 30Gig free space on each of my two 40's (recently didn't notice much difference when both began to get about 75% full).jchunter_2 wrote:Aziz,
Also, how much free space do you have in each drive?
Have you monitored memory and CPU usage while capturing?
Is hyperthreading really enabled? (You should see two performance graphs in the Task Manager)
John
I have experimented with the swap file and now have a fixed 512mb on EACH DRIVE which seems ok - there is mixed advice on this, but I'm pretty sure that when the PC starts to use the page file, things slow down.
I was capturing again the other day while monitoring the Task Manager and noticed that at the most intense moments the CPU (hyperthreading definitely enabled) was only peaking at about 55%. Basically over the course of 5-10 minutes the amount of available physical memory nosedived from about 350mb to 30mb (at which point the DV transcode buffer is flushed). In the meantime, the page file gradually builds up to about 500mb.
Obviously while there is RAM available, it copes perfectly, but as the page file is used more, the system begins to struggle. It's good to know it's not the CPU and while I may never capture really long sections as MPEG, increasing RAM to 1 or 1.5 GB looks like it will help more than anything.
Cheers all - hope this eases future transcoding frustrations for others.
jack
-
THoff
Actually, I think the CPU is the problem. If it could keep up with the transcoding in realtime, the buffer would never fill up.
I would try this: turn off virtual memory completely and reboot. Defragment your drive and reboot. Create a new, larger, permanent swapfile where the minimum and maximum are the same so it doesn't get sized dynamically. Defragment. You should now have a single, contiguous swapfile. If the Disk Indexing Service is enabled, consider disabling it. Exclude the capture / temp file locations from virus scans.
See if that removes the I/O bottleneck that is killing your transcoding. There is little you can do about speeding up your CPU, short of possibly overclocking it a little or swapping it out for a higher-speed processor, but you should be able to reduce the I/O times.
I would try this: turn off virtual memory completely and reboot. Defragment your drive and reboot. Create a new, larger, permanent swapfile where the minimum and maximum are the same so it doesn't get sized dynamically. Defragment. You should now have a single, contiguous swapfile. If the Disk Indexing Service is enabled, consider disabling it. Exclude the capture / temp file locations from virus scans.
See if that removes the I/O bottleneck that is killing your transcoding. There is little you can do about speeding up your CPU, short of possibly overclocking it a little or swapping it out for a higher-speed processor, but you should be able to reduce the I/O times.