Automatically freeing old groups in decodebin2
Locked
Automatically freeing old groups in decodebin2
 
|
Re: Automatically freeing old groups in decodebin2
|
|
On Mi, 2012-04-04 at 10:07 +0200, [hidden email] 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 ? 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. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
signature.asc (205 bytes)
Re: Automatically freeing old groups in decodebin2
|
|
On Mi, 2012-04-04 at 10:27 +0200, Sebastian Dröge wrote:
> On Mi, 2012-04-04 at 10:07 +0200, [hidden email] 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). You probably want to take a look at http://cgit.collabora.com/git/user/tsaunier/gst-plugins-bad/log/?h=hlsdemux IIRC DASH is very similar to HLS (based on fragments with a playlist). After the refactorings in that branch (that will be upstream soon) it should be quite trivial to write a DASH demuxer with the help of the generic code used by hlsdemux. DASH should also be put into the same plugin in the end. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
RE: Automatically freeing old groups in decodebin2
|
|
RE: Automatically freeing old groups in decodebin2
|
|
On Mi, 2012-04-04 at 10:53 +0200, [hidden email] wrote:
> Thank you for your quick answer. I will look at the patch and may > come back to you (also depending on whether it is worth going down > that path knowing there may exist an alternative as pointed in your > other email). The alternative (doing something like hlsdemux) also involves triggering the group handling code in decodebin2 (removing/adding pads all the time). It will only be much easier to use the generic hlsdemux code as a base for a DASH plugin because it already handles all the hard stuff... and it will also be preferred upstream if all the HLS/DASH/etc protocols are implemented with the same base class and the same way. So these are two independent issues and the decodebin2 issue is something that must be fixed in any case. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
RE: Automatically freeing old groups in decodebin2
|
|
RE: Automatically freeing old groups in decodebin2
|
|
On Mi, 2012-04-04 at 10:59 +0200, [hidden email] wrote:
> I wish I had known this branch existed before starting our dev's: there is a lot > of overlap indeed ... I need to look at it a little closer to see if it also > provides an alternative solution to our initial issue of not being able to reset > the decoders when the bitrate changes (leading to our use of decodebin2 chains), > but I suspect it would be easier with HLS as MPEG2-TS should handle this > automatically (unlike MP4 !). The same problem still exists, that's independent. But by re-using that code you will have a lot less code to maintain and hopefully less bugs to worry about too. You have to publish your DASH code under LGPL when re-using that code though. I don't know if you planned to do that. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
| Free forum by Nabble | Edit this page |