I've been reading about Silverlight 4's support for web cam and microphone. I'd like to be able to record audio from the browser and upload it to an ASP.NET MVC site. I've seen some mixed information about whether uploads are supported in Silverlight 4. I'm also looking to encode the audio to MP3 before upload and have seen some references to Speex.
Does anyone have any experience with this scenario that they can share as to whether this will be possible with Silverlight 4?
Your expertise is greatly appreciated!
I'm sure that you can record the audio and upload it to the website. but I don't think there is any Silverlight library that you can use to convert your audio file to mp3. You can always convert it at server-side after uploading as well..
If your SL is trusted OOB application then you can try this http://alvasnet.blogspot.com/2010/02/how-to-save-audio-to-mp3-on-silverlight.html
You can certainly upload any SL4 microphone output to an ASP.NET MVC (or WCF WebAPI) service. I do this in my WP7 project.
As far as encoding, the raw PCM that comes out of the mic is typically huge (for a 16khz sample rate, 16bits/sample, mono channel audio stream, that would net out to 32000 bytes per second of audio).
I have not found an easy (or free) way to encode in MP3 on the SL platform, but fortunately, speech (as opposed to music) is better encoded using the Speex codec. The implementation I use is at nspeex.codeplex.com and has given me excellent compression ratios - e.g. at Quality level 1 (lowest out of 10, which is adequate for my purposes), 64k of audio (the equivalent of 2sec) will encode down to about 1500 bytes.
Related
I am trying to make a web site with IIS smooth streaming but all the tutorials and examples that I found use Microsoft Expression Encoder 4 pro. According to them only the pro version is capable of using H.264 compression. But the problem is Microsoft Expression Encoder 4 pro is discontinued and the available free version dose not support H.264 compression. So I want to know whether there any other encoders(commercial or freeware) that I can use with IIS 7. Please help me
I have used Sorenson Squeeze with relative success for on-demand video encoding. It does not do live video but can successfully encode plan video files into many different formats. This is the "cheap" encoder I recommend for everyday light use. It does most of what Expression Encoder used to do.
For professional-quality encoding needs, you will want to look towards products from Harmonic, Envivio and similar vendors. Together with high quality and broad feature set you will, of course, also be faced with a significant pricetag.
There are also Wowza and Unified Streaming Platform which offer such services for relatively low cost, though my personal opinion of them is not very high - they seem more marketing than functionality oriented businesses.
I create a project in ASP.NET which uses the mpeg-4 video format. It is possible that it will be a commercial project later. This web application will store and play videos in mpeg-4 format in HTML video and Canvas elements.
As far as I know, the mpeg-4 encoder and decoder are not free to use, and I require a license to use them in my project.
I will record the videos mostly by my smartphone in mpeg-4 format, later I will lower their video bit rate by HandBrake, which is an open source free to use universal encoder, which uses the mpeg-4 encoder/decoder.
The mpeg-4 videos with the lowered bit rate will be displayed by my application in HTML 5 Canvas and Video elements, as I mentioned above.
My question is:
Do I have to pay license fee for using the mpeg-4 video format for this kind of usage?
I would rather use the other 2 free video formats (WebM and OGG), but Internet Explorer and Safari does not support them, so I have to use the mpeg-4 format).
After many hours of further searching, I found out, that distributing MP4 video encoded with H264 codec REQUIRES licensing in the case of commercial web applications, if the users have to pay to access the h264 encoded mp4 video content.
On August 26, 2010 MPEG LA announced that H.264 encoded internet video
that is free to end users will never be charged royalties.
(The above quoted information is copied from Wikipedia, the referenced PDF file is no longer available.)
Fortunately, Cisco is launching a project to create a free to use h264 codec for public use in HTML5.
References:
http://shaver.off.net/diary/2010/01/23/html5-video-and-codecs/
https://blog.mozilla.org/blog/2013/10/30/video-interoperability-on-the-web-gets-a-boost-from-ciscos-h-264-codec/
Problem:
To get an iOS app that streams video accepted into the app store, we need to have a HLS version.
What’s the problem?
Android does not support HLS well, and for other reasons, we need to store MP4 and HLS files of the same content.
What’s the difference between MP4 and HLS and why do you need to store both?
MP4 is a container that stores H.264 video and AAC audio for best compatibility in HTML 5 browsers – jsvideo players often have flash fallback if the browser does not support MP4 video in HTML 5 that use the same MP4 file, but played through flash.
HLS is a protocol where text files (.m3u8) contain references to playlists, which themselves reference .ts files (or m2ts), which are mpeg-2 transport streams, not to be confused with mpeg-2 video. The .ts files are containers for the same H.264 video and AAC audio.
Why am I complaining?
It takes time to create the HLS files and playlists from the MP4 files
(Most importantly) We are now storing twice as much data on S3
Why should I care? If your S3 bill is $10K per month for storing both MP4 and HLS, now it is only $5K. Or put another way, if you are paying $100K for storing data in MP4, it would cost $200K to store the same content in both MP4 and HLS.
What do I want?
I want to store only the .ts files and serve both desktop users, iOS users, and Android users with that single file.
Is it possible?
Doesn’t HLS require 5-10 second .ts segments instead of one big file?
As of IETF draft 7, and version 4 of the protocol, HLS supports the tag EXT-X-BYTERANGE which allows you to specify a media segment as a byte range (subrange) of a larger URL.
Are .ts files compatible with HTML5 video?
Apparently not. They are a different container than MP4, yet contain the same video and audio content. Worth looking into how to store the raw video/audio data once and simply using the correct containers when necessary. If JS video players can convert HTML 5 MP4 files into Flash video on the fly if the browser does not support HTML 5 MP4, then why not be able to do the same with M2TS data?
I might be ignorant on some level, but maybe someone can shed some light on this issue, and possibly present a solution.
There currently is no good solution.
A little background.
Video streaming used to require custom protocols such as RTP/RTMP/RTSP etc. These protocols work fine except, we were basically building two separate networks. One HTTP based for standard web traffic, and the other one. The idea came along to split video into little chunks and serve them to the player over HTTP. This way we do not need special servers/software and we could take advantage of the giant HTTP CDNs that were being built. In addition. because the video was split into chunks, we can can encode the same video into different qualities/file sizes. Then the player can choose the best quality video for its current bandwidth. This was the perfect solution for mobile because of the constant changing network conditions. Several competing standard were developed. Move networks was the first to market [citation needed]. The design was copied by Microsoft (Smooth Streaming) and Apple (HTTP Live streaming aka HLS). Microsoft is phasing out smooth streaming in favor of DASH. DASH looks like it will become the default streaming solution of the future. Except, because of its design-by-comity approach, it has basically been stuck in comity for a few years. Now, in those few years, Apple sold Millions of IOS devices. So HLS can not just be discontinued. Why doesn't everyone just use HLS then? I can think of three reasons 1) Its Apples standard, and people are haters. 2) Transport streams are a complicate file format. and 3) Transport streams a patent encumbered. MP4 is not patent encumbered but it also does not have the adaptive abilities. This make user experience poor on 2G networks. The only network supported by the iPhone 1. Also AT&T at the time did not want full bitrate video streamed over there woefully inadequate celular network. HLS was the compromise. All of this predates HTML5. So the video tag was not even considered in its design.
Addressing your points:
1) It takes time to create the HLS files and playlists from the MP4
files
This is a programing website, Automate it.
2) We are now storing twice as much data on S3
[sic] I want to store only the .ts files and serve both desktop users,
iOS users, and Android users with that single file.
You and me both man :).
Possible solutions.
1) What is specifically wrong with Androids implementation? (except for lack of in older devices)
2) JW player can play HLS (Not sure about on android)
3) Server side transmux on demand.
Doesn’t HLS require 5-10 second .ts segments instead of one big file?
You can do byte-ranges, but you need to make sure all devices you are interested in support it.
If JS video players can convert HTML 5 MP4 files into Flash video on
the fly if the browser does not support HTML 5 MP4, then why not be
able to do the same with M2TS data?
They don't convert. Flash natively supports mp4. It is possible to convert TS in AS3/JS. I have done it. JW player can convert TS in browser. video.js may be able to as well.
I am trying to record audio using an iPhone app and send the audio file through Mail. I need to compress the file before sending. what audio compression Algorithm to use in iPhone App?
It depends very much on your application.
Do you need loss-less compression, or can you afford losing some audio quality?
How fast to you need the file transfer to be?
How fast do you need the compression process to be?
Depending on the answers to these questions, you can choose one of the formats available in iOS.
You can read more here:
http://developer.apple.com/library/ios/#documentation/MusicAudio/Conceptual/CoreAudioOverview/Introduction/Introduction.html
http://developer.apple.com/library/ios/#documentation/MusicAudio/Conceptual/AudioQueueProgrammingGuide/AQRecord/RecordingAudio.html#//apple_ref/doc/uid/TP40005343-CH4-SW4
First choose the right bitrate. Typical bitrates for different purposes:
32kbit/s: AM Radio quality
48kbit/s: Common rate for long speech podcasts
64kbit/s: Common rate for normal-length speech podcasts
96kbit/s: FM Radio quality
128kbit/s: Most common bit rate for MP3 music
160kbit/s: Musicians or sensitive listeners prefer this to 128kbit/s
192kbit/s: Digital radio broadcasting quality
320kbit/s: Virtually indistinguishable from CDs
So if audio contains only speech 48 kbit/s is usually enough. For music 128 should be ok.
Second - you should use good compression codec. For detail information please check this link http://soundexpert.org/encoders-48-kbps but usually you should use AAC codec.
Other options (sample rate, bit depth, etc.) are not so important and usually you should leave them default.
I'm putting together a site that will include some instructional videos that will be 1 to 3 minutes long. The users will be accessing these through standard and mobile browsers. I'm particularly concerned with users of i-devices, such as iPhone/iPod Touch/iPad.
To deliver the videos, I'm will probably use videojs.com player - it seems like a pretty robust choice. Unfortunately, I don't know first thing about what file formats and standards to use for encoding files. H.264 Baseline profile seems to be a good choice, but I really need some direction on where to read up on what might be the best choice.
Please help :)
The best resource I've found for this information is Dive Into HTML 5. They have a very concise breakdown of which formats will work with each of the browsers.
The long and short of it, however, is that h264 baseline is the way to go, especially if your HTML5 video player has Flash failover.
While HTML5 video is currently the standard in the mobile space, a back of the envelope calculation reveals that only about 40% of desktop browsers users can view it as compared to Flash's 99%+ market penetration. Moreover, you'd have to encode and store your videos twice (h264 and Theora) in order to reach all HTML5 video capable browsers.
However, by using h264 video and a Flash failover, you can cover all iDevices plus all browser that either don't support HTML5 video, or support HTML5 video for a format other than h264.
One word of warning: iDevices only support the h264 baseline up to level 3.0, so make sure to stay within these specs.
Hopefully that helps.