I'm trying to build a html5 app, part of it requires the recording of audios whose length should be up to a minute and then encode it into 64 based, so I did quite a bit searching and didn't find a good answer.
Are there any ways to record an audio with Html5, Javascript or maybe local APIs on a html5 app, especially on an IOS device?
Html5 doesn't yet have a widely accepted method of recording audio. If you are targeting non-iOS, you can use flash, or any number of javascript wrappers that call out to flash( eg. http://www.sajithmr.me/jrecorder-jquery I think soundmanager2 will also work, but I'm not sure). For iOS, you still need to write an app. :(
Short answer is no for now. Because audio not yet implemented to HTML5 browsers yet.
Method is working but you can't capture any audio.
Well here is a detailed answer for you: Recording html5 audio
This may be too late for a response, but having said that, both Chrome and Firefox now fully support getUserMedia and you can use it along with the AudioContext interface if needed, to capture audio directly from the browser.
The following gitHub project records audio and saves it in MP3 format directly in the browser using just HTML5 and JS.
The audio recording is saved in base64 and can also be directly listened to from the browser after the recording is made.
The project can be found here:
https://github.com/nusofthq/Recordmp3js
and is an extension of RecorderJS that also uses libmp3lame.js.
If you wish you can read more details about the actual implementation:
http://nusofthq.com/blog/recording-mp3-using-only-html5-and-javascript-recordmp3-js/
Related
Is there any way to take the system's sound as an input for the Web Audio API?
For example take a user's spotify music that is playing as an input and analyze it to do stuff with it?
There is a specification which almost does what you want. It's the counterpart of the Media Capture and Streams spec (aka getUserMedia()).
navigator.mediaDevices.getDisplayMedia();
The spec is called Screen Capture and as the name implies it is meant for capturing video and not audio. Capturing audio is optional and not yet supported by any browser if I recall correctly.
There is currently an open issue discussing audio-only support. Maybe it's a good idea to share your use case there.
I can't watch Periscope without flash:
Since Periscope is pretty new and hype I find it a pity flash is required. My best guess then is that they simply can't.
But what is the technical restriction if one?
I can't say for sure about their own technical restrictions but they are serving the video in chunks of .ts files. It is not impossible for HTML5-based player to handle MPEG-TS streams so I can only assume this is a temporary solution.
Example of an HTML5 player handling .ts format is THEOPlayer. Also DailyMotion released an open-source JavaScript HLS streaming client. If others can already do it now, Twitter will do it soon.
Why Flash? :
It's an easy solution that works same on all browsers that it's installed onto so Edge, Chrome, Safari & Firefox etc so it will each give a consistent result to their user base without specific browser limitations (since it's a plugin).
Why assume temporary? :
First of all as you said it's still new (growing/developing). They have a few job openings for video programmers. This particular job opening requires "Ability to create an interface in HTML, CSS and JavaScript". They are currently using a Flash-based JW Player instead of a custom-made Twitter player. That will change in time.
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.
When you play audio using the audio element in Chrome you get annoying clicks and cracks. At least under my 64bit Linux installation, even after I formatted and installed a new Fedora version. (Firefox and Opera are fine, even IE9 in a VirtualBox Windows 7.)
But demos using the Web Audio API instead of the audio element have perfect sound. So I was wondering if I could use the Web Audio API like the audio element? But there are some things you seem not to be able to do with this API. Or am I missing something? The things I couldn't find where:
starting to play a file before it is completely loaded
getting buffer progress updates (depends on the previous point)
getting play progress updates
seeking
Is there a way to do this with the Web Audio API?
This is where I would use it: http://tinyurl.com/magnatune-player
I think you should still use <audio> for streaming at the very least. You can treat it as a MediaElementAudioSourceNode in web audio if you'd like:
var mediaSourceNode = context.createMediaElementSource(audioElement);
AFAIK, there is no way to stream web audio directly. In fact, the web audio api suggests that you don't:
4.9. The AudioBuffer Interface
This interface represents a memory-resident audio asset (for one-shot sounds and other short audio clips). Its format is non-interleaved IEEE 32-bit linear PCM with a nominal range of -1 -> +1. It can contain one or more channels. Typically, it would be expected that the length of the PCM data would be fairly short (usually somewhat less than a minute). For longer sounds, such as music soundtracks, streaming should be used with the audio element and MediaElementAudioSourceNode.
Unless you used a MediaElementAudioSourceNode (which I would assume suffer from the same issues you're having since it's just using an <audio> tag) AFAIK the answers to your questions are:
starting to play a file before it is completely loaded: No.
getting buffer progress updates (depends on the previous point): Possibly (You could check for progress events on the XHR)
getting play progress updates: No.
seeking: No.
In the meantime Chrome fixed the audio playback issues. So I don't need any workarounds anymore.
For the last two month I have been trying to "fool" safari into thinking that it's looking at a file on the server, which in fact is a live video stream from a camera encoded and muxed upon request using Gstreamer into a format that is supported by the browser. Since HTML5 supports progressive video downloads this should at least be possible in theory.
My conclusion is that this gets quite complicated considering that browsers make a partial content request when downloading video files in HTML5, mainly for the sake of seeking. If the server lacks support for this feature the video is not played until the file is completely downloaded.
Have anyone else tried this approach with more success? Or should I just give up and wait for true live video support like RTSP to be integrated into browsers.
Cheers.
This article provides some useful tips: https://developer.mozilla.org/en/Configuring_servers_for_Ogg_media
Are you serving the X-content-duration header?
You have two possibilies.
With H.264 you can emulate a file with fragmented structure: ISO container (.mp4) with movie fragment atoms (MOOF's).
The other option is Google's WebM. Clients can "join in" the stream any time thanks to MKV file's structure. For best results the first frame transmitted to the client should be akeyframe.
If you only need video but not audio, "Motion JPEG" can do it. It's not HTML5 but a Netscape-era feature.
http://en.wikipedia.org/wiki/Motion_JPEG#M-JPEG_over_HTTP