As of ver 3.15, there are still some major issues for me. All of these are pretty important imo!
/*
specs: Windows 10, GTX 1080 Ti, i7-10700k
mostly using: AMQ13 or Prob3 to H.264, +trimming
*/
-
Trimming (IMPORTANT):
It appears the only way to trim is to drag the start/end points with the mouse, whish is extremely inprecise. Going frame-by-frame with the left/right -arrow-keys only adjusts the view, but doesn’t adjust the trim.
Honestly, this was SO MUCH BETTER in v2.6.4, where there were dedicated buttons for setting the left- and right-trim-bracket at the current viewed frame (so you’d first use left-/right-arrows to go to the exact frame and then you’d press the according “{”- or “}”-button to set the trimming-point there). Now those buttons are gone even though “Trimming” isn’t even on by default anymore and has it’s own dedicated workspace. -
Original vs Preview (DESYNC):
When playing the original video and the preview side by side (or in any view), one of them is always a couple frames DELAYED, making it ugly and hard to make a clean comparison. -
Badly encoded H.264?
Sometimes H.264-encoded videos are not able to play (or get meta-data) when HTML-embedded, even though they should be (I know H265 isn’t widely supported yet, but I’m really talking about H264). The strange thing is that sometimes they work, sometimes they don’t. -
Prevent Sleep:
Haven’t tried it yet with the new version, but I guess this issue still exists, as I didn’t see a changelog about it:
It would be nice if the program prevented going to sleep-mode, while processing…
Additionally or alternatively at least add an option of what to do after processing (large) files (like: “After completion: shutdown”). -
SEEKING (slow):
Seeking (via mouseclicks and/or arrow-buttons for frame-by-frame) in the video is often quite slow (whereas in every “normal” player this is instanteanous). And it’s even slower and sometimes won’t even work/update the frame at all (seems to be even worse in trimming-mode and EVEN worse AFTER applying trimming). -
Setting Mb/s:
Setting the bitrate to a specific Mb/s feels like quite a cryptic thing for an average user, as this really depends on the output-resolution etc… Without knowing the default one for the given resolution, it’s impossible to guess the correct relative setting. I liked the “relative to default”-approach (i.e.: “Constant Rate Factor: default: 20”) settings in 2.6.4… would like to see something like it being implemented again (maybe a “relative to default” in % quality-option).