Mar 152016
 

H.265/HEVC logoJust recently, I’ve tested the computational cost of decoding 10-bit H.265/HEVC on older PCs as well as Android devices – with some external help. See [here]. The result was, that a reasonable Core 2 Quad can do 1080p @ 23.976fps @ 3MBit/s in software without issues, while a Core 2 Duo at 1.6GHz will fail. Also, it has been shown that Android devices – even when using seriously fast quad- and octa-core CPUs can’t do it fluently without a hardware decoder capable of accelerating 10-bit H.265. To my knowledge there is a hack for Tegra K1- and X1-based devices used by MX Player, utilizing the CUDA cores to do the decoding, but all others are being left behind for at least a few more months until Snapdragon 820 comes out.

Today, I’m going to show the results of my tests on Intel Skylake hardware to see whether Intels’ claims are true, for Intel has said that some of their most modern integrated GPUs can indeed accelerate 10-bit video, at least when it comes to the expensive H.265/HEVC. They didn’t claim this for all of their hardware however, so I’d like to look at some lower-end integrated GPUs today, the Intel HD Graphics 520 and the Intel HD Graphics 515. Here are the test systems, both running the latest Windows 10 Pro x64:

  • HP Elitebook 820 G3 (tiny)
  • HP Elitebook 820 G3
  • CPU: Intel [Core i5-6200U]
  • GPU: Intel HD Graphics 520
  • RAM: 8GB DDR4/2133 9-9-9-28-1T
  • Cooling: Active
  • HP Elite X2 1012 G1 (tiny)
  • HP Elite X2 1012 G1 Convertible
  • CPU: Intel [Core m5-6Y54]
  • GPU: Intel HD Graphics 515
  • RAM: 8GB LPDDR3/1866 14-17-17-40-1T
  • Cooling: Passive

Let’s look at the more powerful machine first, which would clearly be the actively cooled Elitebook 820 G3. First, let’s inspect the basic H.265/HEVC capabilities of the GPU with [DXVAChecker]:

DXVAChecker on an Intel HD Graphics 520

DXVAChecker looks good with the latest Intel drivers provided by HP (version 4331): 10-Bit H.264/HEVC is being supported all the way up to 8K!

And this is the ultra-low-voltage CPU housing the graphics core:

Intel Core i5-6200U

Intel Core i5-6200U

So let’s launch the Windows media player of my choice, [MPC-HC], and look at the video decoder options we have:

In any case, both HEVC and UHD decoding have to be enabled manually. On top of that, it seems that either Intels’ proprietary QuickSync can’t handle H.265/HEVC yet, or MPC-HC simply can’t make use of it. The standard Microsoft DXVA2 API however supports it just fine.

Once again, I’m testing with the Anime “Garden of Words” in 1920×1080 at ~23.976fps, but this time with a smaller slice at a higher bitrate of 5Mbit. The encoding options were as follows for pass 1 and pass 2:

--y4m -D 10 --fps 24000/1001 -p veryslow --open-gop --bframes 16 --b-pyramid --bitrate 5000 --rect
--amp --aq-mode 3 --no-sao --qcomp 0.75 --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0
--rdoq-level 1 --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 --pass 1
--slow-firstpass --stats v.stats --sar 1 --range full

--y4m -D 10 --fps 24000/1001 -p veryslow --open-gop --bframes 16 --b-pyramid --bitrate 5000 --rect
--amp --aq-mode 3 --no-sao --qcomp 0.75 --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0
--rdoq-level 1 --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 --pass 2
--stats v.stats --sar 1 --range full

Let’s look at the performance during some intense scenes with lots of rain at the beginning and some less taxing indoor scenes later:

There is clearly some difference, but it doesn’t appear to be overly dramatic. Let’s do a combined graph, putting the CPU loads for GPU-assisted decoding over the regular one as an overlay:

CPU load with software decoding in blue and DXVA2 GPU-accelerated hardware decoding in red

Blue = software decoding, magenta (cause I messed up with the red color) = GPU-assisted hardware decoding

Well, using DXVA2 does improve the situation here, even if it’s not by too much. It’s just that I would’ve expected a bit more here, but I guess that we’d still need to rely on proprietary APIs like nVidia CUVID or Intel QuickSync to get some really drastic results.

Let’s take a look at the Elite X2 1012 G1 convertible/tablet with its slightly lower CPU and GPU clock rates next:

Its processor:

Core m5-6Y54

Core m5-6Y54

And this is, what DXVAChecker has to say about its integrated GPU:

DXVAChecker on an Intel HD Graphics 515

Whoops… Something important seems to be missing here…

Now what do we have here?! Both HD Graphics 520 and 515 should be [architecturally identical]. Both are GT2 cores with 192 shader cores distributed over 24 clusters, 24 texture mapping units as well as 3 rasterizers. Both support the same QuickSync generation. The only marginal difference seems to be the maximum boost clock of 1.05GHz vs. 1GHz, and yet HD Graphics 515 shows no sign of supporting the Main10 profile for H.264/HEVC (“HEVC_VLD_Main10”), so no GPU-assisted 10-bit decoding! Why? Who knows. At the very least they could just scratch 8K support, and implement it for SD, HD, FHD and UHD 4K resolutions. But nope… Only 8-bit is supported here.

I even tried the latest beta driver version 4380 to see whether anything has changed in the meantime, but no; It behaves in the same way.

Let’s look at what that means for CPU load on the slower platform:

CPU load with software decoding

The small Core m5-6Y54 has to do all the work!

We can see that we get close to hitting the ceiling with the CPUs’ boost clock going up all the way. This is problematic for thermally constrained systems like this one. During a >4 hour [x264 benchmark run], the Elite X2 1012 G1 has shown that its 4.5W CPU can’t hold boost clocks this high for a long time, given the passive cooling solution. Instead, it sat somehwere in between 1.7-2.0GHz, mostly in the 1.8-1.9GHz area. This might still be enough with bigger decoding buffers, but DXVA2 would help a bit here in making this slightly less taxing on the CPU, especially considering higher bitrates or even 4K content. Also, when upping the ambient temperature, the runtime could be pushed back by almost an hour, pushing the CPU clock rate further down by 100-200MHz. So it might just not play that movie on the beach in summer at 36°C. ;)

So, what can we learn from that? If you’re going for an Intel/PC-based tablet, convertible or Ultrabook, you need to pick your Intel CPU+graphics solution wisely, and optimally not without testing it for yourself first! Who knows what other GPUs might be missing certain GPU video decoding features like HD Graphics 515 does. Given that there is no actual compatibility matrix for this as of yet (I have asked Intel to publish one, but they said they can’t promise anything), you need to be extra careful!

For stuff like my 10-bit H.265/HEVC videos at reasonably “low” bitrates, it’s likely ok even with the smallest Core m3-6Y30 + HD Graphics 515 that you can find in devices like Microsofts’ own Surface Pro 4. But considering modern tablets’ WiDi (Wireless Display) tech with UHD/4K resolutions, you might want to be careful when choosing that Windows (or Linux) playback device for your big screens!

Feb 252016
 

SlySoft logoIt’s over – after 13 years of being almost constantly under pressure by US-based companies, SlySoft finally had to close its doors. Most notably known for software such as CloneCD or AnyDVD, the Antiguan-based company has provided people all over the world with ways to quickly and easily circumvent disc-based copy protection mechanisms such as Sony ArcCos, CSS, ACSS or BD+ and many others for years.

The companys’ founder, a certain Mr. Giancarla Bettini had already been sued – and successfully so – before an Antiguan court. While it was strictly up to Antiguan Authorities to actually sue SlySoft (because the AACS-LA could not do so themselves due to some legal constraints), this did finally happen in 2012, fining Mr. Bettini for a sum of USD $30.000. That didn’t result in SlySoft closing down however.

What it was that happened exactly a few days ago is unclear, as SlySoft seems to be under NDA or maybe legal pressure as to not release any statement regarding the reasons for the shutdown, quote, “We were not allowed to respond to any request nor to post any statement”. The only thing that we have besides a forum thread with next to zero information is the statement on the official website, which is rather concise as well:

“Due to recent regulatory requirements we have had to cease all activities relating to SlySoft Inc.
We wish to thank our loyal customers/clients for their patronage over the years.”

It should be relatively clear however, that this has to have something to do with the AACS-LA and several movie studios as well as software and hardware companies “reminding” the United States government of SlySofts illicit activities just recently. This would’ve resulted in Antigua being put onto the US priority [watchlist] of countries violating US/international copyright laws. Ultimately, being put onto that list can result in trade barriers being put up within a short time, hurting a countrys’ economy, thus escalating the whole SlySoft thing to an international incident. More information [here].

AnyDVD HD

This little program and its little brothers made it all the way to the top and became an international incident! Quite the career…

It seems – and here is where my pure speculations start – that there was some kind of agreement found between SlySofts’ founder and the AACS-LA and/or the Antiguan and US governments resulting in the immediate shutdown of SlySoft without further consequences for either its founder or other members of the company. If true then SlySoft will surely also have to break their promise of releasing a “final” version of AnyDVD HD including all the decryption keys from the online database in case they have to close their doors forever. This is, what “[…] we have had to cease all activities relating to SlySoft Inc. […]” means after all.

So what are the consequences, technically?

I can only say for AnyDVD HD as according to the forums over at SlySoft, but the latest version 7.6.9.0 supposedly includes some 130.000 AACS keys and should still be able to decrypt a lot of Blu-Rays, even if not all of them.

In the end however, the situation can only deteriorate as time passes and new versions of AACS keys and BD+ certificates are being released, even if you bypass the removed DNS A-Records of key.slysoft.com and access one of the key servers by resolving the IP address locally (via your hosts file). Thing is, nobody can tell when SlySoft will be forced to implement more effective methods of making their services inaccessible, like by just switching off the machines themselves.

