Changes in:  gstreamer

 gstreamer:139c96c129149266669c9799ad3b30d84f62065b
 gst-plugins-base:ae4338bd35d8aee3ecf1e5f5e24a5a51e914881d
 gst-plugins-good:8a143dfcbcc4cc63c88bec141692d5d852f8f9a5
 gst-plugins-ugly:12509f4a80a4469430bcc6e6f5847955ae60440f
 gst-plugins-bad:078b82d6d1c609257b6528a9c4efb1ed4acd2bb8
 gst-ffmpeg:ca1b5d85765be8df27d0a87a45426c7925ce1f29
 gnonlin:5d52548056b05a0a2fb7fd901c6b8623c2a1b642
 gst-editing-services:105d901c12d4e9e1f6cdf0681a9e961d80bb6a1e
 gst-python:c889037e40bb3568ef8cd9456123d744b25a919b

====== gstreamer =============

 commit 139c96c129149266669c9799ad3b30d84f62065b
Author: Thiago Santos <ts.santos@sisa.samsung.com>
Date:   Wed Jan 15 00:12:26 2014 -0300

    multiqueue: prevent buffering forever with playbin

    When prerolling/buffering, multiqueue has its buffers limit set
    to 0, this means it can take an infinite amount of buffers.

    When prerolling/buffering finishes, its limit is set back to 5, but
    only if the current level is lower than 5. It should (almost) never be
    and this will cause prerolling/buffering to need to wait to reach the
    hard bytes and time limits, which are much higher.

    This can lead to a very long startup time. This patch fixes this
    by setting the single queues to the max(current, new_value) instead
    of simply ignoring the new value and letting it as infinite(0)

    https://bugzilla.gnome.org/show_bug.cgi?id=712597