Archive for the ‘Useless Rants’ Category

Internetless

Friday, December 6th, 2013

I still don’t have Internet connection at home (for two months and counting) and not sure if I get any this year.

So here’s the list of rants I’d have written, had I had access:

  • SD cards as modern floppies — similarly ubiquitous and slow;
  • Swiss cheeses — some are OK, most are slightly sticky, coated in something very smelly and named “chas”;
  • WMV9 pre-RTM P-frames decoding: how it should be decoded and why our decoder is still wrong sometimes;
  • Bink2 decoder progress report (since I’ve not started working on it yet).

Do not stay tuned.

On Some Smaller Railway Details

Thursday, September 12th, 2013

When I visited VDD13 (they’ve finally made it right — with Trocadero and surströmming, hopefully they’ll keep the level in the future) I could make some additional observations on the rail that finally lead to this post.

First, I like to talk about catenary constructions. They usually come in two variations — a single post with a special support for the wires or two posts with a horizontal construction between them that supports the wires.
It might be hard to believe but they can be æsthetically appealing too.

The top on my list is Sweden (and Netherlands since they seem to employ the same construction). The poles are made from lattice and thus are nice and horizontal supporting constructions are always made as trapezoids.

Runner-up is Switzerland — they also have nice lattice constructions but they seem a bit compressed to me.

Germany has the same poles but for wider ranges they usually have only a wire between poles from which the wire-supporting constructions hang.

Most of the other contries have simple round masts or H-shaped beams that are not interesting, though I must admit French ones have nice wire support constructions reminding of violin bow.

And on the very bottom of the list is Denmark with its large ugly ?-shaped masts in the colour of rust.

And now to the second thing — toilets. I usually try to avoid them but sometimes I feel I have to visit one onboard. So here’s a comparison of that essential thing.

Ukraine — toilets on so-called “InterCity+” should not be that bad, toilets in older carriages are better not be visited at all (and since they dump contents onto tracks directly, toilet rooms are locked long before stations and after them).

Germany — on InterCity trains toilets are decent (or at least tolerable), on ICE they are too small even in the first class. Even on regional trains and trams it seems to be bigger.

France — on TGV first class they are even smaller that on ICE, in the second class even a person smaller than me has problems fitting inside.

Sweden — those people really care. The spaciest toilet rooms on trains I can remember (especially on Reginatåg).

Switzerland — the toilet on Rhätische Bahn regional trains seemed quite good even if those are narrow-gauge trains.

Moral of the story — Swedish trains and railways are the best (and if you have doubts you’re reading the wrong blog).

How I imagine a perfect computer (for me)

Saturday, June 8th, 2013

Of course this interests nobody but I wanted to rant about it for a long time.

General principles:

  1. Compact size — I like to be able to fit all of my computers on the desk, any size comparable with power supply unit size would do. Laptops are fine too.
  2. Silent — no damned fans.
  3. An ability to use normal storage, not 16MB SSB soldered onboard.
  4. No x86 CPU.
  5. If it’s a laptop it should be able to work for 10 hours with battery.

Display:

  1. 4:3 aspect ratio. If displays nowadays are made for movie-watchers then it’s a sad world. Too much of vertical space is eaten by various toolbars, menu bars and such.
  2. sane resolution. Again, 1920×1080 may be ideal for movie-watchers but I prefer it to be either VGA-based (i.e. multiple of 640×480 or 800×600) or power of two based. And whoever thought about 1366×768 should burn in hell!

Performance — if Libav compiles in ten minutes on dual core system then it’s fast enough for me.

ARM-based laptops are almost good for that, especially performance wise. There’s just one big “but” — they are almost all are for Android or chromebooks. And Baidu has never intended those systems for any real usage. Playing games — fine, browsing — passable (though Firefox 3 on my old PowerPC MacMini with 512 MB RAM gives much better experience than Chrome on tablet with 1GB RAM), editing texts (code) — absolute fail. I can live without a numpad on keyboard (it’s a legacy for accountants and their calculators after all) but not having even “delete” key (there’s only backspace) is pathetic.

