[vlc-devel] [Patch] Sending a signal when a vout is?created/destroyed

[Laurent Aimar]

Hi,

On Tue, Jan 26, 2010, Rémi Denis-Courmont wrote:
> Le mardi 26 janvier 2010 22:04:25 Laurent Aimar, vous avez écrit :
> > > <beauze.h at gmail.com> wrote:
> > > > This patchs adds a libvlc_MediaPlayerVoutChanged event, that let an
> > > > application using libvlc know when a vout has been created.
> > > > This can be usefull when trying to know the width or height of a
> > > > media, using libvlc_video_get_width/height, as these functions
> > > > immediatly return when no vout has been spawned.
> > >
> > > It's none of the LibVLC application business when a video output is
> > > created; that's an internal implementation detail. It should only care
> > > that there is a new elementary stream. Hence I think that event does not
> > > deserve to exist.
> > 
> >  I don't agree (completly) with you. It is usefull to know when a vout
> > exists to know when to present some options to the users like:
> >  - snapshot.
> >  - video filters.
> >  - deinterlace configurations.
> 
> Snapshot maybe. But configuring video filters in general and deinterlacing in 
> particular shouldn't be dependent on the existence video output. That just 
> creates more unnecessary event handling boilerplate for each and every LibVLC-
> based application.
> 
> To me, the fact that so many video and audio functions in the LibVLC API fail 
> or misbehave if the video or audio output does not (yet) exist is a bug and an 
> annoyance.
 I don't disagree here, but you missed my point.
 I am talking about what you show to a end user user (someone with a mouse in his
hand and who clicks on a GUI).
 I think that hidding buttons (on the GUI control part) when they have no meaning
for the current state is a good thing, and that include snapshot/deinterlace and
maybe some filters. It is unrelated to what a GUI will also show in its menus or in
its preferences.

> And in fact, there is absolutely no fundamental reason for those 
> limitations to exist. For instance, we can the video-filter variables on the 
> input (or even the instance) object. And *if* there is an active video output, 
> then we can also tell it to update its current state.
 I agree, but won't happen for 1.1. There is a more general discussion to have
on this one, but it is not related to what I am talking about.

-- 
fenrir