Changes are:
- Use the wrapper functions to access opaque data types. To preserve
backward compatibility, define fallback definitions
- Remove the use of idiom "pqueue_size(ssl->d1->sent_messages)", since
there is no replacement
- Use RSA_generate_key_ex instead of the deprecated RSA_generate_key
https://bugzilla.gnome.org/show_bug.cgi?id=773540
rawvideoparse wouldn't error out on not-negotiated,
but would just keep on going, because it didn't pass
the flow return value back to the parent class and
thus upstream, so the source wouldnt' stop streaming.
The change to use GST_EXPORT for symbols under Windows requires
GST_EXPORTS for internal use, and that is also needed under Autotools.
The same thing is done for gstreamer-1.0.dll in -core.
The calling convention may be deprecated, but we still need it for
OpenGL. The build issue was caused by an incorrect syntax being used for
the WINAPI (__stdcall) prototype in function pointers which was accepted
by GCC but is rejected by MSVC.
It was always wrong since the symbols being exported in gstgl-1.0.dll
are platform-specific, and the check we do in dist checks it on all
platforms (which usually means Linux) and the list is instead
Linux-specific right now.
Even if we fix that, it can still never be right because it depends on
your configuration even on a specific platform. For instance, when we
start building EGL support on Windows using ANGLE, the symbol list will
change depending on whether that is enabled or not.
We also don't need this anymore since we use GST_EXPORT for all
functions exported on Windows now.
MSVC warns about this because it's a C++ compiler, and this actually
results in useful things such as the incorrect 'gboolean' return value
for functions that return GstFlowReturn, so let's do explicit
conversions to reduce the noise and increase its efficacy.
With MSVC, this gives the following warning:
warning C4305: 'function': truncation from 'double' to 'gfloat'
Apparently, MSVC does not figure out what type to use for constants
based on the assignment. This warning is very spammy, so let's try to
fix it.
The error is:
unary minus operator applied to unsigned type, result still unsigned
This is a commonly-done operation in gstreamer and it's done on purpose.
It's just noise.
The headers we include already define boolean on Windows with MSVC, and
it leads to a typedef redefinition error with jpeglib.h which tries to
redefine it in jmorecfg.h
At minimum, we only need to glFlush() if we are in a shared GL context
environment. Move the glFinish() to when the actual wait is requested
which may be never. Improves the throughput on older GL systems without
GL3/GLES3 and/or fence sync objects.
In file included from ../subprojects/gst-plugins-base/gst-libs/gst/video/video.h:27:0,
from ../subprojects/gst-plugins-bad/gst/segmentclip/gstvideosegmentclip.c:25:
../subprojects/gst-plugins-base/gst-libs/gst/video/video-format.h:27:39: fatal error: gst/video/video-enumtypes.h: No such file or directory
#include <gst/video/video-enumtypes.h>
^
compilation terminated.
https://ci.gstreamer.net/job/GStreamer-master-meson/269/console
In M2TS mode, we need an extra 4 bytes in the buffer, so need
to ensure the buffer can contain these. The allocation site
does not know the mode, so this is done in all cases.
* Rephrase tune error to be delsys-neutral
* Refer to the actual check in the 'missing sanity check' warnings
* Use "Delivery system" instead of 'delsys'. The
latter is OK as a shorthand in the code but not
even a real word
This was a regression.
We only have a upstream-id via STREAM_START if we were in push-mode.
In pull-mode we need to create one.
Note: It would be good to eventually have that method (copied from
gst_pad_get_stream_id_internal()) public in the future
For each MpegTSBaseStream, we have a GstStream object which
subclasses can extend with information.
For each program a GstStreamCollection is created with all
GstStream from each stream.
