Slashdot Mirror

Don't forget mencoder, part of mplayer. It does everything for video and audio streams that imagemagick does for images.

Worth naming is also sox, that is the same but for (only?) audio. I haven't use that one, so I don't know how good it is.

And maybe netpbm should be mentioned as a precursor to imagemagick.

Good luck on running mplayer with a remote control.

"RTFM" > "LUCK"

Mplayer had LIRC support for over a decade, including on FreeBSD.

XBMC is meant for media center usage, not jerking off to porn at the desktop.

Real geeks have no use for the former. 8-)

But seriously - the opposite of "bloated" is "modular". Mplayer "does one thing and does it well", as per The UNIX Way . It's easily scripted and controllable via a runtime API, with many existing wrappers. So instead of having one bloated mess like XBMC trying to be all things to all people, all we should need is a simple video menu app that then passes control to mplayer.

It so happens that I'm toying around with precisely this kind of project on the back-burner: a Node.JS + HTML5 media searching / browsing UI that can launch mplayer if connecting from localhost. (HTML5 video still sucks, especially on my old system.) It even remembers which parts of the video you've played or skipped through, for automatic resume. I personally don't use a remote control, but hopefully HTML 5.1+ will support that "10-foot user interface" crap as well. And hopefully someday in-browser video formats will be common enough, and in-browser player features powerful enough, to make all them copyleft stand-alone player apps obsolete!

--libman

It seems no patch has been adequate. Either the FFMpeg architecture cannot deal with it, or people who patch don't understand FFMpeg enough to submit a clean patch. Sample:

http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-August/041721.html

either implement it cleanly or
go away

They refuse to apply terrible patches. Another question is why don't they work on it themselves, to fix an obvious deficiency? I don't have an answer to that.

If you're interested in smooth h.264 playback, i recommend downloading the most recent mplayer svn snapshot from here (they recently added multithreading), compiling with -march=native, and pointing smplayer at the resulting binary. I used this method to get functional 1520x1080 playback on a 2100 MHz core2 duo.

What need is there for the middle ground?

First, the terms aren't simple at all. Go ahead, read that, and tell me you really know what that says.

Second, when faced with a choice of:

A. Free forever, no matter what
B. Free unless I happen something to infringe on something in 97K of text.

Why would I be crazy enough to go with B? The terms are updated every 5 years, so there's little guarantee that something that isn't a problem now won't be a problem later.

I still haven't found a player for my Mac (or Linux laptop) that can run songs/movies at double speed without making everyone sound like chipmunks.

MPlayer can supposedly do it, though I haven't tried.

mplayer -speed 2 -af scaletempo foo.avi

That and output as H.264 which is really the only choice.

Agree. H.264 is supported, in hardware, by most of the smartphones you care about (iPhone, Nokia/Symbian and most android phones).

I've found the output from mencoder (part of mplayer) has worked across all three platforms flawlessly.

left arrow is 5 sec by default, iirc. This page from the manual will let you set the seek to whatever you want. http://www.mplayerhq.hu/DOCS/HTML/en/control.html

If you don't like Matroska, you can download the lower resolution AVI file (XVid codec) linked at the site. But I'm curious, what computer system of recent vintage can't play a Matroska file? I can play the 720p version (x264 codec) without any problems on my five-year-old AMD Sempron 3000 (1.8 GHz single core) system. This is using stock MPlayer under 64-bit Ubuntu with a mere 750 MB of DDR1 (!) RAM. For other systems, VLC can play most non-subbed and plain text-subbed video files you can download off the 'Net. (Some anime fans hate VLC for its "alleged" inability to play fancy "soft subs".)

Sorry to say, but RTMPE has been broken for a while, originally as it was badly developed, and now using man in the middle type attacks - http://rtmpdump.mplayerhq.hu/ .

I agree that DRM can work for a limited time, or for a limited target size quite well. But with the current stat-of-the-art in cryptography, DRM will always be breakable. It's simply a game of hiding the key, and always will be.

