GStreamer-devel

The 1.0 plan

Classic

List

Threaded

24 messages Options

Wim Taymans

The 1.0 plan

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
[3] http://cgit.freedesktop.org/~ensonic/gstreamer/log/?h=lazycaps
[4] http://cgit.freedesktop.org/~wtay/gstreamer/tree/docs/random/use-cases-0.11.txt?h=working&id=5ca09f1421847264e69cb111b0887a00d8a58bf9
[5] http://cgit.freedesktop.org/~wtay/gstreamer/log/?h=buffermeta
[6] http://cgit.freedesktop.org/~wtay/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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Tiago Katcipis

Re: The 1.0 plan

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 <[hidden email]> 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
[3] http://cgit.freedesktop.org/~ensonic/gstreamer/log/?h=lazycaps
[4] http://cgit.freedesktop.org/~wtay/gstreamer/tree/docs/random/use-cases-0.11.txt?h=working&id=5ca09f1421847264e69cb111b0887a00d8a58bf9
[5] http://cgit.freedesktop.org/~wtay/gstreamer/log/?h=buffermeta
[6] http://cgit.freedesktop.org/~wtay/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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
http://www.getgnulinux.org/windows

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

David Schleef-2

Re: Not at all related to 0.11 [Was: The 1.0 plan]

On Tue, Nov 16, 2010 at 10:28:23AM -0200, Tiago Katcipis wrote:
> 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.

Elements that require a GMainLoop create a thread and run a GMainLoop
there. One example is souphttpsrc.

David

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Tiago Katcipis

Re: Not at all related to 0.11 [Was: The 1.0 plan]

On Tue, Nov 16, 2010 at 6:28 PM, David Schleef <[hidden email]> wrote:

On Tue, Nov 16, 2010 at 10:28:23AM -0200, Tiago Katcipis wrote:
> 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.

Elements that require a GMainLoop create a thread and run a GMainLoop
there. One example is souphttpsrc.

That approach doesn't bring the same hazards of gst_bus_poll ?

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstBus.html#gst-bus-poll

"You should never use this function, since it is pure evil. This is especially true for GUI applications based on Gtk+ or Qt, but also for any other non-trivial application that uses the GLib main loop. As this function runs a GLib main loop, any callback attached to the default GLib main context may be invoked. This could be timeouts, GUI events, I/O events etc.; even if gst_bus_poll() is called with a 0 timeout. Any of these callbacks may do things you do not expect, e.g. destroy the main application window or some other resource; change other application state; display a dialog and run another main loop until the user clicks it away. In short, using this function may add a lot of complexity to your code through unexpected re-entrancy and unexpected changes to your application's state."

David

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Sebastian Dröge-7

Re: Not at all related to 0.11 [Was: The 1.0 plan]

On Thu, 2010-11-18 at 10:07 -0200, Tiago Katcipis wrote:

>
>
> On Tue, Nov 16, 2010 at 6:28 PM, David Schleef <[hidden email]>
> wrote:
> On Tue, Nov 16, 2010 at 10:28:23AM -0200, Tiago Katcipis
> wrote:
> > 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.
>
> Elements that require a GMainLoop create a thread and run a
> GMainLoop
> there. One example is souphttpsrc.
>
> That approach doesn't bring the same hazards of gst_bus_poll ?

No, if you want to use a GMainLoop inside your element you also have to
create a new GMainContext for it (which is then driven by your private
main loop). There's no need to run a GLib main loop on the default
context or any other ugly things.

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

signature.asc (205 bytes) Download Attachment

Tiago Katcipis

Re: Not at all related to 0.11 [Was: The 1.0 plan]

2010/11/18 Sebastian Dröge <[hidden email]>

On Thu, 2010-11-18 at 10:07 -0200, Tiago Katcipis wrote:

>
>
> On Tue, Nov 16, 2010 at 6:28 PM, David Schleef <[hidden email]>
> wrote:
> On Tue, Nov 16, 2010 at 10:28:23AM -0200, Tiago Katcipis
> wrote:
> > 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.
>
> Elements that require a GMainLoop create a thread and run a
> GMainLoop
> there. One example is souphttpsrc.
>

> That approach doesn't bring the same hazards of gst_bus_poll ?

No, if you want to use a GMainLoop inside your element you also have to
create a new GMainContext for it (which is then driven by your private
main loop). There's no need to run a GLib main loop on the default
context or any other ugly things.

hmm, that's interesting, why gst_bus_poll use the default context them?

