[Bug 735663] dashdemux: synchronize with the download loop thread before signalling it

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=735663
  GStreamer | gst-plugins-bad | git

Matthieu Bouron <matthieu.bouron> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #285470|0                           |1
        is obsolete|                            |

--- Comment #3 from Matthieu Bouron <matthieu.bouron at collabora.com> 2014-09-05 13:38:12 UTC ---
Created an attachment (id=285496)
 View: https://bugzilla.gnome.org/attachment.cgi?id=285496
 Review: https://bugzilla.gnome.org/review?bug=735663&attachment=285496

[PATCH]dashdemux: properly wait fragment downloads

Patch updated with the following changes:

We do not rely entirely anymore on having the fragmemt download condition being
signaled because it could happen before g_cond_wait is called.
We cannot use the fragment download lock in the handle_message as it can be
called when gst_dash_demux_download_uri set the state of the src element.
I dropped the previous version of the patch since we do not have the guarantee
that the source function will be executed (using g_idle_add).

The code is a bit raw but does the job. Maybe waiting for the condition to be
signaled can be dropped as we can only rely on the new variable
fragment_download_signaled with its related lock.

Comments welcome :)

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.