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

[Luis Villa <luis villa gmail com>]

On 1/16/06, Thomas Vander Stichele <thomas apestaart org> wrote:
> 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 everything I've seen, you guys did everything *exactly* right,
given the very shitty situation you're in. I understand that 0.8 had
serious issues, and I don't blame you in the slightest for wanting it
to die as soon as possible. Whether you were right or wrong to do that
doesn't impact whether or not 0.10 is actually something I can
recommend to end users above 0.8 at this time.

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

Unfortunately, gstreamer *is* a coherent whole, in the sense that
GNOME doesn't get to choose 'hey, lets use the gstreamer 0.10 core,
but the 0.8 codecs!' We have to act, and choose, as if it is one
coherent whole. So while I see your point, it is mostly semantic for
us and for our users right now.

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

Nope, nor the video game files. But for both sides of the debate it is
ridiculous to pretend that all formats carry the same weight.

> qtdemux is being
> ported this week by an outside contributor.

I'm not happy, at this point in the cycle, counting on reassurances
that 'don't worry, we'll have MAJOR_FEATURE_X done soon'. I hope you
understand why :) This same worry applies to most of Christian's
reassurances elsewhere in the thread.

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

I firmly believe, as you guys do, that free software will not move
forward if our user experience continue to be suboptimal. That's why I
care about the mainstream non-free codecs, and feel they are important
to us, and why I do think that (sadly) we must do a good job of
supporting this software that we can't ship. [FWIW, I have no moral
objection to shipping most of this stuff- if it were up to me, and
gnome.org were hosted out of a more sane place, we'd have decss hosted
right there as part of the release.]

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

<shrug> Either way, bottom line is bugs in 0.8 won't get fixed. My
sense is that this isn't enough of a reason for us to go to 0.10 right
now, but I realize that isn't black and white.

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

Thanks for being reasonable and not taking this as a personal attack,
as some people on both sides of this thread seem to be doing. You know
I think you guys are (overall) doing great work and moving free
software and free formats forward, even if I think sometimes you pay
too little attention to users ;)

Luis