http://rtmpdump.mplayerhq.hu/

Documentation helps.

http://www.mplayerhq.hu/DOCS/HTML/en/index.html

Stop spreading FUD.
The part that decodes H.264 is from libavcodec, a part of ffmpeg. It uses a FOSS implementation of the H.264 standard which is perfectly legal to distribute. It's manufacturers of devices that can decode H.264 in hardware that have to pay a royalty.

Why would I need "warez" codecs? Mplayer plays virtually everything. The rare exception will usually play in VLC. Thanks to those two I can view more than 95% of all video I wish to see. The only major exception is silverlight (netflix streaming), for which I use a stripped-down windows in VirtualBox.

Windows boxes are more capable media players.

Not really.

I generally prefer Zoomplayer and MPC-HC to stuff like VLC

See, here's your problem. You're comparing competent players to an incompetent player. One that in particular has terrible support for ASS, by far the most popular subtitle format for fansubs. Try mplayer (or a GUI frontend if that's your thing) sometime.

but a big issue is the lack of Blu Ray playing capability under Linux.

For you, maybe. For most people it is a tiny, tiny issue though. And anyways, that's certainly not the case anyway.

There's also gaming, with the exception of Onscript based games, very few visual novels play well with Linux

Plenty of them run well with Wine, but the amount that manage to make something as simple as a VN not work at all under Wine is certainly impressive.

and most Tohou/doujin shooters are Windows only.

The Touhou games all work fine under Wine, minus the occasional minor graphical glitch.

I do not think that the problem lies in use of C/C++, but in the horrible way of using it. From what I've gathered around the Internet "why win32 is great" is that they lacked any kind of stable way of creating their (old?) APIs; everyone just created a new standard for return values and parameter handling. And on top of that some crazy macros that make Symbian code look readable in comparison.

I mean, I've only learned how to program in C/C++ (at university) but been working as a Java dev for quite some time now. Still I can almost make sense of mplayer's or ffmpeg's source code but every time I see some "Windows" C++ it's just plain awful because of all the macros and #define constants. If you ever read KDE's or Qt's sources and compare those to something done with win32... There is a massive difference.

Every tool can be miserably misused.

I am not afraid to stand up for VLC for I've never found something that has worked so flawlessly crossplatform

How about MPlayer and its various Grafical User Interfaces?

I am not afraid to stand up for VLC for I've never found something that has worked so flawlessly crossplatform

How about MPlayer and its various Grafical User Interfaces?

mplayer has complete support for VDPAU as well as support for things like SSA/ASS subtitles. While the current repository versions tend to run a bit behind the development versions (bzip2 archive) at mplayerhq.hu, rvm's builds as part of his smplayer project are quite up-to-date. smplayer is a fine GUI front-end to mplayer as well, and it runs on both Linux and Windows.

mplayer has complete support for VDPAU as well as support for things like SSA/ASS subtitles. While the current repository versions tend to run a bit behind the development versions (bzip2 archive) at mplayerhq.hu, rvm's builds as part of his smplayer project are quite up-to-date. smplayer is a fine GUI front-end to mplayer as well, and it runs on both Linux and Windows.

Well here is the discussion about chrome, one thread, 2 links as it crossed a month boundary.
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-May/070533.html
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-June/070607.html
Also here is where they keep track of violators, http://ffmpeg.org/shame.html

Well here is the discussion about chrome, one thread, 2 links as it crossed a month boundary.
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-May/070533.html
http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-June/070607.html
Also here is where they keep track of violators, http://ffmpeg.org/shame.html

No love for the cross-platform smplayer here, huh?

smplayer is an excellent gui front-end to mplayer. The Windows version packages a very up-to-date version of mplayer as well. On Linux machines with a recent nVidia card you can use the VDPAU driver which offloads H.264 decoding tasks to the graphics hardware.

Ubuntu users can download smplayer from the repositories, but you might want to compile mplayer from SVN. "apt-get build-dep mplayer-nogui" will get you all the devel packages you need. The daily source snapshot is available here (warning: bz2 archive).

Now if only those docs would be on the mplayer/mencoder site rather than on some random .edu site.

???

Chapter 11. Encoding with MEncoder

When I read this question it sounded like a question I had when I first got into ripping DVDs. After researching interfaces I settled on OGMRip as I didn't want all the bells and whistles that other rippers like dvd::rip offers. I also found myself needing to get a better understanding of video recording and playback such as interlacing and progressive. I qualify this by saying this was self study up to the point where I was able to successfully rip DVDs 95% of the time so if I misuse terminology you were warned. I should also say that this is for NTSC DVDs.

With the option "Ensure A/V Synchronization" checked in OGMRip and an understanding of how the DVD was created I've not had many issues. The only trouble I get is from the not so well mastered workout videos which are interlaced. I have two such videos and both had audio synchronization issues. I was able to fix one by going into the Matroska video container I created and set a delay, the other I just haven't gotten around to messing with yet. One other issue I'll run into with OGMRip is if the DVD isn't quite right it will fail ripping it prior to encoding. For this I just use dvdbackup (dvdbackup -M -i /dev/dvd -o /directory/to/save/to) and then point OGMRip to the DVD directory on the harddrive.

The one URL I strongly suggest looking at is http://www.mplayerhq.hu/DOCS/HTML/en/menc-feat-telecine.html#menc-feat-telecine-ident as it briefly explains the various ways a video is originally recorded and the DVD mastered along with how to determine this with your video. With most popular DVDs released today they are typically progressive and so when it comes time to rip it I pick how I want it encoded and then check progressive and away it goes. When encoding I use a matroska container, keep the original audio, use x264 for video, and based on the length of the video the rule of thumb of 700MB per hour (increasing if I'm pulling several audio tracks). For your portable player these are probably not the settings you would use.

So the point I'm wanting to make is having the basic understanding of the entire process from recording to the final encoding is what will make any one of the tools work for you. You can then decide how much control you want in the ripping/encoding process. For me the end product is what I want, something I can stream to my TV, not the joy some get spending lots of time getting all the options set for each DVD.

Why is this on slashdot? Google "linux rip dvd" for many many solutions.

If you are a button clicker, use Handbrake. Download the binary or build from source.

If you are a linux user, use mencoder. RTFMP

I use mplayer for ripping the DVD and avidemux for the transcoding the video.

Specifically I use mplayer to dump the VOB files on the disk. Then I use avidemux, which in turn uses x264, ffmpeg, lamemp3, etc. to transcode the video to any format I want. This process is not a "one-click solution," but I find that going through the process for each DVD title manually gives fine-grain control over the final product.

Mod the parent up ! Absolutely agree with him to the last word :). I tried VLC but it's keyboard control is not even close to that of MPlayer, and it crashes a lot more on windows and FreeBSD. MPlayer's man page is actually useful compared to VLC's almost empty one. And one more minus for VLC is it's QT interface, because I'm using gnome and hate to wait for QT to compile especially if only one application is using it. On the bright side it's probably the only usable video streamer around :).