But even if they stay online for years to come, no new keys or certificates are going to be added, so it’s probably safe to say that the red fox is truly dead.

AddendumJust to be clear for those of you who are scared of even accessing any SlySoft machines with their real IPs any longer; According to a SlySoft employee (you can read it in their forums), all of the servers are still 100% under SlySofts physical control, and their storage backends are encrypted. They were not raided or anything. So it seems you do not have to fear “somebody else listening” on SlySofts key servers.

PS.: A sad day if you ask me, a victorious one if you ask the movie industry. Maybe somebody should just walk over and tell them, that cheaper, DRM-free media actually work a lot better on the market, when compared to jailing users into some “trusted” (by them) black boxes with forced software updates and closed software. Yeah, I actually want to play my BD movies on the PC (legally!!), and on systems based on free software like Linux and BSD UNIX as well, not on some blackboxed HW player, so go suck it down, Hollywood. I mean, I’m even BUYING your shit, for Christs’ sake…

Oh, by the way, China is actually sitting on that copyright watchlist (I mean, obviously), and they gave us DVDFab. Also, there are MakeMKV and [others as well]. We’ll see whether the AACS-LA can hunt them all down… And even if they can… Will it really make them more money? Debatable at best…

Red Fox logoUpdate: Those guys work fast! While SlySoft is gone, several of the developers have grabbed the software and moved the servers to Belize, the discussion forums have already been migrated and a new version 7.6.9.1 of AnyDVD HD has been released, including new keys and reconfigured to access the new key servers as well. The company is now called “Red Fox” and the forums can be accessed via [forum.redfox.bz].

By now, AnyDVD HD respects the old licenses as well, and this will stay this way for the transition period. Ultimately however, according to posts on the forums, people will have to buy new licenses, even if they had a lifetime license before. They also said they’ll cook up “something nice” for people who bought licenses just recently. Probably some kind of discount I presume.

Still, if I may quote one of the developers: “SlySoft is dead, long live RedFox!”

Feb 202016
 

H.265/HEVC logoRecently, after [successfully compiling] the next generation x265 H.265/HEVC video encoder on Windows, Linux and FreeBSD, I decided to ask for guidance when it comes to compressing Anime (live action will follow at a later time) in the Doom9 forums, [see here]. Thing is, I didn’t understand all of the knobs x265 has to offer, and some of the convenient presets of x264 didn’t exist here (like --tune film and --tune animation). So for a newbie it can be quite hard to make x265 perform well without sacrificing far too much CPU power, as x265 is significantly more taxing on the processor than x264.

Thanks to [Asmodian] and [MeteorRain]/[LittlePox] I got rid of x265s’ blurring issues, and I took their settings and turned them up to achieve more quality while staying within sane encoding times. My goal was to be able to encode 1080p ~24fps videos on an Intel Xeon X5690 hexcore @ 3.6GHz all-core boost clock at >=1fps for a target bitrate of 2.5Mbit.

In this post, I’d like to compare 7 scenes from the highly opulent Anime [The Garden of Words] (言の葉の庭) by [Makoto Shinkai] (新海 誠) at three different average bitrates, 1Mbit, 2.5Mbit (my current x264 default) and 5Mbit. The Blu-Ray source material is H.264/AVC at roughly 28Mbit on average. Also, both encoders are running in 10-bit color depth mode instead of the common 8-bit, meaning that the internal arithmetic precision is boosted from 8- to 16-bit integers as well. While somewhat “non-standard” for H.264/AVC, this is officially supported by H.265/HEVC for Blu-Ray 4K. The mode of operation is 2-pass to aim for comparable file sizes and bitrates. The encoding speed penalty for switching from x264 to x265 at the given settings is around a factor of 8. Somewhat.

The screenshots below are losslessly compressed 1920×1080 images. Since this is all about compression, I chose to serve the large versions of the images in WebP format to all browsers which support it (Opera 11+, Chromium-based Browsers like Chrome, Iron, Vivaldi, the Android Browser or Pale Moon as the only Gecko browser). This is done, because at maximum level, WebP does lossless compression much more efficiently, so the pictures are smaller. This helps, because my server only has 8Mbit/s upstream. If your browser doesn’t support WebP (like Firefox, IE, Edge, Safari), it’ll be fed lossless PNG instead. All of this happens automatically, you don’t need to do anything!

Now, let’s start with the specs.

Specifications:

Here are the source material encoding settings according to the video stream header:

cabac=1 / ref=4 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=0.40:0.00 /
mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 /
fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=1 / sliced_threads=0 / slices=4 /
nr=0 / decimate=1 / interlaced=0 / bluray_compat=1 / constrained_intra=0 / bframes=3 / b_pyramid=1 /
b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=1 / weightp=1 / keyint=24 / keyint_min=1 /
scenecut=40 / intra_refresh=0 / rc_lookahead=24 / rc=2pass / mbtree=1 / bitrate=28229 /
ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 /
vbv_maxrate=31600 / vbv_bufsize=30000 / nal_hrd=vbr / filler=0 / ip_ratio=1.40 / aq=1:0.60

x264 10-bit encoding settings (pass 1 & pass 2), 2.5Mbit example:

--fps 24000/1001 --preset veryslow --tune animation --open-gop --b-adapt 2 --b-pyramid normal -f -2:0
--bitrate 2500 --aq-mode 1 -p 1 --slow-firstpass --stats v.stats -t 2 --no-fast-pskip --cqm flat
--non-deterministic

--fps 24000/1001 --preset veryslow --tune animation --open-gop --b-adapt 2 --b-pyramid normal -f -2:0
--bitrate 2500 --aq-mode 1 -p 2 --stats v.stats -t 2 --no-fast-pskip --cqm flat --non-deterministic

x265 10-bit encoding settings (pass 1 & pass 2), 2.5Mbit example:

--y4m -D 10 --fps 24000/1001 -p veryslow --open-gop --bframes 16 --b-pyramid --bitrate 2500 --rect
--amp --aq-mode 3 --no-sao --qcomp 0.75 --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0
--rdoq-level 1 --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 --pass 1
--slow-firstpass --stats v.stats --sar 1 --range full

--y4m -D 10 --fps 24000/1001 -p veryslow --open-gop --bframes 16 --b-pyramid --bitrate 2500 --rect
--amp --aq-mode 3 --no-sao --qcomp 0.75 --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0
--rdoq-level 1 --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 --pass 2
--stats v.stats --sar 1 --range full

Since x265 can only read raw YUV and Y4M, the source video is being fed to it via [libavs’] avconv tool, piping it into x265. The avconv commandline for that looks as follows:

$ avconv -r 24000/1001 -i input.h264 -f yuv4mpegpipe -pix_fmt yuv420p -r 24000/1001 - 2>/dev/null

If you want to do something similar, but you don’t like avconv, you can use [ffmpeg] as a replacement, the options are completely the same. Note that you should always specify the correct frame rates (-r) for input and output, or the bitrate setting of the encoder will be applied wrongly!

x264 on the other hand was linked against libav directly, using its decoding capabilities without any workarounds.

Let’s compare:

“The Garden of Words” has a lot of rain. This is a central story element of the 46 minute movie, and it’s hard on any encoder, because a lot of stuff is moving on screen all the time. Let’s take a look at such a scene for our first side-by-side comparison. Each comparison is done in two rows: H.264/AVC first (including the source material), and below that H.265/HEVC, also including the source.

Let’s go:

Scene 1, H.264/AVC encoded by x264 0.148.x:

Scene 1, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

It has been said that x265 performs specifically well at two things: Very high resolutions (which we don’t have here) and low bitrates. And yep, it shows. When comparing the 1Mbit shots, it becomes clear pretty quickly that x265 manages to preserve more detail for the parts with lots of motion. x264 on the other hand starts to wash out the scene pretty severely, smearing out some raindrops, spray water and parts of the foliage. Also, it’s pretty bad around the outlines as well, but that’s true for both encoders. You can spot that easily with all the aliasing artifacts on the raindrops.

Moving up a notch, it becomes very hard to distinguish between the two. When zooming in you can still spot a few minor differences (note the kids umbrella, even if it’s not marked), but it’s quite negligible. Here I’m already starting to think x265 might not be worth it in all cases. There are still differences between the two 2.5Mbit shots and the original however, see the red areas of the umbrella and the most low-contrast, dark parts of the foliage.

At 5Mbit, I really can’t see any difference anymore. Maybe the colors are a little off or something, but when seen in motion, distinguishing between the two and the original becomes virtually impossible. Given that we just threw a really difficult scene at x264 and x265, this should be a trend to continue throughout the whole test.

Now, even more rain:

Scene 2, H.264/AVC encoded by x264 0.148.x:

Scene 2, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

Now this is extreme at 1Mbit! Looking at H.264, the spray water on top of the cable can’t even be told apart from the cloud in the background anymore. Detail loss all over the scene is catastrophic in comparison to the original. Tons of raindrops are simply gone entirely, and the texture details on the tower and the angled brick wall of the house to the left? Almost completely washed out and smeared.

Now, let’s look at H.265 @ 1Mbit. The spray water is also pretty bad, but it’s amazing how much more detail was preserved overall. Sure, there are still parts of the raindrops missing, but it’s much, much closer to the original. We can now see details on the walls as well, even the steep angle one on the left. The only serious issue is the red light bleeding at the tower. There is very little red there in the original, so I’m not sure what happened there. x264 does this as well, but x265 is a bit worse.

At the next level, the differences are less pronounced again, but there is still a significant enough improvement when going from x264 to x265 at 2.5Mbit: The spray water on the cable becomes more well-defined, and more rain is being preserved. Also, the textures on the walls are a tiny little bit more detailed and crisp. Once again though, x265 is bleeding too much red light at the tower.

