After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 575261 - Do not use the outdated Debian/Ubuntu libass libraries!
Do not use the outdated Debian/Ubuntu libass libraries!
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
0.10.x
Other Linux
: Normal enhancement
: 0.10.15
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-13 15:54 UTC by Eric Appleman
Modified: 2009-08-24 05:57 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26


Attachments
gstreamer010-plugins-bad-libass-0.9.7.patch (1.82 KB, patch)
2009-08-14 11:39 UTC, Stanislav Brabec
needs-work Details | Review
gstreamer010-plugins-bad-libass-0.9.7.patch (2.27 KB, patch)
2009-08-14 14:29 UTC, Stanislav Brabec
none Details | Review
assrender-0.9.7.diff (3.58 KB, patch)
2009-08-24 05:56 UTC, Sebastian Dröge (slomo)
committed Details | Review

Comment 1 Eric Appleman 2009-03-13 15:57:58 UTC
I accidentally posted the Aegisub library. Disregard it for now.

This is the most up-to-date libass available:
http://svn.mplayerhq.hu/mplayer/trunk/libass/
Comment 2 Eric Appleman 2009-03-13 16:00:18 UTC
I take that back. Greg's upstream is the most up-to-date.
Comment 3 Tim-Philipp Müller 2009-03-13 16:28:17 UTC
Library dependencies should generally be released versions, not random git/svn versions, so if there's a good reason to only use a newer version, you should encourage upstream to make a release with those improvements so we can then depend on that. That also ensures everyone involved has a clear idea of what's the most current and 'official' version.
Comment 4 Eric Appleman 2009-03-13 16:39:16 UTC
I take offense at the term random.

Evgeniy and Greg are the only two active libass maintainers. PERIOD.

VLC and MPlayer both currently rely wholly on libass upstream. Furthermore, libass development is currently decentralized.

On top of that, the official release tree is deprecated and no longer maintained:
http://libass.svn.sourceforge.net/viewvc/libass/

The changes to libass since the last official release are astronomical. I could provide a list of changes if you want.
Comment 5 Eric Appleman 2009-03-13 16:50:23 UTC
Better yet, I could get you a whole slew of render comparison shots between the release and upstream.
Comment 6 Edward Hervey 2009-03-13 16:57:56 UTC
Eric, chill !

The only thing Tim wants (along with the rest of the gstreamer devs) is to have a 'official' release/version we can depend on.

The fact that you're using GIT doesn't mean you can't have an 'official' repository for libass. And we're not criticizing the work you're doing, on the contrary, it's good to see projects *not* die !

But please... can we have an official statement for all the distros and projects willing to use libass as to where the *official* repository is ?

the mplayer branch isn't usable for external projects (it's in another project).

as for the videolan repository:

bilboed@hostia ~/work/devel $ GIT_TRACE=2 git clone git://git.videolan.org/libass.git
trace: built-in: git 'clone' 'git://git.videolan.org/libass.git'
Initialized empty Git repository in /home/bilboed/work/devel/libass/.git/
fatal: The remote end hung up unexpectedly
Comment 7 Eric Appleman 2009-03-13 17:21:25 UTC
Official statement? What do you mean.

VLC uses the libass git branch on their servers (down at the moment I assume, try a tarball) for their releases. MPlayer uses the libass SVN branch on their server for development and the upcoming 1.0rc3 release. Ubuntu and Debian use the last official release PLUS a few patches from the MPlayer team. Gstreamer, as far as I know, will use the Ubuntu/Debian package.

If you are asking for a formal libass release, maybe something can be arranged. I don't know, I'm not a code maintainer.

- Eric
Comment 8 Tim-Philipp Müller 2009-03-13 17:28:48 UTC
> I take offense at the term random.

I have no idea what you find offensive about that ...


> Evgeniy and Greg are the only two active libass maintainers. PERIOD.

I don't think I ever doubted or questioned anything you said? (re. "PERIOD."?)


> VLC and MPlayer both currently rely wholly on libass upstream. Furthermore,
> libass development is currently decentralized.

Decentralized and coordinated I presume? (Asking only in order to understand the maintenance situation better.)


> On top of that, the official release tree is deprecated and no longer
> maintained:
> http://libass.svn.sourceforge.net/viewvc/libass/

Ok. So what are the plans of the current maintainers then? Are they going to make releases and put them up somewhere? I don't think it really matters (to us) who the active maintainers are or where they put up the releases, just that the maintenance situation is actively communicated and distros know which tarball to grab and package. And we can depend on something that is versioned and released.


> The changes to libass since the last official release are astronomical. I could
> provide a list of changes if you want.

That's great to hear. A list or screenshots aren't necessary, we'll take your word for it :)


So in short it all comes down to:

 - what's the download location of release tarballs for the latest
   (or future) versions of libass*? I.e. the stuff that you want
   distros to package?

 - if there are no released tarballs yet, please encourage upstream
   to provide some (well, one will do I guess) and ideally also
   announce that on some mailing list and/or website.
Comment 9 Tim-Philipp Müller 2009-03-13 17:34:35 UTC
> If you are asking for a formal libass release, maybe something can be arranged.

That would be good, yes (for us, and for distros and users).


> I don't know, I'm not a code maintainer.

You seem to know your way around the libass situation better than us - maybe you could try to talk to the right people?
Comment 10 Eric Appleman 2009-03-13 17:47:36 UTC
>Decentralized and coordinated I presume? (Asking only in order to understand
>the maintenance situation better.)
Yes, there is coordination, but no central development tree.

