Broken deps: libass.so.3

A short notice for all those who have Fedora 10 and are getting the broken deps message during update because of libass.so.3. Be assured that this is not intentional and that I've made a mistake by pushing the libass update to stable updates too soon, as there are some troubles over at rpmfusion preventing a successful vlc build. I apologize for the inconvenience. Please be patient, the needed vlc update will come ASAP, until then please skip the libass update.

UPDATE: I noticed vlc was successfully built, so as soon as the build is pushed to the repos, this problem will be gone :)

The mess that libass is

With 'recent' inclusion of proper ASS/SSA subtitles support into gstreamer via libass, it became a necessity to package this library separately. There seems to be one official upstream at sourceforge, but mplayer ships it's own patched version of libass, vlc as well and to make the mess even bigger, there's greg's version... As I've taken upon myself the task to provide this package for fedora, I'm trying to find the best solution to this but I don't have a single clue what the best approach would be there. Also, we seem to be on the head of separate packaging of this library separately (I've found debian, ubuntu and gentoo packages) and it would be probably good to solve this issue before other big distros start to package it and make the mess even bigger...

The gentoo package seems to be 0.9.6 unpatched, debian includes mplayer's batch patch against 0.9.6 and ubuntu is pretty much identical to debian...

Now vlc's patches seems to be taken from mplayer + one or two other fixes, however the greg's version deviates further from the official 0.9.6 version and is not API compatible with previous versions. All of those include critical, as well as non-critical, fixes and feature enhancements. Now the question is what to do about this mess? Yes, I could do the same as gentoo and just wait till 0.9.7 is released (and who knows how long will it take), or I can follow debian and just add the mplayer patch and make a note in the spec file where it originates from. That would be both an easy workarounds leading practically nowhere.

I could also review in full all the changes that the patches/greg's version carry, try to understand what does what and back-port fixes as well as submitting the (smaller) patches upstream.

I could also switch to greg's version in rawhide and hope it will not break anything... It seems almost all development is happening there, but on the other hand I'd rather not use git snapshot... Although after quick look at his changelog, it seems he might be releasing 0.9.7 soonish...

Ideally vlc and mplayer would switch to system libass, greg's version merged with upstream and do a release and everyone would be happy...

Now the basic question, are there people willing to help in any way with solving this issue?

UPDATE: The mess is beginning to clean up now. The official page now suggests Greg's git as the main version and I have been told that mplayer has plans to link dynamically against this version as well and vlc is switching over to this one as well. This means that I'll switch to greg's version in Rawhide in near future as well and if it works well, I'll use it also in stable releases.

Fedora 10 and Multimedia - Is It Worse or Better?

Well, a hard question. At first I got thrilled by some new features, especially the automatic codec install, and pretty stable pace of improvements on gstreamer front, but lately I'm starting to notice issues as well.

First let me say that while both video and audio handling in gstreamer got generally improved I recently came across a clip (video in h264 and dual audio FLAC and mp3 in matroska + karaoke using styled ASS subs) that fails misserably pretty everywhere. Totem plays the audio fine, but the video gets pretty quickly out of sync, in gst-launch the video even eventually stops altogether. Gxine does not support styled subs, but other than that it plays it pretty well, though it picks wrong audio track. Mplayer plays it well, but the subtitles are totally out of sync. And that's probably the biggest woe of recent mplayer builds (where recent spans even to some time before Fedora 10 GA) - slightly more complex styled (ASS) subs are frequently out of sync or not displayed at all (usually when there are more subtitles at once).

So I was looking for a workaround using different video player, but... VLC a xine-lib don't support styled subtitles and for gstreamer there is a bug filled, with experimental plugin attached (using libass). So I've created packages for libass (it's built-in in mplayer, but I needed a standalone library) and for the gstreamer plugin (called assrender) and installed it. Yep, totem does not know about the new plugin for subtitles rendering, but after some googling and trying I sort-of learned how to make gst-launcher use it.

And well, though gst-launcher is good for debugging it's not good for playback, so I wanted to make a simple one-purpose media player using gstreamer and ruby (just for the fun of it :) But it seems, ruby bindings for gstreamer are not exactly in a state that makes it possible at the moment...

The assrender plugin, though highly experimental and not official, works pretty well and even support using fonts that are attached in matroska files (that's a really useful and pretty widely used), but because it supports only RGB colorspace output there are two colorspace conversions needed (YUV to RGB and back) which consumes cpu cycles and on my not so hi-end laptop it makes HD (1280p) videos, that are just about what my CPU is capable of, to fail miserably. So dear lazy web, if you want not-so-hard to do coding for gstreamer, you can help out with bringing libass support there. It would remove the last obstacle which prevents me from using gstreamer for everything ;-)

But at the same time, I am a bit concerned about mplayer as well - because on the same hardware, since Fedora Core 6 it's playback capabilities are getting steadilly worse. Not that it cannot play videos, but mplayer tends to fail resuming of paused video, then there's the issue with subtitles and lastly I've experienced a very weird bug (and workarounded it for my own purposes) - there's one assertion in ffmpeg code that prevents playing of certain matroska videos in mplayer.

Basically someone obviously expected that if you have chapters in a movie, than they will be strictly chronological, meaning next chapter (in list) won't start before current one. In matroska this is not always true and the failed assertion makes mplayer crash... For those who are interested, it's in libavformat/utils.c in compute_chapters_end () somewhere around line 1950 or 1960... It's this simple line:

assert(s->chapters[i]->start <= s->chapters[i+1]->start);

I'm still in doubts whether I should fill a bug or not about it... In my opinion there should be just if conditional, assert seems to me like an overkill, especially given that not aborting the code here (if the assertion fails) does not make mplayer doing things it is not expected to do.