Lair Of The Multimedia Guru

Ive been using gmx since over 12 years for my email. And until recently gmx did a fine job at running a SMTP and a POP3 server. But it appears this is slowly changing. A few month ago their SMTP server stoped accepting mail with the verbose message: “550-Requested action not taken: mailbox unavailable\n550 Reject due to policy restrictions.”. It turned out that gmx refused localhost as domain to the EHLO SMTP command. They require a fully qualified domain name now right? no, not really, any random string seems to work just not localhost. My attempt to contact gmx about this, lead to no reaction.

The next thing was this: “550-Requested action not taken: mailbox unavailable\n550 invalid DNS A/AAAA resource record”, yes thats right, gmx rejected outgoing mail because the poor guy had not set up a webpage on the domain that he used to receive mail on. This one btw affected multiple people i tried to communicate with, not just one.

But hang on it was just starting, next there was “451 Requested action aborted: local error in processing’ errormsg=’recipient address nicolas george normalesup org not accepted by the server”

Also it has to mentioned that gmx at around that time (maybe 1-2 month before or so) started to randomly put “*** GMX Spamverdacht ***” in the subjects of random received mails even though i always had and have all spam filtering disabled at gmx (mainly because their filters never worked).
So yeah another try at complaining to gmx about that, and yes this time there was a reaction, i got a mail from them “GMX Sicherheit: Vorsorgliche Sicherheitssperre Ihres GMX Postfachs!” they locked my account and provided me with a few tips on how i can scan my windows system for viruses. Hello gmx, i dont use windows.

My next attempt to contact them and now find out why they locked my account lead to just a polite (probably automated) mail with a link to their payed and expensive phone support. Seriously, locking someones account and refusing to tell them why unless they pay. And locked btw means SMTP was not working, POP3 still worked and so did the web interface where one is asked to change ones password which then unlocks the account again. Maybe iam just missing the point but what sense does that have.

Was that all? no, it seems gmx also reduced the maximum size of mails as a 21mb mail i tried to send to 3 people could not be sent over gmxs smtp server and with a different smtp server it bounced from reimar who also uses gmx so it also could not be received. Iam pretty sure i did transfer bigger things years ago.
Ahh and i almost forgot: “5.7.1 : Recipient address rejected: Your MTA is listed in too many DNSBLs; check http://www.robtex.com/rbl/82.165.159.40.html”, Yes thats gmx being in the DNSBL lists at the time that happened. Now just why was i not surprised by that …

Did anyone really read this far down ? Well as gmx slowly goes from well working to something else, iam forced to find alternatives to handle email. So i got this one: michael@niedermayer.cc, iam still using the gmx addy though, feel free to use either if you want to mail or spam me. I guess if these issues with gmx continue then ill have to start updating my mail address everywhere …

2014-01-26 Update

Heres an example of the random marking of mails as spam, the 2 mails where simple git patches send to ffmpeg-devel, sent by me, at the same time from the same computer and their content should be quite similar and should not have triggered any properly trained bayesian filter.

85260 N 0126 2:11 Ronald S. Bultj (1.3K) [FFmpeg-devel] [PATCH] vp9: disable use_last_frame_mvs on resolution change (scalable).
85261 N 0126 2:30 Ronald S. Bultj (8.9K) [FFmpeg-devel] [PATCH] vp9: fix invalid ref frame w/h on size change.
85262 N F 0126 14:49 To FFmpeg devel (1.2K) [FFmpeg-devel] [PATCH 1/2] avcodec/libfdk-aacenc: change MODE_7_1_REAR_SURROUND to map to AV_CH_LAYOUT_7POINT1
85263 N F 0126 14:49 To FFmpeg devel (0.9K) ??>*** GMX Spamverdacht *** [FFmpeg-devel] [PATCH 2/2] avcodec/libfdk-aacenc: change MODE_7_1_FRONT_CENTER to map to AV_CH_LAYOUT_7POINT1_WIDE_BACK

Also ive sent gmx a link to the blogpost, no reaction from them so far

A few years ago i bought a 24mm f/2 vivitar lens for something like 15 euros, the price was too good to not buy it. It was laying around pretty much untouched until a few days ago

It has a Canon FD mount, which means it is compatible with all Canon FD cameras. Sadly iam not a big fan of these cameras, I like conveniently working manual mode and digital. Adapters for FD->EOS exist but they require optical elements to compensate the otherwise negative adapter thickness that would be needed. So a more geeky solution is needed. But first problem with it is, its aperture is stuck and full of oil