i never used GMainLoop with different contexts, not pretty sure of how it works. If the main loop on the default context is running (the application is using it), and i create my main loop with a different context inside the plugin, to which main loop will go the async result of the GIO call ? (I'm going to read more about multiple main loops with different contexts)

if GIO would work with this approach it seems to be an interesting solution to start using the GIO async API instead of the sync API, and it would be possible to mount the file for the user, making the use of giosrc/sink pretty easier.

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Sebastian Dröge-7

Re: Not at all related to 0.11 [Was: The 1.0 plan]

On Thu, 2010-11-18 at 11:51 -0200, Tiago Katcipis wrote:

>
>
> 2010/11/18 Sebastian Dröge <[hidden email]>
> On Thu, 2010-11-18 at 10:07 -0200, Tiago Katcipis wrote:
> >
> >
> > On Tue, Nov 16, 2010 at 6:28 PM, David Schleef
> <[hidden email]>
> > wrote:
> > On Tue, Nov 16, 2010 at 10:28:23AM -0200, Tiago
> Katcipis
> > wrote:
> > > 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.
> >
> > Elements that require a GMainLoop create a thread
> and run a
> > GMainLoop
> > there. One example is souphttpsrc.
> >
>
> > That approach doesn't bring the same hazards of
> gst_bus_poll ?
>
> No, if you want to use a GMainLoop inside your element you
> also have to
> create a new GMainContext for it (which is then driven by your
> private
> main loop). There's no need to run a GLib main loop on the
> default
> context or any other ugly things.
>
> hmm, that's interesting, why gst_bus_poll use the default context
> them?

Because it was meant to be used by application that have a main loop on
the default context and that want to continue other things in that main
loop while waiting for a message on the bus.

> i never used GMainLoop with different contexts, not pretty sure of how
> it works. If the main loop on the default context is running (the
> application is using it), and i create my main loop with a different
> context inside the plugin, to which main loop will go the async result
> of the GIO call ? (I'm going to read more about multiple main loops
> with different contexts)

GIO uses the thread default main context of the thread that started the
async operation (see the GMainContext docs) and signals are emitted to
any main loop running on that main context.

> if GIO would work with this approach it seems to be an interesting
> solution to start using the GIO async API instead of the sync API, and
> it would be possible to mount the file for the user, making the use of
> giosrc/sink pretty easier.

That's all possible but the problem with that is, that a) the state
change from NULL->READY happens synchronous in GStreamer and that b)
basesrc wants to know the file size in READY already, otherwise it will
never activate random access mode.

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

signature.asc (205 bytes) Download Attachment

Tiago Katcipis

Re: Not at all related to 0.11 [Was: The 1.0 plan]

2010/11/18 Sebastian Dröge <[hidden email]>

On Thu, 2010-11-18 at 11:51 -0200, Tiago Katcipis wrote:
>
>
> 2010/11/18 Sebastian Dröge <[hidden email]>
> On Thu, 2010-11-18 at 10:07 -0200, Tiago Katcipis wrote:
> >
> >
> > On Tue, Nov 16, 2010 at 6:28 PM, David Schleef
> <[hidden email]>
> > wrote:
> > On Tue, Nov 16, 2010 at 10:28:23AM -0200, Tiago
> Katcipis
> > wrote:
> > > 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.
> >
> > Elements that require a GMainLoop create a thread
> and run a
> > GMainLoop
> > there. One example is souphttpsrc.
> >
>
> > That approach doesn't bring the same hazards of
> gst_bus_poll ?
>
> No, if you want to use a GMainLoop inside your element you
> also have to
> create a new GMainContext for it (which is then driven by your
> private
> main loop). There's no need to run a GLib main loop on the
> default
> context or any other ugly things.
>
> hmm, that's interesting, why gst_bus_poll use the default context
> them?

Because it was meant to be used by application that have a main loop on
the default context and that want to continue other things in that main
loop while waiting for a message on the bus.

hmm and in that case using a g_main_context_push_thread_default() to run poll stuff on other context and them g_main_context_pop_thread_default() to restore the main context would prevent other things from happening on the default context, right?

> i never used GMainLoop with different contexts, not pretty sure of how
> it works. If the main loop on the default context is running (the
> application is using it), and i create my main loop with a different
> context inside the plugin, to which main loop will go the async result
> of the GIO call ? (I'm going to read more about multiple main loops
> with different contexts)

