Skip to content
This repository has been archived by the owner on Mar 1, 2022. It is now read-only.

Dynamic Overlays #121

Open
dropitlikecross opened this issue Mar 29, 2019 · 22 comments
Open

Dynamic Overlays #121

dropitlikecross opened this issue Mar 29, 2019 · 22 comments

Comments

@dropitlikecross
Copy link

Hello All,

Wondering if anyone has successfully been able to add overlays from streamlabs and other sites or if ffmpeg even supports this? There's not too much information online about it so I thought I'd ask here.

@LauraWebdev
Copy link
Collaborator

To add streamlabs overlays you'd need a browser that renders the overlay and feeds the rendering output into ffmpeg. I do not believe it's easy to do that though.

@torch2424
Copy link
Owner

torch2424 commented Mar 29, 2019

Agreed with @andreasWebDev

Streamlabs (as I understand), would require a browser.

But this gets me thinking, with pupeteer, maybe that's something we can do? 🤔 But that would bump the project out of the "Raspberry Pi friendly" Category. Perhpas it's time to split the project into two? 🤔 🤔 🤔

@ALegitCookie
Copy link

ALegitCookie commented Mar 29, 2019

Streamlabs support would be crazy, would love to see that supported on the Mac/Windows builds in the future 😸
Plus, if Raspis get more powerful in the future, maybe it would be possible to to that on them 🤔

EDIT: Temporary fix: If you have any hardware that can run OBS, have the OBS display the live-stream-radio stream and then put your browsersource for your overlays on that, and then use the OBS stream as your main stream, while keeping the live-stream-radio stream on a private stream that only the computer running OBS can access?
I think that would work and I might actually do that myself now that you gave me the idea.

@LauraWebdev
Copy link
Collaborator

@torch2424 does puppeteer allow an output of a stream? From a quick glance on the project, I only saw a screenshot function, not sure if it can operate at 30FPS though...

@torch2424
Copy link
Owner

@ALegitCookie Thanks for the workaround!

@andreasWebDev I think I saw something in the past about piping a chrome window through FFMPEG. But maybe I had a dream about it 😂

@LauraWebdev
Copy link
Collaborator

@torch2424 dreaming of ffmpeg? must've been a nightmare.. in any ways, no thoughts on either option for splitting right now, it depends on what you want this project to be. It would obviously open up quite a lot of possibilities, but it would be needed to change the scope.

@torch2424
Copy link
Owner

@andreasWebDev

dreaming of ffmpeg? must've been a nightmare..

HAHAHAHA 😂 Probably was 😂

in any ways, no thoughts on either option for splitting right now, it depends on what you want this project to be. It would obviously open up quite a lot of possibilities, but it would be needed to change the scope.

Yeah true. I'll ask around for advice on this. I could see us doing this with like a flag, or even a new command (E.g live-stream-radio start --browser or live-stream-radio serve ./some-html-file). But pupeteer is a huge install. Wouldn't know a good way to handle this. Though, we could just go ahead with a 2.0 that dynamically npm install's depending on which type of serving you want to do? 🤔 🙃

That being said, this is mayyyyy be possible: puppeteer/puppeteer#478 . Video for sure, but audio would be a maybe.

Or something like this may work: https://github.com/muralikg/puppetcam . Looking through the source, not too complicated to set up and use ourselves. And there is an issue getting audio working: muralikg/puppetcam#4

Which, piggybacks off of: https://www.chromestatus.com/feature/6744724455030784

@torch2424
Copy link
Owner

So I talked to a colleague of mine on this issue for an upgrade path if/when we get the time to experiment with pupeteer. But we came to the agreement something like this would work:

  1. Experiment with puppeteer. Make sure it actually works.
  2. Create an intent to implement (I did this with the node rewrite actually). For the pupeteer version.
  3. Make the repo a mono repo with all three code bases (piStreamRadio, live-stream-radio-1.x.x, live-stream-radio-2.x.x). Direct users to each depending on their needs and what their device can support.
  4. Add deprecation warnings to the 2 old repos.
  5. Once finished with pupeteer. Push a new major (2.0.0).
  6. Tell people on 1.0.0 to move to the new version, or install any updates to the no longer maintained 1.0.0. People can still contribute to 1.x.x, I can push minor updates to it. But no more maintenance from the "core team".

