Nina- you're doing it wrong .. /jk

Okay a bit hard to make heads or tails of what you are saying but I take it after you Produce everything looks great without any issues. (Other than the other old PD issues- which are another story altogether.)

Have you tried the Render Preview function to see if those crazy lines show up?

For those not familiar with it- Use the little side tabs on the timeline scrubber to highlight your section and click Render Preview:
See link for more info: https://forum.cyberlink.com/forum/posts/list/30458.page



Rob
PD 14 Ultimate Suite / Win10 Pro x64
1. Gigabyte Brix PRO / i7-4770R Intel Iris Pro 5200 / 16 GB / 1 TB SSD
2. Lenovo X230T / 8GB / Intel HD4000 + ViDock 4 Plus & ASUS Nvidia 660 Ti / Link: https://www.youtube.com/watch?v=ZIZw3GPwKMo&feature=youtu.be

Yes I have Rob, should have mentioned that.
Then the dots are gone, but not the glitch - even though reduced somewhat.

I think you see my point; what I see is not what I get.

Nina
Just something.
https://www.petitpoisvideo.com

Quote: Another observation, this has been there since first install; Un-checking hardware in preferences
“Produce” totally ignore, which means I have to double check in “Produce” for every move I make.

To my knowledge, based on testing and processes monitoring, this is what I believe is occurring. Yes, I know it differs from some tutorial demonstrations and threads of such capability, to each their own. It's easy to screen capture a few mouse clicks, much more difficult to understand what might be under the hood to the mouse clicks when the docs are so lacking of technical info. Below is what I have surmised.

For PD, Preferences > Hardware Acceleration

The top item determines if you want to use hardware to speed up video effect preview/render. The "video effect" PD refers to are the PD effects that have the AMD, Intel, or Nvidia icon in the lower left corner of the effect depending on your platform capability. If your computer supports OpenCL, then the message will echo that, if not, the wording on the UI will be replaced with the supported hardware acceleration technology: INTEL Effect Acceleration, NVIDIA CUDA, or AMD Accelerated Parallel Process. For reference look at the lower left corner of the PD effect "Abstractionism", that can be a PD hardware accelerated effect with this setting vs "Broken Glass" which can not. This setting offloads the CPU of these effect tasks and lets the GPU handle the load for both preview and render. If selected here, this only applies to video effects in the timeline that support the technology as the PD item states.

The bottom item has nothing to do with encoding, it states decoding. If selected here, hardware accelerated video decoding will be used where portions of the video decoding process are offloaded to the GPU hardware, it is commonly referred to as "GPU accelerated video decoding". PD warns to have a good GPU if you select this feature because it's doing the heavy lifting. Decoding is decompressing the video stream for display or playback, formats like h.264 are highly compressed and can require some compute resources to decode smoothly during playback. This decoding task could be done by either the CPU or the GPU, checking here selects the GPU to do the work.

If you want to encode your video by using hardware acceleration, this option is only selected in the "Produce" tab and/or in the "Create Disc" tab as it should be. PD currently has no preference to always force CPU encoding, HA (GPU) encoding, or SVRT, the user accepts what PD has auto selected or defines what they want for encoding. If the user selects SVRT, regions of the model that require encoding will always use CPU encoding. In the case when one has used a video accelerated effect (like Abstractionism) in the timeline and has used basic CPU encoding, the GPU will be used to help encode the video accelerated effect if the top item in Preferences > Hardware Acceleration was selected.

Maybe the above discussion will shed some light on your observations, I don't see it as an anomaly but the way it is currently defined.

Jeff

Thanks, Jeff.

I’ve read your post several times to get a grip (not Norwegian, this!)
and if I have understood the bottom line here correctly:
What you select / un-select in Preferences regarding HA really has no impact

(but you have to have allowed it in Preferences if you at all want it available….?
PD sets HA in Produce here even if it is un-ticked.)

What you select for production is under Produce (in my case),
and PD will choose for you based on what is (best), or what it thinks is (best), on the timeline.
If I don’t want SVRT/fast rendering/HA, I deal with this in Produce and Produce only in my case.

There have been many discussions about HA during the years, so this thread hopefully will
cover some of my other "observations" as well.
Just something.
https://www.petitpoisvideo.com

Quote: I’ve read your post several times to get a grip (not Norwegian, this!)
and if I have understood the bottom line here correctly:
What you select / un-select in Preferences regarding HA really has no impact

