This allows subclasses that notice missing reference frames to request a
new sync point to allow seamless decoding again. While doing so the
subclass can also signal whether it wants a) all following input frames
until the sync point to be discarded or b) all output frames until the
sync point to be marked as corrupt.
Sending of force-keyunit events for this can be throttled by the
application via the "min-force-keyunit-interval" property.
This replaces custom behaviour for the same in various decoders, for
example openh264dec.
Based on patches by Haakon Sporsheim <haakon@pexip.com> and
Stian Selnes <stian@pexip.com>.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
If the first frame(s) at the very beginning or after a flush are not a
sync point then the base class would discard them before passing them to
the subclass.
This also fixes the previously broken distance_from_sync handling: it
was never reset at sync points.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
This can be used by applications to configure decoders so that corrupted
frames are directly discarded instead of being forwarded inside the
pipeline. It is a replacement for the "output-corrupt" property of the
ffmpeg decoders.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
This can be used by subclasses to mark output frames as known to be
corrupted, for example if reference frames were missing. ffmpeg's
decoders can signal this.
In addition this flag is propagated downstream if the input frame had it
set.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/730>
This is not actually required (anymore?). Source pad caps can be
negotiated at any time regardless of any configured (or existing) sink
pads and videoaggregator comes up with some fixated caps based on the
downstream caps.
Subclasses can override this behaviour as needed by overriding
update_src_caps().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/793>
`gst_gl_memory_read_pixels` reads pixels from `GLMemory` into the
pointer, effectively writing to it. This is opposite from
`gst_gl_memory_texsubimage` which reads texture data from `read_pointer`
into `GLMemory`.
Both cases are clarified by changing `read_pointer` to `write_pointer`,
and explaining what `gst_gl_memory_texsubimage` does in addition to
referring back to `gst_gl_memory_read_pixels`.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/806>
These then don't require going through the generic code path via AYUV64
first but can be converted directly.
This speeds up processing of
videotestsrc ! v210 ! videoconvert ! other_format ! fakesink
by a factor of 1.55 for I420/YV12 and 1.40 for the other destination
formats and reduces memory pressure considerably.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/775>
The type is called GstVideoTransferFunction so the function names should
match, otherwise gobject-introspection is keeping the functions as
global functions instead of methods on the type.
The same mistake was also made in lots of other APIs over the years, but
here we can at least fix it for 1.18 still.
Thanks to Marijn Suijten for noticing.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/807>
For audio we copy metas that have no tags at all, or that only have the
"audio" and/or "audio-channels" tag. Audio codecs don't change the
audio aspect of the stream and in almost all cases don't change the
number of channels. They might however change the sample rate (e.g.
Opus). Subclasses that change the number of channels will have to
override ::transform_meta() accordingly.
For video we copy metas that have no tags at all, or that only have the
"video" and/or "video-size" and/or "video-orientation" tag. Video codecs
don't change the "video" aspect of the stream and in almost all cases
don't change the resolution or orientation. Subclasses that rescale or
change the orientation will have to override ::transform_meta()
accordingly.
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/576#note_610581
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/801>
Some languages have an ISO 639-2 representation but no 639-1
representation, for example where "eng" has a two-letter
equivalent in "en", "enm" doesn't have one.
Discarding those languages from our static table caused functions
such as gst_tag_get_language_code_iso_639_2T() or
gst_tag_get_language_code_iso_639_2B() to return NULL for
valid language codes such as "enm", potentially causing users
of these API such as mpegtsmux to discard language code tags
as invalid.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/785>
Call gst_aggregator_selected_samples() after filling the queues
(but before preparing frames).
Implement GstAggregator.peek_next_sample.
Add an example that demonstrates usage of the new API in combination
with the existing buffer-consumed signal.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/728>
5 seconds might not be enough value for timeout in case an application
is running on a device with very limited computing power.
Note that ANGLE uses 10 seconds timeout value. So even if a timeout
happens here, it's also ANGLE's timeout condition as well
(meaning that bad things will happen either way)
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/769>
It was not working properly and the implementation of the smartencoder
element was weird. This introduce a number of changes (which are all
in one single commit because they basically all work together and lead
to basically reimplementing the element):
* Make smartencoder a bin so that the reencoding chain of elements are
inside of it instead of not having any parent. Those elements were not
be visible when dumping the pipeline which was very confusing.
* Make encodebin create the right encoder with a capsfilter (and parser)
to properly enforce the format specified by the user, and so that the
encoder properties specified in the encoding profile are respected.
* Use `decodebin` to do the decoding instead of selecting a decoder
ourself and not plug any parser etc...
* Ensure that negotiated format in the sinkpad of smart encoder is fixed
through time when the user requested a non dynamic output
* Add a parser at the beginning of the smart encoder
* Handle errors when reencoding
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/751>
This adds linear 32x32 NV12 based tiles. This format is notably used by
Allwinner VCU and exposed in V4L2 as being "SUNXI Tiled" format. In this
patch we generalize the plane info calculation so we can share this part
with the 4L4 variant.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/754>
All UI elements will follow Single-Threaded Apartments (STA) model.
As a result, we should access them from dedicated UI thread.
Due to the nature of the threading model, ANGLE will wait the UI
thread while closing internal window/swapchain objects.
A problem here is that when destroying GstGLWindow from the UI thread,
it will wait GstGLContext's internal thread. Meanwhile, the GstGLContext's
internal thread will be blocked because ANGLE wants to access the UI thread.
That will cause a deadlock or exceptions.
In short, application should not try to call
gst_element_set_state(pipeline, GST_STATE_NULL) from a UI thread.
That's a limitation of current implementation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/745>
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>
