GNOME Bugzilla – Bug 424157
Provide gst_play_audio_file
Last modified: 2009-06-18 21:56:10 UTC
GStreamer often is called too complicated and heavy for simple usage. Considering that there is this great playbin element, I believe this assumption is wrong. All that GStreamer needs for overcoming this wrong picture is a simple API like this: gboolean gst_play_file (const gchar *filename, GError **error); Filename would be the absolute path to a file GStreamer can handle. The function returns TRUE on success and FALSE on failure. Having such a function, hello-gst.c would be reduced to this trivial snipped of code: int main (int argc, char *argv[]) { GError *error = NULL; gst_init (&argc, &argv); if (argc < 2) { g_print ("Usage: %s FILENAME\n", argv[0]); return 1; } if (!gst_play_file (argv[1], &error)) { g_warning (error ? error->message : "Unknown error"); g_clear_error (&error); return 1; } return 0; } My assumption and hope is, that this function would greatly extend usage of GStreamer as nobody could argue any more, GStreamer would be too complicated for his/her simple application. See also: Bug 424143, Project Ridley.
Created attachment 85517 [details] Sample implementation of gst_play_file Hope I've got it right: I am clearly no GStreamer expert.
I'm not convinced of the usefulness of this. Sure, it's good for a simple hello world program, but in order to integrate it into a gtk app, for example, you need to deal with: - where the video output should go - how to handle play/pause/stop buttons - how to integrate into the glib main loop - how to handle URIs - how to handle missing codecs
(In reply to comment #1) > Created an attachment (id=85517) [edit] > Sample implementation of gst_play_file > > Hope I've got it right: I am clearly no GStreamer expert. > Playing videos, controlling playback, network access, weird codecs is not the scope of this tiny function. Purpose I have in mind for this function is just playing simple audio samples you have somewhere on your disk. That primitive stuff you have in /usr/share/sounds. Had that idea, when some folk on GTK+ asked about how to do this. If he shall use plain Alsa, or Jack, or ESD, or libaudiofile, or even directly write to /dev/dsp? And I thought: Hell, there we have this fine media framework, and you cannot even use it for this trivial usecase of playing a fixed audio snippet, as its API is far too complicated for this trivial use case. As sound as you want to do more complicated stuff involing pause, stop, remote files, then the regular API of GStreamer is just fine for my taste. Well - I know, I repeat myself - for the trivial, but common usecase of just playing a audio sample, current GStreamer API is pure overkill. Adding that trival function could greatly improve utility of GStreamer. As you raised the main-loop issue. Also thought about this already. Have not found a good solution yet.
Ok, I misunderstood what you said in #1, then. I agree, a dirt simple audio player would be easy and beneficial for anyone trying to migrate away from audiofile, etc. Main loop integration for such a case is fairly easy (in pseudocode): gst_play_audio_file() { set up pipeline add idle handler to main loop set pipeline to PLAYING return object } idle_handler() { get bus message handle bus message if in error state, fire error signal if done, fire done signal if not done, re-add idle handler } In this case, gst_play_audio_file() returns immediately, and the app can wait for the "done" signal if it wants. Or, there could be a separate waiting version.
Indeed! Using g_idle_add fills the gap and letting gst_play_file return a object provides a clean path for future extensions, if there should be requests for getting slightly more control.
Created attachment 85577 [details] gst-player.c
Created attachment 85578 [details] gst-player.h
Created attachment 85579 [details] hello-gst.c
*** Bug 439091 has been marked as a duplicate of this bug. ***
for me playbin is easy enough to be used. and it already provides close-to-play-file api. just having play-fille is too simple even for simple case like providing preview in file-chooser.
(In reply to comment #10) > for me playbin is easy enough to be used. and it already provides > close-to-play-file api. just having play-fille is too simple even for simple > case like providing preview in file-chooser. Yes, playbin is easy when you took the time to learn the concepts of GStreamer. You'll agree that learning those concepts can take some hours - depending on your background. In opposition to that gst_play_file shall provide a convenient API for those who want to play a simple notification sound without caring much about having a complete audio framework. In case they realize later that they need the framework they know which one to use ;-)
Btw, when reading the entire report again: s/gst_play_file/gst_play_audio_file/
Matthias, please don't get me wrong, but I belive in most cases it would be too simple. Could you share with use what use-cases you have in mind? I could only think of sound-events, but they should be done via e.g. libnotify or the libcanberra proposal (from the pulseaudio developer).
*** Bug 505401 has been marked as a duplicate of this bug. ***
Stefan, libcanberra seems to be stuck in the proposal stage if I look at SVN [1] Is linking to a library like libnotify not a bit overdone if you just want to have a sound event. Furthermore libnotify is not a part of the GNOME desktop Can you explain why you think a very basic API that plays audio files does not belong in gstreamer? For a programmer not familiar with gstreamer that just wants to add a sound event to it's program using a playbin is not trivial. Jaap [1] http://svn.0pointer.de/viewvc/trunk/?root=libcanberra
@Jaap: I have no problem with simple APIs but adding them to the GStreamer core is not a good idea for the same reason GTK+ does not have an API for a simple text editor. I believe we should have a simple API for common things, like the audio playback example and I also believe it should go into a library, other than GStreamer, that does this. For events you also typically want to cache them serverside (to reduce latency and CPU, especially in embedded devices and thin clients). The above simple API on top of playbin then needs to be extended some more (it also does not handle the cases where you have an error while playing). I'm willing to add this as an example object that demonstrates how to shuffly around signals, GError and encapsulate multiple GStreamer objects, but going as far as promote this as the blessed 'ding'-API is not going to happen.
Wim, I see your point. In that case a library like libnotify is indeed a better idea. I filed a bug on libnotify http://trac.galago-project.org/ticket/153
Let's WONTFIX this. There's certainly a niche for such a small helper function/lib somewhere, but I don't see it being added anywhere in GStreamer any time soon, especially not now that there's libcanberra, which is also a much better choice for this kind of thing.
(In reply to comment #18) > Let's WONTFIX this. There's certainly a niche for such a small helper > function/lib somewhere, but I don't see it being added anywhere in GStreamer > any time soon, especially not now that there's libcanberra, which is also a > much better choice for this kind of thing. > ACK. Came to exactly the same conclusion when I saw the bug notification in my mailbox.