| 10:33 | dv_ | damnit |
| 10:34 | dv_ | the vivante headers and libs define the VIV_direct_texture extension, but the drivers dont actually support it |
| 10:34 | dv_ | how stupid is that? |
| 10:59 | _rmk_ | dv_: you may like to consider adding MPEG1 support to the vmeta gst plugin |
| 11:00 | _rmk_ | dv_: vmeta can decode MPEG1 as well - you just give it the MPEG1 stream and tell it mpeg2 - due to the lack of extension headers, it works out that it's mpeg1 |
| 11:01 | _rmk_ | however, if you do end up generating extension headers, it won't work |
| 11:07 | dv_ | I have added mpeg1 |
| 11:08 | dv_ | also tested it with mpeg1 files |
| 11:08 | _rmk_ | ah, great |
| 11:08 | dv_ | funny how companies tend group mpeg1 and mpeg2 together |
| 11:08 | dv_ | freescale does the same thing |
| 11:08 | jnettlet | dv_, that was true with the older driver. With the vivante 4.x series it should be there. |
| 11:08 | dv_ | jnettlet: oh? where can I get these? |
| 11:08 | _rmk_ | dv_: I just need to convince the libva people that they don't support mpeg1 and they need to fix that |
| 11:09 | jnettlet | dv_, you will need to upgrade the kernel driver as well. The kernel part is in the OLPC arm-3.5 branch |
| 11:09 | dv_ | _rmk_: the vaapi practice of requiring a separated bitstream (into slices, metadata etc.) sounds weird btw. and uncommon |
| 11:09 | dv_ | any reason why this is okay? |
| 11:10 | dv_ | jnettlet: hm currently I am using rabeeh's kernel |
| 11:10 | dv_ | can this be patched? |
| 11:10 | _rmk_ | dv: I'm assuming that's what most of the supported decoders requires |
| 11:11 | jnettlet | dv_, it would be a bit of work, but is doable. You just need to upgrade all the binaries and rebuild everything against them at the same time. |
| 11:11 | _rmk_ | dv: I'm beginning to suspect that the vmeta hardware just decodes the slices too, and the metadata is handled separately |
| 11:11 | dv_ | _rmk_: sounds like a catch-22. the decoders adapt to the api, and the api therefore cannot change in the future |
| 11:12 | _rmk_ | iow, it's just the silly vmetahal library that requires the elementary stream |
| 11:12 | dv_ | jnettlet: that kernel works with the cubox? |
| 11:13 | dv_ | _rmk_: would explain why it exists |
| 11:14 | jnettlet | dv_, nope. But my patches should be easily ported to rabeeh's kernel and the cubox. I have moved the vivante codebase into drivers/gpu/vivante with config options broken out so different platforms can select options as needed. |
| 11:20 | dv_ | alright |
| 11:22 | jnettle | 11:22 * jnettlet is going to walk the dogs now. Will pick this up when I return |
| 13:39 | dv_ | the flickering in my xvimagesink modification makes me crazy. no idea where it comes from. |
| 13:42 | jnettlet | dv_, I missed your description of the problem. I remember fixing a flickering for the gsteramer-0.10 plugin a while back. May be the same problem |
| 13:42 | dv_ | its as if suddenly the image is drawn with a previous frame |
| 13:43 | dv_ | or parts of a previous frame |
| 13:43 | jnettlet | oh that sounds very familiar...hmmm |
| 13:43 | dv_ | so if the output frames form a sequence, it is as if it is drawn line 1 2 3 4 5 3 4 6 7 8 9 10 5 7 8 etc. |
| 13:44 | dv_ | causing a "stuttering" effect |
| 13:44 | dv_ | the odd thing is, it doesnt occur with the 0.10 plugins |
| 13:44 | dv_ | I did move over the xvimagesink modifications, but perhaps I missed a detail |
| 13:44 | jnettlet | are you using the 0.10 plugins from OLPC, or the ones from cubox? |
| 13:44 | dv_ | the ones from my layer |
| 13:45 | dv_ | oh no wait |
| 13:45 | dv_ | I took the changes from vmetaxv, not bmmxv |
| 13:46 | dv_ | that is, the one that uses libphycontmem |
| 13:46 | dv_ | hmm I will try out the bmmxv sink. perhaps it also has this problem |
| 13:48 | _rmk_ | dv: sure you've got the frames in the right order? |
| 13:48 | dv_ | yeah. if I play it with a different sink (like the unmodified xvimagesink), it looks fine. same if I output to a video file |
| 13:52 | dv_ | also, it does not happen with all videos |
| 13:52 | dv_ | or at least it is not visible with all videos |
| 16:21 | dv_ | oh look at that |
| 16:21 | dv_ | I add a g_usleep to the sink's drawing call, and the artifacts are gone |
| 16:23 | dv_ | _rmk_: perhaps the driver is really not waiting until the image was drawn? |
| 17:16 | dv_ | hmm perhaps this is all a coincidence |
| 17:17 | dv_ | the marvell plugins seem to use a FIFO as a buffer pool for the picture buffers |
| 17:17 | dv_ | I use the gstbufferpool, which doesnt necessarily behave like a FIFO. so, it may return a picture that just got returned again. |
| 17:18 | dv_ | going by that, I guess the FIFO in the marvell plugins give the modified xvimagesink more time to render the frames |
| 17:18 | dv_ | in other words, there may be a race condition that went unnoticed |