Sorry, I only inherited a small Norwegian portion. Hopefully these two scenario descriptions below for a system with a CPU and single GPU enabled will clarify. What you select in Preference > HA can have an effect on your "Produce" results, it also depends what you have done in the timeline.

Scenario 1: Nothing selected in Preferences > Hardware Acceleration
A) In "Produce" if HA is available and selected, entire video is encoded with HA, your GPU is used to encode.
B) In "Produce" if CPU is used(default when a "Fast video rendering technology:" is not selected), the entire video is encoded with your CPU, your GPU is not used to encode.

Scenario 2: Top item selected in Preferences > Hardware Acceleration
A) In "Produce" if HA is available and selected, entire video is encoded with HA, your GPU is used to encode.
B) In "Produce" if CPU is used(default when a "Fast video rendering technology:" is not selected), the video is CPU encoded except for any portion of timeline that used a PD HA enabled video effect "like Abstractionism, Beating, Black and White...", the encoding of this effect in the timeline is encoded with GPU assistance for your produced file. That is a feature that is triggered by selecting the top item in Preferences > Hardware Acceleration by enabling OpenCL technology for preview/render.

The CPU performance is integral for all producing aspects above, on the other hand, the GPU performance for some producing options above is not influential.

Over the years, multiple issues have occurred with HA encoding in PD, be it Nvidia, AMD, or Intel, older technologies (CUDA, Avivo...) or the newer PD10+, OpenCL implementation. For these reasons, I simply use CPU only encoding in PD for any final project which has been much more robust for many, quality wise, crash/error wise, and burn wise.

Jeff

Thanks again, Jeff. (I think I will bookmark).

In addition to your explanation here, I have read an article on Nvidia on GPU computing.
Nvidia has made a catalog of GPU-accelerated applications for all kinds of stuff,
also editing and effects. (CyberLink is not in this catalog).
Some of the really heavy editing applications are listed, and under the column “Multi-GPUsupport”,
they get checked as “single only”. ( Also NewBlue and Pixelan- along with heavier effects companies.)
The catalog is copyrighted in Oct.2012, so maybe it’s not quite up to date?
PD12 is advertised as an application using Multi-GPGPU (General-Purpose computation on GPU),
so I guess we just have to assume that’s something different ?

Just something.
https://www.petitpoisvideo.com

Quote: PD12 is advertised as an application using Multi-GPGPU (General-Purpose computation on GPU),
so I guess we just have to assume that’s something different ?

Yes, GPU's can be very powerful and computational benefits of them are used in many applications as your research revealed for you. Initially extended to handle complex engineering physics(collisions, gravity, ...) calculations for games, they now find computational applications in many fields.

For me it's hard to decipher what CL has really done as they incorporate some of these technologies and wrap them in sales jargon to sell. For instance, it appears CL have transitioned from card proprietary technology like Nvidia CUDA to more generic OpenCL cross platform coding support for CPUs and GPUs which I believe started at PD10. The attached pic shows this the subtle UI change for the migration.

This OpenCL technology was marketed under the "TrueVelocity" CL jargon and echoed in Preferences > HA top item and also seen in the "Produce" section in the "Fast video technology:" TrueVelocity icon on the right hand side. TrueVelocity appears to be CL's technology umbrella which allows the program to make use of OpenCL and multi-GPGPU support as you ask about (an integrated graphics chipset and an additional GPU card, for instance). They extended the capability to TrueVelocity 3 at PD11 and yet again to TrueVelocity 4 at PD12. What's really incorporated in the next generation of release is for anyone to try to interpret, generically appears to be advertised as speed improvements in sales literature.

As I indicated previously, my discussion is based on following the PD product releases and my own testing experience. I have no insider knowledge of CL products, I just try to use them as others do. Other users that have done the same may have other contributions, clarifications or a different viewpoint that can be beneficial.

Jeff

Quote: Over the years, multiple issues have occurred with HA encoding in PD, be it Nvidia, AMD, or Intel, older technologies (CUDA, Avivo...) or the newer PD10+, OpenCL implementation. For these reasons, I simply use CPU only encoding in PD for any final project which has been much more robust for many, quality wise, crash/error wise, and burn wise.
Jeff

It took me a month or two of using PD to come to this exact same conclusion. GPU acceleration has its place- but with so many systems and configurations (along with the changing / tweaking of the coding that is done by the programs of the software themselves,) the old "results may vary" line seems to be appropriate.

