From: Steve B. <st...@st...> - 2003-04-24 02:49:17
|
I have a proposal to add auto-detection of audio and video sinks to the libgstgconf helper library. There will be two new gconf keys, autodetect_audiosink and autodetect_videosink. When autodetect_audiosink is false, a call to gst_gconf_get_default_audio_sink will do what it does now - return a bin built from the audiosink gconf key. When autodetect_audiosink is true an attempt is made to create number of audio sink pipelines. As soon as one succeeds it is returned as the default bin. The order of trying for now will be: - alsa - oss - esound - any others? The pipeline will be fakesrc ! fooaudiosink and it will be played with 1 buffer of silent 2 channel 16 bit 44100Hz audio. When autodetect_videosink is true the following will happen: - if Xv exists, return (xvideosink) - if sdlvideosink exists, return (sdlvideosink) (not until it becomes embeddable) - else, return (colorspace ! rescale ! xvideosink disable-xv=true) Eventually audiosink and videosink gconf keys could be empty by default and could be populated the first time the auto-detection code is run. One thing I'd like to get some opinion on is adding GError to all the public methods of libgstgconf. It breaks API, but I think the higher-level code needs detailed errors rather than just null return values. Finally, there will eventually be new methods which would return a list of viable sink pipelines ordered by preference. This could be used by an Audio & Video capplet so users can change their sink. I've started this work now so any suggestions are welcome. cheers -- Steve Baker <st...@st...> |
From: Bastien N. <ha...@ha...> - 2003-04-24 09:01:49
|
On Thu, 2003-04-24 at 03:48, Steve Baker wrote: > I have a proposal to add auto-detection of audio and video sinks to the > libgstgconf helper library. > > There will be two new gconf keys, autodetect_audiosink and > autodetect_videosink. > > When autodetect_audiosink is false, a call to > gst_gconf_get_default_audio_sink will do what it does now - return a bin > built from the audiosink gconf key. > > When autodetect_audiosink is true an attempt is made to create number of > audio sink pipelines. As soon as one succeeds it is returned as the > default bin. The order of trying for now will be: > - alsa > - oss > - esound > - any others? > > The pipeline will be fakesrc ! fooaudiosink and it will be played with 1 > buffer of silent 2 channel 16 bit 44100Hz audio. > > When autodetect_videosink is true the following will happen: > - if Xv exists, return (xvideosink) > - if sdlvideosink exists, return (sdlvideosink) (not until it becomes > embeddable) > - else, return (colorspace ! rescale ! xvideosink disable-xv=true) > > Eventually audiosink and videosink gconf keys could be empty by default > and could be populated the first time the auto-detection code is run. > > One thing I'd like to get some opinion on is adding GError to all the > public methods of libgstgconf. It breaks API, but I think the > higher-level code needs detailed errors rather than just null return > values. > > Finally, there will eventually be new methods which would return a list > of viable sink pipelines ordered by preference. This could be used by an > Audio & Video capplet so users can change their sink. > > I've started this work now so any suggestions are welcome. Wicked, this is one of the major problems with Totem-gst (error reporting). I would actually prefer it if the library could return error codes rather than GErrors, because until gst makes the move to gnome cvs, it will have poor i18n compared to a component that is in there. Thanks for working on that Steve -- /Bastien Nocera http://hadess.net #2 0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from /lib/i686/libc.so.6 printf ("Oh my %s\n", preferred_deity); Segmentation fault |
From: Thomas V. S. <th...@ur...> - 2003-04-24 10:00:36
|
Hey Steve, > > One thing I'd like to get some opinion on is adding GError to all the > > public methods of libgstgconf. It breaks API, but I think the > > higher-level code needs detailed errors rather than just null return > > values. > > > > Finally, there will eventually be new methods which would return a list > > of viable sink pipelines ordered by preference. This could be used by an > > Audio & Video capplet so users can change their sink. > > > > I've started this work now so any suggestions are welcome. > > Wicked, this is one of the major problems with Totem-gst (error > reporting). I would actually prefer it if the library could return error > codes rather than GErrors, because until gst makes the move to gnome > cvs, it will have poor i18n compared to a component that is in there. Yep, I've had the same worries at that time. I didn't implement anything because I already had set that API without thinking about error handling and then I probably forgot about it when we had a chance to change it. Here are my suggestions: a) instead of breaking api, we could name the error-returning functions *_error () and implement the non-error-returning functions based on this. This would allow apps to be buildable against both 0.6 and 0.7 (since 0.6 doesn't allow API breakage). We could then mark the original ones as deprecated and to be removed for 0.8. Alternatively, you can invent totally new names as well for these functions. I just want to avoid not being able to compile against stable, so that these functions can be added in 0.6.x and used by apps that are "stable". (I personally think it's unlikely we'll have a good 0.8.x series in time for gnome 2.4.x, btw, so this is why I'm making this point) b) on returning GError vs numerical error (I suppose we're talking about a final argument pointer, right ?) I used to want to also have numerical errors for the same reason; OTOH, that would cause every one to invent their own message for the problem at hand and that would be a lot of duplication of effort and probably lead to bad error messages :) Also, I don't want libgstplay moved to gnome cvs because it should be kept generic and under gst's control. So the idea I had back then would be to i18n the lib, use GError's, and create a gnome-cvs module for libgstplay that would contain translations only, with a script in our gst cvs to sync from that and commit. I've been told that translators actually do not run all the software they translate, so this is not a problem. What do you think ? Thomas -- The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/ <-*- thomas (dot) apestaart (dot) org -*-> yes i am a long way from home <-*- thomas (at) apestaart (dot) org -*-> URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/ |
From: Gustavo J. A. M. C. <gj...@in...> - 2003-04-24 11:27:12
|
A Qui, 2003-04-24 =E0s 10:03, Bastien Nocera escreveu: > Wicked, this is one of the major problems with Totem-gst (error > reporting). I would actually prefer it if the library could return erro= r > codes rather than GErrors, because until gst makes the move to gnome > cvs, it will have poor i18n compared to a component that is in there. You are forgetting that GError contains an error code already, in addition to the error message. If you want, you can ignore the string representation of the error and generate an error message yourself, based on the error code. --=20 Gustavo Jo=E3o Alves Marques Carneiro <gj...@in...> <gu...@us...> |
From: Benjamin O. <in...@pu...> - 2003-04-26 16:27:04
|
On 24 Apr 2003, Steve Baker wrote: > There will be two new gconf keys, autodetect_audiosink and > autodetect_videosink. > Quick question: Would it make sense to autodetect on an empty string instead of adding a boolean property? > When autodetect_audiosink is true an attempt is made to create number of > audio sink pipelines. As soon as one succeeds it is returned as the > default bin. The order of trying for now will be: > - alsa > - oss > - esound > - any others? > Correct behaviour is checking for sound servers first and then using native plugins, I think. It should probably check for arts, too (if we have a working artssink, do we?) > The pipeline will be fakesrc ! fooaudiosink and it will be played with 1 > buffer of silent 2 channel 16 bit 44100Hz audio. > > When autodetect_videosink is true the following will happen: > - if Xv exists, return (xvideosink) > - if sdlvideosink exists, return (sdlvideosink) (not until it becomes > embeddable) > - else, return (colorspace ! rescale ! xvideosink disable-xv=true) > If people have a videocard without Xv support they probably don't have a performant computer either. Added to this is the fact that there is no way i know that would make rescale adjust window sizes on window resizes without weird hacks. For those reasons I wouldn't use the rescale stuff and do it like mplayer: no scaling. > Eventually audiosink and videosink gconf keys could be empty by default > and could be populated the first time the auto-detection code is run. > I don't think it's a good usability idea to let apps change gconf keys without the user requesting it. |
From: Steve B. <st...@st...> - 2003-04-26 21:17:52
|
On Sun, 2003-04-27 at 04:26, Benjamin Otte wrote: > On 24 Apr 2003, Steve Baker wrote: > > > There will be two new gconf keys, autodetect_audiosink and > > autodetect_videosink. > > > Quick question: Would it make sense to autodetect on an empty string > instead of adding a boolean property? Maybe, but I was thinking that people could switch between auto-detection and whatever wacky custom pipeline without deleting their custom pipeline when they switch back. > > When autodetect_audiosink is true an attempt is made to create number of > > audio sink pipelines. As soon as one succeeds it is returned as the > > default bin. The order of trying for now will be: > > - alsa > > - oss > > - esound > > - any others? > > > Correct behaviour is checking for sound servers first and then using > native plugins, I think. It should probably check for arts, too (if we > have a working artssink, do we?) If the ESD_NO_SPAWN thing works then I'll try this. I don't know the status of the artssink - I suspect its bitrotten. > > When autodetect_videosink is true the following will happen: > > - if Xv exists, return (xvideosink) > > - if sdlvideosink exists, return (sdlvideosink) (not until it becomes > > embeddable) > > - else, return (colorspace ! rescale ! xvideosink disable-xv=true) > > > If people have a videocard without Xv support they probably don't have a > performant computer either. Added to this is the fact that there is no way > i know that would make rescale adjust window sizes on window resizes > without weird hacks. For those reasons I wouldn't use the rescale stuff > and do it like mplayer: no scaling. It would be nice if rescale worked but it will be left out until it does. Couldn't xvideosink change its caps when it gets resized? There could be another option without rescaling for people with slow PCs. > > Eventually audiosink and videosink gconf keys could be empty by default > > and could be populated the first time the auto-detection code is run. > > > I don't think it's a good usability idea to let apps change gconf keys > without the user requesting it. Fair enough, but I would have thought an auto-detected default would be better than an empty one. It would only get populated if empty. -- Steve Baker <st...@st...> |
From: Benjamin O. <in...@pu...> - 2003-04-28 11:36:39
|
On 27 Apr 2003, Steve Baker wrote: > It would be nice if rescale worked but it will be left out until it > does. Couldn't xvideosink change its caps when it gets resized? > It would be possible to call try_set_caps with new sizes and see if the peer of xvideosink accepts them. I don't know if this might cause issues with other plugins that can't change sizes (imagine using mpeg2dec ! xvideosink) but you might try. And it has the problem that resizing inside the pipeline would always be preferred to resizing by the videosink. That is videotestsrc ! rescale ! xvideosink would be rescaled by the rescale plugin even if xvideo was enabled. That's why this basically requires QoS and that is not implemented. So I wouldn't want to tackle it but if someone volunteers: Go ahead. Cheers, Benjamin |
From: David S. <ds...@sc...> - 2003-04-30 21:03:24
|
On Mon, Apr 28, 2003 at 01:36:20PM +0200, Benjamin Otte wrote: > On 27 Apr 2003, Steve Baker wrote: > > > It would be nice if rescale worked but it will be left out until it > > does. Couldn't xvideosink change its caps when it gets resized? > > > It would be possible to call try_set_caps with new sizes and see if the > peer of xvideosink accepts them. > I don't know if this might cause issues with other plugins that can't > change sizes (imagine using mpeg2dec ! xvideosink) but you might try. If it doesn't work, it's a bug. :) It should work for videoscale since I recently rewrote it. > And it has the problem that resizing inside the pipeline would always be > preferred to resizing by the videosink. That is videotestsrc ! rescale ! > xvideosink would be rescaled by the rescale plugin even if xvideo was > enabled. Not really. If xvideosink can rescale internally, it should always advertise a range of sizes, and videoscale will work as an identity. The problem arises when xvideosink can't scale. Then you have to add an extra parameter -- do you prefer 1) the x window to resize to the size of the video, 2) the video be scaled to the size of the window, or 3) the video be centered, with black around the borders. Each of these _individual_ cases have well-defined capabilities, being 1) height,width=range 2) height,width=size of window, and 3) height,width=range. Trying to mix these policies is where the problems arise, I think. dave... |