Use proper API to flush libass events when we do
a flushing seek, and also do it in FLUSH_STOP
rather than FLUSH_START, so we can be sure
streaming has stopped.
Fixes seeking back in time.
Something seems to have changed in libass that
renders the old manual way of flushing events
ineffective and libass then seems to ignore
timestamps that are older than the ones last
seen then if we do it the old way.
Fixes#916
With latest XDG shell, we need to fait for the surface to have been
configured before we can attach a buffer to it. This is being enforce by
Weston with an error.
Fixes#933
Fixes the following error.
gstccconverter.c:677:7: error: variable 'len' is used uninitialized whenever 'if' condition is false
[-Werror,-Wsometimes-uninitialized]
if (flags & 0x40) {
^~~~~~~~~~~~
gstccconverter.c:698:10: note: uninitialized use occurs here
return len;
^~~
gstccconverter.c:677:3: note: remove the 'if' if its condition is always true
if (flags & 0x40) {
^~~~~~~~~~~~~~~~~~
gstccconverter.c:572:12: note: initialize the variable 'len' to silence this warning
guint len;
^
= 0
Prior to this, cccombiner stopped consuming video buffers when
data wasn't arriving on its caption pad. In a live situation,
when aggregator is timing out we should still output whatever
video buffers are present, even if no caption buffers can be
aggregated with them.
Since the addition of BUNDLE support, the pads and the transceivers
share a single transport stream. When getting stats from the stream,
filter by the ssrc of the current pad to avoid merging the stats for
different pads.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/889
It is necessary to implement this vmethod, as when the src pad
is marked as reconfigure, the base class will reset to src caps,
and the default update_src_caps simply queries the caps allowed
downstream without taking into account the caps set by
gst_aggregator_set_src_caps.
To make curlhttpsrc behave more like souphttpsrc, set the
BUFFER_OFFSET in its output buffers to match the segment
start. This means that in a HTTP RANGE request, the BUFFER_OFFSET
will match the value in the RANGE request.
To make it closer to a drop-in replacement for souphttpsrc,
expose the same gst_error_message_with_details as souphttpsrc,
so that applications can received the HTTP status code and reason
when an error occurs.
curlhttpsrc uses a single thread running the
gst_curl_http_src_curl_multi_loop() function to handle receiving
data and messages from libcurl. Each instance of curlhttpsrc adds
an entry into a queue in GstCurlHttpSrcMultiTaskContext and waits
for the multi_loop to perform the HTTP request.
Valgrind has shown up race conditions and memory leaks:
1. gst_curl_http_src_change_state() does not wait for the multi_loop
to complete before going to the NULL state, which means that
an instance of GstCurlHttpSrc can be released while
gst_curl_http_src_curl_multi_loop() still has a reference to it.
2. if multiple elements try to be removed from the queue at once,
only the last one is deleted.
3. source->caps is leaked
4. curl multi_handle is leaked
5. leak of curl_handle if URI not set
6. leak of http_headers when reusing element
7. null pointer dereference in negotiate caps
8. double-free of the default user-agent string
9. leak of multi_task_context.task
This commit changes the logic so that each element has a connection
status, which is used by the multi_loop to decide when to remove an
element from its queue. An instance of curlhttpsrc will not enter
the NULL state until its reference has been removed from the queue.
When shutting down the curl multi loop, the memory allocated from the
call to curl_multi_init() is now released.
When gstadaptivedemux uses a URI source element, it will re-use
it for multiple requests, moving it between READY and PLAYING
between each request. curlhttpsrc was leaking the http_headers
structure in this use case.
The gst_curl_http_src_negotiate_caps() function extracts the
"response-headers" field from the http_headers, but did not check
that this field might be NULL.
If the user-agent property is set, the global user-agent string
was freed. This caused a double-free error if the user-agent is
ever set a second time during the execution of the process.
There are situations within curlhttpsrc where the code needs
both the global multi_task_context mutex and the per-element
buffer_mutex. To avoid deadlocks, it is vital that the order in
which these are requested is always the same. This commit modifies
the locking order to always be in the order:
1. multi_task_context.task_rec_mutex
2. buffer_mutex
Fixes#876