Since it’s noticeably not fully on the level of the source still, let’s look at 5Mbit briefly. x265 is able to preserve a tiny little bit more rain detail here, coming extremely close to the original. In motion, you can’t really see the difference however.

Now, let’s get steamy:

Scene 3, H.264/AVC encoded by x264 0.148.x:

Scene 3, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

1Mbit first again: Let me just say: It’s ugly. x264 pretty much messes up the steam coming from the iron. We get lots of block artifacts now. Some of the low-contrast patterns on the ironing board are being smeared out at a pretty terrible level. Also, the bokeh background partly shows block artifacts and banding. x265 produces quite a lot of banding here itself, but no blocks. Also, outlines and sharp contrasts are more well-defined, and the low contrast part is done noticeably better.

At 2.5Mbit, the patterns repeat themselves now. The steam is only slightly better with x265, outlines are slightly more well-defined, and the low-contrast patterns are slightly more visible. For some of the blurred parts, x265 seems to be a tiny little bit to prone to banding though, in a very few spots, x264 might be just that 1% better. Overall however, x265 wins this, and even if it’s just for the better outlines.

At 5Mbit, you really need to zoom in and analyze very small details, e.g. around the outer border of the steam. Yes, x265 does better again. But you’d not really be able to notice this when watching.

How about we go cry a little bit:

Scene 4, H.264/AVC encoded by x264 0.148.x:

Scene 4, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

Cutting onions would be a classic fun part in a slice-of-life anime. Here, it’s just kitchen work. And quite the bad looking one for H.264 at 1Mbit. The letters on the knife are partly lost completely, becoming unreadable. The onion parts that fly off are visibly worse than when encoded with x265 at the same bitrate. Also, x264 produced block artifacts in the blurred bokeh areas again, that simply aren’t there with x265.

On the next level, the two come much closer to each other. However, x265 simply does the outlines better. Less artifacts and sharper, just like with the writing on the knifes’ blade as well. The issues with the bokeh are nearly gone. What’s left is a negligible amount of blocking for x264 and banding for x265. Not really noticeable however.

Finally, at 5Mbit, x265 shows those ever so slightly more well-done outlines. But that’s about it, the rest looks nice for both, and pretty much identical to the source.

Now, please, dig in:

Scene 5, H.264/AVC encoded by x264 0.148.x:

Scene 5, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

Let’s keep this short: x264 does blocking, and bad transitions/outlines. x265 does it better. Plain and simple.

At 2.5Mbit, x265 nearly reaches quality transparency when compared to the original, something x264 falls short of, just a bit. While x265 does the outlines and the steam part quite like in the original frame, x264 rips the outlines apart a bit too much, and slight block artifacts can again be seen for the steam part.

At 5Mbit, x264 still shows some blocking artifacts in a part that most lossy image/video compression algorithms traditionally suck at: The reds. While not true for all human beings, most eyes perceive much finer gradients for greens, then blues, and do worst with reds. Meaning, our eyes have an unequal sensitivity distribution when it comes to colors. So image and video codecs try to save bitrate in the reds first, because supposedly it’d be less noticeable. To me subjectively, x265 achieves transparency here, meaning it looks just like the original. x264 doesn’t manage entirely. Close, but not not entirely.

Next:

Scene 6, H.264/AVC encoded by x264 0.148.x:

Scene 6, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

This is a highly static scene, with only few moving parts, so there is some rain again, and some shadow cast by raindrops as well. Now, for the static parts, incremental B frames really work wonders here. Most detail is being preserved by both encoders. What’s supposed to be happening is happening: The encoders save bit rate where the human eye can’t easily tell: In the parts where stuff is moving around very quickly. That’s how we lose a lot of raindrop shadows and some drops as well. x264 seems to have trouble separating the scene into even smaller macro blocks though? Not sure if that’s the reason, but a lot of mesh detail for the basket on the balcony on the top right is lost – x265 does better there! This is maybe because x264 couldn’t distinct the moving drops from the static background so well anymore?

At 2.5Mbit, the scenes become almost indistinguishable. The more static content we have, the easier it gets of course, so the transparency threshold becomes lower. And if you ask me, both of them reach perfect quality at 5Mbit.

Let’s throw another hard one at them for the last round:

Scene 7, H.264/AVC encoded by x264 0.148.x:

Scene 7, H.265/HEVC encoded by x265 1.9+15-425b583f25db:

Enough rain already? Pffh! Here we have a lot of foliage and low contrast added to the mix. And it gets smeared a lot by x264, rain detail lost, fine details of the bushes turning into green mud, that’s how it goes. x265 also loses too much detail here (I mean, 1Mbit is really NOT much), but again, it fares quite a bit better.

At 2.5Mbit, both encoders do very well. Somehow, this scene doesn’t seem to penalize x264 that much at the medium level. You’d really need your magnifying glass to find the spots where x265 still does better, which surprises me a bit for this scene. And finally, at 5Mbit – if you ask me – visual transparency is reached for both x264 and x265.

Final thoughts:

Clearly it’s true what a lot of people have been saying. x265 rocks at low bitrates, if configured correctly. But that isn’t gonna give me perfect quality or anything. Yeah, it sucks less – much less – than x264 in that department, but at a higher 2.5Mbit, where both start looking quite decent, x265 having just a slight edge… it becomes hardly justifiable to use it, simply because it’s that much slower to run it at decent settings.

Also, you need to take device compatibility into account. Sure, a powerful PC can always play the stuff. No matter if it’s some UNIX, Linux, MacOS X or Windows. But how about video game consoles? Older TVs? That kind of thing. Most of those can only play H.264/AVC. Or course, if you’re only using your PC and you have a lot of time and electricity to burn, then hey – why not?

But I’ll have to think really long and really hard about whether I want to replace x264 with x265 at this given point in time. Overall, it might not be practical enough on my current hardware yet. Maybe I’d need an AVX/AVX2-capable processor, as x265 has tons of optimizations for those instruction set extensions. But I’m gonna stay on my Xeon X5690 for quite a while, so SSE 4.2 is the latest I have.

I’d say, if you can stand some quality degradation, then x265 might be the way to go, as it can give you much smaller file sizes at lower bitrates with slight degradation.

If you’re aiming for high bitrates and quality, it might not be worth it right now, at least for 1080p. It’s been said the tables are turning once more when going up to 4K and UHD, but I haven’t tested that yet, as all my content – both Anime and live action movies – are “low resolution” *cough* 1080p or 720p.

Addendum:

Screenshots were taken using the latest stable mplayer 1.3.0 on Linux. Thank god they’re bundling it with ffmpeg now, making things much easier. This choice was made because mplayer can easily grab screenshots from specific spots in a video in an automated fashion. I used framesteps for this, like this:

$ mplayer ./TEST-H.265/HEVC-1mbit.mkv -nosound -vf framestep=24 \
 -vo png:z=9:outdir=./screenshots/1mbit/H.265/HEVC/:prefix=H.265/HEVC-1mbit-

This will decode every 24th frame of the video file TEST-H.265/HEVC-1mbit.mkv, and grab it into a .png file with maximum lossless compression as supported by mplayer. The .png files will be prefixed with a user-defined string and numbered, like H.265/HEVC-1mbit-00000001.pngH.265/HEVC-1mbit-00000002.png and so on, until the end of file is reached.

To encode the full size screenshots to WebP, the most recent [libwebp-0.5.0], or rather one of its companion tools – cwebp – was used as follows:

$ cwebp -z 9 -lossless -q 100 -noalpha -mt ./input.png -o ./output.webp

Now… somebody wanna grant me remote access to some quad socket Haswell-EX Xeon box for free?

No?

Meh… :roll:

Feb 122016
 

H.265/HEVC logo1.) Giving you the binaries:

Just recently I tried to give the x265 H.265/HEVC video encoder another chance to prove itself, because so far I’ve been using x264, so H.264/AVC. x264 does a really good job, but given that the marketing guys are talking about colossal efficiency/quality gains with H.265, I thought I’d put that to the test once again. It was quite easy to compile the software on my CentOS 6.7 Linux, but my old XP x64 machine proved to be a bit tricky.

But, after a bit of trial and error and getting used to the build toolchain, I managed to compile a seemingly stable version from the latest snapshot:

x265 cli, showing the version info

x265 cli, showing its version info.

Update 2: And here comes my first attempt to build an x86_64 multilib binary, that can encode H.265 at 8-bit, 10-bit and 12-bit per pixel color depths. You may wish to use this if you need more flexibility (like using 12-bit for PC only and 8- or 10-bit for a broader array of target systems like TVs, cellphones etc.). It’s currently still being tested for a short encoding run. You can specify the desired color depth with the parameter -D, like -D 8, -D 10 or -D 12:

Update: And here are the newer 1.9 versions, built from source code directly from the [MulticoreWare] (=the developers) servers. I haven’t tested these yet, but given that I configured & compiled them in the same way as before, they “should work™”:

And the old 1.7 versions from the Videolan servers:

So this has been built with MSVC10 and yasm 1.3.0 on Windows XP Pro x64 SP2, meaning this needs the Microsoft Visual C++ 2010 runtime. You can get it from Microsoft if you don’t have it yet: [32-bit version], [64-bit version]. v1.7 tested for basic functionality on XP 32-bit and tested for encoding on XP x64. The 32-bit version only supports 8-bit per pixel, which is default for x264 as well. The 64-bit versions support either 8-, 10- or 12 bits per pixel. Typically, higher internal precision per pixel results in finer gradients and less banding. 8-/10-bit is default for H.265/HEVC. 12-bit will likely not be supported by any hardware players, just as it was with 10-bit H.264/AVC before.

