Automatically freeing old groups in decodebin2

[Sebastian Dröge]

On Mi, 2012-04-04 at 10:07 +0200, david.corvoysier at orange.com wrote:
> Hi,
> 
> I am currently experimenting with the decodebin2 ability to switch
> from a drained chain to a newly activated one. 
> The idea is to allow chained mp4 streams to be played consecutively,
> pretty much in the same way as the ogg demux does with chained ogg
> files (for those interested, it is related to the DASH adaptive
> streaming).
> 
> The issue I am facing is that when a new group takes over inside a
> chain, the drained group it replaces is not immediately freed: instead
> it is "hidden" and  goes into an "old group" list that is only freed
> when the chain itself is freed.
> 
> Decoders are in particular kept alive, rapidly leading to memory and
> hardware decoding bandwidth issues after a few streams have been
> played consecutively.
> 
> I am new to Gstreamer, so I must confess I don't see why the old group
> cannot be freed immediately, although a FIXME comment seems to suggest
> that it should be done asynchronously in a different thread. 
> 
> "... 
>   /* FIXME: This should be done directly via a thread! */ 
>   GList *old_groups;            /* Groups that should be freed later
> */  
> …."
> 
> Could someone elaborate why old groups cannot be freed immediately,
> and how it could be done async ?

They can't be free'd immediately because you need to set the state of
all elements inside the group to NULL before unreffing the elements.
Setting the state to NULL would happen from the streaming thread(s) of
the demuxer and you must not change states from inside the streaming
threads (general answer, there are some cases where you can).

If you look at GIT and commit e2a038acee2969ed0b558093fa1c8b7422073e40
you'll see a commit that actually does what you described. It wasn't
optimal though and was reverted later. If you want to work on improving
this feel free to talk to me.
Note that in this case you *can* free an old group immediately and it's
not necessary to be done from another thread (if I'm not mistaken, I'm
still only 99% sure that it's safe here). It must happen after the old
srcpads are removed from decodebin2 and the old group is completely
drained and can happen before the new srcpads are added to decodebin2.

Also, if you do it that way you can (and will) still have multiple
decoder instances at the same time immediately between group switches
and both decoder instances must be able to process data for a short
period of time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20120404/448a3893/attachment.pgp>