On Wed, Aug 21, 2013 at 8:03 AM, Carlos Rafael Giani <d...@pseudoterminal.org> wrote: > Yes, it is written from scratch. First, I wanted to use the GStreamer video > decoder base class, which the Marvell decoder didn't. Second, the Marvell > code uses many hacks that simply won't translate to GStreamer 1.0 . Third, > it was much less work, and the code is much cleaner this way :) > > >> I see you have already included our recent fix for the Xv plugin too, >> nice. The IPP deinterlace flag handling is not present, I guess you >> have excluded that for good reason, I'm not even sure what it does... > > To be honest, this is a todo. But I was told that deinterlacing does not > work in the X11 driver yet. So I cannot test it, and therefore cannot add > support for it. > As for the fix, do you mean the one about the alignment?
I mean the recent commits at http://dev.laptop.org/git/users/dsd/gst-plugins-vmetaxv I did not announce them to the cubox community so I'm glad you found them somehow. > The race condition I mentioned is really weird. The flickering disappears if > I add a sleep call right after drawing the shm buffer with XShmPutImage. > This indicates that the frames are filled with new data before they are > fully drawn. In other words, the driver does not cause the plugin to wait > long enough. There are certainly some strange/unpredictable interactions between the XShmPutImage call and the actual PutImage implementation inside the X driver. I found that at http://dev.laptop.org/ticket/12644#comment:7 Maybe it is my change there that is causing the flickering? As the gstreamer plugin no longer waits for the X driver to actually acknowledge that it has rendered the frame. http://dev.laptop.org/git/users/dsd/gst-plugins-vmetaxv/commit/?id=56a35b8d7f3ed5f52371dc826502f1a08894ea46 >> Also looks great that you have got the xv plugin using vmeta libs to >> allocate physical memory areas. Rather than facing the >> libbmm/libphycontmem mess directly like the previous version did. > > True. As it turns out, Marvell's xv sink only used bmm/phycontmem to get a > physical address for a corresponding virtual one. Since I send the > virtual/physical address information inside the GstMemory blocks contained > in the GstBuffers, I do not need these libraries. The Marvell plugins do not > put the physical address inside the GstBuffers (there is no field for that). > >>> The decoder should be stable. The existing sink has a flickering problem >>> which seems to be caused by a race condition in the X11 driver that >>> wasn't >>> noticed so far due to timing coincidences in Marvell's 0.10 plugins. John >>> Nettleton tried out my plugins on OLPCs and informed me that they worked. >>> Perhaps it would be usefult to mention it here: >>> http://wiki.laptop.org/go/Vmeta >> >> I will mention it. That flickering problem will have to be solved >> before this becomes useful to anyone though. > > Okay. Hopefully this will be fixed soon. I will see if there are updates. > >>> I have heard about a new KMS X driver which will be pushed upstream soon. >>> Until I can get it, I will not be addressing the sink's flickering, since >>> the new driver may have fixed it already. >> >> The new driver source is available on the dri-devel mailing list. >> However there are several complications that must be solved before it >> goes upstream. >> >> Then a new X driver will be needed, and whoever steps up to maintain >> that will have to decide if they really want to support the horrible >> hack used by the vmetaxv plugin. And then implement it, test it, etc. >> >> Then there will be a few other hurdles to go over before the new >> drivers are really a convincing replacement. Like GPU support. >> >> In other words, I don't see this being upstream soon, and even when >> that does happen, there will probably be other major steps required >> before it is really useful. So I would continue to focus on the >> existing "stack". > > Russell King added an alternative to the BMM hack; something DMABUF-based, > which is much cleaner. > His alternative can also be detected, unlike the BMM hack (the decoder > cannot find out if the driver contains the hack). Maybe you know more about this then I do then. But I still do not see this new driver stack being deployed as a replacement any time this year... > Do you think there is demand for vMeta encoder plugins as well? Technically, it would be great to have such functionality, for capturing good quality videos from the camera. However, I believe shipping a product with encoding support for these closed formats adds a load of legal costs/headaches, enough to cancel out any demand. Daniel _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel