[Bug 711849] smoothstreaming: Better handling of multi audio tracks

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Dec 18 14:56:43 PST 2013


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

--- Comment #13 from Thiago Sousa Santos <thiago.sousa.santos at collabora.co.uk> 2013-12-18 22:56:35 UTC ---
This is partially fixed, the mssdemux part is done. Fixes are still needed on
baseaudiosink and pipeline buffering.

commit 67f3190301bfdd6673cbfd4ceb20d9791187df17
Author: Thiago Santos <ts.santos at sisa.samsung.com>
Date:   Mon Dec 16 16:14:24 2013 -0300

    mssdemux: remove the stream loop task

    Download and push from the same task, makes code a lot simpler
    to maintain. Also pushing from separate threads avoids deadlocking
    when gst_pad_push blocks due to downstream queues being full

commit 4e6e1315da7b12a31ae535d889652101611d9f6b
Author: Thiago Santos <ts.santos at sisa.samsung.com>
Date:   Fri Dec 13 17:31:11 2013 -0300

    mssdemux: Improve logging

    Show the stream's pad on log messages to make easier to debug
    issues in the multiple threads

commit 056420940e62bf41ce0451cc4b8417acba500454
Author: Thiago Santos <ts.santos at sisa.samsung.com>
Date:   Tue Dec 10 18:08:40 2013 -0300

    mssdemux: improve flow return handling

    Handle different flow returns both from the streaming and the
    downloading loops

commit e847bea1e1e2d7d68ee2830861201f5957ede7ee
Author: Thiago Santos <ts.santos at sisa.samsung.com>
Date:   Tue Dec 10 15:41:00 2013 -0300

    mssdemux: remove stream locks

    Simplify the locking by using a single lock instead of having one
    lock per stream. This still works and is simpler to maintain.

commit 2ce4f6a8e4c8aa33d08d9f5fe28a83779fadf03f
Author: Thiago Santos <ts.santos at sisa.samsung.com>
Date:   Tue Nov 12 09:58:31 2013 -0300

    mssdemux: avoid downloading not-linked streams

    When a stream gets a not-linked return, it will be marked as so and
    won't download any more new fragments until a reconfigure event
    is received. This will make mssdemux expose all pads, but only download
    fragments for the streams that are actually being used.

    Relying on the pads being linked/unlinked isn't enough in this scenario
    as there might be an input-selector downstream that is actually discarding
    buffers for a given linked pad.

    When streams are switching, the old active stream can be blocked because
    input-selector will block not-linked streams. In case the mssdemux's
    stream loop is blocked pushing a buffer to a full queue downstream it will
    never unblock as the queue will not drain (input-selector is blocking).

    In this scenario, stream switching will deadlock as input-selector is
    waiting for the newly active stream data and the stream_loop that would
    push this data is blocked waiting for input-selector.

    To solve this issue, whenever an stream is reactivated on a reconfigure
    it will enter into the 'catch up mode', in this mode it can push buffers
    from its download thread until it reaches the currrent GstSegment's
position.
    This works because this timestamp will always be behind or equal to the
maximum
    timestamp pushed for all streams, after pushing data for this timestamp,
    the stream will go back to default and be pushed sequentially from the main
    streaming thread. By this time, the input-selector should have already
    released the thread.

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

-- 
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.


More information about the gstreamer-bugs mailing list