Hi there. I'm using VS8 full version with all patches and such installed, and I'm following the Recommended Procedure. I'm trying to capture to MPEG2 because I have plenty of computer horsepower to do so. I've set up all capture properties (by clicking the little gear icon on the Capture tab) to be those in the Recommended Procedure, to wit:
NTSC drop frame (29.97 fps)
MPEG files
24 Bits, 720 x 480, 29.97 fps
Lower Field First for digital capture {if capturing analog use "Upper Field First"}
(DVD-NTSC), 4:3
Video data rate: Variable (Max. 8000 kbps)
Audio data rate: 224 kbps
MPEG audio layer 2, 48 KHz, Stereo
except for the VBR. That I've set to Constant. I had some troubles with outputted videos to DVD previously that Ulead Tech Support suggested might be improved by setting the VBR on output to CBR instead. That DID make the problem go away, so I'm trying to Capture with an 8k CBR since that's what I'll be eventually outputting. BTW, I'm outputting to DVD as my final output type.
Anyway, when capturing using this setup (or also when trying the presets of DVD or MPEG on the Capture screen), as soon as I stop capturing I get a box popping up saying "Flushing DV transcode buffer" with a number counting down of frames remaining. This takes quite a long time.
Am I setting something up wrong in my capturing, or is this just part of how it works trying to capture to MPEG2, that when doing so the PC will transcode (I presume that means, essentially, "convert") immediately on capture?
I was hoping to speed things up by capturing to MPEG2 in a format exactly like I'm going to output since the RecProc says "Capture to MPEG2...because the whole video editing process to DVD burn will be faster and simpler". I've previously captured using DV format, but would like to try the MPEG2 if it'll speed things up over the long run. However, if I have to allow the PC to "transcode" after every capture that isn't going to speed things up for me IMHO; I'd rather let it work harder in the Create Video File phase if that's the case.
ADW
"Flushing DV Transcode Buffer": VS8
Moderator: Ken Berry
- Ken Berry
- Site Admin
- Posts: 22481
- Joined: Fri Dec 10, 2004 9:36 pm
- System_Drive: C
- 32bit or 64bit: 64 Bit
- motherboard: Gigabyte B550M DS3H AC
- processor: AMD Ryzen 9 5900X
- ram: 32 GB DDR4
- Video Card: AMD RX 6600 XT
- Hard_Drive_Capacity: 1 TB SSD + 2 TB HDD
- Monitor/Display Make & Model: Kogan 32" 4K 3840 x 2160
- Corel programs: VS2022; PSP2023; DRAW2021; Painter 2022
- Location: Levin, New Zealand
This is one of the hard lessons that every user must learn in his/her own way. You say your computer has plenty of power to capture direct to mpeg-2. But you are now in fact learning that this might not be entirely the case.
Yes, some people can capture direct to mpeg-2 with no problems. Others get the sort of message and reaction you do.
As you may be aware, when capturing from a DV source to mpeg-2, the video signal is converted on the fly. You are correct in your assumption that transcoding and converting in this case are one and the same. But if the signal is coming over a firewire connection, then it is coming in at a great rate of knots.
If your computer is not quite up to dealing with the incoming volume of digital signal at high speed and able to convert it all on the fly as it comes in, then inevitably a backlog starts to develop. The backlog is stored in a buffer, called for obvious reasons a 'transcode buffer'.
Some computers may be completely underpowered for this process, and the buffer fills up quickly, and the capture will be paused every few minutes to allow the data in it to be processed and converted out. When the buffer is empty again, capture resumes.
Your computer may be in a mid-zone -- and you may be capturing in chunks which the computer/buffer can handle -- and the processing only takes place (or at least finishes) after you have captured each chunk.
If you feel the time taken to process what is in the buffer is not acceptable, you can always revert to capturing and editing in DV format, and do the conversion mpeg-2 as a separate step at the end. That is what a lot of us here always do. And of course, you have also done it and know that it always -- well almost always!
-- works.
BTW -- if you check my system button, you will see we have computers with fairly similar resources. I got the same sort of message as you did, and gave up trying to capture direct to mpeg-2 as the process was neither smooth not swift. Added to that, of course, are the difficulties that can often arise when editing mpeg-2.
Yes, some people can capture direct to mpeg-2 with no problems. Others get the sort of message and reaction you do.
As you may be aware, when capturing from a DV source to mpeg-2, the video signal is converted on the fly. You are correct in your assumption that transcoding and converting in this case are one and the same. But if the signal is coming over a firewire connection, then it is coming in at a great rate of knots.
If your computer is not quite up to dealing with the incoming volume of digital signal at high speed and able to convert it all on the fly as it comes in, then inevitably a backlog starts to develop. The backlog is stored in a buffer, called for obvious reasons a 'transcode buffer'.
Some computers may be completely underpowered for this process, and the buffer fills up quickly, and the capture will be paused every few minutes to allow the data in it to be processed and converted out. When the buffer is empty again, capture resumes.
Your computer may be in a mid-zone -- and you may be capturing in chunks which the computer/buffer can handle -- and the processing only takes place (or at least finishes) after you have captured each chunk.
If you feel the time taken to process what is in the buffer is not acceptable, you can always revert to capturing and editing in DV format, and do the conversion mpeg-2 as a separate step at the end. That is what a lot of us here always do. And of course, you have also done it and know that it always -- well almost always!
BTW -- if you check my system button, you will see we have computers with fairly similar resources. I got the same sort of message as you did, and gave up trying to capture direct to mpeg-2 as the process was neither smooth not swift. Added to that, of course, are the difficulties that can often arise when editing mpeg-2.
Ken Berry
-
andywaddell
Re: "Flushing DV Transcode Buffer": VS8
Very good, Ken! DV it will be for my capturing, then. Thanks for the prompt reply and good explanation!
ADW
ADW
