Indeed. Thus the talks with YouTube. The issue has always been more of a technical challenge than a political/design challenge. The foreground popup page used by most extensions is destroyed when focus is lost which makes it a very poor location for hosting YouTube's <iframe>. The audio would stop whenever the popup loses focus. So, the <iframe> is hosted on a background page which, unfortunately, isn't visible to the end user.
I've known about the issue since day 1 and went into this project with the mindset of, "If I make something cool enough to get shut down then I'll consider it a success."
A few years into the project I garnered their attention and was finally able to setup some talks to figure out what my options were for fulfilling their ToS.
My initial suggestion was to allow Streamus to follow in the footsteps of the Google Hangouts extension which uses Chrome Panels to display a tab-independent window over your browser. The intent was that the YouTube video could be displayed there and minimized when not wanted. However, this functionality is being deprecated and Google didn't have much interest in expanding the usage of it.
So, what I've got going now is some code which injects itself into YouTube's iframe and sniffs the responses from YouTube's server, https://github.com/MeoMix/StreamusChromeExtension/blob/Devel.... This allows me to pass around a pointer to the array buffer of video data being rendered in YouTube's iframe. Using this data I'm able to sync and re-render the video inside of the popup without having it coupled directly to the audio.
So far this seems like a satisfactory response to the issue. It's akin to having a YouTube video player running on an inactive tab. The user has the ability to watch the video, but isn't necessarily viewing it while listening to the audio.
I'm aware that I'm playing with fire a fair bit, but I think that's the case when using any API. YouTube has been nothing but completely understanding throughout all of our talks.
Fallback options include migrating Streamus to a Chrome App, which would not suffer the same issue but, IMO, has worse UX, or migrating away from YouTube in favor of other sources such as SoundCloud, MixCloud, SFX.io, etc.
I've known about the issue since day 1 and went into this project with the mindset of, "If I make something cool enough to get shut down then I'll consider it a success."
A few years into the project I garnered their attention and was finally able to setup some talks to figure out what my options were for fulfilling their ToS.
My initial suggestion was to allow Streamus to follow in the footsteps of the Google Hangouts extension which uses Chrome Panels to display a tab-independent window over your browser. The intent was that the YouTube video could be displayed there and minimized when not wanted. However, this functionality is being deprecated and Google didn't have much interest in expanding the usage of it.
So, what I've got going now is some code which injects itself into YouTube's iframe and sniffs the responses from YouTube's server, https://github.com/MeoMix/StreamusChromeExtension/blob/Devel.... This allows me to pass around a pointer to the array buffer of video data being rendered in YouTube's iframe. Using this data I'm able to sync and re-render the video inside of the popup without having it coupled directly to the audio.
So far this seems like a satisfactory response to the issue. It's akin to having a YouTube video player running on an inactive tab. The user has the ability to watch the video, but isn't necessarily viewing it while listening to the audio.
I'm aware that I'm playing with fire a fair bit, but I think that's the case when using any API. YouTube has been nothing but completely understanding throughout all of our talks.
Fallback options include migrating Streamus to a Chrome App, which would not suffer the same issue but, IMO, has worse UX, or migrating away from YouTube in favor of other sources such as SoundCloud, MixCloud, SFX.io, etc.