Output video contains terrible glitches when x264, please help.

[catscarlet]

Some times the output video contains terrible glitches when x264. See in Attachment screenshot.

Version and platform:
Avidemux_2.8.1.appImpage on Linux Mint 20.3 Cinnamon (Based on Ubuntu 20.04)

Video Output Configure:
Mpeg4 AVC (x264)
Not using Advanced configuration.
Preset: slow
Encoding Mode: Average Bitrate (Two Pass) 3500 kbit/s

You cannot view this attachment.

You cannot view this attachment. 

Is there anything wrong in my setup? Or can I avoid this by change some setting?

[eumagga0x2a]

Some times the output video contains terrible glitches when x264.

In other words, the problem is specific to x264 encoder, i.e. videos encoded to HEVC with x265 or to VP9 with libvpx don't exhibit such artifacts, right? Because if they do, the problem is with the source video / with demuxer / with decoder, but not with the encoding phase of processing.

Does the latest available 2.8.2 nightly appImage from https://www.avidemux.org/nightly/appImage4Buster/ have the same issue? (I am not sure that it will run on such an outdated platform as an Ubuntu 20.04 derivative, but please try.)

[catscarlet]

Does the latest available 2.8.2 nightly appImage

I tested some videos with avidemuxLinux_GLIBC_2.28_amd64_230829_0442.appImage, and this issue didn't show up yet.

As I know 2.8.1 is using FFmpeg 4.4 and 2.8.2-nightly is using FFmpege 5.1, right? I'm not sure if it is related to the encoder.

I will keep using this nightly version and if this issue happens again, I will let you know.

(Also don't worry, Ubuntu 20.04 will still receive major support until May 2025 and most of major libs are supported, expect qt6 which makes almost all Linux distros suffers) (I just don't want to use Linux Mint 21/Ubuntu22.04 because that version causes some server issues and they kinda have no willing to fix them. I prefer to just jump from 20.04 lts to 24.04 lts)

[eumagga0x2a]

As I know 2.8.1 is using FFmpeg 4.4 and 2.8.2-nightly is using FFmpege 5.1, right?

Wrong, you must have picked a wrong appImage. The latest one (from 2023-08-29) uses FFmpeg 6.0.

Also don't worry, Ubuntu 20.04 will still receive major support until May 2025 and most of major libs are supported

Such ancient distributions are mostly stuck on old versions, especially bad for everything related to multimedia.

[catscarlet]

Wrong, you must have picked a wrong appImage. The latest one (from 2023-08-29) uses FFmpeg 6.0.

Well nowhere says what it is in avidemuxLinux_GLIBC_2.28_amd64_230829_0442.appImage. All I could find is github commits and it says FFmpeg 5 a lot after 2.8.1. Do you mean the  avidemuxLinux_GLIBC_2.28_amd64_230829_0442.app is not the The latest one (from 2023-08-29)

Such ancient distributions are mostly stuck on old versions, especially bad for everything related to multimedia.

What do you mean? The major problem that makes me not using the latest Ubuntu LTS, is MySQL 8.0, which is not fully supported by Ubuntu 22.04.

[eumagga0x2a]

Do you mean the  avidemuxLinux_GLIBC_2.28_amd64_230829_0442.app is not the The latest one (from 2023-08-29)

This appImage is indeed the latest official one, it uses (should use, unless the local source tree in the build node was greatly out of sync with the public repo) FFmpeg 6.0, this is why I assumed that you had picked an old appImage when you mentioned FFmpeg 5.1.

The switch to 6.0 happened on May 13 2023: https://github.com/mean00/avidemux2/commits/master/cmake/admFFmpegVersion.cmake

What do you mean? The major problem that makes me not using the latest Ubuntu LTS, is MySQL 8.0, which is not fully supported by Ubuntu 22.04.

I understand your dilemma, and mission-critical tasks justify staying at a LTS version, but in case of multimedia applications, very old versions of libs may pose a problem like libaom stuck at 1.0.0 instead of advancing to 3.7.x would render it unusable for Avidemux if you build the latter yourself.

[catscarlet]

