Fansubbing with Linux in mind
 

Over the past few weeks, I've come across a few groups (which shall remain nameless) that seem to be stuck in a vsfilter way of doing thing. To me, these groups are apparently slow to react or oblivious to the need for scripts that are friendly to libass (and perian).

Take episode one of 'Winter Series X' for example, the episode was typeset in such a way that it was capable of crashing or lagging even the most recent of MPlayer builds. The problem was three-fold.

• Apparently libass doesn't like \pos tags with decimals.
• Enormous letters that appear on screen and speed by with ridiculous placement values are a no-no.
• Using Japanese style brackets in scripts will bring fontconfig to its knees.

Fortunately, keen-eyed Linux users like myself are very quick to point out these problems and if the group is smart, they release patches or a v2. ;)

But the problem is deeper than the actual bugs themselves. Fansubbers cannot simply assume that their softsubs or even encodes will play properly on Linux. At the very least, you should run a script through MPlayer on a Linux virtual machine to see if everything renders properly.

To get a sense of how things 'work' on Linux, we need to be informed of the current state of affairs for the software critical to playing fansubs (not necessarily softsubs).

MPlayer: MPlayer and its frontends such as SMPlayer, have been stable for relatively proper decoding for years. There are really no outstanding issues here, however, some will argue that the correct-pts option is pretty essential for proper scene-timing to render precisely and accurately.

libass: The standard for softsubs on Linux. At heart, libass is a clone of vsfilter and boasts the code to match. libass isn't perfect though, as I mentioned above, it can be quirky at times. Aside from that, libass is capable of handled pretty any karaoke or softsub effects that you throw at it.

VLC: A year ago, this player was absolute shit. Today, it is polished turd that can handle styled softsubs through libass. The fansub community is owed a ton of thanks from the VLC dev team for the progress that has been made so far. If not for the lobbying and bug hunting of the Aegisub devs and brave testers like myself, it would still be an unusable player. In some senses, it still is unusable because of the horrid AVC decoding.

Totem: Part of the Gnome desktop for Linux and standard on most Gnome-based distros, Totem is still a work in progress as far as I'm concerned. It has up to date decoding, but the softsub support is still very primitive and does not support styling. The heart of this problem is rooted in the gstreamer backend it relies on. I am currently pushing hard for styled subs to be included and progress based on libass seems promising, despite a noteworthy performance penalty.

Xine: Based on the xine backend. No data aside from the fact that certain Linux players make use of Xine and that styled softsubs are not supported.



~~~ Known libass quirks ~~~ (thanks kovensky)

• Transparency breaks if you use shadows
• Anti-aliasing breaks if you use transparency
• If you use decimal points on some tag it practically ignores the tag
• No \be (blur edges) strength
• No implementation for any of the tags in vsfilter 2.39c
• No @font support

And when you do this, use a two year old build of mplayer because linux users seem to be incapable of updating it.

Fixed that for you. Debian, Ubuntu, etc are still, last I saw, using 2-year-old builds of mplayer.

*spots plork and whistles innocently*

Also, make sure that that said MPlayer build is being run through the terminal for detailed output of any and all errors.

I will admit that finding recent builds of MPlayer is tough and compiling it an even greater challenge. However, most distros ship with a build that is sufficient for softsubs.

It is noteworthy though, that updating MPlayer is made much easier on distros that support RPM or DEB packages. The SMPlayer team (namely rvm, the main dev) provides links to up-to-date binaries. Ubuntu offers said binaries through PPA (Personal Package Archives). As for RPM, repos with mplayer can be found if you know where to look.

At any rate, a Linux user should have enough knowledge to do these kinds of things.

Just curious but... how many groups actually do any of those 3 things you listed above?

Decimal point pos positioning is just silly... and the other things seem highly unlikely to happen on purpose.

A few. One of them is very prominent and well-respected.

Uhmm thing is... if nothing breaks and all works fine, as in your mentioned "fansub with linux in mind", then devs would have little reason to fix stuff. I'm not aware of how much development gets done there, but from what I heard, not much.

How about instead of working around these bugs, we FIX them? Or at least bitch to the devs to fix 'em (lol like that will happen).

That's what I've been doing.

It's a slow process though.

(requisite post)

hard subs ftw

[insert angry response here]

hardsubbing is lazy.

give schneizeleffort a try. you'll find bliss when you what you can with softsubbing, not necessarily your best, and then take a rest.

personally, when I was testing Ubuntu on my comp, I couldn't even install/fully get the packages/etc of mplayer >.> (parts wouldn't install -> errors, my type of ubuntu couldn't install it

In all seriousness, schneizeleffort would be hardsubbed low res avi because it would be the path that would eliminate all problems. Softsubbed problems can't occur if it's not softsubbed to begin with.

Similarly, there can't be problems in the world if everyone is blown up. :blush:

it happens with some motion tracking software or if you resample the script resolution in aegisub

It also happens when groups set the resolution for pixel precision in the script to 704x400, when packaging in 720p matroska releases. Any \pos tags almost ALWAYS become decimal'd, a very good example being here. Simple things like defining the res in a file as what the video is will usually prevent any issues like that. It's not that hard to control really. \blur and \clip are another problem, but pretty much anything else is fine.

Another thing some people do that actually works fine for mplayer users, but fucks with VLC and some windows users, is not setting the framerate on the container when muxing. MPlayer and CCCP have no trouble with reading the framerate from the video track itself, but VLC/GOM/Real all rage at it.

E~

I'm with martino and D404 on this; working around perfectly legitimate uses of SSA overrides is ass backwards and ultimately counterproductive. I don't personally see much use for most of them in regular subtitles, but that's no excuse to settle for a half-assed implementation. VSFilter has been around and considered the standard for I-don't-know-how-long now; anyone who wants to code a different renderer will just have to suck it up and accept that. I mean c'mon, libass is relatively young and still incomplete, how surprising can it be that it doesn't handle some softsubs correctly? The sensible thing here is to fix the libass bugs, not pretend we can't do certain things anymore. The only reason anything else is being discussed is that that's harder than just bugging the fansubbers.

It is the standard... (Including the bugs it has)

There you go, then.

Overall my view is that as long as someone is using the best player available on their platform, at the minimum a show should be watchable, and ideally it should look as good as is possible given the limitations of the player. It is not the user's fault that libass is somewhat lacking, and realistically the vast majority of people using it couldn't do much to help even if they were motivated to. I really don't give a fuck about crashes caused by people using terrible or horribly out of date players, but if the viewer is doing everything they can to make it work well, then you should as well.

Motion tracking looks much better with subpixel precision, so it'd be nice to be able to use it. The main problem is that Resample Resolution in Aegisub doesn't round to the nearest integer, so it's easy to accidently end up with it.

There's very little you outright can't do. Recent versions of libass simply ignore the tags it doesn't know how to render, and I haven't managed to crash a recent version yet. The only time it's really a problem is when you're using a value for a tag that it doesn't support, and I only know of three of those: subpixel pos/move, be > 1, and b<weight>. Avoiding the first and third is no huge loss, and be1 + blur is a decent substitute for the second. Typesetting to make things look as good as possible on with both VSFilter and libass is significantly more work than just targetting one, but it doesn't have to make the end result look any worse than it would have.

Most groups don't really care about their releases on linux.