GNOME Bugzilla – Bug 111511
audio preview should use gstreamer
Last modified: 2008-03-17 23:42:25 UTC
Attached a proof of concept hack to use gstreamer as audio player with the on mouse over music preview in Nautilus. Patched vs. nautilus 2.2.3, it now replaces the default implementation . If there's interest in doing it this way, i could do a cleaned up version with some input on what is important to change.
Created attachment 15981 [details] [review] nautilus icon view preview soundfile using gstreamer
Adding PATCH keyword, setting priority->high because of the patch, and also addding GNOMEVER2.2 and bugsquad keywords.
It looks interesting to me. Although we should probably make the gstreamer dependency compile-time optional. campd, what's your opinion? Also, we should probably reap the thread if its been idle for a while.
we should yes, right now that makes nautilus crash in some cases if you keep it on preview for a long time it seems (after song end).
Created attachment 20656 [details] [review] updated patch vs CVS HEAD
updated patch, now with configure switch ripped from totem mostly. confirmed to work with gst-0.6.3 Also supports flac if gstreamer supports it. Don't know how i should handle the reaping cleanly, so left that out.
Cc'ing thomasvs, who might want to look over the media bits. Anyway, I think this looks mad cool- hope it gets in (in 2.7 :)
*** Bug 47373 has been marked as a duplicate of this bug. ***
we're still thinking about the hover preview stuff - let's wait on this until we have that figured out.
Isn't bug #127872 a duplicate of this bug?
#127872 is about video playing, this bug is about audio playing. Any news on the patch? gstreamer is used by the desktop now, that would be nice to use it for the audio preview ... anybody who wants to update this patch?
*** Bug 308592 has been marked as a duplicate of this bug. ***
Gentoo actually patches nautilus 2.10.x to use gstreamer, maybe foser doesn't consider the patch good for inclusion yet.
does the patch use gstreamer from nautilus? If that's the code alex said it doesn't want such code because a gst bug would crash nautilus and not only the audio preview
Sebastien: Would be nice to get concrete information on that crasher. Using GST is a *MUST*, why else do we have such great streaming technology? :)
there is no known crasher, but running gst from the main thread would expose nautilus to gst bugs (ie: instead of crashing the preview you would crash the browser) that's probably why alex said he doesn't want to do that
This may seem silly, but why not just spawn gst-launch gnomevfssrc location=%s ! spider ! gconfaudiosink It might seem nasty to us an external binary, but this is effectively the same as forking and setting up a mainloop to run the same pipeline, with the advantage that gst-launch is known good code. I've tried it myself and it works fine; the only issue is locating the gst-launch binary (Gentoo calls it gst-launch-0.8, for example) but that can be done with some autoconf-fu, no doubt.
Created attachment 51016 [details] [review] audi-preview-gst-launch.patch Demonstration patch (against 2.11.91) to use gst-launch
Created attachment 51845 [details] [review] nautilus-2.12.0-gstlaunch.patch For 2.12.0. Also improved the pipeline to: gnomevfssrc location=%s ! spider ! audioconvert ! audioscale ! gconfaudiosink to be able to play audio files with other bitrate, bit depth etc.
Ed: 1) please use location="%s", in case the filename/uri has spaces 2) please use decodebin instead of spider, since spider will not detect the media type of some mp3 files (and is therefore deprecated) Otherwise, thanks!
Created attachment 51861 [details] [review] nautilus-2.12.0-gstlaunch.patch OK, switched to decodebin. Re the location="%s": I construct the argv with a GPtrArray rather than by parsing a command line; this means quotes, escaping, etc. aren't needed. The above pipeline is just schematic. Also added a patch to configure.in: AC_ARG_WITH([gst-launch],...)
You may want to add a fallback checking for gst-launch-0.8, since Debian (amongst others) does not appear to install gst-launch by default.
On a sidenote: gst-launch (at least for me) tries to run pipelines even if it lacks an element. This can lead to heavily crippled output. Maybe there is a way to prevent it from runing an incomplete pipeling, and returning an error instead?
Not that I know, you'll need to do some pre-checks on the relevant elements (gnomevfssrc, audioconvert, audioscale, sink, decodebin) inside the nautilus process to ensure it all works.
Ronald: Maybe they could be added to make it simpler for client apps, and for people who invoke it manually like me? I'd even find it more useful if we had a --force-incomplete option which forces continuing if the pipeline lacks elements and we defaulted to "do nothing but fail and complain".
Fine with me, but you'll need to open a new GStreamer bug (feature req.) for that.
I've filed bug 315383 against gstreamer.
Re comment 22: I'm using AC_PATH_PROGS(GST_LAUNCH_PATH, [gst-launch-0.9 gst-launch-0.8 gst-launch], no) so gst-launch-0.8 will be used if available.
*** Bug 127872 has been marked as a duplicate of this bug. ***
Updating bug information, milestoning to Nautilus 2.14.
I'm not sure whether gst-launch should be called directly. gst-launch is more regarded as a developer tool as far as I know. Of course calling gst-launch would appear to work independent of which GStreamer major version is used/installed (0.8 vs. 0.9/0.10), but in the end you'd have to decide for one or try both anyway, as the 'audioscale' element will be gone in 0.9/0.10 and be renamed to 'audioresample', for example. If stability is the main concern for spawning an external helper program (and rightly so probably), then why not just do a fork() + gst_parse_launch("my ! pipeline", &err) instead? Or maybe write a little GUI tool that spawns an audio preview helper dialog with a small seekbar or so? (That would also make it more apparent to the user that a program is running which possibly blocks the audio device). Cheers -Tim
Tim: Thanks for your comments. I agree that error handling could be made nicer if we forked a previewer. We should probably depend on gstreamer 0.9.
Missed feature freeze, milestoning to 2.16.
Created attachment 60086 [details] [review] Proposed patch Proposed prelimitary proof-of-concept patch for GStreamer. It does not launch an app but directly use the API, since GStreamer got more and more stable.
Making dependant on 333112. Testing revealed this GStreamer issue and as long as it isn't fixed we can't use it. Note that the proposed patch from comment 34 does not use a timeout, i.e. the playback instantly starts when you hover over a file, thus stress-testing GStreamer when quickly hovering over many files.
*** Bug 336931 has been marked as a duplicate of this bug. ***
We need some quick workaround! Soon it will be 4 year old bug. Why just not to launch gst-launch-0.10 playbin ! gconfaudiosink?
lets get this thing crackin! But a proposed patch and nothing done for an entire year in gnome kind of out dates it. Don't you think. I am not expert program. Pythons that best I got, but couldn't this progress just a little bit? At least once this year?
Sorry about the rather irrelevant comment, but I agree as far as new features / cleanups are concerned this should be a Priority (!) for the next release. Nautilus' current behaviour for audio previews does not sit well with Gnome's "Just work" mentality where one must inexplicably install mpg123 and cannot get previews for files that only gStreamer can understand. It also does not sit well with the idea that each program does one thing well. If we have 2 programs doing the same thing (gStreamer for video / audio playback, but for no reason mpg123/mpg321 for audio playback within Nautilus), that idea is injured. It also makes no sense because gStreamer should be promoted as a centralized solution! When something as big as the file manager is not using it where it could and should, there is something wrong. Sorry in advance about the following misuse of Bugzilla: With gStreamer doing previews, would it be possible to do an audio preview with a video file? It could work well as an extra bonus that is visible to everyone. A lot of the time, all one really needs to recognize a video is a bit of sound from it. (And on the other hand, a full video preview could be rather painful).
Looks like this has been picked up again by the Red Hat guys at bug 486827. You may want to cc yourselves there.
*** This bug has been marked as a duplicate of 486827 ***