VLC (VideoLAN Client) media player was good up to the 0.8.6 releases and after that it took a bit of a tumble in design and lost popularity because of its tendency to crash or freeze at any minor error or corruption in the media files.

Media Player Classic Homecinema stepped in and took the reigns after that. This player includes internal decoder filters for MPEG-2 (DVD), MPEG-4 (XviD, DivX), H.264 (Blu-ray), and VC1 (Blu-ray) along with audio decoders for AC3 (Dolby Digital), DTS (Digital Theater Systems), AAC (Advanced Audio Codec), etc. It also includes native support for MKV (Matroska) and AVI (Audio Video Interleave) file formats.

The most important feature of MPC-HC is the hardware accelerated DirectX Video Acceleration (DXVA) decoder filters for the H.264 and VC1 Blu-ray codecs allowing this player to leverage ATI, nVidia, and Intel graphics cards to handle the work load with complex 720p and 1080p movies. The difference in CPU usage goes from 70-100% on software decoding with dropped frames to 5% on DXVA decoding and no dropped frames, of course this is relative to the CPU being used.

DXVAChecker is the best tool to use to determine if your video card and latest drivers support hardware acceleration. It will list the list of video streams that are accelerated such as MPEG2, WMV9, VC1, H264 along with DXVA1 (XP DX9) or 2 (Vista DX10) for the version along with the resolution such as 720x480, 1280x720, 1920x1080 that is supported.

