Avidemux Forum

250524 nightly, Intel av1 still not working (first frame only in resulting file). Maybe focus was on fixing libaom preview first, anyway just reporting.

https://paste.debian.net/hidden/3ad9f243/

I can confirm 250524 nightly completes libaom av1 + resize with no errors, intel av1 still not working, log in the other thread.

For constant bitrate I'm able to get a significantly better looking image out of OBS in real-time, whereas when using Avidemux it is below real-time and the quality is worse.  I'm using an RTX 5090, which has 3 NVENC chips, and I believe it is only using one.  Is this true, and if so are there any plans to change that?

Quote from: eumagga0x2a on May 23, 2025, 04:37:31 PMIf I recall correctly, the handling of files (not just MP4) with insanely high timebase denominator like those produced by VLC is still unchanged, i. e. Avidemux replaces it with 90 kHz and fails to export in copy mode due to decode timestamp collisions. Re-encoding such streams with "Resample FPS" filter inserted into the filter chain should work at the cost of quality loss.

Anyway, r241212 or the latest VC++ nightly (the latter for those who don't need AV1 decoding support without an AV1 hw decoder) is a better choice than 2.8.1 release by far.

But if I do what I've been doing, there's no need to reencode. It just means I have to take the extra step of exporting it in MKV (copy mode), then exporting the resulting MKV in copy mode as an MP4.

Am I to take it that what I'm doing shouldn't be working the way that it does? It sounds like you're saying that videos produced by VLC will have timestamp issues regardless of export format, but that is not true in my experience. They export fine in MKV.

Quote from: sark on May 23, 2025, 09:11:26 AMWhich version of AVD are you using?

The latest version (x64) is 2.8.2 r241212 (I'm assuming you're on Windows).
If you are using an older version, as per the confusing main Avidemux page download link, I would first advise to update from below.

https://www.avidemux.org/nightly/win64/

2.8.1.

If I recall correctly, the handling of files (not just MP4) with insanely high timebase denominator like those produced by VLC is still unchanged, i. e. Avidemux replaces it with 90 kHz and fails to export in copy mode due to decode timestamp collisions. Re-encoding such streams with "Resample FPS" filter inserted into the filter chain should work at the cost of quality loss.

Anyway, r241212 or the latest VC++ nightly (the latter for those who don't need AV1 decoding support without an AV1 hw decoder) is a better choice than 2.8.1 release by far.

Which version of AVD are you using?

The latest version (x64) is 2.8.2 r241212 (I'm assuming you're on Windows).
If you are using an older version, as per the confusing main Avidemux page download link, I would first advise to update from below.

https://www.avidemux.org/nightly/win64/

So I get the timestamp error when trying to export in copy mode some of my videos that I've edited as MP4. From what little I've read, it seems this issue is caused by VLC (which is how I trimmed videos prior to learning about Avidemux).

So what I do is export them as MKV instead. 95% of the videos that have issues exporting as MP4 export fine as MKV. But because I don't like working with non-MP4 if I can avoid it (MKVs have caused thumbnailing issues in the past), I just take that MKV and export it again as MP4. 90% of those cases export fine as well.

I don't really need to know why this workaround works (it would probably just confuse me to be honest), I just need to know that it really does work, isn't creating issues that I wouldn't notice at first glance, and won't cause problems down the road. And that's why I'm here.

This was a hilariously stupid snafu: packaging a stock, ancient libaom from Debian while building against a recent libaom in /usr/local. Should be fixed now, solving the problem with crashes. Please try a future nightly. I'm sorry for inconvenience.

However, the OpenGL breakage in appImage is real, please make sure OpenGL is disabled.

May be a long shot here, but I'll take a shot.

I am running portainer on a Synology 1823xs+

I have created a stack for avidemux and everything works fine as far as video playback but the audio does not playback. I get the error "Trouble initializing audio device" My compose looks like this:

version: "3"
services:
  avidemux:
    image: jlesage/avidemux
    ports:
      - 5700:5800
    volumes:
      - /volume1/docker:/config:rw
      - /volume1/docker/avidemux/test:/storage:rw
    environment:
      - DARK_MODE=1
When I try to add

- /dev/snd:/dev/snd
I get the error

Bind mount failed: '/dev/snd' does not exist
Can anyone tell me if there is different location for the sound device in my Synology or if there is another step I need to take to get the container use the sound device? Thank you