The VideoLAN Forums

fix: Apparently video output module must be set to XBC instead of VDPAU output.

The default VLC 3.0.9 of Linux Mint 20.1 has a bug that seems to swap all even and odd scanlines in low resolution video files (downloaded from Youtube), which looks ugly and makes small text unreadable. I am using KDE5 Plasma on AMD Ryzen 2400G (Vega graphics, output through HDMI2VGA adapter on CRT monitor) with recent amdgpu driver 21.20.

(I would include a screenshot example, but don't know how to upload a photo here.)

The bug also happens with other graphics driver versions. It swaps scanlines only on screen but not in the video snapshot PNG saved with VLC itself. Temporary I had tried out VLC 3.0.16 from a PPA (made same bug?), but had to uninstall it because it corrupts converted video files. The bug does not happen on my laptop Thinkpad X61t (Intel Core2Duo 1.6GHz with Intel graphics, 4GB RAM, 160GB HDD, wifi removed) with Win10 (old version) and VLC 3.0.6.

I use VLC mainly for playing downloaded video files and converting them to lower resolutions (often 240p). I do not use the streaming features.

I typically use these conversion parameters:

Encapsulation: MP4/MOV
Video Codec: H-264 (with custom bitrate and height set)
Audio Codec: MP3 (44100 Hz, custom bitrate)

As a collector and hardware researcher of music keyboards and soundtoys, for reference I keep on my harddisk tons of downloaded youtube tech info and tutorial videos. Hence I need VLC for quick sighting and conversion (file size reduction). Yet I used this this on my main PC (Colani bigtower), but because the highend Win98SE machine (AMD K6-3@550MHz, 768MB RAM) became completely overloaded with this work (160GB harddrive full to the brim and FAT32 too slow), I installed an additional modern ITX mainboard with AMD 2400G, 16GB RAM and 8TB harddrive running Linux Mint.

Without logs, nobody can say for sure, but it sounds like a bug in display drivers.

The scanline swap has the width of the played low resolution video, not the much thinner scanlines of the linux graphics mode (using 1280x1024 on a 22'' Trinitron CRT).

This is the debug log from the "Meldungen" window when playing a video. The full debug log (mode 2) is too huge (>1600 lines) and gets refused by this forum.

This seems to be the scaler when playing a 360p H264 video:
At the end there is this stuff. I suspect that it is an upscaling bug happening after decoding the original resolution video. Debug log in mode 1 (warnings) looks like this:

Well, this just confirms that the bugged deinterlacing algorithm is provided by your display driver. You will need to turn hardware decoding acceleration off.

Disabling hardware decoding in the Eingang/Videocodecs/FFmpeg setting does not change it at all. I suspect that the screen stretch algorithm by the display manager might be faulty, but in KDE5 Plasma and Cinnamon they look the same. The vertically alternating stripes of partially wrong scanlines look a bit like a terribly coarse ancient dithering attempt to save computing time (likely a Pentium 2 could do that better). Celluloid plays the same 360p video without any stripes (i.e. text is much better readable). But even when the video is set to 100% size it has swapped scanlines. The fact that a video screenshot by VLC itself is flawless proves that the bug must be in the postprocessing.

Is there a mode to let VLC itself stretch the output to the window size in pure software without any use of hardware or display manager acceleration? Or may it be that deinterlacing gets falsely activated despite the video is not interlaced?

I have switched the video output module from VDPAU to xVideo output (XBC) now, which seems to fix the scanline swap.