Hence why I am now going to build a dedicated NLE rig with massive CPU cores. (Possibly a mini Workstation- but I need to do a bit of research on that since I have never tackled a Workstation before.) The new Haswell refresh (Broadwell) is out by Intel 1st/2nd quarter of next year- will wait and see what that brings to the table. I am interested in the R series of i7 processors since they have the extra on board memory- but that requires, as of now, a whole new motherboard setup. Oh yeah and any rig should have Thunderbolt 2 to futrure proof 4K output.

... oops getting off topic here.

Suffice to say- this is another CL "quirk" that we can only keep hammering away at them to look at and hopefully update / fix.

Rob
PD 14 Ultimate Suite / Win10 Pro x64
1. Gigabyte Brix PRO / i7-4770R Intel Iris Pro 5200 / 16 GB / 1 TB SSD
2. Lenovo X230T / 8GB / Intel HD4000 + ViDock 4 Plus & ASUS Nvidia 660 Ti / Link: https://www.youtube.com/watch?v=ZIZw3GPwKMo&feature=youtu.be

Yes, Rob,

you are swinging out of topic(s) here
I am happy for you and wish you the best with new rig, but while you're planning and waiting for that
to happen, could you offer some explanations of why this happens on my rig?
It's very "interesting" to edit with these circumstances, and I wonder if I'm the only one this happens to.




Just something.
https://www.petitpoisvideo.com

Ha- sorry not meant to taken as a solution- just that Jeff and I have had previous discussions about this.

Anyway...

There are "two" Preview windows here:
One when you edit and modify your picture / clips in the Edit screen and another when you go the Produce screen

Do you have the "enable Preview during production" box checked in the Produce screen before clicking start?
(I personally have that turned off and I never use it. It takes up system resources and the final Produce file is what I am interested in- not a preview of it.)

At this point that I treat both Previews - Editing & Produce as just that- a Preview.
Not the final output. So I have long stopped expecting it to show me the real final Produced file version.

So in other words- if the final output file is error free then I would not worry about it.

Rob

PD 14 Ultimate Suite / Win10 Pro x64
1. Gigabyte Brix PRO / i7-4770R Intel Iris Pro 5200 / 16 GB / 1 TB SSD
2. Lenovo X230T / 8GB / Intel HD4000 + ViDock 4 Plus & ASUS Nvidia 660 Ti / Link: https://www.youtube.com/watch?v=ZIZw3GPwKMo&feature=youtu.be

Well…..I guess I am more particular in regards of preview?

In any case, taking chances of how the production will turn out is not a preferred choice (for me), by far,
and it should not have to be like that.
(“Will this be as intended?”)

Not sure if it’s interesting to others how I edit, but years with PD have given me a
workflow where I pre-produce bits……you never know what could/will happen,
so that’s what is on the agenda right now; I have to produce 1-2 min of what I edit to
be sure it will turn out right.
Oh, no….no preview during production, not that I see what that could have mattered.

Just something.
https://www.petitpoisvideo.com

Nina,

