I want to use an HTML5 video player and stream videos. Is this possible with S3/CloudFront? I understand Amazon uses the RTMP streaming protocol and HTML5's video tag does not support RTMP. Is there any way to stream videos with HTML5 players?
Much of what #Wayne Koorts posted provides the basis for a good answer. The disconnect it seems is that you can "stream" video via progressive download. This works with any html5 compatible video file, as he illustrated.
In order to get the best performance in a progressive download of mp4 files, you need the moov atom meta data to appear at the beginning of the file. Insuring that your mp4 files have this property is one of the reasons that the qtfaststart program is included with ffmpeg.
Of course, progressive download is not a "streaming media server". Streaming media servers were designed to support a number of different features including:
Security and DRM
Adaptive streaming/interleaving (support for multiple bit rates interleaved into a specific file)
Seeking
It seems the particular concern expressed here is the seeking feature. As it happens this is supported fine in html5 and by s3/cloudfront.
What is confusing is that cloudfront of video files has several options. One option is to have the files delivered by their network of licensed Adobe FMS servers. This is where the confusion about the use of RTMP comes into play. However, that is only an option. Files can be distributed to cloudfront in standard "download" form and they will have the seeking property due to the implementation of byte ranges and support for what is popularly known as pseudo streaming.
There seems to be a lot of confusion about the term "Pseudo streaming" but in the case of html5, it's simply the requirement that the HTTP server supports the 1.1 specification. When seeking, the client sends a byte range request and the server is responsible for delivering that portion of the file.
In other words... seeking with the html5 player does work with the cloudfront servers because they are HTTP 1.1 compatible.
As for some of the other functions that streaming servers provide, there are a variety of competitive servers that have implemented "H264 streaming" or elements of MPEG-DASH as an alternative to the use of RTMP and FMS compatible servers. A number of flash based players support these functions, which go above and beyond simple seeking. The JWPlayer and Flowplayer are 2 examples of players that support some or all of the features, however HTML5's video player has no support for any of these features. You can learn more looking at http://h264.code-shop.com/trac#H264StreamingModuleIntroductionversion2
If that's not enough confusion for you, Apple implemented their own "HTTP Live Streaming" protocol, sometimes known as m3u8, which they support in ios and quicktime. I mention this because frequently people want a way to support a variety of different devices.
I hope this helped clarify things a bit.
Something I have done successfully recently is to use the Video.js HTML5 player (open source) video player, with videos hosted on S3. Basically you just upload your video into your S3 bucket, then the code on the page looks something like this (after including the Video.js CSS and JS files into your page):
<video id="example_video_1" class="video-js vjs-default-skin"
controls preload="auto" width="1600" height="900"
poster="http://mys3bucket.s3.amazonaws.com/videoImage.jpg"
data-setup='{"example_option":true}'>
<source src="http://mys3bucket.s3.amazonaws.com/myvideofile.mp4" type='video/mp4' />
<source src="http://mys3bucket.s3.amazonaws.com/myvideofile.webm" type='video/webm' />
</video>
poster is just the still image to display on the video player while the video is loading or not playing. As for the <source> tags, you can link as many or as few of these as you have videos for. More formats just means better support across different platforms (e.g. some vanilla Linux distributions may not play MP4 etc.).
See the Video.js quick start guide here.
When deciding whether to use S3 or CloudFront: IMHO S3 is more appropriate for video in general because the cost is cheaper when you're storing a lot of data (because CloudFront distributes copies of everything to all of its edge servers, although you can limit that somewhat via options). Some people do prefer CloudFront though due to the speed, although remember CloudFront is intended primarily as a content delivery network where super fast response times are required (e.g. for site graphics, stylesheets, JS files etc.), so it's a trade-off depending on your needs. If your videos are all very small then you may find CloudFront actually is appropriate for your needs.
For analysing costs more definitively you can use Amazon's monthly cost calculator.
I am working on some video stuff for a global production. I need to keep cost down but I am looking to be easily scalable and enough features to deliver a pretty complex system securely. AWS seems great, been using them for a few years now and I think the S3 Buckets are amazing. They are free, to a limit. And yes. They certainly do succeed in providing what I believe is streaming video; in that it is housed in S3 and it plays right into my JWPlayer immediately on page load with no jitters or latency.
I can see some of the streaming video delineations are vague and still confusing for me, although #gview did a great job providing us with deeper incite. The complexity of it interest me, but if your agenda is to get that video going, I do not believe HTML5 is your answer. SOAP, REST, HTTP, and even HTTPS are supported and provision-able as far as I know. The documentation at AWS is noteworthy also, very helpful. I will attach a start link here.
# user2352370 : JWplayer..I am undecided. I just purchased the middle tier membership and now upon reading Wayne Koorts above, I think JSvideo is better for a variety of reasons and I will be working with that if I can get a refund. I am not seeing any immediate value in JWvideo, past the styling it provides for the videos. I believe the JWvideo's value to me at least, is limited to the styling of the video. I can use JSVideo to create a variety of fall-backs easily for multiple device and browser types. I can style the JSVideo even, but maybe something is to be said for the simplicity of JWvideo. I am probably going to need it for the onslaught of video post I will have in the months ahead.
Both JWVideo & JSVideo Will Work
I think JWVideo and JSvideo both will do the job, I currently have both on my site for various videos and both do a decent job, have not tested browsers very deep yet though.
Do create a Free AWS account and play with the services for free. Its pretty eye opening if you have been dealing with providers like RackSpace or Host Gator for a while.
AWS Free Tier HomePage
AWS Documentation Site for S3
Was looking at AS3 for hosting videos with VideoJS for my own site and that's why I found your question but when I looked at the example code for VideoJS I noticed that the link was at a company called ZenCoder - http://video-js.zencoder.com/oceans-clip.mp4
http://zencoder.com/en/
I have no association with Zencoder but presumably worth considering if you're looking for cloud based video hosting.
Related
I notice (by looking at the Chromium network tab) an annoying phenomenon of many Web sites that include videos implementing video playing by sending many small video chunks, with the user (behind the Web browser) not aware of this and even being capable of seeking through the video and seeing the current "position" in the video's reproduction relative to the start and end.
What is the professional term/jargon used for this?
Some existing questions that talk about or mention such Web videos:
Play multi part video without interrupts (HTML5)
Chunk audio/video files for web
Are html5 streamed videos cacheable?
videojs: Download/stream video in chunks with quality selecton
How does video on demand work in Youtube?
The term your probably looking for is “Adaptive Streaming” or “Adaptive Bitrate Streaming”. Or maybe you are looking for names of implementations like “DASH” or “HTTP Live Streaming”
Also, it’s not an “annoying phenomenon” it’s a technique that allows for live streaming media with an undetermined length that can adjust to each users internet connection without using expensive media servers and can leverage existing CDNs and caching infrastructure.
In short, I want to record presentation audio, create time markers for that audio in a database, and then provide marker-navigation of that audio content from a web page. What technology (e.g. HTML5 Audio, RTMP) can support this?
My requirements in more detail:
quickly navigate to server-side marked points in server-stored audio, from the browser.
avoid any proprietary client-side software, such as Silverlight; although due to penetration Flash is acceptable, and future-looking standards like HTML5 media are acceptable, provided it ships with the latest browsers.
prefer to leave the 30-50 minute audio files un-split rather than pre-splitting on the selected markers; so that the markers can be seamlessly changed later.
like to keep licensing cost minimal; although single-purchase licensed server-side technologies are fine.
prefer to do most of this from IIS, where I have most experience. however, a parallel streaming server such as Adobe with Windows APIs is acceptable.
Here are my best guesses on a solution so-far:
the presentations will be compressed and stored in mp3 files (but really, any advice on an easily seekable format for speech recording is welcome).
the client will play a unicast stream rather than download file chunks (although TBR, below, challenges this assumption)
HTML5 is not ready, so flash will be required at the client
IIS Media Services is no-go as it requires Silverlight for seekable audio
The leading products in this space, such as Adobe Media Server 5, are probably large kits with their focus on video media. I can probably find a more focused tool like Icecast to reliably do what I need.
OK, I'll bite. I went and looked for how people actually address this, and it's how I said it is in my comment.
Setting HTML5 audio position (it's so close it almost makes this question a dupe)
I've also found this nice blog post from 2009 that describes the further technical possibilities and options. The latter part revolves around advanced video use cases and Ogg, but the first part should apply just fine to <audio>.
http://gingertech.net/2009/08/19/jumping-to-time-offsets-in-videos/
I want to embed an RTMP Live Stream in a HTML document. I want to use HTML5 instead of flash (That it can work under *nix/osx/mobile devices).
How can I do this? Do I need to use 3rd party libraries? When yes: Can you recommend one?
I've found an answer on StackOverflow but it wasn't very helpful. Since the answer was from 2011 I guess it's okay to ask this question again.
RTMP was designed for Flash and works with Flash. I'm not aware of a way to embed it in HTML5 without a Flash engine.
Considering the above you could:
write or find a specialized player that can talk to a RTMP server and
play the stream without Flash, but this beats your intention of
embedding the video in a web page
or
create two streams based on the same source for each target device. This can be achieved by transcoding the source material in multiple formats or live transcoding and re-streaming of the RTMP source. You could use HLS as an alternative protocol which is supported on a greater number of platforms, even if it has its hiccups with certain versions of Android (especially 4.4.3 and 4.4.4)
There are paid and freeware solutions for RTMP re-streaming, like Nimble or Wowza Streaming Engine to name a few.
I'm trying to figure out if web based audio streaming sites use the Web Audio API for playback or if they rely on the audio element or something else.
Since the user of an audio streaming service typically doesn't need more functionality than starting and stopping the audio, then I guess that the audio element is enough. If a VU-meter is required then I would guess the Web Audio API would be used since it has an built in analyser node. But since IE doesn't support the API then I suppose you'd rather use the audio element and reach the IE users than using fancy extras such as an VU-meter.
I've been looking at the source code for Spotifys web player, Grooveshark, BBC radio and the Polish public radio but I find neither audio elements or use of the Web Audio API. I did find that the Swedish public radio (sr.se) makes use of the audio element though.
I'm not asking for anyone to go through the JavaScript source code for me, but rather if someone who is familiar with the subject could point me in the right direction.
I don't know of any internet radio services playing back their streams with the Web Audio API currently, but I wouldn't be surprised to find one. I've been working on one myself using Audiocog's excellent Aurora.js library, which enables codecs in-browser that wouldn't normally be available, by decoding the audio with JavaScript. However, for compatibility reasons as you have pointed out, this would be considered a bit experimental today.
Most internet radio stations use progressive HTTP streaming (SHOUTcast/Icecast style) which can be played back within an <audio> element or Flash. This works well but can be hard to get right, especially if you use SHOUTcast servers as they are not quite 100% compatible with HTTP, hurting browser support in some versions of Firefox and a lot of mobile browsers. I ended up writing my own server called AudioPump Server to get better browser and mobile browser support with HTTP progressive.
Depending on your Flash code and ActionScript version available, you might also have to deal with memory leaks in creative ways, since by default Flash will keep all of your stream data in memory indefinitely as it was never built to stream over HTTP. Many use RTMP with Flash (with Wowza or similar on the server), which Flash was built to stream with to get around this problem.
iOS supports HLS which is basically a collection of static files served by an HTTP server. The encoder writes a chunk of the stream to each file as the encoding occurs, and the client just downloads them and plays them back seamlessly. The benefit here is that the client can choose a bitrate to stream and, raising quality up and down as network conditions change. This also means that you can completely switch networks (say from WiFi to 3G) and still maintain the stream since chunks are downloaded independently and statelessly. Android "supports" HLS, but it is buggy. Safari is the only browser currently supporting HLS.
Compatibility detection is not something you need to solve yourself. There are many players, such as jPlayer and JW Player which wrangle HTML5 audio support detection, codec support detection, and provide a common API between playback for HTML5 audio and Flash. They also provide an optional UI if you want to get up and running quickly.
Finally, most stations do offer a link to allow you to play the stream in your own media player. This is done by linking to a playlist file (usually M3U or PLS) which is downloaded and often immediately opened (as configured by the user and their browser). The player software loads this playlist and then connects directly to the streaming server to begin playback. On Android, you simply link to the stream URL. It will detect the Content-Type response header, disconnect, and open its configured media player for playback. These days you have to hunt to find these direct links, but they are out there.
If you ever want to know what a station is using without digging around in their compiled and minified source code, simply use a tool like Fiddler or Wireshark and watch the traffic. You will find that it is very straightforward under the hood.
We use Web Audio for streaming via Aurora.js using a protocol very similar to HTTP Live Streaming. We did this because we wanted the same streaming backend to serve iPhone, Android and the web.
It was all a very long and painful process that took over 6 months of effort, but now that its all finished, its all good.
Have a look at http://radioflote.com and feel free to shoot questions or clarifications regarding anything. Go ahead and disassemble the code if you want to. Not a problem.
I want so serve some videos on my site. They are available as .MP4 files gotten from a FlipShare camera.
Now I tried converting them to WMV (which succeeded, but when embedded in html in a <object id='mediaPlayer' width='320' height='285' classid='CLSID:22d6f312-b0f6-11d0-94ab-0080c74c7e95' etc' tag, users have to install an addon and the user experience of 10 Windows Media Players on the site isn't just so good.)
So then I looked at youtube and wondered how they do it, but I can't figure out what format they convert the video to.
So my question is: What format do I have to convert my video to, to show it in a player which does not need to be installed in the users browser. What tool do i need and what is the html code to embed such a video?
As you can see: starting from scratch.
PS: I often hear: This or that file extension is just a container, there can be anything inside. If you're using this in your answer, can you explain this to me, because I never understood this. For me a .cs is a c# file and a .doc a Word file, and not 'a container'.
This isn't an easy question. The basic answer is that you need to use a format that the user's computer already supports. There is no one answer to this question. YouTube encodes videos as MP4 and embeds them in the page with a Flash-based movie player, and Flash is pretty widely supported, but you'll notice that Flash isn't available on a lot of mobile platforms — so anybody using an iPhone is shut out if you go the Flash route.
HTML5 introduces the video tag, which is meant to solve this problem once and for all, but there's still a hiccup even there — most HTML5-enabled browsers support h.264-encoded video, but Mozilla supports Ogg Theora instead. YouTube is currently experimenting with a <video>-based player, so this does seem like the future.
I believe the current best practice to support the most people possible is to encode as h.264, try to serve as a <video> element, and have a Flash-based player as a fallback if that doesn't work (which can play the same h.264 file).
I'd say the most popular solution at the moment - utilized by YouTube and other major video portals - is H.264 encoded Flash-based Video. Flash can play Video since... I think Version 8 or 9, and has since gained significant market share.
My personal favourite Flash player is LongTail Player, but it isn't free for commercial use.
Here's a SO question with a list of Flash based players including open source ones.
Flash won't play on iPhone and iPad, though.
If you want to support computers with Flash Player 9 (I've seen some around, but I don't have any hard numbers) you will need to encode FLV files (which use a codec named Sorenson I think).
The upcoming alternative is HTML 5 Video but suport for that in browsers is nowhere near a major market share.
This question requires a re-answer now that it's no longer 2010 and HTML5 videos (as utilized by most video hosting sites) and chunk-based videos (sent as responses to periodic XHR requests - as utilized by Youtube) are the norm. While there is no best way to add video to your site, Flash is definitely nowhere close to even being good as of the time of writing of this answer.
The simple un-researched answer is: Just use a video tag and it'll work out!
This is simple and intuitive, and should work fine in many of your use-cases.
The researched answer is: Unfortunately, upload the video on Youtube and embed it on your site.
The pros and cons of embedding on Youtube over just having a video tag:
The pros:
Allows you to offer your video in a multitude of qualities.
Very bandwidth efficient. Youtube is bandwidth efficient for your users since it reencodes videos, and is also bandwidth efficient for you since you'll no longer be serving your videos off your own hosting.
Offers features like closed captions, automatic subs, playing at multiple speeds, full screen player, etc.
The cons:
It's a very heavily monetized service, chances are they'll want to put ads on your video if any of its content isn't 100% originally yours.
It has very strict laws/terms and conditions that you need to adhere to, at least in my opinion.
It tracks your users. If your application requires privacy and you can't rely on your users to protect themselves, then Youtube isn't ideal.
Other alternatives that mix the pros and cons of those two options are:
Using a Javascript video library to get HTML5 video along with some of the pros of using youtube, but none of its cons.
Using FFMPEG on the server side, for bandwidth issues.
Using some CDN that supports video to deliver the video, for reliability and bandwidth issues. My current favorites are ones that rely on service workers and the bittorent protocol, to stream from users to each other, but whether that suits you or not depends on your application.
Using AWS storage services to store the video, and AWS gateway/CDN services to serve it, which might be a great solution cost-wise and efficiency-wise if you don't want youtube but don't want to store videos on whatever infrastructure is serving your website.
Sources of this answer: Personal experience. As much as I didn't want to answer from experience, this question really needed a new answer! Feel free to edit it with something more concrete.
Converting your video MPEG-4 with H.264 will get you 97% coverage on current browsers across desktop and mobile, although some Android devices don't support hardware acceleration for this format. To address that you could also serve WebM with VP9 codec.
I wrote up a summary of browser support that might be useful: https://stuartk.com/posts/whats-the-best-html-video-format-to-serve/