Hello, i found a problem on gstreamer when i started to use giosrc, is some situations the pipeline blocks and blocks the caller too (for example, calling set_state to NULL or seeking a pipeline when the remote connection fails makes the pipeline block completely, and the caller blocks too). taking a look at the source code i was able to see that the problem is that all functions called on the giosrc are sync, and this can impose several problems when something wrong happens with the connection. another problem is the one of having to mount manually and then calling giosrc, because the mount API AFAIK is async only. but to make use of the async API it is needed a GMainLoop, and there is the problem :-), gst plugins are not aware if there is a main loop running, it is not mandatory. This bug mention this problem (but it is closed): <a href="https://bugzilla.gnome.org/show_bug.cgi?id=510417">https://bugzilla.gnome.org/show_bug.cgi?id=510417</a> This other one seems to address it: <a href="https://bugzilla.gnome.org/show_bug.cgi?id=586939">https://bugzilla.gnome.org/show_bug.cgi?id=586939</a> since it seems to be a design problem it has been left to 0.11, but it is still unconfirmed, is there any idea if this bug will be fixed on 0.11, or at least for 1.0 ? the blocking thing is pretty nasty, sadly even the gio API is not full async (seeking is only synchronous), but having start/stop made async would be a great step. hope this helps you guys to remember to address this problem, if it is possible of course...i know there is a lot of work to do, and i would love to help with giosrc, but im not a very mature gstreamer developer. Here at my job we even tried to fix the plugin, but that started to get so ugly, and we read that the solution would have to wait 0.11, them we made a workaround outside gstreamer, but a more elegant solution would be great. If no one have time to do this i can give it a shot, but i would need some orientation on what is good gstreamer design, until now i just wrote bad plugins :-) sorry if i said something wrong, and for the lousy english :-) best regards, Katcipis <div class="gmail_quote">On Tue, Nov 9, 2010 at 10:53 AM, Wim Taymans <<a href="mailto:wim.taymans@gmail.com">wim.taymans@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hello GStreamer hackers, As most of you know, we'll be starting the new 0.11 development this month. This development effort should then eventually lead to a version 1.0 by the end of 2011. We've collected a fair amount of desired changes and features [1], some of them easy to implement and others not so much. Since the list of changes is rather large, we will have to have a strong focus on the most pressing parts while making sure that the smaller changes can be implemented on top of that. In this mail I would like to give a highlevel overview of the pressing problems we would like to see fixed for 1.0. More detailed information can be found in various places [1][2] and will be fleshed out even more as we go. The purpose is to give people an idea of the problems that will be fixed and what new use case will become possible or easier. This list is mostly collected from talking to people and the experiences of the past 5 years of GStreamer 0.10 development. There are 4 areas that need improvements. Each of those areas can be further subdivided in smaller subtasks [4]. 1) General cleanups. This includes small things like removing old or bad API that we have hanging around, cleaning up structs, fixing the padding, adding GstFlowReturn for events [6], etc.. 2) Performance improvements. The biggest one here is to rework the Caps system to make it faster. We have several ideas here: incremental caps [3] and reducing the amount of caps fields. Other ideas include changing the datastructure for caps. We are also going to change reverse negotiation and untie it from the allocation of data. 3) Extensible Buffer metadata. We're going to make it possible to dynamically attach metadata to buffers. The goal is to make it much easier to integrate with various hardware, DSPs and APIs like OpenMax, OpenGL, Cairo. Things like strides, cropping and regions of interest should be looked into. We would like to make sure that GStreamer elements can do zero-copy data passing for the most common use cases. See [5] 4) Improve dynamic pipeline handling. Problems with events being lost and newsegment accumulation cause difficulties when dynamically constructing complicated pipelines. We would like to make the timing mode more comprehensive and controllable from the application. I would like to ask everyone of you to see that this list is not missing anything important that you think needs to be considered for 1.0. All ideas are welcome and I would suggest to add them to the wiki [1]. Please try to focus on new core features and improvements (bug fixes, documentation, new plugins, performance improvements and other things that don't require API changes continues as usual in the 0.10 branch). I would also like to see how you think the API can be improved or how things can be done better API-wise. One of the big missing items on this list is improving the documentation. We've been thinking again about making a book for 1.0. It always boils down to the fact that most core developers would gladly write a chapter or two here and there but the missing part, it seems, is someone who would take charge of organizing and proofreading all this. If anyone feels like taking the lead here, we would be very very happy hackers. In practice, I would like to encourage people to make git branches with experiments and proposed solutions. I would also like to encourage you to add your ideas and suggestions to the wiki or this mailing-list. We'll take 2 more weeks to collect suggestions and to think about new ideas. Around the end of November we should start the 0.11 branch to start merging branches and porting elements. I would also like to do the weekly status updates of the 0.11 branch to let people know where we are. Exciting times ahead! Wim [1] <a href="http://gstreamer.freedesktop.org/wiki/ZeroPointEleven" target="_blank">http://gstreamer.freedesktop.org/wiki/ZeroPointEleven</a> [2] <a href="http://cgit.freedesktop.org/%7Ewtay/gstreamer/tree/docs/random/plan-0.11.txt?h=working&id=5c05a15e7cd2327e98d0177fdce8e5be3215aa05" target="_blank">http://cgit.freedesktop.org/~wtay/gstreamer/tree/docs/random/plan-0.11.txt?h=working&id=5c05a15e7cd2327e98d0177fdce8e5be3215aa05</a> [3] <a href="http://cgit.freedesktop.org/%7Eensonic/gstreamer/log/?h=lazycaps" target="_blank">http://cgit.freedesktop.org/~ensonic/gstreamer/log/?h=lazycaps</a> [4] <a href="http://cgit.freedesktop.org/%7Ewtay/gstreamer/tree/docs/random/use-cases-0.11.txt?h=working&id=5ca09f1421847264e69cb111b0887a00d8a58bf9" target="_blank">http://cgit.freedesktop.org/~wtay/gstreamer/tree/docs/random/use-cases-0.11.txt?h=working&id=5ca09f1421847264e69cb111b0887a00d8a58bf9</a> [5] <a href="http://cgit.freedesktop.org/%7Ewtay/gstreamer/log/?h=buffermeta" target="_blank">http://cgit.freedesktop.org/~wtay/gstreamer/log/?h=buffermeta</a> [6] <a href="http://cgit.freedesktop.org/%7Ewtay/gstreamer/log/?h=events2" target="_blank">http://cgit.freedesktop.org/~wtay/gstreamer/log/?h=events2</a> ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! <a href="http://p.sf.net/sfu/SAP-dev2dev" target="_blank">http://p.sf.net/sfu/SAP-dev2dev</a> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a> <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a> </blockquote></div> -- <a href="http://www.getgnulinux.org/windows">http://www.getgnulinux.org/windows</a>