My app is able to stream Shoutcast stations, however today I found out that some of the stations use server version 1.9.9beta and my app can't start streaming them, it just fetched header information. There must be an important change between previous server versions. Does anyone aware of this change?
1.9.9beta server cannot handle "Range" header. This is a bug on the server.
Related
I created a web app to let people communicate. I want to implement screen sharing and audio calls.
My current app is programmed in NodeJs and uses express and socket.io to serve the client connection and open a socket connection. I want to stream video and audio. My problem with WebRTC is that all those who connect to a call are vulnerable to a DDoS attack since it is p2p. I found an article from Discord explaining how they managed to let the entire traffic go through their servers: https://blog.discord.com/how-discord-handles-two-and-half-million-concurrent-voice-users-using-webrtc-ce01c3187429, that's exactly what I want to achieve.
Could I possibly use socket.io-stream https://www.npmjs.com/package/socket.io-stream ? I didn't yet figure out how, and it seems like all socket.io streaming libraries are made for file upload/download, not for actual video/audio streaming.
If that doesn't work, a library such as what Discord managed to make would be the perfect solution, since all traffic is proxied, and not p2p. Though I couldn't find any of those libraries, maybe I'm just looking for the wrong thing?
Best regards
You will want to use a SFU.
Each peer negotiates a session with the SFU. They then exchange media through it. Each Peer will just communicate with the server. It has lots of other benefits and is what most WebRTC deploys today use.
There are lots of Open Source SFUs out there. You can even build your own with Open Source libraries.
I've got a rather vague question, but I'm hoping for some help.
I have icecast installed on an unbuntu server, with two server blocks setup using nginx.
Icecast is set to stream on https://stream.domain.com:8443/stream
I have a node.js app running on https://app.domain.com
Is there a way to "listen" to the icecast domain/stream/port using node and start a function when the stream starts, and stop it when the stream stops?
I'm not hoping for a full solution, just clues to point me in the right direction! Thank you in advance.
Make a request to
https://stream.domain.com:8443/status-json.xsl
it will return a JSON status of the server, then see the "source" key in this JSON - not empty "source" will indicate that there is a source connected to the server and Icecast is broadcasting something.
That JSON also provides a lot of additional info you can also use.
Also a basic check is to try to connect to port 8443 - if connection is not happening in, say, 5 seconds - that will indicate that Icecast is completely down.
I've been researching a lot on how to live stream frames coming from the camera on browser, to a node server. This server processes the image, and then is supposed to send the processed image back to the client. I was wondering what the best approach would be. I've seen solutions such as sending frames in chunks to the server, for the server to process. I've looked into webRTC, but came to the conclusion that this works more for client to client connections. Would a simple implementation such as using websockets, or using socket.io suffice?
You can use WebSockets. But, I'd not recommend it. I don't think you should drop WebRTC, yet. It's not just for client to client connections. You can use a MediaServer like Kurento or Jitsi to process your frames and return the output. I've seen Kurento samples for adding filters and stuff. You can build your own modules on how to process the frames. I'd recommend that you check the MediaServer and see if it fits your requirements. Use WebSockets only if you are sure that WebRTC doesn't work for you.
I using RTSP for transmitting video from server to client.
At some points during the transmission I need the server to "send" metadata to the client (some information that something was changed).
I need the sessions to be fully "standard" (VLC should be able to display the video).
I thought of sending DESCRIBE to the server at some interval from the client and using the SDP data to contain the relevant information.
Is it a "standard" approach? shouldn't the DESCRIBE be used for initialization purposes only?
Thanks.
According to the RTSP standard the DESCRIBE method simply describes the URL in the request and should only be used for that purpose. Try using GET_PARAMETER method or use extensibility features of RTSP.
RTSP Draft 2.0 has support for PLAY_NOTIFY although I am not 100% sure that is what you need, you may just need to be able to have a server which is capable of sending an Announce from the Client to Server when the media changes... or that may be encompassed by just using dynamic as the payload types and specifying an additional payload type in the SDP...
My media server implementation should handle this easily and contains a RtspClient which may help also!
http://net7mma.codeplex.com
I've been reading lately about Node.js, Websockets and Socket.io out of curiosity. However, the other day I was thinking of a problem one of my client faces and was wondering if they may be the solution. Essentially, there are two servers. Server 1, is serving raw binary data. Server 2, is setup to receive and handle that binary data.
What needs to happen is data from server 1, is passed through a web browser and then delivered to server 2.
I'm curious to know if this is possible, and what angles you may take to solve it?
It's certainly possible. The connections to both will need to be initiated from the browser/Javascript, but once in place it should be easy to proxy the data from one to the other.
However, there are many non-browser WebSocket clients so you might consider just making a direct WebSocket connection from one server to the other. See this wikipedia page for WebSocket client (and server) implementations.