Nepherte (dot) be

As mentioned earlier, I’ve set up an unofficial arch user repository to share my builds with everybody. Today I will elaborate a little more on the provided packages.

If you look at the current package list:

• x264
• ffmpeg
• mplayer
• ffmpeg-mt
• mplayer-mt
• mpd
• netembryo
• rxvt-unicode

you might be wondering why I provide these packages. All but three can be found in the official repositories after all. In short: I either upgrade them much more frequently, they differ much from the official packages, they are not available in the official repsitories or all of the above. Now I will go more in depth for each package.

x264, ffmpeg and mplayer

These 3 packages are being actively developed. Many new changes are made even in the scope of just a week. Understandably, the arch packagers can’t rebuild these packages whenever changes are made. I repackage them on a monthly base which makes my packages usually a lot more up to date than the official ones.

This, however, is not the main reason I make these 3 packages available. The official arch mplayer build incorporates its own internal static version of ffmpeg (as recommended by the mplayer devs), ignoring the already available ffmpeg on most systems. This approach results in duplication of code and bigger packages. In the programming community, duplication of code is something that one tries to avoid at all cost, as this usually implies a bad design. I apply the same principle to my packages: compile once and use them everyone else.

Some less commonly used options in mplayer and ffmpeg are also disabled:

• No image support in mplayer.
• Many exotic audio/video ouputs and audio/video codecs are disabled.
• No tv or radio support
• …

I also include features not available in the official mplayer package such as pulseaudio support. I’m a huge fan of pulseaudio and support it in all the packages that can handle it.

ffmpeg-mt and mplayer-mt

ffmpeg-mt and mplayer-mt are the multithreaded versions of ffmpeg and mplayer respectively. They have the same feature set as mentioned in the topic on their single threaded versions. If you have no graphics card that supports hardware accelerated video playback, then this is what you want to playback high definition movies.

mpd

In this package, I mainly strip away less commonly used options and only add 1 new feature:

• no http output
• no last.fm support
• no oss output
• no ipv6
• pulseaudio support

netembryo and libnemesi

I maintain both netembryo and libnemesi in AUR and might as well just make a binary version available as well.

rxvt-unicode

This build contains a particular patch that fixes the resizing of this terminal in tiling window managers. Otherwise there always black borders surrounding each terminal window which is just plain annoying

I’ve just packaged and added ffmpeg-mt and mplayer-mt to my arch user repository for all of you out there without hardware accelerated video playback. For more information about my personal repository, including usage instructions, view my repo page. To activate n threads in mplayer, use the following command:

mplayer -lavdopts threads=n moviefile

Instead of constantly typing that command, you can also add it to the invaluable mplayer config file located at ~/.mplayer/config:

[default]
lavdopts=threads=2

Obviously I’m not one of the happy few that have a graphics card with support for hardware accelerated video playback (vdpau for nvidia). When playing a 1080p high definition movie without vdpau and with the singlethreaded mplayer, the movie becomes pretty much unwatcheable: video stuttering, audio running behind on video or vica versa, fastforwarding crashes mplayer, … It’s odd that in a world full of multicore processors, a multithreaded video player isn’t a commodity and probably never will be. Nonetheless I believe there is actually a market for this. After all, not everyone has a fairly recent graphics card (less than 3 yeard old).

With the multithreaded mplayer all of that changes. I am in the possession of an AMD Athlon64 X2 3800+, the first dual core cpu series of AMD, and playback of a 1080p movie with a video bitrate of 15.5Mbps is smooth. It doesn’t even use the 2 cores to their full potential. It appears I only needed a little more but o so necessary cpu power to play it. Until I buy a recent graphics card, hopefully in the very near future, this will certainly do the trick.

For the last decade, there has been a disturbingly major increase in cross site request forgery attacks (csrf). In this kind of attack, an unauthorized request from the user’s browser is made to a vurnerable website to execute an unwanted action, without the user even noticing. These unauthorized requests can be triggered by mails or websites containing malicious <img> or <iframe> tags, for example discussion boards that accept html input. Examples of unwanted actions are stealing sensitive data,  wiring money from one account to the other, …

These csrf attacks are very problematic because it is difficult for a user to protect himself from it without completely degrading the web experience, such as disabling javascript (which is not necessarily a sufficient counter measure). It is mainly up to the developer of a site or web application to prevent these attacks by making sure it is impossible to store code on their site that launches such attacks and by making sure their site is not vurnerable to such attacks. But truth is that most developers are just clueless.

However, distrinet, a reseach group of the University of Leuven, has published a firefox addon called csfire that attempts to mitigate csrf attacks. You can find the paper on csfire here.