- Oct 21, 2020
-
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
Tim-Philipp Müller authored
-
- Oct 20, 2020
-
-
Tim-Philipp Müller authored
From 59cb678 to a825d27
-
- Oct 13, 2020
- Oct 12, 2020
-
-
e.g. on 32-bit arm, we may have armv6, armv7l, armv7hf, etc which all generally have the same layouts. cpu_family() groups all of these into just 'arm' that the ABI check table is expecting. Part-of: <gstreamer/gstreamer!671>
-
- Sep 26, 2020
-
-
Going through each state on the way back down to GST_STATE_NULL can cause deadlocks, for example: gst-launch-1.0 audiotestsrc ! valve drop=true ! autoaudiosink ctrl + C Hangs forever when going to PAUSED, because the "final" state is ASYNC, and the sink blocks waiting for a preroll buffer. Going straight to NULL addresses this issue, and also helps making teardown faster when piping sparse streams to a sync sink. Part-of: <!519>
-
- Sep 25, 2020
-
-
The returned ratio can be bigger than GST_SECOND, in which case we would forever return 0 for the system clock time. Even in other cases if it's close to GST_SECOND it would result in accuracy loss. Instead of doing the division by GST_CLOCK_TIME_NONE during initialization once, do it every time the clock time is requested. Fixes #575 Part-of: <!635>
-
There can only be a single waiter: on the streaming thread. Part-of: <!397>
-
... and immediately return FLUSHING from the streaming thread instead of waiting potentially forever. Fixes gstreamer/gstreamer#516 Part-of: <gstreamer/gstreamer!397>
-
- Sep 24, 2020
-
-
Since the commit https://gitlab.gnome.org/GNOME/glib/-/commit/01c02ac08b682de622930b1278c9c14d0ffe6c49, g_usleep(1) will be translated to Sleep(1) on Windows which means sleep in 1 millisecond. But GLib provides g_thread_yield() API which is exactly what we required here for thread context switching. Part-of: <!644>
-
Subsequent lookups in the hashtable are probably better done on memory we're confident is allocated to us :) It was easy to trigger invalid reads by calling gst_meta_register with dynamically allocated memory, freeing that memory, then calling gst_meta_get_info() Part-of: <!647>
-
Subclasses use the pad segment to determine whether a buffer should be skipped, we thus don't want to check if a buffer needs to be skipped before processing the segment it's part of. Part-of: <gstreamer/gstreamer!646>
-
Print target CPU we're building for. Part-of: <!645>
-
The global seqnum variable wasn't actually increased in the fallback code path, leading to all buffers getting a seqnum of 0. Which also made the unit test fail. This affects platforms/toolchains that don't have 64-bit atomic ops such as when compiling for armv7 rpi. Part-of: <gstreamer/gstreamer!645>
-
In case a plugin filename was renamed with the plugin being in the registry cache the features were not loaded after the rename: 1) Cache of old/gone filename was loaded, features added 2) New filename was loaded, features where not added because they were already found in the registry. 3) In the end stale cache entries for files which are no longer there are removed, including the wanted features. 4) The cache gets updated without the features. Fix this by also checking at (2) that the found feature is from the loaded plugin and not from some stale cache entry. This affected directsoundsink where libgstdirectsoundsink.dll was renamed to libgstdirectsound.dll, losing the directsoundsink element in the process. Fixes #290 Part-of: <!643>
-
Otherwise the proxy pad of the ghost pad still stays linked to some element inside the bin, which is not allowed anymore according to the topology. In 2.0 this should be fixed more generically from inside GstGhostPad but currently there is no way to get notified that the ghost pad is unparented. Part-of: <!642>
-
- Sep 21, 2020
-
-
Since glib 2.64, gthreadpool will start waiting on a GCond immediately upon creation. This can cause issues if we fork *before* actually using the threadpool since we will then be signalling that GCond ... from another process and that will never work. Instead, delay creationg of thread pools until the very first time we need them. This introduces a minor (un-noticeable) delay when needing a new thread but fixes the issues for all users of GSTreamer that will call gst_init, then fork and actually start pipelines. See https://gitlab.gnome.org/GNOME/glib/-/issues/2131 for more context. Part-of: <!634>
-
Part-of: <gstreamer/gstreamer!633>
-
This is what we do everywhere else too, useful for debugging. Part-of: <!636>
-
- Sep 20, 2020
-
-
g_vprintf() will write a string binary to stdout directly using fwrite(). So, depending on character in the string, fwrite to stdout can print broken one but printf family might not cause the issue. Part-of: <gstreamer/gstreamer!637>
-
When posting a buffering message succesfully: * Remember the *actual* percentage value that was posted * Make sure we only reset the percent_changed variable if the value we just posted is indeed different from the current value Part-of: <gstreamer/gstreamer!632>
-
This is a follow up to review comments in !297 + The posting of the buffering message in READY_TO_PAUSED isn't needed, removing it made the test fail, but the correct fix was simply to link elements together + Move code to relock the queue and set last_posted_buffering_percent and percent_changed inside the buffering_post_lock in create_write(). This makes locking consistent with post_buffering() Part-of: <!297>
-
This fixes a bug that occurs when an attempt is made to post a buffering message before the queue2 was assigned a bus. One common situation where this happens is when the use-buffering property is set to TRUE before the queue2 was added to a bin. If the result of gst_element_post_message() is not checked, and the aforementioned situation occurs, then last_posted_buffering_percent and percent_changed will still be updated, as if posting the message succeeded. Later attempts to post again will not do anything because the code then assumes that a message with the same percentage was previously posted successfully and posting again is redundant. Updating these variables only if posting succeed and explicitely posting a buffering message in the READY->PAUSED state change ensure that a buffering message is posted as early as possible. Part-of: <gstreamer/gstreamer!297>
-
- Jun 07, 2020
-
-
In gst_sparse_file_clear function we were closing a file and reopening it using closed file descriptor. Fix: Removed closing and reopening of file. Fixes #512 Part-of: <gstreamer/gstreamer!372>
-
Adding a test
-
- Jun 06, 2020
-
-
When running in pull mode (for e.g. mp3 reading), baseparse currently reads 64KB from upstream, then mp3parse consumes typically around 417/418 bytes of it. Then on the next loop, it will read a full fresh 64KB again, which is a big waste. Fix the read loop to use the available cache buffer first before going for more data, until the cache drops to < 1KB. Fixes gstreamer/gstreamer#518
-
-
- Jun 04, 2020
-
-
Also add a unit test for this. Fixes #524
-
In case the buffer is not writable, the parent (the BufferList) is not removed before calling func. So if it is changed, the parent (the BufferList) of the previous buffer should be removed after calling func.
-
- Mar 14, 2020
-
-
- Mar 13, 2020
-
-
This allows an element to not require implementing transform or transform_ip.
-
Required to avoid broken log string on Windows but missed in the commit of 493a3261
-
- Feb 26, 2020
-
-
g_log_writer_supports_color() was introduced since GLib 2.50.0 which is slightly higher version than our minimum required GLib version.
-
- Feb 15, 2020
-
-
A buffer to be skipped wasn't unref'd in gst_base_parse_chain(). Fixes #406
-
Otherwise an application cannot rely on a subsequent call to e.g. gst_pad_query_duration() succeeding.
-
- Feb 14, 2020
-
-
Previously we would use the object lock only for storing the sync handler and its user_data in a local variable, then unlock it and only then call the sync handler. Between unlocking and calling the sync handler it might be unset and the user_data be freed, causing it to be called with a freed pointer. To prevent this add a refcounting wrapper struct around the sync handler, hold the object lock while retrieving it and increasing the reference count and only actually free it once the reference count reaches zero. As a side-effect we can now also allow to actually replace the sync handler. Previously it was only allowed to clear it after initially setting it according to the docs, but the code still allowed to clear it and then set a different one. Fixes #506
-
- Feb 05, 2020
-
-
The way it was implemented could make the list updated after the list of device was filled with supposdely hidden devices
-
- Jan 09, 2020
-
-
child and bin were switched. !354
-