[gst-devel] Gran Canaria meeting notes

[Bastien Nocera]

On Fri, 2009-11-27 at 09:28 +0100, Edward Hervey wrote:
> Hi,
> 
> On Thu, 2009-11-26 at 18:55 +0000, Bastien Nocera wrote:
> > On Sat, 2009-11-14 at 16:21 +0100, Thomas Vander Stichele wrote:
> > > == GStreamer 1.0 ==
> > > Possible items:
> > > * Easier installations for other platforms
> > >   - Windows and OS/X installs
> > 
> > I'd definitely be interested in making Totem and Rhythmbox work better
> > on MacOS X (for which I actually have test machines).
> 
>   IIRC, I think we were talking about SDK and installation systems for
> those platforms. Some alternatives have starting popping up for windows
> (which enable you to create a 'package' of an application, like
> winbuilds), but macosx is still a grey area.
>   Getting a gst/gtk application to work on windows/macosx is one thing
> (which surprisingly isn't all that hard nowadays codewise).... getting
> it bundled/shipped in an easy way is a whole new world of pain though.

Agreed. Richard Hult showed me a running Totem on MacOS X at the GUADEC
in Istanbul, with a couple of one-liner patches, and there's also
patches available for totem-pl-parser and Totem itself in Bugzilla for
Windows.

Getting the build system ready to test Totem would probably be easier
than getting a user-ready installer.

> > <snip>
> > > == Supporting KDE/Qt better ==
> > > * Need examples of GMainloop/QtMainloop examples
> > > * Widget examples
> > > * applies to OS/X and Windows too - provide more platform example code
> > 
> > Should some parts of Totem's video widget be moved into playbin2, or
> > something on top of playbin2?
> 
>   On top of playbin2 would make more sense imho, like a convenience
> high-level library for playback handling everything you mentionned
> underneath and handle it in a cross-platform way.
>   Making higher-level convenience libraries (like quicktime does on
> macosx) is a noble goal to achieve for 1.0, easening the integration of
> GStreamer in various applications wanting to playback content without
> caring about all the gstreamer tidbit/details.
> 
> > 
> > There's things like:
> > - logo handling (a "rest" image for the movie player, and the main way
> > to show errors in the browser plugin)
> 
>   This *could* be added to playbin2... but not 100% certain whether
> everybody wants that. Might be better handled in the viewer widget part
> (i.e. in convenience lib).

Fair enough

> > - Parts of the missing-plugins code (Totem offers to play video with no
> > sound, but not the contrary, Totem's audio preview, as used by nautilus,
> > will play the sound even if the video can't be handled)
> 
>   Couldn't we add some
> 'missing-video-acceptable'/'missing-audio-acceptable' flags to playbin2
> for that ?

Probably not quite flexible enough, though I can't put my finger on why
right now.

> > - Better error reporting
> 
>   What do you have in mind ? collecting error messages (and maybe other
> events/signals/...) and reporting a reduced set of user-visible error
> messages specific to playback ?
>   Are there some inconsistencies in error messages that we could fix in
> lower levels ?

This is a long standing problem with the GStreamer backend compared to
the old xine-lib one in that the types of errors were far and few in
xine-lib thus the error messages were targetted at end-users.

> > - Tags, subtitles and audio tracks handling
> 
>   That would be nice in the convenience library.
> 
> > - Seeking based on time
> 
>   Err... because we're doing seeking based on bananas-per-square-mile
> right now ? What do you mean by that ?

Huh, being thick :)
The code in Totem doesn't make use of it, but it's available, I should
change Totem to use that now...

> > - Handling of tick signals
> 
>   what do you mean by that ?

Right now, I need to poke at the running playbin a couple of times a
second myself. It would be easier if playbin itself had a tick signal,
and handled emission itself.

> > - Make it easier to test whether a sink is available
> 
>   What do you have in mind with that ? Using auto*sink should remove the
> need for the user to know/need that.

In GNOME apps, we use gconf{audio,video}sink so users can debug eventual
problems with those and set the profile in gstreamer-properties.

This is needed to set the profile on gconfaudiosink. Maybe this is not
needed any more...

This also means we need to check whether the output is available to
present an error message to the user.

> > - Setting visualisations needs a lot of trickery
> 
>   Even with current code in playbin2/playsink ? What's missing ?

Look at "setup_vis()" in the GStreamer backend.

> > - Get/Set video output properties (contrast, brightness, etc.)
> 
>   Yup, proxying to a convenience library would be nice for that.

Cool.

> > - Capturing a single frame from a video
> 
>   Same comment as above.

So, where would I move all this code? :)

Cheers