[gst-devel] Not at all related to 0.11 [Was: The 1.0 plan]
Tiago Katcipis
katcipis at inf.ufsc.br
Thu Nov 18 16:00:31 CET 2010
2010/11/18 Sebastian Dröge <sebastian.droege at collabora.co.uk>
> On Thu, 2010-11-18 at 11:51 -0200, Tiago Katcipis wrote:
> >
> >
> > 2010/11/18 Sebastian Dröge <sebastian.droege at collabora.co.uk>
> > On Thu, 2010-11-18 at 10:07 -0200, Tiago Katcipis wrote:
> > >
> > >
> > > On Tue, Nov 16, 2010 at 6:28 PM, David Schleef
> > <ds at entropywave.com>
> > > 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()<http://library.gnome.org/devel/glib/unstable/glib-The-Main-Event-Loop.html#g-main-context-push-thread-default>to
run poll stuff on other context and them
g_main_context_pop_thread_default()<http://library.gnome.org/devel/glib/unstable/glib-The-Main-Event-Loop.html#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
()andg_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
> 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/20101118/a915694c/attachment.htm>
More information about the gstreamer-devel
mailing list