vMeta GStreamer 1.0 plugins

[Daniel Drake]

On Wed, Aug 21, 2013 at 8:03 AM, Carlos Rafael Giani
<dv at 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