Lair Of The Multimedia Guru

Its quite a while since ive updated my blog, and indeed ive a few things i wanted to put up but have always had something more important to do, well. Today, ive finally decided to skip doing important things and put up something really unimportant.
A while ago I was reading the manual of a toothbrush, an electric ehm “sonic” toothbrush. It said something like 40000 revolutions per second. Reading that and looking at the humble, el-cheapo toohbrush i didnt belive it, so i had to find out how fast the thing vibrates (it actually doesnt do full revolutions). Using my soundcard was out of question as that wouldnt work above 24khz. So i used a old analoge osciloscope that i got for 15 euro from a local flea market a while before.

You can see on the scope, the vibration of the toothbrush head as well as a 1khz reference square wave. The trick is that the toothbrush head is made of some kind of plastic and by rubbing it against something, it becomes electrostatically charged. Just holding the scope probe near then shows the movement of the head.
We can see on this that in about 6 cycles of the 1khz signal we have 2 cycles of the toothbrush, which would give ~1000/3 hz.
Which is 120 times off from 40000, if one considers both ends of the vibration instead of a full cycle its 60 times off. And at that point i looked at the manual again and realized it said 40000 U/min not sec :)
Which proofs my way of measuring it is quite spot on, but my way of reading the manual isnt.

In the last few weeks FFmpegs huffyuv codec has grown the ability to encode and decode a much broader list of pixel formats. From planar rgb variants 4:4:4 YUV to 4:1:0 YUV and bit depths up to 16bit and alpha support.
One might ask why anyone cares about all this, the awnser is simple

Encoding parameters used:
-an -threads 1 -pix_fmt yuv420p10le -strict -2 -vcodec ffvhuff -context 1
-an -threads 1 -pix_fmt yuv420p10le -strict -2 -vcodec ffv1

Encoding parameters used:
-threads 6 -an -pix_fmt yuv420p10le -strict -2 -vcodec ffvhuff -pass 2 test.nut
-threads 6 -an -pix_fmt yuv420p10le -strict -2 -vcodec ffv1 -level 3 -slices 6 test1.nut

As can be seen above huffyuv while it doesnt even get close to ffv1 in terms of compression even though i used per frame huffman tables and 2pass mode in the 2 tests, its simply much faster.

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.