I had some more advanced questions which I couldn't find answers to. My company does both television production and Android development, so Google TV is a natural progression for us. We have a Logitech Revue for website development testing, however, we were unable to make Google IO and get onboard with "FishTank" for app development. I hope there are opportunities for other developers to get on board because we have some great ideas we are looking forward to implement!
Multichannel Audio Support
I notice there is decode support for DTS / AC3 (Dolby Digital) and encode support for AC3 (Dolby Digital) listed in Supported Media Formats. However, there is no information regarding more then 2 channels (Stereo) of audio. Would there be encode support for more then 2 Channels? Such as 5.1 or 7.1? Would these discretely accessible? Could we generate multichannel surround resource files in tools such as ProTools?
Rec. 709 HD Luminance Standards
Do our resources have to confirm to Rec. 709 Luminance Standards? Where reference black is 16 and reference white is 235? Or are the graphics luminance ranges remapped automatically? I also have the same question regarding encoded material in MPEG-2?
For more information on Rec. 709, check out this wikipedia entry.
Overscan and addressable space
I've read the Display Guidelines and was not clear on if Andriod binds you to the display dimensions set during the user screen measurement phase. If it does, could this be overridden? Most television content is already generated with overscan in mind.
Thanks so much! I'm really looking forward to developing!
Scott
I originally posted this on the Google TV Group, this is probably a more appropriate place.
AC3 Encoder:
The AC3 encoder is only available for mixing AC3 stream with Android audio. It maybe possible to play multi-channel audio through AudioFlinger because it does not explicit limit the number of tracks to two. We haven't tested it and engineering isn't hopeful. At the moment there is no way to play multi-channel audio other than embedding AC3 or DTS stream in a proper media container and play it on the MediaPlayer interface.
If it does work internally, it will depend on each OEM's implementation to actually get to the speakers.
Rec. 709:
On the Intel platform, the output is configured for Rec. 709 and the RGB graphics pixels are automatically converted from full RGB to Rec. 709. The color space meta data in the video stream is passed by the decoder to the renderer and converted to Rec. 709 automatically.
Graphics resources should be authored in full RGB space.
MPEG-2 video should be encoded in Rec. 709. If it is SD content, it should probably be left at its original Rec. 601 color space and let the hardware perform the conversion.
Overscan
Android does bind you to the display dimensions set durring the user screen measurement phase. It's not possible to override.
Related
I am working on a video conferencing project. We were using software codec for encode and decode of video frames which will do fine for lower resolutions( up to 320p). We have planned to support our application for higher resolutions also up to 720p. I came to know that hardware acceleration will do this job fairly well.
As the hardware codec api Media codec is available from Jelly Bean onward I have used it for encode and decode and are working fine. But my application is supported from 2.3 . So I need to have an hardware accelerated video decode for H.264 frames of 720p at 30fps.
On research came across the idea of using OMX codec by modifying the stage fright framework.I had read that the hardware decoder for H.264 is available from 2.1 and encoder is there from 3.0. I have gone through many articles and questions given in this site and confirmed that I can go ahead.
I had read about stage fright architecture here -architecture and here- stagefright how it works
And I read about OMX codec here- use-android-hardware-decoder-with-omxcodec-in-ndk.
I am having a starting trouble and some confusions on its implementation.I would like to have some info about it.
For using OMX codec in my code should I build my project with the whole android source tree or can I do by adding some files from AOSP source(if yes which all).
What are the steps from scratch I should follow to achieve it.
Can someone give me a guideline on this
Thanks...
The best example to describe the integration of OMXCodec in native layer is the command line utility stagefright as can be observed here in GingerBread itself. This example shows how a OMXCodec is created.
Some points to note:
The input to OMXCodec should be modeled as a MediaSource and hence, you should ensure that your application handles this requirement. An example for creating a MediaSource based source can be found in record utility file as DummySource.
The input to decoder i.e. MediaSource should provide the data through the read method and hence, your application should provide individual frames for every read call.
The decoder could be created with NativeWindow for output buffer allocation. In this case, if you wish to access the buffer from the CPU, you should probably refer to this query for more details.
In my app I need to play videos from sdcard. Now it works fine on Galaxy S,Galaxy Tab2, But on some chinese tab Like "Giada" It is not working at all.
I have 4 different activities to play videos like. First activity plays a menu video which has navigation link to other activity. Problems I am facing.
First Video plays properly but looping failed and app closed.
If I navigate to other activity to play another video it says "Can't Play Video" and closed Some time it plays same video but not complete and closed app in between.
Video Extension: MP4
Resolution : 1024x600
Playing From : SDCard.
Target Tab Specification.
Resolution : 1024x600
Android :4.1
Tried with Video View and SurfaceView.
Help me out any help will be regreted.
The answer to this question will never be consistent across all devices or across all videos.
Whether a given video file will play in a given player depends on three things:
The video container format (file type).
The codecs the video (and potentially audio) streams are encoded with
Your player's support for that combination of container format and codec
The codec and player/device support for it is almost certainly the cause of the inconsistent results you've seen. (A codec, if you didn't know, is basically a repeatable mathematical formula that tells your system how to turn bits and bytes packed into a file into moving pictures(and back again, for that matter))
There are a large variety of video codecs in the video files floating around out there. Support for these codecs is wildly inconsistent just due to the history of video distribution. Many devices won't support streams encoded with certain codecs. There are a variety of reasons for this, but the most common are obscurity or licensing costs.
For example, up until a few years ago, almost everything was encoded in an .FLV container with an On2 VP6/VP7/VP8 codec. This is causing headaches today because while On2 owned these codecs, they kept a tight rein on the licenses. That didn't relax until .FLV had already begun to lose relevance, and so there is not a whole lot of (legitimate) software out there that can work with On2-encoded content.
What all of this means is that there is no silver bullet. All video will never run on all devices, at least not without the aid of video players that install and use their own codecs to decode the streams.
Needless to say, this does not include the libraries provided to you and your end users by the factory-installed Android libraries.
So, what do you do? Well, short of producing a video player that carries its own codecs, you can most effectively address the problem with a two-step approach:
Target specific devices that you want your application to work on
Encode your content to use use a video codec that works on all the devices you want to target. You may need to produce two copies of your video if you find that there is no codec that works across all devices you plan to support.
Today, the widest support is available with an MP4 container and a video stream encoded with the H.264 (AVC) codec. As I said, there is no silver bullet, and H.264 support is not universal by any means, but this one format will be playable more potential users than any other single choice you could make, due to its popularity and wide support in modern desktop and mobile environments.
Some tools you may find helpful:
MediaInfo will let you peek inside MPEG-flavored video containers to see what codecs are in use. This will be helpful in determining which devices are having trouble with which codecs.
FFmpeg is an encoding application that can convert your content to MP4/H.264
Android Supported media formats
List of supported media audio/video formats.
Good luck!
I am developing an Android application that needs to send short (<60 second) voice messages to a server.
File size is very important because we don't want to eat up data plans. Sound quality is important to the point the message needs to be recognizable, but it should require significantly less bandwidth/quality than music files.
Which of the standard Android audio encoders (http://developer.android.com/reference/android/media/MediaRecorder.AudioEncoder.html) and file formats (http://developer.android.com/reference/android/media/MediaRecorder.OutputFormat.html) are likely to be best for this application?
Any hints on good starting places for bit rates, etc. would be welcome as well.
We need to ultimately be able to play them on Windows and iOS, but it's okay if that takes some back-end conversion. There doesn't seem to be an efficient cross-platform format/encoder so that's where we'll put in the work.
AMR is aimed precisely at speech compression, and is the codec most commonly used for normal circuit-switched voice calls.The narrow-band variant (AMR-NB, 8kHz sample rate) is still the most widely used and should be supported on pretty much any mobile phone you can find. The wide-band variant (AMR-WB, 16kHz sample rate) offers better quality and is preferred if the target device supports it and you can spare the bandwidth.
Typical bitrates for AMR ranges from around 6 to 14 kbit/s.
I'm not sure if there are any media players for Windows that handle .3GP files with AMR audio directly (VLC might). There are converters that can be used, though.
HE-AAC (v1) could also be used for speech encoding, however this page suggests that encoding support on Android is limited to Android 4.1 and above. Suitable rates might be 16 kHz / 64 kbps.
I am having problems figuring out how to detect if an AAC audio source is compatible with Android. The supported media formats page for android says 'AAC LC/LTP' when delivered as 3GP, MPEG4 or ADTS raw AAC. It appears the LC means 'Low Complexity" and LTP means "Long Term Prediction" but, my biggest frustration is determining what AAC profiles/modules are supported on Android. When I run the input into ffmpeg, i see its AAC, but no extended information about the AAC. An example source is http://6693.live.streamtheworld.com:80/WTMJAMAAC_SC . Anyone have any ideas?
You can get extended media information programmatically using the MediaInfo library available here:
http://mediainfo.sourceforge.net/en/Download
The "DLL" or other media downloads include example code in C, C#, etc.
If you do not want to write any code, the same website has downloads for "MediaInfo", a program that uses the library to display information.
Your Android supported media formats link says: "Mono/Stereo content in any combination of standard bit rates up to 160 kbps and sampling rates from 8 to 48kHz". Notice the sample below shows all of those: Channel(s), Overall bit rate, and sampling rate.
It may be necessary to test for yourself whether "up to 160 kbps" means "Up to 160 kbps overall" or "No part of the file, including those encoded with variable bit rates (VBR), may surpass 160kbps."
It is noteworthy that I have played movies on my single-core Android phone which have 256KBit VBR AAC 6-channel audio, though obviously I did not hear the rear surround channels. Because of those, I suspect that the limitations proposed in the link are minimums allowed by Google, but that the audio formats supported in practice are much more broad.
Here is an example from an actual AAC file (using the MediaInfo program):
Format : ADTS
Format/Info : Audio Data Transport Stream
File size : 176 KiB
Duration : 30s 707ms
Overall bit rate : 46.8 Kbps
Audio
Format : AAC
Format/Info : Advanced Audio Codec
Format version : Version 4
Format profile : LC
Format settings, SBR : Yes
Format settings, PS : Yes
Muxing mode : ADTS
Duration : 30s 707ms
Bit rate mode : Constant
Bit rate : 46.8 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Stream size : 176 KiB (100%)
I wrote a wrapper library in C# for MediaInfo. It isn't necessary to use MediaInfo, but makes its use much easier and more ".NET-friendly". It can be found here: MediaInfo.Net.
Load the source into Media Player Classic.
View its propreties.
In the MediaInfo tab it would list:
Format : AAC
Format profile : LC
If you just want to check the profile used for a few files, you may use VLC or any other program (like Sheepy already suggested) - in VLC it's in Extras -> Media Information -> CodecDetails and in your example stream, it's AAC SBR+PS (this is a High-Efficiency Profile), which is decodable by android.
If you do have control over the media you want to play through android, you may want to check out this blog article on cross platform mobile media for the correct encoding. If not (e.g. because the user might be able to choose his own urls or files), you should instead catch any exceptions and display an error message. That way, you are also future proof against new media types, which might be supported in future android versions.
According to developer.android.com, the Android supports the playing of video using the H.263, H.264 AVC, MPEG4 SP and VP8 codecs. However, I want to play a video encoded in the .mxf format (Material eXchange Format, http://en.wikipedia.org/wiki/MXF) in my app. How do I go about it?
MXF generally contains MPEG-2 / AVC video with profile/levels not supported by the decoders in the android devices. Specifically IMX is 422 profile at main level and HD MPEG-2 MXF is generally 422 profile at high level.
The rule of the thumb says that you must use the most common and less resource intensive codec. Bad video playback is a deal breaker. Maybe you know the huge difference that format makes but the user won't.