<vicenteH>
it looks like I will have to create my own customized image.
<vicenteH>
thanks hramrach
<hramrach>
probably
<vinifm>
hramrach, library is userspace driver?
<hramrach>
vinifm: in general the kernel has some buffer manager and the userspace library takes care of filling and submitting the buffers into the kernel
<hramrach>
did not look at mali driver in detail so canot say what exactly the kernel part does but most is implemented in the library and is closed source
<vinifm>
hm
<hramrach>
lima aims at reimplementing the library
<vinifm>
so libUMP and libMali are drivers
<hramrach>
libump is probably part of the buffer management and is opensource
<hramrach>
libmali is the driver
<hramrach>
it converts the GL commands into hardware instructions, has shader compilers and such
<vinifm>
ah, thanks for the explanation
<hramrach>
and specifically for mali it has some graphics hardware instruction scheduler which aims at making optimal use of the accelerator
<hramrach>
many desktop cards drivers don't bother much because the card is overpowered anyway and many would melt if actually used at 100%
<vinifm>
but why Video performance is better in android
<hramrach>
because the drivers are tested with android
<hramrach>
afaik there is exactly 1 person working on video under linux and there is so much you can get done that way
shineworld has joined #linux-sunxi
<mnemoc>
you are probably comparing neon decoding (in linux) vs cedarx decoding (in android)
<hramrach>
if you mean video as opposed to 3D
<hramrach>
for me CedarX decoding in Linux sucks as well
<hramrach>
slow, buggy, lots of artifacts
<hramrach>
never tried on android so don't really have any comparison
<hramrach>
maybe people working on android just have lower expectations because it's such a lame system overall
<vinifm>
i tested a 720p video
<hramrach>
so did I
<hramrach>
it was slow, had lots of artifacts in cut screnes and the player crashed
<ssvb>
vinifm: how did you test it? which video player?
<vinifm>
mplayer
<hramrach>
that does not do CedarX
<vinifm>
and gnome player
<hramrach>
so expect slow, buggy, few artifacts
<hramrach>
because the mplayer softcodecs tend to be mostly correct at least
<mnemoc>
iirc only rellla's xmbc has cedarx support on linux currently
<hramrach>
vlc too
<hramrach>
did not try xmbc since the author of the xmbc port said it's never going to vork and is giving up
<hramrach>
is there any more news regarding xmbc?
<ssvb>
vinifm: if we get XV extension for scaling and colorspace conversion, you may expect 480p neon decoded video playback in mplayer, and maybe even sometimes 720p (with lightweight codecs such as xvid or theora)
<ssvb>
vinifm: would that be enough for you?
<vinifm>
ah, now i understant because low performance
<vinifm>
i dont know :)
<ssvb>
vinifm: the dedicated hardware decoder (that's cedarx, not mali) needs dedicated video players, general purpose video players can't use hardware acceleration
<hramrach>
generally 1080p should be the minimum any decent media player should be able to play
<rellla>
hramrach: which author? gimli?
<hramrach>
not because the resolution is needed on an 800x600 display but because of media availability
<hramrach>
recoding movies just to view them sucks
<hramrach>
rellla: don't remember. there was some thread on the ML with some link to blog post or something
<hramrach>
so any more news?
<rellla>
it works here, anyway.
<hramrach>
does it not have the artifacts vlc has?
<hramrach>
and where do I get it?
<rellla>
not perfectly with all codecs/profiles but useable imo, and hardware accelerated. the problems are documented in the wiki.
<rellla>
take the Frodo-branch of my repo.
<hramrach>
your repo being?
<rellla>
github.com/rellla/xbmca10
<vinifm>
i needed C library, like libplayer
<hramrach>
thanks
<hramrach>
vinifm: the vlc port has a C library for CedarX support
<rellla>
if anyone has some sparetime, there should be made a cross-reading of the different cedarx-implementations, maybe something is fixed in other ones:
<rellla>
i know of 4 different cedarx-using projects:
<rellla>
and there was a xbmc-port at http://github.com/goland which isn't available anymore. from what i could see, this was based on empatzeros port with own "improvements".
<hramrach>
problem is that there is not info about the cedarX hardware
<hramrach>
I read about some media accelerator that it is basically filterpack allowing decoding of anything so long as the driver uses it properly
<hramrach>
not sure if it was teh one in exynos or cedarx
<hramrach>
but you cannot make the driver use it properly when it's closed source
<rellla>
luckily i cloned goland's repo before. it seems that this was used for http://www.vidon.me/
<hramrach>
the artifacts in cedarx decoding I experienced so far seem to be some sort of lack of bandwidth - they happen at cutscenes and video start
<hramrach>
but it might be caused by the library not cleaning up something, too
<hramrach>
it's guide to using the lib
<hramrach>
not to using the hardware
<hramrach>
sure there may be error in using that interface
<hramrach>
but whan the library blows it you are out of luck
<hramrach>
and I don't believe that thing is error-free
<rellla>
we don't know if the error is in using that interface or if it's the library itself. so maybe cross-reading /-testing will help. problem atm is, that no one is working on optimize the implementation of the binary imo.
<hramrach>
and when you can't look into the library it does not help determining where the error is
<hramrach>
like vlc crashing when the screen is blanked
<hramrach>
it crashes in the cedar lib, no less
<hramrach>
yes no one is working on the binary lib
<mnemoc>
i remember xmbc was doing the same
<rellla>
you are right. but if some codec works with vlc and doesn't with xbmc, the lib must basically be ok for that. so you have to see, how xbmc speaks with it.
<hramrach>
when requested fixed version from allwinner they sent the same version
<hramrach>
that's how much they work on it
<hramrach>
well, the crash while playing happens in vlc code
<rellla>
that's the problem why no one is interested to work with a library, knowing that there will be no support from allwinner anyway
<mnemoc>
cedarx lib on xmbc was also crashing, until empat0 found the right way to use it
<hramrach>
FPE
<hramrach>
so it might be vlc error
<rellla>
mnemoc: this is what i mean. we have to find out, to use it the right way. that's the only possibility we have atm.
<hramrach>
so long as there even is a right way to use it. And that is in all seriousness unlikely.
<hramrach>
unless the right way includes recording videos to a format it can handle flawlessly (remember video recoding for iPods?) or reverse-engeneering what it does and do it correctly. And figure out what is between the lines of the interface spec that way.
<ssvb>
libv: unless I' mistaken, techn_ used a13 with mali
<slapin_nb>
mnemoc: are you sure about lvds?
<slapin_nb>
mnemoc: and how the screens are attached on zillions of A13-based tablets?
shineworld has quit [Remote host closed the connection]
<grevaillot>
slapin_nb: regular rgb interface ?
<grevaillot>
slapin_nb: i guess. The old style DPI (24bit + syncs and clock)
<mnemoc>
yes
<slapin_nb>
grevaillot: never seen non-lvds 7 inch display these days
<grevaillot>
well, i've no idea of what's inside the zillions of devices, but for sure, 7inch dpi panels where still quite frequent two years ago, so should be quite cheap
<mnemoc>
slapin_nb: open any a13 tablet and see the part ;-)
<grevaillot>
slapin_nb: and rgb to lvds bridges are cheap
<mnemoc>
i think olimex coverts rgb to lvds for their panels