After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 678306 - decodebin: improve element instance handling
decodebin: improve element instance handling
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
playback
Depends on:
Blocks:
 
 
Reported: 2012-06-18 10:49 UTC by Mark Nauwelaerts
Modified: 2018-05-05 15:41 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
free old groups when switching groups (2.73 KB, patch)
2015-01-16 15:48 UTC, Vincent Penquerc'h
committed Details | Review

Description Mark Nauwelaerts 2012-06-18 10:49:19 UTC
decodebin2 behaviour upon a "channel switch" (like switching in a chained ogg) is currently as follows:
* new pads are added, for which new chains with new element (codec) instances are created
* old pads are eos-ed and removed, upon which the old chains are 'hidden'.  This only entails a partial cleanup, and in particular the old element instances are kept around even in PLAYING state.

At least 2 improvements/fixes seem to apply here:
* arrange for the old element instances to be taken down to e.g. READY
* put the old elements in some cached-element list so they can be re-used next time some such element is needed in a chain (like for example a subsequent channel switch).

[note that keeping the old ones around in READY allows to re-use some global setup performed when going to READY]
Comment 1 Sebastian Dröge (slomo) 2012-06-18 12:50:51 UTC
(In reply to comment #0)
> [...]
> At least 2 improvements/fixes seem to apply here:
> * arrange for the old element instances to be taken down to e.g. READY
> * put the old elements in some cached-element list so they can be re-used next
> time some such element is needed in a chain (like for example a subsequent
> channel switch).
> 
> [note that keeping the old ones around in READY allows to re-use some global
> setup performed when going to READY]

For this see e2a038acee2969ed0b558093fa1c8b7422073e40 in base too (which was reverted later because it wasn't optimal). Switching elements to READY is not trivial here, especially if you want to re-use the elements for the next group already. (But you can switch them to READY from the streaming thread(s) of the next group as far as I see it)


Would you keep elements cached for the whole lifetime of decodebin or would they be removed once the new group is exposed and they're not needed?
Comment 2 Mark Nauwelaerts 2012-06-18 15:03:38 UTC
It would not be the intention here to re-use these for the (already setup) next group (but they could be for the next one that comes along).

I suppose they would remain cached for the lifetime of decodebin, as it seems to be the case also now.

Also, what makes switching to READY not trivial here (dead-locking or ???) ?
Comment 3 Vincent Penquerc'h 2015-01-16 15:48:54 UTC
Created attachment 294698 [details] [review]
free old groups when switching groups

A patch to free old groups with one switch's time delay.
See https://bugzilla.gnome.org/show_bug.cgi?id=731404 for the bug which led to this.
Comment 4 Vincent Penquerc'h 2015-01-16 15:58:32 UTC
commit 6ab711f3f102da0fa8d4f9feabfe7f3f4e8a0d6e
Author: Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
Date:   Fri Jan 16 15:21:14 2015 +0000

    decodebin: free old groups when switching groups
    
    Old groups are freed with one switch's delay when switching groups.
    They're freed in a scratch thread to avoid delaying the switch.
Comment 5 Edward Hervey 2018-05-05 15:41:15 UTC
That was commited.