You may or may not know it, but as of now, x265 cannot be linked against either ffmpeg or libav, so it can only read raw input. To “feed” it properly you need either a frame server like [AviSynth] in combination with the pipe tool [Avs4x265], or a decoder that can pipe raw YUV to x265. I went for the latter version, because I already have libav+fdkaac compiled for Windows to get the avconv.exe binary. It’s quite similar to ffmpeg.

This I can only provide as a 64-bit binary, as I’m not going to build it for 32-bit Windows anytime soon I guess, so here you go:

This was compiled with GCC 4.9.2 and yasm 1.3.0 on CygWin x64. To use the two together, add the locations of your EXE files (avconv.exe and x265.exe) to your search path. Then, you can feed arbitrary video (VC1, H.264/AVC, MPEG-2, whatever) to x265. An example for a raw H.264/AVC input stream using the 64-bit versions of the software:

avconv -r 24000/1001 -i video-input.h264 -f yuv4mpegpipe -pix_fmt yuv420p - 2>NUL |^
 x265 - --wpp --y4m -D 12 -p slower --bframes 16 --bitrate 2000 --crf 18 --sar 1^
 --range full -o video-output.h265

Or another, reading some video stream from an MKV container, disabling audio and subtitles:

avconv -r 24000/1001 -i video-input.mkv -f yuv4mpegpipe -pix_fmt yuv420p -an -sn^
 - 2>NUL | x265 - --wpp --y4m -D 12 -p slower --bframes 16 --bitrate 2000 --crf 18^
 --sar 1 --range full -o video-output.h265

Just remove the carets and line breaks to make single-line commands out of those if preferred. To understand all the options, make yourself some readmes like this: avconv -h full > avconv-readme.txt and x265 --log-level full --help > x265-readme.txt or read the documentation online.

2.) How to compile by yourself:

2a.) Prerequisites:

I won’t describe how to build libav here, but just the x265 part. First of all, you need some software to be able to do this, some of it free, other not so much (unless you can swap MSVC with MSYS, I didn’t try that):

  • [cmake] (I used version 2.8.12 because that’s roughly what I have on Linux.)
  • [Mercurial] (Needed to fetch the latest version from x265′ versioning system. I used the latest Inno Setup installer.)
  • [yasm] (Put yasm.exe in your search path and you’re fine. This is optional, but you really want this for speed reasons.)
  • [Microsoft Visual Studio] (Use 2010 if you’re on Windows XP. Supported versions: 2008/VC9, 2010/VC10, 2012/VC11 & 2013/VC12)
  • [x265 source code] (Enter a target download path and use Mercurials hg.exe like hg clone https://bitbucket.org/multicoreware/x265 to fetch it)

2b.) Preparation of the solution:

Usually, you would use cmake to have it compile your entire project, but in this case it’ll build Visual Studio project files and a solution file for us. To do this, enter the proper build path. In my case I’m using Visual Studio 2010, so VC10, and I’d like to build the 64-bit version, so with the unpacked x265 source, I’d enter its subdirectory build\vc10-x86_64\ and then run the generation script: .\make-solutions.bat:

make-solutions.bat preparing cmake for us

make-solutions.bat is preparing cmake for us.

There are several things you need to make sure here: First, if you’re on Windows XP or Windows Vista, you need to toggle the WINXP_SUPPORT flag. Also, if you’re compiling for a 64-bit target, you may wish to enable HIGH_BIT_DEPTH as well to get to either 10-bit or even 12-bit per pixel other than just 8. The 32-bit code doesn’t seem to support high bit dephts right now.

Then there is one more important thing; With CMAKE_CONFIGURATION_TYPES set to Debug;Release;MinSizeRel;RelWithDebInfo, my build was unstable, throwing errors during encoding, like x265 [error]: scaleChromaDist wrap detected dist: -2029735662 lambda: 256. Setting CMAKE_CONFIGURATION_TYPES to just Release solved that problem! So you may wish to do the same.

Make sure ENABLE_CLI and ENABLE_ASSEMBLY are checked as well, then click Configure. If you’re building with high bit depth support, you’ll be presented with another option, MAIN12. You should enable this to get Main12 profile support in case you’re planning to build a 12-bit encoder. If you don’t pick it, you’ll get a 10-bit version instead, staying within Blu-Ray 4K specifications. After that, click Configure again. Generally, you need to click Configure unless no more red stuff pops up, then click Generate.

2c.) Compiling and installing the solution:

Load the resulting solution file x265.sln into Microsoft Visual Studio, then right click ALL_BUILD and pick Build. This will compile x265. If you want to install it from the IDE as well, right click INSTALL and select Build. This will install x265 in %PROGRAMFILES%\x265\ with the binary sitting in %PROGRAMFILES%\x265\bin\:

Microsoft Visual Studio 2010, ready to compile the x265 solution generated by cmake

Microsoft Visual Studio 2010 with the x265 solution generated by cmake loaded, compiled and installed.

3.) Running it:

Now we can feed x265 some raw YUV files like this, after adding x265.exe to the search path:

x265 encoding a raw YUV file to H.265/HEVC

x265 encoding a raw YUV 4:2:0 file to H.265/HEVC (The options given to x265 may actually suck, I’m still in the learning process).

Or we can use a decoder to feed it arbitrary video formats, even from MKV containers, like shown in the beginning. ffmpeg or avconv can decode pretty much anything, and then pipe it into x265 as raw YUV 4:2:0:

x265 being fed a H.264/AVC bitstream by avconv

x265 being fed a H.264/AVC bitstream by avconv.

And that’s it! Now all I need is some 18-core beast processor to handle the extreme slowness of the encoder at such crazy settings. When going almost all-out, it’s easily 10 times as slow as x264 (at equally insane settings)! Or maybe I can get access to some rack server with tons of cores or something… :roll:

Update: All x265 releases have now been consolidated on [this page]! All future XP- and XP x64-compatible releases of x265 plus a relatively recent version of avconv to act as a decoder for feeding x265 with any kind of input video streams will be posted there as well.

Jan 272016
 

HakuNeko logoJust yesterday I’ve showed you how to modify and compile the [HakuNeko] Manga Ripper so it can work on FreeBSD 10 UNIX, [see here] for some background info. I also mentioned that I couldn’t get it to build on CentOS 6 Linux, something I chose to investigate today. After flying blind for a while trying to fix include paths and other things, I finally got to the core of the problem, which lies in HakuNekos’ src/CurlRequest.cpp, where the code calls CURLOPT_ACCEPT_ENCODING from cURLs typecheck-gcc.h. This is critical stuff, as [cURL] is the software library needed for actually connecting to websites and downloading the image files of Manga/Comics.

It turns out that CURLOPT_ACCEPT_ENCODING wasn’t always called that. With cURL version 7.21.6, it was renamed to that from the former CURLOPT_ENCODING as you can read [here]. And well, CentOS 6 ships with cURL 7.19.7…

When running $ ./configure && make from the unpacked HakuNeko source tree without fixing anything, you’ll run into this problem:

g++ -c -Wall -O2 -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -o obj/CurlRequest.cpp.o src/CurlRequest.cpp
src/CurlRequest.cpp: In member function ‘void CurlRequest::SetCompression(wxString)’:
src/CurlRequest.cpp:122: error: ‘CURLOPT_ACCEPT_ENCODING’ was not declared in this scope
make: *** [obj/CurlRequest.cpp.o] Error 1

So you’ll have to fix the call in src/CurlRequest.cpp! Look for this part:

  1. void CurlRequest::SetCompression(wxString Compression)
  2. {
  3.     if(curl)
  4.     {
  5.         curl_easy_setopt(curl, CURLOPT_ACCEPT_ENCODING, (const char*)Compression.mb_str(wxConvUTF8));
  6.         //curl_easy_setopt(curl, CURLOPT_ACCEPT_ENCODING, (const char*)memcpy(new wxByte[Compression.Len()], Compression.mb_str(wxConvUTF8).data(), Compression.Len()));
  7.     }
  8. }

Change CURLOPT_ACCEPT_ENCODING to CURLOPT_ENCODING. The rest can stay the same, as the name is all that has really changed here. It’s functionally identical as far as I can tell. So it should look like this:

  1. void CurlRequest::SetCompression(wxString Compression)
  2. {
  3.     if(curl)
  4.     {
  5.         curl_easy_setopt(curl, CURLOPT_ENCODING, (const char*)Compression.mb_str(wxConvUTF8));
  6.         //curl_easy_setopt(curl, CURLOPT_ACCEPT_ENCODING, (const char*)memcpy(new wxByte[Compression.Len()], Compression.mb_str(wxConvUTF8).data(), Compression.Len()));
  7.     }
  8. }

Save the file, go back to the main source tree and you can do:

  • $ ./configure && make
  • # make install

And done! Works like a charm:

HakuNeko fetching Haiyore! Nyaruko-san on CentOS 6.7 Linux

HakuNeko fetching Haiyore! Nyaruko-san on CentOS 6.7 Linux!

And now, for your convenience I fixed up the Makefile and rpm/SPECS/specfile.spec a little bit to build proper rpm packages as well. I can provide them for CentOS 6.x Linux in both 32-bit as well as 64-bit x86 flavors:

You need to unzip these first, because I was too lazy to allow the rpm file type in my blogging software.

The naked rpms have also been submitted to the HakuNeko developers as a comment to their [More Linux Packages] support ticket which you’re supposed to use for that purpose, so you can get them from there as well. Not sure if the developers will add the files to the projects’ official downloads.

This build of HakuNeko has been linked against the wxWidgets 2.8.12 GUI libraries, which come from the official CentOS 6.7 package repositories. So you’ll need to install wxGTK to be able to use the white kitty:

  • # yum install wxGTK

After that you can install the .rpm package of your choice. For a 64-bit system for instance, enter the folder where the hakuneko_1.3.12_el6_x86_64.rpm file is, run # yum localinstall ./hakuneko_1.3.12_el6_x86_64.rpm and confirm the installation.

