Don't update info's size with the VA image reported data size for single plane
images, since drivers might allocate bigger space than the strictly required to
store the image, but when we dump the buffer as is (using filesink, for example)
the produced stream is corrupted. For multi-plane images video meta is required
to read/write them.
We updated info's size because gstreamer-vaapi did it too, but the reason to
update it there was for uploading and rendering surfaces (commit c698a015).
Furthermore, this patch adds an error message if the allocated data size for the
image by the driver is lesser than the expected because it would be a buggy
driver.
Fixes: #2959
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5308>
Even if decoder is negotiated with CUDA memory feature, if downstream
proposed no buffer pool, assume that the pool size is unknown.
And disable zero-copy if there's no more free output surface.
Or, in case of reverse playback, always copy frames.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5338>
Even if the segmentation feature value is not updated,
the parsed "segmentation_update_map" and "segmentation_temporal_update"
values should not be cleared as it's referenced during lower
level bitstream parsing. Also, don't use assert() in parser
unless it's clearly impossible condition.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5334>
If DPB is full already, GstH265Decoder::new_picture() might fail if
subclass uses fixed size picture pool and its size is equal to the DPB
size. Call the new_picture() after DPB is cleared in gst_h265_decoder_dpb_init()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5333>
Issue is that when amc was producing a codec-data buffer, a
GstVideoCodecFrame was being popped off the internal queue. This meant
that the codec-data was being associated with the first input frame and
the second (first encoded buffer) output buffer with the second input
frame. At the end (assuming one input produces one output which seems
to hold in my testing and how the encoder is currently implemented)
there would be an input frame missing and would be pushed without any
timing information. This would lead to e.g. muxers rejecting the buffer
without PTS and failing to mux.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5330>
The timestamp offset can be negative, and it can be a bigger negative
number than the latency introduced by the rtpjitterbuffer so the overall
timeout offset can be negative.
Using the negative offset for calculating how many packets can still
arrive in time when encountering a lost packet in an equidistant stream
would then overflow and instead of considering fewer packets lost a lot
more packets are considered lost.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5296>
The GST_VIDEO_FORMAT_Y410, GST_VIDEO_FORMAT_Y412_LE and GST_VIDEO_FORMAT_Y412_BE
formats in fact are packed formats, which have just 1 plane. But we have special
setting for them rather than using get_single_planar_format_gl_swizzle_order().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5314>
As we don't have any mapping from YUV formats + modifiers to an equivalent
emulated format (e.g. NV12 + modifier -> R8+modifier/RG88+modifier), do no
allow these formats to be used with the indirect DMABuf uploader.
Fixes#2942
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5270>
gst_video_info_set_interlaced_format() can return an error if the
width/height causes integer overflow. Handle this case, so that we can
fail cleanly. This has been experienced while testing an in-progress
driver.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5286>
Some drivers will push an buffer flagged LAST but empty. In decoder
case, this results in an "producing too many buffer" warning, even
though the result is entirely correct. Detect this case in order to
signal EOS earlier and avoid this warning.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5286>
This is consistent with the librtmp-based old rtmp plugin and ffmpeg.
While some servers require a valid flash-version, others are failing
with a too long or any flash-version at all.
By changing to the same default as in the old plugin and in ffmpeg,
GStreamer will at least behave the same and will work and fail with the
same servers without setting a flash-version.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5293>
The same is done in the set_property function. This was noticed when attempting
to dump a pipeline containing glsinkbin sink=gtk4paintablesink to dot format.
Critical warnings were raised due to the missing force-aspect-ratio property on
that sink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5311>
It is similar to NV12 but has 10bits per channel instead of 8.
As it is supported by many modern GPUs, VA-API and an increasing
number of Wayland compositors, let's support it as well.
Also bump the required libdrm version accordingly and add a temporary
define for the WL_SHM format.
Tested with Weston, Mutter and Sway.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5275>
unlock_stop() is expected to be run while the streaming thread is idle. To
guaranty this is the case, we should take the streamlock, but its not
possible to take this lock during state transitions from PAUSED to
PLAYING as the wait function that we want to terminate is holding it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4961>
After a create() call, which may have returned FLUSHING or a filled buffer,
if it possible that we detect that we are now in pause. As live sourced
don't produce data in pause, drop the buffer is any and later retry creating
a buffer. This will ensure that we resume from pause while avoiding displaying
ancient frame.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4961>
When the pipeline goes from Playing to Paused, this change will invoke
unlock in the derived class. When the pipeline goes from Paused to
Playing, this change will invoke unlock_stop in the derived class.
This feature was removed in commit 523de1a9 and is now being restored.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4961>
Fixes regression introduced in ba61160d6c,
where running check tests with gst-validate-launcher -f would trigger
this exception:
AttributeError: 'GstCheckTest' object has no attribute 'reports'.
Did you mean: 'reporter'?
The member `reports` is meant to be just part of GstValidateTest, but
not other subclasses, even though a usage is still found in the base
class GstTest in the method test_end().
This patch introduces an override of the methods copy() and test_end()
in GstValidateTest so that `reports` is copied and cleared respectively,
but only for validate tests.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5281>
This is to fix an infinitely blocked upstream streaming thread if
* upstream has fixed-size buffer pool, some H/W decoders for example
* downstream returned flow error without releasing buffer
When the fixed-size buffer pool hits its configured max-buffers and
also downstream of queue returned flow error without releasing corresponding
buffer, upstream has no chance to run the next processing loop
because it will be blocked by acquire_buffer(), and therefore
downstream flow will not be propagated to upstream.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5023>
Old versions of mesa doesn't support VASurfaceAttribDRMFormatModifiers. To
solve it, by just ignoring the modifiers assuming that linear is accepted and
produced, the creation of frames will be tried again without that attribute.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5256>
This patch removes the code duplication of input buffer importation, in all the
va elements that import video frames. It defines a synthetic object whose
members are required to create a new input buffer and do the importation of the
upstream buffer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5257>
Fixes a potential GPU stall if an immediately freed texture/buffer is
attempted to be reused immediately by the CPU, e.g. when uploading.
Problematic scenario is this:
1. element does GPU processing reading from texture
2. frees the buffer back to the pool
3. pool acquire returns the just released buffer
4. GPU processing then has to wait for the previous GPU operation to
complete causing a stall
If there was a reliable way to know whether a buffer had been finished
with across all GPU drivers, we would use it. However as that does not
exist, this workaround is to keep the released buffer unusable until the
next released buffer.
This is the same approach as is used in the qml (Qt5) elements.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5144>
Setting the surface source rectangle has been omitted so far. As a side effect
surface created with padded width/height are being scaled down. Fix this using
the viewporter source rectangle configuration. This can later be enhanced
to support crop meta.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5259>
When we consider the DMA kind caps as input, the input_state->info
only contains the video format of GST_VIDEO_FORMAT_DMA_DRM, which
is not enough for va plugins. The new info in base encoder contains
the correct video info after the DMA caps parsing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5189>
Since d3d11convert and its variant elements does not enable basetransform's
passthrough, passthrough allocation query needs to be handled
manually in order to respect downstream element's min/max buffer
requirement.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5255>
When using `gst_sdp_media_set_media_from_caps` on `application/x-rtp` caps
without `clock-rate` it wrongly reports missing payload type even if `payload`
is present in the caps.
This seems to be a copy&paste error from the error message for missing payload
type.
When using payload=10, both `clock-rate` and some other media properties are
defined by the RTP standard so I was wondering whether I could omit `clock-rate`
and was confused about the error message.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5250>
* Library versioning should not be used for plugins since it will add
-{version}.dll suffix (and versioned libraries on Linux with symlink).
Then the library file name and plugin init function name mismatch
will result in blacklisted plugin.
* Don't define BUILDING_GST_CODECS, makes no sense
* Don't define G_LOG_DOMAIN, which should be used only for libraries,
not plugins
* Depends on gstcodecparsers libary, not gstcodecs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5249>
This page has been only sporadically updated for a decade, and it is
unlikely to be updated properly anytime soon. Update the top half, and
add a note about the tutorial section being out of date.
The trigger for this was a question on the mailing list about Windows
11 support, since it's not listed in the supported platforms list.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5239>
when playing some codec such as matroska with vp9 codec,
demuxer will save information like video_mastering_display_info
and video_content_light_level in caps that decoder need,
v4l2videodecoder can use it by calling V4L2_CTRL_CLASS_COLORIMETRY
ioctl.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4403>
If decoder notify a source change event when the capture format is
changed, not the resolution changed.
then gst_v4l2_object_acquire_format will retuen false due to
unsupported format.
we need to clear the format lists in the source change flow,
and reenumerate format list
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5218>
This elements pass RTP packets along unchanged and appear as a RTP
payloader element.
This is useful, for example when using the gstreamer-rtsp-server
library, in the case where you are receiving RTP packets from a
different source and want to serve them over RTSP. Since the
gst-rtsp-server library expect the element marked as payX to be a RTP
payloader element and assumes certain properties are available.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5204>
Imported dmabuf are not being duped, so they should never be closed. Instead,
we ensure their live time by having strong reference on their original
buffer. This should fix potential flickering due to dmabuf being closed
too early.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5101>
Now that we can split GStreamer buffers over multiple v4l2 buffer, we may
endup waiting for these buffers to be processed. Avoid waiting for any of
the parts being processed. As a side effect, the pool will now try to
grow if the number of buffers is not sufficient, and will fail
otherwise.
This fixes a hang if the very first frame did not fit. In this case, the
driver will retrain that buffer until the capture is setup, but
GStreamer won't setup the capture until process() function have
returned.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5100
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5143>
Fix warnings from bindings changes in various plugin
examples
Fix the python mixer plugin by ensuring that PIL
is not holding a reference to mapped GstBuffer memory.
Port the filesrc example from old_examples
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5187>
The hack enforcing strictly increasing timestamps was, according to the
code comments, because librtmp was confused with backwards timestamps.
rtmp2sink is not using librtmp as rtmpsink did, so this is no longer
required.
Also changing the timestamps is causing audio glitches when streaming to
Youtube.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5212>
Add gst_audio_ring_buffer_set_errored() that will mark the
ringbuffer as errored only if it is currently started or paused,
so gst_audio_ringbuffer_stop() can be sure that the error
state means that the ringbuffer was started and needs stop called.
Fixes a crash with osxaudiosrc if the source element posts
an error, because the ringbuffer would not get stopped and CoreAudio
would continue trying to do callbacks.
Also, anywhere that modifies the ringbuffer state, make sure to
use atomic operations, to guarantee their visibility
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5205>
Section 3.4 in RFC8835 states that if a WebRTC endpoint uses an HTTP
proxy to access the Internet it MUST include the "ALPN" header. This
commit adds this header.
By default the ALPN used when connecting to the TURN/TCP server via a
proxy is set to "webrtc". It can be changed by adding an alpn url
option for the http-proxy. For example:
http://user:pass@my.http.proxy.com:8080?alpn=c-webrtc
This will add the header "ALPN: c-webrtc" to the HTTP proxy CONNECT
request.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4212>
By default, macOS attempts to run lldb against a misbehaving process to handle the crash. This does not play well
with the SISEGV/SIGQUIT handler we add in gst-launch/gst-validate. The 'spinning' mechanism causes the lldb
and debugserver processes ran by macOS to misbehave, taking 100% CPU and rendering both themselves and the GStreamer
instance frozen and very hard to effectively kill. macOS's Activity Monitor is also unusable while this is happening.
This patch takes the quickest possible solution of just disabling those signal handlers entirely on macOS.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5190>
Adds gst_queue_array_sort for sorting and gst_queue_array_push_sorted{,struct} for pushing in a sorted order.
All three functions accept a comparison GCompareDataFunc along with optional user_data to pass to it.
In gst_queue_array_sort a small workaround was needed to correctly sort non-struct arrays. Like what _find() already
does, we need to dereference our pointers first, to make sure we can use the same comparison functions everywhere.
This is done via a small wrapper around the provided comparison function.
The array can also wrap around (tail ends up 'before' the head), in which case we have to reorder the array (similar to
what do_expand() does) to then be able to use an existing sorting function, like g_qsort_with_data().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5112>
If a depayloader aggregates multiple RTP buffers into one buffer only
the last RTP buffer was checked for header extensions. Now the
depayloader remembers all RTP packets pushed before a output buffer is
pushed and checks all RTP buffers for header extensions.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4979>
Don't call wait_event() at all for gap events, as basesink will
end up waiting for the time that the gap event would be rendered
out at the audio device. There's no need to render it at all,
just treat it as a handy point to resync the audio if needed,
let the ringbuffer render silence, and place the next buffer
into the ringbuffer where it belongs.
The only thing we really need to do is make sure the ringbuffer
and clock are running, and wait for preroll.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2749
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5178>
Adding cudaipc{src,sink} element for CUDA IPC support.
Implementation note:
* For the communication between end points, Win32 named-pipe
and unix domain socket will be used on Windows and Linux respectively.
* cudaipcsink behaves as a server, and all GPU resources will be owned by
the server process and exported for other processes, then cudaipcsrc
(client) will import each exported handle.
* User can select IPC mode via "ipc-mode" property of cudaipcsink.
There are two IPC mode, one is "legacy" which uses legacy CUDA IPC
method and the other is "mmap" which uses CUDA virtual memory API
with OS's resource handle sharing method such as DuplicateHandle()
on Windows. The "mmap" mode might be better than "legacy" in terms
of stability since it relies on OS's resource management but
it would consume more GPU memory than "legacy" mode.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4510>
If glyphrun unit is changed in a single line, there could be
overlapped background area which result in drawing background
twice. Adding geometry combine so that background geometry objects
with the same color can be merged and rendered at once
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5179>
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2900
The `reports` list was being copied as a reference, therefore, copies of
a test ended up inadvertedly sharing the same list of reports. Reports
added by one instance of the test would be reflected in all instances.
This caused a race condition where, if a test was run on repeat with
gst-validate-launcher -f, very often wrong log file was shown to the
user. For instance, gst-validate-launcher would say "test failed, see
log for iteration7", but iteration7 would contain "TEST PASSED".
Worse, the runner would add the report to that incorrect log file,
mixing problems between different executions of the tests.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5177>
Latest MSYS2 MinGW provides these now, so we don't need to define them
if they're already present in the header.
The AudioClient3 GUID requires the Windows 10 SDK, so it's only
available in the latest MinGW, and the MinGW in Cerbero is too old.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5155>
VA decoders implementation has been verified from 1.18 through 1.22
development cycles and also via the Fluster test framework. Similar
to other cases, we can prefer hardware over software in most cases.
At the same time, GStreamer-VAAPI decoders are demoted to NONE to
avoid collisions. The first step to their deprecation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2312>
These 10bit formats are identical to NV12_16L32S, but 64bytes of data is being
prefixed with 16bytes data with four pixels of lower 2bits per byte. For
MT2110T, the lower two bits set so each bytes contains a column of 4 pixels,
also describe as tiled lower 2 bits. MT2110T has been chosen as a name to match
the vendor chosen name. This format is unlikely to exist for other vendors.
For MT2110R, the 2 low bits are in raster order.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3444>
When advancing the ringbuffer, store the processed CoreAudio sample
time, then interpolate the clock in the _get_delay() calls to smooth
the clock. CoreAudio's "latency" report is always a constant and
otherwise leads to the clock generating a latency-time staircase.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5140>
Set the BufferFrame size in CoreAudio so it will deliver data
in ringbuffer segment units when recording. Otherwise, CoreAudio
will provide data in whatever granularity it wants, with no
relationship to the requested latency-time.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5140>
The current limit is `x10`, which allows just `+20 dB` of gain.
While it may seem sufficient, this came up as a problem
in a real-world, non-specially-engineered situation,
in strawberry's EBU R 128 loudness normalization.
(https://github.com/strawberrymusicplayer/strawberry/pull/1216)
There is an audio track (that was not intentionally engineered that way),
that has integrated loudness of `-38 LUFS`,
and if we want to normalize it's loudness to e.g. `-16 LUFS`,
which is a very reasonable thing to do,
we need to apply gain of `+22 dB`,
which is larger than `+20 dB`, and we fail...
I think it should allow at least `+96 dB` of gain,
and therefore should be at `10^(96/20) ~= 63096`.
But, i don't see why we need to put any specific restriction
on that parameter in the first place, other than the fact
that the fixed-point multiplication scheme does not support volume
larger than 15x-ish.
So let's just implement a floating-point fall-back path
that does not involve fixed-point multiplication
and lift the restriction altogether?
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5063>
Issue was that Qt was caching multiple different shadersbased on a static
variable location. This static variable location was the same no matter
the input video format and so if an item had an input video format of
RGB and another of RGBA, they would eventually end up using the same
GL shader leading to incorrect colours.
Fix by providing different static variable locations for each of the
different shaders that will be produced.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5145>
There is currently no way for applications to know if the stream has
been properly terminated by the server or if the network connection
was disconnected as EOS is sent in both cases.
Adding a property so connection errors can be reported as errors
allowing applications to distinguish between both scenarios.
Fix#2828
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5115>
When this flag is enabled, the transform_caps() simply set passthrough
to generate the raw caps. This is not correct, because the sink and
src have different format/drm-format fields.
We already add system memory conversion for DMABuf manner, so no more
need for this flag.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _nvmm_upload_transform_caps() only simply apply
"memory:NVMM" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
And in _nvmm_upload_accept(), we should only accept the "memory:NVMM"
feature in input caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _directviv_upload_transform_caps() only simply apply
"memory:GLMemory" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
And in _directviv_upload_accept(), we should only accept the system
memory as input caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _gl_memory_upload_transform_caps() only simply apply
"memory:GLMemory" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
And in _gl_memory_upload_propose_allocation(), we should only allocate
the allocator and buffer pool for the caps with "memory:GLMemory"
feature.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _upload_meta_upload_transform_caps() only simply apply
"memory:GLMemory" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
The current _raw_data_upload_transform_caps() only simply apply
"memory:GLMemory" to all input caps to transform the output caps.
This is not precise and may cause problem. For example, if the
input caps include:
video/x-raw(memory:DMABuf), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
it will be changed as
video/x-raw(memory:GLMemory), width=(int)1920, height=(int)1080, \
interlace-mode=(string)progressive, multiview-mode=(string)mono, \
framerate=(fraction)30/1, drm-format=(string)NV12:0x0100000000000002
For GLMemory kind caps, no drm-format should appear.
So we should let it only transforms which it can recognize.
We also should recognize the system memory caps in _accept() early, if
the input is not system memory, we just return early.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
Most of the time, the RGB kind formats are OpenGL native supported
format which has only one plane. They can be imported at one shot
using no matter DIRECT or INDIRECT mode.
While YUV kind formats which have multi planes have two ways to import.
They can be DIRECT imported, which requires GL_OES_EGL_image_external
extension. The output format should be RGBA and TARGET should be set
as OES after imported. The other way, they can be INDIRECT imported,
which makes each plane as a texture. In this mode, the imported textures
have different fourcc from the original format. For example, the NV12
format can be imported as a R8 texture for the first plane and RG88
texture for the second plane. The output TARGET should be sets as 2D
in this mode.
When converting sink caps to src caps, we first filter the feature of
"video/x-raw(memory:DMABuf)" and system memory. Then Based on the
external_only flag (INDIRECT mode does not care while DIRECT mode cares),
we transform the drm-format into the gst video format.
When converting src caps into sink caps, we first filter the correct
TARGET(INDIRECT mode contains 2D only while DIRECT mode contains 2D,
OES or both of them) gstructure. Then Based on the include_external flag
(INDIRECT mode always true while DIRECT mode depends on TARGET), we
transform the gst video format into drm-format.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3524>
