GNOME Bugzilla – Bug 517993
pipeline-tester should not be hardcoded to ALSA
Last modified: 2008-09-04 18:05:16 UTC
Regarding: /usr/share/gst-python/0.10/examples/pipeline-tester I also notice ALSA is hardcoded into the GStreamer Pipeline tester in examples/pipeline-tester. Note test "Sound capture via ALSA" and "Reencode Vorbis to mulaw, play via ALSA", and "Streaming Ogg/Theora+Vorbis playback, tee to disk. Shouldn't these tests check whatever sink & source you have defined on the system and use those? These tests seem to work okay if I hardcode them to use osssrc and osssink rather than the ALSA ones. I also see a few problems running pipeline-tester: The "Software scaling" test complains "Could not create pipeline. could not link videoscale1 to ximagesink3. Not sure why this is failing. The "Reencode Vorbis to mulaw, play via alsa" does not work if you run the /usr/share/gst-python/0.10/examples/pipeline-tester (rather than running the version in the source tree), complaining it can't find the file cooldance.ogg Considering the file is only 74K (only twice as large as the remuxer.py example), perhaps installing this ogg file to the examples directory would be nice. The "Streaming Ogg/Theora+Vorbis playback, tee to disk" test fails if you run it from a directory where you don't have write permissions, like if you cd to /usr/share/gst-python/0.10/examples, and run pipeline-tester. Might be nice if the test did a change-directory into the /tmp directory or something to do this test. The V4L and DV tests only work if you have these plugins installed, which are not present currently on Solaris. Might be nice to disable these choices if the plugins are not present. Whenever some tests fail (such as the "Streaming Ogg/Theora+Vorbis playback, tee to disk" failure mentioned above), the Stop button doesn't change to a Play button. This is annoying since it means you have to stop and restart the test program to run any further tests.
I also notice that several of the tests fail on Solaris Sparc because Xvideo is not supported. I find that if I change "xvimagesink" to "ffmpegcolorspace ! ximagsink" that the tests work even on machines that do not support Xvideo. Another issue is that the "Sound Capture via ALSA" test hardcodes the endianness=1234, so this makes the test fail on big-endian machines like Sparc. Does this need to be hardcoded? The software scaling test seems to not work because videoscale method=2 only works on I420. Perhaps a different test that works on other machines would be better here? Ignore my comment about "Reencode Vorbis to mulaw, play via alsa" test not being able to find cooldance.ogg. I didn't realize you had to run the "tee to disk" test first to create the file. It might be nice if this were more clear that you need to run the tee test first. Perhaps the "Reencode Vorbis to mulaw, play via alsa" test could be nicer and check for the file and pop-up a dialog explaining you need to run the other test first.
I see that changing endianness=1234 to endianness=(int)BYTE_ORDER fixes the sound recording test so it works on both little and big endian machines.
Created attachment 106741 [details] [review] patch making things work on Solaris This patch isn't exactly right since it just changes the hardcoded alsasrc/alsasink to sunaudiosrc/sunaudiosink, however it does show the changes I made to change "xvimagesink" to "ffmpegcolorspace ! ximagesink" so the tests work on machines that don't support Xvideo. It also shows the endianness fix.
Note that the attached patch also saves and reads the cooldance.ogg file to /tmp rather than the current working directory since users probably want to run the script from the /usr/share/gst-python/0.10/examples directory where they probably don't have write permission. Saving to /tmp makes more sense I think. It also saves the dv.ogg file to /tmp in the "Capture DV via firewire, transcode to Ogg" test.
that patch is a collection of random modifications... which will not make it any better that previously (no, replacing alsasrc by sunaudiosrc is not acceptable).
Edward, I explained when I attached the patch that it was just an example showing how things work on Solaris. I realize that it doesn't make sense to replace alsasink with sunaudiosink. However, I was hoping these changes could go upstream: - changing "xvimagesink" to "ffmpegcolorspace ! ximagesink" This is needed so the script works on machines that don't support XVideo - Fixing endianness from "1234" to "(int)BYTE_ORDER" This should be obvious. Why hardcode the endianness when it is not necessary? These two changes seem appropriate. They just make the script work better if using different architectures. If you would like, I could create a patch with only these changes. Could these two changes, at least, go upstream? I guess I'm surprised that ALSA has to be hardcoded, I would have thought that the python interfaces would make it easy enough to get the default source and sink. I am not sure how to do this, or I would have updated the patch to work this way.
Created attachment 117500 [details] [review] improved patch This patch removes references to "Sun Audio" and just doesn't specify the audio device to use. No real need. I also updated the patch to use "gconfaudiosink" and "gconfaudiosrc" instead of specifying a particular audio sink and source (like ALSA or Sun Audio specific ones). I think this addresses the issues with the previous patch, and is now appropriate for going upstream. Should work for all distros now.
*ping* Can this now go upstream?
We're just 'widening' the scope a bit more by depending on gconf instead of alsa, no ? For sinks, we should use auto[audio|video]sink For sources... well... not much we can do apart from using gconfaudiosrc (we really need auto*src). 2008-09-04 Edward Hervey <edward.hervey@collabora.co.uk> * examples/pipeline-tester: Don't hardcode audio/video source and sinks, and instead use more generic sources. Based on a patch by Brian Cameron <brian.cameron@sun.com> Fixes #517993
Right, but it's good to widen the scope a bit. Hardcoding so it only works on ALSA sucks. Using the gconf plugins is nicer. If/when the auto plugins are ready, I'm also happy if we use those. Thanks for fixing this.