GIO uses the thread default main context of the thread that started the
async operation (see the GMainContext docs) and signals are emitted to
any main loop running on that main context.

Thanks for the help Sebastian, i read g_main_context_get_thread_default () and g_main_context_push_thread_default () doc and helped a lot to understand better how could this work.

> if GIO would work with this approach it seems to be an interesting
> solution to start using the GIO async API instead of the sync API, and
> it would be possible to mount the file for the user, making the use of
> giosrc/sink pretty easier.

That's all possible but the problem with that is, that a) the state
change from NULL->READY happens synchronous in GStreamer and that b)
basesrc wants to know the file size in READY already, otherwise it will
never activate random access mode.

Well if it must be synchronous running the main loop on another Thread does not to seem to be an option. What is done on gst_bus_poll seems to fit here:

1 - the caller on the set_state will get blocked on the call
2 - inside the call we mount the file and do all the stuff async using the main_loop_run to block the caller
3 - after everything is done we get out of the run call and give to the basesrc the file size

this way we can use the async GIO API, mount the file for the user giving a "sync" operation to the set_state caller. But this approach is pretty simple, if you guys still not implemented it... it is because it has something pretty bad on it... it is because the same problem that can happen on gst_bus_poll?

------------------------------ ------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
______________________________ _________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Sebastian Dröge-7

Re: Not at all related to 0.11 [Was: The 1.0 plan]

On Thu, 2010-11-18 at 13:00 -0200, Tiago Katcipis wrote:

>
>
> That's all possible but the problem with that is, that a) the
> state
> change from NULL->READY happens synchronous in GStreamer and
> that b)
> basesrc wants to know the file size in READY already,
> otherwise it will
> never activate random access mode.
>
>
> Well if it must be synchronous running the main loop on another Thread
> does not to seem to be an option. What is done on gst_bus_poll seems
> to fit here:
>
> 1 - the caller on the set_state will get blocked on the call
> 2 - inside the call we mount the file and do all the stuff async using
> the main_loop_run to block the caller
> 3 - after everything is done we get out of the run call and give to
> the basesrc the file size
>
> this way we can use the async GIO API, mount the file for the user
> giving a "sync" operation to the set_state caller. But this approach
> is pretty simple, if you guys still not implemented it... it is
> because it has something pretty bad on it... it is because the same
> problem that can happen on gst_bus_poll?

That would work in theory but the problem here is, that GStreamer does
not require any running GLib main loop on the main context by policy.

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

signature.asc (205 bytes) Download Attachment

Tiago Katcipis

Re: Not at all related to 0.11 [Was: The 1.0 plan]

2010/11/18 Sebastian Dröge <[hidden email]>

On Thu, 2010-11-18 at 13:00 -0200, Tiago Katcipis wrote:
>
>
> That's all possible but the problem with that is, that a) the
> state
> change from NULL->READY happens synchronous in GStreamer and
> that b)
> basesrc wants to know the file size in READY already,
> otherwise it will
> never activate random access mode.
>
>
> Well if it must be synchronous running the main loop on another Thread
> does not to seem to be an option. What is done on gst_bus_poll seems
> to fit here:
>
> 1 - the caller on the set_state will get blocked on the call
> 2 - inside the call we mount the file and do all the stuff async using
> the main_loop_run to block the caller
> 3 - after everything is done we get out of the run call and give to
> the basesrc the file size
>
> this way we can use the async GIO API, mount the file for the user
> giving a "sync" operation to the set_state caller. But this approach
> is pretty simple, if you guys still not implemented it... it is
> because it has something pretty bad on it... it is because the same
> problem that can happen on gst_bus_poll?

That would work in theory but the problem here is, that GStreamer does
not require any running GLib main loop on the main context by policy.

does not require, but if we create it? the user does not need to know that a main loop has been created, and if the mainloop on the main context already exists...we use it.

but i agree that it is ugly and your suggestion seems to be better...make the transition of states async:
https://bugzilla.gnome.org/show_bug.cgi?id=586939

so my question now is... is there any planning on doing this? because if it is not going to be done, even if it is not beautiful (like gst_bus_poll) it seems to be better to let the user "ask" the plugin to mount everything to him instead of having to catch a message "not-mounted" and them having to mount (asynchronously...a pain in the ass) and them setting the pipeline to play again.

best regards,
Katcipis

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Tiago Katcipis

Re: Not at all related to 0.11 [Was: The 1.0 plan]

In reply to this post by Sebastian Dröge-7

