I want to make a single web application avoiding any flash code. This application must contain videoconference, and I want to implement it in pure HTML5. It is possible? I know about websockets, but don't know really if videoconference can be implemented through them with a relative performance (at least, 24fps + sound at a right resolution, minimum 640x480), and both endpoints being web apps (both endpoints should use browser).
Thanks in advance
Anyone following up this question - on Feb 4th, 2013 they produced the solution with WEBRTC in Chrome and Firefox. For examples see https://hacks.mozilla.org/2013/02/hello-chrome-its-firefox-calling/ or http://www.html5rocks.com/en/tutorials/webrtc/basics/ or https://code.google.com/p/sipservlets/wiki/HTML5WebRTCVideoApplication
You can't really use HTML5 video for live streaming at the moment, and it doesn't have support for web cams yet.
Ericsson has modyfied a WebKit browser and is showing how this can be done with hopfully upcoming HTML5 Stream API. See Beyond HTML5 - Implementing and stream management in WebKit
It is impossible to capture web-cam images/microphone feed just through JavaScript (although there are plug-ins which let you handle output through flash), so it would be necessary for you to have some kind of application/plug-in installed.
The speed part is just for the client to worry. I mean, web sockets will be as fast as the connection permits.
You should do some research about web workers, since they would be very useful for speeding up your application (you could have microphone interface, web-cam interface and UI all with their particular worker, thus never blocking the application or rendering it unresponsive).
EDIT: the aforementioned jQuery plug-in works through the use of <canvas>.
As Jonas said, according to the situations now, we can't build video conference with HTML5. There are many limitations with browsers also. As there is no common video codec supported by all browsers. And live-streaming is also properly supported by safari only(using HTML5 video tag). As per my experience we can't build live-streaming on windows with any browser properly.
But if you wanna get some information about live streaming see https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html
you can use this source to test your live-streaming examples
"http://xfunoonx.api.channel.livestream.com/3.0/playlist.m3u8"
This content will work only with safari on Mac.
Related
I have been doing a lot of research into WebRTC for a project I am currently working on. I am aware that it is only supported in Chrome, Firefox, and now Opera. However, I am wondering if their is a cross-browser viewer solution that does not require a plugin. This way I could require that broadcasts be done from a webRTC compliant browser but viewers could use other browsers such as Safari or IE with watching/viewing capabilities only.
The application I am working on is used for small group broadcasts of 25 or less people with a single publisher/presenter.
Here is a list of the options/ideas so far.
Somehow have a html5 canvas element display the frames of the video on non-webRTC supported browsers. However, I also need to support audio as well and I don't believe there is anyway as of right now to feed the audio stream into the HTML5 audio element. This option may be dead before it is even considered...
Have a server subscribe to the webrtc stream and then create a HLS (HTTP Live Stream) stream that can then be consumed by a browser player (Possibly Flowplayer, it supports cross-browser HLS to the best of my knowledge). I have found that Web Call Server 4 from the guys at Flashphoner can do the conversion to HLS but it seems like overkill for a simple server that does the WebRTC to HLS conversion. Hoping that there may be some sort of node.js implementation out there to generate the playlist and files for HLS so there is low latency.
Any help from the community on this would be much appreciated. The question is pretty specific and I have been researching solutions for the last 2 months so I think it warrants a stack overflow post at this point.
-- UPDATE
There may be a 3rd option here, having users on non-webrtc supported browsers install a plugin. This would only be for Safari and IE but it may be a solution. One free plugin that can be distributed for an app based on my findings are [link]https://github.com/sarandogou/webrtc-everywhere It may be possible to use this plugin with something like Kuento for signalling and achieve a solution that will at least work on all desktop browsers until Safari and IE catch-up with WebRTC.
HTML5 audio on mobile devices has many limitations and actually I would call them bugs.
My app implementing something like audio player.
Actually all it works fine for desktop but in mobile version I encounter many bugs and have to do many workarounds different for different browsers and os to get it work, and still it sucks.
I haven't dived into web audio api, but it seems to be designed for slightly different tasks.
So my question is, is it make sense (and is it possible?) to replace HTML5 audio with Web Audio API, if I need just to load files and play them (partly, sprites) just to avoid limitations and bugs of HTML5 audio?
I think you're probably going to find at least as many bugs or edge cases with Web Audio on mobile as you're seeing using the <audio> element. Plus, support for Web Audio on mobile platforms isn't great. If it were me, I'd be inclined to stick with <audio> unless you have a specific use-case that can only be addressed by the Web Audio API.
Actually, I'll disagree - if your goal is to play short snippets of sounds, particularly simultaneously - e.g., providing sound for a platform jumper game - Web Audio is going to be a lot easier to use, including on mobile. has issues managing multiple files/instances. On the other hand, if the problems you're running in to are due to decoding issues, or you're using mostly long files, it's not going to help, as Kevin and Brad said.
I recommend SoundJS which I develop, it takes a lot of the pain out of supporting audio on multiple devices. Basically it lets you write a single code base that works everywhere and already deals with edge cases where it can.
HTML Audio element implementation on mobile devices is really terrible, so if not SoundJS I would at least recommend switching to Web Audio which works well on iOS and Android Chrome but is not supported in Android Native browser.
idbehold's comment is accurate, the most common problem with mobile devices is having to play audio inside of a user initiated event (touch). I've developed a solution to this problem, shared in the Mobile Safe Approach tutorial.
Hope that helps.
I would like to clarify certain things with what I found and raise certain questions with things that I dont know,
Capturing cam/mic through browser could be done through getusermedia();
Is there anything for i devices? because getusermedia() doesn't seem to work in i devices
How could I trap actual audio from web browser application (eg. if I play an audio file and forward it 2mins, I would like to capture the actual audio stream from the html5 player so that I hold the actual audio data)
You need to use Flash, if you are not going to support mobile devices. One best solution is to use wami-recorder.
From their website:
The Problem
As of this writing, most browsers still do not support WebRTC's getUserMedia(), which promises to give web developers microphone access via Javascript. This project achieves the next best thing for browsers that support Flash. Using the WAMI recorder, you can collect audio on your server without installing any proprietary media server software.
The Solution
The WAMI recorder uses a light-weight Flash app to ship audio from client to server via a standard HTTP POST. Apart from the security settings to allow microphone access, the entire interface can be constructed in HTML and Javascript.
Hope this helps.
Since Flash is losing ground I would like to know if there are ways to protect html5 videos with DRM (H264, .ogg and WebM).
On the W3C FAQ on HTML5 it states:
Is there support for digital rights management (DRM) in HTML5 video?
HTML5 doesn't provide direct support, nor any barrier, to using DRM in video. It currently expects this to be handled by the particular codec/implementation. There are implementations which allow for DRM in HTML5 video.
Is dealing with DRM in scope for HTML5?
If enough stakeholders want to standardise some aspect of handling DRM in HTML5 itself as part of the inclusion of video and audio media, then it makes sense for W3C to help standardise an approach which meets the needs of the market. However like all W3C work, relevant stakeholders need to be and show they are committed to developing it rather than expecting it to happen on its own.
Which means it's currently not supported, but there has been a discussion about it on the W3C bug tracker here.
Update:
People interested in this subject might want to consult the working draft of the new encrypted media extension standard.
Updated: EME is currently supported in major browsers.
It does now.
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
Here is an example.
http://www.html5rocks.com/en/tutorials/eme/basics/
This is the best page that I could find on current browser support.
http://www.jwplayer.com/html5/mediasource/
At the time of writing this, EME is supported in
IE11 in Win8.1
Chrome (Desktop and mobile)
Safari 8 in OSX Yosemite
Probably not, even though there's an EME DRM plug-in interface.
Some browsers now support another type of a plug-in called EME (Encrypted Media Extension CDM) for vendor-specific DRM implementations such as Microsoft PlayReady, Google WideVine, Apple FairPlay, etc.
However, the only part of it that is a public standard is a JS API that launches a vendor-specific EME plug-in.
The actual DRM API required to make use of it is vendor-specific, secret and proprietary. To have working DRM across browsers you will have to sign separate contracts with Adobe, Microsoft, Google and Apple (which may be difficult if you're not Netflix).
Consider abandoning idea of DRM, as it's more likely to backfire than protect the content.
This is an updated answer, comments don't make sense any more
Already in chrome.
Here is a running example using it.
Widewine provides video DRM for HTML5 and h.264. Recently, another company Haihaisoft said they released HTML5 DRM for MP4 and WebM video: . It doesn't need Flash anymore. You might try it online. HTML5 Demo in Xvast browser DRM-X 4.0 in the news
You could implement some kind of encryption scheme with public/private key - I recently heard about http://www.widevine.com/ who seem to be doing something like that for html5 and h.264 . But I am not aware of anyone having applied to web video in general.
Sure you can stop someone from downloading the file simply by not giving them permission to download anything from certain folders on your server. Maybe there is something I am missing here. Seems like that would be a relatively easy solution.
we've trying to develop a mobile web app that will provide offline capabilities, not just reading but also creating content.
Gears supports three important aspects:
- local server so we can have cached static content such as html, css, js, etc
- local database so that we can have data stored locally for offline access as well as store new content inside of it while offline
- workerpool, used for a background process that syncs data back to the server
By the looks of the gears page and some other articles, gears is being abandoned in favour of html 5 which is understandable.
However, at this stage there are two problems:
there's still a long way to have HTML 5 supported by major desktop browsers,let alone mobile ones
HTML 5 does not support workers, there is a draft http://dev.w3.org/html5/workers/ but I assume real browser support is still far away.
Do what does one do today? (e.g. within the next year)
Cheers
Rok
I think that you have slightly misinterpreted Google's position on Gears. According to an article in the LA Times:
The Google spokesman wrote to clarify in a follow-up e-mail, "We're continuing to support Gears so that nothing breaks for sites that use it. But we expect developers to use HTML5 for these features moving forward as it's a standards-based approach that will be available across all browsers."
It sounds to me like it is completely safe to continue using Gears, until and after HTML 5 is ubiquitous.
HTML5 support is a little better then you think.
Android has various support for HTML5 standards, with the inclusion of Google Gears into most versions and Android 2.0+ having native support for HTML5 (at least as far as audio/video, canvas, offline storage, and geolocation go). IPhone also supports offline storage along with audio/video tags. WebOS seems to have offline database support, but I don't know much beyond that.
http://www.whatwg.org/specs/web-workers/current-work/ is the web worker draft implemented in Firefox 3.5 and Safari 4, so they should wind up in IPhone's version of Safari eventually.
So if you can live without worker threads and don't mind limiting yourself to Android, WebOS, and IPhone, you can use a hybrid approach of HTML5 with a fallback to Gears.
I don't think supporting other smart-phones is going to be possible in a truly portable way, although Firefox for Mobile (which is nearing release on the Nokia N900) will support all the HTML5 as Firefox 3.6.
Appcache, Web storage & Web workers works on Firefox and newer Android devices.
Use this handy test http://dev.w3.org/2008/mobile-test/v2/ to profile browsers.
HTML 5 does not support workers, there is a draft http://dev.w3.org/html5/workers/ but I assume
real browser support is still far away.
I coded a working example of web workers using the WebKit engine included in Qt 4.6.2. Looking at the code history, support was incorporated sometime in 2008.
I've been surprised by the level of HTML5 already in (desktop) browsers (excepting IE of course). Mobile lags a few years. I've found this site useful: http://caniuse.com/