Now it’s time to have fun using HakoNeko on your Enterprise Linux system! Totally what RedHat intended you to use it for! ;) :roll:

Jan 262016
 

HakuNeko logoSince I’ve started using FreeBSD as a Linux and Windows replacement, I’ve naturally always been looking at porting my “known good” software over to the UNIX OS, or at replacing it by something that gets the job done without getting on my nerves too much at the same time. For most parts other than TrueCrypt, that was quite achievable, even though I had to endure varying degrees of pain getting there. Now, my favorite Manga / Comic ripper on Windows, [HakuNeko] was the next piece of software on the list. It’s basically just a more advanced Manga website parser and downloader based on stuff like [cURL], [OpenSSL] or the [wxWidgets] GUI libraries.

I didn’t even know this until recently (shame on me for never looking closely), but HakuNeko is actually free software licensed under the MIT license. Unfortunately, the source code and build system are quite Linux- and Windows-centric, and there exist neither packages nor ports of it for FreeBSD UNIX. Actually, the code doesn’t even build on my CentOS 6.7 Linux right now (I have yet to figure out the exact problem), but I managed to fix it up so it can compile and work on FreeBSD! And here’s how, step by step:

1.) Prerequisites

Please note that from here on, terminal commands are shown in this form: $ command or # command. Commands starting with a $ are to be executed as a regular user, and those starting with # have to be executed as the superuser root.

Ok, this has been done on FreeBSD 10.2 x86_32 using HakuNeko 1.3.12, both are current at the time of writing. I guess it might work on older and future releases of FreeBSD with different releases of HakuNeko as well, but hey, who knows?! That having been said, you’ll need the following software on top of FreeBSD for the build system to work (I may have missed something here, if so, just install the missing stuff like shown below):

  • cURL
  • GNU sed
  • GNU find
  • bash
  • OpenSSL
  • wxWidgets 2.8.x

Stuff that’s not on your machine can be fetched and installed as root from the official package repository, Like e.g.: # pkg install gsed findutils bash wx28-gtk2 wx28-gtk2-common wx28-gtk2-contrib wx28-gtk2-contrib-common

Of course you’ll need the HakuNeko source code as well. You can get it from official sources (see the link in first paragraph) or download it directly from here in the version that I’ve used successfully. If you take my version, you need 7zip for FreeBSD as well: # pkg install p7zip.

Unpack it:

  • $ 7z x hakuneko_1.3.12_src.7z (My version)
  • $ tar -xzvf hakuneko_1.3.12_src.tar.gz (Official version)

The insides of my archive are just vanilla as well however, so you’ll still need to do all the modifications by yourself.

2.) Replace the shebang lines in all scripts which require it

Enter the unpacked source directory of HakuNeko and open the following scripts in your favorite text editor, then replace the leading shebang lines #!/bin/bash with #!/usr/local/bin/bash:

  • ./configure
  • ./config_clang.sh
  • ./config_default.sh
  • ./res/parsers/kissanime.sh

It’s always the first line in each of those scripts, see config_clang.sh for example:

  1. #!/bin/bash
  2.  
  3. # import setings from config-default
  4. . ./config_default.sh
  5.  
  6. # overwrite settings from config-default
  7.  
  8. CC="clang++"
  9. LD="clang++"

This would have to turn into the following (I also fixed that comment typo while I was at it):

  1. #!/usr/local/bin/bash
  2.  
  3. # import settings from config-default
  4. . ./config_default.sh
  5.  
  6. # overwrite settings from config-default
  7.  
  8. CC="clang++"
  9. LD="clang++"

3.) Replace all sed invocations with gsed invocations in all scripts which call sed

This is needed because FreeBSDs sed and Linux’ GNU sed aren’t exactly that compatible in how they’re being called, different options and all.

In the text editor vi, the expression :%s/sed /gsed /g can do this globally over an entire file (mind the whitespaces, don’t omit them!). Or just use a convenient graphical text editor like gedit or leafpad for searching and replacing all occasions. The following files need sed replaced with gsed:

  • ./configure
  • ./res/parsers/kissanime.sh

4.) Replace all find invocations with gfind invocations in ./configure

Same situation as above with GNU find, like :%s/find /gfind /g or so, but only in one file:

  • ./configure

5.) Fix the make check

This is rather cosmetic in nature as $ ./configure won’t die if this test fails, but you may still wish to fix this. Just replace the string make --version with gmake --version (there is only one occurrence) in:

  • ./configure

6.) Fix the DIST variables’ content

I don’t think that this is really necessary either, but while we’re at it… Change the DIST=linux default to DIST=FreeBSD in:

  • ./configure

Again, only one occurrence.

7.) Run ./configure to create the Makefile

Enough with that, let’s run the first part of the build tools:

  • $ ./configure --config-clang

Notice the --config-clang option? We could use GCC as well, but since clang is FreeBSDs new and default platform compiler, you should stick with that whenever feasible. It works for HakuNeko, so we’re gonna use the default compiler, which means you don’t need to install the entire GCC for just this.

There will be error messages looking quite intimidating, like the basic linker test failing, but you can safely ignore those. Has something to do with different function name prefixes in FreeBSDs libc (or whatever, I don’t really get it), but it doesn’t matter.

However, there is one detail that the script will get wrong, and that’s a part of our include path. So let’s handle that:

8.) Fix the includes in the CFLAGS in the Makefile

Find the line containing the string CFLAGS = -c -Wall -O2 -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread or similar in the newly created ./Makefile. After the option -O2 add the following: -I/usr/local/include. So it looks like this: CFLAGS = -c -Wall -O2 -I/usr/local/include -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread. That’s it for the Makefile.

9.) Fix the Linux-specific conditionals across the C++ source code

And now the real work starts, because we need to fix up portions of the C++ code itself as well. While the code would build and run fine on FreeBSD, those relevant parts are hidden behind some C++ preprocessor macros/conditionals looking for Linux instead. Thus, important parts of the code can’t even compile on FreeBSD, because the code only knows Linux and Windows. Fixing that isn’t extremely hard though, just a bit of copy, paste and/or modify. First of all, the following files need to be fixed:

  • ./src/MangaConnector.cpp
  • ./src/Logger.cpp
  • ./src/MangaDownloaderMain.cpp
  • ./src/MangaDownloaderConfiguration.cpp

Now, what you should look for are all conditional blocks which look like #ifdef __LINUX__. Each will end with an #endif line. Naturally, there are also #ifdef __WINDOWS__ blocks, but those don’t concern us, as we’re going to use the “Linux-specific” code, if you can call it that. Let me give you an example right out of MangaConnector.cpp, starting at line #20:

  1. #ifdef __LINUX__
  2. wxString MCEntry::invalidFileCharacters = wxT("/\r\n\t");
  3. #endif

Now given that the Linux code builds just fine on FreeBSD, the most elegant and easier version would be to just alter all those #ifdef conditionals to inclusive #if defined ORs, so that they trigger for both Linux and FreeBSD. If you do this, the block from above would need to change to this:

  1. #if defined __LINUX__ || __FreeBSD__
  2. wxString MCEntry::invalidFileCharacters = wxT("/\r\n\t");
  3. #endif

Should you ever want to create different code paths for Linux and FreeBSD, you can also just duplicate it. That way you could later make changes for just Linux or just FreeBSD separately:

  1. #ifdef __LINUX__
  2. wxString MCEntry::invalidFileCharacters = wxT("/\r\n\t");
  3. #endif
  4. #ifdef __FreeBSD__
  5. wxString MCEntry::invalidFileCharacters = wxT("/\r\n\t");
  6. #endif

Whichever way you choose, you’ll need to find and update every single one of those conditional blocks. There are three in Logger.cpp, three in MangaConnector.cpp, two in MangaDownloaderConfiguration.cpp and again three in MangaDownloaderMain.cpp. Some are more than 10 lines long, so make sure to not make any mistakes if duplicating them.

Note that you can maybe extend compatibility even further with additional directives like __OpenBSD__ or __NetBSD__ for additional BSDs or __unix__ for a wide range of UNIX systems like AIX or HP-UX. None of which has been tested by me of course.

When all of that is done, it’s compile and install time:

10.) Compile and install

You can compile as a regular user, but the installation needs root by default. I’ll assume you’ll want to install HakuNeko system-wide, so, we’ll leave the installation target directories on their defaults below /usr/local/. While sitting in the unpacked source directory, run:

  • $ gmake
  • # gmake install

If nothing starts to crash and burn, this should compile and install the code. clang will show some warnings during compilation, but you can safely ignore that.

11.) Start up the white kitty

The installation procedure will also conveniently update your window manager as well, if you’re using panels/menus. Here it’s Xfce4:

HakuNeko is showing up as an "Internet" tool

HakuNeko (“White Cat”) is showing up as an “Internet” tool. Makes sense.

With the modifications done properly it should fire up just fine after initializing its Manga connectors:

HakuNeko with the awesomeness that is "Gakkou Gurashi!" being selected from the HTTP source "MangaReader"

HakuNeko with the awesomeness that is “Gakkou Gurashi!” being selected from the HTTP source [MangaReader].

Recently the developers have also added [DynastyScans] as a source, which provides access to partially “rather juicy” Yuri Dōjinshi (self-published amateur and sometimes semi-professional works) of well-known Manga/Anime, if you’re into that. Yuri, that is (“girls love”). Mind you, not all, but a lot of the stuff on DynastyScans can be considered NSFW and likely 18+, just as a word of warning:

HakuNeko fetching a Yuru Yuri Dōjinshi from DynastyScans, bypassing their download limits by not fetching packaged ZIPs - it works perfectly!

HakuNeko fetching a Yuru Yuri Dōjinshi called “Secret Flowers” from DynastyScans, bypassing their download limits by not fetching packaged ZIPs – it works perfectly!

