Archive for the ‘Useless Rants’ Category

On Names, Sacred Animals and Germany

Sunday, August 22nd, 2010

This post is inspired by the fact that in these two days I’ve passed by two towns named Eberbach. For people without German knowledge: this name translates as “Wild Boar’s Spring”. For people with French knowledge — feel free to laugh that the second town is actually called Eberbach(Fils).

It may be insignificant name for you but not for me. There is no official animal for Ukraine, but if you ask people, most chances it will be pig (like bear for Russia). Thus, one may ask “do they name any towns or villages after it in Ukraine?”. Guess what? I’m aware of only one village named “??????”, which can be translated as “Little Boar (village)” or this (hopefully). In the same time (if German Wikipedia doesn’t lie) there’s maybe half a dozen of Eber… towns in Germany (mostly in Baden-Wuerttemberg and Bavaria) and one Schweinfurt (i.e. “Swine Ford”, also in Bavaria).

Pig is the only animal that Tatars and Turks didn’t take during their raid on Ukrainian territory, that’s why Ukrainian population should have very reverent position to pigs (and if you ask, say, Russians you’ll hear that Ukrainians are obsessed with “salo” which is obtained from pigs). Despite that there’re no towns named after it and only two or three monuments to pigs in whole Ukraine (IIRC all of them were installed in last ten years or so). It’s definitely a shame and may partially explain why Ukraine is in such deep you-know-what.

Short Tourist Guide to Germany

Tuesday, August 17th, 2010

Since I stuck in Germany for a while, I like to explore nearest places (though I’d better go see Malmö, Sundsvall, Uppsala and, of course, Stockholm). Here are my impressions after visiting a dozen of different towns.

Due to my location I mostly visited places situated near Rhine, so my sampling may be biased.

My first observation is that smaller towns are usually better (look more beautiful, nicer and more comfortable) than larger ones. For example, in Baden-Württemberg I’ve seen: Baden-Baden, Bruchsal, Donaueschingen, Eberbach, Freiburg, Heidelberg, Karlsruhe, Mannheim, Offenburg, Pforzheim, Stuttgart. Among those I liked Mannheim and Stuttgart the least. Guess what are two biggest cities in this region? Stuttgart also serves for a capital. It’s famous for one guy who invented bicycle and one of the first to invent typewriter (what do you know, Germans still love bikes) and several other guys inventing car (there are still Daimler-Benz and Porsche works in Stuttgart along with their own museums).

Köln (aka Cologne) is the fourth biggest city in Germany. While it has very impressive architecture and interesting museums, it’s queer. Seeing slogan “From Cologne to Cleveland. Gay games 2014” does not improve my impressions. Seriously, Cleveland? It’s rumoured to be one of the worst cities in USA. I’m pretty sure that, for example, Bonn is better despite being former governmental place. Also I’ve heard that they have special dialect, even less understandable than Schwabish (not a problem for me, I can’t understand any German dialect anyway).

Rhineland-Pfalz (aka Rhineland-Palatinate) has no big cities, its capital Mainz has around two hundred thousand people but those towns are beautiful! Well, except Ludwigshafen unless you like concrete panel buildings and chemical industry. Also it’s worth reminding that Mainz was a cradle of one of the most important inventions ever – printing.

I’ve been in Hamburg for about an hour but this (the second largest German city) is also not impressive.

Well, guess what German city sucks most in my opinion (and not only because it’s built on a swamp)? Of course, it’s Berlin. The only good place I’ve seen there is musical instruments museum. The rest looks a lot like Kiev – skyscrapers in the city centre and mostly neglected buildings in other areas. Not to mention that even S- and U-Bahn stations look too spartan and underdesigned. Makes you think that West Berlin was a myth.

The only major exception is Bavaria (even some Germans consider it to be a separate country and not a real part of Germany). They make good cars, they have wonderful tourist attractions, they have very good music (though Wagner was born in Leipzig), they have wonderful nature too. They even had special Monty Python Flying CircusFliegender Zirkus series filmed there, it’s hard to beat that.

I still have to visit Central and East Germany but I don’t think it will change my opinion. And maybe I’ll have a chance to compare Strasbourg to Paris. I suspect result will be quite similar.

VC-1 interlaced: sine-wave expectations

Sunday, August 8th, 2010

Indeed, my expectations on completing at least field-interlaced VC-1 support can be represented as (possibly modulated) sine wave.

