MSP8 freezes for 30 secs

[chtchege]

Mine is a Pentium 4 2.4 2GB RAM and plenty of HD space. What I experience with MSP8 is the following:
When I scroll through the timeline of my project (originally imported from version 7.3 but since then edited only in the new version), or do other things (see below) at a certain moment the program freezes for 20-40 secs: no reaction to the mouse, keyboard or else... Normally such a behaviour is experienced when I scroll the project along the timeline, but yesterday I got this after changing the timeline scale - the mouse cursor was just locked over the scale selection slider for 20-40 secs and wouldn't allow me to leave the area (although it moved over the slider).
Selecting Task Manager shows Ulead MSP8 as running, and after the program unfreezes it runs smoothly.
Has anyone experienced the same?

[Devil]

This is probably a function of the Autosave backup feature. If I remember correctly, the default settings cause a backup dvp file to be saved every 10 minutes. The calculations for this to happen take anything from a fraction of a second to even a full minute, depending on the complexity of your project (the more effects you use, the longer it takes). During this operation, the computer appears to freeze except for a progress bar at the foot of the screen. This is a security function, but you can disable it or change the intervals between back-ups, if you find it too frequent or too long.

[chtchege]

This is probably a function of the Autosave backup feature. If I remember correctly, the default settings cause a backup dvp file to be saved every 10 minutes. The calculations for this to happen take anything from a fraction of a second to even a full minute, depending on the complexity of your project (the more effects you use, the longer it takes). During this operation, the computer appears to freeze except for a progress bar at the foot of the screen. This is a security function, but you can disable it or change the intervals between back-ups, if you find it too frequent or too long.

Thanks a lot for the idea...

[Helge]

Did you edit avi or mpeg files? As I wrote in an other post, I had some problems / crashes with mpeg files. With msp7 I could document (with filemon) an endless loop reading forward / backward the file. MSP8 behaved most often better. It hung for a few seconds and then returned. Seems that they have set now a timeout for some operations.
I think that this could also your problem, because you wrote that you scolled. With my video that happened allways, when I scrubed or scolled backward.

[krwzmann]

I have the same thing happen to me sometimes when scrolling through the timeline. It'll happen maybe once or twice in a 10 hour edit session. I make sure to save often manually on my own and whenever I encounter the freeze, I make sure not to push any keyboard buttons or make any mouse clicks or else MSP8 crashes. If I let it sit, all is normal in 30 secs or so and I let out my sigh of relief hehe.

[Helge]

The same question: AVI or MPEG?
Why do I insist in that?
It seems that very few users realize the big difference, since no message mentions what is used. The difference is, that it is more difficult to read mpeg files backward than avi files.

Hä?
(For non germans: this german aboriginal sound translates to what do you mean please? )

Video files are only designed for reading them forward. That is what video players need. But since video files normaly dont fit into available memory, video editors can hold only the frame they currently show and perhaps some before and some after in memory.
So if you position in the timeline or preview / source window (scrub, sroll or zoom out), the editor needs to read some other frames from the file (files). Reading forward is quite easy - the current frame contains the information to large it is, so if it started a position x in the file and has size N, than the next frame could be found on position (x + N). Reading backward is only easy, if you know the size of the previouse frame. With avi thats the case, since the frames have the same size. But not so with mpeg, where the frames vary in size. You need the information how large the previouse frame is, and that information is contained in the previous frame, which you just want to read.
So what you can do is try and error: assume the frame could begin about somewhere and scan from that position in the file til you find something that looks like the beginning of a frame.
If you dont find something, than try an other start position.
If you find something, it must not necessary be really the beginning of a frame. It could also be some video data of a previous frame. While that is not very likely, it could sometimes happen. So the video editor has to verify the frame carefully. While it is doing this, it works with some information in the (assumed) frame, which could lead to a crash, if the frame was not a frame. Still if the editor decides, that the frame is not ok, it has to try an other start position.
Things get even more complex, since mpeg files contain different types of frames (I, B, P) and for decoding B and P the knowledge of other frames is necessary.

Now you have probably some idea what MSP is doing while you are waiting .
I assume that ULEADs algorithm for positioning backward on mpeg files is not the best (that does not mean that it necessrily contains a bug). And if additionaly the mpeg file is not encoded correctly (there exists some very expensive tools to verify that), than MSP may hang ore even crash.

So it is a good idea to edit your video files as avi where ever posiible.

And if MSP crashes to tell ULEAD what was the format of your files so that they eventually decide to improve there algorithm.

[Devil]

Of course, MPEG editing is a recipe for quality degradation, unless you have an all I-frame GOP. MPEG is a DISTRIBUTION ONLY format. Why? Because you have only occasional frames (I) with full data (usually 1 in 12 or 15) and the intermediate ones save only the changes from the previous or next I frames. Scrubbing backwards is therefore more resource-intensive to reconstitute the frames. When rendering edited non-I frames, the differences have to be recalculated from the original P or B frames, hence the double loss of information, resulting in quality loss.

