It might be a duplicate, but I didn't quite find the answer, so what is more efficient - using just a plain video element (if i dont need support for ie8, for example and all the fancy stuff), or using some plugins for video like video.js?
My main concern is load time - is there something that makes video files load faster when using video plugins?
With a plugin (be it Flash or a framework like video.js) you have the load/initialization time of the plugin itself to consider, though that will be largely minimal compared to the pre-load time of the video. Some Flash players have a fairly large .swf file though most (like most of the .js frameworks you'll come across) are pretty well optimized these days.
The largest chunk of time, with either, will be the pre-buffering to get to a state where the video can play through without further buffering. This will be impacted by the resolution, framerate etc of the video itself and optimizations like the positioning of the MOOV atom (if it's at the start of an .mp4 for instance then the browser doesn't have to read/cache the entire clip before it will start playing)
Flash (a plugin) may have better support for different types of media (for instance if you want to use a fMPEG format like HLS or DASH) but may restrict the devices/platforms you can run on. HTML5 and the <video> tag will - as you point out - only be available on more modern browsers and with or without a player framework to extend it offers a lot of flexibility (and capabilities are improving with time). This is a good overview of pros and cons.
Related
I'm a Javascript dilettante. I need to make a webpage for mobile viewing to deploy a dynamically created but ultimately linear audio piece. Essentially I would need to load a playlist, in which some tracks are fixed but others are randomly chosen from a larger pool; there also need to be timed pauses between some of the tracks. It would need only minimal controls, probably just play/pause.
I'm looking into Web Audio API and the basic HTML5 <audio> tag. My two main concerns for choosing between them are compatibility and simplicity of use.
On the compatibility point, I see that on the main page for the API itself it lists no support for Android, but on this more detailed rundown almost all browsers are listed as green. What's the best source to trust?
Assuming Web Audio API is viable for mobile deployment, do I need to use it? Would it make my life easier or is it just overpowered for my purposes? I see it has a handy onended event handler which I see myself using for queuing, and precise timing functions. It also seems to be more explicit about loading the files asynchronously with a callback function on success - I'd want to have a loading screen so that would be useful.
I'm a bit less clear on the capabilities of <audio>. I guess it must be able to do everything I want given HTML5 players have been built before Web Audio API came along - but is it more fiddly?
Web Audio works just fine on mobile.
Web Audio, in contrast to <audio>, breaks apart and give the developer precise control over the loading, decoding and playing of audio. If you need precise timing - like, beat-synching - of audio, you should probably use web audio. <audio> is pretty imprecise.
That said, a few caveats - as Web Audio by default uses in-memory buffers, it can use a lot more memory than <audio>, and it doesn't have native components to do streaming audio. The onended event is NOT the right way to do real chaining of audio, because it's a main-thread-Javascript callback (that is to say, any event handling like this might be delayed by other JS, garbage collection, etc. - and it might be off by 50 or 100 milliseconds). If you really care about timing, you have to plan ahead and use Web Audio scheduling. (This article I wrote describes this in more detail.)
There are a number of JavaScript libraries available for HTML5 audio, to either make a developer's life easier, ensure cross-browser compatibility or support Flash fallback for older browsers.
I haven't found much in terms of comparatives, except maybe for this article, on a small scale.
Which of the following libraries come recommended and for what purposes? What can I expect in terms of documentation and support (eg: is that library likely here to stay?)
Audio5JS
Buzz
HowlerJS
jPlayer
MediaElementJS
SoundJS
SoundManager2
I don't need UI features for my needs and would rather keep things small and simple. That would seem to make Audio5JS a candidate of choice. However I'm wondering if that's a smart choice simply because it doesn't seem to have as big a community as, say, jPlayer.
EDIT: I simply need to play an audio file (in full and/or parts of it) based on user input and the ability to loop that for a given file (ie: loop the file itself or loop a part of it.)
General guidelines on how to pick a JS library to get a job done will also be welcome.
I mainly wanna save myself the need to try out all those libraries (and more) to figureout their pro's and con's.
Thank you.
You may have already selected a library, but as the developer of howler.js, I thought I'd leave a note. From your description, I'd say howler.js is exactly what you are looking for if you don't need less than IE9 support. howler.js has now been under development/refinement for nearly a year and has a large community around it. It is great for both simple and complex tasks, and leaves any UI needs up to the developer. howler.js is currently the only library that I'm aware of that lets you seamlessly use both Web Audio API and HTML5 Audio with a single, simple API.
My recommendation would be SoundJS, but I may be biased because I work on it.
It allows you to get audio up and running with minimal code that will work across all modern browsers. Looping and playing from an offset both work smoothly. As far as I know, looping only a slice of a larger audio file smoothly can only be done with pure web audio, which currently is only supported in Chrome and Safari. SoundJS doesn't support that functionality directly, but does allow you access the web audio nodes directly so you can set it up manually.
Hope that helps.
You can also check out http://musquitojs.com/. It provides a simple API to create and play sounds.
For example, to play a sound all you've to do is.
import $buzz from 'musquito';
$buzz.play('gunfire.mp3');
The library also supports Audio Sprites.
I've been searching for it for a very long time and can't seem to find any relevant items (I know about the VLC plugin and I don't think it supports sound effects for video games). I need something similar like FMOD or Bass (or an NPAPI wrapper for these two) or a DirectSound NPAPI plugin, or just anything as long as it can support loading .wav, .ogg, .mp3, .m4a, etc. and can play those sounds in multiple instances.
EDIT: The reason I'm trying the NPAPI route is because the Web Audio API isn't really ready for primetime yet. I already tried Chrome's implementation and it has a bit of latency when playing the sounds (and multiple instances of sounds). It's even hard (or maybe impossible) to pause-play sounds with the current API spec. I also tried Flash (via SoundManager 2) and it also suffers from latency. It's fine for games but not good for making music applications such as a drum sampler. I hope this clarifies. (Sorry for my English, it's not my first language)
I don't know of any existing plugins that will do what you want, but if you have some good c++ experience you could build a plugin to do that with FireBreath. The sound playback functionality you'd have to implement yourself, though.
Keep in mind that Chrome has announced plans to stop supporting plugins by the end of 2014 and Firefox will be blocking them by default starting in firefox 26, requiring users to specifically enable any plugins used on a page before they will work. You also have the "fun" install issue.
In short, if you can do something without a plugin you should absolutely not be using a plugin.
I am now using an embedded Windows Media Player (tutorial) and I can manipulate with time slider through Javascript. But then I discovered the Jlembed plugin for jQuery and thought it solves all my problems because of the different platforms, etc.
But after I spent a few hours in setting things up I relized that it does not have functions like setCurrentTime or getCurrentTime and these functions are most important for my type of project.
Is there a way to achieve this functionallity with Jlembed?
As far as I know, Windows Media Player does not support the type of interaction you're trying to achieve with it's embedded player. I did not include any javascript functions for Windows Media Player because it is not necessary. jlEmbed does not affect your ability to control the embedded player with javascript. So, if Windows Media Player supports a particular script, jlEmbed supports it also.
If there is a javascript API for WMP please point me in that direction and I will add better support for it, but I don't think it exists. However, if one does exist, jlEmbed will not prevent you from scripting as would normally be done.
I spent a great deal of time on the YouTube support, but only because I had to. Otherwise, it would have been much more difficult to control the YouTube player, which is the most popular and widely available media player on the web.
Only a small percentage of users will actually be able to use your embedded WMP presentation. The YouTube player is compatible with any browser that supports Flash. You would be better off creating a custom 'chromeless' YouTube player than using WMP for your presentation. An even better alternative would be to use Flash to make your video presentation.
According to the documentation, the following functions exist that might help:
jlembed_seekTo(playerId, seconds, allowSeekAhead)
jlembed_getCurrentTime(playerId)
Hope that helps!
As a Flash and Flex developer it is a little disheartening to see the strides in HTML5. Don't get me wrong I have nothing against progress, for me it is just that currently it is easier to write an app in Flash vs AJAX. I love writing in Flash and Flex and think ActionScript is a really great language. But, it appears the strides made in ActionScript or making their way to JavaScript and that video in HTML 5 may make Flash/Flex a thing of the past.
So when do you think (if ever) that HTML will or is a competitor to Flash/Flex for RIA or will browser incompatibility stop this from ever happening?
The reason I am asking is because I don't know if continuing in Flash/Flex is a good idea career wise if HTML 5 can do more. Just looking for some answers from other developers using the technologies.
There are four things that hold the "modern browser" back from where flash is today.
1) Tools. Animating et al with Flash is obviously much easier to do. Plus JS/SVG don't have the "direct" animation support that Flash does right now. It can be done, but it's manual.
2) Performance. JS/SVG/Canvas can not perform as fast, and certainly not as consistently across browsers, as Flash can. Not every application needs the performance, and JS et al are catching up. But at the moment, they still lag behind in total overall performance.
3) Browser adoption. Ye Olde browser wars. Different implementations, different speeds, legacy browers, etc. All the issues the afflict the portable web are in place for the modern browser technologies. So, it's more work to make a portable artifact, and even then it simply may not work, especially on older browsers.
4) Content protection. Flash is hardly the bastion of content safety in terms of IP control etc, but it's night and day over JS, HTML, SVG, etc. where it's all pretty much free for the taking. This will especially confound things like video which right now is mostly bastioned behind Flash players vs simply streaming mp4s to the client.
We've already seen some of the more clever "Javascript ads" (those annoying, floating animated panels for example). I'm waiting for more of those, just as simply animated mini ad apps vs flash. The primary reason most users who disable Flash do so, is to disable applications. JS mini ads won't have that problem.
However, the primary creator of those ads are the creative folks specifically targeted by Flash. It's easy to use for them without being "real technical". Until you can do that with Javascript and the rest, Flash will have a large market for it.
I think the original poster is asking where do cutting edge open web technologies (draft standards) stand versus Flash/Flex. Ignoring questions of browser support and developer tools, look just at features (as you'll see, I know the web side much better):
Vector Graphics
Flash: Yep.
Web: SVG.
Raster Graphics
Flash: Yep.
Web: Canvas.
Audio
Flash: Yep, with ADPCM, MP3, HE-AAC (MPEG-4 Part 3).
Web: HTML5 audio tag with MP3, Ogg Theora, Ogg Vorbis, WAV.
Video
Flash: Yep, with On2 VP6, Sorenson Spark, Screen video, Screen video 2, H.264. The Windows version of Flash 10.1 has hardware-accelerated H.264 decoding.
Web: HTML video tag with Ogg Theora, H.264.
Animation
Flash: Yep.
Web: Yep, via some Javascript DOM commands and via CSS3 properties for animations, 2D transforms, 3D transforms. Some browsers (e.g. Mobile Safari) hardware accelerate some of properties.
I think the big differences currently (given the caveats mentioned above) are performance and implementing all these features. While Javascript is very good in many ways, the programming experience isn't nearly as integrated as in Flash/Flex's ActionScript (note that many of the animation features that are done in CSS). If you want to learn more about where open web standards are going, check out HTML5 Doctor.
HTML/CSS/Javascript together solve a different problem than Flash does.
HTML and CSS are about the appearance of your page, and are the 'universal' language of the internet. Really it's the only language the browser natively understands. Javascript is natively supported in most browsers, but was a glue language never intended to allow the flexibility of Flash.
Flash/Flex are about creating a portable (albeit proprietary) application framework. However, without HTML, Flash and Flex don't exist.
A developer can never stop learning. If it's not HTML5, it'll be something else. I would continue programming what you love, but start playing with HTML5 and see what it can do. It will expand your horizons and help you to think about things in a new way. But you don't have to give up what you're doing now, especially as HTML5 still isn't ready for the mass market yet.