03:14 | _unreal_ | yay got arch/lxde working |
15:05 | topi` | size or side? :) |
15:06 | topi` | about media playback.. does mplayer / mpv work correctly with i.mx6 video acceleration? |
15:06 | topi` | or should I just absolutely use gstreamer? |
15:06 | topi` | my colleagues have some unhealthy attraction towards mpv... |
15:10 | jnettlet | topi`, no mplayer/mpv does not have any support for the iMX6 VPU. developers talked about adding it but nothing materialized |
15:11 | jnettlet | really gstreamer is the way to go. dv_ has done a fantastic job writing the gstreamer-1.0 plugins for it. |
15:12 | dv_ | :> |
15:12 | topi` | fair enough. I can create a wrapper script that can be called as "mpv" which in reality just invokes gst-launch ;) |
15:19 | topi` | damn. No plugin for video/x-h264 |
15:19 | jnettlet | you don't need one. That is hardware accelerated |
15:19 | jnettlet | so the imx plugins should handle it |
15:20 | topi` | hm, why does gst-launch complain about that... |
15:20 | topi` | on the other hand, most .mp4 files play just fine |
15:20 | topi` | i'll investigate the files |
15:25 | topi` | I think I was missing videoparsersbad |
15:25 | topi` | now that I installed *plugins-bad, h264 works |
15:58 | topi` | glxgears seems to be very slow (4fps), am I missing a package? |
15:58 | topi` | glxinfo reports Direct rendering:YES |
15:59 | topi` | hmm, "AIGLX: Screen 0 is not DRI2 capable" |
16:01 | topi` | hmm, I installed xserver-xorg-video-imx-viv but I believe this is using the framebuffer driver |
16:03 | topi` | ignore this - it seems xserver-xorg-imx-viv was not installed (something must have dropped it) |
16:05 | topi` | now, MUCH better |
16:24 | jnettlet | great |
16:44 | topi` | now my only remaining problem is that it seems webkit is decoding 1280x720 jpegs slowly.. or maybe this is because of missing caching |
16:47 | topi` | it was Xorg, not webkit that was eating 80% cpu |
16:47 | topi` | odd, odd. |
16:50 | jnettlet | topi`, does webkit hook into gstreamer? I know with chromium we have a patchset to accelerate this, also done by dv_ :) |
16:51 | jnettlet | jpegs can be but shouldn't be accelerated. They should actually be rendered by libjpeg-turbo that uses neon to accelerate the decoding. |
16:51 | jnettlet | 1280x720 jpegs should render in NEON in milliseconds |
16:52 | topi` | I haven't been able(yet) to successfully compile CEF (chromium embedding framework) |
16:53 | topi` | we produce kiosk-like systems |
16:53 | jnettlet | topi`, okay well it should. I am in a conference now and can point you at the patches. |
16:53 | topi` | jnettlet: I agree, NEON can decode jpegs pretty quickly. I identified the CPU was consumed by Xorg, so not related to jpeg decoding. |
16:53 | jnettlet | I am working with a couple of people using Tizen and Crosswalk to do kiosk systems |
16:54 | topi` | jnettlet: if you know of any blog post that has a walkthrough to compiling CEF on debian... |
16:55 | jnettlet | I can have Artox, package it if you would find it useful. We already build something similar for node.js |
16:56 | topi` | a year ago, I tried to compile CEF but failed miserably. Hence I settled for webkit with python bindings |
16:56 | topi` | that is pretty easy to bend to any kind of needs |
16:56 | topi` | except the video playback is not HW accelerated |