[Bug 779146] dmabuf: be able to negotiate tiled surfaces

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=779146

Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |OBSOLETE

--- Comment #53 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
I've just re-read that thread, again, and am still not convinced witch way will
do.

The meta way, which will likely end up as GstDrmMeta at this pace, has a lot of
drawback. It inherit the GstVideoInfo/Format and GstVideoMeta for cases where
the format won't be specified inside GStreamer. Of course some of the
compatible fieds could be reused, like strides, but a lot is not. Also, the
formats will be negotiated based on the assumption driver always support a DRM
fourcc with and without the modifiers. Strides are also not negotiated in a
context where this cannot fallback to video_frame_copy() slow path.

On the other side, the video/x-opaque-drm caps negotiation would better
negotiate the format, but exposing the stride to further guaranty that
negotiation is a success does not seem something available API wise. In that
scenario though, GstDrmMeta becomes a clear subset of information passed
blindly to driver (which is what we want) that is sufficient for the exchange.

In the end, I think the modifiers need to be in the caps, which give a plus to
Olivier's proposal.  But we also need to signal the usual stuff like
colorimetry, chroma-siting, 3d layout, framerate, par, etc, which need to be
parsed from the caps, for which reusing the VideoInfo code would be nice. So we
need an in-between. But I'm quite clear now that the modifiers must go in the
caps.

Then for fallback, In think the answer is renegotiation. By dropping the
non-working buffers, and redoing the nego without the format/modifiers that
just failed. This is a lot of non-trivial work though, specially for decoders.
But for vaapi, it's the vpp that would handle that, the decoders can stay
inflexible.Thanks for taking the time to report this.
However, you are using a version that is too old and not supported anymore by
GNOME developers. GNOME developers are no longer working on that version, so
unfortunately there will not be any bug fixes by GNOME developers for the
version that you use.

By upgrading to a newer version of GNOME you could receive bug fixes and new
functionality. You may need to upgrade your Linux distribution to obtain a
newer version of GNOME.

Please feel free to reopen this bug report if the problem still occurs with a
recent version of GNOME, or feel free to report this bug in the bug tracking
system of your Linux distribution if your distribution still supports the
version that you are using.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.