After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 510417 - [gio] make non-experimental
[gio] make non-experimental
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal enhancement
: 0.10.24
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 517137 579984 586939
Blocks: 588322
 
 
Reported: 2008-01-18 15:28 UTC by Sebastian Dröge (slomo)
Modified: 2009-07-11 16:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sebastian Dröge (slomo) 2008-01-18 15:28:45 UTC
Hi,
it would be nice if the gio plugin could be moved to gst-plugins-base for the next release. Not sure if gst/gio or ext/gio would be correct as gio is part of GLib, just needs a newer version than our lowest GLib requirement.

Tim suggested that we move the plugin right after the coming core/base releases and mark it experimental for now to prevent conflicts between bad and base.

The plugin has documentation (although not complete yet) and a test in tests/check/pipelines.

Bye
Comment 1 Jan Schmidt 2008-02-07 01:53:02 UTC
I'm OK with moving it to base as long as it is definitely marked experimental.

That means that it won't appear in the next -bad release at all, right?

I have no way to test it on gutsy. It would be nice if someone else who can run it would chime in with a +1 and confirm that it runs and is valgrind clean.

The docs do need a lot of beefing up. In particular, giostreamsrc and giostreamsink have the launch lines for giosrc/giosink, but all 4 elements need lots more.
Comment 2 Jan Schmidt 2008-02-07 23:23:29 UTC
Plugin moved to -base. I made an attempt at only building it with --enable-experimental, but can't test whether I got it right. Please check it.

This bug is now a blocker for the next -base release, pending updated docs and confirmation of valgrind cleanliness.
Comment 3 Jan Schmidt 2008-02-07 23:34:17 UTC
Oh, and I forgot to move the existing docs bits from docs/plugins - could someone do that?

Comment 4 Sebastian Dröge (slomo) 2008-02-12 09:26:10 UTC
docs and example code is now there and the docs are integrated into the build system again.

Now we only need someone to confirm that it's valgrind free and GLib 2.16.0 to stop it from being marked as experimental :)
Comment 5 Tim-Philipp Müller 2008-03-02 18:54:51 UTC
There's no glib-2.16 as of yet, and I'm not really convinced the gio plugin is ready yet for this (0.10.18) -base release. I'd suggest we punt this for now.
Comment 6 Bastien Nocera 2008-03-02 19:12:14 UTC
It's needed for Totem to work on samba shares (or even the trash) on GNOME 2.22. I guess it would be fine if it was only enable with the experimentals plugins.
Comment 7 Jan Schmidt 2008-03-04 00:03:50 UTC
We'll aim to mark it non-experimental for the 0.10.19 release then -> removing blocker marker.
Comment 8 David Zeuthen (not reading bugmail) 2008-03-04 07:16:07 UTC
Hi. Just FYI I tried this plug-in on cdda:// and gphoto2:// gvfs mounts and ran into an area of gvfs that remains to be implemented; we can't get the size of the file we're trying to play back. Which makes at least totem and totem-audio-preview not work with gvfs daemon mounts.

See bug 520244 for details.
Comment 9 David Zeuthen (not reading bugmail) 2008-03-04 19:15:51 UTC
As an update to comment 8: bug 520244 comment 8 shows playback from a gvfs source using a not-appropriate-for-mainline gvfs patch.
Comment 10 Sebastian Dröge (slomo) 2008-03-07 14:43:34 UTC
Ok, what still needs to be done for this element is:

a) some way of telling the application that it needs to mount the location, maybe with feedback to the element that mounting happened. Or some way of mounting inside the element and letting the application provide authentication data (currently impossible as mounting is only possible async and does things with the default main context).

b) Don't block in start() and stop(), opening and closing the stream may block and we need a way around this. Should be possible once bug #517137 is fixed by using async functions with our own main context and main loop.
Comment 11 André Klapper 2009-03-17 13:51:52 UTC
Are there plans to attack this again?
Comment 12 Tim-Philipp Müller 2009-03-17 14:31:50 UTC
> Are there plans to attack this again?

