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

1–10 of 67 posts

Re: FCast: Casting Made Open Source

#4

Post by nsteel »

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

Re: FCast: Casting Made Open Source

#7

Post by oezi »

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?

Re: FCast: Casting Made Open Source

#8

Post by justinclift »

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.

Re: FCast: Casting Made Open Source

#9

Post by nsteel »

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…

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

Re: FCast: Casting Made Open Source

#10

Post by justinclift »

nsteel wrote: post #9
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…

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 media top box.
Is my reading of this wonky? :)
Post reply on HN