[HN Gopher] FCast: Casting Made Open Source
___________________________________________________________________
FCast: Casting Made Open Source
Author : icar
Score : 261 points
Date : 2024-08-28 05:23 UTC (4 days ago)
(HTM) web link (fcast.org)
(TXT) w3m dump (fcast.org)
| dblitt wrote:
| Could this end up on an embedded smart tv device, like a Roku?
| hiatus wrote:
| They have an android receiver package available:
| https://gitlab.futo.org/videostreaming/fcast/-/tree/master/r...
| koen31 wrote:
| FCast engineer here. Yes it will come to Roku.
| nsteel wrote:
| NymphCast has been around for years but it's still basically
| unheard of. This has more polished marketing (and a less weird
| name) but other than that I don't see what makes it any more
| likely to succeed.
|
| * https://news.ycombinator.com/item?id=22457351
|
| * https://news.ycombinator.com/item?id=27482699
| oezi wrote:
| I wonder what is their ecosystem play? Why would Netflix
| implement this in their app? Why would any TV manufacturer?
| koen31 wrote:
| I am not counting on anybody to implement this on their TV.
| We don't have big budgets to pay TV manufacturers to put
| FCast receivers inside.
|
| Instead, I hope to have receivers that the user can install
| if they wish.
| oezi wrote:
| I am more troubled by how you want to get the Cast button
| into Netflix, YouTube, etc.
| koen31 wrote:
| I am not counting on this to happen quickly if at all.
| Though if FCast is the thing everyone has access to
| (regardless of Apple TV, Fire TV, Android TV, etc) then
| maybe eventually it will happen. If you have a raspberry
| pi, and old computer or an old phone you aren't using,
| you can easily convert it into a FCast receiver. Doing
| the same with Chromecast is more tricky since the
| protocol is more extensive and most clients verify the
| certificates of the casting device to be authorized by
| Google.
| pzo wrote:
| probably worth to consider having official receiver for
| UmbrelOS [0] and CasaOS [1] in their appstores for
| increased user adoptions
|
| [0] https://umbrel.com/
|
| [1] https://casaos.zimaspace.com/
| JonChesterfield wrote:
| Jellyfin exists on various hardware as an optional install
| so it seems likely FCast would work on that distribution
| model.
| riedel wrote:
| Why not use straight UPnP (DLNA). Tons of open source there.
| The only problem was standardising codecs (also related to the
| Chromecast spinoff)
| IshKebab wrote:
| UPnP/DLNA seems to be a bit of a disaster protocol wise. As
| you say the codec support is "eh whatever" which means
| whether it works or not depends on too many random factors.
| It's also a massively over-complicated design-by-committee
| relic.
|
| There also isn't a good open source DLNA server (presumably
| because of the above issues).
| nsteel wrote:
| That's actually pretty fair. I was ready to jump in and say
| that miniDLNA is such a server but having looking I see
| it's actually been unmaintained for 10+ years! It has
| worked pretty well for me but I think I must have just
| gotten everything in the right formats years ago so I don't
| notice the issues I see reported now (I used to just
| restart it to avoid the notify issues).
|
| Presumably you still need some kind of media server for the
| fcast receiver to stream from when playing local media, I
| assumed that would be dlna based but what is the actual
| idea here?
| ciupicri wrote:
| What are you talking about? There's the "Wrap up version
| 1.3.3." commit from 2023-05-31 (see at
| https://sourceforge.net/p/minidlna/git/commit_browser).
| nsteel wrote:
| Oh, that's great, thanks. I didn't realise it changed its
| name to ReadyMedia.
| JonChesterfield wrote:
| You're not alone. apt install minidlna didn't work so I
| assumed it was dead. Just learned of the rename from your
| comment.
| nsteel wrote:
| Yes, 100% this is what I've ended up doing. There's existing
| support on a lot of platforms for DLNA and if you're really
| lucky, it works. I'd be interested in hearing what the
| advantages of something like this is.
|
| Edit: And then there's stuff like Plex and Kodi too with
| existing servers and clients for numerous platforms. I'm
| fairly sure I can "share" a URI to the Kodi app on my phone
| and the Kodi server will stream it. I remember that working
| well but it's been a while.
| brnt wrote:
| I don't know that you can 'cast' using DLNA. Live streams and
| such.
| nsteel wrote:
| 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.
| brnt wrote:
| How do they work with encrypted streams though (because
| aren't they all)?
| nsteel wrote:
| They work for simple online radio streams etc.
| paulryanrogers wrote:
| DLNA is okay if the receiver supported the codecs well enough
| to avoid playback stalling. Though it lacks search and
| dashboard features.
|
| I prefer having an app that can save progress and remember
| what I've already watched. (As a younger person I could
| recognize a show or movie from a glimpse while surfing.
| Nowadays I find myself rewatching for several minutes before
| recognizing the program.)
| _volatile wrote:
| Is it currently usable in anything other than GrayJay?
|
| I wish I could use this with local videos.
| qmarchi wrote:
| Thus far, nope.
| pihug12 wrote:
| Cloudstream uses it too:
| https://github.com/recloudstream/cloudstream/blob/master/app...
|
| For local videos with GNOME Nautilus, there is
| https://gitlab.com/futo-org/fcast/-/tree/master/clients/naut...
| nsteel wrote:
| There's a terminal client at https://gitlab.com/futo-
| org/fcast/-/tree/master/clients/term... which supports local
| videos.
| koen31 wrote:
| Someone also made it possible to stream anything that yt-dlp
| can download https://git.sr.ht/~shironeko/fcast/tree/yt-
| dlp/item/clients/...
| justinclift wrote:
| Seems 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 receiver begins playing the media.
| Once the media is launched, the client can control the playback,
| allowing operations like pause, resume, seek, and volume
| adjustment.
|
| Seems like basically a client-server relationship, but with the
| "client" acting as a server and a "receiver" acting as a er...
| client?
|
| But with the "client" being the thing to control the
| start/stop/etc of the media, which is a weird thing for a server
| to do.
| nsteel wrote:
| What in the above makes you think that? The receiver is the
| "server". Playback happens on the "server" (just like mpd, if
| that helps).
| justinclift wrote:
| In a more normal client-server architecture, initial requests
| are sent to a server, which then responds with the requesting
| data.
|
| ie: give me file XYZ
|
| With the FCast project, it seems like the bulk of the
| transmitted data is from the "client" to the "receiver"?
|
| At least, that's what it sounds like from this description?
| The client [...] uses the FCast protocol to send media
| content to the receiver, such as a TV or media top box.
|
| Is my reading of this wonky? :)
| nsteel wrote:
| The client provides a pointer (usually a URI but I think
| they also support playlists) of what to play. The receiver
| then requests the actual content directly from that URI and
| plays it. I guess it sends some kind of ok/fail response
| back to the client when it's done that.
|
| The receiver does not send requests to the client. The
| receiver is server-like in that it responds to client
| requests, but it's not like a file server, those responses
| don't contain media data. Their description could be
| clearer.
| bastawhiz wrote:
| > the bulk of the transmitted data is from the "client" to
| the "receiver"?
|
| This is not new or novel. See: SMTP
| riedel wrote:
| Speaking of terminology. I open the discussion because I
| thought the title was about the manufacturing process (casting
| with a mold).
| zigzag312 wrote:
| Media provider and controller might be less confusing terms.
| justinclift wrote:
| Thanks, that is helpful. :)
| ravenstine wrote:
| Now we're talking! The experience of casting has recently become
| a bigger headache for me than ever. Last month, I made a comment
| on HN about how the original Chromecast was great and that I'm
| disappointed in the state of the current Chromecast devices; a
| lot of people seem to agree with this. I've also had trouble with
| Airplay since streaming from Quicktime seems to only support
| h264, and even that hasn't really worked for me even though my
| 1st gen Chromecast worked great before my TCL television fried
| it.
|
| Casting video should be simple, straight forward, and open. Glad
| to see there's projects like this trying to solve this problem
| rather than leaving it up to advertising firms.
| ilrwbwrkhv wrote:
| I swear like all of these things used to be so much better and
| if given a chance large companies will make it worse.
|
| I'm glad we are taking this into our own hands. The programming
| community is learning that we have to make the software
| ourselves and also fund it ourselves to have quality software
| in the future.
| koen31 wrote:
| FCast engineer here. Look forward to FCast receivers on platforms
| like AppleTV, Roku, Tizen (Samsung), WebOS (LG).
| grepexdev wrote:
| Will there be a receiver for Fire TV too?
| koen31 wrote:
| https://www.amazon.com/dp/B0CLKVH8GZ/ref=sr_1_1?keywords=fca.
| .. personally only tested on a Fire TV Stick but I believe it
| should be equivalent?
| teruakohatu wrote:
| Are any efforts being made to incorporate this into VLC? Both
| as a receiver and caster?
| koen31 wrote:
| Not ongoing but certainly something I am open to.
| zozbot234 wrote:
| Not sure how useful that would be, since VideoLAN supports
| its own streaming solution
| https://www.videolan.org/vlc/streaming.html
| junon wrote:
| Question, is it named after the sites?
| akvadrako wrote:
| What about as a Kodi plugin?
| koen31 wrote:
| I have seen several attempts at this
| https://github.com/c4valli/kodi-fcast-receiver being one of
| them. There is not one provided by FUTO (for now).
| cobalt60 wrote:
| Any road map for Bandcamp and SoundCloud (logged in) support.
|
| Briefly looked at SoundCloud script js, for the moment it seems
| to be written to pull frontpage with basic API implementation,
| correct me if I'm wrong.
| brnt wrote:
| Thanks for taking this effort, I hope it takes off!
| mintplant wrote:
| The site talks about setting up a receiver, but I can't figure
| out how I would cast something _to_ an FCast receiver, or what
| is currently available to cast.
| koen31 wrote:
| We will do a better job explaining this soon and also provide
| binaries. For now there are a few possibilities:
|
| 1. Grayjay can cast to an FCast receiver
|
| 2. There are some terminal clients and a nautilus plugin, but
| we don't provide binaries (yet). These can be used to cast
| local media and remote media https://gitlab.com/futo-
| org/fcast/-/tree/master/client
|
| 3. Someone made a yt-dlp client that can cast to FCast:
| https://git.sr.ht/~shironeko/fcast/tree/yt-
| dlp/item/clients/...
|
| 4. Cloudfstream supports it: https://github.com/recloudstream
| /cloudstream/blob/master/app...
| viernullvier wrote:
| 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?
| koen31 wrote:
| 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 speaker I don't see
| why it wouldn't be possible with the FCast protocol.
| r-w wrote:
| This 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
| conclusion, but maybe Firefox and/or Brave would be interested in
| an integration?
| koen31 wrote:
| Very demo-y https://gitlab.com/futo-
| org/fcast/-/tree/master/clients/chro... but it works.
| westurner wrote:
| How does FCast differ from Matter Casting?
|
| https://news.ycombinator.com/item?id=41171060&p=2#41172407
|
| "What Is Matter Casting and How Is It Different From AirPlay or
| Chromecast?" (2024) https://www.howtogeek.com/what-is-matter-
| casting-and-how-is-... :
|
| > _You can also potentially use the new casting standard to
| control some of your TV's functions while casting media on it, a
| task at which both AirPlay and Chromecast are somewhat limited._
|
| Feature ideas: PIP Picture-in-Picture, The ability to find
| additional videos and add to a [queue] playlist without stopping
| the playing video
| koen31 wrote:
| 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.
| pzo wrote:
| 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 what languages bindings it
| supports.
| westurner wrote:
| GitHub has package repos for hosting package downloads.
|
| A SLSA Builder or Generator can sign packages and container
| images with sigstore/cosign.
|
| It's probably also possible to build and sign a repo
| metadata index with GitHub release attachment URLs and host
| that on GitHub Pages, but at scale to host releases you
| need a CDN and release signing keys to sign the repo
| metadata, and clients that update only when the release
| attachment signature matches the per-release per-platform
| key; but the app store does that for you
| koen31 wrote:
| The plan is that the FCast SDK will eventually allow you to
| cast (with a reduced feature set compared to FCast) to
| Chromecast, Airplay and others. Improving the download
| experience for users for sure is something we will look at.
| zigzag312 wrote:
| I'm not a native English speaker, but FreeCast would be better,
| more meaningful name in my opinion.
| boomboomsubban wrote:
| Already taken https://en.wikipedia.org/wiki/FreeCast
| zigzag312 wrote:
| Oh, that's unfortunate. Thanks for pointing that out.
| throwaway81523 wrote:
| I've used Icecast before. It worked great. Is Fcast better
| somehow?
| koen31 wrote:
| Had not heard of Icecast before, but it doesn't look like they
| have the same aim of having receivers on every platform
| (AppleTV, Roku, TizenOS, Android, Linux, MacOS, Windows, ...)
___________________________________________________________________
(page generated 2024-09-01 23:02 UTC)