Using `rpi` Options Make the Experience Worse

[monomycelium]

I have rebuilt UxPlay for the Video4Linux2 plugin patches. When I used the rpi options on my Raspberry Pi 4 (uxplay -rpifb when LightDM was turned off and uxplay -rpi when PIXEL was running), the screen mirroring seemed laggier than when I did not use the options. This is fine with me since not using the rpi options already gives me descent performance, except that I cannot have the screen mirroring window in fullscreen mode, which, as much as I know, can only be done using the rpifb option. Should I have installed other plugins for the Video4Linux2 plugin?

[This was originally posted on Discussions at #108.]

[fduncanh]

which OS are you using (RaspberryPi OS, Ubuntu, Manjaro, etc)? I'm not sure what happens when "LightDM is turned off"

The key to non-laggy performance on raspberry pi is to use hardware h264 decoding by the broadcom GPU on the Pi. This needs the video4linux2 gstreamer plugin, and the bcm2835-codec kernel module.

In the latest UxPlay 1.54 I dont think that uxplay without -rpi or -v4l2 options will work any more, because video4linux2 (v4l2) needs a "workaround" (change colorimetry =1:3:5:1 to the closest color scheme that v4l2 currently recognizes, 2:3:5:1=bt709). This is because v4l2 doesn't currently recognize 1:3:5:1 colorscheme which Apple is using.

"bt709" is an international standard for digital TV. Apple's 1:3:5:1 is a modified bt709 with a wider color range. I guess that since AirPlay was designed only for proprietary AppleTV, they didnt think changing the standard was an issue. The gstreamer Video4Linux2 plugin currently looks in a list of well-known standards, and if the color scheme is not there, you are out of luck. I may manage to get 1:3:5:1 added to the list of known color standards in the gstreamer video4linux2 plugin.

in uxplay 1.51-1.53 the bt709 workaround is hard-coded and happens always, but it turned out to break GPU decoding on some non-Raspberry Pi systems with AMD Polaris graphics cards, so I had to move it back to the -rpi or -v4l2 options that only RPi users use. The video4linux2 plugin "v4l2h264dec " interfaces with the bcm2835-codec kernel module which accesses the broadcom firmware on the Pi for h264 video decoding in the GPU.

You can also get fullscreen mode with wayland graphics (currently Ubuntu 22.04, but I think RPi OS non-Lite has some "advanced users" ("beta") option for wayland ) uxplay -rpiwl -fs

You can see the video pipeline used immediately when uxplay starts with uxplay [options] -d -rpifb now (uxplay-1.54) is:

-vp "h264parse ! capsetter caps=\"video/x-h264, colorimetry=bt709\""         (default is h264parse)
-vd v4l2h264dec                                                              (default is decodebin)
-vc v4l2convert                                                              (default is videoconvert)
-vs kmssink                                                                  (default is autovideosink)

if you omit one of these options, you get the default. In principle you can design your own pipeline.

[fduncanh]

I just updated the github latest UxPlay to allow the "bt709" fix to be applied on its own, as an option -bt709

In RPi OS lite with framebuffer video

I get good performance on RPi model 4B with just "uxplay -bt709 -vs kmssink" with latest github, which will be the future uxplay 1.55

• in uxplay-1.55 you will need either -bt709 or one of the -rpi* options to use the R Pi GPU

No need to use the -v4l2 or -rpifb options. I guess gstreamer tries to figure out the best way by itself, and maybe the "v4l2convert" is best left as ".videoconvert" . Yes, maybe sometime you get better results without them, depending on your operating system and graphics setup.

Interestingly "uxplay -bt709" (without specifying a videosink) works but the colors are completely wrong (red becomes blue).

I will work on getting the colorspace 1:3:5:1 added to gstreamer and my patch sets so one will no longer have to use this bt709 workaround.

EDIT. Apple are using unusual "bt709 full-range" (linux 1:3:5:1) while the bt709 standard used in broadcast tv is "limited range" (linux 2:3:5:1). bt709 full range is unusual, because it's no good for broadcast TV, but allows deeper blacks and is brighter on computer monitors. Its annoying that Apple add this complication.....

[fduncanh]

@monomycelium thanks for the feedback. Its vital to get user feedback to keep improving this app.

[monomycelium]

I just updated the github latest UxPlay to allow the "bt709" fix to be applied on its own, as an option -bt709

In RPi OS lite with framebuffer video

I get good performance on RPi model 4B with just "uxplay -bt709 -vs kmssink" with latest github, which will be the future uxplay 1.55

• *in uxplay-1.55 you will need either -bt709 or one of the -rpi options to use the R Pi GPU**

No need to use the -v4l2 or -rpifb options. I guess gstreamer tries to figure out the best way by itself, and maybe the "v4l2convert" is best left as ".videoconvert" . Yes, maybe sometime you get better results without them, depending on your operating system and graphics setup.

Interestingly "uxplay -bt709" (without specifying a videosink) works but the colors are completely wrong (red becomes blue).

I will work on getting the colorspace 1:3:5:1 added to gstreamer and my patch sets so one will no longer have to use this bt709 workaround.

EDIT. Apple are using unusual "bt709 full-range" (linux 1:3:5:1) while the bt709 standard used in broadcast tv is "limited range" (linux 2:3:5:1). bt709 full range is unusual, because it's no good for broadcast TV, but allows deeper blacks and is brighter on computer monitors. Its annoying that Apple add this complication.....

I am not sure how I can upgrade to the newer version. Can you help me?

[fduncanh]

@monomycelium install git, then git clone http://github.com/FDH2/UxPlay

then follow the instructions in the README.

[monomycelium]

@monomycelium install git, then git clone http://github.com/FDH2/UxPlay

then follow the instructions in the README.

I built UxPlay a few weeks ago. Do I have to git pull and then build again to update?

[fduncanh]

yes "git pull" followed by "sudo make install" , both in the previous build directory, should work