[menno]

awaldram1 since yesterday DD 5.1 passthrough is availble on the minix x5 product (RK3066 based). You should also look at the guys at slatedroid which are making linux work on rk3066. This should open another door to 1080p performance. Mali hw acceleration already works!

[Solo0815]

^^ For me 5.1 on every AC3-Movie didn't work with yesterdays FW. XBMC says "No passthrough device found" even if SPDIF-Passthrough is enabled in Android-settings.
Tested with Gotham-Alpha2-libstagefright

[menno]

what i understood so far is that (other than planned) only DD 5.1 over HDMI works. :Let's see it as a start

[droshi]

This log may show my problem with skipping:
http://xbmclogs.com/show.php?id=12451

but realized I forgot to turn on debugging, so here's one with it on:
http://xbmclogs.com/show.php?id=12452

problem is basically trying to skip, but freezes mostly and doesn't skip (using directional arrow keys on D-Pad), fast-forwarding generally freezes the movie too and doesn't seem to act as normal. Resuming videos doesn't work. This is on an ODROID-U2 CM 10.1 playing over SMB...still haven't had the chance to do more testing with a local HDD.

---

passthough over HDMI sounds nice...any chance of this on the ODROID-U2? I know in the logs it seems to mention:
18:53:07 T:1557575880 INFO: Using digital output
18:53:07 T:1557575880 INFO: AC3 pass through is enabled
18:53:07 T:1557575880 INFO: DTS pass through is enabled
18:53:07 T:1557575880 INFO: AAC pass through is disabled

but of course, in the menus no passthrough device is found

just curious as I have no clue what that would take to achieve

[luksol]

^^ For me 5.1 on every AC3-Movie didn't work with yesterdays FW. XBMC says "No passthrough device found" even if SPDIF-Passthrough is enabled in Android-settings.
Tested with Gotham-Alpha2-libstagefright

As far as I know, Minix X5 does not have hdmi passthrough enabled, but 5.1 over spdif. Try to select different audio output than hdmi and then see if you can select a passthrough.

[vel2000]

just for clearance...a noob question
why can't XBMC use the "native builtin" HW acceleration, like MXplayer?
MX plays all the videos from "http://www.auby.no/files/video_tests/" just fine.
Or is there some kind of "Black Magic" involved

[PalmiNio]

just for clearance...a noob question
why can't XBMC use the "native builtin" HW acceleration, like MXplayer?
MX plays all the videos from "http://www.auby.no/files/video_tests/" just fine.
Or is there some kind of "Black Magic" involved

XBMC is open source = "Black Magic" from non open source code can not be added.

[vel2000]

^^^^
really, that's the only reason?
What kind/piece of "non open-source code" should have to be added, to make it working?
I thought, it is some kind of "api-call", or Android "system-function" because even the stock-gallery plays all files.?
I googled around, but couldn't find any explanation or information, why most Player provide HW-Support, but not XBMC.
But as I am technically interested, I would like to understand the problem.

[michael123]

^^^^
really, that's the only reason?
What kind/piece of "non open-source code" should have to be added, to make it working?
I thought, it is some kind of "api-call", or Android "system-function" because even the stock-gallery plays all files.?
I googled around, but couldn't find any explanation or information, why most Player provide HW-Support, but not XBMC.
But as I am technically interested, I would like to understand the problem.

The 'problem' like you've been told already, is that they need to use open source stuff only, so that's what they're doing, MX Player etc. all used closed source stuff.

[vel2000]

The 'problem' like you've been told already, is that they need to use open source stuff only, so that's what they're doing, MX Player etc. all used closed source stuff.

I understand, what you and @PalmiNio mean. (IF it is so....)
But just repeating @PalmiNio without providing any useful information, is not that, what I was looking for.
REAL information please.
What exactly is this "non open source stuff"?
What kind of "stuff" we are talking about?
Firmwares, frameworks, binary blobs or what?
Any details, links, etc.?
HW acceleration is an integrated system-function in Android since 3.0.
This is documented, so every player/app can use it. (What MX and Co. do, without "black-magic")
I am definetely sure, if this "close source stuff" would be the true and only reason, we would have an "unofficial patch" or "plugin" already....
Like many other "unofficial stuff"..

