|
|
|
Cross transitions do not work as they should (they are not proper motion transitions and produce still video either side of the mid point). So it's good that the overlap transitions, which work correctly, are the default. However, choice would appear to have been the most comprehensive solution, in the absence of a fix for the cross transition type.
|
|
|
Unfortunately the "cross" type transitions do not work correctly and so it's good that the the "overlap" is the default.
If you use a "cross" transition between two clips where there is movement in the shot - which is going to be true in almost all cases - movement in the incoming clip is frozen until the mid point of the transition. Likewise, movement in the outgoing clip freezes after the mid point of the transition. So if it's video from an air show, and the clips show moving aircraft, the plane in the outgoing clip will magically start to hover, not fly, from the mid point of the transition.
So - stick to overlap transitions unless you check very carefully that a "cross" transition does not reveal this shortcoming in the program.
|
|
|
|
Right click on the Bmem display for settings, Robert, which here at least on a 4 core system enables me to display the separate cores.
|
|
|
PowerDirector does seem to be remarkably frugal in its memory use, though I guess there are limits.
For monitoring memory, CPU and disk, Bmem is your friend - http://badmofo.org/bmem/ - all my PCs have that installed before anything!
Also the DPC latency checker from http://www.thesycon.de/deu/latency_check.shtml is another essential system checking tool.
|
|
|
|
Another workaround for anyone having Panasonic GH1 720p problems in PD8 - Nero 9 allows you to put all your clips on its timeline, then export to a single file with no rendering. Put that onto the PD8 timeline, right click and tell PD8 to use the video format "interlaced top field first", and if you then split it into separate clips again during editing or by using scene detection, each split item will retain that video format attribute. Then PD8 will handle it with no video freezes. Well, here at least...
|
|
|
I finally found a way consistently to fix the problem of 720p clips freezing on the timeline - right click on each and set the TV format to interlaced (upper field first). Then even a timeline with about 90 clips on plays through with no problem.
Why it should be necessary to tell PD8 that the clips are interlaced when in fact they are progressive I have no idea, but it certainly works.
The trouble is that if you highlight all the clips on the timeline in one go, the right click menu option to change their format globally is greyed out. So it's not a trivial task to set the individually, and because the information is stored in the registry it's not readily possible to do some kind of back door global operation either. The best I've been able to do is to write a little utility which automates the process on the timeline, though it's still necessary to click each clip which is to be changed.
Given that if you want to change the interlace spec of one clip, there's a good chance that you'd want to change the spec for a lot, then it would be handy if PD8 could provide the means to do so readily.
|
|
|
|
I tried that already, thanks.
|
|
|
An update - I've now found out how to hack project files to allow me to substitute one set of clips for another set having the same content but in a different video format.
If I substitute in my full project (almost 100 AVCHD 1280 x 720 Panasonic GH1 clips) clips in the same format (except 25fps instead of 50) transcoded using MediaShow Espresso, it plays through for 15 minutes from the timeline with no problems at all. Interestingly these transcoded clips have a similar Mbps figure to the original even though the frame rate is halved - their size compared to the originals is smaller but nothing like half.
So the problem seems to me proven to lie with something about the original clips themselves - either the way the frame types follow each other or the frame rate, but it's clearly not project related nor 1280 x 720 progressive AVCHD (as such) related.
|
|
|
|
You can pick whatever format plays well on your PC and which provides sufficient quality. The official shadow file format is probably a good choice, but here at least it takes longer than expected to create the shadow files, and then there's some program instability when working with the project. YMMV!
|
|
|
I've now globally replaced "mpg" with "m2ts" in the project file to access a replacement set of 1920x1080 files also created in MediaShow Espresso, and this seems to give the best playback experience (compared to the original 1280x720 files and the 1920x1080 mpeg2 files originally created in MSE). It's almost as if the program is optimised for that fomat. No problems at all between clips (and it would smart render where there are no fx).
All very interesting.
|
|
|
In my ongoing investigations into a few PD8 oddities, I used MediaShow Espresso to create a set of mpeg files from the AVCHD files in my current project, then used a text editor to do a search-and-replace in the project file to tell PD8 to use the mpeg files and not the AVCHD files. Obviously one could then reverse that and use the avchd files for the actual render. Is this a known technique? It's pretty simple. My DIY shadow files were created without the crashes I get when using the PD8 "official" shadow files and it seemed much quicker, and program stability was fine when working with the project subsequently.
However, I notice one curious thing, that certain joins (without transitions) between two clips cause timeline playback problems. The problem can be seen as a brief freeze of the last frame of the outgoing clip, and then playback of subsequent clips becomes jerky due to frames being skipped (probably alternate frames only being shown). Attempting to replay across the problem join gives the same result, but changing the length of the outgoing clip a little resolves it and playback is then fine. This is a bit like the problem discussed in another thread regarding 1280x720 AVCHD clips but it doesn't cause the complete video freeze, 'just' frame skipping.
Anyone else seen that?
|
|
|
|
I mean the second clip goes on the same track as the first clip and to the right of it. If you then move it left (as if to overlap it with the first clip, which indeed you can't actually do) that's when the odd behaviour I described arises. I'm not particularly wanting to overlap it - as you say, you'd need to have the two clips on two different tracks and create fade ins/outs yourself if you wanted a crossfade - it's more a matter of having encountered audio corruption in a real project, this is how it must have accidentally happened, and is it supposed to behave that way for some useful purpose?
|
|
|
Is this supposed to happen?
1. Insert audio clip on the music track
2. Insert another audio clip on the music track next to it
3. Drag second clip over first clip somewhat
4. Displayed length of second clip shortens by the amount of overlap
5. Second clip plays back at higher speed but original pitch
6. Second clip can only be fixed using "power tools" manually setting "modified audio length" back to original.
This explains some audio corruption I got on my recent project where that overlapping must have happened inadvertently. If you speed up the audio more than just a little using that method it quickly sounds pretty horrible.
|
|
|
I think I said all this in another recent discussion of the subject, but here it is again -
If you edit so that material you do not want is cut out at either end of the clip, then you add a transition, then there's two possible ways it can be done.
Either the incoming clip must be faded in starting with some frames you cut out, or it must be faded in starting with the first frame you wanted. Likewise for the outgoing clip. And both are happening at the same time in an overlapped area. If you have the first scenario, the overall length of the production will not change but you will see at each transition some frames you did not want to see. If you have the second scenario, you will only see frames you wanted but the production must necessarily shorten.
Furthermore, if you have not edited the clips at all, and the program uses frames before and after the join for the purpose of crossfading the transition (first scenario), then where are those frames going to come from? In one program that works that way, the first frame of the incoming clip and the last frame of the outgoing clip are simply repeated for the length of the transition, which is less than satisfactory.
I guess in an ideal world the program would provide both scenarios. Drag a transition as at present, and the frames starting/ending the clips determine the start and end of the crossfaded section (current behaviour). Ctrl/drag the transition and frames before and after the clips as edited would be used for the crossfade (opposite of current behaviour). Where the frames are not trimmed, do not allow the ctrl/drag behaviour.
There you go, a little feature request.
[Edit - noting only now that the original question related chiefly to stills, in that scenario I would have thought that the program should indeed automatically extend the length of the stills in order to create the crossfade, thus leaving the length of that part of the project unchanged. But having the choice I suggest above would avoid the need for such selective behaviour.]
|
|
|
|
I don't think this is the same issue at all, Tony. The problem this time relates to the result of the Produce function rather than timeline playback, it would appear. Most likely culprit is that the smart rendering is happening, but that the non-smart-rendered transitions are not being well integrated with the smart rendered bits, which is I think a known problem.
|
|
|
Right now I attribute the freezes (here at least) as being related to this particular flavour of AVCHD which is pretty new, as I understand it, and there may not have been a chance for Cyberlink to test PD8 with it before the release date. I've also seen very heated debate elsewhere as to the inner structure of this AVCHD variant and the problems it can cause in replay and editing (on top of the usual AVCHD challenges!).
In my experience with releases by software companies, release dates are often set way in advance and if something new comes along between the setting of the date and the date itself, tough.
So I'm sitting on the fence for the moment.
Ouch....
|
|
|
Open PD8 with no project loaded
Insert latest five sample clips
Play
Video freezes and audio continues between 4th & 5th clip
Save currently unsaved project
Play
Same freeze
Click on first clip
Click on "Movie" button
Play
Freeze between 3rd & 4th clip
Click on last clip
Click on "Movie"
Home
Play from start
Freeze between 3rd & 4th clip
Play from start (to which it has returned on its own)
Freeze between 1st & 2nd clip
Note that I've not inserted any transitions anywhere anyhow.
Now I insert fade between all clips using the button
Plays to end with no problem
Play again from start
Freeze between 2nd and 3rd clip
Play from middle of second clip
Freeze between 2nd and 3rd clip
Play at high speed using fast forward button
No problem
Play using normal play button
No problem
Play using normal play button
No problem
Play using normal play button
No problem
Play from middle of middle clip
No problem
Play using normal play button
No problem
Save
Play using normal play button
No problem
Add another instance of 1st clip after 5th clip
Play
Freeze between 5th and new 6th clip
Go end to end with fast forward again
Play
Freeze between 5th and new 6th clip
(so fast forwarding doesn't in itself fix the problem)
Add fade to all clips again (thus adding one to the 5th/6th)
Plays all
Plays again end to end
Shorten the end of the 1st clip by about one second by dragging right edge
Plays all
Play from start
Freeze between 5th & 6th clip
Play from start
Freeze between 3rd and 4th clip
I could go on... I see no clear pattern.
|
|
|
Some further samples for those who are (a) interested and (b) have reasonable download allowances and speeds!
http://www.fileden.com/files/2007/9/22/1451533/GH1_01.zip
http://www.fileden.com/files/2007/9/22/1451533/GH1_02.zip
http://www.fileden.com/files/2007/9/22/1451533/GH1_03.zip
There's five x 10 second samples of street views there to play with. The content is a little more interesting than the original sample, but only marginally! Sorry....
|
|
|
|
And explore the buttons below the playback screen, one of which offers playback quality presets if I recall rightly (can't look right now, I'm rendering).
|
|
|
The original symptom of the original problem was (still is) that when playback from the timeline crosses from one clip to another (using the downloadable sample clip which has the 1280 x 720 AVCHD 50fps format which, here, gives the trouble) the video playback freezes completely (showing the last frame of the outgoing clip) but the audio carries on. It happens intermittently but enough to drive me nuts when trying to edit lots of short clips in time to a music bed.
Presence or absence of a transition between the shots doesn't actually come into it as far as I am concerned (that was a red herring in the original thread).
I've also been having problems with rendering but that seems to be another issue, and one which perhaps I shouldn't have mentioned in this thread. However, I am delighted to report that after a reboot (required because a render attempt completely froze the PC) the project finally rendered end to end.
However, thinking that the reboot might help the timeline playback problem too, I at once replayed the project timeline, and almost immediately I got a video freeze as before.
As for further sample clips, I managed to get out of the house for a little while today and grabbed some nondescript shots in town which I will upload in about 12 hours time and I'll post the link here in due course.
|
|
|
Playback or rendering?
These things can just be completely random (yeah, I know computers don't do random things but...)
Currently I'm on about my 20th attempt to get my current project to render. It's just a matter of gradually deleting stuff it doesn't like, but boy, it's time consuming.
|