>Ok. So what are the plans of the current maintainers then? Are they going to
>make releases and put them up somewhere? I don't think it really matters (to
>us) who the active maintainers are or where they put up the releases, just that
>the maintenance situation is actively communicated and distros know which
>tarball to grab and package. And we can depend on something that is versioned
>and released.

I don't know. The ffmpeg devs had to swallow their pride in order to release version 0.5 this week. Maybe something similar can be arranged for libass.

By the way, the current code path for libass is as follows:

Greg's SVN -> MPlayer SVN -> Aegisub SVN -> VLC git

At the moment, the download location for the library itself would be the vlc
git. However there's a catch. There was gigantic change in rendering behavior
between the 2/24 code merge and this week. A lot of fixes landed after it and
are only found on the Greg's, MPlayer's, and Aegisub's SVNs at the moment.

If you wish to learn more or track these changes, may I recommend the
mplayer-dev mailing list and its archives for February and March?

>You seem to know your way around the libass situation better than us - maybe
>you could try to talk to the right people?

Yup. I'm following the development very closely and testing vigorously. Also, as a liaison, I'm trying to the bridge the coordination gap between the coders and packagers.
Comment 11 Eric Appleman 2009-03-13 18:06:13 UTC
(Before I forget, I apologize for my aggressive bug report. I tend to post bugs in an angry mindset and I shouldn't.)

Also, don't put much faith in 'dependability' for ffmpeg, mplayer, or libass with respect to a formal release. Diego, one of the lead devs for mplayer and ffmpeg stated about a week ago that a formal release is just a packaged revision, not and not necessary stable by any sane metric. He also went further by saying that stable releases are, by design, to be quickly outdated and no longer recommended after a short time. A stable release will only be recommended for about a month before the website officially states use the svn again.
Comment 12 Edward Hervey 2009-03-13 18:22:05 UTC
Eric, they (ffmpeg and diego) wouldn't have waited on the results of my regression suite to do a release if they *really* didn't care.

They did put a lot of effort in this release, bashing it down like this is just NOT helping.

Also, off-topic.
Comment 13 Eric Appleman 2009-03-13 18:23:02 UTC
From Evgeniy with love:
http://sourceforge.net/project/showfiles.php?group_id=181138

Libass 0.9.6
Comment 14 Eric Appleman 2009-03-15 00:51:02 UTC
Is there anything else you guys might need?
Comment 15 Sebastian Dröge (slomo) 2009-03-15 09:12:09 UTC
Is there any reason why the plugin should depend on >= 0.9.6 instead of >= 0.9.5? I mean, it works with 0.9.5 although 0.9.6 is of course better, but I don't see a reason why we should force all users to update if it's not necessary...
Comment 16 Eric Appleman 2009-03-16 04:44:02 UTC
What kind of justification would you like?

From a purely practical standpoint, 0.9.6 has yet to be packaged by any major distro.

Obviously, at this point in time, requiring 0.9.6 is not a wise move. However, this reality shouldn't preclude future dependence on 0.9.6 within the 2009 calendar year. The upcoming release of VLC 1.0.0 will pretty much force packagers to adopt 0.9.6 since it will rely on the newer version.
Comment 17 Stanislav Brabec 2009-08-14 11:39:19 UTC
Created attachment 140762 [details] [review]
gstreamer010-plugins-bad-libass-0.9.7.patch

And version 0.9.7 breaks API compatibility again. Attached patch attempts to fix gstreamer for libass-0.9.7 tarball release from http://code.google.com/p/libass/ . It compiles but it is untested.

Please review carefully arguments of ass_set_aspect_ratio() and ass_set_fonts().
Comment 18 Sebastian Dröge (slomo) 2009-08-14 11:49:56 UTC
Could you update your patch to conditionally work with <0.9.7 and >=0.9.7?
For this check for both in configure.ac and AC_DEFINE something. Then #ifdef your changes in the patch.
Comment 19 Tim-Philipp Müller 2009-08-14 12:52:32 UTC
> And version 0.9.7 breaks API compatibility again.

Hrm, I guess this means we should fix the configure check for the upcoming -bad release to disable the plugin for >= 0.9.7?
Comment 20 Stanislav Brabec 2009-08-14 14:29:55 UTC
Created attachment 140776 [details] [review]
gstreamer010-plugins-bad-libass-0.9.7.patch

New patch that should support both libass < 0.9.7 (untested) and libass >= 0.9.7 (verified that it compiles).
Comment 21 Eric Appleman 2009-08-15 00:53:03 UTC
Thanks for the patches.

Is anything being done on the Totem side of things?
Comment 22 Stanislav Brabec 2009-08-19 14:27:04 UTC
I just made gstreamer packages as feature complete as possible and nothing more.

The patch is not tested in runtime. Full support for new arguments for ass_set_aspect_ratio() may require more changes.
Comment 23 Sebastian Dröge (slomo) 2009-08-24 05:56:50 UTC
Created attachment 141524 [details] [review]
assrender-0.9.7.diff

It's not required to add another configure check, libass exports it's version from the header now :)

Also now that there is documentation, I've fixed the aspect ratio settings. I've committed this patch locally and will push it after freeze, i.e. in the next few days.
Comment 24 Sebastian Dröge (slomo) 2009-08-24 05:57:25 UTC
commit 9309295073f7e5be7824d946f582326881d0e21c
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Mon Aug 24 07:54:51 2009 +0200

    assrender: Fix compilation with libass > 0.9.7 and fix aspect ratio setting
    
    Fixes bug #575261.