Earlier quoted context omitted.
Instead of waiting, hoping that big companies will implement the standard. Just make it as easy as possible to adopt by having receivers for all platforms and making client libraries that can cast to AirPlay, Chromecast, FCast and others seamlessly.
Doest current app support AirPlay and Chromecast as different receivers/backends? Websites doesn't mention anything about it. Is there any plan also for iOS app? Some feedback: I would also add dedicated buttons for downloading MacOS and Windows binaries - for typical users gitlab button will be to scary. Website also not clear if there is and SDK for developers (the one that supports also airplay and chromecast) and…
FCast: Casting Made Open Source
61–67 of 67 posts
Re: FCast: Casting Made Open Source
#62FCast engineer here. Look forward to FCast receivers on platforms like AppleTV, Roku, Tizen (Samsung), WebOS (LG).
Would it be possible (in theory) to build a receiver on an embedded platform, for instance an audio-only ESP32 speaker, or is there something in the protocol that requires a more powerful device?
https://gitlab.com/futo-org/fcast/-/wikis/Protocol-version-1
As you can see the 1.0 protocol is very lean and fits on an A4.
If you want to have an audio-only ESP32 speaker I don't see why it wouldn't be possible with the FCast protocol.
Re: FCast: Casting Made Open Source
#63Seems to use confusing terminology? In FCast, a "client" is a device or software application that discovers and communicates with a "receiver". The client, which can be a terminal client or an Android application, uses the FCast protocol to send media content to the receiver, such as a TV or media top box. The client initiates the media streaming by connecting to the receiver, launching the media, and then the receiv…
Media provider and controller might be less confusing terms.
Re: FCast: Casting Made Open Source
#64Earlier quoted context omitted.
I don't know that you can 'cast' using DLNA. Live streams and such.
I think it depends on the server. I believe serviio supports it. Mediatomb supposedly could (another project I thought was dead but turns out has been reborn under the 'Gerbera' name!). They transcode the original stream into something that a dumb DLNA renderer (i.e. your TV) supports.
Re: FCast: Casting Made Open Source
#65Earlier quoted context omitted.
I think it depends on the server. I believe serviio supports it. Mediatomb supposedly could (another project I thought was dead but turns out has been reborn under the 'Gerbera' name!). They transcode the original stream into something that a dumb DLNA renderer (i.e. your TV) supports.
How do they work with encrypted streams though (because aren't they all)?
Re: FCast: Casting Made Open Source
#66This project comes from FUTO, which is now making a name for itself by releasing and maintaining OSS alternatives like this, as well as sponsoring development of other OSS options. I personally first came across them when Louis Rossmann announced his affiliation. Very excited to see where this goes! As an aside, I wonder what it will take to get the protocol integrated into browsers? I presume Chrome is a foregone co…
Re: FCast: Casting Made Open Source
#67Earlier quoted context omitted.
Would it be possible (in theory) to build a receiver on an embedded platform, for instance an audio-only ESP32 speaker, or is there something in the protocol that requires a more powerful device?
The protocol has been designed by taking the commonalities between all different casting protocols like AirPlay and Chromecast as a base. This is what has been used to make version 1.0. I tried making it as simple as possible and low effort to implement. https://gitlab.com/futo-org/fcast/-/wikis/Protocol-version-1 As you can see the 1.0 protocol is very lean and fits on an A4. If you want to have an audio-only ESP32…