MPlayer2 Experimental Package

Yesterday I came across a fork of mplayer called simply mplayer2. When I read it supports ordered chapters, I knew I had no other choice but to build it (as there does not seem to be any other distro package for than for gentoo). To my surprise, the build itself takes about 10-15 minutes so apart from figuring out and installing all the deps it was pretty fast process. The resultant SPEC file used to build the package can be found on my fedorapeople space. It uses same executable name, so it cannot coexist with mplayer and I didn't bother working around that.

Some of its killing features include:

• Ordered Chapters (finally is this Matroska feature supported on linux!)
• Dynamically loads system libraries, including ffmpeg and libass (which among other things means that when ffmpeg is build with multithreading support, mplayer2 is prepared to take advantage of it)
• Uses libass for rendering subtitles by default (yay, finally vertical Japanese subtitles are rendered properly)
• Does not unpause paused movie when e.g. switching to/from fullscreen, seeking, etc.

Plus it seems at first sight that frame-dropping works without any problems (I always had problems with it in mplayer).

So, I'd like to add, if you want to try it, here's your chance but I warn you that it's not your usual high-quality package you are used to in Fedora ;-) Plus, it does not include gmplayer and mencoder as the devs decided to drop these from the codebase (you can read more about that on mplayer2 faq page)

And on a almost unrelated note, first thing I watched using mplayer2 was 君に届け [Kimi ni Todoke, Reaching You], the live action movie version. I have to say I liked it a lot (I admit that despite being healthy boy, I have a soft spot for East Asian romance often found in shoujo manga) and starting today I have new favourite actress :-D Her name is Renbutsu Misako (Renbutsu is surname), she's twenty and she played Chizuru (one of the main protagonist's best friends, see the picture bellow). For those not being able to read Japanese: she's from Tottori Prefecture (west part of Honshu, about 200km north-east from Hiroshima), she likes guitar and drawing picture books and her special skills are piano and karate. Quite an ideal woman for me :-D



Update: I've been reminded that fedorapeople is bound by the same rules as fedoraproject with regards to forbidden stuff, so until I find a better location you can find only SPEC (that AFAIK does not qualify as redistributing patent encumbered software) there – you should be able to download the source from upstream directly and build the package, right ;-) Have I already said that I hate software patents with a passion?

Update (2011/04/08): I've updated to final 2.0 release. Apart from that the update contains a fix for debuginfo package build, disables mp3lib build (which was producing broken audio for me) and contains a config file (I shamelessly stole the config file laying in source and edited it for fedora needs) which sets pulse as default audio output (alsa isn't performing 100%, sometimes mplayer2 refuses to "unpause" with alsa audio driver).

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.

GStreamer is the future?

Hi, with today's news I though I'd share some sentiments I have about the future (and partly present) of multimedia (meaning only video and audio in this post) in linux.

First take a look of what we have now. We have two major libraries written to do the job and another two players doing the same, but with their own libraries integrated. I am talking about gstreamer, xine-lib, mplayer and vlc.

Let me state I was originally a huge fan of xine-lib but during some of the recent Fedoras (namely Werewolf and Sulphur) I slowly dissolved from it for various reasons I explain later. During the same time I became a frequent user of gstreaer and mplayer. I haven't ever been a fan of vlc and I don't like it's ui, but that's not what I'd like to talk about in this post.

So, with linux expanding to desktop machines we need to have also some good way of playing various multimedia ranging from youtube videos through full HD mpeg4-AVC/h264 to our favourite songs in mp3. Or we'd like to share our screencasts in theora, back-up favourite recordings saved in FLAC or burn an audio CD out of our vorbis encoded music collection. And to add to this lot something more - there are zillions of various containers from aging AVI, through "home-made" OGG or playstation 3 compatible MP4 to modern "I can do anything" matroska.

To be able to keep up with the world we need a solid framework that has good enough code, and is easilly expandable to contain new codecs. That's where mplayer or vlc fail - you cannot build up a serious app using their libraries (since they are shipped together with the player), you can just wrap up the player into nicer gui. Also the pace of adoption of new codecs is rather slow (as I'll explain later on some examples).

This is where gstreamer and xine-lib comes. Xine-lib is pretty interesting library, since it has similar capabilities to mplayer it's one of the "great three" of linux video players - mplayer, vlc and xine (which is official frontend to xine-lib). It has great amount of configurability, which makes it more geek-friendly, but everything has it's buts. The design of the library is not that great, as can be proved how much time it took before it could be reasonably split to free and nonfree (patented stuff) version, also it seems not be able to "keep pace" with the age (it took far too long before they get good enough pulseaudio audio output working), it seems to be more susceptible to crashes than gstreamer or mplayer and does not seem to be good on hardware (seem to need more power to play videos).

That, and the continual (and rather fast) improvement of gstreamer drove me away from xine-lib based applications (though I still keep gxine around, partly because I maintain gxine package for fedora). And why gstreamer? You *could* say it's rubbish, but cannot anymore. Yes, back in Fedora 6 it was the half-working default (implemented in totem). That it wasn't "good enough" was proved by most of users switching totem to xine-lib backend, installing xine, gxine or kaffeine, or going the mplayer/vlc way. Not anymore. Over the past few releases it wastly improved no only thanks to it's plugins system.

In gstreamer (as my understanding of the basics is) you have the basic framework and a lots of separately installable plugins (though batched together in logical packs) which can make it rock. Most likely you'll have installed only the base and good plugins which covers almost everything in the FLOSS codecs, containers, ... world. In addition to that, to be able to play more widely used content, you need to install bad and ugly plugins, or perhaps the ffmpeg plugin (ffmpeg is library for decoding/encoding using of the MPEG codecs and more). That makes the framework more robust, more configurable and also easiest to implement new codecs to.