Together with a good comic book reader that can read both plain JPEG-filled folders and stuff like packaged .cbz files, HakuNeko makes FreeBSD a capable comic book / Manga reading system. My personal choice for a reader to accompany HakuNeko would be [QComicBook], which you can easily get on FreeBSD. There are others you can fetch from the official package repository as well though.

Final result:

HakuNeko and QComicBook make a good team on FreeBSD UNIX

HakuNeko and QComicBook make a good team on FreeBSD UNIX – I like the reader even more than ComicRack on Windows.

And, at the very end, one more thing, even though you’re likely going to be aware of this already: Just like Anime fansubs, fan-translated Manga or even Dōjinshi are sitting in a legal grey zone, as long as the book in question hasn’t been licensed in your country. It’s being tolerated, but if it does get licensed, ownership of a fan-translated version will likely become illegal, which means you should actually buy the stuff at that point in time.

Just wanted to have that said as well.

Should you have trouble building HakuNeko on FreeBSD 10 UNIX (maybe because I missed something), please let me know in the comments!

Dec 112015
 

Tokisaki Kurumi logoOk, enough technology and storage stuff already, time for more Anime nonsense! Soon I will seriously need to call myself a figure collector if this keeps going on. So here’s a new one, Miss Tokisaki Kurumi from the Harem Anime [Date A Live]. While I was growing increasingly bored with the formulaic nature of such shows (it’s always a flock of girls swarming around a male center character and falling for him in the end after all), they’re usually fun enough to watch now and then. The same is pretty much true for Date A Live – if it wasn’t for the psychotic, strong-willed Kurumi, which always follows her own agenda and never actually falls for our stereotypical male center character. Not even in the very end of the series.

I kind of liked that, because I never encountered such a character in such a type of Anime before – intelligent, highly manipulative, psychotic and insane, and definitely superior to the center character in almost every sense, be it willpower, intellect or raw force. Nice breeze of change. Also, when she shows up, the series changes from sugary sweetness to a literal bloody mess, which was quite intense! In essence – she makes the series.

Tokisaki Kurumi banner

[1] An interpretation of Kurumi – the clock dial in her eye shows her remaining life time. It can be rewound though – at the price of life force of those surrounding her, potentially all the way to their demise.

Besides all the slightly lewd subplots, the rest of the Anime is basically supernatural action with lots of nonsensical battles and destruction, where our male character – Itsuka Shidō – “disables” newly arrived “spirits” (=the girls) by sealing their highly dangerous and uncontrollable powers so that they can’t cause their accidental spatial anomalies anymore. Those could otherwise annihilate entire cities or even countries. He seals those powers via romancing/kissing them. Sometimes mid-battle. Yeah, it’s about as stupid as it sounds, at least until Kurumi hits the stage and blood starts spilling.

In any case, I’ve been thinking about getting the [AlphaMax] 1/7 scale figure of her for some time, but it’s expensive and I wasn’t quite sure whether I should get her. Did she impress me enough for that? But now, months after watching the show, I’ve still been eyeballing the figure, so yeah.

Recently, I saw something called the [clear dress] version on eBay, which is a 130pcs limited edition made for the [Wonder Festival 2015] only. Not knowing about its existence prior to that, I asked whether this was the “AlphaMax preorder limited” edition I had recently learned about. Well, it wasn’t, but to my great surprise the Japanese seller – a guy who specializes in rare items – looked for and managed to find one for me after my inquiry, here it is:

Tokisaki Kurumi box

Sculpted by MOON for AlphaMax – from the outside it looks just like the regular version – for a moment I thought I was duped… but nah, it’s the exclusive limited edition alright!

Now this limited version doesn’t feature the weird clear dress which creates that contrast between upper and lower part of her garments that I don’t like – also, it doesn’t have the golden guns as bonus parts. I don’t really like them that much either. Instead you get a different version of the clockwork base plate, which is rather iconic for Kurumi and really makes the whole figure much more flashy!

So, the normal base plate looks like this:

The normal clockwork base plate

[2] The regular version comes with this stand.

The clockwork can also be seen appearing in the series whenever Kurumi unleashes her time manipulation powers, so this is really fitting. However, the one I got with this 200-pieces limited edition – which was exclusively sold only by the manufacturer AlphaMax on their own webshop and only within Japan – is this one:

Tokisaki Kurumi golden/metallic base plate

The metallic/golden base plate of the AlphaMax preorder limited edition, I should’ve probably hidden the paper support better, but meh…

So as you can see, that’s quite the eye-catcher! It’s still made of cheap plastic, but the metallic finish makes it reflect light in really nice ways when illuminated. The next part are her guns, a vintage pistol and rifle:

Tokisaki Kurumis weapons

Those guns can shoot normal bullets just fine – but when infused with Kurumis supernatural powers they can do a lot more damage.

Ok, time for showing her off in her full glory, gothic lolita “battle dress” and all:

Her garments do look awesome alright. The whole dynamic feeling comes across really well in her pose, with the dress flowing around like that. And it’s hard to beat a red/orange+black gothic lolita dress in the first place. ;) Let’s get a bit closer, so you can see some of the details better:

Tokisaki Kurumi gothloli front

Her ribbon’s well done as well. The chains could’ve looked better with some more love to detail, but they’re still ok.

And the back:

Tokisaki Kurumis' back

The laces across her otherwise exposed back and the black apron flowing with her implied movement all look awesome. The sculpting is perfect here, just look at the shoulder blades!

And more gunnery:

And now to her face, which is important because of the clock dial eye:

One interesting part is the actual scale; that 1/7 Kurumi should be quite a bit larger than the [1/8 Ho-kago Tea Time figures] made by Alter. The dimensions are almost the same however, with Kurumis’ features being only insignificantly larger. Given that Wave/Dreamtechs 1/8 Elfen Lied scale figures are smaller than Ho-kago Tea Time, this may indicate that Alter is slightly oversizing their figures? Or is it just that nobody’s staying 100% true to the scale factor to begin with?!

Ah, in any case, time to move in:

Tokisaki Kurumi in her new home

She’s living here now. Just give her a wide berth if you’re feeling unlucky today. ;)

Besides the [supersized Kirino], which simply can’t be beaten in how she dominates the whole cabinet due to sheer size (and by being awesome), Kurumi is definitely the most flashy figure I own now. The gothloli dress and her very dynamic pose alone make sure of that, but the limited editions’ golden base plate really uplifts the whole figure to a different level. An eyecatcher and a beauty to look at!

I’d almost feel sad for the other girls from the show for not even considering them for a second, but sorry; you simply can’t even hold a candle to Kurumi! 8-)

Let’s hope I’ll stop buying more for some while. There are two more scales and at least one Nendoroid on my wishlist, but I’ll have to think about the space issues here. That cabinet may be full height, but it’s starting to get a bit crowded in there… ;) At least the Nendoroids don’t need to stand in the cabinet. The two I own for now – I haven’t posted them here yet, [Miyauchi Renge] from Non Non Biyori and [Nee-san] from Plastic Nee-san – are happily standing around elsewhere.

Ah well, we’ll see, we’ll see…

Tokisaki Kurumi's insane

Kurumi says bye bye to you!

[1] The original creator of this image is unknown to me. If you are the creator and wish to object to the publication of this image here, please post in the comment section!

[2] Original image is © 2014 橘公司・つなこ/KADOKAWA 富士見書房刊/「デート・ア・ライブⅡ」製作委員会, published by AlphaMax.

Oct 302015
 

Kirino Kousaka logoOk ok ok, what I actually wanted to do was to post something about technology again after last time, which was a bit massively out-of-context for this weblog, but truth is: I just don’t really have anything. :( And as my Anime craze is getting worse and worse (only by terms of money spent at least, or so I hope), let’s let this here post stand before you as a warning and as a testament to how things can go terribly, terribly wrong real fast! Once you enter the slippery slope you’re pretty much done for, if you’re not particularly strong-willed. And sane. And if you don’t stick to the [rules].

Ok, so there are a lot of series I really like, K-On! being one of them, which is why [I got the Alter figures] of the whole gang in the first place.

Another one that really burned itself into my mind was [Oreimo]. I originally started watching this because it had a theme that was new for me, as it was about a girl named Kirino Kousaka who happened to secretly be a closet Otaku, while instrumentalizing her brother to acquire partially barely legal Anime and visual novel material for her. Or giving her “life advice”. Basically, she’s living two lives in parallel: A normal, or rather high-class one even in public, and a very nerdy one in private. Plus, Oreimo promised to have a lot of typical slice-of-life humor any maybe some very mild harem notes thrown into the mix.

Or so.

Seriously, I did not KNOW when I started watching this. And that’s how I slipped into what’s actually a Siscon Anime for the first time, or to explain properly to those still pure of heart: Into an Anime about a romantic relationship between siblings. Now whether you like or hate that kind of “forbidden love” thing, Oreimo does it more through subliminal tension between the characters than wide-open. Unless the very end, which 99% of viewers disliked anyway (I shall not comment on this). There is also NO erotic content in this title whatsoever. No [Ecchi] or anything worse than that.

Still, I found the whole theme quite… shall we call it “fascinating”.

If only I would’ve never been shown that figure, it might have actually missed it and everything would still be fine! But nooo, It just had to happen, and when I saw it, I immediately knew I had to have it, no matter what. It was Kirino after all, and it was completely insane as well. Let’s give you a little teaser, and as always, click to enlarge:

Kirino Kousaka Teaser

That old öS 10.- coin is roughly 25.5mm or in other words barely over an inch wide… Getting an idea about the issue at hand already?

Ah yes, my apologies for the stamps by the way. I don’t usually stamp pictures I post here, because the license is clear anyway. But I forgot this time, and I’m too lazy to process the originals again, so sorry for that.

Ok, now let me explain something here quickly: You can be figure faggot. That’s weird, ok. People will probably look at you strangely, especially if you own a little bit too many of them. But you can still be a figfag within reason.

Within reason!

There are several types of figures. The classic and most common one is probably the 1/8 scale figure. Those stand around 15cm or 6″ tall in most cases, so they’re rather small and…  uhm, easy to hide I guess. :roll: Depending on quality and accessoires, they might set you back something in between 40-110€ when new. Then, far more rarely you’d find 1/7 scale figures. Those can stand 20-25cm or around 8″-10″ tall and are much more expensive, sums in between 150-200€ can be expected, sometimes more. Those are still relatively normal however.

Well, and then there is…  stuff. Things you just don’t buy. Ever. Because people will simply lose all respect they may have had for you if you do. Things like the 1/2.5 scale Kirino Kousaka. 1/2.5. Bah, let’s just get this over with, so much for guilty pleasures:

Uhm. Yeah. I guess that whoever might’ve still been reading this weblog will have ran away pretty much now. ;) When I first unpacked her, and (already shivering) stuck her onto that pretty nice wooden baseplate to see her stand on my table in all glory… I mean…  It’s… Seriously… Let’s just say, in that moment I truly grasped what it means to have just gone too far with all of this. Like really too far! I did burst into laughter though, after maybe a minute of disbelief, shock and silence. ;)

