On iOS, and I think Safari, we have Apples HTTP Live streaming, which can take a playlist of video files in a certain format, buffer them one by one, and play them seamlessly back to back.
Is there any way to achieve this in other browsers? I can of course detect the video finishing, and then start buffering and playing the next one, but I want to remove the buffering by downloading subsequent videos as each earlier video finishes. I do not want to hack this by stacking up video elements and switching between them. There are various serious consequences to this method.
Perhaps if there is a way to use javascript to download the files into in-memory buffers and somehow point the video element to play from these buffers?
I've seen swapping in video elements for each segment tried, and it's never smooth.
There is an HTML spec in the works that defines exactly the process you're describing, concatenating media segments into a buffer that can be fed into a media element.
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html
This isn't available in browsers today but is working its way into Chrome/Safari. Even when it is, it will take a good amount of work to implement this process.
Your best bet if you need it now would be to use a Flash player that can handle HLS, like OSMF, JWplayer, and soon Video.js.
In html5, you can preload videos, preload the meta information, or not preload at all. The only problem, of course, will be with Internet Explorer which will download everything or nothing at all (and not even show the controls).
This is all controllable with javascript, too. If you want to play them back-to-back automatically, though, this would need to be done with javascript or some third-party tool. Reading where the file is playing is accessible through the API.
Related
Is there any way possible to make HTML Video run off of internet, and buffer when the internet connection is weak, or low, for example, the YouTube Player, The basic idea is to chop video, and buffer it before the client clicks play, can this be based on internet connection and wifi? I will do anyway possible to implement this feature!
Thank you.
IMHO, the video element does most of the buffering in the background (depending on the internet connection), and is usually quite good at it. From experience, it is more time-efficient as a developer to try to optimize the size/quality of the streaming video (using tools like Handbrake) rather than try to alter buffering depending on network variables.
That being said, if you are mainly targeting mobile devices, you could could use the experimental Network Information API to get info in Javascript what kind of mobile connection the device is using, and then direct them to a different (low quality) version of the video if they are using 3g or slower.
Alternatively, if you just want the video to start preloading (not playing) as soon as the page loads, have a look at the preload feature on the html video element.
Is there a way to control how much of the file will be buffered ahead, once you click play, much like Youtube once did?
If you use the built-in video support in the browser then there is no way to control the amount of data that's being buffered. It depends on the browser implementation and there is no API to control it.
Browser implementations are quite good and typically a browser buffers just a small portion of the video before playback begins. Browsers don't download the whole file. However if a file gets completely downloaded by the browser before playback begins then possible causes include:
Maybe the file is very small and the browser has decided to buffer the whole file in memory.
Maybe the header of the file (required to initialize the video decoder) is not at the start of the file but at the end and the browser has to download the whole file until it reaches it. This is uncommon nowadays but old video encoders used to place the mp4 header at the end of the file instead of at the beginning because it simplified the encoder's implementation.
I've noticed that browsers behave oddly if an mp4 file doesn't have a segment index (used for seeking) in its header. Some browsers download the whole file so that they can build a segment index themselves.
If your server is old/misconfigured then the browser may decide that range requests are not supported and download the whole file (or disable seeking).
If you require to control the buffered amount before playback begins then you have to use a more sophisticated protocol (MPEG-DASH, HLS) and a javascript player that allows you to control this parameter. Youtube use MPEG-DASH and have their own player that they've developed over the years.
I'm pretty sure you c an't stop the HTML5 video from buffering the entire video, but here is a useful link for working out how much of the video has been buffered.
https://developer.mozilla.org/en-US/Apps/Build/Audio_and_video_delivery/buffering_seeking_time_ranges
Like mylescc mentioned, preventing the video element from buffering might not be possible, without a workaround (described in a similar posting). However, depending on your use case, you can also make use of existing player implementations, which provide this functionality, like the bitmovin player, dash.js, etc.
How does one go about streaming video in HTML5 ? I can go with using a single browser of the latest version if I have to.I need to be able to start playing from any location of the movie even if the entire video has not been loaded by the browser.
WebRTC ?
I've already seen this question and no one has answered.
Does not allow the viewer to skip to the middle of a video in any
browser. They must watch the video straight through start to finish,
which is not ideal.
This is the main point for streaming.
Currently if you want to use pure HTML5 and work cross-browser you are limited to progressive streaming with the <video> element.
While that still does allow the user to skip ahead via the scrubber or programatically by setting the .currentTime there will still be some buffering while the browser re-loads enough content to be comfortable playing smoothly.
Solutions like Smooth Streaming, HLS do not work across browsers today so you would require a Flash or Silverlight plugin, though with MPEG-DASH being recognized by the W3C there is some hope for the future as samples like this demonstrate http://dash-mse-test.appspot.com/release-notes.html
For today however if you want to stick with an HTML5 solution and you have source in a format the works with the browser then you should be fine
Chrome has implemented the Media Source API in the mean time. Hoping the rest will follow.
http://www.w3.org/TR/media-source/
Abstract
This specification extends HTMLMediaElement to allow JavaScript to generate media streams for playback. Allowing JavaScript to generate streams facilitates a variety of use cases like adaptive streaming and time shifting live streams.
Check out this space shooter demo.
The HTML5 audio is perfect on Chrome 18 and Firefox 10. There is no lag in playing sounds and each sample plays perfectly. The last time I tried to play sounds using HTML5 audio and JavaScript I couldn't get a sound to play more than once.
What sorcery is Scirra doing to make this so perfect?
I'm the developer of Construct 2, so I hope I'm sufficiently qualified to answer your question :)
HTML5 audio is indeed a mess, so I've gone to considerable lengths to try and make it bulletproof in Construct 2. Here's an outline of what I've done:
Use the Web Audio API
HTML5 audio appears designed for streaming music, so a HTML5 Audio object is kind of a heavyweight object. Playing 10 sounds a second with it like Space Blaster does can easily seize up the browser. On the other hand, the Web Audio API is a high-performance audio engine with routing, effects, and lightweight sound playback. It's perfect for games. Audio buffers and audio playback are separated, so you can have one data buffer and efficiently play it many times simultaneously, whereas some browsers are so buggy if you play a HTML5 sound a few times it re-downloads it each time! Since it was actually designed for games and such, you can happily play back tonnes of sound for ages and it will still hum along nicely. It can also use HTML5 audio as a sound source, although I only use HTML5 audio for things the user has designated as music tracks (since that's where you'd prefer to have streaming - typically everything else in the Web Audio API is fully downloaded before playing).
The Web Audio API is supported in Chrome, has also made it in to iOS 6+ (although it's muted until you try to play some audio in a touch event), Firefox are working on support, and it should be coming soon to Chrome for Android. So on these platforms audio will be significantly more reliable.
More info on HTML5Rocks and the proposed spec - you'll have to use the spec as the documentation for now, there's not much else out there.
Other browsers: implement an audio recycling system
The Web Audio API isn't yet supported everywhere, notably IE, which means you still need to crowbar HTML5 audio in to something that might work for games for backwards compatibility. The way to do this is to recycle audio objects.
The player's laser in Space Blaster fires 10 times a second - and that's not including any other sound effects! As I mentioned earlier, Audio is kind of a heavyweight object, so if you're doing new Audio() 10+ times a second, lo and behold, the browser eventually dies and audio starts glitching up. However, you can drastically reduce the number of Audio objects created by recycling them.
Basically, for each sound effect, keep a cache of every Audio object you've created with that sound as a source. Then, when playing a new sound, search the cache for any sound effects which have finished playing (the ended property will be true). If you find one, rewind it back to the beginning (currentTime = 0) and play() again. Otherwise, create a new Audio() object in the cache.
Since the player's laser sound effect is short, instead of creating 600 Audio objects a minute, there will just be 3 or 4 that it keeps cycling round. Some browsers unfortunately will still download it 4 times (Safari did this last I checked!) or have high latency the first time each sound buffer is played, but eventually the browser catches up since the same buffers are always being reused. So basically sound might be a bit weird for a few moments, then it clears up. We also use the HTML5 app cache so next time you play everything loads from disk, so subsequent plays should perform well immediately.
That's basically it. It's still a little dodgy on the first play with HTML5 audio, but every time after that should be fairly solid providing the browser has a sane audio implementation. There are a number of ways to try to clone Audio objects, but I've found that rewinding existing Audios works best.
There's no SoundManager or any Flash/plugin-based fallbacks at all since we make a point of being pure HTML5.
We also support audio APIs provided by PhoneGap and appMobi for mobile, since HTML5 audio on mobile isn't even worth trying. That makes a total of four audio APIs our audio engine wraps, and yes, it does look like a frankenstein mess, but it works.
That's it. I suppose our competitors will read this, but who cares when there's SO rep to be had???!!!1111
I have pages where i need to play dozens of small audio file when the user clicks on things. Responsiveness is very important.
I'm thinking of using one for each file, and preloading the audio files. Is this the a reasonible approach?
Thanks.
What I experience using SoundManager2 (audio Javascript lib) is that Chrome nor Firefox have no issues loading and playing multiple (100+) sounds through their Html5 capabilities
(Firefox must play OGG though)
With IE9 it's a different story. Looks like it has a limit to load and play no more than 40 sounds. :-(
As, the game we develop requires constantly to have 50+ sounds played within 1 minute period, we have to fallback to Flash for playing sounds on IE9.. luckily SM2 does it too
I also confirm this behaviour with html5 mode using jPlayer. I'm only able to create 40 instances of jPlayer. Each can preload and play sound that it defines.
41st and following instances will fail with an error on IE9/Windows7
Error: "Media URL could not be loaded"
It's reasonable, and probably the correct solution. I recently wrote a demo application (http://www.soundscribe.com) that makes heavy use of individual (and simultaneous) audio clips in HTML5. IE9 and FF3/4 handle it well. Chrome has some issues that seem to be specifically related to simultaneous playback (which probably won't apply to your app). The biggest block I hit was in IE9, which seems to have a mysterious limit on the number of audio objects that can exist at once. The max is about 40, after which IE9 will silently fail to download the file. FF and Chrome both try to support an unlimited number.
The alternative approach of putting all the audio in a single file and changing the offset to play is a bad choice for several reasons. It's much more complicated to code, you need to keep up with additional metadata (where does the clip start, how long is it), and it's likely to work slightly different between browsers. And the worst part, there's really no way to know when your clip is fully loaded. You can only tell when the clip "can play through", which is determined by the browser based on the size of the audio file and the current download rate. This means that even after the browser reports the audio clip is ready, you may not be able to play a clip somewhere near the end.
It seems like a reasonable approach. However you need to consider a couple of things.
Each sound clip will need to be held in memory. While this is will not matter for most cases, users with a lot of tabs open, multiple programs open or old computers may get slow down on their computer. Especially if the sound files are large.
From a usability point of view, if I hear a sound every time a click a button on the site, I'll leave immediately