GNOME Bugzilla – Bug 756913
hlsdemux: fix race condition while changing bitrate and seeking
Last modified: 2018-11-03 13:41:34 UTC
- Changed GST_M3U8_CLIENT_LOCK to a recursive mutex - This was needed as a race condition was present in gst_hls_demux_change_playlist, while switching variant it was possible for a seek to occur because the mutex was unlocked. This seek would fail at this point because client->current->endlist would not have been set to true yet. Changing GST_M3U8_CLIENT_LOCK to a recursive mutex prevents a seek occurring while switching variant. - This fix only applies to 1.4.5 - I understand that changing GST_M3U8_CLIENT_LOCK to a recursive mutex may not be an ideal solution, so I am open to suggestions on a more appropriate solution.
Created attachment 313815 [details] [review] Suggested Fix
Can you provide a patch against 1.6 or git master? Instead of a recursive mutex, we could add _locked() variants of the functions that are called while the mutex is hold. That seems like a better solution. Or alternatively move the seeking logic inside m3u8.c and just do it right there.
Hi, I am not in a position at the moment to test this with 1.6, as we have not moved from 1.4.5 to 1.6.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/314.