January 20, 2021, 12:27:01 AM



2.7.2 has a refresh problem

Started by Marc66FR, March 16, 2019, 01:34:45 PM

Previous topic - Next topic


Just installed 2.7.2 and noticed the current time location does not update straight away when making changes. Here are 2 examples:

1. Open a file, move to 10 min into the file >> Time counter does not show current time location right away

2. Cut from beginning of file to current location (Select end marker & erase) >> Removed part does not disappear straight away and time location does not go to zero

2.7.1 does not have this problem; updates are instanteneous


March 16, 2019, 05:30:00 PM #1 Last Edit: March 16, 2019, 05:32:00 PM by eumagga0x2a
I can't reproduce this with the release build on my late-2016 MBP running macOS 10.14.3. Which hardware and macOS version are you using? Do you experience the refresh issue with OpenGL support and display enabled?

Starting with Qt 5.10, the old OpenGL implementation in Avidemux has become not viable, the new one, premiered in 2.7.2, actually fixed massive redraw problems. Qt 5.12.x has introduced new regressions / issues, this is why the release is built with 5.11.2 instead.


I'm running OSX Sierra (10.12.6) on an iMac (27" 5K 2017) with 24 GB RAM

My preferences were set to Qt, no OpenGL and no HW acceleration. I changed Qt to OpenGL (faster), enabled OpenGL and didn't have the problem. I reverted to my original settings and also no longer had the problem. My tests were done on a much smaller file (500 MB) than when I posted my message. I'll try again on a larger file (6 GB) when I have one.

BTW, should I or should I not enable:
- Display - Video Display: OpenGL or Qt ?
- GUI Rendering: OpenGL or not ?
- HW Accel: Decode video using video toolbox or not ?

I don't think I ever had those options enabled and never had any issues


Quote from: Marc66FR on March 17, 2019, 10:04:23 PM
I changed Qt to OpenGL (faster), enabled OpenGL and didn't have the problem.


QuoteBTW, should I or should I not enable:
- Display - Video Display: OpenGL or Qt ?

OpenGL as long as it works. Qt is the fallback when everything else fails.

Quote- GUI Rendering: OpenGL or not ?

This is the master switch for OpenGL support inkl. video display, changes effective after Avidemux restart. Should be enabled as long as it doesn't cause major problems like crashes etc.

Quote- HW Accel: Decode video using video toolbox or not ?

Effective only for H.264 and HEVC, especially useful with HEVC (big energy savings). Should be enabled, though the benefit is not that astounding as from VDPAU or LibVA on Linux because after decoding in the graphics card the data has to be downloaded back to the memory. In case of failure Avidemux falls back on software decoding.


Since I use version 2.7.2 on an iMac (5k, 2014) with MacOS Mojave 10.14.3) I have had a similar problem.
I have applied all of your recommended settings, but this did not help.
The attached screen photo makes it clear that there is no longer any indication of the progress of time.


March 20, 2019, 11:50:48 AM #5 Last Edit: March 20, 2019, 11:53:16 AM by eumagga0x2a
Is it with dark theme only? (Never tried it myself)

Looks like white text on white background.


The dark mode is fixed in Qt 5.12 which has a major issue with OpenGL enabled (Avidemux window is completely blank on startup unless resized after it has been shown) which forced to use 5.11.x for the Avidemux release.


Sorry, but your answer is a little too difficult for my understanding.
I will continue to use version 2.7.2 in dark mode (which I also like); and maybe a solution will come soon.


The solution depends on Qt framework developers fixing issues in their product or on Avidemux applying more or less ugly workarounds like automatically resizing the application window a little bit after it has been shown.


Qt: this may not look good in this case.
I remember that Qt was also indicated as the reason why I' can't use the CMD + V keyboard shortcut  within Avidemux to enter a file name in order to save a file since a VERY long time.


Interesting, I wasn't aware of this issue. The corresponding Qt bug report is marked as fixed in 5.12, but default editing shortcuts definitely don't work with 5.12 in the file dialog of Avidemux, which might be attributed to the way Avidemux populates its menus or to something completely different.