To say it in numbers: Kirino Kousaka stands about 66cm tall without and roughly 68cm with the baseplate, that’s about 26.8″. Also, the model weighs a hefty 6 kilograms, so you need to be careful when lifting her as a whole. Also, those 6 kilograms of PVC do dispense a lot of nasty smell/gas as well, not sure how healthy that can be. So please don’t lick her, she’s probably toxic, ok? :roll:

In any case, she was made by [Griffon Enterprises], which was one thing I was really worried about, because I had zero experience with the company, and they have a seriously bad reputation amongst fans for two main reasons; First, their quality fluctuates massively, depending on what sculptor/group of theirs is doing which figure. And on top of that they’re well known for showing off beautifully perfect prototypes only to deliver complete shit as an – overpriced, mind you – end product. Ah, and actually, there’s a third, because sometimes they also mess up the painting or scratch the figure somewhere after production, maybe during the packaging process.

Also, Griffon does out-of-canon figures (can you say it like that in English?), and this is one of them. I don’t usually like it when they take regular characters and put them into swimsuits for no good reason for instance. Here it’s diverting in a different way, as they’ve added a tail and cat ears. Now somehow I still totally love this Kirino of theirs to no end, I just can’t help it… But they could’ve made the ears and maybe the tail removable, that would’ve been nice. In any case, it was sculpted by some guys called “TEAM GENESIS”, and they’re supposed to be pretty much amongst the best Griffon has to offer, and it shows:

They did mess up the paint though, so it is not perfect! If you look at the string coming off, you can see it’s pretty much pink in color, and it runs very close alongside her left leg. While some parts like the tail were covered in individual protective plastic bags, the string was not. It seems the figure was packaged or handled in a rushed fashion, and some of that pink paint got onto her leg, giving her pink spots all over. She also has some slight blackish marks here and there on the legs.

Now if you get a figure with deficiencies like those, you can fix them by yourself in some cases, other than what most people seem to believe! As you can see, there are no marks left on those pictures above, right? All you need is a soft sponge and some water, then rub the affected areas very carefully. You really need to use a soft one, otherwise you will scratch the PVC, which has already been softened by plasticizers. And don’t overdo it, or the leg color itself might start coming off. Work slowly and carefully, and it’s gonna look perfect, just like you can see up there. The whole thing’s worth some minus points, but at least it’s fixable.

Ok, time for some action:

Kirino Kousaka and Ritsu Tainaka

Go Ritsu!!!1

I just had to snap that picture. ;) For an 1/8 model, Ritsu Tainaka is actually pretty large because of here extensive baseplate which needs to hold not only her, but also her signature drum kit. It’s probably one of the wider 1/8 sets out there. And still, she can almost play right in between Kirino’s lower legs. ;)

Now where do you put a figure this excessive? It’s not like you can fit one this large into any regular display case. Luckily, my cabinet can just barely hold her when removing one of the glass floors. I was a bit worried about that because the specifications talk about 70cm rather than 68cm, but in the end, she fits in quite well:

Kirino Kousaka in the cabinet

Her display spot

Oh and… ah yes… There is one more detail I’d really rather not talk about, but since it’s funny as well… There are actually two versions of this breathtakingly large figure of Kirino Kousaka. After about a year of delays with the official final release being tomorrow actually, the normal one (I mean, heh, “normal”, nothing’s normal here anymore!!) was supposed to come out first, and after that the… uhm… “Soft Bust” version. Yeah, it really means what it sounds like, sigh…

In any case, and let me make this perfectly clear here, I DID NOT order the Soft Bust version! :roll: Instead I ordered the normal one at [SolarisJapan], partly because I feared Griffon would mess something up terribly with that soft material. Also because it’d look really, really bad to do something like that! ;)

They failed to deliver the normal one though, as it seems the number of units was just too small and all were gone through preorders already. They were able to offer me the Soft Bust version for the same price as a replacement however, and even waived the higher delivery fees resulting from the manufacturer misdeclaring the units’ true weight (Good work deceiving people there, Griffon, haven’t heard that one before).

SolarisJapan is a nice shop by the way, they even have English and German speaking support staff, those guys really hired native speakers for that! So, after sleeping over it for one night I decided to accept their offer before I miss out on her entirely and have to buy for completely insane prices on the aftermarket. I mean, this figure costs around 350-400€ new without custom fees or shipping costs, and that ain’t cheap, but not expensive either, considering what you’re getting. The aftermarket is already asking 700-800€ for the regular one right now, profiting out of the low volume. Well, whatever.

I am still not exactly sure what the hell they did to the plastic, but it seems like they poured in a ton of plasticizer to make her boobs soft. What actually happened is that her entire upper torso and shoulders are a bit soft to the touch, much more so than the rest of the figure, which feels normal for PVC treated with plasticizer. Also, that part of the material attracts dust and dirt more easily, and cleaning it is not as straightforward, as compressed air doesn’t work there. You really have to wipe. :roll: I just hope it won’t change color or shape (yeah, shape ;) ) over time.

In any case, since I do now own the Soft Bust version after all, I guess there’s simply no way I can get around this, eh? So there you have it: ;)

Kirino Kousaka Soft Bust

Words can’t possibly express how wrong this is… But I’ll admit, I did giggle quite a lot. ;)

Talk about losing whatever rest was left of my self-control. As the man who tricked me into this whole thing said it after seeing the pictures (freely translated into English):

“Less well-educated people might presume here, that some things may have went a little bit out of control.”
A terrible Person, who hasn’t even posted his new figures on his own blog after luring me into this whole Anime hell, way to go MacFly!!1 :roll:

Oct 152015
 

Ho-kago Tea Time logo - Azu-nyanI think I have made a threat about posting Anime stuff before, and since everything I’ve been doing all day for the better part of the past eight months had at least something to do with Anime, I’ll just go with that. There is nothing really new on the PC, storage or Linux/UNIX frontlines anyways. And if there was, i’d probably miss it anyways, heh…

Before I start, I would like to thank… – no wait, rather blame –  [Umlüx] for all this crap, because he (re-)infected me with this whole Anime craze, and after a few series it just spiralled completely out of control. I still don’t quite grasp what the hell actually happened and how I’ve seen 60 Anime titles totalling almost a 28.000 minutes of viewing time in eight months…

Anyhow, like most rather die-hard Anime fans, I wanted figures of my favorite characters at some point. I already own two extremely rare figures from the brutal Yandere series Elfen Lied, [Lucy] and [Nana] (as you can see, I went through some efforts to present them properly) that I got about six years ago. But I never actually started to really collect them, so it was still only those two. I wasn’t really watching Anime anymore anyway, until this March. However, at some point, shit had to happen, and it happened for the Anime series [K-On!]:

As always, click or shift+click to enlarge:

Now whether you love or hate cute [Moeblob] series, I greatly enjoyed quite a few of them, including this music-related slice-of-life series, where the viewer accompanies 4-5 girls through their little adventure of founding their schools’ light music club and with it their band “Ho-kago Tea Time” (eng. “After School Tea Time”). So yeah, this is another highschool series. Yes, it’s very Moe. It’s also very much about nothing most of the time, but hey. If you’re a Moepig like I am sometimes, you might enjoy this. Anyway, let’s get to it, the complete K-On! figure set by manufacturer [Alter]!

I’ll start with the first character of the series, our classic clumsy airhead who goes by the name of Yui Hirasawa. She plays Ho-kago Tea Times’ lead guitar (’cause hey, that’s what clumsy airheaded highschool girls with zero skills do) and does some of the vocals as well:

Now, when looking at the quality it becomes clear that Yui herself is pretty standard fare. Don’t take it the wrong way, the sculpting and painting quality is great, and she resembles the Yui from the Anime a 100% (so the face is perfect), but there is just so much detail to flesh out for a normally dressed highschool girl out of an Anime.

Where Alter really begins to shine though is accessories, in this case the musical instruments. Keep in mind that these 1/8 scale figures stand only about 15cm tall in total, so the details you can see on the guitar are quite tiny in reality. What we get is some nice body finish, actual real strings on the guitar and well-defined details on the neck and body. Just look at the pickups and the bridge assembly! Not bad at all.

Now, let’s continue with the super-shy Moequeen of the series, Mio Akiyama, who is the bass guitarist and main vocalist of the band:

