I have seen other posts related to these programs. However, none address the ideas/question I have.
chroot = full linux on android = "daddy likes" or in my terms, "awesome, i can convert, compile and port android applications on a bus, plane, work break/lunch etc. But, hmm... I rather would like to attempt to do more... for absolutely no other reason than 'because i can'" So brainstorm with me people.
1st: What settings would be the absolute least CPU intensive to encode/decode on Xvfb?
2: How does one change the refresh(fps)
3: Can it be encoded to mp4, perhaps invoking hardware decoding on an android device? If so, do any *droid* happen to have a hardware encoding option (perhaps because of camera) that can be made use of to improve Xvfb(or clone) performance?
4: What about Kill-android video processes ; link -> chroot or startx?
5: how about a virtualized application container? Something more efficient than vnc, which could execute a process, with hardware supporting inside a "window" that knows what to do with it, rather than emulate a complete frame buffer?
If you are one of those people that read this and want to say something negative: I am ignorant to many things, this is something i realize more with every thing i learn.
Welcome to science.
"Take chances, make mistakes, get messy!" -Miss. Frizzle
Nothing? You realize i will heavily read up on any suggestions you make. Im not looking for directions, im looking for ideas.
I don't really know what are you talking about, take this as a BUMP to your thread
tardisguy said:
3: Can it be encoded to mp4, perhaps invoking hardware decoding on an android device? If so, do any *droid* happen to have a hardware encoding option (perhaps because of camera) that can be made use of to improve Xvfb(or clone) performance?
Click to expand...
Click to collapse
mp4 is just a container, am I right? So you should be looking for what codecs can be encoded/decoded by hardware.
MuF123 said:
I don't really know what are you talking about, take this as a BUMP to your thread
mp4 is just a container, am I right? So you should be looking for what codecs can be encoded/decoded by hardware.
Click to expand...
Click to collapse
Begging your pardon sir, I will be more specific: Yes mp4 is a container format with includes MPEG-4 video compression method. Which when played by most androids is accelerated by an auxilary core processor, which gives you the smooth video playback with far less cpu use.
I, having never thought to actually loop up the hardware features of the powerVR compatable core, theorized the possibility that the acceleration core, might have depreciated encoding abilities in parallel to the decoding. (like maybe the chip encodes because directly encoding video from your phones camcorder, would be highly taxing on the cpu.) But then, if they hadnt thought of that, then the people who designed this core... well ill be nice.
Maybe you need to ask on Droid Development forum, not on Milestone forum, because we have a locked bootloader and we can't use custom kernels or do any bigger modifications.
Related
according to http://www.engadget.com/2009/11/15/samsung-unveils-android-equipped-galaxy-spica-i5700/
the new spica comes equipped with built in divx support. Is this a codec or is it an app that needs ported?
Anyone have any idea?
Nobody knows yet, as there hasn't been a dump from this device made available yet. Also, this should probably be moved to the Q&A area (or general) until there's something development wise that can happen.
Mi|enko said:
Nobody knows yet, as there hasn't been a dump from this device made available yet. Also, this should probably be moved to the Q&A area (or general) until there's something development wise that can happen.
Click to expand...
Click to collapse
What about the LG Eve dump that popped up a few days ago? Now I'm no dev, but I did a little bit of peeking around in it, and there is a bunch of stuff referencing DivX and mpeg4, h264, etc.
Am I wrong in assuming something can be done with those?
Moot
Whether it's a program to be ported or a codec to be included plays no real part in the answer to your question. The simple fact of the matter is that the G1 is too underpowered to do justice to DivX, h.264 or any other high capacity codec. The Spica is coming out with an 800 MHz processor, enabling it to jump through graphical hoops that we can't.
I agree that either way, just codecs or a (hopefully) simple port of a program, that we can at least try watching DivX, but I'm not getting my hopes up.
I bet it's got the decoder in hardware. That'd be a much easier, cheaper way to do it.
zapyourit said:
Whether it's a program to be ported or a codec to be included plays no real part in the answer to your question. The simple fact of the matter is that the G1 is too underpowered to do justice to DivX, h.264 or any other high capacity codec. The Spica is coming out with an 800 MHz processor, enabling it to jump through graphical hoops that we can't.
I agree that either way, just codecs or a (hopefully) simple port of a program, that we can at least try watching DivX, but I'm not getting my hopes up.
Click to expand...
Click to collapse
My 200mhz T-Mobile Wing with 64MB of ram did DivX just fine with TCPMP media player. The G1 can easily handle it if it can bypass the java interpreter.
Sumanitu said:
My 200mhz T-Mobile Wing with 64MB of ram did DivX just fine with TCPMP media player. The G1 can easily handle it if it can bypass the java interpreter.
Click to expand...
Click to collapse
Agreed, especialy if there swap running and other tweaks. Playback shouldn't be a problem but encoding and decoding would not be practical. But I guess we will see. But why not just encode to a format the g1 can handle that's what I do, so there is no need for other codec support.
marixsmith said:
according to http://www.engadget.com/2009/11/15/samsung-unveils-android-equipped-galaxy-spica-i5700/
the new spica comes equipped with built in divx support. Is this a codec or is it an app that needs ported?
Anyone have any idea?
Click to expand...
Click to collapse
The LG dump has divx support as well it looks like an entire media center, video editor and everything. From what i saw its hard coded libraries.
Libmmp_divxreg.so
zapyourit said:
Whether it's a program to be ported or a codec to be included plays no real part in the answer to your question. The simple fact of the matter is that the G1 is too underpowered to do justice to DivX, h.264 or any other high capacity codec. The Spica is coming out with an 800 MHz processor, enabling it to jump through graphical hoops that we can't.
I agree that either way, just codecs or a (hopefully) simple port of a program, that we can at least try watching DivX, but I'm not getting my hopes up.
Click to expand...
Click to collapse
My G1 plays back x.264 video just fine (all of my videos I encode for my phone are x.264 with AAC audio), and when I check on my PC (without hardware acceleration enabled) x.264 takes a little more juice than a similarly encoded MPEG4 ASP codec such as DivX or XviD would. Your argument is flawed.
jmotyka said:
Playback shouldn't be a problem but encoding and decoding would not be practical.
Click to expand...
Click to collapse
And how would playback without decoding the DivX video be carried out?
/Mats
Has anybody tried the yxflash app in the market? It does wmv pretty well and does do DivX video although not convinced how well. Sometimes it's kind of jerky but not sure if that's because it's the trial version. They want $20 on their web site for the full version and I'm not going to pay that without being sure it works all the time every time. But it still gives me hope that we will be able to play DivX on our G1s one day.
Charlie
Have the phone on hands but need help of some specialist to take out rom and player from there.
pls contact me ICQ 7120916
gtalk: [email protected]
Managed to install adb drivers, but because of idiotic rom could not install any apps on it...
Have tried to play divx file- http://www.hpc.ru/soft/software.phtml?id=20980 it did, my htc magic didn't
viewing a "divx" file is simple;
1) you need to switch out the fourcc tag to one that is reconized properly (and compatible -- mpeg4-asp i.e. H263) since nobody in the real world has heard of or cares about "divx",
2) use a recognized CONTAINER format (i.e. 3gp)
3) stick to resolutions and bitrates and other encoding parameters that make sense for the particular device.
Note: The device HAS an mpeg4 decoder chip capable of mpeg4-asp (h263/divx) and mpeg4-avc (h264). The CPU is IRRELEVANT since the decoding is all done in a dedicated video decoder chip.
lbcoder said:
viewing a "divx" file is simple;
1) you need to switch out the fourcc tag to one that is reconized properly (and compatible -- mpeg4-asp i.e. H263) since nobody in the real world has heard of or cares about "divx",
2) use a recognized CONTAINER format (i.e. 3gp)
3) stick to resolutions and bitrates and other encoding parameters that make sense for the particular device.
Note: The device HAS an mpeg4 decoder chip capable of mpeg4-asp (h263/divx) and mpeg4-avc (h264). The CPU is IRRELEVANT since the decoding is all done in a dedicated video decoder chip.
Click to expand...
Click to collapse
Apologies. I did not realize the G1 had a dedicated chip for such things.
zapyourit said:
Apologies. I did not realize the G1 had a dedicated chip for such things.
Click to expand...
Click to collapse
Even if it didnt have the mp4 decoder it still has enough power for divx, every windows phone I had has lower specs or the same processor and played them fine.
The G1 def has enough power I am not sure where you got the information, not being cocky but thats some bad information to spread around.
1Way
lbcoder said:
viewing a "divx" file is simple;
1) you need to switch out the fourcc tag to one that is reconized properly (and compatible -- mpeg4-asp i.e. H263) since nobody in the real world has heard of or cares about "divx",
2) use a recognized CONTAINER format (i.e. 3gp)
3) stick to resolutions and bitrates and other encoding parameters that make sense for the particular device.
Note: The device HAS an mpeg4 decoder chip capable of mpeg4-asp (h263/divx) and mpeg4-avc (h264). The CPU is IRRELEVANT since the decoding is all done in a dedicated video decoder chip.
Click to expand...
Click to collapse
So, having some kind of app decoding h263 when fourcc is divx or dx5 ecc instead, the main problem reduces to the support of common PC "containers" like avi, i'm right?
1wayjonny said:
Even if it didnt have the mp4 decoder it still has enough power for divx, every windows phone I had has lower specs or the same processor and played them fine.
The G1 def has enough power I am not sure where you got the information, not being cocky but thats some bad information to spread around.
Click to expand...
Click to collapse
Agreed.
My Windows Mobile 2003 Samsung SCH-i730 played any video file I threw at it flawlessly.
Flawlessly.
Saying that the G1 is too underpowered is just complete and utter misinformation.
1wayjonny said:
Even if it didnt have the mp4 decoder it still has enough power for divx, every windows phone I had has lower specs or the same processor and played them fine.
The G1 def has enough power I am not sure where you got the information, not being cocky but thats some bad information to spread around.
1Way
Click to expand...
Click to collapse
Every windoze phone you had also had a decoder chip. So what?
fl3xo said:
So, having some kind of app decoding h263 when fourcc is divx or dx5 ecc instead, the main problem reduces to the support of common PC "containers" like avi, i'm right?
Click to expand...
Click to collapse
No, the trick is to simply *change* the fourcc to h263 and/or be able to RECOGNIZE divx AS h263. Adding in more DEMUXERS (not decoders) would also help with dealing with additional containers, HOWEVER, there really isn't much point in supporting avi, since it is a terrible container that doesn't take A/V synchronization into account, AND it is typically used for video's that are over the resolution and bitrate limits.
Note: there may be licensing issues when dealing with certain container formats. I suggest staying as far as possible away from anything that carries a microshaft label on it (like avi, wmv, etc.).
lbcoder said:
Every windoze phone you had also had a decoder chip. So what?
Click to expand...
Click to collapse
What? Man you do not even make sense pfff
The point was a phone with less or equal to hardware specs could play the video fine.
Oh and BTW you should also know that the Windows Mobile Platform never optimized ANYTHING for the decoders built in the phones.
Most recent windows phone for the past a few years has a 3D accelerator that was NEVER used nor optimized expect by a Sony game released for the xperia. (which other phone could run with the correct DLL copied over as well, showing microsoft was lazy on 3D acceleration)
So much for not using the decoders eh?
The point in case you missed it is that WITH or WITHOUT the decoder the G1 has enough power to play the video.
Please use google if you need spoon fed information ...
Hi Everyone,
I m kindly asking you to help me push MS into fixing the avi/xvid issue since conversion times are too long.
edit Several members have also raised concern that the Zune software transcodes videos where there is really no need!
ruscik said:
a 720p Family guy blue harvest in divx (my own copy) was converted to mp4 but resolution was not lowered.
A 720p family guy something dark side in mp4 was converted to mp4 but resolution was not lowered or audio adjusted.
Click to expand...
Click to collapse
I have created a post on the official MS support forums and the fellow users have supported the post but MS is trying not to give a proper answer on the issues unless people reply enough or click the "I would like an answer too" button. The post seems to be ending up unanswered and pushed back. I need to let the post grab MS attention!
I would like MS to escalate the issue internally but I need more input! So please be so kind!
I suggest that we could do this for other issues as well!!!
Their forum relies on Live IDs so it is just about entering your username. (Doesn't take long)
http://social.answers.microsoft.com...7/thread/b71af2ac-9f72-4b10-a5ee-eaa29c1933e7
It can be fixed quite easily.
1) Write down the spec of your computer on a piece of paper.
2) Go to your local PC shop
3) Hand them the piece of paper and ask for something faster at encoding video
4) Happiness
Yep. Crap computers suck at transcoding video. Even a better graphics card would work much better, since lots of GPUs these days can offload much of the conversion.
Some notebooks were sold without multi-core processors (but are still 64-bit, some people assume 64-bit = multi-core), and lots of consumers have things like mismatched ram sticks and the like that can reduce their computer performance for these types of tasks.
Thanks a lot guys!!!! Appreciated!
It looks like they are still ignoring the issue. I think I might try to upvote the thread tomorrow again.
My general issue is that I am accessing different PCs all the time. Let it be work, uni, friends, or my home laptop. So I generally just need a fast way to get stuff onto the device.
Maybe we get lucky and they enable it again
I personally don't think this issue should have a high priority, as Zune software reencode your file on the fly.
Even at Microsoft, ressources are limited, and there are lots a other stuff I would like first (custom ringtones, multitask, silverlight and flash on the browser...)
My 2 cents.
(nico) said:
Even at Microsoft, ressources are limited,
Click to expand...
Click to collapse
The issue here is that it works on the Zune HD without re encoding or demuxing and the same applied to the wp7 emulator until they decided to take the feature out...
Maybe it will be a OEM specific feature?!
Name one reason for DivX /XviD support, except that you want to play your pirated movies...
Transcoding XviD shouldn't take much time with a modern computer.
Why do they have to be pirated? There are those of us who have huge DVD/BD libraries ripped to xvid (and later on MKV). Personally I have several hundred DVDs that I have painstakingly converted to xvid for digital storage and easy access from my HTPCs.
Sir. Haxalot said:
Name one reason for DivX /XviD support, except that you want to play your pirated movies...
Transcoding XviD shouldn't take much time with a modern computer.
Click to expand...
Click to collapse
You could make the same assumption about mp3s. I started ripping in 99.. I don't have the resources to rerip my music into something better now. And in a real case scenario I don't want to be told 2 years from now that an MP3 player doesn't play mp3s anymore because they are "all" considered to be pirated .....
I have pleny of DVD's/BD that on top of normal movie have a digital copy that can be used with portable players. They come in many formats on those discs and all require to enter a code before 1st play so it can check if it is valid copy.
I do that and then can play them on my PC even via Zune. Formats I have are WMV, AVI, MP4 and DIVX.
My death race in wmv that works on windows 7 fresh install (with no extra codes and net access) is converted by zune. Annoying as zune officially supports WMV and even plays that movie.
Two mp4 movies (Mummy and Mummy 2) from the same Box set one just copies and works one is converted from mp4 to mp4. Some Divx movies are "converted" but it lasts 1 to 2 min aka it only changes extension while some are properly reconverted but resolution or quality are the same afterwards (720p or standard resolution no matter). There is a problem there.
I just thought about the thing that there's no good video player for android, that decently plays .mkv files in 720p, even on the Desire HD.
But what about Archos? They have also Android as OS, and use a 1 GHz Processor ( ARM8 I think) in their newer devices.
But even the Archos 5 IT could playback 720p with its 800 MHz CPU. May it be possible to implement the ARCHOS media player on other Android devices?
Or is it coded too specifically, using the graphics accelerator so only the Archos can work with that app?
Would love to here ur oppinion about this
Sorry if this question is too dumb,
Hi Dr lele
I recently started work on my DHD and found a program called arkMedia. You can download it from your app store for free. It works very well for me right accross my varied media including avi, flv, mp4 etc...
I believe this is the tcpmp equivalent for android.
I hope it works for you as well as it is working for me.
Kind regards,
J
maybe arcmedia?
Thank You I'll try it
But I'll also try to get the app from the archos to the DHD maybe the video player works. That would be pure awesomeness
Dr. lele said:
I just thought about the thing that there's no good video player for android, that decently plays .mkv files in 720p, even on the Desire HD.
But what about Archos? They have also Android as OS, and use a 1 GHz Processor ( ARM8 I think) in their newer devices.
But even the Archos 5 IT could playback 720p with its 800 MHz CPU. May it be possible to implement the ARCHOS media player on other Android devices?
Or is it coded too specifically, using the graphics accelerator so only the Archos can work with that app?
Would love to here ur oppinion about this
Sorry if this question is too dumb,
Click to expand...
Click to collapse
No software player will help you overcome what hardware can't do , 800 MHz to 1000 MHz is not the issue here. Alot of things make a CPU package for phones, CPU is just a general purpose hardware not fast enough for 3D games or 720p+ video decoding.. . There are several software players out there with their own codecs that will use your cpu in software mode , you will be able to play avi,divx,xvid if your phone can't already do so, but to playback 720p you need alot more horsepower or specialized hardware. Your Desire HD has Snapdragon CPU
Archos 5 does have slower general purpose CPU less MegaHertz but ! that CPU happens to be Cortex-A8 it is more geared for media has "NEON™technology for multi-media and SIMD processing".
Same CPU but slightly faster is in my AT&T Captivate and or any other Samsung Galaxy S phone.
I can playback 720p video no problem high bitrate H264,x264 ect. Amongs many video containers it can also playback MKVs and with some help from players like "mVideoPlayer" it can even render internal and external subtitles.
You can only blame marketing and low education of general population , where everyone thinks all CPUs are equal and only MegaHertz that matters
Hope that was educational for you , in case it was not short answer , Player from Archos 5 will not help you play 720p video. It is not the player that does the hard work.
Ah thx... thats sad news, but i feel a little bit smarter now and somehow I expected that there's a reason for the DHD's original Media Player not to playback mkv containers
So with a Samsung Galaxy phones i could playback more media files... thats really interesting because I looked for an Android Phone which combines the powers of the Archos PMPs and an Android Phone
So, some of the videos I want to put on my phone are over 4 gigs. I want to put them on my phone, and it's Fat32, so 4 gigs won't cut it. I figure if I downsample it a bit, it'll fit, not to mention my phone's resolution isn't huge.
So... is it possible?
There is a program out there can't remember the name that will take your video and resize it for your phone. Will let you know when I remember the name.
Sure you can
I use this app (SUPER) for the task, but maybe it requires some knowledge
google for: erightsoft super
and click the first post
give ir a try, you can find info about its options by googling, or ask if you like.
I use free video converter, just google it and you'll get a link. But it's free and converts any video file.
i just remember there is another tool for this, really easy to use, almost 1 click
search for: PocketDivXEncoder
its kind of old, but it does the job
You could try Badaboom if you have an nVidia GPU that supports CUDA, or for the ATi side, Avivo Video Converter, both of them allow quick transcoding speed using the GPU, which is pretty useful if your CPU is dated, in which most video transcoding software use.
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