Feedback on newer 2020 builds (a couple of issues)

[Urik]

It's been a while since I checked the forums, so I decided to try the new nightly builds (June). Sadly, there's a couple things I immediately noticed that are a step back for me in terms of performance.

• Now, when a video is opened, a "Decoding frame type" window appears. I realize there's probably some point to that feature, but it does slow file opening significantly. I eventually noticed it can be cancelled without aborting the loading of the file, but that takes two mouse clicks. Can a user setting be implemented to skip that step?
  
  
• 
  It looks like there have been some changes to interface drawing or scaling. Now the program window freezes for a while if I drag it between different (1080p and 4k) monitors, which have different Windows scaling factors applied to them. It often leads to broken (blacked out) video viewport. screenshot
  (I am still using DXVA2 with OpenGL by the way, if that matters (works best for me)).
  note: MinGW 200620 seems to be less problematic in that aspect (than VC++ 200611), but the viewport still breaks after dragging to 2nd monitor and back screenshot
  This did not happen with whatever version I was using before, which was sometime between 191130 and now.
  

Lastly, does anyone have backups / hoarded older MinGW Win64 installers? The ones between 201911 and now? I think I was using a late 2019 or early 2020 MinGW build, but when trying latest one, I thoughtlessly uninstalled the one I had. I've been able to copypaste 191130 build from my laptop but still regret I never kept the installers.

Thanks for continued development.

[eumagga0x2a]

Now, when a video is opened, a "Decoding frame type" window appears. I realize there's probably some point to that feature, but it does slow file opening significantly. I eventually noticed it can be cancelled without aborting the loading of the file, but that takes two mouse clicks. Can a user setting be implemented to skip that step?

Hitting ESC should abort decoding frame type, no rodents harmed. Err, it does need multiple key presses. It should be safe to cancel if you know for sure that the H.264 stream in your video doesn't change parameter sets on-the-fly, is never field encoded and you don't need to know whether a frame is P-frame or B-frame before getting it decoded.

This feature has been added to handle stuff like interlaced H.264, ubiquitous in France and UK, to warn about streams changing their properties on-the-fly and actually to find out frame type which we left unset for MP4 until now, necessary for improved cut compatibility checks in copy mode. No user setting to skip this ability permanently is planned ATM as other functionality relies on correct frame type (the MP4 demuxer stood out as the only one which lacked this ability).

It looks like there have been some changes to interface drawing or scaling. Now the program window freezes for a while if I drag it between different (1080p and 4k) monitors, which have different Windows scaling factors applied to them. It often leads to broken (blacked out) video viewport. screenshot
(I am still using DXVA2 with OpenGL by the way, if that matters (works best for me)).

Thank you very much for the info, but behaviour with multiple monitors is completely untested and I cannot work on it due to limitations of my local environment. The only thing which I probably could do is to implement a way to disable automatic HiDPI scaling by Qt alltogether. Patches warmly welcome.

MinGW 200620 seems to be less problematic in that aspect (than VC++ 200611)

Probably the difference between Qt 5.15.0 in the recent MinGW builds and Qt 5.12.x in the MSVC env.

[Urik]

Ok, thanks.

It should be safe to cancel if you know for sure that the H.264 stream in your video doesn't change parameter sets on-the-fly, is never field encoded and you don't need to know whether a frame is P-frame or B-frame before getting it decoded.

Yeah, 99% of the time I use Avidemux with screen or camera recordings which only have P-frames and strictly fixed i-frame interval.

other functionality relies on correct frame type (the MP4 demuxer stood out as the only one which lacked this ability).

That probably explains why I've been seeing a similar "reading clusters" window for opening .mkv files (ripped movies, which would have b-frames and dynamic GOP size based on scene changes). I thought that had to do with embedded chapters or extra metadata exclusive to mkv.

[eumagga0x2a]

That probably explains why I've been seeing a similar "reading clusters" window for opening .mkv files

