test_negotiation would occasionally time out, for unknown reasons.
Simplify the test setup and get rid of the main loop, busses, and
notify signals. With this I can no longer easily reproduce the
timeout. Fingers crossed.
These are very much artificial of course, but got to
measure something. appsink one contains lots of buffer
creation/free overhead, while appsrc one does not.
We can either receive an element that is floating or not and need to
accomodate that in the signal return values. Do so by removing the
floating flag.
https://bugzilla.gnome.org/show_bug.cgi?id=792597
It does not timeout anymore, even though it's a very slow test. For the
context, this test runs routines for a fixes amount of time and prints
the throughput. Which means the test takes more time everytime a pixel
format is added. If that becomes a problem again, we should disable the
benchmarks by default.
Need to add gio-unix-2.0 dep to pipelines/tcp test otherwise it
won't find the gio/gunixfdmessage.h header which is not in the
same dir as the other gio headers. This issue was masked before
because we didn't include config.h so HAVE_GIO_UNIX_2_0
wasn't defined.
In many cases the unistd.h includes weren't actually needed.
Don't build tests that need it on windows with MSVC
(multifdsink, multisocketsink, pipelines/tcp).
Preparation for making tests work on Windows with MSVC.
Some GL platforms (EGL, WGL) require deactivating the OpenGL context in
one thread before it can be used in another thread which this test
currently violates and would e.g. result in EGL_BAD_ACCESS errors from
gst_gl_context_activate().
Fix by moving the object creation into the GL thread instead and not
requiring additional gst_gl_context_activate() calls.
https://bugzilla.gnome.org/show_bug.cgi?id=792158
If timestamp goes forwards more than allowed, we consider that the
timestamp belongs to the previous counting, so the extended timestamp
is unwrapped.
https://bugzilla.gnome.org/show_bug.cgi?id=783443
Tests and documentation will follow separately.
The mixer elements in the opengl plugin need to stay
in -bad for now since they use GstVideoAggregator.
https://bugzilla.gnome.org/show_bug.cgi?id=754094
The client-draw callback is running on the GL Thread, which will
be required to map the buffer. Map early, and pass the mapped
frame instead. On top of that, make sure to signal any pending
draw before trying to push EOS, as some pad locks might be taken.
This is the cost of using the same thread to control GStreamer and
to render GL.
Except for gst/gl/gstglfuncs.h
It is up to the client app to include these headers.
It is coherent with the fact that gstreamer-gl.pc does not
require any egl.pc/gles.pc. I.e. it is the responsability
of the app to search these headers within its build setup.
For example gstreamer-vaapi includes explicitly EGL/egl.h
and search for it in its configure.ac.
For example with this patch, if an app includes the headers
gst/gl/egl/gstglcontext_egl.h
gst/gl/egl/gstgldisplay_egl.h
gst/gl/egl/gstglmemoryegl.h
it will *no longer* automatically include EGL/egl.h and GLES2/gl2.h.
Which is good because the app might want to use the gstgl api only
without the need to bother about gl headers.
Also added a test: cd tests/check && make libs/gstglheaders.check
https://bugzilla.gnome.org/show_bug.cgi?id=784779
