2013-02-20, 18:37
2013-02-20, 21:36
(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 garbledStrange. 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..
2013-02-21, 03:11
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
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
2013-02-21, 03:26
2013-02-21, 03:33
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
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-21, 08:35
(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 garbledStrange. 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 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
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
edit 4: on further search, any video that was recorder using G+ Hangout will NOT display correctly
2013-02-21, 12:09
(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 ROMGood catch! Looks like the "stride effect" happens when the WIDTH is not MOD16. So I'll have to blacklist those, too.
http://www.youtube.com/watch?v=Qh8BWp6XkvM
It's a silly bug, really. I bet it wouldn't take more than 15min to a Rockchip engineer to solve this...
2013-02-21, 12:52
Koying
you have to understand this issue
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 ?
you have to understand this issue
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, 13:00
(2013-02-21, 12:52)CruNcher Wrote: you have to understand this issueNo. 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.
This padding works fine in the default Android Framework it just fails with 3rd party GPU Render implementations so far
On all other platforms, the MOD16 width/height is properly used, so it is just a plain stupid coding error/typo.
2013-02-21, 13:16
Yes thus i guess if you give the decoder what he want's (a mod16 resolution input) there will be no problem with this
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
* 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
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
* 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:35
(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 thisYou 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 createdAn what again, cherry on top?
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:49
(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 *
2013-02-21, 14:35
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.
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.
2013-02-21, 16:08
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 ?
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 ?
2013-02-21, 18:56
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
</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?
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
</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?