The default number of jobs to use is half of the available cores
rounded down, but in situations where only one core is available (such
as under some VMs), this means that `gst-validate-launcher` defaults
to using zero jobs, a case that the test-running code is not prepared
to handle.
This change makes the code match the documentation for the `--jobs` option,
guards against negative values both in the default setting and in argument
parsing, and introduces some defensive programming to prevent other situations
where the code might try to use zero jobs.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-devtools/-/merge_requests/154>
This adds a non-thread safe refcount to the GstV4l2Request. This will
allow holding on more then one request in order to implement render
delay. This is made non-thread safe for speed as we know this will all
happen on the same streaming thread.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1881>
Starting from this patch, all queue and dequeue operation happening
on V4L2 is now abstracted with the request. Buffers are dequeued
automatically when pending requests are marked done and only 1 in-flight
request is now used.
Along with fixing issues with request not being reused with slice
decoders, this change reduces the memory footprint by allocating only
two bitstream buffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1881>
It looks like the _set_rendering_details call is superfluous
in _startup(), as it will get called in run_pipeline.
The problem with calling it before timeline_set_user_options
is that we are going to fail creating a smart profile if
the user selected eg --track-types=video, as the get_smart_profile
method compares the tracks in the asset with those on the timeline.
Reproduce with a video-only clip:
ges-launch-1.0 --track-types=video +clip file://$PWD/jelly.mp4 \
inpoint=15.0 -o foo.mp4 --smart-rendering
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/228>
Some decoding APIs support delayed output or a command for decoding
a frame doesn't need to be sequential to corresponding command for
getting decoded frame. For instance, subclass might be able to
request decoding for multiple frames and then get for one (oldest)
decoded frame or so.
If aforementioned case is supported by specific decoding API,
delayed output might show better throughput performance.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1925>
Currently the default drm device is always used on a system with
multiple drm devices. This patch allows user to specify the required
drm device via GST_VAAPI_DRM_DEVICE env variable
Example:
GST_VAAPI_DRM_DEVICE=/dev/dri/renderD129 gst-launch-1.0 videotestsrc !
vaapih264enc ! fakesink
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/409>
GST_VALUE_HOLDS_... macros may cause -Waddress warning
on gcc if GValue is allocated on stack:
gstvalue.h:145:46: warning: the comparison will always
evaluate as ‘true’ for the address of ‘v’ will never
be NULL [-Waddress]
#define GST_VALUE_HOLDS_CAPS(x) ((x) != NULL &&
G_VALUE_TYPE(x) == _gst_caps_type)
Fixes#653
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/738>
drmGetBusid() (GET_UNIQUE ioctl) won't return a valid bus id when
drmSetInterfaceVersion() (SET_VERSION ioctl) hasn't been called(see[1]),
so we can't get the right device path. Running test-display will get the
error below:
** (test-display:18630): ERROR **: 10:26:00.434: could not create Gst/VA
display
Calling drmSetInterfaceVersion() before drmGetBusid() can't fix this
issue because a special permission is required for SET_VERSION ioctl.
This patch retrieves the device path from file descriptor via
g_file_read_link()
[1] https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/drm_ioctl.c#L48-L104
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/-/merge_requests/412>
* Don't warn for live object, since ID3D11Debug itself seems to be
holding refcount of ID3D11Device at the moment we called
ID3D11Debug::ReportLiveDeviceObjects(). It would report live object
always
* Device might not be able to support some formats (e.g., P010)
especially in case of WARP device. We don't need to warn about that.
* gst_d3d11_device_new() can be used for device enumeration. Don't warn
even if we cannot create D3D11 device with given adapter index therefore.
* Don't warn for HLSL compiler warning. It's just noise and
should not be critical thing at all
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1986>
Force a string type for structure values obtained through parsing a
serialized timeline by inserting a (string) specifier after a '=',
rather than relying on gst_structure_from_string guessing the type.
As such, the functions that extract clocktimes and properties are
modified to accept string value types.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/123>
Add two examples to demonstrate "draw-on-shared-texture" use cases.
d3d11videosink will draw application's own texture without copy
by using:
- Enable "draw-on-shared-texture" property
- make use of "begin-draw" and "draw" signals
And then, application will render the shared application's texture
to swapchain's backbuffer by using
1) Direct3D11 APIs
2) Or, Direct3D9Ex + interop APIs
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1873>
Add a way to support drawing on application's texture instead of
usual window handle.
To make use of this new feature, application should follow below step.
1) Enable this feature by using "draw-on-shared-texture" property
2) Watch "begin-draw" signal
3) On "begin-draw" signal handler, application can request drawing
by using "draw" signal action. Note that "draw" signal action
should be happen before "begin-draw" signal handler is returned
NOTE 1) For texture sharing, creating a texture with
D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX flag is strongly recommend
if possible because we cannot ensure sync a texture
which was created with D3D11_RESOURCE_MISC_SHARED
and it would cause glitch with ID3D11VideoProcessor use case.
NOTE 2) Direct9Ex doesn't support texture sharing which was
created with D3D11_RESOURCE_MISC_SHARED_KEYEDMUTEX. In other words,
D3D11_RESOURCE_MISC_SHARED is the only option for Direct3D11/Direct9Ex interop.
NOTE 3) Because of missing synchronization around ID3D11VideoProcessor,
If shared texture was created with D3D11_RESOURCE_MISC_SHARED,
d3d11videosink might use fallback texture to convert DXVA texture
to normal Direct3D texture. Then converted texture will be
copied to user-provided shared texture.
* Why not use generic appsink approach?
In order for application to be able to store video data
which was produced by GStreamer in application's own texture,
there would be two possible approaches,
one is copying our texture into application's own texture,
and the other is drawing on application's own texture directly.
The former (appsink way) cannot be a zero-copy by nature.
In order to support zero-copy processing, we need to draw on
application's own texture directly.
For example, assume that application wants RGBA texture.
Then we can imagine following case.
"d3d11h264dec ! d3d11convert ! video/x-raw(memory:D3D11Memory),format=RGBA ! appsink"
^
|_ allocate new Direct3D texture for RGBA format
In above case, d3d11convert will allocate new texture(s) for RGBA format
and then application will copy again the our RGBA texutre into
application's own texture. One texture allocation plus per frame GPU copy will hanppen
in that case therefore.
Moreover, in order for application to be able to access
our texture, we need to allocate texture with additional flags for
application's Direct3D11 device to be able to read texture data.
That would be another implementation burden on our side
But with this MR, we can configure pipeline in this way
"d3d11h264dec ! d3d11videosink".
In that way, we can save at least one texture allocation and
per frame texutre copy since d3d11videosink will convert incoming texture
into application's texture format directly without copy.
* What if we expose texture without conversion and application does
conversion by itself?
As mentioned above, for application to be able to access our texture
from application's Direct3D11 device, we need to allocate texture
in a special form. But in some case, that might not be possible.
Also, if a texture belongs to decoder DPB, exposing such texture
to application is unsafe and usual Direct3D11 shader cannot handle
such texture. To convert format, ID3D11VideoProcessor API needs to
be used but that would be a implementation burden for application.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1873>
1. Set the default output alignment to frame, rather than current
alignment of obu. This make it the same behaviour as h264/h265
parse, which default align to AU.
2. Set the default input alignment to byte. It can handle the "not
enough data" error while the OBU alignment can not. Also make it
conform to the comments.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1979>
The current behaviour for obu aligned output is not very precise.
Several OBUs will be output together within one gst buffer. We
should output each gst buffer just containing one OBU. This is
the same way as the h264/h265 parse do when NAL aligned.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1979>
The current optimization when input align and out out align are
the same is not very correct. We simply copy the data from input
buffer to output buffer, but we failed to consider the dropping of
OBUs. When we need to drop some OBUs(such as filter out the OBUs
of some temporal ID), we can not do simple copy. So we need to
always copy the input OBUs into a cache.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1979>
Problem is that unreffing the EGLImage/SHM Buffer while holding the
images_mutex lock may deadlock when a new buffer is advertised and
an attempt is made to lock the images_mutex there.
The advertisement of the new image/buffer is performed in the
WPEContextThread and the blocking dispatch when unreffing wants to run
something on the WPEContextThread however images_mutex has already been
locked by the destructor.
Delay unreffing images/buffers outside of images_mutex and instead just
clear the relevant fields within the lock.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1843>
1. Add the mono_chrome to identify 4:0:0 chroma-format.
2. Correct the mapping between subsampling_x/y and chroma-format.
There is no 4:4:0 format definition in AV1. And 4:4:4 should
let both subsampling_x/y be equal to 0.
3. Send the chroma-format when the color space is not RGB.
Fixes: #1502
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1974>
