I need to build a web based video player. Something like coursera/udemy. I would like to know the following.
Where we can store videos (Blob,Db..etc)?
Say I uploaded video in Blob storage. How can I make sure nobody is able to download this videos?
What should be an ideal video streaming architecture(BE+FE) if I am expecting 500 concurrent users?
Do I really need to build a video streaming Back End or I can simply use services like vimeo to get this done?
I inspected how Udemy is doing, i could find the following. It looks like they are using some blob to store videos. But when I tried to access this directly it says I cannot. How this works?
There can be no way to protect your video from a determined sophisticated hacker. In the very worst case, they can record the video from their screen using a iPhone.
You can learn more about blob: URL e.g. here. The bottom line: it's a browser-side object, it's not to store videos.
You definitely can use streaming services, but this will even further reduce your control. OTOH, it's not worth your effort to develop some new streaming architecture if you only expect 500 concurrent streams.
Related
I was able to successfully encrypt and decrypt the videos using AES encryption. It worked good for smaller videos while for the bigger files it gave us the memory out/Overflow exception. Is there a better way to safe guard the video files where only my application can have the access to it.
I am using this library "node-forge"
How are Video streaming apps like Netflix and Amazon prime are securing the videos locally, which are accessible only through their apps. If they are decrypting the whole file, how is the process so fast?
I was just wondering if we can just corrupt the file and de-corrupt while converting to base-64 ?
EDIT:
This is a E-learning application where videos are accessed through SD Card securely. These Videos should be secured and can be played in only our app.
You need to design your security measures based on your requirements which is a very complex process and you need to consider a lot of details. In one hand you need to design a suitable protocol for your application, and in the other hand you should try to make it secure.
As suitability of design, for example, you need to consider how you are going to playback your video or how much disk/memory you have. In cases like Netflix which they playback video while downloading, they they probably use streaming modes of encryption algorithms. But As I said, without understanding complete design of your application, suggesting encryption methods is somehow unethical.
Update:
If a simple encryption is what you need, I suggest you to use a streaming method(like CTR). In this case, you can decrypt your content on-fly rather than completely decrypting your files first. But you need to feed this content into your player. This may be a little problem if you have not written your own player. I did this once by hooking file read/write APIs and did similar thing that you need, so it is possible.
As you have said that you have successfully encrypted the smaller video files with AES, i will suggest you to break down your all files into small chunks (for example 512kb/1Mb parts file1.part1 or even give custom names so your app only knows which is part 1,2 and so on) and then encrypt each. During the decryption process decrypt each one after other to get the whole file or if you can create custom player do this on-the-fly.
I have an web page where users can view videos.
But the problem is when I inspect the page, it shows the video url.
So is there any idea how we can hide video source like youtube and other videos portal ?
There is no way to hide the video URL entirely without resorting to browser plugins. You can obscure it though, but in most cases they won't be worth it.
Using Media Source Extensions you can deliver segments of video data using obscured urls. And the URL won't be immediately visible in the source of the page. This is similar to what Youtube or Netflix does but requires massive engineering work on the backend. This is also the technique used to play MEPG-DASH with e.g. dash.js or shaka-player.
Set it using Javascript, so it's not viewable with view source, it won't help with inspecting though.
If your issue is people copying the stream URL and using it in their own players, then you might look at protecting it with some sort of tokens security. This is supported by almost any CDN out there, and there are plenty of open source systems to do it in most programming languages.
Lastly, if the issue is that you don't want anyone to copy the content, you can apply DRM protection. One of the easiest and straightforward ways to get started with that, might be using Azure Media Services.
I want to grant access to audio files for some group of people - now in the browser but in future in Ionic / Cordova app as well. But Access to them will be after authentication and I want to protect against downloading them.
What will be the best way to do it?
put files to some service for audio files - similar to youtube?
streaming from server - I use PHP?
use flash app?
Thanks for any solutions,
Similarly, to video files you can't prevent someone form downloading a file if you want to stream it to their device.
Ultimately, the file has to get to the device and there are many ways to store it even if you try to make it hard.
The usual approach to take is to DRM protect the files - this is commonly used by the paid music services.
Audio DRM is a little different from video, because most devices do not have a secure media pipeline for audio, which means it is a little less secure.
Ultimately, all these measures are hurdles and detergents - it generally ends up being as much a business solution as anything. If the user perceives that the cost is not too high for the service, or is low enough not to bother circumventing, then they are more likely to use it legitimately.
Is it possible to live stream video (& audio) without using the RTSP protocol? Today I tried out Adobe's Flash Media Server and the free alternative Red5. Both seemed like a bit of an overkill (plus had issues with Red5 not supporting AAC audio).
Basically I'm looking for a way to upload live video to my server so it can be viewed using jwplayer, and then stored so it can be viewed later. Does MP4 support live streaming? So that I can record it client-side then upload it for viewing?
I've been experimenting with uploading jpg images and using a HTML5 canvas to display them so it appears like a video.
Here's my code: (using only a few images)
http://jsfiddle.net/QM5EV/
There's several things wrong with it. For one, it's not efficient because it requires mass amounts of jpg's to be uploaded. And most importantly there's no audio.
What would be best to do? Is RTSP the only sensible choice? Thanks. :)
Live via HTTP servers is, for the most part, not an option. But there is "Apple Live Streaming" aka MPEG-TS, although that limits your clients to iOS devices. It uses a plain ol'web server. (This seems to be changing, increasingly desktop browsers are supporting MPEG-TS, but will probably take some time before it is common place.)
For online streaming, rtsp is the best solution. Other protocols such as RTMP ( http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol) but transmit to any multimedia content using RTSP.
Another thing is that you can make a specific streaming server accepts HTTP redirect requests. Thus, instead of URL's as rtsp://mydomain.com:554/myfile.mp4 can have URL's like http://mydomain.com/myfile.mp4
Regards!
So I have some videos in .flv format which I'd like people to be able to view from my site, without being able to download them. So far Flowplayer seems like the best choice for the actual flash player.
However, I've been looking into this video streaming thing, as its supposed to make the videos very fast to view and allows seeking to the middle of the video, etc. What do I need to make it work, do i need to have some special server software for this? And how can I integrate with this software using the javascript/PHP code that i'll use to display the videos?
Thanks.
Good news! You don't need special software, most reasonable web servers can do all of that out of the box. What you're describing, and what Youtube and the rest do, isn't streaming actually. It's called progressive download.
Basically the SWF player (flowplayer in your case) is downloading the FLV video, and playing what it has downloaded so far. To skip to some video that it has already downloaded, it seeks in the downloaded file. To skip beyond what has already been downloaded it discards the downloaded file and starts a new download, but it asks the HTTP server to start giving it the file at a certain offset. Thankfully, most HTTP servers can do this out of the box.
So you just need to put the FLV files somewhere that's publicly available to download via HTTP (just test this with your browser). Assuming you put flowplayer at /flowplayer.swf on your site, and the video is /2girls1cup.flv you would insert this into your page:
<script src="http://static.flowplayer.org/js/flowplayer-3.0.6.min.js"></script>
<!-- Edit this with the width and height to display the video -->
<a
href="/2girls1cup.flv"
style="display:block;width:425px;height:300px;"
id="player">
</a>
<!-- this script block will install Flowplayer inside previous anchor tag -->
<script language="JavaScript">
flowplayer("player", "/flowplayer.swf");
</script>
I took this example from the flowplayer demos page where there's lots more examples of lots of ways to customize flowplayer, the way it behaves and is displayed.
There are two ways in which an actual streaming server is better. One is for doing multicasts of a stream, in which all clients are at the same place in the video, which is easier on the server. The other is being able to deliver a number of different encodings of the same stream, so that, for example, clients can the video at a bitrate that best matches their playback capability.
A lot of companies bet a lot of money that this would be very important for video to take off on the web. It looks like all of them are wrong. Streaming servers are mostly used in the enterprisey world, which might explain their enterprisey prices.