openhab-core
openhab-core copied to clipboard
openhab
[WIP] Add a new feature media to simplify handling of media in Openhab
Add a new feature media to simplify handling of media in Openhab
Description
See this issue for description : https://github.com/openhab/openhab-core/issues/4710
Hello @All,
@florian-h05, @digitaldan, @lsiepel,
I would apreciate if someone with more experience in core that me can give comments on this first version. Especially, about the PlayerItem modifications.
I finally decide to drop my new BrowerMediaItem implementation, and modify the existing PlayerItem. I introduce a new MediaType accepted command on it. The idea is that this MediaType command would be use to play / queue an album / track / artist to play on the PlayerItem.
The MediaType is a complex type compose of:
- The type of command : PLAY/QUEUE (for now).
- A parameter (that id the id/path of entry to play).
This command would be relay from core to addons, and addons would have to implement if to handle the play/queue request. I've currently test this approach with spotify and upnp addons, and it seems to work (minor some obvious bugs to handle).
Laurent
Not sure if i can be of much help here. If i have more tim ei could look into it, but i think others have more knowledge about these parts.
JFTR please don't use force-push as this makes it harder to review / keep track of changes.
Hello,
Make some progress on this today. Of course, it will be not ready for 5.0, perharps for 5.1. I fix some issues on popup navigations in UI part make things a littles more stables. Also start to see how I can add a media Renderer popup to select the output device directly from the oh-player-control.
Still a lot of work to be done on it. I like to have something simple to use for end user, where you have only one way to implement this whatever device you have in your configurations.
Laurent.
@lo92fr By coincidence, I made this commit the other day: https://github.com/Nadahar/openhab-core/commit/a35e2180382d1dbd0b2a3135403a833293205d4d
Your commit has some strange definitions IMO 😉
Ok, we are on the same way :)
More globally, I'm currently looking at implementing MPEG-Dash support inside Openhab. Mpeg-dash is sort of m3u container, that are use to handle streaming of audio and video. I've a very early code inside Tidal addons that do something like this, but I fill it will be better to handle this directly in core.audio. Currently, I only prefetch all the Mpd chunk and create a MemoryStream with the full flac result. But it will certainly needs more rework to enable on the fly streaming of the chunk as we are currently playing it.
Laurent.
I've take a look also to .m3u and .pls support in core.audio. Perhaps we can do something more useful for it. It seems that currently, if you try to stream a m3u, it will only play the first audio stream of the m3u, and ignoring all other.
More globally, I'm currently looking at implementing MPEG-Dash support inside Openhab.
I know what it is, but isn't sure how you want OH to "support" it. When dealing with adaptive protocols, HLS should be very relevant as well. But, with "support", do you only mean to forward it from a source to a sink where both support it, or do you mean to somehow generate a Dash (or HLS) stream from a regular source? Or the opposite, to combine them into a "regular file"?
While on the topic, I have a library for handling cue files, also when embedded in FLAC: https://github.com/DigitalMediaServer/cuelib
This allows seeing e.g a full FLAC album ripped to one file as individual tracks.
More globally, I'm currently looking at implementing MPEG-Dash support inside Openhab.
I know what it is, but isn't sure how you want OH to "support" it. When dealing with adaptive protocols, HLS should be very relevant as well. But, with "support", do you only mean to forward it from a source to a sink where both support it, or do you mean to somehow generate a Dash (or HLS) stream from a regular source? Or the opposite, to combine them into a "regular file"?
Generally, Sink, and most audio renderer does not support it. Perhaps some video renderer are able to support it via Upnpcontrol binding, but not very sure it will currently work. What I've work so far is to decode the mpd, download the chunk, and combine them to a regular file. What will be better is to have something in openhab audio that feed the combine stream as it us consume by the sink !
The use case on my side is that tidal deliver hi res loos less audio (>=44khz) only using mpd stream. So if I want to play them, need to do some sort of recombination before deliver them to the sink.
The use case on my side is that tidal deliver hi res loos less audio (>=44khz) only using mpd stream. So if I want to play them, need to do some sort of recombination before deliver them to the sink.
I see. I think that could be a quite huge task, and that it might be smart to do this independently of the "general media handling" PRs. Also, you'll need to download the whole file before you can put it together and send it to the sink, and you'd ideally need to handle the "progressive part" (switch to lower quality chunks if bandwidth is lacking). These files could be quite large, so you'll have some cache handling to do as well - how long to keep them etc. You must make sure to delete them after use, or you could quickly fill up the relatively small storage available in many OH installations.
FFmpeg could probably combine them "live" for you, so that they could be played back while receiving. But, integrating FFmpeg with OH is another huge task, and I'm not even sure that hardware such as the RPi is up for the task, at least not for video.
This is a slippery slope, you're quickly entering into the realm of a media server, and thinking about doing tasks normally done by a media server. That's not a small undertaking 😉
The use case on my side is that tidal deliver hi res loos less audio (>=44khz) only using mpd stream. So if I want to play them, need to do some sort of recombination before deliver them to the sink.
I see. I think that could be a quite huge task, and that it might be smart to do this independently of the "general media handling" PRs. Also, you'll need to download the whole file before you can put it together and send it to the sink, and you'd ideally need to handle the "progressive part" (switch to lower quality chunks if bandwidth is lacking). These files could be quite large, so you'll have some cache handling to do as well - how long to keep them etc. You must make sure to delete them after use, or you could quickly fill up the relatively small storage available in many OH installations.
FFmpeg could probably combine them "live" for you, so that they could be played back while receiving. But, integrating FFmpeg with OH is another huge task, and I'm not even sure that hardware such as the RPi is up for the task, at least not for video.
This is a slippery slope, you're quickly entering into the realm of a media server, and thinking about doing tasks normally done by a media server. That's not a small undertaking 😉
Yes, this his huge thing, and I would not even try to work on it for now. But just want to have a quick look if it would be possible to implements. And you are right, if do it, will be on a different PR from feature-media.
There a lot more things that would prevent Tidal addons to be release at all, mainly licensing issue. All of the opensource project that support tidal today seems to be illegal as tidal does not support officially to do audio playback.
Laurent.
More globally, I'm currently looking at implementing MPEG-Dash support inside Openhab.
I know what it is, but isn't sure how you want OH to "support" it. When dealing with adaptive protocols, HLS should be very relevant as well. But, with "support", do you only mean to forward it from a source to a sink where both support it, or do you mean to somehow generate a Dash (or HLS) stream from a regular source? Or the opposite, to combine them into a "regular file"?
Generally, Sink, and most audio renderer does not support it. Perhaps some video renderer are able to support it via Upnpcontrol binding, but not very sure it will currently work. What I've work so far is to decode the mpd, download the chunk, and combine them to a regular file. What will be better is to have something in openhab audio that feed the combine stream as it us consume by the sink !
The use case on my side is that tidal deliver hi res loos less audio (>=44khz) only using mpd stream. So if I want to play them, need to do some sort of recombination before deliver them to the sink.
Hello @Nadahar,
For information, I've pushed very preliminary support for MPEG-DASH in openhab.core.audio this evening. You will find it on this PR : https://github.com/openhab/openhab-core/pull/5130/files.
Surprising, this was no so much complicated.
The idea is to have an intermediate Stream in audio that take the chunk Urls, and download the necessary chunk when the AudioSink need them. Like this, we perhaps can totally avoid to do modifications on Audio Sink, and just repose on the Stream to handle all the streaming stull.
Of course, this is very basic so far. I've test only with Audio mpd stream, and UpnpRenderer endpoints. But that done the stuff, enable to feed it a Tidal sources .mpd, and play it at 192khz/24bit on my Marantz Upnp renderer. The current implementation is very simple, just taking the fist adaptation / representation in the Mpd files.
Laurent.