However, I find this libstagefright project interesting and will participate with tests and logs later, when I really woke up...

[droshi]

The 'problem' like you've been told already, is that they need to use open source stuff only, so that's what they're doing, MX Player etc. all used closed source stuff.

I understand, what you and @PalmiNio mean. (IF it is so....)
But just repeating @PalmiNio without providing any useful information, is not that, what I was looking for.
REAL information please.
What exactly is this "non open source stuff"?
What kind of "stuff" we are talking about?
Firmwares, frameworks, binary blobs or what?
Any details, links, etc.?
HW acceleration is an integrated system-function in Android since 3.0.
This is documented, so every player/app can use it. (What MX and Co. do, without "black-magic")
I am definetely sure, if this "close source stuff" would be the true and only reason, we would have an "unofficial patch" or "plugin" already....
Like many other "unofficial stuff"..

However, I find this libstagefright project interesting and will participate with tests and logs later, when I really woke up...

There's tons of info about XBMC and open source. No need to clog this thread up, but basically if the developer can't see the full code they don't use it. So no binaries are called. I don't know much about MX player so I can't comment further what binaries they use.

[vel2000]

^^^^
one more "useful", "thread clogging" reply.
I asked a serious question.
Why do you reply, if you don't understand my question, or have nothing to say?

However, back to the topic libstagefright:
ONDA V972
Allwinner A31
Android version : 4.1.1
Ram 2 GB
Processor ARMv7 Processor rev 3 (v7l)
Kernel 3.3
Resolution: 2048 x 1440

Videos from http://www.auby.no/files/video_tests/ in top/down order

xbmc-20130403-6200f76-Gotham_alpha2_stagefright-armeabi-v7a.apk

Results:

01. doesn't play - crashes the app - debug log here: http://xbmclogs.com/show.php?id=13005
02. plays with low framerate, between 9-10 fps
03. Only audio - no Video - stopping the video crashes XBMC | debug log 2+3 here: http://xbmclogs.com/show.php?id=13009
04. plays fine, around 30 fps
05. plays fine, 24 fps stable
06. stutters a bit, between 22-25 fps
07. starts playing, but crashes XBMC after a few seconds | debug log 4-7 here: http://xbmclogs.com/show.php?id=13012
08. plays fine - 30 fps
09. plays fine - 30 fps
10. starts playing, but crashes XBMC after a few seconds | debug log 8-10 here: http://xbmclogs.com/show.php?id=13013

[natethomas]

My understanding is that there are two different issues. Each hardware decoder uses a separate sdk to provide decoding hooks, and these sdks are private (aka requirement payment or an agreement to see). So until libstagefright came along, it was literally impossible to hook into most hardware decoders (unless you had an agreement of some kind with the hardware provider). Since any agreement we might make with them would require that we openly show the sdk implementation, they simply aren't interested in playing nice.

libstagefright (and more recently MediaCodec) is, to some extent, Google's way of bullying the hardware decoder manufacturers to provide some method of hooking into the hardware decoding. Some manufacturers are willing to play nice with libstagefright (e.g. NVIDIA) and some are not (e.g. Allwinner). And then there are those like AM Logic, who don't implement the libstagefright protocol, but make it easy to hook directly into the decoders openly.

I should note, I could be completely wrong about any or all of that. The only thing I'm REALLY sure about is that Android is a fragmented clusterf***.

[Gombi]

Hi,

I was playing with the Feb 19th hwaccl version of XBMC for Android on my Minix Neo X5 box for the last couple of days. I'm seeing two major phenomenas:

1. Sync between audio and video is off about 320ms. This is easily correctable in the audio menu of the player and the change is persistent.
2. For all video types, SD, 720P, 1080P, web streaming or even from an external hard drive - The video is not fluent (though much better than without hw acceleration). It's like a stutter but it seems more of a frame rate misalignment than a resource starvation issue.

Needless to say that with hw acceleration enabled players (Mx player, Archos player, etc...) all is playing fluently.

Has anyone noticed this? What can be done to improve it?

I'm running Finless 1.2b ROM, with 720P kernel, latest libstagefright and with the blacklist removed via the proper xml file.

[Juanjo]

@vel2000:
you are probably getting the crashes cos libstagefright is NOT for alwinner chipsets, besides the fact that all this is experimental and such...