I'm looking for a way to integrate opus-codec (the decoder part) with my Android application.
Do you know of any implementations that have done so? We are currently using ogg-vorbis for spoken prompts, considering going with either speex (deprecated, but with few documented attempts) or opus (currently no documented attempts).
If we would have to go the NDK route, do you think it should provide us with a application size improvement? OggVorbis is supported by the platform, neither speex nor opus are.
I recommend you have a look at the Opus API documentation. Also, there's now an OpusFile library (equivalent to Vorbis' libvorbisfile) in early development. Otherwise, you can always read the opusdec source code.
Related
I am thinking about making app on videos in android. I came to know that there are 2 famous libraries, FFMPEG and Vitamio.
I just want to know that can i do simple video functions like playing the video, grabbing a frame, converting video to mp3 with both the libraries? What are their pros and cons?
Thanks in advance.
Vitamio is much easier to use. It is just like the default MediaPlayer in Android but with some fancy capabilities. At the same time it can't do everything you want. As I understand it just plays video.
FFmpeg is not as simple. It is quite a powerful library that requires some thoughtful native coding in C. I'm sure you can do whatever you need with it, but it will cost you lots of efforts.
So I can recommend you to use either default Android's or Vitamio's MediaPlayer for playing video. And implement some specific features with the help of FFmpeg.
Old question, but since I'm working on this very problem and I found a lot of outdated information, I think it might be worth an answer anyway.
Vitamio is acually based on ffmpeg which makes the "Vitamio vs ffmpeg" question moot:
What's Vitamio, on the Vitamio website
The Media Formats paragraph cites:
Vitamio used FFmpeg as the demuxers and main decoders, many audio and video codecs are packed into Vitamio beside the default media format built in Android platform, some of them are listed below.
the "used" instead of "uses" looks like a typo (the site is choke full of them...).
Therefore the tip of the scale would point toward Vitaminio, it seems, as it's very easy to use. However...
Vitamio is a derivative work of ffmpeg for android, with an unspecified license (it's spelled quite clearly on the site that individuals can use the library for their own apps freely, though. That part was probably added after the answer by Marcus Wolschon)
ffmpeg for android is a derivative work of ffmpeg (more than that, actually: it's a port) and it's released under the LGPL v3 to abide it's contractual terms with ffmpeg (it actually does), relaying the same obligations to the user in a viral way (attribution, making the source of the library used for the compilation available, etc etc)
ffmpeg (the original work) is released under a dual license: a very liberal GPL (of no consequence in this discussion) and LGPL (the one picked by ffmpeg for android)
What follows is strictly my biased personal opinion, not a statement about the facts
This leads me to think that unless the company selling Vitamio has some agreement with both the author of ffmpeg android and ffmpeg, that we know nothing about, Vitamio is violating the copyright of ffmpeg for android (and therefore ffmpeg) hard.
The fact that the Vitamio's website has a lot of broken links, a grammatically challenged documentation, and not all legal information required for an educated choice, doesn't exactly plays in its favor, if I had to make my mind between considering them a high profile company or some individual trying to live off the back of the ffmpeg team's work...
This leads me to the following considerations:
from a practical standpoint, Vitamio might or might not be the best choice as it should be easy to integrate in your project (I say it should, as I didn't manage to do it yet, and I have quite some experience as an android developer under my belt...). The conditional is due, as the software is based on ffmpeg for android, which already makes an effort for easy Android integration.
from a legal standpoint, the situation is even more shadier, the options are:
turn a blind eye. The company behind Vitamio says that the product is fine and it's free to use (more than that actually: it sells the library), so if there is a licensing issue, it's their issue: as developers we have a semi-legitimate reason to bother to a point, as we would be as cheated as the people behind ffmpeg (I'm not very convinced about this whole argument myself...).
golf for honesty and shun Vitamio, adopting ffmpeg for android instead, which might mean more homework during the integration, both to replicate MediaPlayer and to abide to the LGPL terms, but guarantees a clear conscience
I didn't my mind yet, but I'll probably opt for "2"
Hope this helps
UPDATE It looks like that Vitamio is (at least partially) complying with the terms of the LGPL license, as they are publishing the source code required to build their product:
ffmpeg for Vitamio on GitHub
I don't have the time to find out if this is all that's required for complying with the original ffmpeg license (I'm skeptic), and how that influences the previous considerations (sorry).
You can't use Vitamio in any project because it has no license.
Without a LICENSE file or any other mention what rights you are granted you are granted to rights to use it at all.
See here: http://vitamio.org/topics/93?locale=en
I am writting an app which needs to decode H.264(AVC) bitstream. I find there are AVC codec sources exist in /frameworks/base/media/libstagefright/codecs/avc, does anyone know how can one get access to those codecs in an Android app? I guess it's through JNI, but not clear about how this can be done.
After some investigation I think one approach is to create my own classes and JNI interfaces in the Android source to enable using the CODECS in an Android App.
Another way which does not require any changes in Android source is to include CODECS as shared library in my application, use NDK. Any thoughts on these? Which way is better(if feasible)?
I didn't find much information about Stagefright, it would be great if anyone can point out some? I am developing on Android 2.3.3.
Any comments are highly appreciated.Thanks!
Stagefright does not support elementary H.264 decoding. However it does have H.264 decoder component. In theory, this library could be used. But in reality, it will be tough to use it as a standalone library due to its dependencies.
Best approach would be use to JNI wrapped independent h.264 decoder(like the one available with ffmpeg).
I'm looking for a way to decode AAC natively to PCM on Android. The decoder source code is at https://android.googlesource.com/platform/external/opencore/+/master/codecs_v2/audio/aac/dec, but I'm not familiar with NDK at all.
1) There's no way of doing this directly using the Android SDK, but can this be done via the NDK?
2) I would especially be interested in a simple way of accessing the decoder from SDK, with a short "bridge" through the NDK. Is this feasible?
3) Would such a solution work all Android versions (1.5-2.2)?
4) I guess I could use http://code.google.com/p/aacplayer-android/ instead, but it looks like this implementation is fairly CPU intensive. Does anyone have experiences with this?
Not sure what the policy is here for answering really old questions but what is working well for me is using OpenSL with the NDK; it comes built in and in fact the NDK comes with an example "native-audio" that demonstrates what you need.
One thing you may look into is the FFMpeg stuff, it is GPL and TuneIn radio posted their mods here: http://radiotime.com/mobile/android#/support/open-source
I want to use the codecs in Android from my application. For now I just want to use the H.264 codec for testing, unless the mp3 or aac codecs provide functions for sending the audio to the device's speaker in which case I would prefer one of those.
I have the NDK installed along with Cygwin, GNU Make, and GNU Awk. I can't figure out what I need to do from here though. I'm downloading the entire OpenCORE tree right now but I don't even know how to build it or make Eclipse plugin know it needs to include the files.
An example or a tutorial would be much appreciated.
EDIT:
It looks like I can use JNI like P/Invoke which would mean I don't have to build the OpenCORE libraries myself. However, I can't find any documentation on the names of the libraries I need to load.
I'm also confused as to how to do it. I'm looking at http://www.koushikdutta.com/2009/01/jni-in-android-and-foreword-of-why-jni.html and I don't understand what the purpose of writing a library to access a library is. Couldn't you just use something like System.loadLibrary("opencore.so")?
You cannot build opencore seperately. It has to be built with whole source code. What are you trying to acheive. If you just want to play a video/audio, use VideoView or MediaPlayer object.
Build the Android source and use the headers and the static library from it. This will propel you straight to the zone of unsupported APIs.
Has anyone built OpenAL for the Android, or found the shared library for it on the system? This seems like an obvious need for a game of any kind, yet there's no resources out there for it. It seems the Android java sound library can't do pitch changes from what I can tell, so there seems a need for OpenAL. I know OpenAL Soft can be built on top of ALSA, but I'm not sure if anyones done that, and I'm sure it would take me a month.
If there's a good guide somewhere on sound manipulation on the Android without OpenAL, that's fine too. It's just that OpenAL is sort of a standard for game makers and it would be nice to port my thousands of lines over to this system, which I sort of thought was the point of the NDK before I dugg into it and saw that there's almost no shared library access on the system.
Thanks.. I hope I can actually port without becoming a java expert myself. Really disliking the NDK so far!
A few options are available now for NDK audio:
It's not OpenAL, but OpenSL ES 1.0.1 is an official part of the NDK as of API level 9 (2.3). More information here.
OpenAL Soft has an OpenSL ES backend in its git master (not released as of version 1.13). It is however at this time broken on Android, as it is written for OpenSL ES 1.1, not 1.0.1. See this commit for a fix.
As mentioned in a previous answer, a JNI backend for OpenAL Soft is linked to and described here as the only option for OpenAL on pre-2.3 Android platforms. However, this is an outdated fork of OpenAL Soft - I've updated the backend to the latest version on a github repo here along with the OpenSL ES 1.0.1 fix. Also included is an untested optional patch that claims to provide better performance and less latency.
Just before Google announced that 3D audio is going to be included into Android 2.3, I managed to compile OpenAL for Android, and package it as shared object.
See http://pielot.org/2010/12/14/openal-on-android/
Might still be helpful if you'd like to target devices < 2.3.
Cheers.
OpenSL is planned for a future Android build; OpenAL isn't available, and the low-level hardware is off-limits to anything you can do in the NDK, so you can't safely build it yourself.
There's no support for low-latency audio even planned; there's a bug to that effect here:
http://code.google.com/p/android/issues/detail?id=3434
Star it if it's relevant to you; maybe Google will listen if it gets enough stars.
EDIT: There IS low latency audio in Android 4.0+, and OpenSL is available now. See this page and linked pages: http://source.android.com/devices/audio/latency.html Also see the NDK guide on OpenSL.
You can use the NDK to build OpenAL and package it with your APK. That way you can access it from your native code.