Re: [gst-devel] auto-detecting sinks

[David Schleef <ds@sc...>]

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...

[gst-devel] auto-detecting sinks

[Steve Baker <steve@st...>]

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 <steve@...>

Re: [gst-devel] auto-detecting sinks

[Bastien Nocera <hadess@ha...>]

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

Re: [gst-devel] auto-detecting sinks

[Thomas Vander Stichele <thomas@ur...>]

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/

Re: [gst-devel] auto-detecting sinks

[Gustavo J. A. M. Carneiro <gjc@in...>]

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
<gjc@...> <gustavo@...>

Re: [gst-devel] auto-detecting sinks

[Benjamin Otte <in7y118@pu...>]

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.

Re: [gst-devel] auto-detecting sinks

[Steve Baker <steve@st...>]

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 <steve@...>

Re: [gst-devel] auto-detecting sinks

[Benjamin Otte <in7y118@pu...>]

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

Re: [gst-devel] auto-detecting sinks

[David Schleef <ds@sc...>]

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...