-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Adds a GUI media service to handle audio and video playback for Common Play Service #2952
Conversation
Voight Kampff Integration Test Failed (Results). |
LOG.debug("Falling Back To Audio Type") | ||
self.bus.emit(Message("playback.display.audio.type")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what's happening, but using a slightly modified version of Ake's YT Skill, I'm seeing this log message that its falling back to Audio but it then uses the Video player.
I added logs to the handle_display_video
and handle_display_audio
methods in the control Skill and it somehow is triggering the Video handler.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What type of stream is Ake's YT Skill providing ? Video or Audio ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The debug message was wrong and has been fixed in newer commit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If Ake's YT stream URL consist of "videoplayback" in the URL it will fallback to Video type as that is the only sane and logical way to check if the mime type for those type of streaming links is actually an Video.
As I recall it would prefer audio streams and fall back to video streams if no pure audio stream existed |
Extracted streaming links don't exactly end with known type extensions which does not help with mime detection, I rather have CPS tell the audio service what type of stream it is (Audio/Video) than depending solely on mime detection in the Audio Service but I think that is an issue is for another PR not supposed to be blocking this PR |
The audioservice interface supports sending the mimetype already so the skill can inform the audioservice of the type already so should definitely not be a blocker. Though the handling inside audioservice can definitely be improved |
Sorry if this is a duplicate comment, I thought I'd already posted this, but can't find it... It's working well so far, looks like a really solid start. I'm thinking we should add it as a plugin rather than including it in mycroft-core itself. We want to do this with the other Audioservices when we get around to it too. So I've setup a new repo at: The docs for audioservice plugins are here: As it is in this PR, it will need to be an "Audioservice" plugin for the moment, but as you can probably tell from the repo name, I think we should revisit that in the near future given we're now handling audio and video. |
audio plugins seem to be broken, see fix here HelloChatterbox/HolmesV@3698485 and example plugin to test with here https://github.com/OpenVoiceOS/ovos-vlc-plugin |
ported from MycroftAI/mycroft-core#2952
Closing in favour of the new plugin that can be found at: https://github.com/MycroftAI/plugin-playback-gui-player |
Description
Adds a GUI media service under Audio Services that establishes full media serving capabilities via Mycroft-GUI's media service backend for Common Play Service
Requires: MycroftAI/skill-playback-control#46
Requires: MycroftAI/mycroft-gui#97
How to test
Change the local backend to use "guiplayer" type instead of "simple" in mycroft.conf.
Contributor license agreement signed?
CLA [x] (Whether you have signed a CLA - Contributor Licensing Agreement