I agree with you totally as far as being consistent in operation. You have identified previously the MONO audio issue with PD12. I have entered a NEW thread on it since as far as I'm concerned a mono video should by default always edit in BOTH tracks as nearly ALL other video editing apps do.
Your issue in this thread points out the fact that some of the app designers involved with PD12 were probably not PD11 users. In addition they also missed the flaw while checking their app prior to release. PD12 (I've used it now for only 2 days) seems to have a lot of small annoyances that point to lack of adequate testing prior to release. Win 10, i7

Hi Nina -

There's some excellent & useful information emerging in your thread, but you're still left with the preview glitch/artifact.

Does that yellow line occur randomly? or only when you do specific things?

Could you please post the photo frame image as an attachment? I've been trying to replicate your issue with similar images & processes, but have failed so far.

I do agree that the Preview screen (whilst not "perfect") should be an accurate indicator of the finished product.

Cheers - Tony
Visit PDtoots. PowerDirector Tutorials, tips, free resources & more. Subscribe!
Full linked Tutorial Catalog PDtoots happily supports fellow PowerDirector users!

Hi Tony,

yes, I hereby giveaway some of the frames in question. :

I tried different px width stroke, different drop down shadow /without drop down…
you name it, I tried. I thought the drop down shadow was the problem, but same jags without.
The yellow line is there as soon as there is an overlay (pip). It’s only nearly full size (16:9) it will
place itself without the line. It has occurred to a couple of produced files, but reading Jeff’s
input here I now make absolutely sure nothing is ticked in Produce and Open CL in Preferences
is unticked as well. (as a sort of precaution)

And, while I’m at it;
there’s also a funny thing going on with chroma key- at least in my understanding.
You have a clip (layer) you want to chroma key out. Under is another layer (clip/image).
What you want to chroma key has a rather light, intense lime green.
On the other layer there are a few small spots green, but in a dark grass-green – totally different.
Going in to Modify, everything green gets keyed.
PD is thinking; Green is green, and here we go.

Just something.
https://www.petitpoisvideo.com

Quote: ... The bottom item has nothing to do with encoding, it states decoding. If selected here, hardware accelerated video decoding will be used where portions of the video decoding process are offloaded to the GPU hardware, it is commonly referred to as "GPU accelerated video decoding" ...

Although I agree with you, the documentation tends to blur things a bit: both the built-in PD help and the User guide state:

Enable hardware decoding: if your computer supports NVIDIA CUDA/AMD Accelerated Parallel Processing/Intel Core Processor Family technology, select this option to use hardware acceleration to decode the video during the editing process and when producing video.

So, does this mean there is some decoding while producing? I would have thought any decoding would be done at the editing point. I7-4770, 3.40Ghz, 16GB RAM, Asus Z87-Plus Z87chipset, Sapphire ATI Radeon HD7850 PCI Express-16 3.0 2GB, Samsung EVO 840 SSD 1TB

Quote: Although I agree with you, the documentation tends to blur things a bit: both the built-in PD help and the User guide state:

Enable hardware decoding: if your computer supports NVIDIA CUDA/AMD Accelerated Parallel Processing/Intel Core Processor Family technology, select this option to use hardware acceleration to decode the video during the editing process and when producing video.

So, does this mean there is some decoding while producing? I would have thought any decoding would be done at the editing point.

I don't see any conflict with what I stated to the documentation, nor the item in red. In order to encode something to a format you need to decode it from the existing format. So yes, all video has to be decoded while producing, except for SVRT usage. For SVRT you do a straight passage of the stream since format in equals format out. Nothing needs to be done, hence it's appealing speed and potential quality benefits when done right. The CPU has traditionally done the decoding but the GPU could do the task as well, a check enables the GPU hardware for the decoding.

Jeff

I don't know if anyone is still running into this same issue, but this is still a problem for at least some of us. I think I have narrowed down when this happens to the following criteria.

Required clip conditions: It seems like all three of the following conditions must be met, at least for my part, for this yellow/orange line issue to happen.

You have a clip you're using as a PiP.

The PiP is sized to (roughly) 60% or smaller of the total production window.

The PiP is a chroma key applied to it.

If I have a PiP that is smaller than 60% of the full window size but has no chroma key applied, I don't see the orange or yellow line. If I have a PiP that does have a chroma key applied and it's at least 65%+ of the total production window, I don't see the line, either. Maybe this can help narrow things down so a patch can be released to fix this.

PiP Editor window exception: If I'm in the PiP editor, the clip does not have the line initially. However, if I resize the clip in the PiP editor, the line then appears. And the line is brought into the final production, so the .mp4 file I'm creating has the same line I saw in the main (general) editor.

Hardware/software changes: I just recently made a new computer (i.e., bought parts and assembled them myself) and installed an OEM version of Windows 7 Home Premium with SP1. After installing PowerDirector 12 Ultra on the new machine, installing drivers for my new GPU (EVGA GeForce GTX 780 Ti), and then installing the lastest PDR patch (build 2726), I went back to projects that previously had worked on my old system without the yellow / orange line. It might be of note that the old system's version of PDR12 didn't have the newest patch, and the graphics card for that system was a bit older (XFX ATI Radeon HD 5870).

Here's hoping someone can find a solution and/or Cyberlink can get another patch to remove this colored line issue. Xexor Weglin
http://www.youtube.com/user/xexorweglin

This has been solved by uninstalling the 3D Vision component in the nVidia driver package. Let us know if you have it currently installed AND if uninstalling it gets rid of the issue

YouTube/optodata

DS365 | Win11 Pro | Ryzen 9 3950X | RTX 4070 Ti | 32GB RAM | 10TB SSDs | 5K+4K HDR monitors

Canon Vixia GX10 (4K 60p) | HF G30 (HD 60p) | Yi Action+ 4K | 360Fly 4K 360°

I did have it installed. I uninstalled the 3D Vision and 3D Vision Controller items from Control Panel. The problem remains. Xexor Weglin
http://www.youtube.com/user/xexorweglin