Re: GStreamer regression analysis [was: GNOME and GStreamer]

[Thomas Vander Stichele <thomas apestaart org>]

Hi,

thanks for the feedback, Ronald.

I'm only going to discuss gnome-media for this mail, I'm personally not
working on the totem backend atm.


> Part 2, gnome-media
> 
> didn't build for me, requires some more patches to be 0.10 aware.

If this was the GSR_CFLAGS issue, that's been fixed.

> gstreamer-properties:
> - should be moved back to some behind screen, since gst now contains
> autodetection elements and most, if not all, users will no longer need
> gstreamer-properties.

Personally, I feel:
- gnome apps should keep using the gconf elements
- the gconf elements could default to audiotestsrc
- gstreamer-properties should probably stay around for another cycle
until audiotestsrc has proven itself.

audiotestsrc doesn't handle a lot of cases correctly yet; it will never
use esdsink (there's no implementation for sound servers yet in the
code, last time I checked); and a lot of people still have problems with
alsa and dmix, which get solved by using alsasink device=hw:0

I'd lean towards removing gstreamer-properties when audiotestsrc has
actually received some real-world testing with 0.10.
>From what we can tell on irc, most people that had lots of issues with
alsasink in 0.8 are happy with the 0.10 version.


> gnome-sound-recorder:
> - vorbis audio recording does not work. MPEG-4/AAC audio recording is no
> longer available. FLAC/WAV works fine, and MP3 (once added in
> media-profiles) appears to work also.

Looks like Tim was right - it was using the old schemas.  To make sure
this doesn't happen in the future, I've versioned the gconf keys, just
like the ones in -base.  I should have done this when I originally added
them, but hey :)

> - playback is broken for all formats.

Tim is looking into it.

> - Totem hangs on EOS for all files created by g-s-r, unsure if that's
> related to the earlier hang-bugs or a file creation bug.

Haven't tried this yet - will try.

Other modules beside gnome-media have a configurable backend choice, so
those modules are fine as they are - distributors that are currently
working on GStreamer 0.10 can choose to build them with it.

For gnome-media, a patch to enable it from configure would get really
ugly.  Here's my suggestion:

- a patch gets made from the 0.10 branch
- this patch gets commited to HEAD, with a one-liner command to run
before autogen

This should be acceptable for all - the tarball that gets shipped
contains code to build against 0.8 and 0.10 and is acceptably easy to
build either way.  In practice, the shipped tarball would be close to
identical to the 2.12.0 release (very few changes were made).  But it
would allow the port to be tested by users.

Ronald, does that sound acceptable ? Release team ?

I'm ready to roll a release, because I'd like to get some wider testing
by interested parties (Fedora, Ubuntu, ...)

There's still a good five hours left before the deadline; if that gets
missed, I'd appreciate the release team giving an extension on this
issue, but of course I'll accept any decision otherwise from the release
team.

Thanks
Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
We did it by the door
We did it on the floor
how about tonight, maybe
we do it some more ?
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/