So I live with a faint hope that there will be a computer good enough for me.

In ten years every codec becomes Op^H^HJPEG

Saturday, May 11th, 2013

So, RAD has announced Bink 2. While there are no known samples or encoder, decoder is present in RAD game tools already. For some random reason (what I have to do with Bink anyway?) I decided to look at it.

Format is probably the same except that preferred extension is .bk2 and it starts with 'KB2f' instead of 'BIKf' or 'BIKi'.

The main features they advertise are speed and dual-core decoding support. Most parts of the code are SIMDified indeed and as for dual-core decoding support it seems to be fulfilled with breaking frame into top and bottom half (not that I’ve looked at it closely but strings in the player suggest that).

Now about the format itself. Bink2 operates in YUV 4:2:0 format with optional alpha and employs 8×8 DCT with 16×16 macroblocks. There are not many interesting details in the coding itself: DCs are coded separately before ACs, three quantisation matrices — two for luma/alpha (for intra and inter blocks) and one for chroma, static codes are used for coding them (compare that to the way it was done in Bink Classic), motion compensation is halfpel for luma and quarterpel for chroma now with bicubic interpolation. There are four modes for coding block: intra block, skip block, motion-only block and motion compensation with residue coded.

There seems to be some postprocessing they rightfully call “Blur” but I’m not that sure about it.

What can I say about the codec overall? It’s boring. While Bink 1 is not that fast it was much more fun to RE: coding values in bundles ­— I’ve rarely seen that (Duck TrueMotion 2 comes to mind and that’s all), various coding techniques — vector quantisation and DCT (as I’ve mentioned above, coding DCT coefficients was rather unique too) and some other tricks (unusual scans, specially coded block difference, double-scaling blocks, etc. etc.).

Overall, Bink2 will probably be what it’s promised to be (fast, portable codec for games) but it won’t have the real spirit of Smacker and Bink design. Or maybe it’s just me getting older.

P.S. I wonder if they start providing logo in Bink2 file embedded in player like they do with Smacker and Bink players.

P.P.S. This post title is inspired by a certain German saying about cars in case it wasn’t obvious.

OMG

Saturday, March 23rd, 2013

IMG_1466

I think this should be in every first aid kit.

A new record

Monday, March 4th, 2013

I thought that there’s no codec more horrible than Go2Despair and was proved wrong again. Here’s the even worse pair: Dxtory codec and its standalone companion PackBit.

DxtoryCodec.dll is 8.2MB which rivals Go2C++Hell because it’s standalone decoder without any additional code. PackBitCodec.dll is even more elegant. Of the total size of 672256 bytes more than 357000 bytes are occupied by the code of one function (that’s 3-6 times more than the ordinary zlib-based codec complete DLL file). Truly some people should not be allowed to program.

On Sweden and small details

Monday, February 4th, 2013

Probably Sweden was never a really influental in science besides chemistry but it has contributed a lot of small things that really made our world better: high-precision measuring tools, or official human rights representative, or Trocadero, even flatpacked furniture.

Here’s an example: in the swedishest corner of Sweden there was a guy who really changed our world with two simple things. One of them is centrifugal milk separator. Another one is the nozzle. Yes, a simple nozzle that is used in rocket and jet engines. Were those inventions that great and important? Maybe not. Were they useful and have they changed the world a bit to the better? Definitely yes.

And that’s how the place where he came from looks nowadays:

IMG_1107

IMG_1109

IMG_1119

(in case it was not obvious — I’ve been to Orsa and I’m proud about that).

A few words about G2M4 (that were not censored)

Sunday, November 4th, 2012

Okay, I looked into G2M4 closer, here’s the output:

