| 03:15 | Coburn | Can someone tell me how well Android supports the CuBox-i ? |
| 03:15 | Coburn | I'm looking at a i4-Pro, the one with all the bells and whistles |
| 15:17 | kgp | rabeeh :) any git scripts from you? :) |
| 15:19 | rabeeh | kgp: nop |
| 15:19 | rabeeh | i'm actually stuck |
| 15:19 | rabeeh | with the damn xorg driver |
| 15:19 | rabeeh | i was hoping i can test the vivante v5 xorg drivers; but i still didn't get them (and all hints shows that those are alpha materials) |
| 15:20 | rabeeh | everything else (including LK 3.14.14) looks great |
| 15:29 | cbxbiker61 | hey rabeeh |
| 15:30 | cbxbiker61 | i've been experimenting with h265 with good results |
| 15:31 | cbxbiker61 | and i just realized that with a bit of time and development, h265 may work on the cubox-i4's |
| 15:31 | rabeeh | you mean as a soft decoder |
| 15:31 | cbxbiker61 | the main thing holding that back will be developing an open source based opencl decoder |
| 15:32 | cbxbiker61 | which i think will inevitably happen |
| 15:32 | cbxbiker61 | there's already a proprietary opencl based decoder working on a different arm platform |
| 15:33 | rabeeh | have a link? |
| 15:33 | cbxbiker61 | http://www.cnx-software.com/2014/01/23/arm-mali-gpu-demos-at-ces-2014-4k-3d-ui-and-games-astc-texture-compression-xbmc-gesture-recognition-and-hevc-video-decoding/ |
| 15:35 | rabeeh | oh; Ittiam work |
| 15:36 | cbxbiker61 | do you know them? |
| 15:38 | rabeeh | yeah |
| 15:39 | rabeeh | cbxbiker61: opencl might be first step to get h.265 into an already running platforms (exynos, imx6 etc...) |
| 15:40 | rabeeh | but down the road video engines will support that natively; this will be mainly driven by mobile machines that they require saving battery life |
| 15:40 | cbxbiker61 | i'm building xbmc 14 for the cubox-i now, it does have software support for h265, just for kicks i'll see what the quad can do with small h265 videos |
| 15:40 | rabeeh | cbxbiker61: but what have you expiermented for now? |
| 15:40 | jnettlet | that reminds me. We need to profile OpenCL under the v5 drivers to see if any progress has been made by Vivante |
| 15:41 | rabeeh | yeah |
| 15:41 | jnettlet | cbxbiker61, I was just testing some hi10 playback and that chokes even on the quad. |
| 15:42 | cbxbiker61 | i've encoded h265 with ffmpeg on my 8 core, it does 720p at about 22 fps |
| 15:42 | jnettlet | mostly because xbmc does split the various decoding audio/video/output into their own threads |
| 15:42 | cbxbiker61 | hi10-h264 may not be threaded enough though |
| 15:42 | jnettlet | ideally you would have 1 core handle the container, one for audio, one for video and one for output |
| 15:43 | rabeeh | cbxbiker61: encoding performance relies a lot on the output vitrate and perceived quality |
| 15:43 | cbxbiker61 | h265 will split the decode across cores |
| 15:43 | jnettlet | well that will help then |
| 15:43 | jnettlet | maybe it has more hope than hi10 |
| 15:44 | cbxbiker61 | rabeeh, yep, i'm encoding at the same quality setting i was using for h264 |
| 15:44 | rabeeh | for instance; a good performance measurement would be taking a well encoded h.264, trasncode to h.265 and only when the output bitrate is half with same perceived quality then you can really measure performance |
| 15:45 | rabeeh | 720p with 22fps sounds too good to be true |
| 15:45 | rabeeh | i'm assuming 10 Mbps |
| 15:45 | cbxbiker61 | they've made dramatic improvements lately |
| 15:45 | rabeeh | x.265? |
| 15:45 | cbxbiker61 | yep |
| 15:45 | rabeeh | does that use the gpu too? |
| 15:45 | cbxbiker61 | i use crf set to 24 |
| 15:46 | cbxbiker61 | no, only cpu at this point |
| 15:46 | cbxbiker61 | filesize is 450M vs 800M for h264 |
| 15:46 | rabeeh | oh |
| 15:46 | rabeeh | perceived quality? |
| 15:46 | cbxbiker61 | and quality looks good to me |
| 15:46 | rabeeh | impressive !!! |
| 15:47 | cbxbiker61 | i tested it 6-12 months ago, and it sucked |
| 15:47 | rabeeh | any idea how much power does that machine eat when encoding? |
| 15:47 | cbxbiker61 | about 220 watts just for the cpu |
| 15:47 | rabeeh | ok |
| 15:47 | rabeeh | this is your AMD horse |
| 15:47 | rabeeh | right? |
| 15:47 | cbxbiker61 | yep |
| 15:48 | cbxbiker61 | opencl will really change things, but they're just not there yet |
| 15:51 | cbxbiker61 | the x265 guys already have a "closed" opencl branch, which they plan to open up when it's ready |
| 15:52 | cbxbiker61 | they have a talk at one of the AMD events and they see huge opportunity for HSA work, since this type of code likes to do some things parallel and other thing serial |
| 15:52 | cbxbiker61 | and they won't have to move the data back and forth across pcie |
| 15:55 | jnettlet | cbxbiker61, what are the specs of your AMD? |
| 15:55 | cbxbiker61 | normal clock is 4.7G, turbo is 5G |
| 15:56 | jnettlet | 8 cores? |
| 15:56 | cbxbiker61 | yeah, it's the high-end FX |
| 15:58 | cbxbiker61 | it's in a sabertooth r2 mb with water, rock solid |
| 16:06 | jnettlet | okay you have me by about 15% on passmark :-) But I my TDP is way lower. |
| 16:06 | jnettlet | but I should be able to test encode something |
| 16:09 | jnettlet | oh actually only 7% difference. I forgot that they bumped my processor to the new rev. |
| 18:21 | jmontleon | is there any way to get galcore on a current stable/mainline kernel at present? |
| 18:21 | jmontleo | 18:21 * jmontleon thinks not, but hopes maybe he'll be surprised |
| 18:25 | jnettlet | jmontleon, I will be releasing a galcore that runs against mainline very soon. Just stabilized it on 3.14.14 |
| 18:27 | jmontleon | nice! |
| 18:38 | Z0l | hello |
| 18:39 | Z0l | i've had some progress with my hdmi problem, but i'm still far away from solving it |
| 18:40 | Z0l | looks like the delay is caused by the hdmi_edid_wait_i2c_done function during hdmi initialization |
| 18:41 | Z0l | this is part of the hdmi_edid_i2c_read function, that gets called during bootup to initialize the hdmi controller |
| 18:41 | Z0l | if both the tv and the cubox are powered off, the device boots up without any problems, everything is working fine |
| 18:42 | Z0l | once both the cubox and the tv are warmed up, this function is unable to read the edid and waits 1 second for every single byte to be read, causing the delay |
| 18:42 | Z0l | so if I reboot, it takes about 3 minutes to boot up |
| 18:43 | Z0l | and hdmi output is not working |
| 18:43 | Z0l | *hdmi audio output I mean |
| 18:44 | Z0l | i can reproduce this with any xbmc distro using the 3.10 kernel |
| 18:45 | Z0l | is it possible to read the edid and start the functions in the kernel after it's booted up? |
| 18:46 | Z0l | or to force an existing edid to make sure hdmi audio is always enabled? |
| 18:47 | Z0l | or any clues how this could be debugged? |
| 18:49 | Z0l | i could save the working edid when the system booted up correctly, and i can see it in the sysfs that the edid is filled with zeroes when it didn't |
| 19:37 | dv_ | 19:37 * dv__ recalls tools for reading the edid |
| 19:38 | dv__ | ah no, that was for parsing |
| 19:38 | dv__ | there is parse-edid that can parse the edid dump for you, |
| 19:38 | dv__ | but I think edid itself you have to access over i2c |
| 20:32 | d00fus | hey all...wondering if there is a guide or tips for getting a Windows OS on a cubox 4i ?? |
| 20:40 | malte_ | wont work |
| 20:44 | d00fus | ahhh shiiiiite. short answer, why? |
| 20:45 | malte_ | the cubox i an ARM device, most windows run on x86 devices |
| 20:46 | d00fus | roger that, thank you =) |
| 20:48 | malte_ | perhaps one day windows 8 will run on it - but the question is - who wants this? :) |
| 21:00 | d00fus | lol yup i agree. my boss wants windows on it, we bought a couple w/out really looking at hardware details...just figured it would be fun. oops : P |
| 21:01 | malte_ | u can use it as an thinclient |
| 22:25 | jmontleon | jnettlet, is that in the linux-linar-stabe-mx6 repo on github on the v3.14-mx6 branch? |
| 22:25 | jmontleon | if so I might have to go and give that a whirl |
| 22:52 | deniska | http://nullr0ute.com/2014/08/fedora-21-and-arm-device-support/ yay? |