FFDshow Tryouts is another codecs to look into is that is based on libavcodec and ffmpeg-mt (multi-threaded) and handles pretty much all audio and video codecs in software using CPU decoding and includes a lot of filters for audio 2.0->5.1 up-mixing, real-time AC3 encoding for surround sound, noise filtering, and video filters for noise, sharpening, and subtitle support.

CoreAVC Pro codec is the most efficient software and hardware nVidia CUDA accelerated H.264 (Blu-ray) decoding. In hardware CUDA mode it users ~15% CPU to perform decoding and in software mode it users 50-70%, relative to the CPU being used of course. This codec a bit more efficient than FFDshow in software but a lot better in CUDA mode, nVidia video card required.

Haali Media Splitter is the preferred splitter for MKV (Matroska), MP4, and AVI files. This is the recommended splitter for these file formats over the internal splitters that usually come with the players.

MPlayer Media Player is also a complete alternative that now has hardware acceleration support for nVidia video cards with the latest SVN releases.

VLC is an OK media playback application. I, for one, never understood why someone would prefer it over using mplayer.

I used mplayer for years, I tried a windows binary, didn't like it much. The command prompt is horrible in windows, and all of the GUIs I've found just didn't work all that well. VLC was a nice slim media player, worked well with any file I threw at it (like mplayer), it had a nice playlist I could drag and drop files onto, and it was easy to use. Same thing on my mac.

In linux I use mplayer for everything, but linux is more command line based, I'm used to it. I know how to quickly navigate a linux system with the command line. There isn't some fancy windows explorer or finder that I want to integrate nicely with on linux so mplayer works just fine for me in that situation. But seeing as how most people use windows or mac, VLC is very easy to install and will play just about anything, it's kind of obvious why most people would use it.

Sorry... though I appreciate VLC, I think its far from the best media player. My vote would go to the numerous incarnation of MPlayer. From Xbox Media Center to SMPlayer on Linux and Windows to MPlayer OSX Extended on Mac OS X, MPlayer has always been able to play whatever weird codec or container I toss at it. Meanwhile, every time I've attempted to use VLC (mainly on OS X) I've become frustrated by hangs and crashes... Maybe I'll hate this version a little less?

VLC is an OK media playback application. I, for one, never understood why someone would prefer it over using mplayer. It's got all the nice libavcodec improvements first, and is the perfect example of unintrusive UI design (note that I'm talking about the CLI-only `mplayer`, not `gmplayer` or any other graphical front-end).

To anyone involved in maintaining ports of third-party software to a particular OS (or even a distro), working with a release of that software is quite important. Unfortunately, ffmpeg-developers couldn't be bothered with such things. Here is a rather arrogant response I got two years ago from them:

We have them [releases -mi]. They are called nightly snapshots. Now, if you were to ask us to spend our time on evaluating and telling you which of the snapshots we consider to be more stable than the other ones -- you would be asking us to do *YOUR* job. Not a nice thing to do unless you can also give us some incentive.

He further explains their stance as:

The best way to use FFmpeg is to privatize its source code inside your project

If, indeed, this idiotic view has been retired for good — great!.

We're working on it. Just to let you know, while I'm sure an official release will be useable, don't expect the raw source ffmpeg model to go out any time soon. I expect that bug fixes and features will be in the repository very quickly and if you have a need for these things, you should probably compile the code from source. You may also want to keep an eye on the mailing lists
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-cvslog/
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel/

