Incorrect colours on Raspberry Pi 4, -avdec is faster than hardware decoding

[connorh315]

Receiver device running UxPlay: Raspberry Pi 4 Sender: iPad Pro (M1) | iPhone 15 Pro OS Version: Most recent Raspberry Pi OS (64-bit) with Desktop - "Debian GNU/Linux 12 (bookworm)" - released 2024-07-04 GStreamer version - 1.22.0 UxPlay version: 1.69 Launch command: ./uxplay -p -d Videosink: any

My Raspberry Pi 4 is not showing certain colours from the Airplay stream. It is the exact same as the issue described here: #313. The only difference is that I know it cannot be the sender device not sending the correct colours as the stream looks perfect on my Windows machine running UxPlay. As such I can only assume that it is a Linux GStreamer issue. I have tried xvimagesink, ximagesink and glimagesink and they don't make a difference. Just as some additional information, -avdec produces a smoother stream than hardware decoding on all the videosinks which is odd. I have reinstalled the Raspberry Pi OS twice now to check and used on two different Raspberry Pi 4 boards

This is not an issue with the sender device sending poor streams, as my UxPlay instance running on Windows does not have the same colour issues.

[fduncanh]

I see it.

seems OK on linux, but the red seems brown and the blue is less bright on r pi.

https://www.youtube.com/watch?v=lnrJASmgHBM

[connorh315]

There seems to be a big issue with greys as well, some greys just do not show up at all and instead are rendered as white only. I'll try and grab a screenshot in a bit.

[fduncanh]

I compared the above image on R Pi with (side by side) (1) the image shown on firefox on R Pi. (2) the image on uxplay on R Pi, transmitted from the screen if an iPad showing it.

on RPi firefox and UxPlay seem to have identical colors so it seems to be a R Pi issue, not UxPlay ? please do this test for yourself and report what you see.

[fduncanh]

please find a link to a greyscale image on web, that the viewing-side-by-side-on-browser-and-uxplay test can be done on.

[fduncanh]

is this a fix?

https://forums.raspberrypi.com/viewtopic.php?t=304842

EDIT: I did this but am not sure if it changes anything?

[connorh315]

I tried that one already and I don't think it made any improvements either :(

[fduncanh]

In any case since uxplay and firefox show identical colors (do you agree?) , its not a uxplay or gstreamer problem.

There should be a fix to be found out there on the web?

[connorh315]

Definitely, will close this - Once I've found a solution I'll post it here.

[connorh315]

Sorry, might've prematurely closed this, please see attached image; It shows a screenshot of the iPad screen, compared against the actual UxPlay stream:

--Photo removed--

You can see the difference is mainly with greys being off, or just converted to white?

[connorh315]

Attached here is the UxPlay stream as seen from a Windows PC, showing that the correct colours are being sent by the sender:

--Photo removed--

[fduncanh]

I see the grey issue. so that is uxplay/gstreamer.

what about the color issue?

[connorh315]

Sorry I hope that I didn't come across like it was a vibrant colour issue, I meant that the grey "colour" was showing up as white. I probably should've put a reference image there 😬

[fduncanh]

Can you find a link to or post an appropriate test image for the grey issue? thanks.

(Something that is easy to display on the iPad screen with a standard app, preferably a browser.)

[connorh315]

If you go to this website, the hero banner at the top has the colours #ffffff and #f5f5f5 right in the middle and the two colours show up as white despite one being a grey. Additionally, I have noticed that the colours on this site too are all displaying as white, despite the fact that some of them are actually a light-green or a light-blue

[connorh315]

Issue also exists on Ubuntu Desktop for Raspberry Pi 4, running GStreamer version 1.24.x (can't remember minor revision)

[connorh315]

Just for reference, using -vdmp and dumping the h264 stream, I can replay it in VLC on the same raspberry pi and the grey colour shows fine.

[fduncanh]

@connorh315 great investigating! this is exactly the type of info needed!

for uxplay, we need to know if the problem is the same with -avdec and -v4l2. as these are two different image rendering engines (-avdec in software, -v4l2 in RPI4 hardware)

[connorh315]

@fduncanh issue occurs with both -v4l2 and -avdec. For reference as well, I've also tried replaying the h264 dump with this command just here: gst-launch-1.0 filesrc location=videodump.h264 ! h264parse ! decodebin ! xvimagesink. This pipeline is as simple as it gets and yet still the same issue occurs. Changing the videosink to glimagesink has no impact either.

[fduncanh]

Does the videodump.h264 look OK with e.g vlc?

what about with Gstreamer on Linux on a desktop machine x86_64 etc.

I assume its R Pi specific?

is the videodump file able to be made public?

That way one can post an issue to GStreamer developers.

[connorh315]

Does the videodump.h264 look OK with e.g vlc?

Yes looks absolutely fine when played back with VLC

what about with Gstreamer on Linux on a desktop machine x86_64 etc.

Actually the same issue exists on a x86_64 machine! The machine I've just tried on is an Ubuntu 24.04.1 install running on a Lenovo laptop. It has GStreamer 1.24.2 as default.

I assume its R Pi specific?

I think so. Again will test in a second. As just discovered, same issues exists on the Ubuntu machine.

is the videodump file able to be made public?

Yes: videodump.h264.zip (It had to be .zip, I couldn't upload a raw .h264 file as it wasn't in GitHub's whitelist)