One of the examples where you can find only a limited number of players being able to play it THEORA video in Matroska container. It's perfectly correct usage, adhers to both THEORA and Matroska specifications, but behold - xine-lib based players cannot play it, vlc cannot play it. And "rare combination" excuse does not stand a chance. It's working flawlessly with mplayer, it's working flawlessly with gstreamer - that's two working implementations already. GStreamer can even both encode theora video to matroska container and read it afterwards, mplayer (resp. mencoder) wasn't capable of muxing matroska last time I checked.

Now another example is adopting of brand new and partly "scientific research" codecs like Dirac or Schroedinger. Did you know that the only way how to encode video using schroedinger codec with fedora is using gstreamer? Did you know that the only way how to play Dirac/Schroedinger videos, be it either in OGG or Matroska, is to use gstreamer? Yes, there are patches for mplayer, xine-lib, ... but they're not in. Why? Because it's a patch and that means modifying source code and it needs to be accepted by the developers of xine-lib, resp. mplayer, first. In gstreamer though, the only thing you need to do is write a plugin - that means you do not need to wait till your code is accepted, it does not need to be, because it's standalone. It can be published and installed separately. And that is a great advantage.

And to add more fuel to the gstreamer camp, it seems there will be a way, thanks to gstreamer being plugin-ready, RPM being able to know what plugin handles what, PackageKit being able to install and depsolve all the needed plugins and plugin (yet-to-be-written) being able to tell PackageKit that gstreamer needs plugin to handle this or that, and given you have all necessary repositories installed (in Fedora case it's most likely livna, or rpmfusion in the future); the installation of codecs will be completely automatic. GStreamer sends a request to PackageKit to install missing plugin (more exactly to install something that provides the necessary functionality), PackageKit hopefully finds it in the repos (thanks to RPM being able to provide information about what content the plugin handles), resolve all the needed dependencies and tada - you can play the video.

I just can't wait to see this in actions!

The only thing that still keeps mplayer on my machine is its support for SSA/ASS styled subs. Not only it can parse it, but it can also render the advanced styling correctly. I wonder if there is a RFE for this in gstreamer bugzilla already, or whether I should move my butt and file one :-D

PS: I am too lazy to add references this time (partly due to me being ill), so use google to find what you'd like to read more about, e.g. googling for "dirac video" gives you on the first hit the homepage of the Dirac and Schroedinger codecs.

Making Good Screen-casts - How To?

I am gradually making some screen-casts for echo tutorials and I wonder what is the best way to make them. There is a lot of options and one needs to choose... What I've done so far is available on my Fedora People page.

First thing to choose is the application that will do the actual screencast. From rough investigation I discovered these three that are available in fedora/livna:

• instanbul - easy to use, however almost non-existant configuration, output compressed terribly much, which makes the video small but ugly
• xvidcap - configuration options are pretty good, you can customize the output as much as you want, however tend to freeze during captioning, also does not support encoding to theora
• gtk-recordMyDesktop - seems to support output only to ogv/theora/vorbis, not very well handled area selection, adds skeleton track to the output, usage not very intuitive

So after some thinking I dismissed instanbul, as the output does not have the desired quality (and I cannot do anything about that) and xvidcap due to frequent freezes (before that I managed to record one 3 min long screencast though). That leaves gtk-recordMyDesktop.

Next, we need to decide about the content - will we add commentary? If yes, will it be spoken or via subtitles? Subtitles are very good for translating, you just use the original one and use e.g. subtitleeditor (in fedora repos) to make a translation without changing the subtitles timing/styling. Also it's good for deaf people. On the other hand, you need to show the subtitles somewhere, which might render the part of screen on which they are shown unreadable. You can minimize the costs by using styled subs (e.g. ASS/SSA) to position the subtitles, but you'll then need special programs that can handle the styling (e.g. mplayer with -ass option).

Audio has the drawback that it can be hard to understand, for the person doing the screencast harder to create (not all of us are good English speakers), also it's harder to make a translation. So I guess subtitles are overally a better choice.

Now what format choose for video? If I had a choice, I'd go with MPEG-4/AVC (H264) which is excelent format with probably the best quality to compression ratio (and is pretty much used for most of HDTV content). It has however a drawback of being patent encumbered which renders it not an option for videos targeted on all Fedora users (even though you can play it in Fedora if you install additional codec packages from livna, but that's not an official Fedora repository). Software patents also put out of the game most of the other codecs, which leaves Theora. It has pretty good quality to compression ratio and is already the output of the gtk-recordMyDesktop, so if you are content with the compression, you don't need to recompress/re-encode the video.

Lastly we need to choose a container format. In opensource world the best choices are probably OGG/OGM/MKV (listed in no order). I don't know if OGG can handle subtitle tracks and OGM seems to be rather hack of OGG to better support videos. It's not much widely used either. On the contrary Matroska Video (mkv) is designed to be portable, fast, open, ... It can contain almost anything which renders it almost ideal container for shipping videos (it can contain multiple video, audio, subtitle tracks, fonts, various other files..., and yet it's generally very fast). It also comes with handy tools that makes adding new subtitle or audio track to existing video a piece of cake [mkvmerge(-gui)].

So what's my choice? It's obvious from the previous text:

• gtk-recordMyDesktop
• Theora
• ASS/SSA subtitles
• Matroska Video (mkv)
  
• (optionally Vorbis audio)

What do you think? Do I have even better choices?