Now cleaning an aperture is not hard, though do NOT try it with this lens if its your first such repair attempt, as this lens is a floating element design, which in laymen terms means complex. The tools you need are just a bunch of small screwdrivers (for most screws the cheapest will do), some paper towels for various things, a clean soft brush to remove dust. And something to clean the aperture blades, probably anything that removes oil would do. And a box of some kind to put all parts in when taking them apart so tiny things are trapped by gravity inside a quickly search-able space and not your whole room. First step is to loosen the screw on the side of the front

After that the top can be unscrewed, the next part is hold in place by a similar screw, loosen it too and unscrew the part, be careful as this exposes the front glass element and if you take it out, only thing you will achieve is getting dust in.

Now you need to remove the 2 screws and the part that holds the front lens group in correct distance/rotational alignment, you do want to take some notes or add markings to get it later back in exactly the same position. As i am lazy i relied on my carefully composed pic above instead of wimpy notes or markings. You also need a good screw driver here as these screws arent easy to loosen even after removing the stuff that holds them in place with aceton. After you removed the 2 screws and that thingy, put the ring that held the front element in place back so the element doesnt escape

Once the glass is secured you unscrew the front group as a whole (you have to turn it in the other direction from what you expect). After unscrewing it you reach the front side of the aperture. And here i believed i could just remove the 3 screws and take it out, but no its not nearly so easy.

So as we cant get it out yet, disassembling of the bottom is next, remove the 3 screws that hold the mount in place, beware there is a spring, a small pin and a metal ring that are more or less loose

The rear lens group is just screwed in and can easily be screwed out, allowing us access to the rear part of the aperture, what the annoying part is we still cannot take it out for proper cleaning.

To move forward next step is to remove the 2 screws and the part that hold the inner rear part in distance and rotational alignment, again take notes and make markings, the rear part is a little fiddly to put back together with markings (aka expect 2-3 minutes for doing that later) without markings, it would probably be fun but not impossible.

Now the inner rear can be screwed out. And hidden you will find 3 holes in the helix, in these holes there are screws that hold the aperture in place, to loosen them take careful note of their original position, or just be lazy and do like I and do exactly 3 full turns, so you can get it back with 3 exact full turns later. It shouldnt ruin the lens if the aperture isnt centered exactly but id guess there was a reason for this odd way to mount it

Once the 3 screws are loosened a bit (and a spring is removed) the aperture can be taken out, its further disassembly and reassembly should be obvious. To clean it you can probably use almost anything, i used a little window cleaner in a small container put all parts in and used the “shaken but not stirred” technique, in addition cotton buds and 100% ethanol. Note the pictures below dont look so oily because I tried cleaning it before full disassembly with cotton buds

Once cleaned, reassemble everything, its trivial just reverse of disassembly

From FD to M42 to EOS

The rear FD mount was kept in place by 3 screws, looking a bit around i found a worthless 35mm/2.8 M42 lens laying around that only produces blurry images no matter what, though it was in 100% perfect condition, surely used only once by any previous owner. Its rear fits almost, 2 out of 3 screws can be screwed in without modification. For all 3 a little drilling is needed

With this hack it can be mounted on any M42 camera or with M42-EOS adapter on any canon EOS DSLR. it doesnt focus beyond 1m in that configuration though. That is at 1m real distance you are at infinite on the scale. Also its easy to switch the mounts back :)

Now to get it focus to infinity we need to loose some material, first the M42 rear i picked had a circular ridge that screamed to me “flatten me”

The pic above shows it in the middle of the flattening process. This wasnt enough though, infinity focus still was far away, so the ring that keeps the aperture selection ring in place had to go too. Note, below the next (now loose) ring are 2 loose springs and 2 tiny steel balls dont loose them if you try this. A magnet is a pretty nice way to temporary store them safely.

With this ring too removed infinite focus becomes possible on M42 and EOS. But due to all the removals, one ring holding the aperture selection ring in place and the aperture controlling parts that where part of the FD mount. We still arent done, so next is rebuilding the aperture control parts that a manual lens would have. Ive build it out of a piece of aluminum that i found in a old box from my grandfather, I still remember how my mother wanted to throw all the stuff from him away, lucky i safed a few boxes…