Would love to hear your opinions @andreasWebDev @dropitlikecross . Also, hope you don't mind us hijacking the issue. Will probably rename it, as this can be the starting point of the next major upgrade 😄

@LauraWebdev
Copy link
Collaborator

Sounds good to me. It could be the next "chapter" in this project, I can see this feature alone make this project much more usable for a lot of use cases. Of course we would close off some other use cases, but that's the price to pay ^^

@torch2424
Copy link
Owner

@andreasWebDev Yeah, definitely. I think we can direct users (like for example, if a pi can't handle running puppeteer and ffmpeg), we can direct them to 1.0. Which could still be updated by other users who are interested in using a pi 😄

@dropitlikecross
Copy link
Author

@torch2424 No worries, I've been reading the messages as they come in. :)
I also think this the next step the project needs to take and it will bring a lot of the missing features. It might even make us a contender with OBS.

If you need infrastructure resources let me know.

@LauraWebdev
Copy link
Collaborator

@dropitlikecross it could very well compete with OBS in the "live server" configurations. OBS tends to not run well unmaintained for longer than a few hours so this project could definitely evolve into a solution for all the FlareTV's out there who plan to have 24/7 livestreams with high customizabilities. So definitely keep the focus on the "always on" principle of the livestream radios (rather than, for example, try to be a solution for casual streams - the actual focus of OBS)

@torch2424
Copy link
Owner

Was thinking about this today and found this: “How to use headless chrome to screencast audio and video to an RTMP endpoint” by Sebastian Pereyro https://link.medium.com/qGCVJKJ8XW

It's totally possible, and apparently, pupetteer isn't too bad on a raspberry pi 3 🤔

@torch2424
Copy link
Owner

And oh shit, electron does exactly what we need it to 😂 cypress-io/cypress#1767

@torch2424
Copy link
Owner

Pi 4 was just released, https://www.raspberrypi.org/products/raspberry-pi-4-model-b/ which totally should be able to run an electron rewrite (I would assume, specs look nice)

And I just saw https://github.com/guysoft/FullPageOS which maybe we could do with electron? 😄

@ALegitCookie
Copy link

ALegitCookie commented Jun 24, 2019

This sounds very promising and i'm looking forward to the possible update!
Edit: Holy Moly!!!! 4GB of RAM! I see lots of new advanced projects coming in the future!

@LauraWebdev
Copy link
Collaborator

Guess who's gonna buy a new RasPi in august?

@ALegitCookie
Copy link

@andreasWebDev Guess who else is gonna buy a new RasPi in august?

@dropitlikecross
Copy link
Author

Can across this old project which I thought was interesting:

https://github.com/JamesTheHacker/Facebook-Live-Reactions

@torch2424
Copy link
Owner

@dropitlikecross Oh nice! Thanks for sharing that 😄 Yeah seems to also be using ffmpeg, hopefully we can learn something fro the way they are using it 😄 👍

@dropitlikecross
Copy link
Author

As I was for obs to install, I saw @torch2424 pop up in my feed and I started thinking about this again.

So now that we're hopefully wiser and 100× busier, it might be interesting to see what 2021 ideas everyone has.

I'm inclined to think that it should be doable with nginx and since docker's a thing now it would also add the ability to have multiple outputs without the pain setup pains.

@torch2424
Copy link
Owner

Yeah I'm definitely wayyyy busier haha! 😂

I'd probably still vouch for something like Electron, especially since Raspberry Pis keep raising the bar. I think using electron on top of a good CLI would be a good idea 😄

But! I don't have much time recently to dedicate to this project 😢

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants