Avidemux Forum

Quote from: roadhazard on October 28, 2026, 01:11:00 AMI don't know if I'm allowed to post it here but if I can, I'll gladly share it with the world. To me, this makes Avidemux 1000x better.

If you're not posting links to alternatives to Avidemux (bad form), and there are no potential licensing issues with anything you post, it really should not be an issue.

I would be interested in seeing the steps you use to get AI making subs.

I use https://sourceforge.net/projects/subtitle-workshop-classic/ which offers a lot of options but is complex to get use to it.  You can move timeings by just seeing the audio waveform which is often good for spotting start of dialog.  You also get warnings when the number of words exceed maximum average reading speed. It's easier to let some long sub lines extend into silence and it's easy to spot when the scene changes.  However, of course this is a lot of work to make a high quality subtitle or fix an existing one. I've noticed that a lot of .ass files fail to load because they are missing a leading 0. in the timing on each line.  Maybe the new version is better. Such .ass files can be fairly easily fixed with a text editor search replace.

I don't understand why you want to edit media that has srt subs.  Are you just removing ads?  I can see why removing a brand promo at the start can require a timing change for every sub, but you can do that pretty easily at: https://subtitletools.com/subtitle-sync-shifter
I use that all the time to fix timings.

As we all know, Avidemux is the best tool ever for easy and laser sharp cutting of MKV files. It's dead simple to use and does an excellent job of cutting. For years and years and years, I've been looking for a program that was as good as Avidemux with cutting -BUT- was able to retain/re-index SRT embedded subtitles.

I tried lots of MKV editors and Clever FFmpeg-GUI was the closet to what I needed but it's GUI (for whatever reason) seems backwards to me, it made my head hurt using it. I eventually gave up on my quest and forgot all about this journey ... until yesterday.

I had my brother use Claude to generate some helper files that would let you save your project file after cutting a video and take that .py file, the original MKV and the saved/cut MKV and would do some AI magic and presto chango, spit out a finished MKV, WITH SUBS, that are perfectly in sync with all the cuts you did!

I don't know if I'm allowed to post it here but if I can, I'll gladly share it with the world. To me, this makes Avidemux 1000x better.

Loving AI for stuff like this! My brother, nor myself, are developers but I'm really good at writing prompts.

Quote from: JanMeki on October 27, 2026, 02:31:41 PMIt says Display: RGB on the status bar.

This means that VDPAU display is not available.

Quote from: JanMeki on October 27, 2026, 02:31:41 PMDon't know why the intel decoder is not detected

Probably due to mismatch between the build and the host environment or due to another reason – please redirect stdout and stderr of appImage to a file and attach it to your reply here or post it on some pastebin equivalent as far as that service doesn't require login.

./relative/path/to/appImage 2>&1 | tee path/to/admlog.txt
Please replace paths containing personally identifiable information in a consistent way with placeholders prior to uploading the log.

Quote from: JanMeki on October 27, 2026, 02:31:41 PMEdit: Seems like Xvideo is the only video display mode that doesn't stretch the video frame. Is that the best one to use in my situation?

Yes, sure.

Quote from: JanMeki on October 27, 2026, 02:31:41 PMShould I use hw acceleration with that one?

As long as a closed-loop hw accel (libva hw decoder + libva display or VDPAU decoder + VDPAU display) is not available, NVDEC will always be beneficial. Therefore yes, use NVDEC then.

Quote from: JanMeki on October 27, 2026, 02:31:41 PMOpenGL makes the avidemux ui unusable (garbled) so that's out of the question.

Could you please eventually do build Avidemux locally to have a clear picture of what works and what doesn't?

I've been using video display: vdpau under display in the settings and nvdec under hw accel because it's the only one available (vdpau and libva are grayed out). It says Display: RGB on the status bar. Don't know why the intel decoder is not detected (I can use it in smplayer). This is on Skylake / Maxwell so there is no VP9 decoder and only the iGPU does h265 Main decoding. Maybe it's better to have hw acceleration off instead if multithreading is beneficial for VP9, h265 adn AV1? What are the optimal settings for my situation?

I don't see any difference capping the refresh rate of the gui. I feel like the scaling thing is the problem because if I use zoom 2:1 it plays in slomo and for every 1 sec the video is late by another 3000 ms.

Edit: Seems like Xvideo is the only video display mode that doesn't stretch the video frame. Is that the best one to use in my situation? Should I use hw acceleration with that one? OpenGL makes the avidemux ui unusable (garbled) so that's out of the question.

Quote from: JanMeki on October 25, 2026, 11:44:21 AM

Code Select Expand

/tmp/.mount_AvidemmePfkG/usr/bin/avidemux3_portable: symbol lookup error: /tmp/.mount_AvidemmePfkG/usr/lib/libgobject-2.0.so.0: undefined symbol: g_sort_array
/home/abc

My best bet would be recommending you to build Avidemux from source locally on your system (which is very easy on Linux, see github.com/mean00/avidemux2) so that libraries included into the appImage don't clash with system libraries.

You don't need to package and install Avidemux to run it, it can be excuted via a wrapper script (all explained in the README).

If the Avidemux window can't fit into the available screen real estate, Qt may distort the frame used to draw the video at least with the unaccelerated "Qt" video display if I am not mistaken. Avidemux won't add scroll bars to video frame, selecting zoom level too high will at least try to push parts of the GUI out of sight. If your (presumably) laptop has a high-density display, you might also consider disabling automatic HighDPI scaling in Qt, e.g. by setting the env var QT_SCALE_FACTOR to 1:

QT_SCALE_FACTOR=1 ./relative/path/to/Avidemux-x86_64_20261018_legacy.AppImage

Make sure you use an accelerated video display in Avidemux, i.e. NOT "Qt" / "RGB", preferably VDPAU (but with the graphics wired to Intel this might not work), OpenGL / QtGl or XVideo, else all the scaling work is done on the CPU. The best options are to use VDPAU hw decoder with VDPAU display or LibVA decoder with LibVA display (whatever works). If NVDEC is used, it always downloads decoded pictures to the main memory that need to be re-uploaded to the graphics card for display. This may still be beneficial, but not as efficient as it can be.

Another huge cause of lag can be the status bar itself, especially at 60 fps. Try hiding it via the "View" menü or restrict refresh rate of the GUI in Avidemux Preferences to a lower value e.g. by enabling the cap and setting the redraw interval to 20 ms (1000/20 = 50 fps) or higher.

Already when playing 1080p60 videos (h264) I'm getting this problem sometimes. It may have something to do with scaling, because when I use a zoom level of 1:4 or 1:2 I never get the issue but already when using fit to window (65%), 1:1 or 2:1 I'm getting major A/V desync. When opening a 1920x1080 video the zoom level is 69% but if I change it to fit to window, which is 65% I'm getting desync again. I've tried with and without hw acceleration enabled (nvdec). I'm not maxing my hardware, I've got plenty of CPU, dGPU, iGPU left.

Usage:
CPU: 15%
iGPU (Render/3D): 35%
dGPU (if used): ~5%

I can play 4k60 h264 videos fine with smplayer/mpv.

Linux Mint 22.3
Avidemux-x86_64_20261018_legacy.AppImage, Avidemux-x86_64_20260516_legacy.AppImage, ...
Intel/nVidia Optimus
1920x1080 display

If I set the zoom to 1:1 when viewing a video it stretches the video instead of zooming it (it fills the viewing area with a wrong aspect ratio). 1080p video on 1920x1080 screen. Fit to window is 65% zoom and correct AR.

Linux Mint 22.3
Avidemux-x86_64_20261018_legacy.AppImage