Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clarification on the possibilities project #30

Open
Florent4223 opened this issue Apr 8, 2020 · 15 comments
Open

clarification on the possibilities project #30

Florent4223 opened this issue Apr 8, 2020 · 15 comments

Comments

@Florent4223
Copy link

Hello

I saw the project and I find it very interesting.
On the other hand I would like a clarification on the possibilities: on an Android is it possible to send the video stream on nympcast server and then broadcast it in an rtmp or other stream?

thanks

@MayaPosch
Copy link
Owner

Hello, and thank you for your interest in the project!

The current capabilities and features are listed in the Readme for the project. At this point RTMP streams can be played back on the NymphCast server. I imagine that server functionality (along with transcoding) would require a significant amount of work.

I'll of course gladly accept ideas and pull requests :)

@Florent4223
Copy link
Author

Florent4223 commented Apr 8, 2020

thank you for your reply
I read readme but I needed more information.
typically instead of (or in addition) redirect the flow to the RPI's hdmi port, could we redirect it to a flow software for example FFMPEG or GSTREAMER?
on readme : "3rd party audio / video streaming protocol support on the server side" as...ffmpeg or gstreamer?

I am working on a project (on a RPI4) with gstreamer which generates an RTMP stream from a camera. This flow is then processed by an NGINX server for broadcasting.
Ideally the idea would be to keep roughly the same architecture as possible to broadcast the camera of a smartphone.

@MayaPosch
Copy link
Owner

NymphCast already uses ffmpeg internally, which means it's mostly a matter of implementing code that exposes this functionality. At this point such a feature has not been planned, however.

@Florent4223
Copy link
Author

thank you for your return.
Can we interact on the ffmpeg command line directly in the code?

Personally for my project I planned to use chromecast (out of spite) ... I would much prefer to use yours.
If there is a direct possibility to modify the processing of ffmpeg and if you can tell me where in the code, I can test in this direction.

@MayaPosch MayaPosch added this to In progress in NymphCast Server Apr 13, 2020
@MayaPosch MayaPosch moved this from In progress to Questions in NymphCast Server Apr 13, 2020
@gabrielstuff
Copy link

Hello,
The project looks fantastic and I will certainly try it. From what I understand it aims at replacing closed source solution from industrial such as Google Chromecast and other Anycast Miracast compatible devices.

What I'd like to know, if it is compatible with a specific standard, or is it a complete new solution that could be integrated in the device of our choice and in the app of our choice.

i.e:

  • I need to develop or add the capabilities to stream to nymphcast on my existing mobile apps
  • I need to integrate the nymphcast in my desktop app in order for my user to stream from my mobile app

Thanks a lot for the clarification. I'm sorry if I miss something somewhere, I did not find any piece of information regarding :

Miracast / Unicast / Chromecast / Airplay

Thanks a lot !

@MayaPosch
Copy link
Owner

MayaPosch commented Oct 27, 2020

@Florent4223 Sorry for taking a while to answer. Could you summarize your requirements if you are still interested in such a solution?

@gabrielstuff NymphCast uses its own (RPC-based) protocol. There is no compatibility with other systems as they're either proprietary or overly complicated to implement.

The NymphCast client library is the current C++ reference implementation for client-side communications with a NymphCast server (receiver). The 'client' implementation shows how to use it in a CLI application, with the Qt-based NymphCast Player showing integration of it in a GUI-based application.

An Android-based client is also under development that uses the NDK with the client library.

@Ramblurr
Copy link

NymphCast uses its own (RPC-based) protocol. There is no compatibility with other systems as they're either proprietary or overly complicated to implement

I came to this issue looking to see if the existing android apps I have with a Google Cast button (spotify, NPR, other radio apps) could cast to a NymphCast server without support from the developer. Your quoted reply seems to indicate that this is not possible. Is that correct?

@MayaPosch
Copy link
Owner

@Ramblurr That is correct. ChromeCast protocol receivers ('servers') require authentication by clients (like the Spotify app) using secret keys that only Google knows. This means effectively that implementing one's own ChromeCast receiver is impossible.

In NymphCast the idea to circumvent this in two ways: a) by allowing these client apps to also implement NymphCast support, and b) by using NymphCast server-side apps to provide access to these services without first-party app support.

As an example, there's a SoundCloud app in NymphCast that allows one to search and play back all publicly available music on that service. This can be extended to other services, including Spotify, Netflix, YouTube, etc.

I hope this answers your question :)

@Ramblurr
Copy link

Brilliant @MayaPosch, it definitely answers my question. I didn't realize the chromecast protocol was so locked down, I figured it would just take some reverse engineering.

Looking forward to NymphCast's future!

@MayaPosch
Copy link
Owner

Thank you, @Ramblurr :)

Back with the CastV1 protocol (based on DIAL) it was possible to write one's own client and server, but with the v2 protocol which Google introduced with ChromeCast v2, they use a full authentication chain with secret keys.

Some references on the v2 protocol:

The receiver authentication challenge-response:
https://blog.oakbits.com/google-cast-protocol-receiver-authentication.html

Essentially, while even a DIY client can authenticate that a receiver is genuine, a genuine client (using the Cast SDK) will reject anything but a genuine receiver (providing the correct response). In addition, the actual Cast apps (Netflix, Spotify, etc.) are loaded from remote servers (HTML & JS), which appear to have their own authentication checks and secret keys for backend APIs.

@mapl
Copy link

mapl commented Feb 21, 2022

I am wondering how VLC does it, since it can stream media to a Chromecast? I am also using https://airflow.app/ which works very well.

@MayaPosch
Copy link
Owner

@mapl Streaming to a ChromeCast instance is a supported feature, it is the 'build your own receiver' part that's impossible, unless you want to build the equivalent of a first-gen ChromeCast with the v1 DIAL protocol.

@mapl
Copy link

mapl commented Feb 21, 2022

I didn't catch that. Thx! :)

So the nymphcast receiver could not just output the stream to a directly attached Display or GUI, but also stream to a Chromecast?

@MayaPosch
Copy link
Owner

Yes, that would be a possibility, just like streaming to e.g. DLNA or RTMP devices, I guess. This falls outside the use cases of NymphCast, of course.

@mapl
Copy link

mapl commented Feb 21, 2022

This would still be a neat extension to the Project to have an Output or Render Plugin for the NC receiver :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
NymphCast Server
  
Questions
Development

No branches or pull requests

5 participants