Avidemux Forum

Quote from: budda on March 06, 2021, 02:52:04 PMAvidemux_2.7.8 r210306 = cpu load 99-100% vs old 2.7.5 Cpu load 40-50 but coding speed slower ~1.5x.

Could be the effect of multi-threaded decoding in the new or single-threaded encoding in the old version. Unless overheating is the problem, it makes no sense not using 100% per CPU core during encoding with a software encoder like x264. However, you should set the priority of the process to low in order to avoid slowing down other tasks.

Quote from: budda on March 06, 2021, 02:52:04 PMSeems new Avidemux good for modern Cpu and old for old.)

No, not at all.

Quote from: eumagga0x2a on March 09, 2021, 08:31:54 PM

Quote from: budda on March 06, 2021, 02:52:04 PMAvidemux_2.7.8 r210306 = cpu load 99-100% vs old 2.7.5 Cpu load 40-50 but coding speed slower ~1.5x.

Could be the effect of multi-threaded decoding in the new or single-threaded encoding in the old version.

I have similar experience (AMD Ryzen 5 2400G, Xubuntu 20.04):

• Avidemux 2.7.5: 25-32% CPU, 50-60 FPS
• Avidemux avidemuxLinux_2.7.8_GLIBC_2.28_amd64: 80-90% CPU, 100-120 FPS

A have actually never found out, why converting movies recorded from DVBT-2 (conversion from H265 1920x1080, 50FPS to x264 960x540, 50FPS) always worked only on 25-32% CPU with Avidemux 2.7.5. And other movies downloaded from the internet (so various codecs and FPS) I could convert also to x264 using 90% CPU. As a workaround when I convert DVBT-2 files, I convert 3 different files at once.
Now with Avidemux 2.7.8 the multithread conversion is faster for one file, but less efficient (CPU consumption is 3 times higher but conversion is just 2 times faster).
Overheating is not problem for my computer and I also do not have any troubles with running another processes - just the efficiency surprised me.

With a HEVC source it might be beneficial to use even VA-API hw accel (it is almost for sure beneficial to use VDPAU if you have an NVIDIA graphics card). You didn't clarify whether this option is available for you.

The problem with VA-API is the terribly inefficient NV12 to yuv420p / YV12 pixel format conversion. With VDPAU, we get yuv420p right away from the driver.

Just tested NV12 conversion in dummyVideoFilter::getNextFrame, with
image->convertToNV12(..);
image->convertFromNV12(..);roundtrip i get >350fps with 720p source (sw decoded).

Quote from: eumagga0x2a on March 11, 2021, 12:16:01 PMWith a HEVC source it might be beneficial to use even VA-API hw accel (it is almost for sure beneficial to use VDPAU if you have an NVIDIA graphics card). You didn't clarify whether this option is available for you.

If I look to Preferences - HW Accel there are only VDPAU (NVIDIA) and LIBVA (Intel) options. Both of them produce broken output so I do not use them.
This is the same for

• Avidemux 2.7.5 (200502_0a7883af677-fflibs 4.2.2), compiled from source,
• Avidemux 2.7.8 (avidemuxLinux_2.7.8_GLIBC_2.28_amd64.appImage)

BTW: I can use VA-API on my system, it works with mpv and ffmpeg version 4.2.4-1ubuntu0.1. But I do not know how to set ffmpeg to produce output file with similar size as Avidemux can (setting up ffmpeg is magic for me so I use Avidemux instead).

