Odd rendering behavior with MSP8: bug & workaround

Post Reply
JaySigel

Odd rendering behavior with MSP8: bug & workaround

Post by JaySigel »

I'm an experienced user of MSP7 and started using MSP8 a month ago or so. There is a bug when rendering a simple AVI to MPEG file. If you have not "really" edited the AVI, that is, no video filters applied and only did trims, cuts and pastes but no frame editing, the render takes twice as long as when you edit the file by applying video edits. That's right: AN EDITED FILE RENDERS TWICE AS FAST AS UNEDITED FILE. This is "bass-ackwards."

For example, if you have a high quality AVI file, say, from your digital video camera, and it only needs a snip here and there and you are now ready to make it into an MPEG to eventually place on DVD, when you render it, it is a 2 step process. First, the preview screen will stay blank, the time code staying at 00:00:00:00 the entire time. The progress bar will move across the bottom of the screen and the ETAs will be calculated. As the remaining time approaches zero, the second step begins. The remaining time will appear to stall as the preview screen NOW shows the video clip from the beginning and runs through it with screen refreshes at about 1 second per refresh as the time code now starts increasing on top of the preview window. So, if you have an hour AVI that you are so rendering, the initial render will proceed slightly faster than real-time to about 3 minutes left (although you do not see anything in the preview window and the time code stays at 00:00:00:00), at which time, the preview NOW begins, at real-time once again, with the file only now being displayed in the preview window, the time code now starting to "tick" upwards and taking another hour in real-time. The displayed 3 minutes left will decrease extremely slowly, taking a full hour to decrease to zero and actually complete the render. So, an AVI file that would take, with this computer, about 65 minutes to render a 60 minute AVI with MSP7, now takes almost 120 minutes with MSP8.

I have written to tech support asking them why is MSP8 doing this when MSP7 never did this and their suggestions have been reinstalling MSP8, looking for new video device drivers and reinstalling Windows XP! I can tell you that this behavior has been identical when MSP8 has been run on 3 completely different computers. Tech support also said the longer rendering speed was caused by MSP8's need of increased computing horse-power compared to MSP7. I say baloney!

I then noticed, by accident, that if you apply a video edit, such as cropping the sides of the frames, that the file now renders in real-time, showing up immediately in the preview window, with one run-through, much faster! As I type this, a 1:59:00 file is rendering with an estimated time (at about 80% completion) of 2:08:00. This is practically real-time and the preview has little hesitation. To accomplish this, I applied the cropping edit and set the height and width to 100%, so it does absolutely nothing to the frames themselves. To apply a video edit that does nothing is stupid, of course, but it works!

So, this might be idiotic, but until Ulead fixes this, it works: To dramatically speed up the rendering of a plain AVI without real video edits applied (trimming and insertions do not count here as edits by this definition), apply the crop edit from 2D Mapping to the entire file and set the beginning and ending crops percentages to 100% height and width (the percentages indicate what you have left - so, a 100% means you haven't cropped anything).
sjj1805
Posts: 14383
Joined: Wed Jan 26, 2005 7:20 am
operating_system: Windows XP Pro
System_Drive: C
32bit or 64bit: 32 Bit
motherboard: Equium P200-178
processor: Intel Pentium Dual-Core Processor T2080
ram: 2 GB
Video Card: Intel 945 Express
sound_card: Intel GMA 950
Hard_Drive_Capacity: 1160 GB
Location: Birmingham UK

Post by sjj1805 »

Just to satisfy my curiosity and possibly provide a reason for this apparant anomoly.

When you made those edits did you then play the edited clip in the preview window before moving onto the next edit?

If so the bit you just watched got rendered at the time you watched the preview. The smart render process kicks in when you later render the entire project. So bits that you have edited and previewed will now appear to 'render' quicker than bits that you have left untouched (or unwatched)
JaySigel

"You are moving very slowly..."

Post by JaySigel »

which is what Spock says to Kirk in the original Star Trek series episode "The Wink of an Eye."

Thanks for responding, but please re-read what I wrote. It matters not one bit the order in which you apply the edit or whether or not the clip is played before rendering it. Take a clip of significant duration - I just captured a 1 hour TV show. I cut out all of the ads and it is 45 minutes long. I applied a crop edit, cutting nothing off the sides (it's set to 100% for width and length), so I have basically done nothing to change the clip. The estimated time to completion for rendering this file on my 2 year old Gateway laptop is 44 minutes and the MPEG is being written to a USB drive at that. The video plays in the rendering window as the file is rendered and the time position is advancing appropriately. The rednering behavior is nearly the same as with MSP7. Total rendering time is 44 minutes.

Now, take that same clip and don't apply any edits (cutting out ads has no effect on this and is not, by definition, a video edit) and the behavior is VERY different. First, the rendering window is totally blank and stays blank until almost the end of the estimated time to completion. The timer stays at 00:00:00:00 but the estimated time to completion is about the same, about 40 minutes. Something is happening, I guess, because the completion bar progresses at the bottom of the screen and the estimated time to completion decreases. Near the end of that 40 minutes, say at about 2-3 minutes remaining, the second phase then begins. The estimated time to completion dramatically slows down, the file is only now displayed in the rendering window and the clock advances from 0 to 00:45:00:00 (45 minutes) in 1 second increments and the displayed video is not smooth, but a frame is displayed each second almost like a Power Point show. The 3 minutes left to completion very slowly decreases over the next 45 minutes and you have to watch very closely to see it decrease at all. It's like being in a time warp! So the first phase, ended at 37 minutes (40 minus 3), then the second phase took another 45 more minutes to complete the render, for a total of 82 minutes - almost double the time.

There is no difference in size or quality of the resultant MPEGs. It matters not one iota whether you use Smart Render or not. It matters not whether you render the file individually or batch them with the Create Multiple Files option. No preference setting makes any other difference including video bit rate, variable or constant nor any advanced options. If you apply a video edit, the render processes at almost double the speed than if you don't. This behavior occurs on multiple computers with different video cards, processor types (AMD vs Intel, 64 bit vs 32), Windows XP Home or Pro, EIDE, SATA, or USB drives, different amounts and types of RAM, phase of the moon or ambient humidity. Whoever wrote the code for rendering did not expect us to use no video edits (pardon the double negative). But, if you take video pictures under good conditions and don't need to adjust each frame, or capture off of a high quality digital source, like satellite, and don't need to edit the video, you will have twice as long video rendering if no video edits are applied. If you don't mind rendering a 2 hour movie over 4 hours, then you don't need to do anything else. But you can render that 2 hour movie in about 2 hours just by applying this silly video edit, in this example, applying the crop edit but telling it to crop absolutely nothing! I have not attempted this with other edits, like audio. But it is harmless to apply a crop nothing edit and it doubles the rendering speed. Anyone reading this - try it yourself.
Post Reply