akaizen has quit [Remote host closed the connection]
_BJFreeman has joined #linux-sunxi
_BJFreeman is now known as BJfreeman
utzig has joined #linux-sunxi
RaYmAn has quit [Remote host closed the connection]
vinifr has quit [Remote host closed the connection]
ZetaNeta has joined #linux-sunxi
rz2k has quit []
<TheSeven>
ssvb: SD video playback seems to mostly work now in XBMC (seems like it skips a frame now and then, but acceptable)
<TheSeven>
CPU load isn't the problem apparently
<TheSeven>
for HD video playback I have some weird issues with both XBMC and VLC
<TheSeven>
or at least for some HD videos
<TheSeven>
I repeatedly managed to get cedarx into a state where it produced garbage colors (horizontal r/g/b bars) with correct luma until a reboot
<TheSeven>
and with VLC I also have some issues where audio playback is completely garbled or stalls for about 5 seconds every couple of seconds. video playback is choppy during these stalls, but CPU usage is low.
akaizen has joined #linux-sunxi
akaizen has quit [Ping timeout: 240 seconds]
<TheSeven>
this, repeatedly:
<TheSeven>
[0xb67005f8] main input error: ES_OUT_RESET_PCR called
<TheSeven>
[0xb67005f8] main input error: ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 5000 ms ignored)
<TheSeven>
there's also a rather nasty problem where after playing a file to its end in xbmc the cedar overlay will stay over the mali-rendered layer, which effectively results in a black screen. even if I restart XBMC!
<wingrime>
TheSeven: mali?
<TheSeven>
well, or whatever that is... the "UI" layer of XBMC
<wingrime>
actualy it on a20?
jemk_ is now known as jemk
<TheSeven>
a10
ibrah has quit [Ping timeout: 240 seconds]
<wingrime>
TheSeven: more about usecase please
<TheSeven>
of which of these problems?
<wingrime>
black screen
<TheSeven>
I start XBMC, watch a video. when I pause it or otherwise enter the menu, everything is fine. If I let the video run until the end however, I get stuck on a black screen. I can hear XBMC produce menu sounds, but the screen stays black. Even after restarting XBMC.
<wingrime>
TheSeven: oh well I can explain what it happens
<TheSeven>
that's with native linux libvecore, but I think it has also happened with the libhybris one
<wingrime>
TheSeven: our Disp driver actualy piece of crap from AW
<TheSeven>
looks like it doesn't properly remove the overlay somehow
<wingrime>
TheSeven: yes
<wingrime>
TheSeven: I have noticed that with black-light
<TheSeven>
I'm just wondering why it only seems to happen if I let a video run until the end
<wingrime>
TheSeven: all you problems related hardware overlay handling
<wingrime>
TheSeven: lines on top - looks like incorrect overlay mode
<TheSeven>
yes
<wingrime>
TheSeven: for example disp can handle UVY video
<wingrime>
*image
<TheSeven>
however the "pausing audio and stuttering video" VLC issue doesn't seem to be overlay-related to me
<TheSeven>
that seems more like a demuxer or audio codec thing
<wingrime>
can explain more
<wingrime>
?
<wingrime>
TheSeven: also, problem with XBMC can be produced due incorrect /dev/disp close / ioctl sequence
<TheSeven>
for some HD video files I'm getting garbled audio in XBMC (and IIRC also in VLC), along with very bad video frame rate (<5fps), then after a while the audio comes alive somehow and video gets smooth as well. then after a few seconds audio goes silent and video stutters again for 5 seconds, then it works normally again. and so on. VLC messages: see above
<wingrime>
TheSeven: good news *it fixable* - thats not related blobs
<TheSeven>
well, if I had some background in this area I would be tempted to just throw those blobs out and reimplement the whole mess based on reverse engineered HW knowledge...
<wingrime>
TheSeven: thats audio bug - some sync related
<wingrime>
TheSeven: I working on it)
<TheSeven>
let me know if I can be of any help :)
<wingrime>
TheSeven: but It it still not usable state
<jemk>
wingrime: some of the ve registers in h264 engine seem to have different function in h264 and vp8, so the name you gave them doesn't fit for both
<jemk>
wingrime: how should we handle this?
<wingrime>
jemk: no idea
<wingrime>
jemk: use different #define is bad
<wingrime>
jemk: single name mostly prefered
<wingrime>
jemk: any idea?
<jemk>
wingrime: e.g. reg 0x21c is PART_OFFSET for vp8, but for h264 it contains values from slice header
<jemk>
so totaly different use
<wingrime>
I glad paullo join us
<jemk>
did you talk to him?
<wingrime>
jemk: still no
<wingrime>
jemk: MACC_H264_POFFSET_VP8_<some>
<wingrime>
jemk: there some name for VP8 and H264 codec family?
<jemk>
wingrime: don't know, that gets ugly
<wingrime>
jemk: indeed
<oliv3r>
mripard: may have a naming or other suggestion for you guys
<wingrime>
jemk: are you figured what extatly value for H264 means
<wingrime>
jemk: if it only slice header
<wingrime>
MACC_H264_VP8_SHDR
<wingrime>
jemk: I try add
techn__ has quit [Ping timeout: 264 seconds]
<wingrime>
jemk: take a look now
<jemk>
wingrime: i don't know if vp8 name is correct, but for h264 it contains values all named *_qp_* something
<wingrime>
jemk: but slice and part are not synonims?
<wingrime>
"slice" can be == "part"
<jemk>
wingrime: no, not that i know, maybe you find the answer in paullos code
<wingrime>
jemk: better se him there
<wingrime>
*see
<wingrime>
jemk: his code not ever runed
<jemk>
wingrime: well, its decompiled and cleaned up i think
<wingrime>
jemk: any way I Add new name in *single row*
<wingrime>
jemk: how idea?
<jemk>
wingrime: i don't really know wiki syntax, but why not two rows?
<jemk>
wingrime: do we have a way to read ve-ram from cpu, to check my idea of function of regs 0x2e0 and 0x2e4
<ssvb>
TheSeven: what kind of kernel are you using on your a10? the leaked disp overlay problem should have been fixed quite a long time ago
<wingrime>
jemk: what you mean ve-ram?
<wingrime>
jemk: we have dram and sram
<jemk>
wingrime: the sram mapped to ve
<wingrime>
jemk: ok, we can remap it back
<jemk>
wingrime: but how, we would need help of kernel, or not?