So even on my brand new MT4G with Flash, it won't let me stream from the website and to my knowledge the Netflix App doesn't yet support video like it does on the iPhone.
Has anyone else figured out a workaround yet? I was thinking maybe there's some way to "trick" the YouTube app into doing it for me.
Thanks!
Im not exactly sure, but i think netflix uses silverlight and that doesnt work on android. There is no official netflix app on android yet.
http://blog.netflix.com/2010/11/netflix-on-android.html
The same security issues that have led to piracy concerns on the Android platform have made it difficult for us to secure a common Digital Rights Management (DRM) system on these devices. Setting aside the debate around the value of content protection and DRM, they are requirements we must fulfill in order to obtain content from major studios for our subscribers to enjoy. Although we don’t have a common platform security mechanism and DRM, we are able to work with individual handset manufacturers to add content protection to their devices. Unfortunately, this is a much slower approach and leads to a fragmented experience on Android, in which some handsets will have access to Netflix and others won’t.
Click to expand...
Click to collapse
Silver light, a MS app, runs netflix streaming
Sent from my PC36100 using XDA App
Hello,
I'm thinking about new project - podcasting for mobile phones mainly for Android OS phones. I need compatibility with Iphone's which are devices WITHOUT flash support.
<b>I am looking for any solution which I can put into my mobile site and stream videos to the viewer. </b>In other words, I am looking solution for share my video podcasts with users on mobile devices. I would like to make mini youtube for my users I would like to use Flowplayer but flowplayer is written in Flash environment.
I have only one need - It can't be written in with Flash technology, I need to embed any player written in any language than Flash. I hope that any solution is avalaible...
regards
This is not a specific question. Rather, I am asking for your guidance/opinion.
I have to build a video player (that plays Youtube Video, not live streaming) using Java for Android phones.
I would like to know your opinion on:
Which library is the easiest to use and incorporate with Eclipse for developing a video player? I would like to use the Eclipse Android Emulator, if that's possible.
Can u guys suggest tutorials/howtos/books regarding such development. I am new at this, so when I try to search the Internet, I get loads of hits, which confuses me. Please provide me with a starting point.
Bye.
Use the generic class MediaPlayer (included in Android SDK, so it can be easily added to your project).
Good morning to you all!
I've posted this in the thread about the apt-x petition, but didn't get any replies so far. And since it's also partially off topic there, I thought I'd open a new thread.
Beloved mods, if this is the wrong section, then please move it into a more fitting area. I also wasn't sure about the correct thread title prefix, so if this one is inappropriate, please change it to a better one. Thanks!
I'll basically repeat what I said in the thread over there. The thread title actually is a good tl;dr, so here's the longer version:
Apt-x is not a viable alternative as bluetooth codec in Android devices, due to various reasons explained in the thread above. But AAC could be a nice alternative. It's a much more complex and powerful codec than SBC, theoretically resulting in much higher audio quality, if the playback device/bluetooth receiver supports AAC decoding. Maybe AAC isn't as efficient as apt-x, but it's definitely a great format - in low bitrate ranges with HE-AAC and in high bitrate ranges with low complexity AAC (the latter is what's being sold by Apple in the iTunes store at high bitrates).
AOSP does contain a high quality AAC encoder since Jelly Bean (nothing like the FAAC or ffmpeg encoders for AAC, they're not providing good quality), the code has even been extracted for use in other applications that need a high quality AAC encoder, for example the popular video transcoding tool Handbrake. It's available under the name FDK-AAC (also see http://sourceforge.net/projects/opencore-amr/).
My main concern is: I don't see why it shouldn't be possible that AOSP ROMs could use this encoder for encoding audio for A2DP. There can't be any licensing issues, because the codec already is in AOSP, right?. I know that if it were that easy, someone probably would have already implemented that in some custom ROM (or even Google would have enabled AAC over A2DP per default), but I don't understand what the technical problems here are. The only thing I can think of is processing power. Encoding AAC needs moch more power than SBC, but I'd assume that modern smartphones shouldn't have a problem with that. We're talking about playback-speed encoding, it's not like you want to use the encoder on your phone to transcode you music library that should work as quickly as possible. I don't have any numbers, but my common sense tells me that power shouldn't be the issue. Isn't AAC encoding maybe even hardware accelerated on some SoCs, considering that AAC is also being used as audio codec in most video recording formats?
Maybe someone could clear that up for me.
To clarify: I'm not looking for an immediate practical solution, this question is more of theoretical nature. I'd really appreciate it, if someone, who understands this whole bluetooth audio situation in Android, could explain it in words that I (no developer, semi-advanced user with experience in audio formats) can understand. I'd also be thankful for any links to documentation or specifications, which might help to explain things.
I hope you understand what my question is. If not, please ask me, and I'll try to explain it in other words.
Seriously, is really nobody interested in that? Or am I completely wrong with my assumptions?
Please, if someone knows anything about the inner workings of audio via bluetooth in AOSP, share your knowledge. Maybe there exists documentation that I haven't found yet, even just a link would be very appreciated.
This is the only bump of the thread, promised.
It's not that nobody is interested, it's that it's much more complicated than that. Bluedroid does support aac sure, but for an app to support sink for aac then it has to include hardware-specific headers. In an open platform like Android, this is difficult for developers to do.
From what I understand, there is no setting/code in kernels or bluedroid to make any app automagically support aac over a2dp - the apps themselves need to have HCI natives/interfaces. And these may very well be patented by the Oem e.g
Broadcomm.
Sent via Tapatalk on my Xperia Z
This is very insightful, thanks.
I wasn't aware that the apps themselves needed specific support. I thought this was one system-wide thing: Once paired with the bluetooth receiver, the same codec will be used for all A2DP audio. If that's not the case, I see that this makes it even more complicated.
If there are even patents and complicated hardware-specific code required, I understand it's more difficult than I thought.
But impossible? Aren't at least the Nexus devices open enough to try something?
I could be mistaken, this is how I understand it though. I actually investigated this myself a couple years ago and never got anywhere, I needed source code for the *receiver* too. Apparently it's not quite standard or something.
Things may have changed since, at least I bumped the thread maybe someone else knows more
Edit: I wouldn't get your hopes up though. It might be possible, but not legal. Aac is not "free", having the codec doesn't mean they're legally allowed to implement it in every level (I.e. A2dp is different to local file encoding in camera recording) and as the Nexus devices are developer devices not designed for general consumer use I don't see it having support for it. An Xperia device is another story though for example, we even have ATRAC support (obviously requires a Sony headset/device to pair with though).
Sent via Tapatalk on my Xperia Z
CosmicDan said:
I bumped the thread maybe someone else knows more
Click to expand...
Click to collapse
Nah, you've definitely provided some thoughts that I didn't have before. Thanks for that.
CosmicDan said:
Aac is not "free", having the codec doesn't mean they're legally allowed to implement it in every level (I.e. A2dp is different to local file encoding in camera recording)
Click to expand...
Click to collapse
If this is true, how are the FDK AAC and opencore-amr guys doing it? As far as I know, they extracted the AAC code from AOSP and are using it at their leisure without legal consequences. It would be really weird (but possible, I guess), if the AAC code in AOSP may only be used for certain functionality, e.g. camera videos, but not A2DP.
CosmicDan said:
and as the Nexus devices are developer devices not designed for general consumer use I don't see it having support for it.
Click to expand...
Click to collapse
I understand that, but since you said there was some low level access required for some parts of the hardware or firmware, isn't it the developer devices that have the best chance for some solution?
CosmicDan said:
An Xperia device is another story though for example, we even have ATRAC support (obviously requires a Sony headset/device to pair with though).
Sent via Tapatalk on my Xperia Z
Click to expand...
Click to collapse
Sure, there may be manufacturers that are using their own proprietary codecs like ATRAC, but I'm not really interested in that. It's an even worse situation than with apt-X, because the latter is already supported by a variety of devices, while ATRAC will be mostly Sony-only. That's just my assumption, of course.
AAC is supported by a lot more devices, probably due to licensing stuff.
In any case, I'm thankful for your replies.
I'm not sure about those guys, but Ffmpeg for example doesn't include/support aac for patent reasons. The codec is not free, use of an existing codec is free though. http://www.vialicensing.com/licensing/aac-faq.aspx
Edit: Fdk is Fraunhofer, they're actually a shared holder of the patent. So yeah they have the rights to do it. Ffmpeg supports aac, but it's a violation to distribute aac encoding binaries without license so it's DIY in that case.
I did some more research, seems Lg did indeed pay for Aac encoder in Nexus 4. Most recent android devices do.... So I guess there is no legal barrier at all, I'm just talking nonsense
My guess is that there is missing hardware to support viable aac over a2dp, seems strange that it hasn't been done already. Or the aac encoder is separate to bluedroid; and requires a *second* license (along with reimplementation) for it to work with aac. Both seem just as possible to me.
Sent via Tapatalk on my Xperia Z
Yeah, this licensing stuff is very confusing. There's different information on the web, Wikipedia'd description is quite telling... "License: Liberal,[3] but not a license of patented technologies".
They're referencing the official AOSP license file that's included in the source: https://android.googlesource.com/platform/external/aac/+/master/NOTICE
And this document is really confusing to me. An important sentence is;
AOSP NOTICE said:
You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized
by appropriate patent licenses.
Click to expand...
Click to collapse
But it's defined nowhere what these authorized purposes are.
So you could be right about them needing a second license for a different "authorized purpose". And additionally there could be hardware restrictions, that's true. I'm not familiar enough about how this works on a device. Like, is there hardware acceleration for AAC encoding/decoding, or is it done entirely in software. Must the bluetooth chipset specifically support certain codecs, or can it be used as "generic" device and the audio codec is all software stuff? Or is there something specific in the firmware for that chipset/radio etc. I really have no idea.
I'd still like a developer, who knows BlueDroid and maybe the Nexus devices, to explain this. ELI5. And we'll probably need a lawyer to explain the patent/licensing stuff. :laugh:
I *think* the Neon extension in ARM supports aac hardware encoding, or at the very least something in modern soc's would use hardware based encoding. Maybe only decoding, and that's the issue? Software based encoding could be a factor. I don't think it's done entirely in software, not decoding anyway - no idea about encoding to be honest. Probably varies per device. Apparently Samsung's support aptx so that could be an exynos thing for example.
Afaik the a2dp protocol can passthrough already-encoded aac streams regardless as it's part of the specification but I was thinking more of a highspeed (or additional) bus to allow the higher bitrates to work. But I'm just speculating here.
Maybe you'll have better luck asking on the Cyanogenmod forums? Xda is pretty crowded these days. This section is loaded with Chinese related firmware hacking and super-duper script "tweaks".
Sent via Tapatalk on my Xperia Z
Well seems like Google solved it now
Hello,
recently I've been working on an app that can "transform" an Android tablet into an audiobook player for visually impaired, senior people.
The idea is to have a simple to use, single-purpose device built on top of a fairly inexpensive off-the-shelf product.
The UI is geared towards seniors who are not very familiar with technology, whose gestures are not precise any more and who can have difficulties reading due to poor eyesight.
It works well for one person already
Features:
focused on audiobook playback (individual files not exposed in the UI),
reads book titles via Text-to-Speech,
just a single large "start" button,
"flip-to-stop": playback is stopped by flipping the device screen down (the simplest thing I could think of),
kiosk mode.
When the app is installed with the kiosk mode on (no rooting required but it only works on Android 5.0+), the phone/tablet becomes a single-purpose audio player.
You can find a video and the app itself on my website:
msimonides.github.io/homerplayer/
(I can't post links yet, please add the protocol in front of the URL).