2010/11/18 Sebastian Dröge <[hidden email]>

On Thu, 2010-11-18 at 13:00 -0200, Tiago Katcipis wrote:
>
>
> That's all possible but the problem with that is, that a) the
> state
> change from NULL->READY happens synchronous in GStreamer and
> that b)
> basesrc wants to know the file size in READY already,
> otherwise it will
> never activate random access mode.
>
>
> Well if it must be synchronous running the main loop on another Thread
> does not to seem to be an option. What is done on gst_bus_poll seems
> to fit here:
>
> 1 - the caller on the set_state will get blocked on the call
> 2 - inside the call we mount the file and do all the stuff async using
> the main_loop_run to block the caller
> 3 - after everything is done we get out of the run call and give to
> the basesrc the file size
>
> this way we can use the async GIO API, mount the file for the user
> giving a "sync" operation to the set_state caller. But this approach
> is pretty simple, if you guys still not implemented it... it is
> because it has something pretty bad on it... it is because the same
> problem that can happen on gst_bus_poll?

That would work in theory but the problem here is, that GStreamer does
not require any running GLib main loop on the main context by policy.

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Tiago Katcipis

Re: Not at all related to 0.11 [Was: The 1.0 plan]

On Thu, Nov 18, 2010 at 3:40 PM, Tiago Katcipis <[hidden email]> wrote:

2010/11/18 Sebastian Dröge <[hidden email]>

On Thu, 2010-11-18 at 13:00 -0200, Tiago Katcipis wrote:

>
>
> That's all possible but the problem with that is, that a) the
> state
> change from NULL->READY happens synchronous in GStreamer and
> that b)
> basesrc wants to know the file size in READY already,
> otherwise it will
> never activate random access mode.
>
>
> Well if it must be synchronous running the main loop on another Thread
> does not to seem to be an option. What is done on gst_bus_poll seems
> to fit here:
>
> 1 - the caller on the set_state will get blocked on the call
> 2 - inside the call we mount the file and do all the stuff async using
> the main_loop_run to block the caller
> 3 - after everything is done we get out of the run call and give to
> the basesrc the file size
>
> this way we can use the async GIO API, mount the file for the user
> giving a "sync" operation to the set_state caller. But this approach
> is pretty simple, if you guys still not implemented it... it is
> because it has something pretty bad on it... it is because the same
> problem that can happen on gst_bus_poll?

That would work in theory but the problem here is, that GStreamer does
not require any running GLib main loop on the main context by policy.

does not require, but if we create it? the user does not need to know that a main loop has been created, and if the mainloop on the main context already exists...we use it.

but i agree that it is ugly and your suggestion seems to be better...make the transition of states async:
https://bugzilla.gnome.org/show_bug.cgi?id=586939

so my question now is... is there any planning on doing this? because if it is not going to be done, even if it is not beautiful (like gst_bus_poll) it seems to be better to let the user "ask" the plugin to mount everything to him instead of having to catch a message "not-mounted" and them having to mount (asynchronously...a pain in the ass) and them setting the pipeline to play again.

Is anything going to be done about this on gstreamer 0.11/1.0 ?
like async changes, that would make possible to write a better giosrc plugin.

Here at my job we work a lot with network sources, on the past we used gnomevfssrc and now we are using giosrc, but its usage is ugly (gnomevfssrc is deprecated but was more easy to use),

I'm really interested on helping to make it better, but there is no use on writing a solution that wont be accepted on gstreamer.

another problem related to async state changes is setting a pipeline that is using giosrc with a network source (tested with ssh) to NULL when the connection is down, the sync call to set_state to NULL blocks the application...for a long long time.

eg:
- im playing ssh://myfile
- ops, connection is down...stopped playback
- i call set_state(NULL) - (if i call a seek i will block too)
- i got blocked for a long long time (this made our server to freeze completely)

it seems that having async set_state calls would be a good idea when working with network sources. There is no good way to now if everything is fine before calling a set_state that can block for a long time (there is no feedback about the status of the connection).

i would like to help making giosrc better, but on the 0.11/1.0 plan i didn't see anything about it.

sorry for the bad english.

best regards,
Katcipis

best regards,
Katcipis

------------------------------------------------------------------------------

Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
http://www.getgnulinux.org/windows

--
http://www.getgnulinux.org/windows

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Thomas Vander Stichele

Re: The 1.0 plan

In reply to this post by Wim Taymans

Hi,

> 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.

