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.
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
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
- Add overlay video renderer "video-sink" property, so that can be set
- In create_video_sink, it returns video sink instead of always NULL
- Add new renderer_new_with_sink() API to set video sink
https://bugzilla.gnome.org/show_bug.cgi?id=776490
'extern inline' was added in 2fb76c89 for MSVC (it was just
'inline' before), but all of this doesn't really make sense,
the functions are not going to be inlined anyway, and what
'extern inline' means exactly also appears to depend on the
Cxx standard targetted. Let's just remove the 'extern inline'
entirely. At least gcc6 still emits the exact same code as
before anyway. Fixes compilation/linking with gcc 4.8 as
used on L4T on the TK1.
The reason we previously used queue2 was to calculate the download rate,
but that wasn't entirely correct and we therefore calculate it before
queue2. We therefore now just need a simple queue.
../../../../gst-libs/gst/gl/gl.h:57:45: fatal error: gst/gl/gstglcontrolbindingproxy.h: No such file or directory
#include <gst/gl/gstglcontrolbindingproxy.h>
^
No-one's using/depending on it (it would have criticalled and not worked)
and it's causing more problems than it's solving. Store the GMainContext
in the public struct instead for subclasses to optionally use instead of
relying on the push/pop state to be correct.
https://bugzilla.gnome.org/show_bug.cgi?id=775970
This is potentially racy (in the unlikely scenario that we get two
first-time calls to gst_player_error_quark() at the same time). This
should not impact anything in terms of performance since it's only on
the error path.
The call itself could just be inlined by making GST_PLAYER_ERROR be
defined to the g_quark_from_static_string() call, but this feels ugly
from an API perspective.
If a sub class of GstGLContext does not create a group
then it currently crashes:
0 g_atomic_int_get (&share->refcount)
1 _context_share_group_is_shared (context->priv->sharegroup)
2 gst_gl_context_is_shared
3 _default_set_sync_gl
https://bugzilla.gnome.org/show_bug.cgi?id=774518
This is a subblass of VideoFilter but yet does not use any of it's
features. This also fixes issue in case the incoming images have custom
strides as the VideoMeta is no longer ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=775288
When a MSS server hosts a live stream the fragments listed in the
manifest usually don't have accurate timestamps and duration, except
for the first fragment, which additionally stores timing information
for the few upcoming fragments. In this scenario it is useless to
periodically fetch and update the manifest and the fragments list can
be incrementally built by parsing the first/current fragment.
https://bugzilla.gnome.org/show_bug.cgi?id=755036
Calling g_main_context_push_thread and then g_main_context_invoke()
(used by gst_gl_window_send_message_async()) in the same thread will
cause the invoked function to run immediately instead of being delayed.
This had implications for the creation of the OpenGL context not waiting
until the main loop had completely started up and as a result would
sometimes deadlock in short create/destroy scenarios.
https://bugzilla.gnome.org/show_bug.cgi?id=775171
626bcccff9 removed some locks that
allowed the main loop quit to occur before the context was fully
created.
2776cef25d attempted to readd them but
missed the scop of the quit() call.
Also remove the use of g_thread_join() as that's not safe to use when
it's possible to lose the last reference from the GL thread.
https://bugzilla.gnome.org/show_bug.cgi?id=775171
The smallest section ever needs to be at least 3 bytes (i.e. just the short
header).
Non-short headers need to be at least 11 bytes long (3 for the minimum header,
5 for the non-short header, and 4 for the CRC).
https://bugzilla.gnome.org/show_bug.cgi?id=775048
It's been removed and thus compiling anything against GstGLMemoryEGL
would error with:
In file included from gstomxvideodec.c:41:0:
usr/include/gstreamer-1.0/gst/gl/egl/gstglmemoryegl.h:32:41: fatal error: gst/gl/egl/gstglcontext_egl.h: No such file or directory
#include <gst/gl/egl/gstglcontext_egl.h>
^
https://bugzilla.gnome.org/show_bug.cgi?id=774886
Otherwise, when the application reuses the same UIView, we were getting
draw notifications on the previous view/layer's which weren't valid anymore
and were referencing pointers that had been freed.
https://bugzilla.gnome.org/show_bug.cgi?id=753003
This changes the failure case to require a consecutive number of
failures rather than being spread out over the entire stream.
Fixes the case where fetching the manifest was intermittent.
https://bugzilla.gnome.org/show_bug.cgi?id=774177
For formats that need to update the manifest to know about new
fragments as they're being written by the server would never receive an
updated fragment list after a seek event
https://bugzilla.gnome.org/show_bug.cgi?id=774177
- xcb is supposedly thread-safe!
videotestsrc ! glimagesink now doesn't spuriously result in a
'call XInitThreads()' error however if anybody else is using X11,
then XInitThreads() still needs to be called and multiple glimagesink's
still need XInitThreads().
Everything still takes libX11 handles as they are compatible with the xcb
variants. Unfortunately we cannot move fully over to xcb due to GLX being
entirely based on Xlib. It's also impossible to transform a xcb_connection
to a Display which means we require X11 handles.
