Overriding the pad query function completely overrides all the default
query handling implemented in basesrc, including caps etc. The correct
thing to do is just override the basesrc query vfunc and then chain up
for the queries we don't handle.
When the sink receives a buffer that is neither a wl_shm one nor a
dmabuf one, this buffer is copied to an internal wl_shm buffer before
being sent to the display.
In that case, the actual size of the received buffer (which may differ
from the one negotiated in the caps) must be used.
https://bugzilla.gnome.org/show_bug.cgi?id=777841
See https://bugzilla.gnome.org/show_bug.cgi?id=773666
This would ideally be solved in baseparse but that requires further
thought at this point, and in the meantime it would be good to have
rawbaseparse not assert on this but handle it gracefully instead.
The cached texture was treated as user_data passed to GstGLBaseMemory
and freed with a GDestroyNotify function. However, this data must
be treated specially: it must be destroyed in the GL thread.
https://bugzilla.gnome.org/show_bug.cgi?id=778434
Enforce exactly the same raw video format on both sides, include a
videoconvert and queue before the video sink and make the shm area a
little bit bigger so that things don't get stuck.
If we need to send EOS on a pad that hasn't prerolled, generate
an error on the bus instead, otherwise the app will have no idea.
Fixes the HLS testFragmentNotFound test, which is waiting
for either EOS or an error.
Make the unit tests handle the fact that pads don't appear
immediately. Before, the test assumed pads are exposed before the
internal source element is created, which is no longer true.
To ensure that pads have caps when they are exposed, do
the exposing when all pending streams have prerolled an
output buffer, and only then EOS and remove any old pads.
Improves the switching sequence by making caps available
as soon as a pad appears.
With fixes from Seungha Yang <sh.yang@lge.com>
https://bugzilla.gnome.org/show_bug.cgi?id=758257
Unless the video format has an alpha component (ARGB, ...), set the
video_surface opaque.
In the usual case where the black area_surface has the same size as the
video_surface (eg: run gst-play-1.0 video.mp4), this makes the black
surface totally occluded which makes weston compositor's life easier
since it can ignore that surface.
Also unconditionally set the black area_surface opaque.
https://bugzilla.gnome.org/show_bug.cgi?id=778078
and error out here already otherwise. We currently don't support
reconfiguration here and it can't happen really either unless the auto
mode is selected.
Otherwise the destructor will never be called, and we would have to call
the constructors manually at some point... which we never did, so
calling release() on it before it got otherwise initialized caused a
crash. For example when running gst-inspect-1.0.
Vulkan handles are either pointers (64-bit) or 64-bit integer
handles (32-bit). Cast the type in failure cases.
vkwindow.c:229:561: error: return makes integer from pointer without a cast [-Werror=int-conversion]
vkwindow.c:231:194: error: return makes integer from pointer without a cast [-Werror=int-conversion]
https://bugzilla.gnome.org/show_bug.cgi?id=777979
send_event() of parent class (i.e., GstBinClass) iterates srcpads
to send SEEK event. And performing it per srcpad is inefficient.
So, let's drop duplicated SEEK event by checking seqnum
https://bugzilla.gnome.org/show_bug.cgi?id=776612
To satisfy follwing restriction of HLS spec 6.3.3,
select startup fragment sequence to 4th from end of playlist.
Also, seek range should exclude last three fragment in playlist.
"the client SHOULD NOT choose a segment which starts less than
three target durations from the end of the Playlist file."
https://bugzilla.gnome.org/show_bug.cgi?id=777682
hls live starts playback from the allowed latest fragment,
but its "sequence position" is set to zero, and so stream
time is also set to zero.
This does not make sense, because hls live allows seeking to past position,
and it's negative stream time from downstream element's point of view.
Note that, allowed seekable range (and seeking query) is
from the first fragment of playlist to the allowed latest fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=777682
HLS spec 6.3.3 is saying that
"the client SHOULD NOT choose a segment which starts less than
three target durations from the end of the Playlist file."
To ensure above statement, the third fragment from the end of playlist
should be excluded from seekable range and also from available starting fragment.
(i.e., the fourth fragment from end of playlist is the starting fragment).
https://bugzilla.gnome.org/show_bug.cgi?id=777682
During live playback, the first fragment in a updated
playlist can be advanced from that of startup playlist.
Meanwhile, since hlsdemux finds target seek position
by just accumulating fragment's duration, the base should
be adjusted to the updated first fragment's timestamp.
https://bugzilla.gnome.org/show_bug.cgi?id=777682
