BUG in Video Event Pan/Crop w/ large JPEGs in AMD-7800 APU processor

john_dennis wrote on 7/12/2018, 1:06 PM

I've got 2 more minutes to waste until this render finishes.

1. 4000x3000 is not a large JPEG pixel dimension.

2. I can't run your project because it was created in Vegas Pro 15. Create the project in Vegas Pro 10 and you'll get more interest in the community. After all, you say the problem has been around for a long time.

3. I'll stick with my intel system.

4. In today's environment, you should be free to post anything you want on youtube.

Kinvermark wrote on 7/12/2018, 1:14 PM

JPEG pans & crops work great for me! Even on panoramas over 10k pixels wide.

Not going to download anything off your dropbox, it might be full of BUGS! Or other undesireable digital microbes 😀

OldSmoke wrote on 7/12/2018, 1:18 PM

Hi, guys from Magix. This is not the first time I've reported this BUG. I already reported this BUG to AMD, Sony (in the time that Vegas was from Sony) and a few years ago to the Magix team. In all these years, none of these companies have taken any steps to remedy this problem.

This is yet another attempt to expose the problems. If it is not resolved, I must post it on YouTube, so that the whole world can know about the disregard.

Vegas Pro is not working well on pan / crop in large JPEG images on machines with AMD processor A10-7800 APU.

I made a video explaining the BUG's step by step. Anyone can watch it here:
https://www.dropbox.com/s/b7wuuznrw44qumv/Vegas-Pan-Crop-Bug.mp4?dl=1

You can download projects, sample JPEG file, rendered file and system information at
https://www.dropbox.com/s/32pryretnoz8tbn/Vegas-Bug-Pan-Crop-JPG-in-AMD-A10-Proc.zip?dl=1

If my problems can not be solved, what I might be doing is alerting others on YouTube, Vimeo, Daily Motion, etc. My patience has run out for years!

Are you using it's internal GPU or a dedicated one?

vjsouza wrote on 7/12/2018, 2:56 PM

OldSmoke, AMD A10-7800 is a 12 cores APU, Is a GPU and CPU in the same processor. This does not need a graphics card. I can do pan/crop with JPEG in others NLEs, So, the problem is not with the proc.

matthias-krutz wrote on 7/12/2018, 3:16 PM

Hm, the project shows no errors in the preview (R9 380).

But a longer time ago I had similar problems with Pan / Crop in the forum addressed. I think they exist since VP14 and are not limited to AMD graphics cards. I see the problems when using Media FX or FX before Pan / Crop. Then the output area is shifted or jumps. Without GPU accelaration it can then come to a crash. Last week, I reported the error to Magix again and received confirmation that it was logged as a bug in there list.

A download link to the project is here. The project is created with MSP12.

vjsouza wrote on 7/12/2018, 3:55 PM

matthias-krutz, when you had this problem, do you remember the model of proc and/or graphic card?

matthias-krutz wrote on 7/12/2018, 4:18 PM

I still have these problems. My 2 computers are listed in the signature. Did you test my project? It runs also on VP15 and MSP15? The result would be interesting.

OldSmoke wrote on 7/12/2018, 5:17 PM

I still have these problems. My 2 computers are listed in the signature. Did you test my project? It runs also on VP15 and MSP15? The result would be interesting.

@matthias-krutz I ran your project on my Surface Pro 3 and I can reproduce the behavior/bug. I have SVP13 on my Surface too and that works fine. I even used my own images from my a6300 which are 6000x3376 and I applied a 4:3 crop and I can see the bug; again SVP13 doesn't show that bug.

Edit: It also work if you put any FX in front of Pan/Crop on the event level; SVP13 is working fine.

matthias-krutz wrote on 7/13/2018, 2:54 PM

@OldSmoke Thanks for the test and the confirmation. As a workaround, I have renounced Media FX and FX in front of Pan/Crop, if Pan/Crop is used.

D7K wrote on 7/14/2018, 10:53 AM

Seems to be related to the size of the file and the length of the pan/zoom. 5440 wide jpg, down to 1/5 size in 10 seconds get jumps, lengthen to 20 seconds smooth as butter.

Kinvermark wrote on 7/14/2018, 11:22 AM

Just preview or after render as well?

Former user wrote on 7/14/2018, 12:51 PM

“Seems to be related to the size of the file and the length of the pan/zoom.”

All very well, but have you checked the size of the microbes and bugs, its well known that they can play havoc with the crop size.

D7K wrote on 7/14/2018, 3:45 PM

After render

vjsouza wrote on 8/16/2019, 7:51 AM

JPEG pans & crops work great for me! Even on panoramas over 10k pixels wide.

Not going to download anything off your dropbox, it might be full of BUGS! Or other undesireable digital microbes 😀

I classify this answer as a moral offense. The moderators of this forum should remove this!

Former user wrote on 8/16/2019, 7:58 AM

This post is over a year old.

vjsouza wrote on 8/16/2019, 8:19 AM

Not going to download anything off your dropbox, it might be full of BUGS! Or other undesireable digital microbes 😀

Kinvermark, I think your personal offenses against me are absolutely unnecessary to this forum as well as unnecessary to solve my problem. Since your contribution is totally nil, you might not have commented at all.

matthias-krutz wrote on 8/16/2019, 9:45 AM

The good news first. The problems with the Video FX in front of Pan / Crop seem to be solved.

But the performance problems still exist, even in VP17. This has not changed with me over the different PC configurations. At the moment it is a Ryzen R7 2700.
With Process Monitor I tried to find the cause. I noticed that JPGs and PNGs are read in 4k blocks.
I placed a picture of 3456x2592 JPG with 3.9MB as a 10 second event on the timeline. Only effect is a slight panning with pan / crop realized. For this one event about 200MB! of the one file will be read. That requires 200ms file time. Dyn RAM is set to default. It is also not due to generating the thumbnails. It seems to be a general problem with wicplug.dll and / or the file caching. It would be nice if someone repeated this test with his system. There may also be a difference between AMD and Intel processors.