omxplayer | commandline OMX player for the Raspberry Pi

So what happened is that the library in Debian providing support for live555 was removed in February of this year, this affects all downstream distros including but not limited to RPi OS and Ubuntu:

https://askubuntu.com/a/1363113

The 2 active versions were 2020.01.19-1 and 2018.11.26-1.1, Live555 has since added GPL license headers to the offending files, however the RFC issue remains.

Now you may be tempted to just download the latest Live555 source code and compile it... it does not work. There have been changes to function names and structures referenced by VLC, and as such VLC will not compile against the source. You need to get an older version, I specifically used this one, which is a tweaked snapshot from 2020 prior to the modifications that prevent VLC compilation:

https://github.com/rgaufman/live555

The configuration you want is ./genMakefiles linux-with-shared-libraries, I do not know if it is required but since my system is x86-64-bit I added -m64 to the compiler options first

After compilation and install, I went on to compile VLC, adding '--enable-live555' and '--with-live555-tree=extras/live555-master' after placing the root Live555 folder in the VLC extras folder, however VLC failed to compile, it turns out the Live555's make install does not copy all the header files needed to where VLC is looking. They were dropped as 4 subfolders into /usr/local/include/, and the actual libs into /usr/local/lib/. Adding the correct CXX/CPP flags will make it look where they were put, however I put them all in a single folder and used 1 flag.

I also had to '--disable-mod' to work around a dependency version issue that I had no interest in fixing, since I do not use modplug or any mod files.

50 minutes later... VLC successfully compiled! However it was expecting the libraries for Live555 to be in /usr/lib/ not /usr/local/lib/, since it took so long to compile I was just fine with linking or copying the libraries into the expected folder, and after that VLC works with RTSP when linked to the new file. Or you can choose to maintain the original VLC and run the new file directly if you need to load the camera feeds.

The problem was solved by adding SRT subtitles to a MKV-container instead of MP4:

What you did wrong is you are making 3 forms without id and it makes every submit button send all the URLs to the backend. Put incremental id to form.. below code works.

Most players don't like such a low frame rate. Add -r 10 output option:

So the problem was I should have force both input and output rates(r .2 and -r 30) Here is my final command:

Okay, I solved it. The above is correct, however, my card number and device number were off. To see list of devices:

aplay -l

From there, find your device and it should work! This was mine:

Established in chat and comments:

• cat temp.mp3 | omxplayer -o local --vol -500 /dev/stdin causes a segfault.
• omxplayer -o local --vol -500 /dev/fd/3 3< <(cat temp.mp3) works correctly.

Thus, we can pass a MP3's data in... but not on stdin (which omxplayer uses for controls: pausing, early exiting, etc).

This is equivalent to "Approach 3", but instead of using very new and modern Python functionality to do the FD wrangling in-process, it launches a copy of /bin/sh to do the work (and consequently will work with much older Python releases).

I would suggest going with VLC

Ok, with @pptaszni help I found how to do it.

The problem was that boost could not detarmine the function signature because boost::bind return a function object.

To avoid this problem, I have to specify the signature when call make_function.

Example: