• 1
  • 21
  • 22
  • 23(current)
  • 24
  • 25
  • 52
libstagefright - Experimental hardware video decoding builds
(2013-02-20, 18:11)psycon Wrote: ...SD streams do not play properly at all, all i get is audio, subs, and garbled
Strange. Looks like the "MOD16 effect", which should be blacklisted. Could you provide a log, please.
(2013-02-20, 18:37)Koying Wrote:
(2013-02-20, 18:11)psycon Wrote: ...SD streams do not play properly at all, all i get is audio, subs, and garbled
Strange. Looks like the "MOD16 effect", which should be blacklisted. Could you provide a log, please.

i cannot seem to find the log. i enabled debugging, installed the log uploader. set my email addy, but receive no log... the directory where it says its storing the log on the osd seems to be non existant..
Ehmm Koying couldn't you make this optional as well

Blacklisting:

Non MOD16 height vids on Rockchip (see above)

this means practically no default 1080p stream is gonna playback, only anamorphic ?
how to test now if every stream fallsback to ffmpeg which is idiotic overall as we don't want to test it ?
and will this be the same with the software renderer ?
also never a SD file is crashed yet if it was mod16 it just gets garbaged but it doesn't crash the kernel
and the 1080p crashes have nothing todo with this if i disable 1 core and it plays without issues how can this be a mod16 issue ?

This is a test release why fixing such things @ all just leave them in until they are fixed, people that complain should understand the nature of a test release Wink
(2013-02-21, 03:11)CruNcher Wrote: Ehmm Koying couldn't you make this optional as well

Blacklisting:
Have you read up to the "Advanced Settings" bullet point?
Sorry got it

for everyone that's a little lost where to enable the advancedsettings see http://wiki.xbmc.org/index.php?title=Adv...ttings.xml
(2013-02-20, 18:37)Koying Wrote:
(2013-02-20, 18:11)psycon Wrote: ...SD streams do not play properly at all, all i get is audio, subs, and garbled
Strange. Looks like the "MOD16 effect", which should be blacklisted. Could you provide a log, please.

FWIW this SD youtube video does not play correctly (garbled screen) on a MK808 using Finles 1.6 ROM

http://www.youtube.com/watch?v=Qh8BWp6XkvM

so far any 720p video (in youtube plugin) plays perfectly fine Smile Thanks for the hard work!

EDIT: I will try to provide a LOG ASAP

EDIT 2: here is the log file: http://www.xbmclogs.com/show.php?id=1060

I closed XBMC after enabling debug, opened and when directly to add-ons, youtube, and selected the SD video (displaying garbled video, audio is fine), after a few seconds of playing I closed the video and exited XBMC, I hope I did it right Smile

on line 635 it says: stream #0:0: Video: h264 (Main), yuv420p, 854x480, 461 kb/s, 30 tbr, 1k tbn, 60 tbc

edit 3: oops found a 720p video that also display garbled video, http://www.youtube.com/watch?v=ZrDQ5VwGb58 I am thinking the MOD16 blacklist is not working properly Sad

edit 4: on further search, any video that was recorder using G+ Hangout will NOT display correctly Smile
(2013-02-21, 08:35)shanti Wrote: FWIW this SD youtube video does not play correctly (garbled screen) on a MK808 using Finles 1.6 ROM

http://www.youtube.com/watch?v=Qh8BWp6XkvM
Good catch! Looks like the "stride effect" happens when the WIDTH is not MOD16. So I'll have to blacklist those, too.
It's a silly bug, really. I bet it wouldn't take more than 15min to a Rockchip engineer to solve this...
Koying

you have to understand this issue Wink

http://forum.doom9.org/showthread.php?t=143215

This padding works fine in the default Android Framework (Software Rendering, Hardware Overlay) it just fails with 3rd party GPU Render implementations so far (XBMC and MX Player)
And also both are unstable with the Multithreaded Slice Decoding part of Rockchips Decoder in the GPU Render mode

Did you tried to padd the result via the Parser and give that to the Rockchip Decoder so if the input is 1080p fake the bitstream info and send 1088 to the decoder as the actual width of the resolution what happens ?
(2013-02-21, 12:52)CruNcher Wrote: you have to understand this issue Wink
This padding works fine in the default Android Framework it just fails with 3rd party GPU Render implementations so far
No. It fails because Rockchip OMX components are using the published width/height of a stream rather than the MOD16 one used by THEIR decoder to allocate THEIR HW buffers we don't have access to.
On all other platforms, the MOD16 width/height is properly used, so it is just a plain stupid coding error/typo.
Yes thus i guess if you give the decoder what he want's (a mod16 resolution input) there will be no problem with this Smile
though it's anyways strange that 1080p works fine if you disable 1 core and it doesn't show any more strange lines so it fixes suddenly both the mod16 res and the sliced decoding, though only for 1080p.

