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