We're working on it. Just to let you know, while I'm sure an official release will be useable, don't expect the raw source ffmpeg model to go out any time soon. I expect that bug fixes and features will be in the repository very quickly and if you have a need for these things, you should probably compile the code from source. You may also want to keep an eye on the mailing lists
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-cvslog/
http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel/

Take Silverlight for instance, you do NOT have to use it, there are other alternatives. Look at Flash, you can develop Flash with whatever code, even Adobe's, but makes sure it will play with the FREE Gnash Flash movie player [slashdot.org], not just the Adobe player.

Yes, but you can do the same with Silverlight and Moonlight. What makes Flash better?

Most people when they refer to Flash are talking about Adobe Flash and Adobe Flash reader only. I am not. I am suggesting that create Flash content with whatever software tools that you want, but on your website, DO NOT offer an "Adobe" specific version as the first or only choice.

If how ever you encode it allows it to be opened with Gnash or Flash Player, great.

If how ever you encode it, lets say you use an Adobe specific library and/or function that only can be understood by Adobe Flash Player, so that Gnash or other non-Adobe- specific-Flash players can NOT open it, not good at all. Best to avoid problems due to lock in.

Personally I do not think either Flash or Silverlight either one are superior to a an encoded H.264 CODEC enabled video. Though admittedly it depends on the settings used by the person who encodes the video. It is telling that to get close, not equivalent to, H.264 quality with other CODECs you have to increase the resolution and the FPS. Per this evaluation of video codecs (H.264, VC-6, and VC-1) In all comparisons, H.264 exhibited the best still frame quality. . They analyzed individual still frames of various videos looking for problems with the images and side effects by inferior encoding and compression methods, not just still pictures. H.264 encoded Videos were better of higher quality and better to the eye to watch. H.264 can come in either proprietary or open source coding. The open source codec is superior or equivalent to all proprietary H.264 codecs...so why make anything proprietary unless you are lazy or have alternative motives..i.e. Software or Operating System Lock In.

Therefore I might suggest the MPlayer is superior to either Silverlight or Flash. And it will work under all operating systems that most people use: Unix, Linux, MacIntosh and yes even Microsoft Windows.

Flexibility, open to all; the fact that H.264 is a superior CODEC than what is standard for Adobe Flash and/or Microsoft Media Player is icing on the cake.

As a business that wants everyone to see my content and at the highest resolution and the most effective frame rate (fps) that makes sense for the bandwidth that I have available to me.

MPlayer is a movie player which runs on many systems (see the documentation). It plays most MPEG/VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, RealMedia, Matroska, NUT, NuppelVideo, FLI, YUV4MPEG, FILM, RoQ, PVA files, supported by many native, XAnim, and Win32 DLL codecs. You can watch VideoCD, SVCD, DVD, 3ivx, DivX 3/4/5, WMV and even H.264 movies.

Take Silverlight for instance, you do NOT have to use it, there are other alternatives. Look at Flash, you can develop Flash with whatever code, even Adobe's, but makes sure it will play with the FREE Gnash Flash movie player [slashdot.org], not just the Adobe player.

Yes, but you can do the same with Silverlight and Moonlight. What makes Flash better?

Most people when they refer to Flash are talking about Adobe Flash and Adobe Flash reader only. I am not. I am suggesting that create Flash content with whatever software tools that you want, but on your website, DO NOT offer an "Adobe" specific version as the first or only choice.

If how ever you encode it allows it to be opened with Gnash or Flash Player, great.

If how ever you encode it, lets say you use an Adobe specific library and/or function that only can be understood by Adobe Flash Player, so that Gnash or other non-Adobe- specific-Flash players can NOT open it, not good at all. Best to avoid problems due to lock in.