Actually right after clusters (internal Matroska structures, not related to chapters etc.) are located, the "Matroska Images" working dialog is displayed while H.264 slice headers are decoded to determine frame type. The similar code for HEVC is disabled, probably due to some problem in underlying functions (didn't look into it yet).

Exactly for the case that a user knows for sure that a video doesn't contain any B-frames, Avidemux doesn't reject loading MP4 when frame type decoding has been canceled. Everything is a trade-off.

[eumagga0x2a]

Yeah, 99% of the time I use Avidemux with screen or camera recordings which only have P-frames and strictly fixed i-frame interval.

Do these H.264 streams conform to the Baseline profile? In this case it might be a reasonable trade-off to skip frame type decoding (this would leave those mp4 files with H.264 Baseline profile video which lie about the position of keyframes completely broken as they were all the time before the check was added to the demuxer, but they are indeed rare).

By the way, why do you ask about Avidemux packages with installer? The Avidemux program directory is sufficient, copy it anywhere you like, done. Packaging as *.exe matches the expectations of many people, but it is not necessary.

OpenGL stuff greatly depends on graphics drivers, so in doubt try the latest and greatest. Apart from that, Qt is hit and miss regarding OpenGL, with 5.13.x and 5.14.x versions severely broken for Avidemux on Windows.

When you see "freezes" on moving Avidemux window from one screen to another, do you notice any messages matching these transitions in admlog.txt?

[Urik]

So, it's a big reply and some description are perhaps messy. I just tried to briefly mention everything in one message.
Some of these things with Windows are inconsistent and weird, and hard to find any logic/consistency to provide reliable info.
Like, the fact that on my laptop, none of interface scaling and behavior issues are present, despite it running almost same Win10 build as PC.

First I'd like to admit that the "broken viewport" thing turned out to be a rare occurrence, and it's also fixed by triggering a scale event (touching/dragging the window edge).
After testing out 200622 many times today, I didn't run into that anymore.

Do these H.264 streams conform to the Baseline profile? In this case it might be a reasonable trade-off to skip frame type decoding (this would leave those mp4 files with H.264 Baseline profile video which lie about the position of keyframes completely broken as they were all the time before the check was added to the demuxer, but they are indeed rare).

Nope, my are all High. I checked, even videos from very old smartphones use High profile. Usually level 4 for my 1080p cameras/phones, and level 5 for newer phones and desktop recording.
I found frame decoding can be skipped with esc > spacebar (because "cancel>yes" gets selected)

By the way, why do you ask about Avidemux packages with installer? The Avidemux program directory is sufficient, copy it anywhere you like, done. Packaging as *.exe matches the expectations of many people, but it is not necessary.

Yes, it's what I did. Just that installer's a bit faster/easier. I regret not keeping them.

OpenGL stuff greatly depends on graphics drivers, so in doubt try the latest and greatest. Apart from that, Qt is hit and miss regarding OpenGL, with 5.13.x and 5.14.x versions severely broken for Avidemux on Windows.

The reason I stick to OpenGL on PC is it doesn't have "quarter resolution" pixelated output on my main (4K) monitor, as if I'm seeing 540p output in 1080p viewport - like DXVA2 (display) does.
But I've finally figured the washed blacks (gamma) issue in Avidemux when DXVA is used with Nvidia card - there's an option in Nvidia Control Panel that can force (override) color settings. After setting gamma to Full Range (0-255), it shows it correctly now (with DXVA, but it was never a problem with OpenGL).
I recall doing that the same for when I had similar issue with VLC (I primarily use K-lite MPC-HC, which doesn't have that issue). So there's maybe some misinterpretation going on between Avidemux and Nvidia?
On my laptop, which has dual graphics so it uses Intel iGPU normally (outside of games), I can use Avidemux with DXVA display without any issues, and it plays back everything except heavy 4k 60p where it does slow down.

edit: I had to cut out the rest of this reply due to something in it got blocked by forum engine, will post later once I figure why

[Urik]

When you see "freezes" on moving Avidemux window from one screen to another, do you notice any messages matching these transitions in admlog.txt?

Turns out, the freezing isn't caused by dragging between screens, but when Avidemux window touches edge of screen (left, right, bottom), or goes beyond it, and then if I try to pull it back FAST (not slow), it kinda "sticks" to it for a second or two.
With 200622, it happens even without video loaded; with 191130, it never happens without video loaded, but does happen a little with video loaded, but still to a lesser degree than 200622.
I thought the cause might be in Nvidia, so I did a test removing the card and running only one monitor (2560x1080, no scaling) connected to Intel iGPU (i7 7700k/HD 630) and it still was happening with 200622.
The craziest thing is it doesn't happen at all on laptop.

I've attached the logfile, well, it's a copypaste of two logs actually. I guess forum didn't like something in the log.

For some reason, older Avidemux seems to run more resize events than newer one. But it's not 100% consistent, the log output sometimes varies...

One thing I forgot to mention is that somewhere between 200601 and 200620, something changed that is causing the text and gui elements like progress bar playhead to be bigger on new versions:
191130 on the left, 200620 on the right
Maybe it has to do with Windows scaling, because on laptop both old and new look identical.

[eumagga0x2a]

The attachment contained the copy of the post, but no logfile content.

Turns out, the freezing isn't caused by dragging between screens, but when Avidemux window touches edge of screen (left, right, bottom), or goes beyond it, and then if I try to pull it back FAST (not slow), it kinda "sticks" to it for a second or two.
With 200622, it happens even without video loaded; with 191130, it never happens without video loaded, but does happen a little with video loaded, but still to a lesser degree than 200622.

Does disabling OpenGL in Avidemux have any influence on that? In any case, IMHO this must be an issue between Qt and the graphics driver.

Regarding different interface scaling, I'd attribute it to the Qt upgrade, and Qt version in MinGW builds is as a rule what comes with the current revision of MXE at the time of build env update. It is possible to patch MXE to get an older version of Qt, but this is complicated.

By the way, there is indeed a new issue with recent builds, which you suprisingly didn't mention (maybe it is specific to the DirectX "DXVA2" video output), which I probably should investigate (but likely won't as it is not a deal breaker):

When a filter changing video dimensions has been added to the filter chain and filter preview mode is enabled, stopping playback results in video display showing solid black. It is necessary to force refresh either by resizing the window or by navigating to a different frame to get a properly displayed picture again.

Windows-only, I see it neither on Linux nor on macOS.

[Urik]

Does disabling OpenGL in Avidemux have any influence on that? In any case, IMHO this must be an issue between Qt and the graphics driver.

Just tested, yes, turns out unchecking "Enable OpenGL support" totally eliminates that issue when video is not loaded. With video loaded, it still happens with DXVA display, but that is true about 191130 as well.

When a filter changing video dimensions has been added to the filter chain and filter preview mode is enabled, stopping playback results in video display showing solid black. It is necessary to force refresh either by resizing the window or by navigating to a different frame to get a properly displayed picture again.

Well that makes sense since I only ever use Avidemux in stream copy mode.

[eumagga0x2a]

Does disabling OpenGL in Avidemux have any influence on that? In any case, IMHO this must be an issue between Qt and the graphics driver.

Just tested, yes, turns out unchecking "Enable OpenGL support" totally eliminates that issue when video is not loaded. With video loaded, it still happens with DXVA display, but that is true about 191130 as well.

I wonder if playing with power saving settings in the graphics driver (if such settings are exposed on Windows) might have any effect on this.

When a filter changing video dimensions has been added to the filter chain and filter preview mode is enabled, stopping playback results in video display showing solid black. It is necessary to force refresh either by resizing the window or by navigating to a different frame to get a properly displayed picture again.

Well that makes sense since I only ever use Avidemux in stream copy mode.

This matches my personal use case for Avidemux as well :-)

Anyway, the black video display issue should be fixed by [dxva2Render] Use indirect route right away instead of futilely trying the direct one first.

[Urik]

Don't know how many versions ago this happened, but basically I noticed that newest MinGW 210104 starts as fast as VC build now. At some point, MinGW builds were taking noticeably longer to start than VC builds for me. Nice.
I still like hidpi scaling better on VC but as you said that due to different Qt versions or something.

[eumagga0x2a]

I noticed that newest MinGW 210104 starts as fast as VC build now.

Avidemux mentions the Qt version in admlog.txt, you could check whether anything has changed in MinGW builds in this respect (I would be very surprised if it has).

At some point, MinGW builds were taking noticeably longer to start than VC builds for me.

I could never reproduce this difference in startup time on Windows.