So please contact chen im sure hes interested in this, im pretty sure he didn't expected it to be used from outside the Android Framework they created Smile

* author: chenhengming [email protected]

though i hope if this requires a firmware change they would push it to every of their device vendors and advice them to update
(2013-02-21, 13:16)CruNcher Wrote: Yes thus i guess if you give the decoder what he want's (a mod16 resolution input) there will be no problem with this Smile
You don't get it, do you? I CAN'T! If you find a way, please submit a patch.

(2013-02-21, 13:16)CruNcher Wrote: So please contact chen im sure hes interested in this, im pretty sure he didn't expected it to be used from outside the Android Framework they created Smile
An what again, cherry on top? Wink
I spent 100x more time debugging this that it'd take them to fix it. If they want to talk to me, I'm avail. I'm definitely not going to chase them...
(2013-02-21, 13:44)movie_enjoyer Wrote: I am confused after looking at several threads and pages. So I ask, Is hardware acceleration playback possible in XBMC Linux on a MK802 A10 device or not?
We are here to serve.
Which word didn't you understand: * WARNING: Not for AmLogic nor Allwinner SoC's, which do not support libstagefright *
Koying ignore it. Its like a war against zombies - you shot one down and 3 new appear.


Guys remember - this is a development thread. Read the first post and post the stuff which is important or just STFU! If i continue seeing such stupid questions here i will dedicate a hour of my time and just go with a big fat railgun through this thread and will clean out every post which i think is stupid enough! And then i pick the one with the most stupid post and send him the receipe for this one hour.
AppleTV4/iPhone/iPod/iPad: HowTo find debug logs and everything else which the devs like so much: click here
HowTo setup NFS for Kodi: NFS (wiki)
HowTo configure avahi (zeroconf): Avahi_Zeroconf (wiki)
READ THE IOS FAQ!: iOS FAQ (wiki)
Does libstagefright support 1080p60 ? Just did some testing yesterday on my Nexus 7 (Tegra 3). Tried a few different clips all seems to be fine. After that tried one clip 1080p60 at 28 MB/s. This is an MTS clip from a Sony camera supporting AVCHD 2.0 specs, unprocessed so exactly as come from camera. Most current Sony and Pnasonic cameras support this mode now.
Tried first with MX player and BS player, both work well with HW acceleration (HW+ only on MX). In SW mode no way, as expected image hardly moving.
Tried XBMC latest build from first message. It tries to work, in other words it's better than SW so I suppose that HW acc kiks in but the image is very jerky. As the other 2 players work, I'm sure the SoC can do 60p at 28Mb/s. Any comment on it ? Anybody tried this mode on other SoCs ?
hi koying,

thank you for your nice work!

I looked your patches https://github.com/xbmc/xbmc/pull/1832 (lightly, I'm not expert in this area), and I'm interested in following things,

1. this uses libstagefright directly

I think normal media player apps for Android just use media framework. it will use HW decoder on the device which has HW decoder, and it will play HD movies nicely.

Rockchip may extend interface in libstagefright, and Rockchip may extend media framework to use extended libstagefright. then, apps which use media framework can play movies well, but apps which use generic libstagefright interface can't play movies well. (it's just my guess, I don't know it's correct... I hope it's wrong)

<EDIT>
I don't say using libstagefright is wrong. it's nice.
well, it's off-topic but, about Linux on RK3066, there is no way to use hardware decoder on it. but it may be possible to use libstagefright(I have no idea). OpenGL ES is already working on Linux on RK3066. oh, then, there may be a chance to use hardware decoder with this... sorry, it's off-topic Wink
</EDIT>

2. this uses OpenGL ES texture to render decoded frames

(I'm sure that GPU does nothing for video decoding/encoding)

I guess normal apps which use media framework and/or surface framework may use hardware overlay(or something like 2D accelerator) to render decoded frames.

and there are interesting thread about RK3066's 3D,
http://www.armtvtech.com/armtvtechforum/...f=4&t=1606
http://www.armtvtech.com/armtvtechforum/...t=10#p9066
they say 3D animation is not smooth.

I'm sure there are some versions of Mali kernel modules and userland libraries for RK3066. it may affect rendering performance and behavior such as smoothness.
(I'm sorry if Mali version is already logged in debug log)

I'm not sure about frameworks in Android, is it difficult to use 2D overlay via common framework?
  • 1
  • 21
  • 22
  • 23(current)
  • 24
  • 25
  • 52

Logout Mark Read Team Forum Stats Members Help
libstagefright - Experimental hardware video decoding builds10