VLC support

[sionglow]

Hi,

I was wondering how difficult it would be to port this to VLC instead of using OMX Player? I just discovered the file titles don't show up unless the format is AVI, and this appears to be an OMX player issue.

Thank you again.

[sionglow]

Or, perhaps an easier way would be to change the way the title is shown (currently as subtitles) by running another instance of omxplayer on a different layer on top of the video? I am not familiar at all so this is just a lot of research. I just want a text (preferably on the top corner) to overlay on the top of the video to show some information that changes from time to time. When we change the information, we can just restart pi_video_looper. I currently have it working already - I can FTP in to the USB drive, rename the file, and restart pi_video_looper, but this only works with .avi files.

[tofuSCHNITZEL]

this will become even more important since there is no omxplayer package for debian 11 (which is the dist for the latest raspberry pi os)
any help to add VLC as a player would be appreciated.

[tofuSCHNITZEL]

Hey @PaintYourDragon,
I saw you are working on a CVLC implementation - thats great! do you think we could change the install script in a way that it determines if omx and hello can be installed on the system if so omx, hello and cvlc are installed and if run on bullseye only cvlc is installed? we could leave then all the settings in the ini - and inform the user via the install script which players can be used on their system (and maybe build a little sanity check in the python side to display a nice error message if unsupported player is selected via ini)

[PaintYourDragon]

@tofuSCHNITZEL Hello! I was going to ping you at some point, or open an intentionally incomplete PR to get a discussion going, so thank you for reaching out proactively.

The Bullseye check (with different install behavior) sounds like a good plan. Could perhaps parse for the VERSION_ID string in /etc/os-release

To be honest, been bungling my way through this…coming at it from zero and the code’s a bit more complex than I anticipated. Just knew that this is among the top “problem feedback” guides in the Adafruit Learning System and I’d been tasked with fixing it. If you’d like, I could pass along my notes with getting cvlc running in Bullseye Lite (actually pretty minor, just needed to find the right combo)…and then if you’d be amenable to writing the .py file for it, I could work on rewriting parts of the guide. Would that work? I’d be less worried about my breaking something that way, as it seems you already know this through and through.

Thanks.

[tofuSCHNITZEL]

The Bullseye check (with different install behavior) sounds like a good plan. Could perhaps parse for the VERSION_ID string in /etc/os-release

yes lets do it this way. maybe we create two inis one for "legacy" and one for "current" and remove the options that are not working for each version (I assume cvlc will work on the legacy version)

Yes I can take care of the python part. I already tried to play around with getting cvlc to work - but it was never really working out so well but I see that you have already found some stuff to get it working.

if you want we can continue the work directly in the pb-bulseye branch and keep the discussion in here

[tofuSCHNITZEL]

@PaintYourDragon: I have pushed the updated install and ini. just reach out when you want to work on the cvlc launch part.

[tofuSCHNITZEL]

@PaintYourDragon: with my latest commit - playback with cvlc works

[PaintYourDragon]

Oh nice! I’ll remove my fork, since this covers it.

I did find that Pi 4 & 400 require a firmware update before some piece of this (the fkms overlay, I think) would work correctly. Hence my version of install.sh had an “apt upgrade” in there, which seems to takes care of this (though adds several minutes to the install process). It didn’t prompt for reboot if the firmware was updated though, which really would be the right thing to do.

HOWEVER…since this ONLY affects Pi 4/400 models, running Bullseye, and ONLY if their firmware isn’t previously updated…perhaps it’s really a documentation issue and not a script issue. What’s more, if the installer is run on a Pi 3 and the card is later moved to a 4, that apt upgrade is of no use…the Pi 4 may still need the firmware upgrade, so yes, answering my own thing, this is more a documentation issue, and the “upgrade” can be left out of the script.

The full and persnickety firmware update sequence for Pi 4/400 seems to be:

sudo apt update
sudo apt upgrade
sudo apt full-upgrade
sudo rpi-eeprom-update -a
reboot

[tofuSCHNITZEL]

Could we find a way to determine the firmware version and do the system update only if necessary?

[PaintYourDragon]

On Pi 4, sudo rpi-eeprom-update provides status (appending -a to this applies the latest update from a prior apt-get upgrade). Could probably do some grepping around in the output.

Here’s a dump from an up-to-date Pi 400:

BOOTLOADER: up to date
   CURRENT: Thu 29 Apr 16:11:25 UTC 2021 (1619712685)
    LATEST: Thu 29 Apr 16:11:25 UTC 2021 (1619712685)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Using bootloader EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

Same, for a NOT-recently-updated updated Pi 4:

*** UPDATE AVAILABLE ***
BOOTLOADER: update available
   CURRENT: Thu  3 Sep 12:11:43 UTC 2020 (1599135103)
    LATEST: Thu 29 Apr 16:11:25 UTC 2021 (1619712685)
   RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
            Use raspi-config to change the release.

  VL805_FW: Dedicated VL805 EEPROM
     VL805: up to date
   CURRENT: 000138a1
    LATEST: 000138a1

And on a Pi 3 B+:
This tool only works with a Raspberry Pi 4

Might not need any grep…

sudo rpi-eeprom-update
echo $?

Returns 1 if an update is available. 0 if up-to-date or on a Pi 3.

[PaintYourDragon]

Y’know what? I think the firmware update thing is a red herring and I was confused with something else, let’s skip it for now. Seems to work just fine on a Pi 4 without it.

Should I PR this as-is then, or any further changes needed?

[tofuSCHNITZEL]

yes if you want you can create a draft pull requst. and then we work there on finishing the feature.
from the top of my head this would be:

• porting more settings from omx to vlc (especially displaying the video title)
• maybe minimizing the packages installed with vlc (I remember somewhere that there is a way to install vlc with less packages especially if you don't have a running window manager
• maybe checking if the whole videolooper script could run without root? or finding out why cvlc needs sudo to run from the script (it may have something to do that sudo drops the whole process to a certain necessary terminal session?) maybe it also has something to do why the whole script needs sudo despite running as root if you run it via systemd

[SamVimes78]

Afaik VLC supports videos AND pictures. If so, you could theoretically create a loop containing both. Maybe someone could add an option to choose how long pictures are shown in the loop if you use VLC.

[Sandvoxel]

I wanted to reach out here because it appears this is the only place discussing something similar to what I'm trying to accomplish. I'm working on creating a video looper that plays videos based on external input. In the past, I've written one using Python and OMXPlayer, but since OMX has been deprecated and VLC is now the standard, I'm encountering significant issues. Specifically, VLC displays a black screen between videos or between videos and images. I'm wondering if anyone here has discovered a workaround for this limitation, as it renders VLC unusable due to the flashing of the underlying command prompt between videos.

[tofuSCHNITZEL]

yes thats why the VLC support is kind of "halted" at the moment... there are lots of issues and it is just not a "drop in replacement" for OMX like some people say

[sertonix]

A bit of topic but is mpv a viable option? I haven't seen it mentioned anywhere.

[tofuSCHNITZEL]

I think it all boils down to hardware decoding support, which omxplayer does fine even on modern pis with older software. Vlc I think is also very far in that regard so it would be a good choice as a replacement. I just looked a bit at mpv but it seems the hw-decoding on pi is not rock solid yet?