So here’s a short log of my mood during my attempts on implementing it:

  • initial state — no feelings at all
  • discovered old unfinished patch — mood goes up
  • tried to make it decode more than one field — fail, mood goes down
  • found out that first frame is actually composed of I and P field — mood goes up
  • looked at decoded picture — mood goes down
  • “that P-frame structure differs a bit but that’s all” — mood goes up
  • read about actual motion compensation routine for interframes and related bitreading —can you guess the consequences?

Some may argue this may be better represented with triangle or sawtooth wave though.

Seriously, now I understand why some people consider interlaced video to be evil. First of all, it’s an artefact of bandlimited era. Thus it adds unnecessary complexity to modern progressive systems.

I’m pretty sure there are people who will cry when they hear about interlaced coding and coded field order. There may be people who wince at word “telecine”. There may be H.264 interlaced modes (yes, several of them, MBAFF seems to be most popular) decoder implementers. Probably I’ll join one of those groups too.

Seriously, I consider adding interlaced mode (at least to some codecs) an offence against humanity.

I don’t see why interlaced decoding must differ from progressive one that much. Okay, we have two fields and we may need to select better reference for one of them. No problem. Select two references for motion vector prediction (which is described as several pages of blah-blah-code, yes, that comprehensible)? Gentlemen, include me out!

To make things worse they decided to complicate motion vector encoding along with prediction. Honestly, one should suspect that field MVs should be smaller due to fields having half of original picture height; in reality there is an additional group of bits read to augment motion vector. Why?

And a bit of icing. FFmpeg seems not to be adapted well for interlaced decoding. For instance, who knew that you should use picture->linesize[0] instead of mpegenccontext->linesize because the former will be used in calculating offsets for current block data and if you set mpegenccontext->picture_structure to say PIC_TOP_FIELD it will modify something for you? Not to mention how to deal with motion block data needed for reference (I honestly have no idea how well it will work).

Thus, I invite somebody able and fearless to finish this task. I don’t have any samples to interest me (for the reference, in the best times my DVD collection was around two or three discs, guess the number of Blu-Rays I own) and I found better ways to spend my time (and probably more interesting codecs as well).

P.S. Moving VDPAU chunks to dedicated AVHWAccel is also needed and is trivial even for somebody without deep FFmpeg knowledge.

Standards: Video versus Audio

Wednesday, July 21st, 2010

Since I work on multimedia stuff, I had some chances to look at different specifications for audio codecs as well as video ones. And comparing those specifications led me to rather surprising conclusion:

Video codec specifications are better than audio ones

I admit that I might miss some details or interpret something wrong yet here’re my impressions.

Video codec specifications tend to be complete and while they are not always easy to comprehend you can write codecs after them (well, maybe in VP8 case you need to add some glue code to reference decoder disguised as specification). And those specs usually cover everything, including extensions and rather freely obtainable (usually drafts are good enough for all practical purposes). I know mostly ITU H.26x, MPEG video and SMPTE VC-1 codecs but that seems to apply to all of them.

Audio codec specifications often lack those features. Looks like they offer you more or less complete version of core decoder and good luck finding description of extensions. And even then they manage to lie or omit some things.

MPEG Audio Layers I-III — no objections (except for Layer 3 bitstream design, of course).

AAC — nothing wrong with core bitstream parsing. Heck, I even managed to write something that produces valid AAC stream (sometimes) that can be decoded into recognisable sound (with a bit of luck). Now look at the extensions — they are very poorly documented. That was the reason why FFmpeg got AAC SBR and AAC PS support that late.

ATSC A/52 (some call it AC3) — again, nothing wrong with core decoder. FFmpeg even got encoder for it long before native decoder (you can blame liba52 for that too). But E-AC-3 is a different beast. It’s mostly okay unless you try implementing enhanced coupling or dependent streams. The former has some bugs so implementing it right by the specification will result in decoder failing to parse bitstream sometimes and the latter is almost fine but in version available in the wild there’s no mention that some of extension channels are actually channel pairs. Good luck figuring it out by yourself.

