I'm a bit confused on this topic...would it be possible to list out which of the chipsets will most likely/possibly handle XBMC hardware decoding? For example, I presume the latest AMLogic chipset (ARM Cortex A9) will cooperate with XBMC to handle hardware decoding, correct? How about the Cortex A8? Does it depend on who uses the chipset in their builds, or generically stating?
For example, can I assume the Boxchip A10 1.5GHZ will be able to handle XBMC hardware decoding?
Thanks.
-Scott
Well it was the easiest and most obvious approach. Ffmpeg has stagefright support for h.264. If this would work we wouldn't even need to change anything in xbmc. We would just need to activate it in ffmpeg and would be set for h.264 at least. That was the idea.
Of course you can implement your own libstagefright codec for hw decoding but this involves more work (and not sure if this is even the way to go). For sharing the work:
You "just" use the ffmpeg script for this. In our xbmc code tree in lib/ffmpeg/tools there is a script called "build_libstagefright" or so (its provided by ffmpeg). Just adapt the configure flags in there to the ones from our configure.in:
https://github.com/xbmc/xbmc/blob/master...e.in#L2590
Then follow the complete android build readme. After the initial build was done run the build_libstagefright script (modified with our configure flags) and after that run make apk. Well something like that (its out of my mind).
(2012-10-29, 21:55)cableghost Wrote: [ -> ]I'm a bit confused on this topic...would it be possible to list out which of the chipsets will most likely/possibly handle XBMC hardware decoding? For example, I presume the latest AMLogic chipset (ARM Cortex A9) will cooperate with XBMC to handle hardware decoding, correct? How about the Cortex A8? Does it depend on who uses the chipset in their builds, or generically stating?
For example, can I assume the Boxchip A10 1.5GHZ will be able to handle XBMC hardware decoding?
Thanks.
-Scott
No as stated 1 billion times - you can assume nothing in arm world. And maybe you get the idea that xbmc for android is not ready for the masses (in the meaning of masses of different hardware running android). So its time for some patience as these questions start to annoy us. And we wrote it in big fat letters in the sticky thread that we can't answer questions about supported hardware because we don't know the answer. But users can't stop asking them - this really makes me sick...
the A42 might handle hardware decode.
I have another two questions:
(1) Why does Pivos implement a dedicated AMLPlayer instead of providing standard OpenMAX interfaces? If Pivos provides standard OpenMAX interfaces, then xbmc-android can work on OMXPlayer, and OMXPlayer is much more common than dedicated AMLPlayer.
(2) Does anyone try to run xbmc-android over android's MediaPlayerService? If xmbc-android can run on MediaPlayerService, it will be less tied to specific hardware.
Thanks in advance!
1) Eh ? Perhaps you should investigate what AMLogic provides on android before asking this question. Also, for the millionth time, there is no standard OpenMAX interface on Android. There might be some OMX bits but you must code your own OMX IL API.
2) For the millionth time, the existing Android API for player services are too limited, we can't use XBMC's virtual file system. That means no SMB, no NFS, no AFP, no anything that uses our VFS.
Stop thinking there is some trivial way to resolve this, there is none. We are not inexperienced coders, we have looked.
(2012-11-02, 04:59)davilla Wrote: [ -> ]1) Eh ? Perhaps you should investigate what AMLogic provides on android before asking this question. Also, for the millionth time, there is no standard OpenMAX interface on Android. There might be some OMX bits but you must code your own OMX IL API.
2) For the millionth time, the existing Android API for player services are too limited, we can't use XBMC's virtual file system. That means no SMB, no NFS, no AFP, no anything that uses our VFS.
Stop thinking there is some trivial way to resolve this, there is none. We are not inexperienced coders, we have looked.
davilla, thank you for the reply!
(1) Maybe AMLLogic has its good-working player used in many products. So it is natural for AMLLogic to provide only player interfaces instead of OpenMAX interfaces. This is just our situation. Our device is based on hisilicon chip and hisilicon doesn't provide OpenMAX, and it even doesn't provide support for stagefright.
(2) I don't have any knowledge about XBMC's VFS, so sorry for the silly question; but the reply is very important for us to make decisions.
Have someone looked into gstreamer backend on android yet?
The press release says "some features such as hardware acceleration are only available from API Level 16 (Android 4.1, Jelly Bean)" and it will be really interesting if its the hardware accelerated video playback its referring.
http://www.collabora.com/press/2012/11/a...r-sdk.html
(2012-12-03, 14:59)s7mx1 Wrote: [ -> ]Have someone looked into gstreamer backend on android yet?
The press release says "some features such as hardware acceleration are only available from API Level 16 (Android 4.1, Jelly Bean)" and it will be really interesting if its the hardware accelerated video playback its referring.
http://www.collabora.com/press/2012/11/a...r-sdk.html
It is probably referring to video hw acceleration using the JB-introduced MediaCodec classes. (probably using the native parts of that code)
I have pointed out that route before. But it will limit the userbase to JB and later devices. I think that the XBMC team would like to have a broader user-base than JB and newer devices.
Regards // OwL
By refering to AMLPlayer, we implemented HISPlayer for hisilicon platform, and now we can play HD videos using hisilicon's hardware ability.
(2012-12-22, 04:32)sonach Wrote: [ -> ]By refering to AMLPlayer, we implemented HISPlayer for hisilicon platform, and now we can play HD videos using hisilicon's hardware ability.
Nice, you have a public repo for this yet ? It would be nice to get this push into mainline sometime.
This work is at its very begining, just can play HD video files using the hardware's ability. VFS, subtitles, OSD and many others are not implemented. We expect one delicated developer to finish this but he is occupied by other stuff at this moment.
No public repo ATM but we plan to put this onto github as soon as it is a bit stable.
@davilla: Since HISPlayer is very platform specific and is similar to AMLPlayer(for example, by adding "--add-player=hisplayer" when do 'configure'), does it make any sense to push it into mainline? (Of course, if mainline can merge this work, I am very happy to do so)
There's also work being done with amlogic hw video decode under xbmc's internal dvdplayer. XBMC mainline was feature frozen before I could inject but it's visible an running in the Pivos XBMC repo. This was the original concept that I set aside because I could not figure out how to keep a/v sync. I'm much smarter now
so the code has been resurrected again.
This of course depends on how HISPlayer works.
davilla, I am not quite sure what do you mean:
(1) your original concept for amlogic hw-video-decode is to use dvdplayer, but this concept was set aside because you could not figure out how to do a/v sync. So finally you decided to use seperate AMLPlayer?
(2) And now you find some way to do the a/v sync when using dvdplayer, so you are looking into do amlogic hw-video-decode under dvdplayer?
for HISPlayer, it now works similarly to AMLPlayer.
And if hisilicon hw video decode can be done under dvdplayer, it will be really great, and will be meaningful to mainline.
But the difficulty is: the file parse, video and audio decoding, video rendering and video display are all done by the hisilicon SDK. So it will be difficult to use dvdplayer together with paplayer and do a/v sync maybe.
you got it right - davilla implemented an amlcodec for usage with the dvdplayer