[vlc-devel] vlc patches to libass

[Evgeniy Stepanov]

On Monday 13 July 2009 18:15:23 Derk-Jan Hartman wrote:
> On 12 jul 2009, at 13:38, Martin Sourada wrote:
> > Hi,
> >
> > I am fedora maintainer of libass package and I take as upstream for it
> > the one at sf.net [1]. I was asked in our bugzilla [2] to include your
> > patch [3] against it. But it is fedora policy to "work upstream" which
> > means if we include a patch in our package we should reference
> > upstream
> > bz#, which does not seem to exist in this case. I hoped you, as
> > co-authors of the patch, would enlighten me in this matter why vlc
> > carry
> > its own set of patches against libass instead pushing them directly
> > upstream (and using system copy libass instead of their own).
> >
> > Thanks,
> > Martin
> >
> > Note: I'm not subscribed to this list, so please CC when replying me.
>
> Ah yes, the reason for this is simple.
>
> * [1] is the official project and official version of the separate
> library, but outdated in functionality and missing some critical fixes
> * mplayer's private version is where most of the development
> originally occurred, these are often later added in batches to the
> official library version.
> * greg's version (http://greg.geekmind.org/viewgit/?
> a=summary&p=libass ) is the most up to date, but not API compatible
> with earlier versions. It does have several CRITICAL fixes however,
> incl. some important memoryleak fixes.
>
> Ergo one big mess. And your guess of where to send patches is as good
> as ours :(
> I have CC'ed this to one of the original libass authors.

Greg's version is the main (and, AFAIK, the only one active) line of 
development for libass now. There are plans to use it in mplayer (by dynamic 
linking), and, ideally, everywhere else.

> DJ
>
> > References:
> > [1] http://sourceforge.net/projects/libass/
> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=506530
> > [3]
> > https://trac.videolan.org/vlc/browser/extras/contrib/src/Patches/libass_m
> >player_updates.patch