It was checking for GST_IS_CAPS only and that would fail if the new
restriction caps was NULL and its documentation says it accepts NULL as
valid input.
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
Function body must only be removed if compiling with
GST_REMOVE_DEPRECATED. Function declaration must not
be skipped if GST_DISABLE_DEPRECATED is defined, since
it contains our export decorator and we wouldn't export
the symbol as public API any more then since we compile
with GST_DISABLE_DEPRECATED.
Instead of trying to guess what profile to build, just get the possible
elements to use with the specified caps and determine the
EncodingProfile from it.
https://bugzilla.gnome.org/show_bug.cgi?id=795490
Otherwise it won't be possible to specify some profiles such as
video/x-h264,profile=(string)high-4:4:4
With this patch, we can do
video/x-h264,profile=(string)high-4\:4\:4
We need different export decorators for the different libs.
For now no actual change though, just rename before the release,
and add prelude headers to define the new decorator to GST_EXPORT.
It is the only thing gst_pb_utils_init() does and it could be
automatically called from the places in pbutils it is needed.
After 1.14 we should deprecate gst_pb_utils_init().
https://bugzilla.gnome.org/show_bug.cgi?id=793611
There is a race going on somewhere when we attempt to remove elements
*while* the parent container is switching to PLAYING.
In order to avoid this issue with discoverer, make sure we never
remove elements while switching to PLAYING.
This would result in a lot of warnings regarding elements not being
in NULL state when removed, or even leaked elements.
Instead make sure we take the lock and check whether we are processing
or not before allocating or adding anything to the pipeline
And monitor no_more_pads.
With live sources such as rtsp, uridecodebin only creates its
child decodebins between PAUSED and PLAYING.
This means that the ASYNC_DONE it posts when getting NO_PREROLL
in its change_state method gets immediately propagated by the
GstBin parent class, as opposed to a situation where a
decodebin has been added to it already, and has posted ASYNC_START.
The proposed solution, instead of simply waiting for ASYNC_DONE,
and finishing prematurely in that case, waits for three conditions
to be true:
* the uridecodebin needs to have emitted no_more_pads
* its current state must be PAUSED if not live, PLAYING otherwise
* There must be no "pending subtitle pads", ie pads where we haven't
received tags yet.
All these conditions are checked in the message handler, as we
post custom messages on it when we get subtitle tags or no_more_pads.
https://bugzilla.gnome.org/show_bug.cgi?id=783257
Child streams could have more accurate width/height or various other
information added. If they have the same name, they are likely to be the
same streams.
https://bugzilla.gnome.org/show_bug.cgi?id=782697
The parser might do some conversion on a stream but the stream keeps
being the same, and we need to make sure GstDiscoverer detects it is the
case.
https://bugzilla.gnome.org/show_bug.cgi?id=778298
It is often usefull to make sure that you get a full copy of a profile.
For example you want to let the user modify it in the user interface
but still keep an unchanged version for later use.
API:
gst_encoding_profile_copy
encoding-profile.c: In function ‘get_profile_format_from_possible_factory_name’:
encoding-profile.c:1532:6: error: ‘fact’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (fact)
^
encoding-profile.c: In function ‘profile_from_string’:
encoding-profile.c:1720:6: error: ‘res’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (profile)
^
cc1: all warnings being treated as errors
Instead of enforcing the user to know and understand caps to describe
the encoding format, let him use element factory names directly.
This also makes it possible to ensure that a specific encodore/muxer
is used instead of letting the ranking system do it.
It is now possible to describe an encoding format simply specifying:
matroskamux:x264enc:vobisenc
Factor out functions in the parsing, cleaning up the whole thing.
Update documentation.
We used to only care about the name of the files even if the name
is defined in the encoding target serialized file.
That commit also allows user to define several names for a single
target file (using a ';' between the names) which allows us to have
a target for youtube that is called 'youtube;yt' or a target for
'ogg;ogv;oga' file extension.
The caps put into the stream topology by decodebin are the caps at the
moment the pads are exposed on it. This is usually before decoders
received any buffers.
In discoverer we however wait for pre-roll, which ensures that each
decoder handled buffers already. At this point, there might be more
information known about the caps already that we could make use of.
One example here is extra information stored in the SEI of H264, like
the multiview-mode. This will be known if there is a SEI before the
first keyframe, but decodebin won't put this into the topology as it
only waits for the initial caps of h264parse (which come directly after
SPS/PPS).
With this change, the multiview-mode is in the caps reported by
discoverer in many cases.
The caps might not be fixated (which is required by GstVideoInfo) and we
would assert otherwise. However the caps often contain useful
information in the already-fixed parts that we can use here.
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
parsed, framed, stream-format and alignment are only relevant for parsers and
should not matter here. We still want to be able to use an encoder that can
only output byte-stream if the input was avc.
https://bugzilla.gnome.org/show_bug.cgi?id=768566
Caps are cleaned up for missing plugins, and for creating encoding profiles
and caps descriptions.
Fields like streamheader, parsed, framed, stream-format and alignment are not
relevant here. The last ones all because a parser will take care of them.
https://bugzilla.gnome.org/show_bug.cgi?id=768566
If we e.g. have AVI with DV container with video/audio inside the DV
container, we can't handle this at this point with an encoding profile.
Instead of erroring out, flatten the container hierarchy.
https://bugzilla.gnome.org/show_bug.cgi?id=765708
When converting discoverer output to an encoding profile, it makes sense to
omit these. It's very very unlikely that our encoder is going to produce bit
by bit the same codec_data or streamheader.
https://bugzilla.gnome.org/show_bug.cgi?id=765534
