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

[Thomas Vander Stichele <thomas apestaart org>]

Hi Luis,


> I've bit my tongue so far in this thread, but this really sort of
> irritated me. End users do not know or care that the version is being
> improved/worked on. What they definitely do see is regressions- 'I
> upgraded and now I have fewer features and fewer things work.' No
> normal user will think 'I upgraded and now the software is shittier,
> but hey, I'm sure that means that in six months it'll be better!' To
> think that end users will understand why their software suddenly works
> less well is insane and, frankly, I think it is indicative of a
> long-standing problem in the gstreamer project where the focus is more
> strongly on the core technology than the actual user experience.

Thanks for being frank.  A reality check is always appreciated :)

>From an outsider's POV, I'd be inclined to agree if the premise was that
0.8 was completely stable.  The reality is simply that there are
low-level issues in the 0.8 core that cannot be fixed in 0.8.  The
number one issue here is threading.

While a lot of careful hackery has gone on in 0.8 to alleviate the worst
pains, bugzilla is still filled with random crashes, segfaults, and
thread issues.  They're never going to get fixed in 0.8 because the API
doesn't allow it to be fixed.

Getting the core technology settled was indeed the focus of this release
cycle, from the start on out.  The incredible support burden of having
mountains of plugins holding us back making the tough choices that were
made was addressed by splitting up the modules for plugins.  This was
widely announced, as well as the reasons for it.  I think this worked
well for us as a team - it allowed us to concentrate on abstracting out
the good bits of all these plugins, and put them where they belong.  I'm
sure there's lots of work to be done still, but it's work to be done in
the plugins.

In practice, this means that whatever the next stable series will be, it
will not involve a major reworking of the core API.

> From what I can see, the real problem here is that gstreamer 0.10 is
> really an api-frozen development branch still, which may be suitable
> for server use with some codecs but is not an actual
> feature-comparable end-user stable release. I'd urge everyone to
> re-read this thread substituting 'api-stable development branch' for
> '0.10' and see if it changes their thinking.

I think you're reasoning from a perspective that sees "gstreamer" as one
whole.  GStreamer 0.10 is not a development branch, it is stable.  In
practice, this means we take great care in releasing, not introducing
regressions, and it means that no big things need to be added to the
core to support whatever is needed in apps.  The same goes for
gst-plugins-base - you will not find new plugins there.  Realistically,
this is a step that needs to be taken *before* you can attract
developers to help out in porting remaining plugins.

Compare to the GTK+ 2.0 situation - very few people started porting
applications to GTK+ 2.0 when it first came out.  Does that make it a
development branch ? The difference lies in the pluggability of
GStreamer - which you should view separate from the core.

I completely agree that it is a fair reason for not choosing to use
GStreamer 0.10 - I just wanted to point out the difference.

At the same time, I do not want to have us overestimate the problem with
all these proprietary formats.  avi's work fine, codecs inside avi's
work fine.  an asf demuxer port is close to being complete, that will
handle a lot more cases.  I doubt you personally have ever seen a
matroska file, but feel free to tell me otherwise. qtdemux is being
ported this week by an outside contributor.

And in reality, GNOME can't even ship the tarballs this code is in.
People can choose to keep sticking their heads in the sand on this
issue, and it's as much of a baffling thing to do when building a
desktop based around the idea of "Free Software" as it is for the
Creative Commons to use proprietary formats all over.

> Now, it might not- there are plenty of legitimate reasons I can see to
> switch to 0.10 anyway, even if it should still be called 0.9.90.
> Primary of them, of course, is that if we ship with 0.8, no one will
> fix any reported bugs, and I can't blame the gstreamer/fluendo team
> for that, given their limited resources.

It's not even a question of limited resources. 0.8 has gone about as far
as it can go.  The serious architectural issues in it cannot be resolved
with the same API.  They're resolved in 0.10.  (crosses fingers :))
People have worked on 0.10 for exactly this reason - why would they want
to go back, knowing what they know now, and try to fix the unfixable ?

Again, thanks for providing the other side of the coin.  It helps me
crystallize my take on it :)

Thomas



Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
I'm gonna turn on you before you turn on me
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/