DCA — it was fun when I discovered that actual CRC calculation is performed with polynomial different from the one given in specification. Luckily nobody bothers about it. Some of the tables are not given in specification — DCA is the codec with the largest amount of tables if you count its extensions (TwinVQ is a close competitor though), so they decided not to give tables with more than 1024 elements in specification. You need reference code for that. And good luck finding specifications for extensions. And I assure you that like in case with E-AC-3 reference decoder sometimes does different things than written in spec. The most wonderful part? Your decoder should be bitexact if you want lossless mode operating properly and looks like the only way to do that is to copy a lot of stuff from reference decoder.

Speech codecs (AMR-NB, AMR-WB, ITU G.72x, RFC xxxx) — some of them nice but I still have that impression that most of them had specifications written by the next formula: “Here’s how it should operate in principle, I don’t remember exact detail anyway but we need to write something here, you have your reference decoder source so bugger off”. I remember looking at
those G.72x specs (some are quite nice though), I remember troubles Robert Swain had with AMR-NB decoder (I tried to help him a bit with it too) and there’s some speech codec (iLBC?) that simply dumped all source code files into RFC body without much explanation.

That’s why I claim that audio codec specifications are generally worse than video codec specs. I think if somebody ran simple test on specs assigning penalty points for things like:

  • containing non-obvious pseudocode constructs like QTMODE.ppq[nQSelect]->inverseQ(InputFrame, TMODE[ch][n])
  • containing five-line pseudocode for what can be expressed in one clear sentence
  • containing source code listings (bonus points for spanning more than one page)
  • omitting details essential for implementation
  • lying about details (i.e. when reference decoder and specification disagree)
  • assigning decoder to do irrelevant tasks (like upsampling, postfiltering and such)

virtually no audio codec would have zero score unlike video codecs.

German Transport

Thursday, July 15th, 2010

Looks like people expect rants about transport from me. OK, here’s what should be the last in that series — regional and urban rail transport.

There are several types of rail transport:

  • Trams (Strassenbahn)
  • Commuter trains (S-Bahn)
  • Underground (U-Bahn)

In theory, trams go in cities on the ground, U-Bahn goes under the ground and S-Bahn goes to suburbs and S-Bahn trains look like this.

But during my travels I’ve seen it’s not completely true.

Munich

This city has a proper system with all three components, nothing peculiar at all.

Heidelberg/Mannheim

Proper trams and S-Bahn, nothing peculiar. But Neckar valley views are impressive.

Stuttgart

Proper S-Bahn but their U-Bahn reminds me of trams for some reason. They have underground trains with maximum of two carriages (or one articulated) with third rail between usual two. I heard they’re better at cars though.

Karlsruhe

This is rather small city so they have only one proper S-Bahn route — to Heidelberg and Mannheim, the rest of S-Bahn routes are served by trams, the same trams serve internal routes. Yet this network is quite extensive, I’d never believe that I can visit famous Russian resort (Baden-Baden) by tram — and that’s in 30 kilometres from Karlsruhe!

Berlin

I visited Berlin to attend live IRC chat (aka LinuxTag) yet I’ve tried to look at local transport system.

U-Bahn is curious, they have two kinds of trains: narrow and not so narrow. Both seem to have the same types of trains in two different sizes though. A pleasant surprise is that it actually works even at night, not all of the lines though.

S-Bahn is actually can be described as “U-Bahn that shares some tracks with railroad”. Honestly, it’s the same third rail system as any underground and if not for the line naming (S1, S2, … versus U1, U2, …) you cannot distinguish them; even the trains are similar. And I have an impression that it does not serve much of the suburbs either.

I heard they also have trams but never seen those.

About my new work

Sunday, May 30th, 2010

While I’m extremely lazy maybe it’s time to write about my new work.

Yes, I’ve finally got a job in civilised country (Germany). I admit, I’ve chosen the offer based mostly on environment and what I got:

  • my work — working on multimedia technologies implementation (codecs for now).
  • my colleagues — nice and friendly people with good knowledge so I don’t feel alone and can talk about technical stuff too.
  • my living place from consumer position — maybe not ideal but with very good infrastructure and mostly I can easily get what I want.
  • geographical position — not far from Rhine and near Schwarzwald, so I can enjoy scenic landscapes as well.

Overall conclusion: I was lucky to pick this job. Though I still miss Sweden but life is not ideal.

Some Observations on Transport Infrastructure

Thursday, March 25th, 2010

Today I’d like to rant about the ways transport is organised in different places I’ve visited so far.

(more…)

Bink samples needed

Wednesday, March 10th, 2010

