gstreamer zero copy

[totaam]

Add some form of zero copy to the gstreamer encoder and decoder (#3706).
We use Gst.Buffers wrapping one or more Gst.Memory areas.
The problem is that the pixel data (planar YUV or plain RGB) is consumed by the encoder and produced by the decoder - this data can be huge and copying it around is extremely inefficient.
Despite boasting of having zero-copy mechanisms, it's not obvious how one would use them via appsrc and appsink - or even using other, potentially custom, elements.
Most of the buffer methods end up copying the data:
https://github.com/GStreamer/gstreamer/blob/main/subprojects/gstreamer/gst/gstbuffer.c

Do we have to mess with allocators? ie: GstDmaBufAllocator

Interesting read: Inter-Process Texture Sharing with DMA-BUF
Ideally, we don't want to tie this to a specific rendering backend, but if the decoder is on a GPU appsink will probably end up downloading the data to system memory..

shmsrc is not a good fit as we would need to copy our data into a shared memory area.
Perhaps shmsink can give us a zero copy buffer - not clear yet.

[TijZwa]

@totaam What about glimagesink? https://gstreamer.freedesktop.org/documentation/opengl/glimagesink.html?gi-language=c

[totaam]

@TijZwa glimagesink sounds good, but the video decoding code currently does not know where the picture is going to be used - this would only work for the OpenGL case.
Another problem is that gstreamer is asynchronous so managing the window events (create and destroy mainly) would be quite difficult.
It is mostly used in video players and such, where you create the window only once, whereas we may need to create and destroy multiple windows many times per second.

[totaam]

Apparently, we are meant to use gst_buffer_new_wrapped_full
I'm pretty sure I've played with it before - I just can't remember what was wrong with it.