Mio is one of the two founders of Ho-kago Tea Time, – following Ritsu against her will originally, but it was only after Yui named her own guitar something along the lines of “geetah” that Mios beloved bass guitar also got its name “Elizabass”, which was bashfully accepted by Mio only in secret. In contrast to Yuis childlike appearance, Mio looks more grown-up, mostly thanks to her different eye design. This is also reflected in her more earnest character, where Yui is just an airheaded mess in comparison. As mentioned however, she is extremely shy as well, making her the instant Moewinner in K-On!.

As you can see, the details like the knobs, pickups and especially the bridge assembly are once again top notch, as is the finish of the guitars body!

Let’s pull out the last of the three guitarists from behind, Azusa Nakano. She joined as the last member one year after the original founding, and is actually really proficient in playing her guitar:

Yeah, she’s wearing cat ears (jap. 猫耳, hepb. nekomimi). You can remove them as they’re optional, but who would ever want to remove the cat ears of the series’ local cute, semi-loli [Tsundere] character? Ah yes, I feel like I have to post these as well, just can’t help it, otherwise we’re not getting any actually visible Moe here today:

Eh…  yeah, well, now that that’s out of the way…

Besides the nice sculpting, Azu-nyan has a small flaw on one of her legs though, about 1mm in size. It’s relatively negligible though. You may be able to spot it on the top left photo of her, just to the left of her knee.

As for her guitar, the knobs are just “ok” in comparison (ah shit, I can’t get my eyes off those GIFs while writing this…), but the structured whiteish surface of the body and those subminiature screws are excellent indeed! The head of the guitar leaves pretty much nothing to be desired either, and the whole neck plus head even mimic the originals’ wooden structure, which can also be seen with Yuis guitar by the way. I just forgot to take an according picture of hers.

But now it gets really serious, let me show you the second most expensive of the five figures, the keyboarder and classic “calm, blonde and super rich girl” of the group (there always has to be a rich girl), who always delivers the most exquisite sweets and expensive tea for the actual “After school Tea Time”; Tsumugi Kotobuki, or in short Mugi-chan, who is also kind of an airhead on top of things:

Unfortunately, her figure shows quite some damage, likely due to ultraviolet radiation, or in other words: Direct sunlight exposure over an extended period of time. It’s actually worse than it looks on the photograph. Sunlight exposure is generally quite bad for pre-painted PVC figures, as it “burns” the color, severely darkening it in the process. So it’s far from mint condition, and it’s pretty clear that while the figures were completely clean and very professionally packaged in their original boxes, it is likely they’ve been unpacked and on display at some time in the past.

Her keyboard is the real deal however. That level of detail is breathtaking, with many of the features smaller than a single millimeter! Just look at the display! Not only does it look like an actual LCD, but in just about 10mm of width it fits an unbelieveable amount of detail including one of the bands’ song names “Cagayake! GIRLS”. I didn’t even spot that with the naked eye, I only noticed that on the magnified photos afterwards. Insane, given that there are even much smaller features than the track name!

Alter is really showing its strengths here! But let’s take a look at the last of the five, our wild Tomboy drummer, Ritsu Tainaka and her signature yellow drumkit:

Once more, one can feel Alters love for detail! Not only do the drums and hihats look awesome, they have actual drumheads with proper tension. Heck, the snare drum even has an actual working snare attached to it! A shame I forgot to take a picture of that. Ah yes, and the pedals. At least the bass drum pedal even moves a little and the beater is properly attached to and moves with it. Now you can’t really play the drum with that as there is not enough leeway, but still.

I’m not sure if I’m impressed more by Ritsus drumkit or Mugi-chans highly detailed keyboard, as both are really awesome in their own right!

Let’s put ’em all together, this is our fully staffed Ho-kago Tea Time:

Ho-kago Tea Time!

From left to right: Support vocalist Yui on the lead guitar, Ritsu on the drums, Azusa on the support guitar, Mugi-chan on the keyboard and lead vocalist Mio on the bass guitar!

Now I clearly can’t leave them like that, and I don’t have an actual figure display case as I am not (or was not?!?) a collector in the first place. Also I don’t wanna buy one because I don’t have a good place for something like a set of [DETOLFs]. I do have a wooden glass cabinet though, which is an integral part of my living room furniture. That cabinet is large enough and was orginally used for storing decanters, vases and drinking glasses. Now who needs those on display, right?! Right.

So I removed them, and together with the built-in halogen lamp of the cabinet we get a setup with some nice atmosphere, so that’s where I’m gonna leave them:

Ho-kago Tea Time at night

Ho-kago Tea Time performance!

It’s also perfect considering that there is just enough space to place the entirety of Ho-kago Tea Time in there without making it look too cramped. While the door has wooden strips in the middle, moving the figures slightly to the left and right respectively works well enough to make them all visible to the viewer.

It seems I have finally found a new money sink after it doesn’t really make much sense to buy modern multi graphics card setups anymore…

Ah yes, let’s talk about price: If you wanna become a figfag, it’s seriously gonna cost you. Shit’s expensive when it’s high quality and very often you’d have to import from Japan from shops like [AmiAmi], [Solaris Japan] or maybe eBay where US American or European stores don’t carry what you want. This complete set here can be obtained for slighty short of 400€ if you’re careful enough to pick the right sellers. 450€ with fast and safe EMS shipping for a large parcel like this one.

Then there is customs tax, which will NOT apply at least for the EU, as the TARIC code of collectors figures [9703] lists them as being tax free if newer than 50 years. There is still VAT though, which amounts to 20% here.

So for 450€ (yes, shipping is included in the calculation) you’d have to pay an additional 10€ customs handling fee plus 90€ VAT making it a 550€ total. Wohoo, right?

So there you go! This will bleed me dry, but somehow I can’t manage to regret it! ;)

Edit: Ah yeah, before I forget it, there are actually quite a few nice songs in this series, some of which I’m regularly listening to. Here is a quick list of some of my favorites, links to YouTube:

And many more of course…

Jun 072015
 

Kung Fury: Street Rage logoSo after the release of that crazy crowdfunded (and free of charge) movie [Kung Fury], there is also a game! Now that was fast. Made by the Swedish game developers of [Hello There], the game is basically a clone of [One Finger Death Punch], as many gamers have already pointed out. Not that anybody seems to mind that – me included. It’s a superficially very simple 2-button street fighting game, where one button means “punch/kick/whatever to the left” and the other “punch/kick/whatever to the right”. Don’t let the seeming simplicity fool you though. There is more skill involved than you might think…

So let’s have a look at the intro of the game, which strongly resembles an 80s arcade machine style:

Kung Fury: Street Rage; That's our Hero!

Kung Fury: Street Rage; That’s our Hero!

So with the use of some Direct3D 9.0c shaders, the game simulates the look of an old CRT monitor, just like the arcade machines of old had! At the press of a button or after waiting for a bit we’re greeted with this:

Kung Fury: Street Rage - Insert Coin

Insert Coin!

Another button press and we can hear our virtual player throwing a coin into the machine, which gives us three lives (after being hit three times, we’d go down for good). And then, whenever any enemy approaches us from either side, you just press left or right to punch, kick, shoot or electrify the guy. It’s ok, they’re all Nazis anyway. We do this with our pals Barbarianna, Triceracop and Hackerman standing around in the background – all three as seen in the movie of course, just like all the enemies we’re beating up:

Kung Fury: Street Rage; Beat 'em up!

There are splatter effects even!

That screenshot is from the very beginning of the game, where we can only see our lowest-end Nazi foes. There are some Swedish Aryans too, which can take two hits, then that clone chick with Kung Fury essence infused into her, which needs a more advanced left/right combo to put down, and more. Like the kicking machine and the mysterious Ninja, all as seen in the movie. As long as you don’t miss too much (you have limited range) or get hit, you’ll build up a score bonus too. Not sure if there are more enemies than that, I haven’t really gotten that far yet.

Actually, I did reach a new High Score while doing those screenshots accidentally, leaving both chicks behind me, pretty neat:

Kung Fury: Street Rage; New High Score!

A new High Score!

Now Thor might still be doable, but Hackerman will be one tough nut to crack. I don’t think I’ll ever make it to the top though, the game is pretty damn hard. As it progresses, it starts speeding up more and more, and it’ll also throw more of the harder enemies at you, which will require quick reaction and sharp perception to get the combos right. “Just mash two buttons” may sound easy as said, but don’t underestimate it! Like with “One Finger Death Punch”, only the most skillful players will have a chance to reach the top!

When you’ve got enough, just press <Esc> (on the PC), and you’re asked whether you really want to quit. In an interesting way:

Kung Fury: Street Rage; Quitting the game.

Quitting/bluescreening the game.

If you confirm to quit the game, you’ll get another shader-based CRT effect thrown in:

Kung Fury: Street Rage; Quitting the game

It’s shutting down…

I haven’t really managed to play this for more than 5 minutes in a row, which sounds like very little, but this game is extremely fast-paced, so I can’t take much more in one go. ;) It’s quite a lot of fun though, and while not as sophisticated as “One Finger Death Punch”, it’s awesome in its own right, given the Kung Fury cheesiness, the CRT look and the chiptune-like soundtrack of the game.

The game is available in both paid and partially also free editions on several platforms now, and while I’ve read that the free versions do have ads, the paid ones definitely don’t, as I can vouch for on the PC platform at least. So here are the links:

  • [PC version] @ Steam for 1.99€ / $2.50. Supports >=Windows XP, >=MacOS X 10.6 and SteamOS plus regular Linux on x86_32/x86_64.
  • [PC+ARM version] @ Windows Store for $2.29. Supports Windows >=8.0 on x86_32/x86_64 and ARM architectures.
  • [Android version] @ Google Play for free or for 2.46€ with ads removed. Also available as a [separate APK file]. Supports Android >=2.0.1.
  • [iOS version] @ iTunes for free or for $1.99 with ads removed. Supports iOS >=6.0 on the iPhone 5/6, iPad and iPod Touch.

Now if you’ll excuse me, I’ll take another shot at number 3! :)