Adding `! vah264enc ! vah264dec` to pipeline introduces weird artifacts

Application Development
1

I’ve only recently begun learning to use gstreamer. A few days ago I was able to get the following two pipelines connected over the network:

gst-launch-1.0 -v videotestsrc ! "video/x-raw, width=(int)1920, height=(int)1080, framerate=(fraction)30/1" ! x264enc ! h264parse ! rtph264pay ! udpsink host=127.0.0.1 port=5002

and

gst-launch-1.0 -v udpsrc port=5002 caps="application/x-rtp" ! rtph264depay ! parsebin ! vah264dec ! videoconvert ! videoscale ! xvimagesink

(I was using these to prototype the concept for an idea i want to apply in my own application)

Yesterday I upgraded my gstreamer Arch packages from 1.22.7 to 1.22.8, after which I began seeing scan line like artifacts (not sure if that’s the right terminology) in the output when i include ! vah264enc ! vah64dec as in the following simplified example:

gst-launch-1.0 -v videotestsrc ! "video/x-raw, width=(int)1920, height=(int)1080, framerate=(fraction)60/1" ! vah264enc ! vah264dec ! queue ! xvimagesink

(removing the ! vah264enc ! vah264dec from this removes the scan line artifacts).

Here is a screenshot demonstrating the scan line artifacts I am talking about:

2023-12-22-161349_7680x2160_scrot
2023-12-22-161349_7680x2160_scrot1920×540 160 KB

I’m wondering if anyone can point me in the direction of a troubleshooting approach to figure out what’s going on? For what it’s worth I’ve already tried downgrading the gstreamer packages back to the previous 1.22.7-1 Arch package and the problem seems to persist.

I also filed a bug report on the git repo with slightly different details from what I’ve mentioned here: vah264enc/vah264dec after recent upgrade to 1.22.8 from 1.22.7 (#3195) · Issues · GStreamer / gstreamer · GitLab

2

Okay it looks like the problem isn’t in any of the gstreamer packages but in one of the mesa packages that were upgraded alongside the gstreamer packages on my system: mesa lib32-mesa libva-mesa-driver mesa-vdpau

I was able to solve the issue on my system by adding these packages to the IgnorePkg list in /etc/pacman.conf and manually downgrade them to the previous version in my package cache, eg

pacman -U /var/cache/pacman/pkg/lib32-mesa-1:23.2.1-2-x86_64.pkg.tar.zst /var/cache/pacman/pkg/lib32-vulkan-radeon-1:23.2.1-2-x86_64.pkg.tar.zst /var/cache/pacman/pkg/libva-mesa-driver-1:23.2.1-2-x86_64.pkg.tar.zst /var/cache/pacman/pkg/mesa-1:23.2.1-2-x86_64.pkg.tar.zst /var/cache/pacman/pkg/mesa-vdpau-1:23.2.1-2-x86_64.pkg.tar.zst /var/cache/pacman/pkg/vulkan-radeon-1:23.2.1-2-x86_64.pkg.tar.zst

After doing this the weird visual artifact I describe here no longer shows up.

According to someone on gitlab there is a set of fixes targeting the gstreamer 1.22 branch that may address the issue: Backport of "va: fixes for Mesa driver" into 1.22 (!5778) · Merge requests · GStreamer / gstreamer · GitLab