[HN Gopher] FCast: Casting Made Open Source
___________________________________________________________________
FCast: Casting Made Open Source
Author : icar
Score : 118 points
Date : 2024-08-28 05:23 UTC (2 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.
| 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)
| _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...
| 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).
| 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.
| koen31 wrote:
| FCast engineer here. Look forward to FCast receivers on platforms
| like AppleTV, Roku, Tizen (Samsung), WebOS (LG).
___________________________________________________________________
(page generated 2024-08-30 23:01 UTC)