Git send-email on OSX

The TL;DR version of this guide

sudo -H cpan IO::Socket::SSL

sudo -H cpan -fi IO::Socket::SSL

sudo -H cpan -fi Net::SMTP::SSL 

Colloquy up and down

On a fresh Colloquy install, you will be surprised that the up and down arrows do not bring back the history of your chats. In reality it does, but you have to hold alt while pressing the arrows. This is so that you can move around your input field freely just with keyboard.

The problem is that there is no option in the preference GUI to change this behaviour and you have to resort to the command line, as pointed out here. I hope this will change in the future.

defaults write info.colloquy JVSendHistoryUsesOnlyArrows -bool true

OSX energy controls redux

It's not the first time I find myself complaining about one design aspect of OSX, despite appreciating most parts of it.

This time is the Energy Control panel, which in newer versions is merged in a single slider, instead of having the usual configurations "when plugged-in" and "when battery".

Luckily there is a way to restore everything properly this time, thanks to this helpful trick (from MacRumors forum).

edit "/System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86PlatformPlugin.kext/Contents/Resources/Your-Mac-Model.plist"
find:
<key>UnifiedSleepSliderPref</key>
<true/>
replace:
<key>UnifiedSleepSliderPref</key>
<false/>

Unfortunately I couldn't find a matching model number so I just ended up editing all of them >_<
But it worked, so yay!

A short story of interlacing in HEVC

And how it nearly ruined another video coding standard.

Everyone knows that interlacing was a trick in the '80s for pseudo motion compensation with analogue video. This more or less worked because it mimicked how television worked back then. This technique was preserved when flat panels for pc and tv were introduced, for a mix of backward compatibility and technical limitations, and video coding features interlacing in MPEG2 and H264 and similar.

However as with black and white, TACS and Gopher, old technology has to be replaced with modern and efficient technology, as a trade off of users' interests and technology providers' market prospects. In case you are not familiar, interlacing is a mess to support, makes decoding slower and heavily degrades quality. People saying that interlacing saves bandwidth do not know much about video coding and bad marketing claiming that higher resolution is better than higher framerate has an effect too.

So, when ITU and then MPEG set out to establish the mandates for a new video standard capable of superseding H264, it was decided that interlacing was old enough, did more harm than good and it was time for retirement: HEVC was going to be the first video codec to officially deprecate interlacing.

Things went pretty swell during its development, until a few months before the completion of the standard. A group of US companies complained that the proposed tools were not sufficient (a set of SEI messages and treating fields like progressive frames) and heavily protested with both standardisation bodies. ITU firmly rejected the idea (with the video group chair threatening to step down) while MPEG set out to understand the needs of the industry and see if there was anything that could be done.

An ad-hoc group was established to see if there was any evidence that interlaced coding tool would have improved the situation. Things looked really shady, the Requirements group even mentioned that it was the first time that an AhG was established to look for evidence, instead of establishing an AhG because there was evidence. Several liasons from EBU and other DVB members tried to point out this absurdity while the threat of adding interlacing back in HEVC became real. Luckily the first version of the specifications got published in the meantime, so this decision didn't slow down the standardisation process.

Why so much love towards interlacing? Well in the "rebellious" group defence, it is true that interlaced content in HEVC is less performant than in H264; however it is also true that such deinterlaced content in HEVC outperforms H264 in any configuration. Truth is that mass marketed deinterlacers (commonly found in televisions for example) bring a lot of royalty income, so it is normal that companies with vested interests would prefer to have interlacing in a soon-popular video standard like HEVC. Also in markets like US where the network operator (which has control on the encoding but not on the video source) might differ from the content provider, it could be politically difficult to act as a carrier only if you have to deinterlace a video.

However these problems are actually not enough for forcing every encoder, decoder, analyser to support a deprecated technology like interlacing. Technical problems can be solved with good deinterlacers at the top of the distribution chain, while political ones can be solved amending contracts. Plus having progressive only video will definitely improve quality and let the industry concentrate on other delicate subjects, like bit depth, both properties going in favour of users' interests.

At the last MPEG meeting, the "rebellious" group which had been working on reintroducing interlacing for a year provided no real evidence that interlaced coding tools would improve HEVC at all. The only sensible solution was to disband the group over this wasted effort and support progressive video only, which is what happened luckily. So now both ITU and MPEG support progressive video only and this has finally nailed it.

Interlacing is dead, long live progressive.

Written by Vittorio Giovara (projectsymphony@gmail.com)
Published under a CC-BY-SA 3.0 license.

Libav 10 and my first year with the team

I am very glad to announce that Libav 10 has been released!

This has a bunch of features that I contributed to, in particular regarding stereoscopic video and interlaced filtering, but more importantly this release has the work of an awesome group of people which has been carried out for a whole year. This is the magic of open source!

I joined the group more or less one year ago, with some patches regarding an obscure H.264 specification which I then later reimplemented in HEVC and then I wrote a few filters I needed and then designed an API and then, wow! A whole year passed without me noticing, and I am still around, sending patches to the same group of people who welcomed someone who had problems with shifting values (sad but true story)!

