I've got an app that enables end-users to upload their audio files. Mostly songs/music. Currently, I am using Zencoder for my encoding service, which allows .mp3, .m4a, .mp4 or .ogg
When a user uploads an audio file, it will be available for other users to listen too via the app as well. Would the mp3 format be suitable enough for this?
The licensing should be a major concern here. mp3 has some interesting licensing conditions based on whether your service is free to the end-user. Too complicated to go into length here, you can look it up on the web or contact Frauenhofer for more details.
The second obvious concern is bandwidth and audio quality. The sampling has to be high enough that the end-user cannot tell the audio has been limited or compressed, but the file still needs to be small enough that the file can be downloaded or streamed quickly. Any broadband connection these days can handle a 320kbps mp3 fairly easily.
Hopefully this will give you some good starting points for research:
wikipedia:Comparison_of_audio_formats
mp3 would suffice, mp4 would be better as it offers improved sound quality and compression over mp3. Ogg is a good format but has less broad support on players.
To state the obvious, the quality of the sound is very much dependent on the original file uploaded by the user. You will never improve on that quality, and each time you transcode between formats, you will degrade the quality.
If you ask people to compare between mp3, AAC (m4a, mp4) and ogg - they will give you different answers. Different codecs with different bit rates produce different audio print. Some claim that for certain specific music types you should prefer one format over another.
You can google different bit rates and comparisons easily - technical part is easy.
I would go for ogg. Here's why:
1) It's easily good enough for the job
2) It's an Open Source
3) You don't get into trouble (legally) using it together with upload encodings.
Related
I'm working on an app that will play several audio files. I have gotten that to work, having no trouble. But I'm not sure what file format to use. Right now I am using .wav and one .mp3. Is there a file type that is recommended? I don't know how the app is packaged for the App Store; should the audio be compressed or uncompressed?
Thank you!
It depends on what you're trying to accomplish.
Personally, I favor compression unless quality is an issue. Mp3s, while lossy is my preferred default. It's a standard file type, easy to work with, it can be high quality and iPhone/iOS is efficient at decoding.
However, if you need higher quality, AAC or uncompressed can be better. It's also possible for an mp3 to take a fraction of a second before it starts to play due to decoding. That may or may not be an issue if your audio is tied to a UI event.
An app bundle is the most common way of packaging the executable code(though not the only way.)
I will recommend you to read the following to know about how the bundle structure is.
https://developer.apple.com/library/ios/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1
With regards to the audio file format, There is no favourite as such for apple. You can find the preferred list of audio formats as:
https://developer.apple.com/library/ios/documentation/AudioVideo/Conceptual/MultimediaPG/UsingAudio/UsingAudio.html#//apple_ref/doc/uid/TP40009767-CH2-SW9
Hope this solves your problems.
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 really stucked with that problem, because I haven't seen enough information in the internet regarding video encoding in iOS, however we can observe plenty of apps that deal with the problem of video streaming successfully (skype, qik, justin.tv, etc.)
I'm going to develop an application, that should send video frames obtained from camera and encoded in h.263 (h.264 or MPEG-4 it is under decision) to a web-server. For this, I need some video encoding library. Obviously, ffmpeg can deal with that task, but it is under LGPL license, which could probably lead to some problems in submitting the app in the AppStore. On the other hand, there are some applications, which are seemed to use ffmpeg library, but only Timelapser clearly states this fact in app description. Does this mean, that other apps are not using ffmpeg or just hiding this information?
Please, share your thoughts and experience in this topic. I'm open for dicsussion.
After googling and making some research in this area, I found this one library http://www.foxitsolutions.com/iphone_h264_sdk.html. They really use hardware encoding. I've examined demo example with instruments, and they showed me that while encoding, ~12% cpu is used and syscall read() constantly called. From that I can conclude, that their library uses standard AVFoundation's AVAssetWriter to write into the temporary file, and (most probably) concurrent thread is used to read this temp file for retrieving encoded frames.
Also, take a look at http://www.videolan.org/developers/x264.html. It is under GPL, but still can be useful.
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 want to find out if I can get some data on the percentage wise distribution of video content, for different video codecs currently used for video encoding. I know there are different applications/use-case scenarios which have different encoder used but i want to consdier all that and have a overall usage number(%)
My guess is(highest to lowest % of content) -
H.264(AVC)
DivX
MPEG2
VP6
Where do H.263, MPEG4, VC-1, RV, Theora, etc. fit in here.
How may this look like in future?
PS:I would like this to be community wiki to have get wider range of inputs, if someone with privileges can do it for me please.
thank you.
-AD
I am guessing that WebM format (which is actually VP8) which is part of the WebM Project will see a rise since YouTube is encoding all of the videos in WebM format as an alternative.
I vote for WebM as a better quality and freer alternative to H.264