Minor GUI issue (with Win64Qt5 v2.7. with filters that don't have a configure GUI:
- the option is still present in the menu when they are added to the filter chain (configure menu entry should be disabled).
- Configure Button is enabled when they are made partial

Quote from: signy13 on March 11, 2021, 03:14:47 PMIf I look to Preferences - HW Accel there are only VDPAU (NVIDIA) and LIBVA (Intel) options. Both of them produce broken output so I do not use them.

Why didn't you report this right away, at least the libva part? Could you please build Avidemux off the current git master yourself instead of using an appImage and check whether VA-API / libva hw accelerated decoder for H.264 works? If it doesn't work either, please redirect Avidemux stdout and stderr to a file and attach this file to your reply.

It might be better to start a new topic for that.

Quote from: butterw on March 11, 2021, 04:01:32 PMMinor GUI issue (with Win64Qt5 v2.7. with filters that don't have a configure GUI:
- the option is still present in the menu when they are added to the filter chain (configure menu entry should be disabled).
- Configure Button is enabled when they are made partial

This is not a GUI issue but an API shortcoming. There is no way to know whether a filter has a real configuration dialog. All filters have a configure function by API requirement, it may just return 1 and do nothing.

Quote from: eumagga0x2a on March 01, 2021, 10:53:19 PM

Quote from: butterw on March 01, 2021, 10:16:38 PMA normal font with monospace digits would be more readable.

From purely utilitarian POV, probably yes, but this solution has a benefit of maximally reducing flicker and provides a reference to physical world (thinking about digital recorders with such displays). A "normal" fixed width font looks somewhat inconsistent and usually has a zero with a central slash or dot, very helpful for coding but alien to normal users. Already tried that.

I can see your point. At first I found the font weird but somehow cool.
Now, after days of using Avidemux it got worse - I noticed that for me is quite difficult to read it (to recognize the time) and I would appreciate "normal" monospaced font much more.

I looked for monospaced font on my system and there are couple of them with GNU or SIL Open Font License.
From these fonts I like the Noto Mono the most, it has very good readability in my opinion (and its size is 108kB).

I changed files ADM7SEG.* in avidemux2/avidemux/qt4/ADM_userInterfaces/ADM_gui/fonts/with font NotoMono-Regular.ttf (I created SFD file in Font Forge) and I an happy with the result (you can see screenshot in the attachment).
It would be great if other users have an option to change the LCD font without compilation from source.

At very small font sizes and with the fallback Qt style (i.e. "windows" instead of "fusion") the LCD font becomes indeed difficult to read. Below two screenshots as attachments – how it is supposed to look (how I see it on my desktop, Cantarell 11 pt + fusion Qt style) and how it looks with DejaVu Sans 10 pt + windows Qt style.

Readable:
You cannot view this attachment.

Not so much:
You cannot view this attachment.

You managed to find some very old or modified version of the font. The modern Noto Sans Mono, provided by some Linux distributions (however not by default), is very different. Old or new, it looks out of place at larger font sizes for me (the big reason I looked for a concept which would justify the font looking different).

Glad you found a solution for you, but I would politely ask you to rename the font (simple find and replace does the trick) if you redistribute it.

Memory leak wasn't avidemux issue. Other time torrent client brings same issue until get restarted. Seems reason is custom Windows tweaks for performance or memory got bad sectors.

Quote from: eumagga0x2a on March 21, 2021, 12:53:26 PMAt very small font sizes and with the fallback Qt style (i.e. "windows" instead of "fusion") the LCD font becomes indeed difficult to read.

For me is the LCD font always difficult to read - for example number 4 looks quite different from "normal" 4 etc. Even 0 broken into pieces... It is very different from everything I can see on my desktop and this is probably the reason of bad readability.

Quote from: eumagga0x2a on March 21, 2021, 01:18:29 PMYou managed to find some very old or modified version of the font. The modern Noto Sans Mono, provided by some Linux distributions (however not by default), is very different.

I can not agree. I do not know how or when I got the NotoMono-Regular.ttf font so I tried to download it from 2 sites:
https://www.fontsquirrel.com/fonts/noto-mono
https://www.google.com/get/noto/#mono-mono
and did md5sum check - two downloaded files are exactly the same as the one I found in my system so I consider it as up-to-date.

Quote from: eumagga0x2a on March 21, 2021, 12:53:26 PMOld or new, it looks out of place at larger font sizes for me (the big reason I looked for a concept which would justify the font looking different).

It might be about difference between chosen system font and the time font in Avidemux. My default font "Sans regular" looks very similar to the NotoMono-Regular.ttf so it is OK for me.
How difficult it would be to give users a setting in Preferences, where everyone could choose their preferred font for the time field?
Dealing with Qt5 on my computer to be able to compile Avidemux took me a half a day and for most users is their own compilation just "mission impossible".

Quote from: eumagga0x2a on March 21, 2021, 12:53:26 PMGlad you found a solution for you, but I would politely ask you to rename the font (simple find and replace does the trick) if you redistribute it.

Good point. I just did what was the easiest way to fix what made my Avidemux using difficult (without necessity to change actual source code).
I have no intention to spread my compiled Avidemux (well, maybe except my girlfriend's computer). But if I wanted to share my compiled version with someone else, I'll do it in the proper way as you mentioned.

Quote from: signy13 on March 22, 2021, 06:00:36 AMNotoMono-Regular.ttf font

Language Support is good but at now most optimal font is Roboto.
- Comes from android to windows,
- Have good look if small,
- Many where used also for subtitles,
- Used by popular streams like YouTube.