Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FCast: Casting Made Open Source

fcast.org

Post reply on HN
Print view View original

11–20 of 67 posts

Re: FCast: Casting Made Open Source

#11

Post by nsteel »

justinclift wrote: post #10
nsteel wrote: post #9

Earlier quoted context omitted.

What in the above makes you think that? The receiver is the "server". Playback happens on the "server" (just like mpd, if that helps).

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 me…

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.

Re: FCast: Casting Made Open Source

#12

Post by pihug12 »

_volatile wrote: post #5

Is it currently usable in anything other than GrayJay? I wish I could use this with local videos.

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...

Re: FCast: Casting Made Open Source

#13

Post by ravenstine »

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.

Re: FCast: Casting Made Open Source

#14

Post by bastawhiz »

justinclift wrote: post #10
nsteel wrote: post #9

Earlier quoted context omitted.

What in the above makes you think that? The receiver is the "server". Playback happens on the "server" (just like mpd, if that helps).

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 me…

> the bulk of the transmitted data is from the "client" to the "receiver"?

This is not new or novel. See: SMTP

Re: FCast: Casting Made Open Source

#15

Post by riedel »

justinclift wrote: post #8

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 receiv…

Speaking of terminology. I open the discussion because I thought the title was about the manufacturing process (casting with a mold).

Re: FCast: Casting Made Open Source

#16

Post by riedel »

nsteel wrote: post #4

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

Why not use straight UPnP (DLNA). Tons of open source there. The only problem was standardising codecs (also related to the Chromecast spinoff)

Re: FCast: Casting Made Open Source

#19

Post by koen31 »

oezi wrote: post #7
nsteel wrote: post #4

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

I wonder what is their ecosystem play? Why would Netflix implement this in their app? Why would any TV manufacturer?

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.

Re: FCast: Casting Made Open Source

#20

Post by r-w »

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?

Post reply on HN