memory:DMABuf usage with waylandsink

[Damian Hobson-Garcia]

Hello All,

I am working on a plugin for H/W that can output video buffers as
dmabufs for display on a wayland compositor via waylandsink.
It looks like the colour formats supported by the compositor are
reported by waylandsink in 2 separate caps structures, one for SHM
buffers and one for DMABUFs. The DMABUF structure sets the
GST_CAPS_FEATURE_MEMORY_DMABUF caps feature while the SHM one doesn't.

According to the gstdmabuf.h header (plugins-base), though, this should
only be set for non-mappable DMABUF, but since my DMABUFs *are*
mappable, it seems like I shouldn't be setting this flag.  Without it,
though only the formats supported for SHM buffers can be negotiated.  Of
course, its easy enough to just lie and set the flag, but I'm wondering
if there is a more correct solution.

In general, what should upstream plugins be doing to negotiate the
DMABUF formats with waylandsink?  I've tried to find some examples in
other plugins, but grep hasn't given me much to go on.

Thank you,
Damian
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le lundi 04 septembre 2017 à 17:28 +0900, Damian Hobson-Garcia a
écrit :

> Hello All,
>
> I am working on a plugin for H/W that can output video buffers as
> dmabufs for display on a wayland compositor via waylandsink.
> It looks like the colour formats supported by the compositor are
> reported by waylandsink in 2 separate caps structures, one for SHM
> buffers and one for DMABUFs. The DMABUF structure sets the
> GST_CAPS_FEATURE_MEMORY_DMABUF caps feature while the SHM one doesn't.
>
> According to the gstdmabuf.h header (plugins-base), though, this should
> only be set for non-mappable DMABUF, but since my DMABUFs *are*
> mappable, it seems like I shouldn't be setting this flag.  Without it,
> though only the formats supported for SHM buffers can be negotiated.  Of
> course, its easy enough to just lie and set the flag, but I'm wondering
> if there is a more correct solution.
>
> In general, what should upstream plugins be doing to negotiate the
> DMABUF formats with waylandsink?  I've tried to find some examples in
> other plugins, but grep hasn't given me much to go on.

There is no solution to this problem other then using a caps feature.
This of course prevents software element like text overlay or other in-
place filter to work, you'll need a converter.

The solution that I have recommended is to implement a GL fallback for
SHM buffers, so that formats supported by DMABuf are also supported by
SHM. This also has the plus side that if you get DMABuf that aren't
compatible (e.g. wrong stride), you still save a copy by passing the
DMABuf FD as being SHM. For PC compositor, this is an evident choice as
the compositor will need to support software video decoders.

regards,
Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Damian Hobson-Garcia]

Hi Nicolas,

> CC: [hidden email] <[hidden email]>
>
> Le lundi 04 septembre 2017 à 17:28 +0900, Damian Hobson-Garcia a
> écrit :
>> Hello All,
>>
>> I am working on a plugin for H/W that can output video buffers as
>> dmabufs for display on a wayland compositor via waylandsink.
>> It looks like the colour formats supported by the compositor are
>> reported by waylandsink in 2 separate caps structures, one for SHM
>> buffers and one for DMABUFs. The DMABUF structure sets the
>> GST_CAPS_FEATURE_MEMORY_DMABUF caps feature while the SHM one doesn't.
>>
>> According to the gstdmabuf.h header (plugins-base), though, this should
>> only be set for non-mappable DMABUF, but since my DMABUFs *are*
>> mappable, it seems like I shouldn't be setting this flag.  Without it,
>> though only the formats supported for SHM buffers can be negotiated.  Of
>> course, its easy enough to just lie and set the flag, but I'm wondering
>> if there is a more correct solution.
>>
>> In general, what should upstream plugins be doing to negotiate the
>> DMABUF formats with waylandsink?  I've tried to find some examples in
>> other plugins, but grep hasn't given me much to go on.
>
> There is no solution to this problem other then using a caps feature.
> This of course prevents software element like text overlay or other in-
> place filter to work, you'll need a converter.

Ok, I see. Thank you for the feedback.

Damian
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le jeudi 07 septembre 2017 à 15:54 +0900, Damian Hobson-Garcia a
écrit :
> > There is no solution to this problem other then using a caps feature.
> > This of course prevents software element like text overlay or other in-
> > place filter to work, you'll need a converter.
>
> Ok, I see. Thank you for the feedback.

I forgot to mention, long term, for the text overlay, we'll enable
CompositionMeta support in waylandsink using a sub-surface. We'll then
get higher quality sub-title and will work with caps feature. We just
need someone to have the time to do so.

regards,
Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Yasushi SHOJI-2]

Hi,

On Mon, Sep 4, 2017 at 5:28 PM, Damian Hobson-Garcia
<[hidden email]> wrote:
> According to the gstdmabuf.h header (plugins-base), though, this should
> only be set for non-mappable DMABUF, but since my DMABUFs *are*
> mappable, it seems like I shouldn't be setting this flag.  Without it,
> though only the formats supported for SHM buffers can be negotiated.  Of
> course, its easy enough to just lie and set the flag, but I'm wondering
> if there is a more correct solution.

It might be nice to rename it to
GST_CAPS_FEATURE_MEMORY_NONMAPPABLE_DMABUF?

If dmabuf get ubiquitous in the future, many developers get confused.
--
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le vendredi 08 septembre 2017 à 13:19 +0900, Yasushi SHOJI a écrit :

> Hi,
>
> On Mon, Sep 4, 2017 at 5:28 PM, Damian Hobson-Garcia
> <[hidden email]> wrote:
> > According to the gstdmabuf.h header (plugins-base), though, this should
> > only be set for non-mappable DMABUF, but since my DMABUFs *are*
> > mappable, it seems like I shouldn't be setting this flag.  Without it,
> > though only the formats supported for SHM buffers can be negotiated.  Of
> > course, its easy enough to just lie and set the flag, but I'm wondering
> > if there is a more correct solution.
>
> It might be nice to rename it to
> GST_CAPS_FEATURE_MEMORY_NONMAPPABLE_DMABUF?

Too late, it's in the API. It's also a bit wrong since you may be using
the caps feature with mappable DMABuf too. It's a matter of
negotiation, if nothing in the pipeline prevents it, it will be used.
Will happen in some future to satisfy waylandsink when doing v4l2src !
waylandsink.

We could clarify the doc though. Feel free to give it a try.

regards,
Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel