Batch Processor is slow and crash-prone

jaydear

Member
I've been using the Batch Processor quite a lot since you guys helped me to get it working. Many thanks for that. Unfortunately it is slower than the main program and also intermittently locks up. I can live with the slowness, but the lock-ups are a darn nuisance, especially if I've set it to do 4 encodes and the first or an early one fails - Murphy's Law in action :rolleyes:

Some mp4 BP encodes lock up at 99% which I think suggests that it couldn't handle the moov atom process. In all cases, if I run failed BP encodes directly in VRD rather than through the Batch Processor they succeed, quicker and usually without locking up. My source files are all *.ts and for all my edits/encodes I save an mp4 and a ts file. The saved ts file is at the same resolution as the source ts but the mp4s are all 720p so take much longer of course.

If VRD totally fails to manage an mp4 encode, I can always convert the edited ts in VidCoder (HandBrake). The BIG problem with that is that there is no way I have found to generate a chapter file in VRD that is acceptable to HandBrake nor MKVToolnix GUI and I really need the chapters in my mp4s and mkvs!
 

jmc

Well-known member
"Some mp4 BP encodes lock up at 99% which I think suggests that it couldn't handle the moov atom process"

You can find the usable file where ever you set your "temp" to if the problem is "moov atom".

Or turn "moov atom" off and redo the process.
 

Danr

Administrator
Staff member
It's tough to imagine how batch could be any slower than interactive since they are using the exact same program (VideoReDo6.exe). What batch does is invoke TVSuite via COM calls rather than via respond to user actions invoked from the keyboard and mouse. Any chance you can give us some examples between batch and interactive of editing the same file / project? The key metric to look for is "frames / second" in the output status dialog. There is a copy of this information in the log file as well.

Pro tip: When benchmarking video edits and saves always do it twice since the first time you save a file, Windows will cache the contents in unused memory and the 2nd time it will read from memory, if it can, rather than from your SSD or hard drive. Then take the best result as your final measurement.

Regarding the stall at 99%, MOOV atom copies are no longer a big thing in V6 since the default is to reserve space for the MOOV atom at the front of the file and fill it in later at the end of the save. There's a way to override this, but this is the default. If batch is stalling then email the log file to us at support and we can start figuring out what the issue based on that. Don't delete the original source file and/or project as we might need a copy those as well.
 

jaydear

Member
I've been quitting VRD after queueing all my edits. Reason being that if I leave VRD running and Run the batch, VRD always crashes at the end of the job and the PC doesn't turn off. I restart the PC to "flush" it out, start VRD Batch Processor directly, check the job list is all there and hit Run. If VRDBP doesn't crash, it all completes normally and the PC shuts down.
 

jaydear

Member
"Some mp4 BP encodes lock up at 99% which I think suggests that it couldn't handle the moov atom process"

You can find the usable file where ever you set your "temp" to if the problem is "moov atom".

Or turn "moov atom" off and redo the process.
I'll look into that, thanks
 

Danr

Administrator
Staff member
Here's the logic for Version 6, which is quite a bit different from V5:

If the output profile specifies put MOOV at the front, and you are NOT doing a QSF, then there is no longer a temp file. Instead we reserve space at the front of the file for the MOOV atom and fill it in after all the audio and video data is written. If you're doing a QSF and put MOOV is "at front" then it works like V5. A temporary file is created for the audio and video data, the MOOV atom is created in the final mp4 output file and then the audio and video data are copied over from the temp file to the final mp4 output. This is because QSF does not determine the file duration when opening the file.
 

jmc

Well-known member
Very good to know!

Could see getting very confused...Where is that blasted temp file.
Now you see it now you don't.

Thanks.
 

Danr

Administrator
Staff member
The temp file defaults to the output folder. You can override it from the Tools>Options>H264/HEVC page.
 
Top Bottom