I've been particularly thinking about this and asking around for
opinions.

I very much liked the way the Couchdb people set up their book website
and ended up publishing it: http://guide.couchdb.org/

a) they developed the book in a code repository
b) they use it to tag physical releases of the book, and manage
translations
c) they had a site set up all the way through with some simple
javascript so anyone could leave a comment on any specific paragraph and
it was posted as a mail to a list dedicated to the book
d) everything to make the book is freely available

They wrote the book in a subset of HTML5 instead of docbook, and are
able to convert it to docbook.

I don't want to overly focus on the toolchain to make a book, but I
think c) was killer - they got lots of feedback as they wrote the book
(even from me), which both helped them improve content as well as
motivate the writers directly.

One practical idea for the book I thought would be good is to have
enough simple code samples on how to do things in C, and pick a
higher-level language (Python) and "translate" all C examples in the
equivalent Python code. Just as in our current manual, it would be
important to make sure these examples compile/validate and/or run.

I'm willing to take the lead on this if we find some people that are
willing to write specific chapters. It'd be useful to have someone help
us out with concrete info who's already written a book (Jono, you still
lurking here?) We should probably start with a rough chapter outline for
it and see who'd be up for writing some chapters. I myself was thinking
about doing one on synchronization for example as I'm going to make an
internal presentation about it at Flumotion at some point.

Who else is interested in writing part of a GStreamer book?

Thomas

--
Keep me in your bed all day
Nothing heals me like you do
--
URGent, best radio on the net - 24/7 !
http://urgent.fm/

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Andy Wingo

Re: The 1.0 plan

On Thu 25 Nov 2010 12:51, Thomas Vander Stichele <[hidden email]> writes:

> I'm willing to take the lead on this if we find some people that are
> willing to write specific chapters.

OK everybody, thomas is writing the book! Excellent!

> Who else is interested in writing part of a GStreamer book?

I'll be a late-stage investor: once you have 6 chapters lines up I'll
take one of the ones that's left.

Get Wim to agree, and set up the web site!

Andy
--
http://wingolog.org/

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Stefan Sauer

Re: The 1.0 plan

In reply to this post by Thomas Vander Stichele

Am 25.11.2010 13:51, schrieb Thomas Vander Stichele:

> Hi,
>
>> 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.
>
> I've been particularly thinking about this and asking around for
> opinions.
>
> I very much liked the way the Couchdb people set up their book website
> and ended up publishing it: http://guide.couchdb.org/
>
> a) they developed the book in a code repository
> b) they use it to tag physical releases of the book, and manage
> translations
> c) they had a site set up all the way through with some simple
> javascript so anyone could leave a comment on any specific paragraph and
> it was posted as a mail to a list dedicated to the book
> d) everything to make the book is freely available
>
> They wrote the book in a subset of HTML5 instead of docbook, and are
> able to convert it to docbook.

I have been recently playing with ascii doc quite a bit and like the pragmatic
concepts of it. One basically write wiki-markup. It can render to html, docbook,
etc.

Also I 2nd the feedback thing. Having that for all kind of docs would rock. Need
to look at how they did that.

>
> I don't want to overly focus on the toolchain to make a book, but I
> think c) was killer - they got lots of feedback as they wrote the book
> (even from me), which both helped them improve content as well as
> motivate the writers directly.
>
> One practical idea for the book I thought would be good is to have
> enough simple code samples on how to do things in C, and pick a
> higher-level language (Python) and "translate" all C examples in the
> equivalent Python code. Just as in our current manual, it would be
> important to make sure these examples compile/validate and/or run.
>

I think the way we have some of the example in our current docs is okay, its
just that probably now most people are not aware of the magic and start putting
examples directly into the docs. A few lines in docs/README docuemnting it would
be appreacited.

>
> I'm willing to take the lead on this if we find some people that are
> willing to write specific chapters. It'd be useful to have someone help
> us out with concrete info who's already written a book (Jono, you still
> lurking here?) We should probably start with a rough chapter outline for
> it and see who'd be up for writing some chapters. I myself was thinking
> about doing one on synchronization for example as I'm going to make an
> internal presentation about it at Flumotion at some point.

REgarding out current docs. I would like to merge the ADM and PWG into one book.
This way we can have a common introduction (design, concepts, debugging) and we
can xref things better.
There would be two main chapters about writing apps and writing plugins.

Anyone against that idea?

Regarding the book, shall we start from scratch or turn the current manual(s)
into the book?

