[gst-devel] Not at all related to 0.11 [Was: The 1.0 plan]

[Sebastian Dröge]

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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101118/382ca0ca/attachment.pgp>