As with the previous beast, there are two types of images combined in single tile — so-called synthetic layer and natural layer. What you see if the first layer decoded.

Here’s the general tile structure:

  • Compression subtype (top bits from the first byte).
  • Transparency colour (three bytes)
  • Number of palette entries minus one (one byte)
  • Palette entries (byte triplets)
  • Synthetic layer (16-bit BE chunk size plus deflated data, may be not present)
  • Natural layer (probably headerless JPEG data, too lazy to verify)

Synthetic layer image is (after decompression) contains packed bitmap that uses palette from above, each row is coded as 8-bit flag [packed row data]. If the flag is zero then row data is present (that’s my guess, it always seems to be zero). Row data is just palette indices stored as 1/2/4 or 8 bits per index depending on palette size. Sample output you can see above.

Feel free to complete RE.

FnAQ about G2M2/G2M3

Saturday, November 3rd, 2012

Just to clarify status: I’m not working on this anymore so anyone can pick it up and finish.

And here are some possible questions that might be asked but more probably won’t.

Q: who cares about this codec anyway?

A: Not me. VLC does.

Q: so why don’t you do it?

A: there are several reasons. First, now I have idea how it works and it’s not that interesting anymore. Second, it would require some debugging and I cannot run that decoder under MPlayer2 (and I don’t use Windows at all).

Q: but wait, there’s G2M4!

A: right, and it uses completely different coding. I might look at it but no promises either.

Q: so, how does it work?

A: the idea is simple. Every frame is divided into tiles and some tiles can be updated from the previous frame or not; some additional information (i.e. mouse cursor shape and position) is also stored in the frame.
G2M2/G2M3 use the technology licensed from Accusoft that combines JPEG and ELS-coded image.

Q: how do they do it?

A: the approach (I call it JPEG-Binary Koder or J-BK for short) is quite simple. Every tile has ELS-coded picture with possible transparency. Transparent areas should be replaced with headerless JPEG data (i.e. only scan data without any markers but with escapes).

Q: sounds easy, where’s the catch?

A: I’m too lazy to catch bugs in my quick JPEG decoder reimplementation and ELS-coded image requires some debugging which I can’t do.

Q: okay, I want to do it, where shall I start?

A: is it the first of April? No? Hmm… Okay, here’s what I would do: grab a copy of g2m.dll (there are enough of them around, in various sizes too), disassemble it.
Find the ELS thresholds table (referenced values are 0x10000, 0x12A00, 0x15C00, 0x19600, 0x1DA00, 0x22800, 0x28500, ...) — the function referencing it is the one used to update ELS coder state, go up from there. Feel free to look at the wiki entry about G2M. Bonne chance!

Teasing

Saturday, October 6th, 2012

In the recent month I was not very productive, so I’d like to talk about codecs that I’m not likely to finish soon (not that I’m going to finish any codec soon anyway).

GoToMeeting 2/3

G2M2 decoder output (the best I could get)

Here’s the best output I could get from G2M2 or G2M3 data by decoding JPEG part of the tiles. ELS part still needs some work since it’s boring — 10-neighbour prediction, differential pixel decoding and other wonders of binary coder.

Certain Intermediate Codec

I managed to reverse engineer some parts of it. First you have so-called fixed header, then you have strip sizes and then strip data with some header as well. The way it’s coded is also more or less clear. But some connecting details — like how those strips are divided (now it looks like 96×1 macroblocks or equally ridiculous).

Since it’s QuickTime it’s hard to say where are the entry points to the codec and what functions are invoked.
Also the only usable binary (with debug symbols) is PowerPC only. It’s nice platform but I still need to learn some of its peculiarities.

VoxWare MetaSound

It turns out that it is slightly simplified variant of TwinVQ. It does not have variable-length codes, all values are read as fixed bits (depending on sampling rate and bitrate of course). The only catch is that it’s hard to find where such description is retrieved or generated. And existing codebooks are somewhat different.