| 00:21 | MMlosh | that sounds really nice.. is 480 a limit for vmeta deinterlacing? |
| 00:22 | MMlosh | It seems that our TV broadcasting is done in interlaced 720x576 |
| 00:27 | cbxbiker61 | MMlosh, no it doesn't de-interlace anything at the moment, but the higher the resolution the better interlaced content will look |
| 00:55 | _rmk_ | cbxbiker61: as I've said in the past, the diagonal stuff seems to be a hardware bug which there's no way to detect it happening other than by someone looking at the display and saying "that's not right" |
| 00:55 | _rmk_ | the Marvell driver occasionally gets it, my DRM driver occasionally gets it too - and we do things in different ways. |
| 00:58 | _rmk_ | last time I got it, I tweaked a few registers, and the best I found is that adding one to one of the horizontal timing registers seems to "fix" it when it happens, but that will screw stuff up when it doesn't happen. |
| 00:58 | _rmk_ | but re-setting the mode with xrandr (eg, changing the refresh and back again) sorts it every time for me |
| 00:59 | cbxbiker61 | _rmk_, it'd be nice if Marvell would comment on that |
| 01:00 | _rmk_ | it could be an interaction between the dove and the tda998x chip |
| 01:01 | _rmk_ | but I suspect not because overlay video also becomes diagonal while the graphic isn't |
| 01:05 | cbxbiker61 | i'm rebuilding llvm/mesa with the amd open vdpau support enabled, it'll be interesting to see how well that works |
| 01:06 | cbxbiker61 | we may actually have an "open" hardware-accelerated option |
| 01:18 | _rmk_ | I need to go back to my libav driver to work out why some previously working mpeg files I have has stopped working. |
| 01:18 | _rmk_ | libva driver |
| 01:19 | _rmk_ | the stuff I most care about still works though (which is vlc playback of transport streams with mpeg2 video) - was watching something on the cubox tonight. |
| 01:20 | cbxbiker61 | _rmk_ do you have a repo for the libva? |
| 01:21 | _rmk_ | and I know my mpeg4 stuff still works as well (I don't mean h264, which I can't get to work, I mean mpeg4 video itself) |
| 01:22 | _rmk_ | not published yet - partly because it's quite hit and miss with what it works with |
| 01:22 | _rmk_ | much of that stems from problems with how vmeta wants to work being not how libva wants to work, and having to reconstruct bits of the elementary stream |
| 01:23 | _rmk_ | for example, vmeta seems to be pipelined, and keeps reference frames in a different format to displayed frames |
| 01:24 | _rmk_ | libva assumes it can pass a reference to the reference display frames, and it also wants to pass the data for a frame and get that exact frame back immediately |
| 01:27 | cbxbiker61 | _rmk_ rabeeh made a patch that dma caching for the frames that are submitted to vmeta, if your not using that, you might want to look at the patch on openbox |
| 01:28 | _rmk_ | any ideas what kind of improvements that makes? |
| 01:28 | cbxbiker61 | and theres another patch that fixes the caching by flushing |
| 01:29 | cbxbiker61 | well he says it improves performance |
| 01:29 | cbxbiker61 | initially he set caching on the submitted frames and the the picture frames, but then he removed it from the picture frames |
| 01:30 | _rmk_ | there's soo many possibilities for improving that stuff - on the picture side you don't need to map the buffers if you don't touch the frames themselves |
| 01:31 | cbxbiker61 | he's been able to playback very high bitrate stuff, i'm still rolling in some of those patches into my tree |
| 01:31 | _rmk_ | so having the expense of mmap() and munmap() those is silly |
| 01:32 | _rmk_ | unfortunately, standard libbmm and the kernel side can only free buffers by virtual address (!) but allocate by returning you a physical address which you then have to mmap() |
| 01:32 | _rmk_ | which gives you a fun situation: if mmap() were to fail, you can't free the bmm buffer! |
| 01:34 | _rmk_ | another fun libbmm one is this: |
| 01:34 | _rmk_ | - allocate a bmm buffer in process A |
| 01:34 | _rmk_ | - mmap it in process A |
| 01:34 | _rmk_ | - pass its physical address to process B |
| 01:35 | _rmk_ | - mmap it in process B |
| 01:35 | _rmk_ | - munmap it in either process |
| 01:35 | _rmk_ | - buffer is now freed |
| 01:35 | _rmk_ | the other process is free to continue using its mmap() to that memory |
| 01:36 | _rmk_ | note that process B could be the result of a fork() of process A |
| 01:38 | _rmk_ | other things which are crappy about bmm - each time a process wants to translate a buffer address between virtual and physical, it calls into the kernel. libbmm is nothing more than a veneer to the kernel side driver with no caching... add caching and you can save quite a number of syscalls |
| 01:38 | _rmk_ | and you can then start thinking about redesigning the API to be more sane. |
| 01:40 | _rmk_ | (I say "start thinking about" because by doing that you have to break compatibility with existing libbmm) |
| 10:42 | dv_ | _rmk_: breaking compatibility sounds like a good plan, given bmm's shortcomings |
| 10:42 | dv_ | just call it bmm2 :) |
| 15:07 | RandomPixels | hello, anyone around ? |
| 15:14 | dv_ | whatsup |
| 15:27 | jnettlet | _rmk_, if you are re-working bmm perhaps you should checkout out videobuf or our implementation of ION MM which is what Android is using. |
| 15:28 | jnettlet | The ION memory manager backed by CMA gives the added bonus of not having to allocate buffers until runtime. |
| 19:54 | RandomPixels | hello rabeeh_ |