Some times the output video contains terrible glitches when x264.

In other words, the problem is specific to x264 encoder, i.e. videos encoded to HEVC with x265 or to VP9 with libvpx don't exhibit such artifacts, right? Because if they do, the problem is with the source video / with demuxer / with decoder, but not with the encoding phase of processing.

Does the latest available 2.8.2 nightly appImage from https://www.avidemux.org/nightly/appImage4Buster/ have the same issue? (I am not sure that it will run on such an outdated platform as an Ubuntu 20.04 derivative, but please try.)

Well Today I encounter this issue again, with avidemuxLinux_GLIBC_2.28_amd64_230829_0442.appImage.

You cannot view this attachment.

TBH I don't think this is related to the Encoder: ffmpeg.

The preview also showed broken. Sorry I didn't take a screenshot because when I tried to change the setting, avidemux crashed.

I have a suspicion that it's the Decoder: VDPAU, but I don't have enough evidences.

You cannot view this attachment.

I'm using Linux Mint with
- CPU: Intel i7-4790K, the 4th Gen, Haswell.
- GPU: Nvidia GeForce GTX 1080. Driver Version: 535.113.01. CUDA Version: 12.2

Here is my Graphic Hardware info:

Graphics:  Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics
          vendor: Gigabyte driver: i915 v: kernel bus ID: 00:02.0 chip ID: 8086:0412
          Device-2: NVIDIA GP104 [GeForce GTX 1080] vendor: Gigabyte driver: nvidia v: 535.113.01
          bus ID: 05:00.0 chip ID: 10de:1b80
          Display: x11 server: X.Org 1.20.13 driver: modesetting,nvidia
          unloaded: fbdev,nouveau,vesa resolution: 1920x1080~60Hz
          OpenGL: renderer: NVIDIA GeForce GTX 1080/PCIe/SSE2 v: 4.6.0 NVIDIA 535.113.01
          direct render: Yes

Any ideas?

[eumagga0x2a]

If the video displayed in Avidemux exhibits the same artifacts, we may forget about encoders. It is probably just a damaged video, with different decoders using different strategies to cope with not cleanly decodable macroblocks.

Of course, testing with hw decoder switched from VDPAU to NVDEC as well as with hw decoder disabled completely is the obvious first thing to try.

In doubt, please provide a sample source video preferably via WeTransfer, Mega, Dropbox or Google Drive and specify the time offset of damaged frames I should look at.

[catscarlet]

It is probably just a damaged video

Dude what do you mean it's a damaged video. I recorded the video by using OBS with standard encoders. The previous videos are also created by various camera, phone, youtube-dl, ffmpeg-x264.

Also, re-encoding the same video won't reproduce the same issue, and that's why I'm asking here to understand does anyone else has encountered this. It just happens very randomly.

Here is the sample source video link via Mega Nz: /file/e1931A7Q#9Xhwkgp1HC2xrqcvkRCCZ6dPizhg1XVErFeaSAvN8Xg . Your forum is blocking mega so accomplish the link by your self. It's only 4 seconds. The damaged frame should be at about 02.553

[eumagga0x2a]

Cannot reproduce based on the provided sample using both the official nightly and an up-to-date local build, tested with VDPAU, NVDEC and hw accel. decoder disabled. Also tested on macOS with a local build, with hw decoder enabled and also with hw decoder disabled. All 240 pictures cleanly decoded, no visible artifacts whatsoever.

[catscarlet]

Cannot reproduce

That's why I say it happens randomly.

[eumagga0x2a]

I reloaded the sample quite a few times (which tears down and re-creates the decoder) and restarted Avidemux multiple times switching back and forth between different builds without the issue occurring.

Anything happening randomly with the same input means usually that uninitialized memory is used to evaluate some condition. Valgrind complains quite a lot about such memory errors in the closed-source NVIDIA driver. I never observed any artifacts from using NVIDIA hw accels myself, but nevertheless, please disable hw decoders (VDPAU, NVDEC wasn't enabled on your screenshot) and test whether it affects the reproducibility of the issue.

It would also help to use a sample which itself does not look like a glitch in the decoder :-)