A deadlock can happen when the source sends EOS when
being put to NULL as the object lock is being held by the
thread that sets the element to NULL and is needed by
the event handler.
Cancelled is a 'permanent' state of the uridownloader and is only
removed by a call to _reset. When a download fails we just want to
return NULL on the fetch function and leave the downloader ready
for another fetch, otherwise the user has to call _reset after
failed downloader, even when it didn't call _cancel.
Adds a new API gst_uri_downloader_fetch_uri_with_range that allows
downloading only a byte range from an URI. It uses a seek event
sent to the source to signal the range to be downloaded.
https://bugzilla.gnome.org/show_bug.cgi?id=702206
When chain method was called after gst_uri_downloader_stop and before state has been changed to NULL, execution was blocking on g_mutex_lock.
Conflicts:
gst-libs/gst/uridownloader/gsturidownloader.c
When downloading and cancelling quickly the uridownloader object and the
element using it could miss the cancelled window and the uridownloader
would fetch the wrong URI and block on subsequent fetches.
This was also problematic when stopping elements, while one task would
call the cancel, another element thread could issue a new fetch_uri. As
the cancel state isn't 'permanent' this fetch_uri would block and
prevent the whole element from stopping and going to NULL.
This patch makes the 'cancelled' state permanent until a
gst_uri_downloader_reset is called. This way the element knows the
window where the uridownloader isn't active and only reactivate it when
ready.
