Tweet
I'm sure everybody using MS Pro 7 has checked out the instant playback feature. Most notably, the "Enable multi-threading" checkbox and performance slider under "Playback options."
I have made some observations regarding this feature and was hoping to hear some of your comments.
After doing some informal testing, it seems as though the multi-threading option allows the MS Pro instant preview engine to get a "head start" on preparing the real-time playback. I have noticed that if I turn off multi-threading on a scene that my computer cannot play in RT (say a moving path on a high resolution bitmap image), the playback begins immediately, but is choppy in playback. BTW, I have a P4 2.4B.
If I turn on "multi-threading," then a small portion (first few seconds) of the video to be played back is processed before the playback starts. The higher the slider, the more video is preprocessed and the longer it takes for playback to start. This is kind of like a "processing buffer."
If you have a video with short portions of high cpu loading, perhaps transitions and other things of a second or two, this buffer can allow MS Pro's RT to keep up with the video. In effect averaging the overall cpu loading of a project so that although there may be spots the cpu is unable to handle in RT, there are also parts that it can handle, and have some processor cycles left over to begin work on sections not yet playing. During these "easy" sections, the cpu can "prepare" for the next difficult section. In theory anyway. As long as the complex scenes are short and there are low cpu's scenes that allow MS Pro to pre-render, or "get ahead" of playback in order to preprocess the next difficult section before it arrives.
On the other hand, if the difficult scenes are longer than 2 or 3 seconds, by my observations and on my system, then the preprocessing buffer is used up and you are getting whatever frame rate your system can do in real-time with no "head start."
For most of my needs, I'm finding that I like turning of multi-threading. RT playback start immediately, and most of my complex scenes are longer than 2 or 3 seconds. In addition, even though the RT is not 30fps on all sections of my projects, it is very usable.
Of course it's nice to have the option. I'm not sure why Ulead decided to call this multi-threading. I think "pre-processing" would have been more informative.
Anyway, I thought I'd share my observations of this function. I'm curious to hear what others think about this.
BTW, kudos to Ulead for incorporating this feature into MS Pro. I think it will be more useful as processors become more powerful. When the cpu can almost keep up with RT rendering the preprocessing functions can serve to smooth out the rough spots.
Update! While typing this something came to mind and I tested my theory:
When the multi-threading option is off, obviously no preprocessing occurs before the video starts to play or during playback of light cpu loading portions of the video.
When "multi-threading" is enabled at a slider level of 0 a little preprocessing occurs. The question is if MS Pro preprocesses video, or tries to "get ahead" as much at this setting as at a setting of 10?
I ran some tests to answer this question.
I'll put 12 seconds of straight dv in front of a really tough section. A moving path on a high resolution image.
First I played this section from the beginning with multithreading off. When the easy section ended and the moving path began, the preview began to immediately drop frames. Also note that cpu loading was about 25% during the easy section and shot to 100% during the hard section.
Next I enabled multi-threading at a slider level of 10. This time the preview played back smoothly during the "hard" section for about 5 seconds before becoming jerky, ie preprocessing buffer ran out. cpu loading during this entire test was 100%! Great job Ulead, this is how it should be. During the easy section, MS Pro was using the 75% unused processing cycles to "prepare" the next section.
Finally, I ran this test with the performance slider set at "0." This time the preview was smooth for 4.5 seconds into the hard section! THIS IS VERY IMPORTANT! Even at a slider setting of "0" enabling multi-threading is very useful. While "easy" sections of your video are being previewed MS Pro is "looking ahead" and using spare cpu cycles to preprocess difficult sections to come.
As would be expected, cpu loading throughout this test was 100%.
Note that the .5 seconds difference between setting "10" and "0" is the result of the extra preprocessing done at the higher level.
Just to verify this I started the video at different points so that MS Pro would have less time to preprocess the moving path portion. As expected, the closer I started to the moving path section, the less of it would playback smoothly.
So, you can receive the benefits of this preprocessing of hard sections (high cpu load) while easy sections (low cpu load) of your video are playing while still getting almost instant playback once you hit "play" by enabling multi-threading at a setting of "0."
Ulead really got this right. And, as I said above, as our processors become more powerful RT all of the time, with almost instant play after hitting "play" will become a reality sooner rather than later.
-Mark
I have made some observations regarding this feature and was hoping to hear some of your comments.
After doing some informal testing, it seems as though the multi-threading option allows the MS Pro instant preview engine to get a "head start" on preparing the real-time playback. I have noticed that if I turn off multi-threading on a scene that my computer cannot play in RT (say a moving path on a high resolution bitmap image), the playback begins immediately, but is choppy in playback. BTW, I have a P4 2.4B.
If I turn on "multi-threading," then a small portion (first few seconds) of the video to be played back is processed before the playback starts. The higher the slider, the more video is preprocessed and the longer it takes for playback to start. This is kind of like a "processing buffer."
If you have a video with short portions of high cpu loading, perhaps transitions and other things of a second or two, this buffer can allow MS Pro's RT to keep up with the video. In effect averaging the overall cpu loading of a project so that although there may be spots the cpu is unable to handle in RT, there are also parts that it can handle, and have some processor cycles left over to begin work on sections not yet playing. During these "easy" sections, the cpu can "prepare" for the next difficult section. In theory anyway. As long as the complex scenes are short and there are low cpu's scenes that allow MS Pro to pre-render, or "get ahead" of playback in order to preprocess the next difficult section before it arrives.
On the other hand, if the difficult scenes are longer than 2 or 3 seconds, by my observations and on my system, then the preprocessing buffer is used up and you are getting whatever frame rate your system can do in real-time with no "head start."
For most of my needs, I'm finding that I like turning of multi-threading. RT playback start immediately, and most of my complex scenes are longer than 2 or 3 seconds. In addition, even though the RT is not 30fps on all sections of my projects, it is very usable.
Of course it's nice to have the option. I'm not sure why Ulead decided to call this multi-threading. I think "pre-processing" would have been more informative.
Anyway, I thought I'd share my observations of this function. I'm curious to hear what others think about this.
BTW, kudos to Ulead for incorporating this feature into MS Pro. I think it will be more useful as processors become more powerful. When the cpu can almost keep up with RT rendering the preprocessing functions can serve to smooth out the rough spots.
Update! While typing this something came to mind and I tested my theory:
When the multi-threading option is off, obviously no preprocessing occurs before the video starts to play or during playback of light cpu loading portions of the video.
When "multi-threading" is enabled at a slider level of 0 a little preprocessing occurs. The question is if MS Pro preprocesses video, or tries to "get ahead" as much at this setting as at a setting of 10?
I ran some tests to answer this question.
I'll put 12 seconds of straight dv in front of a really tough section. A moving path on a high resolution image.
First I played this section from the beginning with multithreading off. When the easy section ended and the moving path began, the preview began to immediately drop frames. Also note that cpu loading was about 25% during the easy section and shot to 100% during the hard section.
Next I enabled multi-threading at a slider level of 10. This time the preview played back smoothly during the "hard" section for about 5 seconds before becoming jerky, ie preprocessing buffer ran out. cpu loading during this entire test was 100%! Great job Ulead, this is how it should be. During the easy section, MS Pro was using the 75% unused processing cycles to "prepare" the next section.
Finally, I ran this test with the performance slider set at "0." This time the preview was smooth for 4.5 seconds into the hard section! THIS IS VERY IMPORTANT! Even at a slider setting of "0" enabling multi-threading is very useful. While "easy" sections of your video are being previewed MS Pro is "looking ahead" and using spare cpu cycles to preprocess difficult sections to come.
As would be expected, cpu loading throughout this test was 100%.
Note that the .5 seconds difference between setting "10" and "0" is the result of the extra preprocessing done at the higher level.
Just to verify this I started the video at different points so that MS Pro would have less time to preprocess the moving path portion. As expected, the closer I started to the moving path section, the less of it would playback smoothly.
So, you can receive the benefits of this preprocessing of hard sections (high cpu load) while easy sections (low cpu load) of your video are playing while still getting almost instant playback once you hit "play" by enabling multi-threading at a setting of "0."
Ulead really got this right. And, as I said above, as our processors become more powerful RT all of the time, with almost instant play after hitting "play" will become a reality sooner rather than later.
-Mark
Comment