Streaming services such as Twitch or Youtube allow you to stream videos using the RTMP protocol, using an url and a "stream key/name".
Usually the stream url is in this form:
rtmp://rtmp.example.com/live
And the stream key
123456789abcdefghij
but in the end, the url used by streaming softwares is actually :
rtmp://rtmp.example.com/live/123456789abcdefghij
Is it only security though obscurity ? The streamkey should be very easy to get trough network sniffing.
Is there a security layer I'm not aware of ?
Is there a security layer I'm not aware of ?
Yes, but it doesn't have a ton of use. RTMPS is RTMP over TLS. Facebook Live supports it. I don't think Twitch does. I thought YouTube did, but I cannot find a reference to it at the moment.
Without this, you're absolutely correct in that the connection can be sniffed. As #szatmary says though, these keys are generally one-time-use keys making this not really an issue.
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 need some help.
What is the best way to set up LIVE STREAMING over the web from my WEBCAM to the server and back to multiple users?
Essentially I'm trying to create a group video chat application that can support many users.
I don't want it to be peer to peer webRTC.
I actually managed to make it work with getUserMedia() -> mediaRecorder -> ondataavailable -> pass blob chunks to node.js via SOCKET.IO -> socket.io sends back blob chunks to other connected users -> append those chunks to a sourceBuffer that's connected to a mediaSource that's set as the source URL on a
And it actually worked! BUT it's so slow and laggy and resource intensive. As these chunks get passed like 20 per second and it's slowing the page a lot. I don't think you're supposed to pass that many blobs to the sourceBuffer so quickly. Just for a test I tried saving mediaRecordings every 3 seconds (so it's not that resource intensive) and passing those webm blobs to the sourceBuffer but for some reason only the first webm loads, and the other ones don't get added or start playing.
It just can't work for a production app this way.
What's the "RIGHT" way to do this?
How to pass a video stream from webcam to a Node.js server properly?
And how to stream this live stream back to the web from the Node.js server so that we can have a group video chat?
I'm a bit lost. Please help.
Do I use HLS? RecordRTC?
Do I stream from Node.js via http or via socket.io?
There are services that already let you do that easily like vonage video api tokbox but those seem to be very expensive?
I want to run the video streaming through my own Node.js server that I control.
What's the best way to do this?
Please help.
Thank you
Essentially I'm trying to create a group video chat application that can support many users.
I don't want it to be peer to peer webRTC.
Video chat requires low latency, and therefore requires usage of WebRTC. Remember that one of the "peers" can actually be a server.
And it actually worked! BUT it's so slow and laggy and resource intensive.
Video encoding/decoding is resource intensive no matter how you do it. If by "slow" and "laggy" you mean high latency, then yes, recording chunks, sending chunks, decoding chunks, will have higher latency by its very nature. Additionally, what you're describing won't drop frames or dynamically adjust the encoding, so if a connection can't keep up, it's just going to buffer until it can. This is a different sort of tradeoff than what you want.
Again, for a video chat, realtime-ness is more important than quality and reliability. If that means discarding frames, resampling audio stupid-fast to catch up, encoding at low bitrates, even temporarily dropping streams entirely for a few seconds, that's what needs to happen. This is what the entire WebRTC stack does.
As these chunks get passed like 20 per second and it's slowing the page a lot. I don't think you're supposed to pass that many blobs to the sourceBuffer so quickly.
No, this is unlikely your problem. The receiving end probably just can't keep up with decoding all these streams.
Do I use HLS?
Not for anyone actively participating in the chat... people who require low latency. For everyone else, yes you can utilize HLS and DASH to give you a more affordable way to distribute your stream over existing CDNs. See this answer: https://stackoverflow.com/a/37475943/362536 Basically, scrutinize your requirements and determine if everyone is actually participating. If they aren't, move them to a cheaper streaming method than WebRTC.
RecordRTC?
No, this is irrelevant to your project and frankly I don't know why people keep using this library for anything. Maybe they have some specific use case for it I don't know about, but browsers have had built-in MediaRecorder for years.
There are services that already let you do that easily like vonage video api tokbox but those seem to be very expensive?
This is an expensive thing to do. I think you'll find that using an existing service that already has the infrastructure ready to go is going to be cheaper than doing it yourself in most cases.
Good day! I'm a newbie on video streaming. Can you help me find good ways on how to make a video streaming secure?
I'm having some issues on my video hosting project security.
I am creating a web page which calls a video stream hosted on a different server where
my web page is deployed.
Server 1(web page video embed) calls video to stream on Server 2(video host).
The problem is that they are hosted on an absolute different network. Should Server 2 where the video is hosted should be private and only allow Server 1 to fetch the video stream creating a server to server transfer of data, or should it be public for the clients to be able access it.
Can you help me decide what to do to secure my videos?
I badly need some idea on this... thanks guys!
How are you streaming and what streaming protocol are you using?
Server to server wont help in securing the video.it is better to stream the video direcly from your Server 2(video host) directly to the client,so that it wont be overhead for server 1(web page video embed).You need to use secure way to protect you video on server 2.if the server2 is not secure,even if you stream through server1 it wont help.
Here are details of security level on different video streamings.
If you are using progressive download.This can be done using normal http protocol.In this approach you would be able to see the video url in the browser.Once you got the url you can download it as a normal file download.Security is very low here.Even if you sign the video url,the user can download the video easily.
Streaming,you can stream the video using different protocol like rtmp etc.If you are streaming videos using some rtmp.In this approch, you wont be able to download the video directly,but you can use some good software to capture the video stream and save to the pc.
Streaming securly.There are some protocols like rtmpe.I tried only rtmpe,In this protocol,the streaming content will be encrypted on the server and decrypted on the client.so the software wont be able to capture the video stream.
Along with approach 3,if you sign the video url,it will add more security.Hope this helps.
I'd like the .mp3 files being streamed inaccessible to the listeners, but without having to sacrifice mobile compatibility. Which protocol would be best for that?
There is no such thing as inaccessible streaming. How are you going to stream if it is inaccessible? :) If a user can listen to any song via streaming, it is accessible to user.
If you are trying to prevent users from recording or downloading .mp3 files for your stream, you are falsely thinking security through obscurity. If a device can get a data over a network and play it, there is surely a way record the data. It's either by capturing the network traffic, or reverse-engineering your application to understand the protocol you are using to play songs. Whatever you do to obscure your protocol, it will surely be reverse engineered.
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