Add URL streaming option for AutoKiosk system
|Status:||In Progress||Start date:||20 Aug 2020|
|Target version:||PiBox - 2.0 - Harkonnen|
|Severity:||01 - Critical|
Ive had a request to allow videofe to stream from a URL. The request also asked for the playback to occur on power cycle, which implies use in AutoKiosk.The way to do this is:
- Add a cli and config file option that specifies the URL to open by omxplayer.
- Add support in videofe to prefer the URL option over playing locally. If playing locally, don't use the local db code.
- Add support for testing the URL for it's availability.
- Add notification that remote url can't be accessed.
- On boot, look for USB stick with file: autokiosk.url
- That file has one line: the url
- if present, update videofe.cfg with the config option and that url.
For this to work I need to be able to configure the kiosk after installation. The way to do this is with a videofe.db file. If that file exists it will be read first. That file can contain URLs to add to the list of files to play and/or remote .db files to download. The remote .db files must be named <file>.db and they can only contain URLs to play.
Valid URLs for the .db files must start with http:// or https://. If a line in those files starts with anything else it will not be downloaded. All valid lines must also be suffixed with a supported video format, which defaults to one of p4 mkv m4v avi mov. However, to avoid having to fully download the file before playing the file should be in the MP4 format.
Additionally, to allow configuration after the device is installed with PiBox a USB stick can be inserted with files on it. An init script will install files it finds on the USB stick.
If the usb stick has a config file for videofe that should be copied over at boot time.
If the usb stick has a playlist (re: .db) file for videofe that should be copied over at boot time.
- Status changed from New to In Progress
- % Done changed from 0 to 10
I switched the omxplayer build from local ffmpeg to system ffmpeg to get access to tls support, which is required to use an http URI. This also makes omxplayer build much faster. This was just for testing purposes - it's not checked in yet. I need to make sure this change doesn't affect standard Media System or Kiosk operation.
I can play the video stream like so:
./omxplayer.bin --loop -o hdmi -r -s https://client.cybsm.com/videos/Test/main_scurt.mp4
I cannot play the URL like so, because omxplayer doesn't support an HTML5 parser.
If you dig into the HTML you can see there are two urls that get played here:
./omxplayer.bin --loop -o hdmi -r -s https://client.cybsm.com/display
Lag on the internet causes playback to stutter a little (not terrible, but it happens). This is worse for the "hit_music" video because it's audio stops too. That's more noticable than the video stutter.
If I download these videos to the local network, and I run on wired ethernet, there is almost no stutter. On a closed network I'd expect there would be no stutter at all.
Next step is to verify the omxplayer build changes don't cause any regressions. Status: they didn't. Changes can be committed and pushed.
Then I can look at adding config option changes to videofe to support this type of playback.
- % Done changed from 10 to 30
I have the changes implemented to support a videofe.db file. I need to test the following:
- Add remote urls to videofe.db: These are https:// urls added to /etc/videofe.db. If videofe.db exists then any https:// urls should be ADDED to the list of files to play. That means both remote and local files can be played in kiosk mode. I need to test
- local urls only (the regression test)
- remote urls only (new functionality)
- local and remote urls (mixed functionality)
- Add remote dbs to videofe.db: These are https// urls to videofe.db files. If the remote url is a videofe.db file then that file should be parsed for remote urls ONLY (any local files should be ignored). I need to test
- remote videofe.db with remote URLs only
- remote videofe.db with invalid local URLs (these should be ignored)
- remote videofe.db with mixed remote URLs and invalid local URLs
- remote videofe.db with invalid URLs (non-http and non-https; these should be ignored)
- remote videofe.db with videofe.db URLs (these shold be ignored)
The code for this is currently in my sandbox for videofe (re: vfe cdtools).