| 03:15 | dbsx | are you there cbxbiker |
| 03:15 | dbsx | ? |
| 09:30 | dv_ | jnettlet: ping |
| 09:30 | dv_ | I updated the meta-cubox layer , but I am not using the newer libvmeta |
| 09:30 | dv_ | since the vdec_os_alloc* calls to not work with it |
| 09:41 | jnettlet | dv_, okay I am getting my github account cleaned up right now. I can easily add bmm support to libphycontmem so we can have one memory allocation layer for all options. |
| 09:41 | dv_ | okay |
| 09:42 | dv_ | oh, and did you read what I wrote about what I found out regarding the xv flickering? |
| 09:43 | jnettlet | dv_, I saw that you put a sleep in there and it fixed things. some sort of race condition. |
| 09:43 | dv_ | yes. does this ring a bell? |
| 09:43 | dv_ | it seems that the xvshmputimage call isnt blocked until the frame is drawn |
| 09:43 | dv_ | I guess that 1080p videos dont show the flickering simply because the frames take longer to draw |
| 09:44 | dv_ | (or longer to decode - in gstreamer, decoded frames are pushed downstream as fast as possible, it is up to the sink to synchronize and block) |
| 09:46 | jnettlet | are your patches pushed to github? |
| 09:47 | dv_ | yes |
| 09:48 | dv_ | the sleep call is here: https://github.com/dv1/gst-vmeta/blob/master/src/vmetaxvsink/vmetaxvsink.c#L552 |
| 09:49 | jnettlet | yeah I see that. |
| 09:54 | jnettlet | dv_, if you switch back to what the old code was doing and unconditionally deleting the buffer does the glitch occur? |
| 09:54 | dv_ | yes |
| 09:55 | dv_ | what puzzles me is that it works in the 0.10 plugins |
| 09:59 | jnettlet | dv_, it could the 0.10 pipeline has inefficiencies that cause this race to not show up. |
| 09:59 | dv_ | yes, that is one suspicion I have. perhaps the race simply was never found |
| 09:59 | dv_ | or it was found, but they drew the wrong conclusions. it would explain the note about "Check VMETA BUF" in the sink |
| 10:00 | dv_ | in that case, it is probably a driver problem |
| 10:00 | dv_ | unfortunately, without adding a new galcore to the kernel, this hacked xv is the only way to show high-res videos without a lot of CPU% |
| 10:25 | jnettlet | dv_, I am wondering if this is instead a timing problem due to clock differences. |
| 10:25 | dv_ | looking into the code |
| 10:25 | jnettlet | at 1080p the vmeta engine gets clocked up to a faster speed |
| 10:26 | dv_ | perhaps adding DOVEFB_IOCTL_WAIT_VSYNC would help? |
| 10:26 | jnettlet | that is what I am thinking |
| 10:27 | dv_ | somewhere around here: http://dev.laptop.org/git/projects/xf86-video-dove/tree/src/dovefb_xv.c#n2650 |
| 10:27 | dv_ | or no, a bit lower, at line 2670 |
| 10:30 | jnettlet | let me check I have to see if the VSYNC ioctl releases when the offscreen region begins or ends |
| 10:33 | jnettlet | at the beginning, so that would be a good proof of concept. I am not sure that is the best fix for this. |
| 10:33 | dv_ | hmm I do not see any effect :/ |
| 10:33 | dv_ | next try: I enable the UseGPU flag |
| 10:34 | dv_ | oh nevermind, doesnt work. gcoHAL_QuerySeparated3D2D symbol is missing |
| 10:35 | jnettlet | dv_, oh you can just comment that out. on the older chipsets you don't need it. |
| 10:36 | jnettlet | I have to finish getting my cubox dev environment up and running again. I have a bunch of patches that need to get published. It is good to be healthy again. |
| 10:37 | jnettlet | dv_, do you have an image I can download to test against quick? |
| 10:37 | dv_ | \o/ |
| 10:37 | dv_ | yes |
| 10:38 | jnettlet | I need some new fast microsd cards |
| 10:38 | dv_ | uploading to dropbox |
| 10:50 | dv_ | okay, jnettlet : here: https://www.dropbox.com/s/1xuskhcukkoxi6l/cubox-demo-image-x11-vmetaxvtest.tar.bz2 |
| 10:50 | dv_ | you also need to copy in the gstreamer 1.0 plugins for vmeta : https://www.dropbox.com/s/xzp9qtf4ys08n2t/gst10-vmeta-plugins.tar.gz |
| 10:50 | dv_ | and, I can see the flickering with this test video: http://download.openbricks.org/sample/H264/SampleClip.m4v |
| 10:51 | jnettlet | dv_, is that image one big filesystem or do you use a separate /boot partition? |
| 10:51 | dv_ | use this gst-launch call: GST_DEBUG=*vmeta*:2 DISPLAY=:0 gst-launch-1.0 filesrc location=SampleClip.m4v ! qtdemux name=dmx multiqueue name=m dmx. ! m. dmx. ! m. m. ! h264parse ! vmetadec ! vmetaxvsink m. ! fakesink sync=true |
| 10:51 | dv_ | one big filesystem |
| 10:51 | dv_ | it includes the boot.scr |
| 10:51 | jnettlet | okay and uboot supports ext4 now? |
| 10:52 | dv_ | unfortunately no |
| 10:52 | jnettlet | didn't think so. okay |
| 10:52 | jnettlet | thought I may have missed something |
| 10:52 | dv_ | just create one partition, untar the archive to it, put it in the cubox. that should be all |
| 10:53 | dv_ | (oh, and put in the plugins and the test video of course) |
| 10:53 | dv_ | also, after upgrading, I noticed that stride problems have returned. but this may be some bug in my code. I will check it later. |
| 10:56 | jnettlet | brb, need to switch my desktop over to displayport so I can bring the cubox up on hdmi |
| 11:04 | jnettlet | dv_, I see the stuttering. Do you also get the errors about the timestamping problem or computer is too slow? |
| 11:04 | dv_ | yes, but these happen only at the beginning, and are unrelated I think |
| 11:04 | dv_ | (otherwise they would pop up all the time) |
| 11:04 | dv_ | plus, I have seen this stuttering with other videos that didnt show the timestamping issues |
| 11:04 | dv_ | this sample was probably uncleanly ripped |
| 11:05 | dv_ | btw. the gstreamer 1.0 vmeta binaries are built from the latest gst-vmeta master |
| 11:06 | jnettlet | dv_, does your image support dhcp? my interface didn't come up. |
| 11:06 | dv_ | it did |
| 11:06 | dv_ | I got an IP |
| 11:08 | jnettlet | adding a static works. weird |
| 11:09 | jnettlet | okay I see the problems will take a look when I get back from walking the dogs |
| 11:09 | dv_ | cool, many thanks |
| 11:09 | dv_ | with any luck I will get to writing encoders this week |
| 11:10 | dv_ | right now, I gotta leave. be back in about an hour. |
| 11:10 | jnettlet | worked that time. |
| 11:10 | jnettlet | ttyl |
| 13:09 | dv_ | jnettlet: "worked that time" ? |
| 13:21 | jnettlet | dv_, dhcp on reboot |
| 13:21 | dv_ | ah |
| 13:21 | jnettlet | although hdmi is acting flaky |
| 13:21 | dv_ | yes. I have had problems with it. |
| 13:21 | dv_ | it refuses to give me more than 1024x768 |
| 13:22 | dv_ | on other screens, I can get up to 1920x1080, but the screen pixels dont match with the framebuffers, as if the image was scaled |
| 13:22 | dv_ | I tried to look into the code, but its ... chaotic. |
| 13:23 | dv_ | looking at it again is something I might do later, but there are more pressing concerns ATM |
| 13:23 | jnettlet | dv_, well it is probably time to switch over and start pushing on the KMS driver. |
| 13:23 | jnettlet | get some unified development resources |
| 13:23 | dv_ | there is a KMS driver? |
| 13:23 | dv_ | oh definitely |
| 13:23 | jnettlet | dv_, yep _rmk_ is pushing his upstream |
| 13:23 | dv_ | \o/ |
| 13:23 | dv_ | _rmk_, you are my hero :) |
| 13:24 | dv_ | thats great, I can then add support for his dmabuf modification |
| 13:24 | jnettlet | yep |
| 13:24 | dv_ | does the KMS driver work with the vivante GPU ones? |
| 13:25 | jnettlet | I haven't tested against the newest Vivante drivers, but it does work with the older. I think he may have some outstanding patches |
| 13:25 | dv_ | nice |
| 13:26 | dv_ | perhaps the flickering issue is fixed as well :) |
| 19:01 | jnettlet | dv_, hurray I finally partially sorted out gcc 4.8 with your cubox image. Everything built fine, however I have no idea where the image was created ;-) |
| 19:02 | dv_ | hehe |
| 19:02 | dv_ | look in tmp/deploy/images |
| 19:04 | jnettlet | dv_, hurray found them |
| 19:05 | jnettlet | bitbake could be a tad kinder and tell me where it put stuff :-) |
| 20:17 | dv_ | jnettlet: how is the gcc experiment going? |
| 21:15 | _rmk_ | okay, so the vaapi gst plugins in ubuntu 12.04 don't seem to work |
| 21:16 | _rmk_ | they cause gstreamer to complain with "Missing element: video/x-surface decoder" |
| 21:16 | _rmk_ | which is a shame, because it means I don't yet have a way to test the output side of the libva stuff |
| 21:17 | _rmk_ | ... which should be capable of doing x11, drm, dri or wayland methods |
| 21:19 | dv_ | and unfortunately, the gstreamer 1.0 vaapi plugins are still very much work-in-progress |
| 21:21 | _rmk_ | dv: does gstreamer have a list of 'capabilities' which it knows need to be linked to a particular class of plugin? |
| 21:22 | _rmk_ | a bunch of the other vaapi components do accept video/x-surface on their sink pads, but gstreamer seems to refuse to bind them to the video/x-surface source on the vaapidecode plugin |
| 21:22 | dv_ | yes |
| 21:22 | dv_ | oh, a list |
| 21:22 | dv_ | hmm I think |
| 21:23 | dv_ | there is http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/section-types-definitions.html |
| 21:24 | dv_ | and http://gstreamer.freedesktop.org/wiki/GstreamerCaps , not sure how up to date this one is though |
| 21:24 | dv_ | there is no global registry for media types (the video/x-surface stuff is not a mimetype, it is a media type) |
| 21:28 | _rmk_ | the message hints at gstreamer thinking that it needs a decoder for video/x-surface, which is not true, a vaapi surface is just a container for the rendered image in whatever format the decoder has produced |
| 21:29 | _rmk_ | and a vaapi surface can be rendered directly (by vaapisink) - internally, you pass libva the surface ID of what you want to be rendered onto the screen |
| 21:31 | dv_ | I recommend asking in #gstreamer for this |
| 21:31 | dv_ | me, I never used vaapi to be honest |
| 21:31 | dv_ | with any luck, the gst-vaapi author is around |
| 21:32 | dv_ | in other news, I hear your driver is being mainlined. that is super nice :) once this is done, I will change my OE layer to use your driver |
| 21:33 | _rmk_ | yea, I saw the comments in the scrollback :) |
| 21:33 | _rmk_ | I need to have another go at pushing it to airlied |
| 21:34 | _rmk_ | the tda998x patches have been accepted recently, which sort out the mainline driver for the hdmi stuff including audio. |
| 21:34 | dv_ | finally I can use dmabuf :) |
| 21:34 | dv_ | so the asoc stuff is sorted out? |
| 21:35 | _rmk_ | ha. hahahahaha. that's all gone super quiet :( |
| 21:36 | dv_ | I dunno, this whole asoc thing sounds wrong to me |
| 21:36 | dv_ | an attempt to shoehorn very diverse things into a common design with no real net benefits |
| 21:37 | _rmk_ | Liam is around again, and we've discussed a few bits but I'm waiting for him to respond atm |
| 21:37 | dv_ | for example, I wonder how features like adjustable PLLs or hardware async resamplers fit into this |