Topaz does not provide a plain test environment, so nothing can be done to isolate if the hardware is the cause.
As I have suggested before, Topaz should provide benchmarks and an environment where we can check if the hardware is capable of running correctly.
I have been participating in this tester since the alpha version (around May), and I feel that most of the reported error symptoms are due to the lack of coordination between FFMPEG and TVAI GUI.
For example, the container format and codec do not match, the fps and color space of the input files are not recognized, and wrong outputs are made, and these are due to the immaturity of the GUI.
I think the CLI was relatively stable in my environment.
After 3.0.1, showing a preview will sometimes lock up the application (hour glass cursor forever). This did not exist under 3.0.0; I could stack up half a dozen previews without a problem. Iām having to go back to TVEA 2.6.4 .
This new version has a lot of brilliant work in it. It has some great features and can do some amazing enhancement work. And,I hate to say it, but I donāt think VEAI 3.0.x is ready for prime time.
Whether it is to Preview or Export, The GUI it hangs all too easily. It appears to get out of sync and lose contact with the FFMPEG sessions it is running; which may actually be one of the reason it hangsā¦
And, finally when it crashes or hangs, it leaves an alarming number of unclosed handles and other resources, making a full system reboot necessary.
Love it, but I canāt use it. - Iām going back to the last release of VEAI 2.x until they get it more stabilized.
Make that three as I havenāt encountered any issues with v3.0.1 either - and I only use the GUI. I probably donāt push it as far as some other users but it just works for me, and itās faster than 2.6.4 too. Same three videos with the same settings - 11 hrs 3 mins in 3.1.0 (running concurrently) but 12 hrs 39 mins in 2.6.4 (running consecutively).
Make that four. Iām generally happy with v3 and havenāt suffered any GUI crashes (but havenāt tried to process anything more than short clips). Although there are still some things that need to be improved and added (but am sure they are coming, such as frame counting/numbering, and improved models), the devs are doing a good job rolling out updates.
I think in a few months this application is going to be amazing!
No, not really, but since the GUI effectively creates and launches the FFmpeg jobs as semi-autonomous child processes. - If all the GUI needed to do was launch the FFmpeg processes and then forget about them there would be fewer problems, but such a one-way GUI would not be especially useful. - In order to be a fully functional tool, the GUI must also maintain 2-way communication with the FFmpeg jobs it has started.
This is the problem: They need to be able to perfect the handshake they use to work together. In order for them to work together there needs to be a reliable 2-way status interface with rules.
(-A lot of my early background was in early machine-to-machine telecommunications. The number of things that can go wrong when two computers are talking to each other is enormous. )
Although these processes are both running on the same system, the same problem applies. - The GUI to FFmpeg relationship must be kept synchronous, (or stateful), in both directions. If they canāt, do that a failure is sure to happen.
There are many ways to accomplish this interface. The problems occur when this interface encounters a situation it canāt handle, or when the two processes also rely on communication that is outside the defined interface. (Itās like hot-wiring equipment to make it run; it may work but may not be fully functional and it is too easily broken.)
Bottom line:If they can improve the GUI to FFmpeg interface, a lot of VEAI 3ās problems will vanish.
They need to get passed ffmpeg and be able to use handbrake.300 for a gui is expensive.
Cropping needs to done like Gigapixel.
Or decoding and encoding needs to be done like Divinchi Resolve Or Final Cut Pro or Vegas20.
lol, suggestion, use Gigapixel + davincin resolve + final cut and + vegas20 => the software you want
(just kidding, but i donāt really see a lot of improvement in vegas20 compared to 19, thatās a 200ā¬ update, not a 99 )
iām almost pretty sure that time has been lost in fixing the Gui crash which appeared at some points, and certainly because of that, lot of time has been lost during the alpha/beta/EA and this time has not been used to solve other issue. the gui crash is now almost over, and rarely happen (at least in 3.0.0), as you can see, much more things have been added to the software in term of change since this issue has been mostly cleared. if itās the reason, certainly future update will improve things better and faster.
iām curious about the fact if everybody who have the most biggest issues with 3.0.1 have all RTX card, and the people who have an ok experience with 3.0.1 have GTX card.
i know you have a GTX card. if my memory is correct PaulM too. (sorry if itās not).
maybe itās related to this difference ?
the issue i experienced with a 4500RTX + 3.0.1 :
big drop in term of speed processing, between 0.10 to 0.20 seconds per frame, when 3.0.0 is close to 0.01 to 0.02 (compared to 2.6.4)
when using trim, the videos is corrupted during 1/3 of the result file. after 1/3 it resume and plays ok. like black parts during 1/3 of the file
when loaded in vegas pro, the audio track is totally out of sync with the video. itās shifted and the whole video is longer with the audio track starting after the video track.
noticed this on 3.0.0 and 3.0.1 , no big deal : when using crop in 16/9 on SD files, we see a one pixel part of the source file once the preview has been rendered on the left of the preview while playing it back.
in preferences, when clicking on the box, we see in transparency the playback window (this one was funny) ).
the only big issue i have with 3.0.0 in regards of upscaling and change of frame rate (didnāt tried anything else) was the trim make a corrupted video. at least with using MPC-BE (fork of Mpc-HC) and vegas pro 19.
Bon matin! might be! yes I have GTX1070. I didnāt check performance too closely on 3.0.1, I would need to go back to our messages to find where we compared performance and see if it got slower for me or notā¦going to check now
VEAI 3.x should be able to do a lot of this stuff. And in the future, probably more.
But FIRST, they must get the GUI - FFmpeg interface working properly.
If an FFmpeg session goes belly up or there is an error, the GUI must know this so it can update the screen, do what is necessary to handle the error and let the user know.
If FFmpeg finishes a job correctly, it should also let the user know. Right now, you can blow this all away by just clicking in the wrong place on the GUI while an FFmpeg job isnāt finished or in a transition. It can miss the ball entirely and hang.
VEAI has a huge potential, but the interface needs to be very solid and itās not there yet.
You may be on to something. My AMD RX 6600 hasnāt had problems but itās just slower normally then either my 3060 or 3060Ti. Now itās faster but only because the 3060ās are slower then they were. I donāt stack videoās normally I just open new instances of the software to do multiple at a time. I havenāt had issues with crashing. Again Iām only using ProteusV3 and mostly just estimating the values. So I just drop back to 2.6.4 for everything right now.
If I was up to it Iāll see if I can swap out a 3060 for either or both my 1050Ti or my 1660 super.
The problem the limitation of ffmpeg.
Divinchi Resolve is free and handles video better with same color space.
Handbrake does same job and more as ffmpeg.
Hdr10 is easy to Add for meta data.
The gui can analyze the video and insert the metadata.
Interesting detail! - Since most of the interaction (work) involved with the GPU is done via FFmpeg, then itās possible thereās still a few more RTX-related things that need to be fixed in the code theyāve added there.
On the other hand, perhaps the GUI is just passing wrong parameters to FFmpeg that cause the problem. The command interface between them needs to be kept in sync, too.
However, if the problem is RTX/GTX-related, it is more likely that the problem is somewhere in (or under) FFmpeg. - In case you didnāt see my post, I attempted to do (Export) deinterlace the same file in 2 jobs. One was using a 1x and the other a 2x framerate setting. The first one went DOA about 90% finished. I killed the 2nd one and attempted to exit. Of course, the GUI hung waiting for a dead FFmpeg. I finally killed the GUI via Task Manager, but the number of hung resources and file handles belonging to FFmpeg was enormous!
I rebooted and retried twice more with 0% success.
.
)