Feature Request: x86 version of 3.x

[dlasher]

While it's beautiful to get 2x2 or 3x3 displays working on a PI, there comes a point where the pi horsepower (even the pi4) runs out. Especially now that rpisurv 3.x requires VLC (instead of OMXplayer) it would be nice to be able to install/run it on a x86 machine.

Any interest/plans/etc in providing a wrapper of some sort/etc that would make rpisurv3 install/run on a x86 linux distro? (debian 11, ubuntu 20 etc?)

Thanks

[CronoBandit]

@dlasher While I am not the maintainer nor a code contributor for rpisurv, I can offer some insight as to why porting rpisurv to an x86 platform is not realistic in effort. It will largely take a complete re-write/re-approach, and there is quite simply another (easier) way. The main reason why is “MMAL” : The Pi has a GPU with proprietery hardware video hooks, aka a hardware API called MMAL. It has this capability to overcome the exact issues your are referring too - horsepower. By using the hardware API, it unburdens the Pi’s CPU, thus making it way more capable. In fact, I have 9 low-def CCTV feeds running from my Pi4 right now, and it’s not even breaking a sweat! CPU is hovering around 8-10% and load averages around 0.4. That’s impressive. So I’m not sure what you are reffering too, as the Pi running out of horsepower. Yet anyways, let’s continue . . . So, the 1st video renderer to “tap” into this API was omxplayer (exclusive for the Pi platform). Other than the tremendous performance boost, the really cool thing about this mmal API, was the feature to use literal screen coordinates X/Y to deliberately position video, which is key in tiling multiple video streams. Fast-forward today… omxplayer is phased-out and vlc is the replacement. This was only possible, once mmal was finally compiled directly into the vlc debian package for 32-bit Pi distros-only, as normally vlc’s default API can’t “see” down to the hardware/GPU on Pis nor x86 platforms - and that is the point of the problem with porting this to x86. vlc on regular x86 Linux distros obviously won’t have mmal compiled in, why should they, as it only exists for Pi systems, so one cannot pinpoint multiple video sources to specific regions of the screen, nor take advantage of hardware acceleration. Rpisurv heavily leverages the mmal calls, thus can’t be ported as-is to x86. I’ll stop-short of saying porting to x86 is impossible, but why do it when there is no need to fill. This is because vlc can already do this type of multi-feed tiling on x86 systems, and it’s already built-in. It’s called the “mosaic” overlay feature. vlc has the built-in ability to create a virtual screen (which you match to your physical screen), then tile (overlay) multiple sources/feeds into this virtual screen. It’s actually quite trivial to configure, simply by authoring a text conf file for vlc. That said, and while vlc’s mosiac feature is a great way to bypass hardware API screen coordinates, it does not utilize hardware acceleration - but that’s okay, because you’d be using a more power x86 system now. So while rpisurv won’t be able to port over to x86 “as-is”, you can certainly leverage vlc’s native mosiac to achieve the same results on x86. And if anyone is wondering if vlc mosiac works on Pi – it does not. Besides, mmal already gives you everything needed, plus HW acceleration, so just stick with rpisurv. Side-note: Since the release of the Bullseye distro, it recently broke the “tvservice” portion of rpisurv thus broke rpisurv. So the maintainer of rpisurv suggests you stick with Buster for now. That said, I have discovered that Bullseye can indeed work with one simple edit in /boot/config.txt aka switch (back) to the fkms API. See my posts in Issue 143 & 141 for more details.

[dlasher]

@CronoBandit : Thanks for sharing such a detailed response. I absolutely understand the high level of dependence upon MMAL/OMXplayer as RPISurv exists today. Before MMAL, using anything but OMXPlayer was considered impossible.

All the issues you bring up, are why I think having a version of rpisurv for x86 would be fantastic. It's already been proved that the project (rpisurv) can pivot from OMX to VLC, so IMHO the hardware dependency on the PI is mostly worked away from. Start VLC w/o MMAL, using Mosaic config if you're on x86, and you keep the rest of the nifty wrapper that RPISurv is, alive and well. (FWIW I spent the better part of a week trying to get mosaic to work in VLC, and gave up with nothing functional, and I'm moderately competent in this space. Having a wrapper like RPISurv build the config, wrap VLC, would be pretty awesome.)

Oh, and to make things MORE fun, default VLC packaged with Debian/Ubuntu distros won't play RTSP any more (https://askubuntu.com/questions/1359032/can-not-play-rtsp-streams-with-linux) -- which would make it all the harder for people to figure out how to get a solution based on VLC working on their own. (snap vlc ftw).

Also, working around the memory challenges of the PI's can be a real pain, especially when you start playing with 4k cameras (sub streams or not). Being able to purpose build a GPU/CPU solution that could handle better sources, and still use RPISurv, would be awesome.

[SvenVD]

Firstly, Rpisurv can do more than vlc mosaic, cycle between preconfigured screens for example, among others, like a being handy wrapper. Secondly Rpisurv porting to x86 is for sure doable, however,

• Rpisurv has a caching mechanism to show the next screen in a cycle so they will be displayed almost immediately instead of waiting for them to connect, this, among other things, like manipulating coordinates makes use of very specific raspberry pi-only routines.
• Rpisurv can also display images, this is currently only tested with the pygame version shipped with raspbian.
• The devil is in the details, Rpisurv has a lot of options which can be combined and currently no automated test setup so a change here and there is already quite some testing effort, let alone changing the whole thing to x86 will increase the testing work since the low level elements would be different. An option is off course to start the x86 version with a minimal viable version and then add the options as we go.

But finally the most important reason is that Rpisurv doesn't have a whole developer team to develop and test this. This is largely an effort in my free time (which is scarce nowadays), so I want to keep the maintenance doable. More platforms = more issues, more testing (x86 and raspberry version). So as long as the raspberry pi platform suits my needs, I will not put a high priority on the x86 version personally :-) (but open for pull requests, and maintainers which will dedicate in maintaining the x86 version).

[dlasher]

Fair enough, and solid answer - thank you!

[CronoBandit]

@dlasher Thank you for highlighting that Debian's vlc (apt package) is currently broke for RTSP (I was not yet aware). Just trying it on my pop-os box - yup, no workie-workie. Sad, it seems there is some potential copyright violations "in question", so the act to remove it was deliberate, as Debian doesn't want to compile vlc with live555 support as of this typing.

Now... it could get fixed- if the maintainers of live555 resolve this soon. I bet some of it is original Real Time code ... yet they went under so long ago, that code should be public domain - yes?? RTSP is EVERYWHERE ... that's going to make a ton of folks unhappy. I digress. And staying on-topic here ... call this a prediction ... if the x86_64 package no long has it, it's just a matter of time before the vlc package in the ARM (Pi) repository removes it as well - which will affect rpisurv no doubt.

I tried compiling vlc from source on my tower - got too many env issues, so went for "easy" and just blew-in the vlc flatpak - works fine. Oh, and I just re-tested my mosaic.conf file - that works too (side-channel if interested).

[dlasher]

@CronoBandit :

Oh, and I just re-tested my mosaic.conf file - that works too (side-channel if interested).

Would appreciate a share - thanks for the offer.