I met the team both at VDD and FOSDEM and they've been the most exciting conferences I ever went to (and I went to a lot of them). I couldn't believe I was with the devteam of my favourite multimeida opensource projects I've been following since I was a kid! Until a year ago, I saw the names from the commits and the blogposts from both VideoLAN and Libav projects and I had been thinking "Oh wouldn't it be so cool to be like one of them".

The answer is yes, it definitely would, and it's something that can happen if one is really committed in it! The Libav Info page states "Being a committer is a duty, not a privilege", but it sure does feel like one.

Thanks for this exciting year guys, I look forward to the next ones.

MacVim and gVim and Vim configuration

Remember that if you use gVim or MacVim the configuration file is different! GUIs for vim read the options in .gvimrc instead of .vimrc.
However most of the times it's enough to have a simple simlink from one to another, so just do

ln -s ~/.vimrc ~/.gvimrc

Note that just deleting .gvimrc won't be enough, as defaults will be loaded then.

Strage issue with Fastweb and SSH/GitHub

I recently changed my Internet Service Provider and suffered from a strange connectivity issue.

When connecting to SSH on Fastweb network I got some random hangs and especially on GitHub I couldn't either fetch/clone or anything.

The solution is quite strange, as found on this forum, and requires to add a flag to every connection made, -oIPQoS=cs0

However it's not possible (or I haven't found a way how) to set connection parameters for git, so I had to rename the system ssh into ssh_right and supply this simple script instead:

$ cat /usr/bin/ssh
#!/bin/bash

exec ssh_right -oIPQoS=cs0 $@

When git cloning locally...

If you clone a local git repository while you are on a given branch, also the new clone will be on that branch.
This is solvable by some easy git fetch but the HEAD will point to the first branch, and will give you headaches when you have to rebase.

the solution is *not* set-upstream, which will track changes from another remote by default, but *set-head* which will point to another local branch.

So, to restore sanity

git remote set-head origin master

clang colorized html output

I love that clang has COLOURS in its output, but how to keep this formatting when copying the output to a file?

The solution is simple, add a -fcolor-diagnostics option and pipe the result to ansi2html. Of course since most of the interesting output is on stderr, don't forget to correctly redirect it (2>&1).

So in the end

$ clang -fcolor-diagnostics temp.c  2>&1 | ansi2html > temp.html

Many thanks to nemo for sharing this trick and several others on this blog!

pemissions on .ssh

Remember that every user's .ssh folder needs to have 700 as permssion, or ssh will complain and revert to passphrase authentication.

It is also good practice to have authorized_keys as 600.

Libav function prefixes

For future reference, all (or most of) functions and structs in libav have a prefix that indicates the exposure of that functions. Those are

• av_ meaning a public function, present in the API;
• ff_ meaning a private function, not present in the API;
• avpriv_ meaning inter-library private function, used internally across libraries only.

Source: #libav-devel

CMake library location

For some reason, you either know what kind of library you're going to build (STATIC or SHARED) or there is no way to know which prefix and suffix your library is going to get.

However, you can use the LOCATION property of the target and do some magic there.

See http://www.cmake.org/Bug/view.php?id=5195

Fast authors for Mercurial

In case you need to find out who commited the first version of a file to a Mercurial repository, there is this little command that does so quickly.

hg log -r 'first(file("path/to/file"))' --template '{author}\n' -f

This is using hg log together with hg templating. You can customize your output with stuff like {date|isodate} or {desc). -f follows through renames and removals.

Working with D3D9 device Reset()

...lost context and going fullscreen!

At work I got the opportunity (sigh) to work with some DirectX rendering for video pipelines.

