|
|
I'm trying to produce an .m2ts file (H.264 AVC 1920x1080/60p) because I like the high quality, and I've never had any problems with this particular format before (I've produced many videos of my kids playing in recitals this way).
It is an 8-minute video - a slideshow of a family vacation, containing text, video clips (both from my iPhone and from Disneyworld - they now produce video clips of your experiences on certain rides), pictures with various keyframe manipulations and masks, and an mp3 audio track (the mp3 crossfades into another mp3 toward the end).
I got the same error message with the previous official version of PowerDirector, which prompted me to upgrade to the beta.
I'm running Windows 10 with 16GB RAM, i5-6500 processor. I don't know if this issue is related to another issue I just had outlined here:
http://forum.cyberlink.com/forum/posts/list/62842.page
My NVIDIA driver is up to date and Windows Media Player / Quicktime are up to date.
|
|
|
In PowerDirector 15 (Windows 10, 4 i5-6500 cores, 16GB RAM), I took about a month break from editing a project. The project is nothing fancy - just pictures, music and text fading in and out. Despite its simplicity, when I push spacebar to preview anywhere in the project, it renders so slowly that I literally see nothing and only hear the audio. This issue wasn't present a month ago.
In fact, even when I merely single-click on the timeline just to view a single frozen frame of the project, it often takes 15-20 seconds to "render" in the preview window even though it's just a stupid little JPEG.
(Side note: after the previewing is done, a little green bar appears literally on the timeline grid, permanently marking that spot in the timeline, perhaps to show me that "this is a slow spot to view" for future reference, similar to the yellow and red routes on GPS... but that's just my guess.)
In my NVIDIA control panel, I tried setting "CUDA - GPU" to "none" for CyberLink PowerDirector. I even restarted PowerDirector... didn't help.
The only "change" I made to my system since then was the installation of Presonus Studio 1 v.3. (Not really a system change, just a new application.)
Help please!
|
|
|
Hi Tony,
Sorry, my mistake. I've participated in a few other forums where the developers are pretty active, and I guess I just assumed... Also, I did write to CyberLink tech support, and they are very clearly avoiding admitting it's a bug. Their response to me was very similar to yours... and now that I stand corrected I fully acknowledge that it's totally different coming from a fellow user than it is coming from a developer.
They even told me that the "solution" to the erratic time shifting problem of the "overlap" transition would be to first arrange my entire track 1 (all the way through my entire slideshow) and get all the transitions perfect, then add other stuff. I guess they don't realize that sometimes the "other stuff" (music, video, other objects...) determines the timing of the slideshow.
I do like analogies... and their response to me didn't feel much different than if I were told by the makers of Finale or Sibelius that I needed to write the flute part of an entire symphony first, then go back and "fill everything else in." This seems no less insane of a response to me than the one I actually got from CyberLink. It seems to me that CyberLink's slogan ought to be, "If at first you don't succeed, redefine success." Some software behaviors are so atrocious that, intentional or not, they really ought to be classified as bugs.
Just curious, are there any other <cough> "behaviors" (i.e. bugs) that you've discovered in PowerDirector in your experience? Have you used other video editing software available for PC, and if so, are any others any better?
Thanks,
CS
|
|
|
Quote
In fact, that's exactly what's causing the interference with motion. Overlap transitions behave much more smoothly & won't interrupt movement.
...
It's not a bug. It's how the transitions behave.
Another thing to note is that switchng to overlap-type transitions will decrease the overall duration of your slideshow by the sum total of the duration of the combined transitions. e.g. a slideshow with 11 images x 10 secs duration with 10 transitions of 2 secs...
I appreciate how thorough and friendly your reply was. I do understand everything you explained, and watched the YouTube video. I did already know everything you wrote to me and knew what the video demonstrated, so I guess I must have miscommunicated. It's like writing to a senator asking them to change or update a really terrible law, and instead of getting a response such as "Thank you for pointing this out - I will change it," or, "Actually this law makes sense and here is why...", I just get a circular "The law is the law" response back. This response isn't helpful.
I don't want to sound rude, or arrogant... but I just can't agree that this behavior should be normal. I am certainly open to listening to why (from a programmer's point of view):
1) the user can't be prompted with a choice to shift only the current track, or all tracks, when a "cross" transition is added. It seems to me that such an option could easily be added to the software, considering the user is already given this option with just about any other edit that results in timing changes (i.e. lengthening or shortening a track asset, moving it to another track, etc.). I'd be perfectly happy to finally zip my mouth about this issue if someone could just explain to me why this behavior is actually desired by your users, necessary from a programming point of view, or both. But so far, all I'm getting is, "It's not a bug because we know about it and our opinion is that it isn't a bug. It's not a bug because that's the way we designed it to work." This is completely circular logic. I'm explaining to CyberLink why it would be best a different way, and I never get any kind of response other than "this is how it works," which of course I already know. The whole point is that the way it works really stinks and should be changed. Analogy: if turning off the car results in the car horn going off every time for 2 seconds, and I tell the manufacturer about this problem, how do you think it will make me feel (and how do you think it makes the manufacturer look) if they just write back, "No, that's not a defect. That's how we designed it." Maybe there is a really good reason for that car horn to go off, but it certainly doesn't help anything when the manufacturer refuses to share that reason with customers who are concerned about it.
2) an "overlap" transition cannot be achieved without the jerky stop-motion at the beginning/end of the clip. I'm skeptical about any such argument though, since other software that does crossfades (whether audio editing software or visual editing software) does them perfectly smoothly.
In other software, users are not faced with the impossible choice of doing jerky overlap transitions or cross transitions that destroy the synchronization of all the tracks. Neither choice is appealing. Until someone offers me compelling reasons for why cross transitions need to affect other tracks erratically, and why overlap transitions need to be so jerky, telling me "no, it's not a bug" without offering necessary rationale for its behavior will not advance the discussion at all. I hope that my text above clarifies and advances the discussion.
Side point: the terminology itself is baffling. In audio engineering (which I have considerable formal training in), "cross-fading" refers to when audio clips overlap each other and fade into each other (and in that process, the clips are shortened). But in PowerDirector, this term "cross" is being used as the alternative to this overlapping behavior, with "overlap" being the substitute for "cross" or "cross-fading." To fade two clips into each other simultaneously (fade one out while the other fades in), by definition, is referred to as cross-fading. This is true in other video editing software too, such as Adobe Premiere. I would suggest renaming "cross" to just about anything else such as "join," "touch," "neighbor," "adjoin," etc. The "cross" term is extremely misleading, not only to the trained user but also to the layman who understands the practical meaning of the word "cross." IN FACT, I think I may have actually gotten some of my terminology in this post confused - maybe I use "overlap" when I should instead use "cross," and vice-versa.
|
|
|
I have JPEG files in track 1 for a simple slideshow movie. I already have set various keyframes for position, rotation, scale, etc. so that the pictures "come to life" (rotate, zoom, move) in the video.
Unfortunately, when I apply transitions between photos (doesn't matter which one, although the Fade transition makes this problem easiest to observe), before the transition is complete, the other keyframes come to a halt. Position, scale, rotation, etc. all seem to stop. This is the case for lead-in transitions as well as lead-out transitions. (For lead-in transitions, I can see the picture failing to animate for a short time at the very beginning of the transition, then the animation begins a split second later.)
I have "produced" the project to high-quality 60fps video to see if this was only a preview problem, but it is not. The problem persists in the rendered video.
My transitions are set to "cross," not "overlap," although I don't think that should matter.
I do not experience this problem if I manually adjust opacity keyframes to achieve fading. But that workaround is only good for the Fade transition.
Before I report this as a bug to CyberLink, I was hoping to either 1) get confirmation from other users that this is indeed a bug, or 2) ideas of what I might be doing wrong (i.e. any settings that could affect this).
Thanks,
CS
|
|
|
Quote
The posted video is clear enough to show what is happening. It is normal behavior because your default transition behavior is set to overlap instead of cross. On your 3rd transition everything to the right only on track 2 and 3 moves because there are gaps in the 3rd and 4th tracks before the next asset.
Goto Preferences/Editing and change the default transition behavior to cross instead of overlap. That should take care of the problem.
THANK YOU! Changing the preferences solved my problem.
I'm feeling a lot of sympathy right now for various other newbie users in the future who are doomed to be affected by this problem. A couple more questions, if you have time (or for anyone who wants to chime in):
- Is there a good reason why "overlap" behavior should be the default transition behavior setting, given the problems that I had (and likely most new users will have) with erratic timeline behavior?
- You called the erratic timeline behavior "normal," but when one deletes an asset, extends or reduces the length of an asset, or moves an asset to a different track (i.e. when timing of an asset is directly changed), the software prompts the user for how the current (and other) tracks should behave in response to the change in timing. I fail to see why any edit that affects asset timing (whether it's an "overlap" transition effect or a straight timing edit of an asset) should be treated any differently. Even though Cyberlink apparently (?) coded this behavior into the software on purpose, it seems like it ought to be treated as if it were a bug. Would it ever be advantageous to not have the same timing shifts happen in other tracks? It seems to me that in the worst case scenario, the user hasn't lined anything up in the other tracks yet, so timing shifts or no timing shifts, it wouldn't matter. But many times it will matter, and in those cases the user needs the option to shift everything over by the same amount.
Thanks again!
Chad
|
|
|
I have a simple slideshow of JPG files on track 1, with text and other things in tracks 2 and 3. The content in tracks 2 and 3 is lined up carefully to sync with the slideshow in track 1.
When I add transition effects between the pictures of track 1, the behavior of tracks 2 and 3 is unpredictable. Sometimes tracks 2 and 3 shift by the same amount as track 1, and sometimes tracks 2 and 3 do not shift at all.
In case this explanation isn't clear enough, here is a video of it:
http://twedt.com/Capture.mp4
I already wrote to CyberLink support, and 1) they did not admit that this was a bug (let alone say that they're going to fix it any time in the future), and 2) their "solution" was for me to first add all of my pictures and required transitions into track 1 first, then add other stuff to tracks 2 and 3. (In other words, no solution.)
I hope I'm not the only one who thinks that this is insane advice - it would be like the makers of Finale or Sibelius telling a composer that they must write only the violin part for a symphony first, then go back and add all the other instruments. How can any developer design this software to run this way? It blows my mind.
I am writing to see if the PowerDirector user community can come up with any other ideas. The solution the CyberLink person gave me is not a solution, because it means I must discard a great deal of work I've already done.
Chad
P.S. I noticed this same behavior in PowerDirector 13, and was so incredibly disappointed to see that such a debilitating bug (a bug that I would only expect in Beta level software) not only existed in the thirteenth version of a commercial software title, but even still remained in version 15. Is version 17 any better?
|
|
|