Above picture shows it in partly finished state, it needed more filing and bending before it worked fully smoothly. The removed ring also needs to be replaced. One could have just made it thinner but i dont have the tools to do this exactly and quickly, besides it would make it impossibly to undo it. So i used a piece of plastic cut from a cap of something random from the bathroom, also to get the focus a bit closer to correct (it was way over infinity) i put the thin metal ring from the FD mount back in

And last fine-tuned the focus with the 3 screws intended for that purpose visible at an earlier picture, cleaned the glass a bit and ready is my 24mm f/2 vivitar/kiron for M42 and EOS.

Was the work worth it? For the lens/photography, probably not. For the fun and geek factor, absolutely yes. :)

Google is planing to drop h264 support from the video tag in chrome html-video-codec-support-in-chrome and more-about-chrome-html-video-codec. With some blah blah about open and patents

• real network, rv1, rv2, rv3, rv4 failed
• Apple SVQ1, SVQ3 (there was no 2) failed
• Microsoft MSMpeg4v123 WMV* failed
• On2 VP* failed
• Google VP ehm i mean webm ….

About open, ITU H.264 was developed on a public mailing list namely JVT-experts, using public FTP containing software, spec drafts, proposed changes, test results, meeting protocols and god knows what else. Anyone could read in near realtime what was discussed, proposed,changed and why and any expert that wanted to contribute iam pretty darn sure would have been taken serious. google webm is On2 last video codec, that to the best of my knowledge was developed behind closed doors by On2 and On2 people where on the jvt-expert list.

So calling webm more open than h264 is a insult at best, calling it less patent encumbered is something that will only be found out once its widespreadly used and third party companies have enough financial interrest in cross checking their patents against it. And about which has better compression vs quality, that was elaborated by others to great lengths already. I guess google needs a new motto, like dont be stupid

I found 2 Insects looking like this in my appartment:

Anyone knows what it is, its about 10cm large from leg tip to tip if it stretches out and capable of flight, seems not to have any inteligence to speak of. I could catch it and throw it out of my appartment but iam affraid its too cold outside?

Anyone knows what it eats? How long it lives?

Building a polynomial out of its roots is not particularly hard, one just multiplies the corresponding linear/first degree polynomials. But this isnt fast, even doing it recursively and using FFT based multiplication isnt all that great its still O(nlog²n). We can under some circumstances get rid of one of these log(n) factors as ill describe in a moment below. But first i wonder if below is the best that can be done or if iam silly and theres a faster or simpler way?

The idea of this method is not to build up the polynomial coefficients but to build up a vector of polynomial evaluations at evenly spaced points. Doing this for a linear factor “prototype” like x-1 on m points costs us O(m). next we build a sparse vector that is 1 where its index matches a root (and 2 for double roots,…) otherwise its 0. Now we can almost build our evaluation of the final polynom by convolution, just that convolution adds its terms while we need the factors multiplied of course. The solution is simply to convert the evaluation of the “prototype” linear factor by elementwise log() before convolution and by exp() afterwards. The value for log(0) does not matter for us except for numerical stabilty, we have to after exp() reset all roots to 0 anyway. With log(0)=0 one gets first order derivatives at the roots though. Also one can implement this using clasic log/exp and a complex value fft or finite field log/exp with a real or finite field fft. The last step of turning the evaluation vector of our polynom into coefficients can be done with a finite field fft. This make the whole thing run in O(m logm) time for a field size of m.

Whats annoying on it is that the the first part works with samples evenly spaced (aka an additative subgroup) while the second, that is turning the evaluation into coefficients is on a multiplicative subgroup of a finite field. In practice that means while my roots are along a multiplicative subgroup of GF(2¹⁶+1) i have to apply the rdft over the whole field. which is kinda feeling like a waste of cpu cycles

Suggestions to improve this are welcome. Also alternatively if one knows of a linear time method to zero pad in the frequency domain a block of size 2ⁿ to twice its size than the resursive multiplication variant should also run in O(n logn) time.

My acer NB today: Critical temperature reached (101 C), shutting down.
And disablng power management of the HD produces errors after a while, not just today but always.

A little rant to keep my blog from rotting, firefox after 3.0 or so no longer works on kernels that randomize memory allocation a bit. Ones choices are either patching firefox or to disable the randomization for it. And we all know if one application needs all the security layers one can get then its the modern web browsers.
Not to mention how one can be so lame to have such bug open for ages and still not even produce an error message but rather run mmap() munmap() in an infinite loop.

