I've made an app to view vine videos on Android devices. These are basically .mp4 videos being loaded into a VideoView. From the following documentation (http://developer.android.com/guide/appendix/media-formats.html), mp4 video playback is supported on Android version 3+ devices.
I've already added a android:minSdkVersion="11" to the manifest file to filter out older android versions from downloading the app, but I'm still getting feedback from users running newer versions of Android (eg. 4.1, 4.2) that complain about getting a "Video cannot be played" error message.
Since there's no way (that I know of, please correct me if I'm wrong) to test video playback using the emulator, I can't really know what's going on.
Is there any way to check for a device's ability to do video playback or at least get the emulator to play videos, so I can correctly fix this issue?
pd. for those interested, here's a link to my app in Google Play. As you can see, I'm being crushed by negative reviews: https://play.google.com/store/apps/details?id=com.thirtymatches.vineflow
If you look at the Google compatibility matrix closely, you'll see that support for MP4/H264 encoding started with the Android 3.0 release. Playback of MP4/H.264 has been supported by all Android devices back to Android 1.0, so there's no need for you to limit availability to newer releases of Android (unless you have other API compatibility needs).
Via VideoView, the video playback on all these devices is done using the hardware decoder provided by the phone's chipset. So to guarantee compatibility, the video has to be encoded to lowest-common denominator. Google provides "Video Encoding Recommendations" at the bottom of the page you linked; I also wrote an answer describing how we transcoded to a form of MP4/H264 that plays across all Android devices.
Not knowing what Vine is doing with their video clips, it might be that the videos aren't all encoded with uniform encoder parameters. They might be taking the videos straight off handsets and streaming them without any additional server-side processing to ensure wide compatibility; I don't know. If that's the case, you might find it challenging to develop an Android app that can show the content without a) implementing your own software codec (as apps like RockPlayer, MX Player or VLC do) or b) transcoding the videos on a server (which probably will run afoul of Vine's terms of service).
Related
=== BACKGROUND SUMMARY===
At this moment, we are using Android VideoView to perform video play black. Everything seems to be working great until we encounter Live Streaming.
VideoView tends to have 10-15 seconds delay from the live stream within a local network (LAN).
While attempting to solve this issue, we came across VLC Embed for Android. After searching on the Internet, it seems there isn't any article compare pros and cons of using Android VLC Embed vs. Android VideoView.
=== QUESTION ===
What's the advantage (pros) and disadvantage (cons) of using Android
VLC Embed vs. Android VideoView?
Is VLC Embed stable?
Anything I should be careful when switching existing VideoView to VLC?
Thank you all in advanced
My view may not be very professional but it's about what I've experienced so far.
First, Android VideoView is good since it comes with the Android SDK so it does not require external library. But this one has some limits. For example, as far as I know, it doesn't support MMS and MMSH protocols and some others I didn't quote. Which is not the case for Android VLC SDK. This library is complete and supports almost all media formats I know so far.
It just increases your apk on size, on my side that's the only disadvantage.
Is the Android VLC SDK stable? Yes it's stable and maintained by a huge community.
Anything I should be careful when switching existing VideoView to VLC?
You should keep your sources same and care about aspect ratio.
What's the advantage (pros) and disadvantage (cons) of using Android VLC Embed vs. Android VideoView?
Advantage：
More features. VLC supports almost all media formats, hardware decoding. audio tracks, subtitles, chapter are also supported.
More integrated, simpler logic. You can easily get media information and cache them. The playback engine will proactively notify state changes and events, just register player event listening.
Disadvantage:
APK file size increas. If both arm64-v8a and armeabi-v7a are supported, it will increase more than 30MB.
Multiple instances are not perfect. For example, playing 2 videos at the same time is a hassle.
Is VLC Embed stable?
Stable. Starting with VLC 2.0.x (now 3.0.x), I use the VLC library in my Android App. It runs steadily from Android 5.1 to Android 8.0. A small number of 4k h265 video playback is not normal, but can be resolved by displaying "Can not play".
Anything I should be careful when switching existing VideoView to VLC?
To use LibVLC on Android The Medialibrary(org.videolan.medialibrary) is also required. You also need to note the licenses.
VLC for Android is licensed under GPLv3
This may be a concern for you if your project uses a different license.
From
Android Developers - Enhanced camera & video,
Android 5.0 also adds support for multimedia tunneling to provide the
best experience for ultra-high definition (4K) content and the ability
to play compressed audio and video data together.
Any details or specifics of how Lollipop can play compressed Audio/Video? Also, what are the changes regarding that compared with earlier versions?
From the sources, there is some amount of understanding as captured in this post on Google groups: https://groups.google.com/forum/#!topic/android-platform/isNabAHLLks
To summarize, the implementation of the video tunneling is vendor/device specific implementation.
EDIT: The aforementioned information is for the new feature Video Tunneling introduced in Lollipop. The normal playback is handled through NuPlayer unless there is a system property employed to specifically use StagefrightPlayer as shown here.
you can get clearly concept from
https://medium.com/google-exoplayer/tunneled-video-playback-in-exoplayer-84f084a8094d
If you want to know more detail, I think you could download
AOSP project to trace the tunnel mode APIs.
So with StageVideo you can play a h264 .mp4 file, and by any example which I found you need to have a fallback Video component.
Problem is that I was unable to play the .mp4 video files with the Video component on a mobile device, Android or iOS.
.flv works fine, but I can't have backup video files as it takes too much space.
Is it really necessary to have the fallback to the Video component? what are the chances it will fail?
Thanks.
From my experiences (I've created 3 separate AIR VOD apps for both iOS and Android), the following is true:
StageVideo works on Android 4.0+. I was unable to get it to work with 3.x, but I have been told it works. I can, for sure, confirm that it does not work on 2.x.
StageVideo works on iOS 5+. On iOS 5, you will need to play a silent sound at startup to make sure sound works, but you should do that regardless since the iPad 2 rarely plays sound without doing that. It is a known bug in AIR that, as far as I know, has never been attempted to be fixed
iOS can only play h.264 MP4s through StageVideo and StageWebView. They will not work in Flash video players (including VideoDisplay, the base for Video and all OSMF-based players). I do not recall the exact reason for this, but I believe it has something to do with the MP4 requirement for hardware accelerated playback.
iOS can play FLV and, maybe, F4V through the Flash video players described in #3. This will lack hardware acceleration, however. That means your video and your UI will run on the same thread and share the same process. Basically, lower framerates while video is playing. Additionally, CPU decoding is a battery drain.
Android is a little more wild. You cannot use StageWebView for any playback as of Android 4.3 (have not tested on 4.4 yet). You can use Flash video players for h.264 MP4s... on some devices. I've found that they seem to work fine on Android 3.0+ on all devices I have tested. Keep in mind that is only a couple dozen out of over a thousand possibilities, though. On 2.x, it is extremely hit-or-miss. It seems to work fine on HTC and Motorola devices (which I've tested on), but I have had reports from users who cannot playback on Samsung and Sony devices.
As you mentioned, a fallback player is definitely recommended. Without having multiple sources/encode types, the fallback is useless on iOS, however. I currently have an app in the Play Store (All About Trikes) that was originally released without a fallback player and just used a StageVideo implementation. A day after release, we started getting reports that users on 2.x couldn't play videos. We had to scramble. We first released a version that couldn't be installed on 2.x and then another version that uses Flex's VideoDisplay as a fallback, which seems to have fixed the problem for those users, but I know there will be others than cannot playback video.
Long story short, there is no fool-proof way of playing back h.264 MP4s on mobile using AIR. You do want to include a fallback player, regardless of platform. Ideally, if you are streaming the video, you should have both h.264 MP4s and FLVs available with the fallback using FLVs instead of MP4s.
Hopefully that helps.
Is it possible to perform adaptive (multibitrate) streaming onto an Android device? If yes, how to do that?
If you have 4.0 or 3.2 you just use access the adaptive stream as you would any other video. Literally.
It's a HTTP access.
So if you use as a data source //mywebsite/video1.mp4 you woulduse as a data source the equivalent //mywebsite/video1.m3u8. Now, I'm not including any discussion on how you create your streaming file but only how you would access it.
All the magic happens within the client (ex: mediaplayer, videoview) supported on 4.0 and 3.2. For the record, you may be able to access and run streaming segments (.m3u8 files) on earlier versions of Android because the manufactures have sometimes played around with the code. But I haven't found any that actually adapt. They usually stick to the first segment they run or default to the lower bitrate segment in the bunch and stay there regardless of bitrate.
I'm writing an app for a multimedia website I frequent and I've run into a problem.
After grabbing a video stream URL (h264 wrapped in an mp4 container) and attempting to play it with the native video player, it fails.
This is on my Moto Droid running 2.2 (BB) and 2.3 (CM7). I've tested the app on my Xoom (3.1 stock) and it works great.
I've also had a friend test it on her Xperia Arc (2.3 stock as far as i know) and it worked for her. Makes me think it's a hardware decoder issue since I can play the stream fine using RockPlayer's software decoder but can't using the hardware one.
So I have three things here I want to find out:
Does the native Android player support software decoding. if so, how do I tell if it's using hardware or software and is it possible to toggle?
are there any 3rd part media players with readily available SDKs (free).
How can I just open the video in another app like Rock Player since I know it works. When I download a video using the browser, it asks me what video player I want it to use. How can I get this to pop up within my app and then send the video to it?
Yes, Android provides software h264 decoder, but it may not be available in 2.2. You can prefer software codec, see AOSP source code for stagefright:
usage: stagefright [options] [input_filename]
…
-s(oftware) prefer software codec
…
ffmpeg has many derivatives and wrappers on Android, which are available with a variety of license restrictions.
It's pretty easy to launch an Intent that targets a specific app. You can use setComponent() to match exactly the Activity you need. The better and more flexible way to deal with the problem is to create a custom Chooser (see e.g. Custom filtering of intent chooser based on installed Android package name), to let the user decide which player she/he prefers. With a custom chooser, you can decide to hide some of the handlers that are registered to the Action (e.g. not use the system player on Android version below 3.0).