Personally I do not think either Flash or Silverlight either one are superior to a an encoded H.264 CODEC enabled video. Though admittedly it depends on the settings used by the person who encodes the video. It is telling that to get close, not equivalent to, H.264 quality with other CODECs you have to increase the resolution and the FPS. Per this evaluation of video codecs (H.264, VC-6, and VC-1) In all comparisons, H.264 exhibited the best still frame quality. . They analyzed individual still frames of various videos looking for problems with the images and side effects by inferior encoding and compression methods, not just still pictures. H.264 encoded Videos were better of higher quality and better to the eye to watch. H.264 can come in either proprietary or open source coding. The open source codec is superior or equivalent to all proprietary H.264 codecs...so why make anything proprietary unless you are lazy or have alternative motives..i.e. Software or Operating System Lock In.

Therefore I might suggest the MPlayer is superior to either Silverlight or Flash. And it will work under all operating systems that most people use: Unix, Linux, MacIntosh and yes even Microsoft Windows.

Flexibility, open to all; the fact that H.264 is a superior CODEC than what is standard for Adobe Flash and/or Microsoft Media Player is icing on the cake.

As a business that wants everyone to see my content and at the highest resolution and the most effective frame rate (fps) that makes sense for the bandwidth that I have available to me.

MPlayer is a movie player which runs on many systems (see the documentation). It plays most MPEG/VOB, AVI, Ogg/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, RealMedia, Matroska, NUT, NuppelVideo, FLI, YUV4MPEG, FILM, RoQ, PVA files, supported by many native, XAnim, and Win32 DLL codecs. You can watch VideoCD, SVCD, DVD, 3ivx, DivX 3/4/5, WMV and even H.264 movies.

What will really help this technology take off is if it's able to convert your porn into an LED display. Stick figure porn FTW!

With mplayer you already can play movies on a LED display, just upgrade the microcontroller, make a 80x24 LED display, and use one of the appropriate video output drivers:

mplayer -vo aa movie.avi | netcat localhost 6666
mplayer -vo caca movie.avi | netcat localhost 6666
mplayer -vo bl movie.avi | netcat localhost 6666

aa - ASCII art video output driver that works on a text console. You can get a list and an explanation of available suboptions executing mplayer -vo aa:help

caca - Color ASCII art video output driver that works on a text console.

bl - Video playback using the Blinkenlights UDP protocol. This driver is highly hardware specific.

For more details check the mplayer man page.

Use of ffmpeg contrary to the GPL has become so common the developers now maintain a "hall of shame".

Use Mplayer .

mplayer -fs -cache 1024 -cache-min 99 'http://movies.apple.com/movies/paramount/star_trek/startrek-tlr2_h.640.mov'

works just fine on my crappy K7 system. ( Kubuntu 8.04 )

jdb2

K. Start using Mplayer [1] and VLC [2] NOW. They ignore the executable parts of MSFT's multimedia formats.

[1] Grab the "Windows GUI" and the "Windows X86 codec package" from here: http://www.mplayerhq.hu/design7/dload.html
[2] http://www.videolan.org/vlc/

Now that I've just upgraded it seems that those "performance upgrades" don't show up at least on (K)Ubuntu 8.10 beta.

Running without desktop effects, under firefox or konqueror it still needs the whole core to do simple low quality video decoding. mplayer (w/ ffdshow) does videos with same resolution with less than 10% of total cpu usage.

Wished at least some kind of performance boost ..

*continues to use mencoder since it is maintained and community developed*

You mean, like these?

http://ffmpeg.mplayerhq.hu/shame.html

I happened to look at ConvertXtoDVD the other day. While ffmpeg itself is licensed under the LGPL, ConvertXtoDVD also appears to use both libpostproc and libswscale which are both GPL. The ffmpeg licensing page states, "If those parts get used the GPL applies to all of FFmpeg."

I don't see any LICENSE.txt file nor any mention of the GPL or the LGPL in the version of the product I downloaded. Running strings against the binaries looking for things like "public" doesn't bring it up either.

You mean, like these?

http://ffmpeg.mplayerhq.hu/shame.html