About a month ago we (the ffmpeg team) voted about which name our NGO to which people soon will be able to donate should have. A sideeffect of that is that the world now has one more application to count votes using various condorcet methods, borda count and instant runoff voting. Get it from svn://mplayerhq.hu/michael/trunk/ffvotetov with your favorite command line svn client while its still fresh ;).

The vote itself went pretty well, we had a huge participation and it was quite fun :). Less funny was that murphy hit us and the winning choices “FFmedia/Foundation for free multimedia” domain name was already taken by some anonymous person through domaimsbyporxy, who asked us for cash even to just forward a message. Luckily the 2nd most popular choice “FFMTech/Foundation for free multimedia technolgies” didnt had that problem and was just by 1 vote behind so we picked that.

About which voting method is best, i dont know, but for our vote at least they all produced the same result most of the time while people added their votes. In that sense i wonder if any vote in reality that used a condorcet method actually ever needed rules beyond condorcet like the popular schulze method? Anyone knows? i checked debians past votes but it seemed they all had a condorcet winner

ld.so is the little thing that loads all your shared libs and binds all the referenced symbols to their definitions, well more or less at least. I think a better name for it would be a russian roulett linker, it binds symbols correctly most of the time but if it fails you dont want to be anywhere close to its line of fire ;).

The problems start with a mistake,oversight or let me call it a typo in the ELF spec. More precissely every reference in every object, be that the application or a lib will be resolved to the first matching symbol definition. The search order is a breadth first search starting from the application. This doesnt look wrong at first and thats why i call it a oversight or typo. The problem is for example if your application links to libz1 and libpng1 while libpng1 links to libz2. All references to libz2 in libpng1 will be resolved with things from libz1 and if we now assume these 2 are incompatible … boom. Had the ELF spec required a breadth first search starting from the object that contains the reference this problem and all the ridiculous mess that i describe below would not exist.

As the ELF spec requires this quite unpractical behavior one would expect that there would be some option that could enable a more practical search order. Sadly there is not in GNU ld.so, instead people recomand to use symbol versioning as a workaround.

Symbol versioning, the heal all ill in a world free of thouse who wrote GNU ld.so.

Symbol versioning, as implemented by sun and later gnu has various purposes like finding the lowest version of a lib an application needs but in GNUs world it serves a much more important purpose, to workaround GNU ld.so fantastic misdesign.

The idea is that if everyone and everything uses symbol versioning then in our little example above libpng1 will use symbols from libz2 while the application uses symbols from libz1 and things actually work

The bad news is that symbol versioning is disabled by default, it can be enabled by using a version script or using –default-symver

The worse news is that you cant enable it if it wasnt enabled in a released binary without hell breaking loose due to the ld.so bugs i describe below

The Bugs in ld.so

Sorry for the long intro above but the whole really is a convoluted mess that is hard to explain …

