Add property "handle-segment-change" for user to allow pushing
custom segment event. For now, this property can work only for
time format GstSegment.
This property can be useful in case application controls timeline
of stream such as there is timestamp discontinuity but playback is
expected to be continuous. Multi-period scenario of MPEG-DASH is an
example of this use case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/663>
Since we are using VideoMeta, the converter (similarly to the video_frame_copy
utility) should have no issue dealing with frames that are slightly larger.
This situation occure as some element will use padded width/height for
allocation, which results in a VideoMeta width/height being larger then the
display width/height found in the negotiated caps.
Fixes#790
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/747>
For example, BT709, BT601, and BT2020_10 all have theoretically
different transfer functions, but the same function in practice. In
these cases, we should use the fast path for negotiating. Also,
BT2020_12 is essentially the same as the other three, just with one more
decimal point, so it gives the same result for fewer bits. This is now
also aliased to the former three.
Also make videoconvert do passthrough if the caps have equivalent
transfer functions but are otherwise matching.
As of the previous commit, we write the correct transfer function for
BT601, instead of the (functionally identical but different ISO code)
transfer function for BT709. Files created using GStreamer prior to that
commit write the wrong transfer function for BT601 and are, strictly
speaking, 2:4:5:4 instead. However, this commit takes care of
negotiation, so that conversions from/to the same transfer function are
done using the fast path.
Fixes#783
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/724>
If the cropping or scaling input or output rects put us completely
outside the input/output frame respectively, we can't draw anything
except black safely. Check for those conditions and don't set up a
configuration that attempts to access out of bounds memory outside
the input/output framebuffers.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/696>
If the frames passed in to gst_video_converter_frame()
have a different layout than was configured for, the
conversion code might go out of bounds and crash.
Do a sanity check on each frame passed in, and in the
absence of a return value in the API, just
refuse the conversion in invalid cases and leave the
destination frame untouched so it's obvious to
users that it was broken.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/696>
This patch was taken from #629#note_178766, the comment made
at the time was:
The root issue is a mismatch between the initialization of render_rect
in GstGLWindowX11Private and what's expected in the draw_cb function.
Because render_rect is not explicitly initialized to a width and height
of -1 (unlike gstglwindow_wayland_egl.c which does initialize to -1),
the less-than check for explicitly-set render_rect at gstglwindow_x11.c:453-454
always fails, even when the parent_win has been set and the render rectangle
has never been set.
Maybe this came from copying the similar check in the wayland code? Regardless,
I think the correct inequality should be '<= 0' (on both lines).
Alternatively initialization could be changed, but other sinks, e.g.
xvimagesink don't appear to use -1 to mean "unset" render_rect this way.
The issue can be reproduced by running the example in
tests/examples/gl/qt/videooverlay/ on X11, and resizing the output
window
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/701>
Previously we only handled one event at a time, which could lead to the
following two suboptimal situations:
- frame 0 at 20ms, frame 1 at 40ms and two force-keyunit events at 10ms
and 15ms. We would create a new keyframe for both of the frames.
- 100 force-keyunit events with running-time NONE would cause all
following 100 frames to be made into a keyframe.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/684>
Also not optimal but at least simplifies the code a bit and doesn't
require g_list_length() and g_list_append() in a few places.
For 2.0 there are some more candidates to change but unfortunately
they're currently part of the API.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/683>
This means we cannot access [view layer] or view.bounds from the OpenGL
thread. This also means that we need to call the main thread when
setting the window handle. However, we cannot perform that
synchronously as that may deadlock with the application performing the
set_window_handle() call.
We need to defer the actual update and run it asynchronously and wait
for the window handle update internally at each point it is needed.
Fixes: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/372
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/681>
The gir generator wrongly assume that the vfunc
GstGLFilterClass.filter() and the method gst_gl_filter_filter_texture()
are related. As a result it complains about not matching argument names.
Workaround this by naming both of their arguments input and output.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/664>
the old manner does not consider the profile idc. The profile idc should
play an more important role in recognizing the profile than the other
information. And there is no need to mix profiles of different extensions
together to find the closest profile when the bits stream is not standard,
different extensions support different features and should not be mixed.
The correct way should be recognize the extension category by profile idc
firstly, and then find the closest profile.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/645>
GstH265FormatRangeExtensionProfile declares the common bits used
for not only format range extensions profiles, but also for several
different h265 extension profiles, such as high throughput, screen
content coding extensions, etc. And So the old name is not proper.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/645>
If there are two elements and threads attempting to query each other for
an OpenGL context. The locking may result in a deadlock.
We need to unlock each element's context_lock when querying another
element for the OpenGL context in order to allow any other element to
take the lock when the other element is querying for an OpenGL context.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/642>
When receiving an instant-rate-change event, store the updated
seek flags and replace the flags in any input segments with them
to allow for instant switching between trickmodes and not.
When receiving an instant-rate-change event, store the updated
seek flags and replace the flags in any input segments with them
to allow for instant switching between trickmodes and not.
It's possible that a buffer might be within the segment proper,
but not within the "valid" part we're playing, which is only
things after the 'offset' part of the segment. In that case,
the running-times of the buffer-start and buffer-stop will be
GST_CLOCK_TIME_NONE, and we'd better not schedule playback that
far in the future.
This commit modifies GstVideoMasteringDisplayInfo and GstVideoContentLightLevel
structs so that each value is to be more like hdr_metadata_infoframe struct
of linux drm header and DXGI_HDR_METADATA_HDR10 struct of Windows.
So each value is no more fraction but normalized one as per CTA 861.G spec.
Also the unit of each value will be consistent with H.264, H.265
specifications, hdr_metadata_infoframe struct for linux and
DXGI_HDR_METADATA_HDR10 struct for Windows.
[38/1301] Generating GstVideo-1.0.gir with a custom command.
../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideoaggregator.c:231: Error: GstVideo: identifier not found on the first line:
*
^
Because the color value is stored in MSB, so we can reuse the
Y210 code for P012_LE / P012_BE
Sample pipeline:
gst-launch-1.0 videotestsrc ! video/x-raw,format=Y212_LE ! glimagesink
This can be used to have compositor display either the background
or a stream on a lower zorder after a live input stream freezes
for a certain amount of time, for example because of network
issues.
gst_gl_window_quit() will attempt to send a message but will be called
from GstGLContext's finalize handler and so the weak ref that backs
gst_gl_window_get_context will return NULL as it has already been
cleared. We need that context in send_message_async to decide whether
to run the provided callback immediately or queue in GCD
Without this fix, it is possible that outbuf is not initialized, which
will result in segfault when call gst_buffer_replace (&outbuf, NULL). In
addition, the patch fixes potential memory leak in restart path.
The segfault can be reproduced by the pipeline below:
GST_GL_PLATFORM=egl \
gst-launch-1.0 videotestsrc ! msdkh265enc ! msdkh265dec ! \
'video/x-raw(memory:DMABuf)' ! glimagesink
In the situation that the direct dmabuf path is chosen, but with an
unsupported texture format, this causes accept to fail rather than
continue and fail at the upload stage. It is also possibly necessary to
reconfigure after falling back from direct to non-direct dmabuf upload
paths.
