| 00:22 | unicorn | I found a solution, thx |
| 00:45 | unicorn | Is there someone available here ? |
| 08:20 | jnettlet | dv_, I will get a patch together today for testing. For the fourcc format definitions would you rather include a header from the graphics driver or just keep a duplicate set of definitions in the gstreamer plugin source? |
| 09:18 | dv_ | jnettlet_: hmm perhaps a duplicate set for now |
| 09:19 | dv_ | jnettlet_: we can figure out later how to put this in a header cleanly later |
| 09:19 | dv_ | er, I mean, I'd include a header in the plugins, and later, we can figure out how to put it in a package or smth |
| 09:26 | jnettlet_ | dv_, that is what I was favoring as well. |
| 09:29 | jnettlet_ | The next step is coming up with a unified driver. We have _rmk_'s KMS driver, There is another more basic one in the forums, I have my own which is more geared at the pxa168 chipset. Then we have multiple DDX drivers, legacy, new, and even one from vivante. |
| 09:30 | jnettlet_ | It will go a long way to get one repository that everyone can put their effort into. |
| 09:38 | dv_ | yeah, that would be good |
| 09:38 | dv_ | also perhaps I can finally fix my resolution problems |
| 09:39 | dv_ | with a 720p screen here, I cannot get X to use something higher than 1024x768 |
| 09:39 | dv_ | and with some 1080p screens, the framebuffer pixels actually dont match the screen ones. it looks a bit stretched |
| 09:43 | jnettlet_ | dv_, you are using rabeeh's kernel and the dovefb driver? |
| 10:13 | dv_ | jnettlet_: yes |
| 10:14 | dv_ | rabeeh's 3.6.9 kernel |
| 10:14 | dv_ | here is the OE recipe I wrote: https://github.com/dv1/meta-cubox/blob/master/recipes-graphics/xorg-driver/xf86-video-dove_git.bb |
| 10:15 | dv_ | (I mostly guessed the define values) |
| 10:20 | jnettlet_ | dv_, I will throw that on my cubox later and test a bit. |
| 10:21 | dv_ | okay, am I using the right repo btw? |
| 10:39 | dv_ | oh, also, I updated the build scripts to check for the suspend functions and to link in the rt library. if the suspend functions are not present, the whole gst_vmeta_dec_suspend_and_resume() function is disabled. I hope this is how you did things as well. either way, when you have the time, please check if it now builds out-of-the-box for mmp2 and mmp3. |
| 10:39 | dv_ | (might have missed a spot where to link rt to) |
| 15:55 | _rmk_ | yay, vlc 2.0.8 has support for va_DeriveImage |
| 15:55 | _rmk_ | (so I don't need my patch for that) |
| 16:40 | rabeeh | _rmk_: zero copy? |
| 16:42 | _rmk_ | hardly with vlc, but that does remove one unnecessary copy |
| 16:45 | _rmk_ | I took another look at h264 under libva, and it's impossible to reconstruct a stream for vmeta without violating h264 requirements concerning the picture parameter sets and sequence parameter sets |
| 16:45 | _rmk_ | even if you provide a new PPS with each frame of h264, the decoding won't use it... |
| 16:46 | _rmk_ | and because you don't have access to the original PPS or the defaults that were in it, you can't rebuild a PPS which reflects what was in the original, so you can't pass the default information into vmeta |
| 16:47 | _rmk_ | so... I'm either going to remove the h264 attempts or just disable it in my backend driver |
| 16:47 | _rmk_ | the only way I can see that changing is for vmeta to be opened up |
| 16:47 | _rmk_ | ... which probably will never happen |
| 16:51 | _rmk_ | hmm |
| 16:51 | _rmk_ | [GC_WARNING ] gckEVENT_Notify@1077: Event 7 lost (stamp 68425) |
| 16:51 | _rmk_ | [323]Event 7 lost (stamp 68425) |
| 16:51 | _rmk_ | [GC_WARNING ] gckEVENT_Notify@1063: Queue is null,interrupts 0x00000080 are not pending |
| 16:51 | _rmk_ | [323]Interrupts 0x00000080 are not pending. |
| 17:35 | _rmk_ | and of course it's not going to do it now that I added some debug |
| 17:37 | dv_ | libva? |
| 17:37 | dv_ | oh, you want to adapt vmeta to vaapi? |
| 17:38 | _rmk_ | I _have_ done for mpeg4 and mpeg2 for the last 9 months or so |
| 17:38 | _rmk_ | ... after lots of headaches trying to work out how to reconstruct the stream for vmeta |
| 17:40 | _rmk_ | h264 always proved to be a problem, and I finally put the effort in to find out why (which involved lots of spec reading, manual decoding of streams, etc |
| 17:40 | dv_ | I am surprised that you have to reconstruct a stream |
| 17:40 | dv_ | demuxing and parsing, yes. but reconstructing? |
| 17:41 | _rmk_ | what libva is handed is the slices, with all the other metadata already decoded |
| 17:41 | _rmk_ | you're not given a complete stream as such |
| 17:42 | dv_ | oh |
| 17:42 | dv_ | weird design. this should be optional |
| 18:17 | _rmk | 18:17 * _rmk_ waits for galcore to spit out the error again... rhythmbox seems to eventually provoke it |
| 19:35 | _rmk | 19:35 * _rmk_ must have placed sufficient debugging to discover the problem... because the problem's not happening now |
| 20:10 | _rmk_ | bingo. it's a race between a thread using galcore, and its "threadRoutine" |
| 20:15 | _rmk_ | wow |
| 20:19 | _rmk_ | so, gckEVENT_Submit claims the event listMutex... allocates an event id, drops it, and then submits the command queue... |
| 20:19 | _rmk_ | so two threads can do this... |
| 20:19 | _rmk_ | CPU0: claim listMutex |
| 20:19 | _rmk_ | CPU0: get event ID |
| 20:19 | _rmk_ | CPU0: drop listMutex |
| 20:19 | _rmk_ | CPU1: claim listMutex |
| 20:19 | _rmk_ | CPU1: get another event ID |
| 20:19 | _rmk_ | CPU1: drop listMutex |
| 20:20 | _rmk_ | CPU1: insert commands into the command queue |
| 20:20 | _rmk_ | CPU0: insert commands into the command queue |
| 20:20 | _rmk_ | and then we have the second event due to fire first, which upsets the event handling |
| 20:21 | _rmk | 20:21 * _rmk_ isn't sure adding yet more locks to this thing is the right answer |
| 20:22 | _rmk_ | honestly I think all the layering stuff in galcore is actively hurting the code |
| 20:45 | dv_ | _rmk_: how are the mainlining efforts going? |
| 21:33 | jnettlet | _rmk_, I don't think more locks is needed there. Why not just hold the eventListMutex until after the Event is submitted to the command queue? |
| 21:40 | jnettlet | really unless the commands are part of the same context there is no reason that they should need to be executed in the same order as the event came in. |
| 23:58 | _rmk_ | jnettlet: having been out to the pub tonight, now is the right time to tackle this problem :) |