A lot of fun was spent in trying to make the graphics card behave correctly during a context restore. When switching fullscreen or changing modes there are very precise steps you must follow or you get very cryptic error messages (by the way using M$ tools is no fun at all and I'll explain why) .

First of all when you switch to fullscreen you need to call Reset() on your device with the new backbuffer size, which *must* correspond to one of the resolution supported by your device (and don't forget to set the refresh rate too).

Before doing so you absolutely need to delete any surface, shader and whatever you allocated with a Get* method, using a proper Release() call. Beware *not* to delete your d3ddevice [1]. Then you just recreate all surfaces and you are done, it make sense to reuse the same initialization code for this purpose.

If you don't do this procedure you can get different results, but usually you'll just get a lot of D3DERR_DEVICELOST after a Present(), and only after it (so don't bother checking for this error anywhere else). Other rendering functions such as StretchRect() will just silently fail.

In order to avoid leaks of any kind and check for other errors you might be tempted to use DirectX Control Panel and turn on the Debug version of DirectX. This might work, but beware that on some architectures (I'm looking at you, NVIDIA ION) you might get a lot of exceptions (especially in within Reset()) that make no sense at all [2]. While normally these reports are useful and the breaks help you find mistakes, sometime it just get frustrating when there is a bug on someone else's code.

So if you get desperate in debugging a perfectly working restoration code, just try disabling debug mode or run your code on another architecture...

[1] Actually you can delete the d3ddevice, but then you don't have to call Reset() and have to recreate both the device and the surfaces again. It works but screen glitches a lot and it's a plain waste of resources.

[2] Error such as "Lost Device Due to Display Uniqueness Change" and "Could not get exclusive mode when we thought we could". If you Google them you'll get a lot of information on how to properly do a context restore, but the solution might be closer than you thing.

Finally one libvlc_video_set_format_callbacks() example

libVLC new (2.0) API for video size and chroma (libvlc_video_set_format_callbacks) is much more powerful than libvlc_video_set_format. It allows either to get video size and chroma dynamically so that your rendering pipeline can adapt, or to modify such values to get the values you need.

However, I find it a little more complicated to use and spent some time looking for an example. Apparently I am not alone, so I'll share my finding.

The main source example I found is from FBVLC, a web browser plugin based on VLC. You can read the full source here: http://code.google.com/p/fbvlc/source/browse/FBVLC.cpp

Basically you need to create two functions with this exact signature

static unsigned video_setup_cb(void **opaque, char *chroma, unsigned *width, unsigned *height, unsigned *pitches, unsigned *lines);

static void video_cleanup_cb(void *opaque);

and as the names go initialize all variables in the first function and cleanup in the second one. You can find sample implementation in the previous source code, under the name of

video_format_cb and video_cleanup_cb.

I spent some time in selecting the right chroma to adopt (and missed the fact that you had to memcpy there) for my standard h264 420 file "RV32" was working fine. Also the pitches variable is important, it represents the the video width in luma components, so for 420 it corresponds to width * 4.

I want this bugfix

Please commit it NAO

http://savannah.gnu.org/bugs/?23273

CMake Linker Test Flags

Source: http://www.cmake.org/pipermail/cmake/2011-July/045525.html

If you need to test linker flags, try out this code snippet, and make sure to unset the variable or subsequent tests will fail!
 

include(CheckCCompilerFlag)
set(CMAKE_REQUIRED_FLAGS "-Wl,-z -Wl,noexecstack")
check_c_compiler_flag("" HAVE_NOEXECSTACK) #empty because we are testing a linker flag
if(HAVE_NOEXECSTACK)
    list(APPEND pascal_flags "-k-z" "-knoexecstack")
    if(NOT ${MINIMAL_FLAGS})
        set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${CMAKE_REQUIRED_FLAGS}")
    endif()
endif()
unset(CMAKE_REQUIRED_FLAGS)

Dangerous history editing with Mercurial

...let's be revisionist for once

I decided to stop worrying and love the bomb, it was time to edit the immutable repository history of Mercurial! Thanks to the power of hg I almost lost every changeset I was working on but in the end I succeeded in modifying a few past changesets.

I spent some time between documentation and tutorials so I'll sum up the most important commands with a brief description.

You start off by populating your queue with a few revisions with

hg qimport -r revision_start:revision_end

this will generate one .diff file in .hg/patches for each revision between revision_start and revision_end. Afterwards you remove every (with -a in the example) patch from your local repo, so that only the ones in .hg/patches exist. You do so with

hg qpop -a

and then you can edit whatever revision simply by modifying the equivalent rev.diff file. You can merge, delete and add changesets withqdelete qnew qfold
When you are done with modifications you just have to re-apply your revised patches with  

hg qpush -a

and complete the editing with

hg qfinish -a

Not bad.

Achievements in BitFighter

...8 BitFighters make 1 ByteFighter

Today I got mentioned in the credits of Bitfigher, a neat two space shooter multiplayer game.

* BFLogBot Commit: 4a4fe6ac0503 | Author: buckyballreaction | Message: koda now belongs in the credits 

I really appreciate the endless support from the developers while I break their sources!
Check out this awesome game: www.bitfighter.org.

Breaking the Great Firewall

...breaking the law, breaking the law!!!

I'm in the main country of Asia on a work trip and I don't really like the censoring applied here. I will briefly explain how to use the Internet like it should be.

1. Set up a computer with an accessible IP address with an SSH server (I recommend doing this while you are still in your country)
2. Connect using this line

   ssh -ND port usrname@host
   

   -N disables shell input
   -D is the port which will be forwarded to
   username@host is your ssh server
3. Go to Firefox under Options->Advanced->Network->Settings, select Manually enter proxy information" and in the SOCKS section insert 127.0.0.1 and
4. Enjoy your free internet

Now, traffic might be a little slow so I recommend using the Foxy Proxy Firefox extension and manually set the website that are needing it. This extension replaces Firefox proxy implementation so you'll have to configure it again by creating a 'New Proxy' and inserting the site rules like in the example. Don't forget to activate the proxy and Foxy Proxy itself in the main page.

By the way Blogger is normally blocked here, so you'll have to read this blog before leaving.