Request: We really need a full screen payback of Preview clips in VEAI. The split screen functionality we have now is not sufficient.
Being able to view Preview clips in an external playback app is nice, but it also has some drawbacks.
Request: We really need a full screen payback of Preview clips in VEAI. The split screen functionality we have now is not sufficient.
Being able to view Preview clips in an external playback app is nice, but it also has some drawbacks.
Seeing same sort of numbers with 3900x and RTX 3060Ti. 25% cpu and 35-48% GPU depending on input file resolution, output scaling and output file type.
Checked with 2.6.4 and they are mostly the same with about 20% more GPU memory used at 4 and 8K scaling in 2.6.4 oddly.
Since I do multiple instances generally lower GPU percentage is a good thing but if the GPU usage was 90-100 percent and the speed almost doubled then I would not have the need to run multiple instances, just batch jobs.
Deinterlace? Is it interlaced to begin with? What kind of file is it? If itās a VOB, the release notes say there are still problems with them. - You should submit it for examination; It would be very useful for them.
Suggestion: When playing back Preview clips, the Zoom always resets to 100% is another clip is selected. - This behavior is rather annoying when trying to view the image quality differences between Previews of similar clips. - I suggest this behavior should have a āzoom lockā toggle.
Itās archival m2ts, of which I have a large library for ārestorationā. I have already sent the source and logs to the devs.
Does anyone here actually use more than one of the facilities of Beta at the same time? By that I mean Deinterlace, Enhance, Resize, etcā¦
If itās a short video I guess itās fine, but when trying with something longer it takes forever! I have always noticed that, for me, if Iām doing 2 or 3 separate processes I can get the job done faster than all at the same time.
Nope. I think it just makes the results worse.
William,
Modern video media is compressed, the methods used are effective for keeping the files compact, but the method is lossy.. The higher the compression, the potential for degraded image quality increases. As such, the decompression and subsequent recompression for each successive pass will degrade the video. - The only way to minimize this degradation is by keeping your CRF values as low as you can and/or keeping your output bitrate as high as possible. (Note: VEAI relies on bit rate rather than CRF values.)
One of the benefits of setting up VEAI 3 to do the whole job in one or two passes is a big step towards reducing processing degradation. If fact, if the AI Enhancement applied carefully, it can put a lot backā¦
BUG: I am experiencing a new problem. At the end of long rendering (a.k.a.Export sessions,) 3B is exiting by itself, sometimes exiting before closing the output file correctly. I the last two days, it has happened twice. Once the output was playable, the other has no image information and is simply 19 GBs of useless file space that took my system 8+ hours to produce.
I have extended logging turned on. If you want me to upload the relevant logs and data files, please let me knowā¦
Yes I tried that but also experienced that it sometimes takes too long for me to process. Havenāt checked yet if doing it seperately would finish faster here.
This āknown issueā descriptor is wrong. It suggests you have to set the memory use percentage only once after installing the beta (I guess, also installing a beta update). This is not true. It doesnāt save the memory use percentage AT ALL, so the correct descriptor is āSet the memory use percentage on each app launchā, not just āafter installationā. Probably a lot of the testing Iāve done is set to 10% memory, geez. (Although I do have 12Gb GPU to start with.)
OK, so just tried 90% memory and get exactly the same error on my m2ts interlaced source as beforeā¦
Once videos have been added to the queue, is there a way to re-order the jobs that have not yet begun processing?
Just started using the 3.0 beta, so sorry if my comments are overlapping with others.
It is not obvious when an export is finished - I had the player looping on the source footage and thought the export was still being processed and lost just a few hours
Compared to V2, it is no longer possible (or at least I did not find how) to resize and crop, which I typically do for DVDs (target size 1920x1080 or 3840x2160 - plus some excess zooming in order to remove the parts which are removed (overscan) when watching on a TV and which are usually dirty)
Resizing vs. enhance is unclear to me, since it was part of the same job in V2 - it might be worth explaining in what orders things are processed; and is resizing just regular bilinear resizing or is it AI-powered?
The names of the intermediate files are not explicit and should be - also, it would be nice to have a view of all jobs for a single export - ETA is currently meaningless - you do not know if it is the last job or if 3 other jobs are necessary for this export,
There is (as there was in V2) a huge performance degradation when the output size (depending on the output size) is higher than a certain threshold: time per frame gets suddenly multiplied by 10 or 20 - consequently, I now do intermediate steps in V2 (576p to 720p to 1080p). In V2, it was possible to see if the speed was ridiculously slow at the beginning of a job and add an intermediate step when necessaryā¦
In V3, this is not possible when the stupidly slow performance happens in the 4th job of an export.
I saw this for Artemis HQ and Dione DV and I strongly suspect it happens with other models.
I use an M1 Pro with 16GB RAM and 16 GPU cores, and a M1 Max with 32GB RAM and 32 GPU cores.
Where has grain gone?
Thatās all for now. I certainly have forgotten stuff.
3.0 is going to be a huge leap forward once it is out of beta!
Small bug with the version:
(example with source 1480x1080 px source prores HQ 10 bit 4:2:2):
If using āAUTO-CROPā stabilization (any strength)
if we use at the same time the Resize āSame as sourceā, the program makes an output with dimensions smaller than the source. (equal to the crop)
Current workaround:
Resize + Custom Height = 1080 (same as source and W is correctly calculated and output is OK).
Otherwise the sequence:
Stabilization + Enhance fine tune āautoā + convert FPS (from 16fps) to 25 fps + Resize CUSTOM Height 1080 + PRORES 422 HQ 1480x1080 output in final output: I get an encoding at 2.8 fps
GPU = RTX 3090, average utilization 30%. A margin of progress is expected.
(Never again the possibility of using AVISYNTH?)
Will those files be recognized correctly when the information is viewed in ffprobe?
If the time is wrong, maybe the length or fps is not recognized.
ffprobe looks to be ok:
Input #0, mpegts, from ā/myfolder/Topaz works/RĆ©siste (DVD).m2tsā:
Duration: 02:26:10.44, start: 4200.000000, bitrate: 7001 kb/s
Program 1
Stream #0:0[0x1011]: Video: mpeg2video (Main) (HDMV / 0x564D4448), yuv420p(tv, progressive), 720x576 [SAR 64:45 DAR 16:9], 25 fps, 25 tbr, 90k tbn
Side data:
cpb: bitrate max/min/avg: 8000000/0/0 buffer size: 1835008 vbv_delay: N/A
An Additional Thought:
IMO, I believe that VEAI 3.0 has put the deinterlace filter in the wrong place, (that is assuming the filters are being done in the sequence the are listed in.)
Functionally, deIntelacing should be done first for the rest of the filters to work correctly. In fact, moving it to first place would facilitate stabilization and allow cropping without error.
However, this is my conjecture. Deinterlace might actually be the first thing VEAI 3B does, it just isnāt shown that way.
Not sure about VEAI B3 because I havenāt got it to work yet, but another stabilizer product I use doesnāt stabilize AT ALL unless I manually deinterlace first. It makes sense to me because the reason for stabilizing is to combat (camera) MOTION, and itās MOTION that makes sequential (upper, lower field) frame images radically different (the toothcomb effect) which confuses calculations as they attempt to follow object boundaries.