[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