- 30 Oct, 2018 2 commits
-
-
Zeeshan Ali authored
-
Zeeshan Ali authored
Otherwise, last line can be lost.
-
- 28 Oct, 2018 3 commits
-
-
-
Jan Schmidt authored
If a segment has stop == -1, then gst_segment_to_running_time() would refuse to calculate a running time for negative rates, but gst_segment_do_seek() allows this scenario and uses a valid duration for calculations. Make the 2 functions consistent by using any configured duration to calculate a running time too in that case. https://bugzilla.gnome.org/show_bug.cgi?id=796559
-
-
- 26 Oct, 2018 1 commit
-
-
Sebastian Dröge authored
It's not a warning if an URI doesn't have an extension, and it's also not mandatory that sources have an URI or even answer the URI query.
-
- 23 Oct, 2018 2 commits
-
-
GST_TIME_FORMAT, GST_TIME_ARGS, GST_STIME_FORMAT, GST_STIME_ARGS GST_PTR_FORMAT, GST_SEGMENT_FORMAT, GST_FOURCC_FORMAT and GST_FOURCC_ARGS are format specifiers. They can't be used outside of C and should be generated in the gir. https://bugzilla.gnome.org/show_bug.cgi?id=797320
-
GST_ERROR_SYSTEM can't really be used outside of C and should be skipped. https://bugzilla.gnome.org/show_bug.cgi?id=797320
-
- 22 Oct, 2018 2 commits
-
-
Since we use full signed running times, we no longer need to clamp the buffer time. This avoids having the position of single queues not advancing for buffers that are out of segment and never waking up non-linked streams (resulting in an apparent "deadlock").
-
If we ever get a GST_FLOW_EOS from downstream, we might retry pushing new data. But if pushing that data doesn't return a GstFlowReturn (such as pushing events), we would end up returning the previous GstFlowReturn (i.e. EOS). Not properly resetting it would cause cases where queue2 would stop pushing on the first GstEvent stored (even if there is more data contained within).
-
- 17 Oct, 2018 1 commit
-
-
Olivier Crête authored
Use the test clock instead of using a real one to make it easier to run in valgrind. https://bugzilla.gnome.org/show_bug.cgi?id=797291
-
- 16 Oct, 2018 1 commit
-
-
Tim-Philipp Müller authored
-
- 15 Oct, 2018 2 commits
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- 12 Oct, 2018 2 commits
-
-
Philippe Normand authored
Using the MEDIA_ classifier prefix was inappropriate. It is sufficient to specify the additional klass name that element can set in their metadata. (follow-up of commit ca4b61c5) https://bugzilla.gnome.org/show_bug.cgi?id=796921
-
Philippe Normand authored
The Harware factory type classifier allows elements (decoders and encoders, mostly) to advertize they rely on hardware devices to perform encoding or decoding operations. This classifier can be used by applications to filter and select only the elements that use hardware devices, for instance to ensure zero-copy support is enabled for a specific pipeline. https://bugzilla.gnome.org/show_bug.cgi?id=796921
-
- 11 Oct, 2018 5 commits
-
-
Jan Schmidt authored
Previously, with opportunistic sync we'd track a master clock as soon as we see a SYNC message, and hence sync up faster, but then we'd announce we're synched before seeing the ANNOUNCE, leaving the clock details like grandmaster-clock empty. A better way is to start tracking the clock opportunistically, but not announce we're synched until we've also seen the ANNOUNCE.
-
Jan Schmidt authored
Log message arrival times. Fix a typo in one debug string
-
Jan Schmidt authored
The follow-up and delay-resp messages carry precise timestamps for the arrival at the clock master, but the local return time is unimportant, so we should be very lenient in accepting them late. Some PTP masters don't prioritise sending those packets, and we reject all the responses and never sync - or take forever to do so. Increase the tolerance to 20x the mean path delay. Also fix a typo in one debug output that would print the absolute time of the delay-resp message, not the offset from the delay-req that it's actually being compared against.
-
Jan Schmidt authored
Add some debugging to be able to tell what is happening inside the PTP clock protocol handling.
- 07 Oct, 2018 1 commit
-
-
- 03 Oct, 2018 3 commits
-
-
-
Thibault Saunier authored
Setting it to "unspecified-system-id".
-
In some cases the system protection ID is not present in the contents or in their metadata. This define is used to set the value of the "system_id" field in GstProtectionEvent, with this value, the application will use an external information to choose which protection system to use. Example: The matroskademux uses this value in the case of encrypted WebM, the application will choose the appropriate protection system based on the information received through EME API. https://bugzilla.gnome.org/show_bug.cgi?id=797231
-
- 27 Sep, 2018 4 commits
-
-
Vivia Nikolaidou authored
gst_queue_array_clear will clear the GstQueueArray, gst_queue_array_set_clear_func will set a clear function for each element to be called on _clear and on _free. https://bugzilla.gnome.org/show_bug.cgi?id=797218
-
Mathieu Duponchelle authored
-
Mathieu Duponchelle authored
This is exposed as a solution to the use case of plugging in sources with a higher latency after the aggregator has started playing with an initial set of sources, allowing to avoid resyncing. https://bugzilla.gnome.org/show_bug.cgi?id=797213
-
Mathieu Duponchelle authored
The documentation incorrectly used to state that the pads were not automatically activated when added, whereas we actually do that when appropriate. Callers of gst_element_add_pad must not hold the object lock, which implies that they cannot perform the same checks as add_pad in a non-racy manner. This updates the documentation, and removes the g_warning that was output before performing automatic activation. https://bugzilla.gnome.org/show_bug.cgi?id=797181
-
- 24 Sep, 2018 3 commits
-
-
Tim-Philipp Müller authored
Otherwise we try to build a shared lib when we build the rest of GStreamer statically, which won't work because we pass -DGST_STATIC_COMPILATION when building statically, which means we won't dllimport public symbols from our libs which means that on Windows the unit tests will fail to link to libgstcheck. https://bugzilla.gnome.org/show_bug.cgi?id=797185
-
Tim-Philipp Müller authored
Can't mix/match imports and exports from the same library here, so just include all .c files needed instead and don't link to gstnet at all then. https://bugzilla.gnome.org/show_bug.cgi?id=797185
-
Tim-Philipp Müller authored
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 ...
-
- 23 Sep, 2018 2 commits
-
-
Tim-Philipp Müller authored
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. https://bugzilla.gnome.org/show_bug.cgi?id=797185
-
Tim-Philipp Müller authored
This is for use by the various GST_*_API decorators and will be what they get defined to when a library API is being used by external users of that library (not the library itself whilst it's being compiled). In most cases it will simply map to a plain 'extern' but on Windows with MSVC it will need to map to __declspec(dllimport). For functions this is not strictly needed, but for exported variables it is. https://bugzilla.gnome.org/show_bug.cgi?id=797185
-
- 21 Sep, 2018 1 commit
-
-
Fix build on some non-US locale Windows systems Error: gstreamer/gst/gstdebugutils.c(194): error C2001 https://bugzilla.gnome.org/show_bug.cgi?id=797186
-
- 20 Sep, 2018 1 commit
-
-
Mathieu Duponchelle authored
-
- 19 Sep, 2018 4 commits
-
-
-
Tim-Philipp Müller authored
And fix up bogus libs/ prefix for controller lib includes. https://bugzilla.gnome.org/show_bug.cgi?id=797165
-
Change to always include gst/libs/base.h in order to also include base-prelude.h, but also because it's the right thing for people to include anyway. https://bugzilla.gnome.org/show_bug.cgi?id=797165
-
Tim-Philipp Müller authored
We want this enabled by default, also in releases, but people may want to disable this for performance-critical workloads or on embedded devices.
-