[gst-devel] The 1.0 plan

Tue Nov 16 13:28:23 CET 2010

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):
https://bugzilla.gnome.org/show_bug.cgi?id=510417

This other one seems to address it:
https://bugzilla.gnome.org/show_bug.cgi?id=586939

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

On Tue, Nov 9, 2010 at 10:53 AM, Wim Taymans <wim.taymans at gmail.com> wrote:

> 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] http://gstreamer.freedesktop.org/wiki/ZeroPointEleven
> [2]
> http://cgit.freedesktop.org/~wtay/gstreamer/tree/docs/random/plan-0.11.txt?h=working&id=5c05a15e7cd2327e98d0177fdce8e5be3215aa05<http://cgit.freedesktop.org/%7Ewtay/gstreamer/tree/docs/random/plan-0.11.txt?h=working&id=5c05a15e7cd2327e98d0177fdce8e5be3215aa05>
> [3] http://cgit.freedesktop.org/~ensonic/gstreamer/log/?h=lazycaps<http://cgit.freedesktop.org/%7Eensonic/gstreamer/log/?h=lazycaps>
> [4]
> http://cgit.freedesktop.org/~wtay/gstreamer/tree/docs/random/use-cases-0.11.txt?h=working&id=5ca09f1421847264e69cb111b0887a00d8a58bf9<http://cgit.freedesktop.org/%7Ewtay/gstreamer/tree/docs/random/use-cases-0.11.txt?h=working&id=5ca09f1421847264e69cb111b0887a00d8a58bf9>
> [5] http://cgit.freedesktop.org/~wtay/gstreamer/log/?h=buffermeta<http://cgit.freedesktop.org/%7Ewtay/gstreamer/log/?h=buffermeta>
> [6] http://cgit.freedesktop.org/~wtay/gstreamer/log/?h=events2<http://cgit.freedesktop.org/%7Ewtay/gstreamer/log/?h=events2>
>
>
>
>
> ------------------------------------------------------------------------------
> 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!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

-- 
http://www.getgnulinux.org/windows
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101116/0234b2cc/attachment.htm>