If you add a version to an existing library without bumping the soname you will hit ld.so bug #1, an assertion failure if an application compiled against the versoned lib is linked to a lib without versioning:
Inconsistency detected by ld.so: do-lookup.h: 115: check_match: Assertion `version->filename == ((void *)0) || ! _dl_name_match_p (version->filename, map)' failed!
That one can be fixed by a single line change, commenting the assert out or as debian&ubuntu prefer by adding hundreads of dependancies (one for each use of the changed lib).

This bug is funny because if you rename the lib, load it with LD_PRELOAD and hexedit the filename out of it, it works and no more assert failure happens

But lets look at bug #2, ld.so will satisfy unversioned symbol references with the first symbol found versioned or not. This makes the coexistence of versioned and unversioned libs pretty much like walking a minefield. More specifically if you thought you can just turn versioning on with a ABI and soname bump, think again, it doesnt work because the old sonamed lib didnt use versioning the linker will bind references that where intended to the old lib to the new if that happens to come first in the list of dependancies.

And due to bug #3 ld.so will satisfy versioned symbol references with the first symbol found versioned or not. Unless the filename matches some test in which case bug#1 will end ld.sos life and also that of your application. Together with bug#2 this means if theres a lib with versioning and one without loaded, your references versioned or not can end up bound to either depending on luck the only thing you should not expect is that both will be bound correctly, because i think that cant happen at least not without very obscure tricks

The solution

Fix ld.so obviously, anything else is pure insanity, i dont even want to think further on what breaks and how it could be worked around. Heres a simple proof of concept patch but keep in mind this has only lightly been tested and it does not fix the root problem, that is searching is still in the silly order, just that now references will be resolved preferably with matching definitions and without random filename related assert(0).

A quick test and demonstration of the difference (id upload the tgz of the code if wordpress wouldnt disallow uploading tgz files)

./compileX.sh /lib/ld-2.9.so
Test for introducing versioning into A0 and a new A1 with versioning
Trying 6 A0:0 A1:2 B0:4 App:0
libA0 B:libB0 libA0 libA0
Trying 7 A0:1 A1:2 B0:4 App:0
libA0 B:libB0 libA1 libA0
Trying 14 A0:0 A1:2 B0:4 App:8
./app: ./libA0.so: no version information available (required by ./app)
Inconsistency detected by ld.so: do-lookup.h: 115: check_match: Assertion `version->filename == ((void *)0) || ! _dl_name_match_p (version->filename, map)’ failed!
Trying 15 A0:1 A1:2 B0:4 App:8
libA0 B:libB0 libA1 libA0
Test for introducing versioning into A1 and a new A0 with versioning
Trying 9 A0:1 A1:0 B0:0 App:8
libA0 B:libB0 libA0 libA0
Trying 11 A0:1 A1:2 B0:0 App:8
libA0 B:libB0 libA0 libA0
Trying 13 A0:1 A1:0 B0:4 App:8
./app: ./libA1.so: no version information available (required by ./libB0.so)
Inconsistency detected by ld.so: do-lookup.h: 115: check_match: Assertion `version->filename == ((void *)0) || ! _dl_name_match_p (version->filename, map)’ failed!
Trying 15 A0:1 A1:2 B0:4 App:8
libA0 B:libB0 libA1 libA0

./compileX.sh ~/libcugh/eglibc-2.10.2/build-tree/amd64-libc/elf/ld.so
Test for introducing versioning into A0 and a new A1 with versioning
Trying 6 A0:0 A1:2 B0:4 App:0
libA0 B:libB0 libA1 libA0
Trying 7 A0:1 A1:2 B0:4 App:0
libA0 B:libB0 libA1 libA0
Trying 14 A0:0 A1:2 B0:4 App:8
./app: ./libA0.so: no version information available (required by ./app)
libA0 B:libB0 libA1 libA0
Trying 15 A0:1 A1:2 B0:4 App:8
libA0 B:libB0 libA1 libA0
Test for introducing versioning into A1 and a new A0 with versioning
Trying 9 A0:1 A1:0 B0:0 App:8
libA0 B:libB0 libA1 libA0
Trying 11 A0:1 A1:2 B0:0 App:8
libA0 B:libB0 libA1 libA0
Trying 13 A0:1 A1:0 B0:4 App:8
./app: ./libA1.so: no version information available (required by ./libB0.so)
libA0 B:libB0 libA1 libA0
Trying 15 A0:1 A1:2 B0:4 App:8
libA0 B:libB0 libA1 libA0

A week? ago my good old duron cooling fan, a ac copper silent 3 started to make funny noises. It sounded a little like a seeking harddisk. Well i obviously had to and did get a new one, i also considered getting a new CPU but seems socket A cpus arent available anymore. Well i wasnt seriously looking for an upgrade anyway, just curious.

Once i had the new cooler, (i bought the same as the previous) i thought i take the failing one appart. I expected to find some screws behind the stickers but no, there are no screws on the thing. To get it appart you have to pull the rotating part hard, nice design. As expected it was quit dirty in there, especially the ring magnet, i cleaned all parts except the ceramic bearing as there was some green lubricant on it that i couldnt replace if i cleaned it. Not really expecting it to work better i put it back together and, well it worked and was silent again :)

Murphy doesnt sleep though a day or 2 later the noise was back again :( So i repeat the procedure but sadly it made no difference this time. So being out of all options except 3, from which the first could damage my microwave and the second needs a sledge hammer that i dont have, i drop the thing by mistake, no really i didnt do it intentionally my 3rd option is actually taking the ceramic bearing appart and cleaning it with a bunch of paper towels. Ive taken a picture before doing that, sadly i didnt take more pics, like at the very start when it was really dirty …

The bearing is held together with a little metal ring that i somehow got off with a screw driver, and to my surprise it didnt fly through the room. After cleaning it and putting it back together i added a little bicycle oil. And it works and mosly silent. Anyone wants to bet how long it will last? I somehow think ill have to replace it with the new one soon …