>
> Who else is interested in writing part of a GStreamer book?

I'd love to contribute.

Stefan

>
> Thomas
>

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Tim-Philipp Müller-2

Docs/Book (Re: The 1.0 plan)

> shall we start from scratch or turn the current manual(s)
> into the book?

Start from scratch.

Cheers
-Tim

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Marco Ballesio

Re: The 1.0 plan

In reply to this post by Thomas Vander Stichele

Hi,

On Thu, Nov 25, 2010 at 1:51 PM, Thomas Vander Stichele
<[hidden email]> wrote:
.. snip ..

>
> Who else is interested in writing part of a GStreamer book?

Networking for me, please!

Regards,
Marco

>
> Thomas
>
> --
> Keep me in your bed all day
> Nothing heals me like you do
> --
> URGent, best radio on the net - 24/7 !
> http://urgent.fm/
>
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Marco Ballesio

Re: Docs/Book (Re: The 1.0 plan)

In reply to this post by Tim-Philipp Müller-2

Hi,

On Fri, Nov 26, 2010 at 1:06 PM, Tim-Philipp Müller <[hidden email]> wrote:
>
>> shall we start from scratch or turn the current manual(s)
>> into the book?
>
> Start from scratch.

Some copy-paste wouldn't be bad in case of printing. Btw, if the two
things (manuals+book) would be maintained together, I vote for
cross-referincing.

Regards

>
> Cheers
> -Tim
>
>
> ------------------------------------------------------------------------------
> Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
> Tap into the largest installed PC base & get more eyes on your game by
> optimizing for Intel(R) Graphics Technology. Get started today with the
> Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
> http://p.sf.net/sfu/intelisp-dev2dev
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

Sandino Flores Moreno

Re: The 1.0 plan

In reply to this post by Wim Taymans

Something I'd like to see in the futire, is a better gobject-like use
of callbacks.

For example, instead of:

void gst_pad_set_chain_function (GstPad *pad, GstPadChainFunction chain);
GstFlowReturn (*GstPadChainFunction) (GstPad *pad, GstBuffer *buffer);

I would prefer:

void gst_pad_set_chain_function (GstPad *pad, GstPadChainFunction
chain, gpointer user_data);
GstFlowReturn (*GstPadChainFunction) (GstPad *pad, GstBuffer
*buffer, gpointer user_data);

This way, gstreamer would play more nicely with Vala and the bindings.

Just my two cents.

- Sandino

On Tue, Nov 9, 2010 at 6:53 AM, Wim Taymans <[hidden email]> 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
> [3] http://cgit.freedesktop.org/~ensonic/gstreamer/log/?h=lazycaps
> [4] http://cgit.freedesktop.org/~wtay/gstreamer/tree/docs/random/use-cases-0.11.txt?h=working&id=5ca09f1421847264e69cb111b0887a00d8a58bf9
> [5] http://cgit.freedesktop.org/~wtay/gstreamer/log/?h=buffermeta
> [6] http://cgit.freedesktop.org/~wtay/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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

wally_bkg

Re: The 1.0 plan

In reply to this post by Wim Taymans

Wim Taymans wrote

One of the big missing items on this list is improving the documentation.

Understatement of the year!

The replies to this message alone are proof that information about the "proper" way to do things is sorely lacking.

IMHO one of the worst parts of gstreamer is the v4l2src stuff, particularly selecting the proper video norms (seems about half the world will have video cards that default on power up to the wrong standard) and selecting the proper input. Is there even a way to do it via gst-launch?

I also think the best documentation is a working sample code, with decent comments. The only way I could figure out how to interpret video data pixels in a buffer (either as a plugin or appsink) was to stumble around the source code for gstgamma and gstvideoscale.

Of course the data you get in a buffer depends on the caps, but am I the only one who thinks there has to be a better way than:

GstStructure *structure;
gint width,height;

// this seems rather ridiculous as a way to get info about interpreting the buffer,
// but after inspecting gstvudeoscale.c appears to be what the gst designers intended :(
data = GST_BUFFER_DATA (buf);
size = GST_BUFFER_SIZE (buf);
structure = gst_caps_get_structure (gst_buffer_get_caps(buf), 0);
gst_structure_get_int (structure, "width", &width);
gst_structure_get_int (structure, "height", &height);

So I guess this comment just degenerates into another vote for having metadata in the buffers. OTOH I'd not be surprised if there is a better way that is undocumented and buried somewhere in the source tree I've not stumbled on to.