The correct way to determine the byte offset at a certain yoffset
in a subsampled component is to shift the yoffset by the component's
hsub
This fixes out-of-bounds memory accesses and visible artefacts,
example pipeline with the samples from #802:
gst-launch-1.0 compositor name=vmixer sink_1::xpos=1910 sink_1::ypos=1080 ! \
videoconvert ! videorate ! xvimagesink \
filesrc location=VID_20200723_203606.mp4 ! decodebin name=demux1 ! \
queue ! videoflip method=vertical-flip ! vmixer. \
filesrc location=bridgeoverstubbledwater.mp4 ! decodebin name=demux2 ! \
queue ! vmixer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/988>
This was only taken care of previously if there was a decoder before.
However if previously a decoder was not needed then the ghostpad
would've been linked directly to the slot's srcpad.
Reconfiguring the slot requires this to be undone so that linking can
happen normally.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/985>
Fix the following build failure with gcc 4.8 which has been added with
d268c193ad:
../gst-libs/gst/video/gstvideoaggregator.c: In function 'gst_video_aggregator_init':
../gst-libs/gst/video/gstvideoaggregator.c:2762:3: error: 'for' loop initial declarations are only allowed in C99 mode
for (gint i = 0; i < gst_caps_get_size (src_template); i++) {
^
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/974>
libvisual api expects a priv data pointer to be passed, though we know its
going to be `GstDebugLevel`.
```
../subprojects/gst-plugins-base/ext/libvisual/plugin.c:33:39: error: cast to smaller integer type 'GstDebugLevel' from 'void *' [-Werror,-Wvoid-pointer-to-enum-cast]
GST_CAT_LEVEL_LOG (libvisual_debug, (GstDebugLevel) (priv), NULL, "%s - %s",
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/975>
First: the buffer is pushed on the encoding filesink only *after* the
checkpoints, leading to wrong ordering in expectations.
The second one is about EOS being posted on the bus *before* the
stop action is executed, leading to the action never being executed.
That action was plain useless as the default behavior of validate
scenario is to internally create a "stop" action on EOS (unless
disabled by user).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/968>
Add a way for applications to specify that the underlying file is
growing which implies that the source won't EOS when reaching the end
of the file but instead start monitoring it and start reading it again
whenever a change is detected.
Also add a validate test to check the behavior
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/937>
We've been allowing only a few known chroma-site values such as
jpeg (not co-sited), mpeg2 (horizontally co-sited) and
dv (co-sited on alternate lines). That's insufficient for
representing all possible chroma-site values. By this commit,
we can represent any combination of chroma-site flags.
But, an exception here is that any combination with
GST_VIDEO_CHROMA_SITE_NONE will be considered as invalid value.
For any combination of chroma-site flags,
gst_video_chroma_to_string() method is deprecated in order to
return newly allocated string via a new gst_video_chroma_site_to_string()
method. And for consistent API naming, gst_video_chroma_from_string()
is also deprecated. Newly written code should use
gst_video_chroma_site_from_string() instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/927>
audiobasesrc's setcaps contains an optimization that makes it not re-
acquire the ringbuffer if the caps have not changed. However, it doesn't
check if it has successfully acquired it or not. It's possible to have
the caps set but not having ringbuffer acquired if the previous attempt
to acquire fails.
This commit replaces the caps existence check with whether the
ringbuffer is acquired or not. There's no need to check for caps
existence because 1.) it's unlikely to be NULL if the ringbuffer is
acquired, and 2.) _setcaps shouldn't be called with a NULL caps.
This should also let the element retry on acquiring ringbuffer after an
error by re-setting the element's state to READY and back to PLAYING.
Whether this behavior is correct is up for debate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/512>
The sink_query just uses context, other_context and display to query info.
But all these objects can be changed or distroyed in state_change() func
and other places.
This patch is not very perfect. The condition race still exists in other
places in this element. All the functions directly access these objects
without protection. Most of them are executed when the data is pushing and
draw context/window have already been established, so they should not have
problems. But the sink_query and propose_allocation functions are the query
-like functions and executed in query context, which can be called in any
state of the element. So it can cause some crash issues because of destroyed
context object.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/922>
New signals are added for managing the internal list of rtp header
extension implementations read by a specific depayloader instance.
If the 'extmap-$NUM' field is present in the src caps, then an
extension implementation will be requested but is not required to be able
to negotiate correctly. An extension will be requested using the
'request-extension' signal if none could be found internally.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/748>
New signals are added for managing the internal list of rtp header
extension implementations read by a specific depayloader instance.
If the 'extmap-$NUM' field is present in the sink caps, then an
extension implementation will be requested but is not requited to be
able to negotiate correctly. An extension will be requested using the
'request-extension' signal if none could be found internally.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/748>
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/681
added a layoutSubViews, which never gets called, because it should have been
called layoutSubviews (non-capital "v"). However after fixing that, it still
doesn't work correctly, because window_width/height values are immediately
updated and then draw_cb will never trigger the resize path, because the
values are already up to date.
Update the values inside the resize path again instead, so the check for
entering the resize path is logically always correct.
This makes the layoutSubviews unnecessary, as it only updated the internal
size values prematurely, so it is deleted instead of method naming fixed.
These changes were originally done to avoid accessing UIKit objects on the
main thread, but no additional accesses are added here, only internal
private variable assignments under the same draw_lock, so there should be
no threading issues reintroduced.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/945>
A CGSize contains CGFloat values (a typedef to double or float), which means
that the values aren't equal, despite it being equal after they are cast to
int by assigning them to window_height/width private members. This leads to
excessive gst_gl_window_resize calls on each frame, at least if the CGFloat
value has a .5 decimal value, e.g. 103.5.
Fix it by storing them as CGFloat instead of gint.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/945>
Instead of going through the list of known muxers go ahead and
instantiate the muxer specified as 'preset name' as this specifies
the exact element factory name to use.
Currently max-errors gets set during init to default or via property.
However, if a decoder element calls gst_audio_decoder_reset with 'full'
argument set to TRUE, it would result in all the fields of context being
zeroed with memset. This effectively results in max-errors getting a
value of 0 overriding the default or user requested value set during
init.
This would result in calls to GST_AUDIO_DECODER_ERROR which track error
counts and allow max-errors, to be ineffective.
To fix this move max-errors out of GstAudioDecoderContext, as changes to
context should not affect this. The error_count is anyways also in
GstAudioDecoderPrivate and not in context.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/946>
The XV_COLORSPACE attribute exists on some Xv adapters, with the same
semantics as the XV_ITURBT_709 attribute that was already supported.
A value of 0 is bt601, and 1 is for bt709 colorspace.
Fixes color shifting issues displaying bt709 content on some Xv
adapters.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/941>