I happened to look at ConvertXtoDVD the other day. While ffmpeg itself is licensed under the LGPL, ConvertXtoDVD also appears to use both libpostproc and libswscale which are both GPL. The ffmpeg licensing page states, "If those parts get used the GPL applies to all of FFmpeg."

I don't see any LICENSE.txt file nor any mention of the GPL or the LGPL in the version of the product I downloaded. Running strings against the binaries looking for things like "public" doesn't bring it up either.

Mplayer. You have to get the codecs.

btw there once was a mplayer plugin for the alternate http source including cracked encryption
it never made it into main, because of coding style
see here http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-March/050179.html
worth an efford because of grown number of channels and true bittorrent source

hmm, so it is.
I must have been using the latest version from SVN
http://www.mplayerhq.hu/design7/dload.html

Of course, that means finding a load of libraries and stuff and then compiling it yourself.
It is not a wonderfully straight-forward process.
If you decide to try it then this page might help a bit especially if you are using debian or ubuntu
http://ubuntuforums.org/showthread.php?t=558538

Also, you might want to know about the -framedrop option which will prevent audio desync when the mplayer cannot render the video fast enough.
(it is not a solution, just a work around so that the audio stays in sync)

It's time finally there is some HW accelerated H.264 on Linux. Intel is def. on it, I read something on FFmpeg mailing list maybe this or around http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2008-February/042269.html post.

While SRT subtitles are simple, SSA/ASS subtitles can be anything but simple. VLC does quite well with SRT subtitles as long as they do not overlap (i.e. one subtitle line is already displayed when another is to be displayed). However, it ignores the vast majority of the SSA/ASS spec apart from timing (and to some extent, color).

For example, this is a SRT subtitle line:

10
00:02:17,679 --> 00:02:19,237
I'm really sorry.

From this you can determine the line number, the start --> end times, and the dialogue. It's plain text, although every now and then you might see the use of HTML italics (<i>italic text</i>). You can set what font these type of subtitles are displayed in, within VLC's preferences.

However, SSA/ASS subtitles are considerably more complex, and are widely used, especially for anime fansubs. An example ASS line looks like this:

[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:23:47.10,0:23:51.59,Ed - R,,0000,0000,0000,,{\be1\fad(200,200)\org(0,0)\c&H7B70ED&\2c&HB4AFE2&}{\k20}{\k30}na{\k35}mi{\k29}da {\k62}ga {\k64}ko{\k62}bo{\k26}re{\k30}so{\k40}u{\k37}na

The "Format:" line specifies what the information displayed in the "Dialogue:" line is. Comments can be included on "Comment:" lines. The text portion of this particular line is karaoke, and includes parameters to specify blurred edges, fade in/out, the origin point, color and alpha transparency (primary and secondary), and karaoke timing for each syllable. This is not simple, and VLC (up to the current release version) ignores basically all of it other than the timing and (to some extent) the colors. The font declarations are ignored by VLC, it would use whatever subtitle font you specified (or the default one). VLC is also often mocked because it will display the contents of {} if they are not valid SSA/ASS parameters. A number of groups tend to include notes inside braces, usually for editing purposes, because most players (other than VLC) do not display them.

Unlike SRT, the lines in SSA/ASS are not numbered, and do not need to be in the order in which they are displayed.

Here is the style information the line above uses:

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Ed - R,Cascade Script LT Std,45,&H00856232,&H00AB956E,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,2,0,7,40,20,20,1

Note that the first two characters of each color are for transparency.

Also, the assertion that subtitles are typically an ASCII file is generally untrue; while both of these types of subtitles can be a text file, they're more commonly found muxed into a container that supports multiple tracks, usually either as a .mkv or (less commonly, these days) an .ogm file. (Anime .mkv files are most likely to be x264 video.)

With regards to soft-subs, though, MPlayer is vastly superior to VLC, in that it handles subtitles properly, and you can set it to auto-play specific subtitles and audio (for multiple audio/subtitle track files) by adding the following lines to your ~/.mplayer/config:

ass=yes
embeddedfonts=yes
c