It stil needs new API in gio (so we can use a custom main context), and possibly new API in GStreamer for the async authentication stuff.
Comment 13 Benjamin Otte (Company) 2009-06-21 10:56:03 UTC
(In reply to comment #10)
> a) some way of telling the application that it needs to mount the location,
> maybe with feedback to the element that mounting happened. Or some way of
> mounting inside the element and letting the application provide authentication
> data (currently impossible as mounting is only possible async and does things
> with the default main context).
> 
Can't you make the gio elements have a GMountOperation property that can be set? If the mount operation is NULL, you fail if the file isn't mounted, if it is non-null, you assume a main context is there and do the async mount? This is not very friendly to apps without a main loop, but those will likely not use gio elements, will they?
Comment 14 Bastien Nocera 2009-06-21 11:24:01 UTC
(In reply to comment #13)
> (In reply to comment #10)
> > a) some way of telling the application that it needs to mount the location,
> > maybe with feedback to the element that mounting happened. Or some way of
> > mounting inside the element and letting the application provide authentication
> > data (currently impossible as mounting is only possible async and does things
> > with the default main context).
> > 
> Can't you make the gio elements have a GMountOperation property that can be
> set? If the mount operation is NULL, you fail if the file isn't mounted, if it
> is non-null, you assume a main context is there and do the async mount? This is
> not very friendly to apps without a main loop, but those will likely not use
> gio elements, will they?

That would be very very useful for Totem and Rhythmbox...
Comment 15 Sebastian Dröge (slomo) 2009-06-21 12:30:47 UTC
(In reply to comment #13)
> (In reply to comment #10)
> > a) some way of telling the application that it needs to mount the location,
> > maybe with feedback to the element that mounting happened. Or some way of
> > mounting inside the element and letting the application provide authentication
> > data (currently impossible as mounting is only possible async and does things
> > with the default main context).
> > 
> Can't you make the gio elements have a GMountOperation property that can be
> set? If the mount operation is NULL, you fail if the file isn't mounted, if it
> is non-null, you assume a main context is there and do the async mount? This is
> not very friendly to apps without a main loop, but those will likely not use
> gio elements, will they?

I guess that would be easy to do but would require blocking in open until the async callback is called
Comment 16 Sebastian Dröge (slomo) 2009-06-21 12:32:48 UTC
..and should be possible to get finished until July 6th (next core/base freeze).
Comment 17 Sebastian Dröge (slomo) 2009-06-24 10:14:05 UTC
I'm working on that now btw, Bastien, how do you want to use it in totem? Get the source of playbin2 and if it's giosrc set a GtkMountOperation? I'll probably use use totem as my test application with that approach ;)
Comment 18 Bastien Nocera 2009-06-24 11:22:56 UTC
(In reply to comment #17)
> I'm working on that now btw, Bastien, how do you want to use it in totem? Get
> the source of playbin2 and if it's giosrc set a GtkMountOperation? I'll
> probably use use totem as my test application with that approach ;)

Yes, something like that.
Comment 19 Sebastian Dröge (slomo) 2009-06-25 12:32:48 UTC
Implementing this is a problem because of some fundamental design issues or broken apps (depending on how you look at it), see bug #586939.

Apart from this I have the mounting implemented... and some other things fixed.
Comment 20 Sebastian Dröge (slomo) 2009-07-08 13:57:27 UTC
commit ce08823dc5bab446e07ecae0c78420751fd416d7
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Wed Jul 8 15:52:35 2009 +0200

    gio: Post a custom "not-mounted" message on the bus
    
    This allows applications to mount the GFile if possible and restart
    the pipeline instead of simply giving an error.


I also have a proof of concept patch for totem that uses this message but it needs some cleanup... I'll file a bug for totem with that patch later.
Comment 21 Sebastian Dröge (slomo) 2009-07-08 14:54:40 UTC
Bug #588079 contains the totem patch, this should be ready for committing now I guess.

Is there anything else to do before the gio plugin can be made non-experimental? :)
Comment 22 Sebastian Dröge (slomo) 2009-07-10 09:26:51 UTC
commit 29627032dc462697e8bd262c68bb93c8eb17ee98
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Fri Jul 10 11:24:57 2009 +0200

    gio: Remove the experimental status from the GIO plugin
    
    Fixes bug #510417.