For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.
What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.
While we're at it, add new GST_API_EXPORT in config.h and use
that for GST_*_API decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
When the position query fails the returned value shall remain -1 instead of 0 to
avoid confusion on application side between error and beginning of media.
https://bugzilla.gnome.org/show_bug.cgi?id=797066
Move the errant piece of dtlssrtpenc state change
management from dtlstransport in the Webrtc libs,
into the transportsendbin that does the rest of
the element management so it's all in one place.
It is completely legal to have packets with zero sizes.
Zero-sized packet indicates header with only Start Code.
One eg: is user data packet. The patch allows having
GstMpegVideoPacket with zero sizes.
https://bugzilla.gnome.org/show_bug.cgi?id=796477
If connection-speed property is in use, this value should be used as the
current download rate since subclasses might read it to figure out
which playlist variant they will use.
https://bugzilla.gnome.org/show_bug.cgi?id=784592
Regardless of LIVE or VOD, "a manifest has next period but
currently EOSed" state is meaning that it's time to advance period.
Previous behavior of adpativedemux, however, was able to period
advancing only for VOD case, since the adaptivedemux tried to
update and wait new manifest without respecting existence of the next period.
https://bugzilla.gnome.org/show_bug.cgi?id=781183
This moves all the conversion related code to a single place, allows
less code-duplication inside compositor and makes the glmixer code less
awkward. It's also the same pattern as used by GstAudioAggregator.
This is only used for caching reasons and should never actually be in
the public API. If this is ever a bottleneck later, caching around a
class private struct could be implemented.
The aggregated_frame is now called prepared_frame and passed to the
prepare_frame and cleanup_frame virtual methods directly. For the
currently queued buffer there is a method on the video aggregator pad
now.