With DV, HuffYUV or MJPEG codecs, each frame is compressed individually as a whole and there are therefore no calculations over groups of pictures. When re-rendering, the original info is maintained, where possible, and each frame is whole, in any case. Such codecs are almost lossless, resulting in little loss of quality, even over multiple renders (within reason).

The only true lossless system is RGB uncompressed.

So, editing in MPEG is to be avoided where possible.

[krwzmann]

I would edit .avi but I don't think I have a choice if I want to edit HD. The HD video is captured as mpeg 2. Is there a way to capture HD footage as an .avi?

[Devil]

You have to capture HD in MPEG, as I understand it (don't use HD myself), but you could convert it to a semi-lossless format before editing. If you intend finishing with standard DVD, you would have the choice of doing the conversion to the HD or to SD format. HD would possibly give you marginally better quality, at the end, but SD would be quicker, especially encoding the AVI to DVD-compliant MPEG-2.

[MSP maniac!]

Back to the freeze,

I have found mine sometimes hesitates when I'm scrolling through quickly and I found in my case this was related to the drawing of waveforms. So I turn waveform off until I need to show them and then there is no further hesitation when scrolling.

[Terry Stetler]

One thing that'll slow down large programs is themn having to constantly hit the system swapfile.

Sometimes this is due to not having enough physical RAM, forcing programs to use virtual memory (the swapfile). The only real fix for this is adding RAM to the system. More often this affects systems with less than 1G of physical RAM, and these days RAM is cheap so....

There is another cause for swapfile hits: Windows keeps the DLL's (libraries) used by programs in memory (cached) even though the program has been closed.

Since some libraries can be several hundred kilobytes in size this can eat memory like a hawg, forcing many programs to hit the swapfile to load the module for such mundane functions as an autosave. I've had this happen not just in MSPro but in PhotoImpact or Photoshop when I have a large image loaded. The "fix" is to turn off DLL caching in the registry. To do the fix you first Start/run regedit. Next you browse the tree in the left panel until you arrive at the following key location;

HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Explorer

Right-click on Explorer and from the context menu choose "New/String value" and name the new key "AlwaysUnloadDLL". Doubleclick on this new key and set its value to "1" to automatically unload DLL's and "0" to turn unloading off. Restart WinXP and the change will be applied.

[Devil]

Back to the freeze,

I have found mine sometimes hesitates when I'm scrolling through quickly and I found in my case this was related to the drawing of waveforms. So I turn waveform off until I need to show them and then there is no further hesitation when scrolling.

It's obvious that both filmstrip and waveform modes require more horsepower to draft and is consequently a lot slower.

[Helge]

Good practice or not, MSP offers the possibility to edit MPEG video files so it should work without hangs or crashes.
I do it rarely, but there are also situations where it makes sense to use mpeg eding mode and where is not necessarily a loss of quality:
If you only want to combine some clips to a larger video, eventually with some hard cuts but without any effects, overlays and so and if your clips are allready coded as mpeg. In that case no recoding is required and at the cuts a good video editor can simply add some I-frames.
To avoid recoding I usually set the output quality (bitrate) slightly above that of the input files. You can verify if MSP had recoded the video: If MSP first estimates a duration of two hours to create the output video, but is ready after 10 seconds, it had not recoded it.
I wished there would be an option in the create file dialog "do not recode". This would be easier then adjusting the output quality settings.
(Same applies to dws2.)

[Devil]

Good practice or not, MSP offers the possibility to edit MPEG video files so it should work without hangs or crashes.
I do it rarely, but there are also situations where it makes sense to use mpeg eding mode and where is not necessarily a loss of quality:
If you only want to combine some clips to a larger video, eventually with some hard cuts but without any effects, overlays and so and if your clips are allready coded as mpeg. In that case no recoding is required and at the cuts a good video editor can simply add some I-frames.
To avoid recoding I usually set the output quality (bitrate) slightly above that of the input files. You can verify if MSP had recoded the video: If MSP first estimates a duration of two hours to create the output video, but is ready after 10 seconds, it had not recoded it.
I wished there would be an option in the create file dialog "do not recode". This would be easier then adjusting the output quality settings.
(Same applies to dws2.)

Sorry, WS2 DOES give you that option, provided the MPEG file is DVD-compatible.

[Helge]

Thank you very much Devil, for that hint! This is really great!
I am working so long now with DWS2 but I didnt realize it. But now since you said it so definitly, I searched every configuration option and every setting til I finaly detected it. (First I thought you would have a different DWS2 version than I.) The reason why I didnt see it before is, that I allways looked at the wrong place - i.e. everywere else e.g. even in the advanced disk template compression options.