[Webkit-unassigned] [Bug 260654] [Nvidia][GStreamer][GTK] Unable to play any video whatsoever

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=260654

--- Comment #26 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Philippe Normand from comment #25)
> Yes...
> 
> There's two different issues I think.
> 
> - with our GL sink we should ideally behave almost the same as gst-play
> (with glimagesink) and negotiate GLMemories all the way from decoder to sink.

If you know how to do that...

> - with our DMABuf sink I'm not sure how to proceed, but video/x-raw
> negotiation should be avoided... we'd need a dmabufupload (or maybe glupload
> can handle GLMemory conversion to DMABuf now) that would convert CUDA or
> GLMemories from the decoder to DMABufs.

This is how I think the DMABuf sink works:

We claim to support a fixed list of formats, which are the ones that can be handled by the texture mapper. Then two things can happen:

 1) gst can provide one of the formats as DMABuf: In this case we just import the DMABUf as textures and render them into the texture mapper.

 2) gst can't provide the formats as DMABuf: in this case we receive a raw video frame in one the formats we claimed in caps. We allocate a GBM buffer and upload the video frame there, then we do as if the DMABuf was provided by gst and import it as textures to render them into the texture mapper.

So, in both cases, I wonder what happens if the buffer format (and modifiers) is not supported by the driver. I guess in the first case we will fail to import the DMABuf and in the second case we will fail to allocate the buffer. I guess we should claim to support only the formats supported by the driver, the same way we do in the renderer. Do we know where exactly is failing?

And in case of not getting a DMABuf from gst, is it really more efficient to allocate, upload and then import the DMABuf? Can't we just fallback to GL or non-accelerated video?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20240709/7b272a09/attachment.htm>