I’m searching for old Bink samples. There are plenty “BIKi”, “BIKf” and some “BIKh” samples available but next to nothing of older ones. By pure luck we were able to find some “BIKb” but that’s all.

We are still in need for old Bink versions, anything from “BIKa” to “BIKe”. Can you help us?

Here’s that list of stuff using Bink. Looks like that games released since 2000 use “BIKf” and later, so we are hunting earlier games (and it’s because some Mike has not bothered to retrieve all that information from MobyGames).

Probably “Might & Magic VIII: Day of the Destroyer” demo may use it (release uses “BIKf” and “BIKh”), for a start. Maybe some other Heroes of Might and Magic III games have them (“Shadow of Death” addon I have features “BIKb”).

Any help will be appreciated.

Notes:

Bink versions are determined by first four bytes of file, any hex viewer can help you.

Some games (like the ones by New World Computing) may have all video files in single archive named like “videosomething.smt” or “something.vid”, sometimes along with Smacker files. But those archives usually feature file names at the beginning, again that can be easily viewed with any hex viewer. And if file resides in directory named “Video” or “Movie” it’s a good hint too.

Update: looks like there are no such files (except maybe in some archives of RAD developer(s)).

It was not the codec you’re looking for

Friday, February 12th, 2010

There is only one thing that may taint the joy of REing yet another codec. It’s when you realize that most of the samples you want to decode are coded with another codecs.

While recent Indeo 5 decoder addition allows playing many files, I found out that I have more samples encoded with Indeo 4. Even though I have Bink Video decoder it looks like I don’t have much samples for it. But there are many other games with custom codecs worth REing.

Yet it’s not that bad as sounds. M$ Video 1, Cinepak, Smacker and Sierra VMD seem to cover most of the samples I have interest in. Luckily for me there are many codecs left to RE for which I have some interest. Another guy had fulfilled his dream of being able to watch movie trailers in QuickTime format, so there’s almost no new work from him.

P.S. After I’d published that “looking for a job” post, I got many proposals, but for some reason they are mostly for USA and some people asking if I’d consider Australia too (BTW, answer is no, it’s too warm place for me and I plainly can’t work in such conditions). Either I want something unrealistic (i.e. job in Europe) or it’s Murphy Law in action.

All codecs roads lead to FFmpeg

Saturday, February 6th, 2010

This is written mainly as a response to some flamewars.

All codecs may be divided into two categories — mature codecs and developing codecs. In the first case we have frozen bitstream format and not so many enhancements to codebase supporting that codec. In the second case we have codec that may change bitstream format and (what is quite important) encoder features.

FFmpeg itself went that way — from highly experimental H.26x encoder and decoder to rather stable set of almost all decoders available around and several encoders. Since there are some coding rules and conventions and existing framework in it, it makes it very convenient place to implement decoders — you can reuse a lot of code optimised for many platforms (so you don’t have to care about DCT speed, for example) and users don’t have to worry about adding new decoding interface and new lines in configure script, it’s all handled inside libavcodec. And “NIH syndrome” also gives a benefit here — you don’t have to worry about additional libraries (and original codec devs will have their codec specs tested as well).
You know the other advantages of this approach too.

In the same time those features make FFmpeg a bad place for having still evolving encoders for they are not likely to fit into existing framework so easy. The best this tension could be viewed in our interaction with certain encoder. They constantly modify this encoder, so existing FFmpeg options and presets are not good for them and it’s hard to tell how well it will work. Now let’s see what happens if x264 code will be merged into FFmpeg. It will put a rather harsh constraint on x264 developers because it’s hard to tell what change breaks other codecs (changes behaviour, whatever) or vice versa. The same applies to codec-specific features (like muxer using some encoder information, think H.264+MPEG-TS).

On the other hand, it is much easier to incorporate into FFmpeg an encoder not changing so much — some compromises should be made on common interface, some parts replaced with standard FFmpeg routines and voila!

I think that’s the reason we have a lot of decoders and not so many lossy encoders (especially not so many lossy encoders with good quality) in last N years. And it’s the reason why encoder should be originated as standalone projects and merged when they are stable. I’d also like to note that FFmpeg has standing issues with providing better framework for non-H.261 based codecs and descendants (where is codec-independent rate control and motion estimation?), maybe this affected Snow development as well. Anyway, let’s live and see how all these things will be resolved.