I would like to implement video recording/playback/storage capability for my website. I'm done a bit of research, for HTML5 recording, there is RecordRTC which is based on WebRTC. For playback there's video.js. I want to be able to store them on s3 but I haven't figured out how.
1) Is this the best way to do it without paying for cloud based commercial ones such as ziggeo, nimbb and pipe?
2) are there any alternatives that i should look into?
3) how does storage work after recording using RecordRTC and uploading to s3? Do i need to do any sort of compression?
Any help would be great! Really appreciate it
Video recording is the future of all websites in our eyes - and by our I mean here at Ziggeo (full disclosure, I work at Ziggeo :) ).
In regards to recording there are many ways to do it and it is up to you to go with a specific one or implement all of them, so you could do it through Flash, WebRTC (https://webrtc.org/), or ORTC (https://ortc.org/).
We are currently offering you to record using WebRTC plus fallback with Flash and are working on implementing ORTC as well.
Now as mentioned above, there are many ways to do it and it is up to you, however it is up to your end users also since they might not be able to record over flash due to company policy or your website is on HTTP so you can not use WebRTC, etc.
With your own implementation you need to run the numbers and combine it all together (and work on keeping it up and running), while here at Ziggeo we do that for you and keep improving our SDKs and features.
Further more we also allow you to push the videos to S3 buckets, FTP, YouTube and Facebook - soon to DropBox as well.
So if you are like us, you will probably like to go down the road of do it yourself. If you however want to have time to work on your website, apps, and other things and just have the video, I do suggest using some service.
In regards to compression. It is good to mention that we do transcoding of all videos that are uploaded to our servers (You can see more here: https://ziggeo.com/features/transcoding). There is an original video that is kept and next to it the transcoded video (which can have watermark or some effects, etc. while it does not need to).
In general you want to 'standardize' the uploaded videos since different browsers will give you different video data containers and this would give you the upper hand so that it is easier to make adjustments to them later on for preview depending on the browser that is used.
To summarize:
1) - This depends on what kind of recording/playback and storage you need. If it is professional then using a service such as Ziggeo will help you focus on the important part of your service - like website design, functionality and similar, while if it is for fun and play you still have a free plan on Ziggeo, or you could get your sleeves up and do some codding :)
2) - I would personally look into WebRTC and ORTC if I was making implementation myself to see which one I would need more (or would be easier for me to implement). Once you find the one that you like, they usually offer some suggestions on their forums with what works best for them. (Be prepared however to need flash implementation at some point as well if it is business related setup)
3) It is best to standardize what you store in terms of resolution, video data containers and similar and often it is good to keep the original videos as well, so that you can always re-encode them if that is needed (which can happen in early stages of development).
Related
I'm trying to add a few videos to my website using HTML5. My videos are all 1080, but I want to give people the option to watch in a lower quality if needed. Can I do this without having to upload multiple videos (1 for each quality) without the usage of a server-side language?
I've been extensively searching for this. Haven't find anyone say that it can't be done, but no one said it can either. I am using Blogger as my host, which is why I am can't use server-side languages.
Thank you.
without the usage of a server-side language?
Yes, of course. The client can choose what version of the video to download.
Can I do this without having to upload multiple videos (1 for each quality)
Not practically, no. You need to transcode that video and upload those different versions.
Haven't find anyone say that it can't be done
A couple things to consider... first is that a video file can contain many streams. I don't know what your aversion is to multiple files, but yes it is possible to have several bitrates of video in a single container. A single MP4, for example, could easily contain a 768 kbps video, a 2 Mbps video, and an 8 Mbps video, while having a single 256 kbps audio track.
To play such a file, a client (implemented with Media Source Extensions and the Fetch API) would need to know how to parse the container and make ranged requests for specific chunks out of the file. To my knowledge, no such client exists as there's little point to it when you can simply use DASH and/or HLS. The browser certainly doesn't do this work for you.
Some video codecs, like H.264, support the concept of scaling. The idea here is that rather than having multiple encodings, there's just one where additional data enhances the previous video that was sent. There is significant overhead with this mechanism, and even more work you'd have to do. Not only does your code now need to understand the container, but now it has to handle the codec in use as well... and it needs to do it efficiently.
To summarize, is it possible to use one file? Technically, yes. Is there any benefit? None. Is there anything off-the-shelf for this? No.
Edit: I see now your comment that the issue is one of storage space. You should really put that information in your question so you can get a useful answer.
It's common for YouTube and others to transcode things ahead of time. This is particularly useful for videos that get a ton of traffic, as the segments can be stored on the CDN, with nodes closer to the clients. Yes, it's also possible to transcode on-demand as well. You need fast hardware for this.
No.
I can't fathom how this could ever be possible. Do you have an angle in mind?
Clients can either download all or part(s) of a file. But to do this you would have to somehow download only select pixels of each frame. Even if you had knowledge of which byte-ranges of each frame were which pixels, the overhead involved in requesting each byte-range would be greater than the size of the full 1080p video.
What is your aversion to hosting multiple qualities? Is it about storage space, or complexity/time of conversion?
It's been a long time since I've needed to build a streaming media solution for the web since there are so many good services providing basic needs. Ages ago I had done streaming deployments with Red5 and a frontend player like Flow or JW, but despite a lot of searching I haven't been able to determine what the best modern options are to achieve a simple web solution that has good native compatibility with mobile and desktop. I'm hoping someone can suggest a good open source stack that would be a good fit for what I'm trying to do:
Mobile + Desktop Web Audio Support (with the possibility of some video at some point)
Streaming (not live on-air streaming, but the ability to seek and listen without downloading the whole file and only buffering enough to for good quality as to not waste bandwidth)
Track how much of a stream has been listened to (not the amount downloaded)
Protecting streams (this should be pretty easy either using headers or URL patterns that expire the link/connection after a certain point of time by writing that logic into the server side but I wanted to mention it anyways)
Lightweight, maybe 10 to 20 concurrent audio streams for now.
My initial thought, since my knowledge in the streaming space is dated, was to do it with RTMP, RTSP or HLS and something like JWPlayer for the frontend, depending on which protocol seemed to have the best support across the most devices. Or, if the client side support is good I could probably skip the media server and go with psuedo-streaming via the webserver. On the server side I could handle the access control to the streams and on the front end player I could use the API to keep track of the amount of seconds played and just ping that data in a ajax request to keep track of how much has actually been listened too (as opposed to downloaded/buffered).
The thing is I have a feeling that is probably an obsolete way to go about it in 2017. Even though I haven't turned up anything specific yet, I had a feeling perhaps there was a better solution out there utilizing Node and perhaps websockets to accomplish the same thing with a server and player coupled more tightly (server aware of playhead/actual amount played vs front end only) or a solution that leverages newer standards (MPEG-DASH?). Plus, in the past getting the other streaming protocols to be compatible across all devices was a pain and IIRC there is no universal HTML5 support for any given one of the older protocols across all browsers.
So what are the best current approaches to tackle something like this? Is a media server + a front end like JW or Flow still one of the better ways to go or are there better/easier ways to deploy a solution like this?
Apparently I used the totally wrong keywords while googling because Im looking for solutions on how to embed videos in my webpage and still make "impossible" (i.e. make it hard) to download these directly as a mp4 file. I mean there are various players where you'll quite easily find out the original file on the webserver directly within the browser...
And on the opposite there are pages like youtube where you cannot really find out the full file but you'd have to use third party solutions to download the files.
Do you know any libraries / modules which support embedding in such a way like youtube?
Thanks
It really is not that hard to download/capture the file if you are making it available to stream to a device, even for YouTube videos, so you have to consider what your goals are.
Most content protection systems, or Digital Rights Management systems, don't really attempt to stop someone capturing the file. Rather they try to ensure that the captured file is of no use by having it encrypted so it cannot play back.
The tricky part then moves to securely sharing the decryption key with authorised users in a way that neither they nor a third party can view or share the key. This is the essence of nearly all common DRM systems.
If you do want to use DRM but don't want to pay for a full DRM solution then you could use clear key encryption with MPEG-DASH streaming. This essentially transmits the key with the stream so it not very secure, but it may meet your needs. There is some info on using it with a cloud encoding service here:
https://bitmovin.com/tutorials/mpeg-cenc-clearkey-drm-encryption/
I would like to have some info about apple's in-app purchases option.
I can't seem to find any place where they are explaining what is actually allowed. Becaus i wanted to make a digital bookstore with interactive books in asctionscript and offer the user interactive books (seperate swf files) via in-app purchases but apparently it is not allowed to have any code in your swf file, so that option is out of the window (btw if anyone knows of another option instead of swf files, please let me know).
Then have have thought of maybe starting in cocos2d but again i have no idea how i would distribute separate interactive books to the users. What are the options here?
So my questions are: what is allowed with in-app purchase, how can i offer interactive books (with posibility to click on elements and view animations etc) through in-app purchases.
And secondly and more important:
Would it be possible to do it via as3.0? Preferably i would like to do it through actionscript but can anyone tell me if its possible? Can i offer the user interactive books with elements that are pressable and animations etc through in-app purchases? And having all the books inside the application and unlocking them is not an option. I want to be able to provide books separatly.
Definitely on the right track,
I think if you are looking to do an animated books series or something that's more interactive that a simple text format you should be fine using In-App Purchases for this. You'll only get in trouble if you're duplicating something iBooks can already provide.
You'll need an ANE to give you access to the InApp Purchases API from AS3, there are a few out there and I'll shamelessly plug mine:
http://distriqt.com/native-extensions#in-app-purchase
The major problem you'll have is actually distributing the additional content, as you may not be able to load in a swf and play it in a compiled iOS AIR application as you would a normal flash/AIR application. You'll have to do some research and see if you can create a player that just loads images and animation sequences (in xml or other).
Good luck
1) You can't play swf files on the iPhone. Not without converting them to HTML5 or video. Which probably makes them non-interactive (not sure about HTML5).
2) Downloading any executable code to an iOS device is out of the question. There are some gray areas, for example downloaded Lua scripts which only contain data but due to their nature are executable code. It's a risk to do something like that, instead of just downloading XML or pure text/binary files.
3) Apple never tells you exactly what is allowed. They tell you what is not allowed, and even there they remain vague. There are always some gray areas and Apple reserves the right to define whether something in the grey area is acceptable to them or not. If you think your app is in the gray area, you need to have a backup plan in case Apple won't like it, or removes the app because they didn't initially find something wrong with it but later changed their mind.
4) Read the iOS Developer Program License Agreement and the App Store Review Guidelines. You may need to re-read some sentences because it's somewhat lawyer speak, though not really that hard to understand.
5) There are no guarantees. Best option: look at apps like yours and see if you can find your payment model implemented by other apps. If you find several such apps, it's most likely ok to do that. If you can't find any app that does something even remotely like you want to do it, beware.
6) I think you're on the wrong path. Use iBooks. Problem solved.
I'm looking for a way to securely deliver video to mobile devices. There are two options:
HLS in tag. This works very nicely for iOS and supports adaptive bitrate, perfect for mobile. However, is seems to only work well on iOS. There seems to be only fragmented support for it on Android. I've read that Android has officially supported it since 3.0, but on all the android devices I've tested (>3.0), HLS hasn't played back on the browser.
Progressive download in tag. This will work on iOS and Android devices fine, but the concern is that since it's just a progressive download of the video, that the user find a way to just grab that video once the browser has finished downloading it. This may be more difficult on iOS, but I'm sure it's not that hard to figure out where the browser stored the video download in a tmp folder somewhere.
Either method I'd say can be protected from deeplinking by using an expiring token approach, where the token is generated serverside with a secret key that only the content server knows about. The video request would only be valid for 5 or 10 minutes, would would kill of deeplinking.
Is anyone aware of any way around these issues? Even if I was able to prevent deeplinking, the user could still get the video itself and re-distribute. Perhaps it's just not possible?
Thanks
Rule #1 of the internet:
If you don't want someone stealing it, don't put it online.
Welcome to the circumvention arms race. Brought to you by DownloadHelper.
There's nothing you can do to stop someone who really wants to pirate your video. There are various measures, like those you mention, that make it more difficult, but someone who really wants to copy it could find a way to capture it from memory, or even just point a camera at the screen and record the playback of the video.
It's the same way you protect your car. You install a steering lock, an alarm and an engine immobiliser, and then someone comes alongs and pulls the car onto a flat-bed truck and drives away with it.
Bottom line - you can't stop a determined thief, but you can make theft more difficult so that you're not the most attractive target.
As I was reading the above I could easily get pass all these techniques pretty quickly.
For a project I can't describe too much because of nda, we created our own protocol based on a well known encryption method can't mention that either , military grade) , encoded packets on the server to the protocol, and decoded on the device.
unfortunately this isn't perfect either because a lot of mobile apps can be re-versed engineered and once you get the key game over, very easy on android, of course you could periodically recycle the key, in which case even if they decompiled the android app and got the key it wouldn't work very long.
This is a lot of work and can't be implemented with html5 or hLS or event rtsp.
It also requires a custom server application that takes the video stream re-transmits it with the custom protocol.
On the other hand the protocol was transport agnostic, which meant we could use a variety of transports, tcp, IAP and bluetooth. Also would work on all mobile / desktop platforms.
The other little requirement, is couldn't use a browser, have to be a custom app.