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

daily-core and webrtc-daily #13

Open
pinkforest opened this issue Apr 20, 2024 · 3 comments
Open

daily-core and webrtc-daily #13

pinkforest opened this issue Apr 20, 2024 · 3 comments

Comments

@pinkforest
Copy link

It seems to miss daily-core etc. sources to build ?

@aconchillo
Copy link
Contributor

It seems to miss daily-core etc. sources to build ?

Unfortunately, that's right. We will publish those sources at some point, but I can't say exactly when.

@nickdichev
Copy link

@aconchillo Any update on releasing those libraries?

At work we are using the agora c++ sdk to interface with their network through a gstreamer-like application. I am evaluating Daily since a lot of the AI solutions being discussed really align with what we are building.

I am looking to evaluate how we can push data from this application into Daily. My understanding is that we need those libraries to build a wrapper of this package without the python specific stuff (our stack is in Elixir) or access to APIs to push h264/aac into Daily. We could also handle the RTP packetization in our pipeline though.

@aconchillo
Copy link
Contributor

Hi @nickdichev! Apologies for the delay, somehow the notification got lost in my inbox. Currently, daily-python is probably your only option. This will connect to Daily's backend servers (SFU) and you will be able to stream audio/video. This uses WebRTC so RTP packetization, jitter buffer, packet retransmission, etc is handled by the WebRTC stack.

I wrote an example that uses GStreamer a while back. It's basically a video player, it reads an MP4 file and sends it to the Daily room using daily-python: https://github.com/daily-co/daily-python/blob/main/demos/gstreamer/media_player.py

We have many customers who don't have a Python backend and what they do is spawn a Python process. But yes we are aware that the ideal solution is to make our internal Rust libraries public.

I hope this helps. let me know if you have any questions and I'd be more than happy to help.

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

No branches or pull requests

3 participants