Jul 152016
 

H.265/HEVC logoSince I’ve started to release x265 binaries for Windows XP / XP x64 (and above), I’ve started to take interest in how it’s performance has developed over time. When looking back on x264, we can see that the encoders’ performance has always gradually improved with more and faster assembly code, optimizations for new CPUs’ instruction set extensions (think AMD FMA4, SSE4a or Intel AVX/AVX2) and so on. Over many years x264 has become a ton faster, as you can also see when comparing an old x264 v0.107.1745 (white results) with newer ones (red results) for the same CPUs in the [x264 benchmark].

So, x265 is much newer, but still, it’s been around for a few years now – since 2013 to be more precise – so I’d like to take a look at its performance trends using the options I typically apply for transcoding animated content. You can find the encoding settings and other information about the test below.

Note that I don’t compile every revision of x265, so I can compare only a few, namely the ones I chose to [release] periodically, excluding the new 2.0+2, which I haven’t released yet (waiting a bit more for a release). Here we go:

x265 performance trends across versions, 2016-07-15

x265 performance trends across versions, state 2016-07-15

Note that this runtime graph is inverted, in the sense that “higher = better”. Version 1.7 was the first which could actually encode using the options of my choice, older versions don’t understand all of them and are not comparable in my case because of that. We start off with pretty bad performance and then we get an ample boost with the earlier 1.9 versions.

From 1.9+15 to 1.9+141 we can see a gradual performance increase, as expected from continued development and optimization. Naturally, 8-bits per color channel is fastest, as it makes use of a lot of 8-bit arithmetic internally. For higher bit depths (10 and 12 bits per channel, or 30 and 36 bits per pixel respectively) the internal arithmetic is boosted to a 16 bit precision, resulting in better outputs for finer gradients. This costs performance of course.

As expected, 10 and 12 bit runtimes are relatively close in terms of speed with 8 bit being quite far ahead.

Now the most surprising thing is the nose dive we take from 1.9+141 to 1.9+200. I have no idea what happened here?! Did they fix a major bug? Or did some performance-critical options change in the veryslow preset I’m using? I have no idea. But to put is in numbers easier to understand: For 8 bit, my test encode went from a runtime of 30:39.312 (1.9+141) to 41:20.296 (1.9+200)! Ah, the time format being MM:SS.sss, M = minutes, S = seconds and s = milliseconds. That’s almost -35%! It’s less pronounced for the higher bit depths with -25% for 10 bits and -24% for 12 bits, but that’s still significant. Maybe I shouldn’t have deleted the output data, might have been useful to look at the H.265 stream headers.

Well, from there on out we continue to see a gradual performance increase again, in a steady and stable fashion. But what happened between 1.9+141 and 1.9+200? I don’t know. Something major must have changed, I just don’t know what it was exactly…

Maybe somebody can enlighten me a bit, so here are the options used, right from the benchmarking script:

expand/collapse source code
  1. @ECHO OFF
  2.  
  3. :: ###################################################################################
  4. :: #                                                                                 #
  5. :: #  Please note, that command lines passed to timethis.exe may not be longer than  #
  6. :: #  1024 characters including expanded variables, so we need to keep it short      #
  7. :: #  enough. Some of the options passed to x265 may already be superflous due to    #
  8. :: #  being included in the veryslow preset, but I did not really double-check that. #
  9. :: #  Instead, I kept it just short enough by using shorter file names instead.      #
  10. :: #                                                                                 #
  11. :: #  Where to get the files:                                                        #
  12. :: #    * x265.exe     : http://wp.xin.at/x265-for-winxp-and-winxp-x64               #
  13. :: #    * avconv.exe   : http://wp.xin.at/x265-for-winxp-and-winxp-x64               #
  14. :: #    * colorecho.exe: http://wp.xin.at/archives/3064                              #
  15. :: #    * timethis.exe : https://support.microsoft.com/en-us/kb/927229               #
  16. :: #                                                                                 #
  17. :: #  GPL v3 license for this scripts code, colorecho.exe, parts of avconv.exe and   #
  18. :: #  the CygWin companion libraries for avconv.exe:                                 #
  19. :: #    * https://www.gnu.org/licenses/gpl-3.0.en.html                               #
  20. :: #                                                                                 #
  21. :: #  GPL v2 license for x265.exe:                                                   #
  22. :: #    * https://www.gnu.org/licenses/old-licenses/gpl-2.0.html                     #
  23. :: #                                                                                 #
  24. :: #  LGPL v3 license for other parts of avconv.exe:                                 #
  25. :: #    * https://www.gnu.org/licenses/lgpl-3.0.html                                 #
  26. :: #                                                                                 #
  27. :: #  NT Resource Kit license for timethis.exe:                                      #
  28. :: #    * https://enterprise.dejacode.com/license_library/Demo/ms-nt-resource-kit    #
  29. :: #                                                                                 #
  30. :: #  The x265 encoder  : http://x265.org                                            #
  31. :: #  The libav         : https://libav.org                                          #
  32. :: #  The Cygwin project: https://www.cygwin.com                                     #
  33. :: #                                                                                 #
  34. :: ###################################################################################
  35.  
  36. :: First round, 8 bits per channel color depth (MAIN profile), 8 bit arithmetic:
  37. FOR %%I IN (1.7-8b 1.9+15 1.9+108 1.9+141 1.9+200 1.9+210 1.9+230) DO .\colorecho.exe ^
  38.  ""Testing v%%I, 8 bits..."" 10 & .\timethis.exe ""echo x265 v%%I-8b & .\avconv.exe -r ^
  39.  24000/1001 -i input.h264 -f yuv4mpegpipe -pix_fmt yuv420p -r 24000/1001 - 2>NUL | ^
  40.  .\x%%I.exe - --y4m -D 8 --fps 24000/1001 -p veryslow --open-gop --ref 6 --bframes ^
  41.  16 --b-pyramid --bitrate 2000 --rect --amp --aq-mode 3 --no-sao --qcomp 0.75 ^
  42.  --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0 --rdoq-level 1 ^
  43.  --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 --pass 1 ^
  44.  --slow-firstpass --stats %%I-8b.stats --sar 1 --range full -o %%I-8b-p1.h265 2>NUL & ^
  45.  .\avconv.exe -r 24000/1001 -i input.h264 -f yuv4mpegpipe -pix_fmt yuv420p -r ^
  46.  24000/1001 - 2>NUL | .\x%%I.exe - --y4m -D 8 --fps 24000/1001 -p veryslow ^
  47.  --open-gop --ref 6 --bframes 16 --b-pyramid --bitrate 2000 --rect --amp --aq-mode 3 ^
  48.  --no-sao --qcomp 0.75 --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0 ^
  49.  --rdoq-level 1 --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 ^
  50.  --pass 2 --stats %%I-8b.stats --sar 1 --range full -o %%I-8b-p2.h265 2>NUL"" 1> ^
  51.  .\results-%%I-8b.txt 2> .\timethis-errorlog-%%I-8b.txt
  52.  
  53. :: Second round, 10 bits per channel color depth (MAIN10 profile), 16 bit arithmetic:
  54. FOR %%J IN (1.7-10b 1.9+15 1.9+108 1.9+141 1.9+200 1.9+210 1.9+230) DO .\colorecho.exe ^
  55.  ""Testing v%%J, 10 bits..."" 10 & .\timethis.exe ""echo x265 v%%J-10b & .\avconv.exe -r ^
  56.  24000/1001 -i input.h264 -f yuv4mpegpipe -pix_fmt yuv420p -r 24000/1001 - 2>NUL | ^
  57.  .\x%%J.exe - --y4m -D 10 --fps 24000/1001 -p veryslow --open-gop --ref 6 --bframes ^
  58.  16 --b-pyramid --bitrate 2000 --rect --amp --aq-mode 3 --no-sao --qcomp 0.75 ^
  59.  --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0 --rdoq-level 1 ^
  60.  --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 --pass 1 ^
  61.  --slow-firstpass --stats %%J-10b.stats --sar 1 --range full -o %%J-10b-p1.h265 2>NUL ^
  62.  & .\avconv.exe -r 24000/1001 -i input.h264 -f yuv4mpegpipe -pix_fmt yuv420p -r ^
  63.  24000/1001 - 2>NUL | .\x%%J.exe - --y4m -D 10 --fps 24000/1001 -p veryslow ^
  64.  --open-gop --ref 6 --bframes 16 --b-pyramid --bitrate 2000 --rect --amp --aq-mode 3 ^
  65.  --no-sao --qcomp 0.75 --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0 ^
  66.  --rdoq-level 1 --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 --pass ^
  67.  2 --stats %%J-10b.stats --sar 1 --range full -o %%J-10b-p2.h265 2>NUL"" 1> ^
  68.  .\results-%%J-10b.txt 2> .\timethis-errorlog-%%J-10b.txt
  69.  
  70. :: Second round, 12 bits per channel color depth (MAIN12 profile), 16 bit arithmetic:
  71. FOR %%K IN (1.7-12b 1.9+15 1.9+108 1.9+141 1.9+200 1.9+210 1.9+230) DO .\colorecho.exe ^
  72.  ""Testing v%%K, 12 bits"" 10 & .\timethis.exe ""echo x265 v%%K-12b & .\avconv.exe -r ^
  73.  24000/1001 -i input.h264 -f yuv4mpegpipe -pix_fmt yuv420p -r 24000/1001 - 2>NUL | ^
  74.  .\x%%K.exe - --y4m -D 12 --fps 24000/1001 -p veryslow --open-gop --ref 6 --bframes ^
  75.  16 --b-pyramid --bitrate 2000 --rect --amp --aq-mode 3 --no-sao --qcomp 0.75 ^
  76.  --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0 --rdoq-level 1 ^
  77.  --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 --pass 1 ^
  78.  --slow-firstpass --stats %%K-12b.stats --sar 1 --range full -o %%K-12b-p1.h265 2>NUL ^
  79.  & .\avconv.exe -r 24000/1001 -i input.h264 -f yuv4mpegpipe -pix_fmt yuv420p -r ^
  80.  24000/1001 - 2>NUL | .\x%%K.exe - --y4m -D 12 --fps 24000/1001 -p veryslow ^
  81.  --open-gop --ref 6 --bframes 16 --b-pyramid --bitrate 2000 --rect --amp --aq-mode 3 ^
  82.  --no-sao --qcomp 0.75 --no-strong-intra-smoothing --psy-rd 1.6 --psy-rdoq 5.0 ^
  83.  --rdoq-level 1 --tu-inter-depth 4 --tu-intra-depth 4 --ctu 32 --max-tu-size 16 --pass ^
  84.  2 --stats %%K-12b.stats --sar 1 --range full -o %%K-12b-p2.h265 2>NUL"" 1> ^
  85.  .\results-%%K-12b.txt 2> .\timethis-errorlog-%%K-12b.txt
  86.  
  87. .\colorecho.exe "Benchmarks completed, cleaning up..." 10
  88.  
  89. :: Removing output and statistics files:
  90. del /Q *p*.h265 *stats*
  91.  
  92. .\colorecho.exe "All done, results are to be found in the results-*.txt files!" 10

So if I missed some critical changes that happened in between 1.9+141 and 1.9+200, please let me know! Oh, and here are the exact system specifications, in case it matters (it probably doesn’t):

  • Intel Xeon X5690 3.33GHz (SSE4.2 is max, no AVX), running at an all-core turbo of 3.6GHz
  • 24GB DDR-III/1066 10-10-10 2T
  • X58 chipset
  • Windows XP Professional x64 Edition SP2 with all Server 2003 R2 x64 updates

I guess I’ll keep doing the performance evaluations from here on out just to see how the encoder evolves over time, performance-wise… And maybe I’ll redo 1.9+141 and one of the newer versions and parse the stream headers to see if the effective encoding options differ anywhere after all. If yes, I’ll update this post!

Jun 092016
 

The InternetAnd no, it’s not because of that [failing drive] in the server, but because another Wednesday’s coming up, and it’s maintenance time again, says my internet service provider. I don’t know what they’re doing really, but it seems they have to fix something like every other month now. Well, whatever. The time frame is the same as last time, but instead of several short offline periods, we should be expecting a single longer one this time. So:

Wed, 2016-06-15, 01:00 am – 06:00 am UTC+1: A downtime of ~2h duration is to be expected within this time window!

When I’m ready to replace the breaking hard drive, I’ll let you know in advance as well. Maybe. Depends on my mood. :roll:

Jun 032016
 

H.265/HEVC logoAnd here’s another x265 build for Windows XP and Windows XP x64, following [1.9+141]. As usual, these work on modern versions of Windows just as well. Again, built with Microsoft Visual Studio 2010 SP1 and tested for correct encodes for 8-bit, 10-bit and 12-bit color depth. The 8-bit test has been done using the x86_32 version, the 10- & 12-bit tests has been done with the x86_64 version. I’m not running complicated test suits on this, just a simple encode with manual output checking.

Here is the software for 32-bit and 64-bit systems:

As usual, the builds depend on the Microsoft Visual C++ 2010 runtime which you can download from Microsoft [for 32-bit systems] and [for 64-bit systems] if you don’t have it already.

This time around, it’s a pure binary release, giving you the x265.exe and libx265.dll. I think I’m gonna keep it that way. It’s meant for users, not developers anyway.

I’m thinking I might create a project page for this, so that all releases get consolidated on a single spot, that’d probably better than creating a new post for each and every build I’m pushing out. If I’m gonna do that, links to it will be added to each post regarding information about how to build x265 for WinXP+, and also to all binary release posts.

Such a page could also give you an avconv release on the spot, so you can work with all kinds of video input to your liking, given that x265 can only accept raw YUV video by itself. Just need to build a 32-bit version of libav as well then.

Oh well, have fun! :)

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.

Jun 022016
 

KERNEL_STACK_INPAGE_ERROR logoRecently, this server (just to remind you: an ancient quad Pentium Pro machine with SCSI storage and FPM DRAM) experienced a 1½ hour downtime due to a KERNEL_STACK_INPAGE_ERROR bluescreen, stop code 0x00000077. Yeah yeah, I’m dreaming about running OpenBSD on XIN.at, but it’s still the same old Windows server system. Bites, but hard to give up and/or migrate certain pieces of software. In any case, what exactly does that mean? In essence, it means that the operating systems’ paged pool memory got corrupted. So, heh?

More clearly, either a DRAM error or a disk error, as not the entire paged pool needs to actually be paged to disk. The paged pool is swappable to disk, but not necessarily swapped to disk. So we need to dig a bit deeper. Since this server has 2-error correction and 3-error reporting capability for its memory due to IBM combining the parity FPM-DRAM with additional ECC chips, we can look for ECC/parity error reports in the servers’ system log. Also, disk errors should be pretty apparent in the log. And look what we’ve got here (The actual error messages are German even though the log is being displayed on a remote, English system – well, the server itself is running a German OS):

Actually, when grouping the error log by disk events, I get this:

54 disk errors in total - 8 of which were dead sectors

54 disk errors in total – 8 of which were medium errors – dead sectors

8 unrecoverable dead sectors and 46 controller errors, starting from march 2015 and nothing before that date. Now the actual meaning of a “controller error” isn’t quite clear. In case of SCSI hardware like here, it could be many things. Starting from firmware issues over cabling problems all the way to wrong SCSI bus terminations. Judging from the sporadic nature and the limited time window of the error I guess it’s really failing electronics in the drive however. The problems started roughly 10 years after that drive was manufactured, and it’s an 68-pin 10.000rpm Seagate Cheetah drive with 36GB capacity by the way.

So yeah, march 2015. Now you’re gonna say “you fuck, you saw it coming a long time ago!!”, and yeah, what can I say, it’s true. I did. But you know, looking away while whistling some happy tune is just too damn easy sometimes. :roll:

So, what happened exactly? There are no system memory errors at all, and the last error that has been reported before the BSOD was a disk event id 11, controller error. Whether there was another URE (unrecoverable read error / dead sector) as well, I can’t say. But this happened exactly before the machine went down, so I guess it’s pretty clear: The NT kernel tried to read swapped kernel paged pool memory back from disk, and when the disk error corrupted that critical read operation (whether controller error or URE), the kernel space memory got corrupted in the process, in which case any kernel has to halt the operating system as safe operation can no longer be guaranteed.

So, in the next few weeks, I will have to shut the machine down again to replace the drive and restore from a system image to a known good disk. In the meantime I’ll get some properly tested drives and I’m also gonna test the few drives I have in stock myself to find a proper replacement in due time.

Thank god I have that remote KVM and power cycle capabilities, so that even a non-ACPI compliant machine like the XIN.at server can recover from severe errors like this one, no matter where in the world I am. :) Good thing I spent some cash on an expensive UPS unit with management capabilities and that KVM box…

May 132016
 

3dfx logoI had actually meant to post this upon release, but forgot. I’ve now been reminded on the forums that I should maybe do this, even if it isn’t really a match for this weblog, considering the target audience, language-wise. Well, whatever. Somewhere in 2014, a user named [OutOfRange]German flag from the German 3dfx forum [VoodooAlert]German flag had begun to write a German transcript for an interview that the [Computer History Museum] had conducted with the founders of the now-long-gone PC 3D graphics pioneer 3dfx Interactive. This is especially interesting stuff for PC gamers and hardware enthusiasts of the mid-90s to the early 2000s. I allows quite an insight into both the technological and business sides of a now-legendary 90s chip startup company.

Also, those guys are really nice people as well it seems. :)

It had been requested to have some kind of text file-based translation to read while watching the video by some guys who can’t speak English, and OutOfRange had begun to translate the video and write that, with some minor passages done by another user called [Kaitou]German flag. Ultimately, when I picked up the project, I (and others) had the idea of making a German fansub out of that. So together with OutOfRange, who supplied me with the latest versions of his transcript on-the-go, I started to learn about how to do (very) simple ASS/SSA soft subtitling using [Subtitle Workshop] and just got to it. Early on, there was little or no color coding and very little formatting, so working on it looked like this:

The early on of subtitling the 3Dfx Oral History Panel

The early-on of subtitling the 3Dfx Oral History Panel, I translated as I got fed new bits and pieces by OutOfRange…

But it got better and better, colors got assigned to all the guys to differentiate them from each other better when several people were talking at once (you get used to the colors fast!), explanatory information was put to the top of the frame and slowly but surely, the German fansub of that 2½ hour interview started to take shape:

3dfx Oral History Panel Screenshot

The 3dfx founders talking about how the would never do CAD on their first 3D chip for PC gamers, known as the “3Dfx Voodoo Graphics”. From left to right: Gary Tarolli, Scott Sellers, Ross Smith and Gordon Campbell.

So, where are the files? Here they are (thanks fly out once more to OutOfRange, [CryptonNite]German flag and [Hutzeputz]German flag for helping out with download mirrors!):

The 3Dfx Oral History Panel in its german fansub:

Downloads:

Audio & video are © 2013 Computer History Museum
[original English transcript] (This fansub is not based on it!), [original web stream] [http://www.computerhistory.org] [Terms of use] Used with express permission!

The subtitles are licensed under the [CC BY-NC-SA 4.0].
CC BY-NC-SA 4.0

  • Initiator and main translator: OutOfRange
  • Co-translator: Kaitou
  • Editor & fansubber: GrandAdmiralThrawn (that would be myself)
  • [http://www.voodooalert.de]German flag

This release was made possible also because of the friendly help of a legal representative of the Computer History Museum who helped clear up how we can dual-license and re-release this video by ourselves. Note that if you wish to redistribute a modified version (!) of this by yourself, you’d need to get express permission from the Computer History Museum by yourself. If you wish to modify the fansub, you may redistribute the .ass files freely under the CC BY-NC-SA 4.0, but not the whole, remuxed video unless you have permission from the Computer History Museum!

In essence: You may not redistribute modified versions of audio & video without express permission from the creator, as their license is in essence something like the [CC BY-NC-ND].

As a final note, I’m not really a fansubber, so don’t expect any kind of professional quality here. Or something that you’d get from an actual fansubbing group. But for an amateurish sub, it should be quite decent. ;)

Have fun! :)

PS.: If you’re ever anywhere near Silicon Valley, California, and even if you’re just a tiny bit interested in computer technology and history, pay that museum a visit! It’s seriously awesome, they even have mainframes from the 60s, magnetic core memory panels from the 50s and more modern stuff as well. Ah, I remember stuff like that CRAY machine or the “Weapons Director” box,  really nice exhibits there!

Apr 292016
 

The InternetAnd here we go again… Wednesdays. Well, on Wednesday, 2016-05-04 my internet service provider will have to do some undefined maintenance again, and that’s supposed to be happening in between 01:00 – 06:00 am. According to my provider UPC, there will be several short periods of unavailability of service about 15 minutes long. Of course they’ll do everything as quickly and properly as possible as to not to interrupt their customers’ services too much – or so they say. So, once again:

Wed, 2016-05-04, 01:00 am – 06:00 am UTC+1 – Expect several short downtimes in that time frame!

Oh, and in case anyone noticed (nah, I know you didn’t…), sorry for that unannounced downtime on Thu, 2016-04-21. Should’ve been roughly from 03:00 pm – 07:00 pm UTC+1. This was done for two reasons:

  1. The WinSSL layer had broken down permanently (LsaSrv) due to a bug. When that happens, only a reboot can fix it. There is only one service relying on WinSSL instead of OpenSSL or GnuTLS, but it’s an important one that I do not wish to operate without a cryptography option, as it’s endangering the privacy of my users.
  2. The OS hard drive had shown signs of sectors becoming defective. This called for an analysis to see what areas of the file system had taken damage. Luckily, it only got some $I30 index files (deleted files still being referenced) and one unimportant IPCache.dat, which is just a local DNS cache file of a single service. Also, if the state would be recoverable, a full backup was in order.

So, the file system errors have been repaired, and defective blocks have been marked, restoring proper, consistent operation. Since the drive is no longer to be considered reliable enough, I decided to take the extra time to create a fresh full backup / system image of the operating systems’ and services’ current state, so when “C:” does die, I can restore without too much hassle. The last full backup was too old anyway, with a lot of important stuff already missing by now.

Got any flawlessly working U160/U320 68-pin SCSI drives >=36GB that you could part with? ;) If so, post in the comments, let me know how much you want for it. ;) And maybe don’t try to post in the time noted above. :)

Apr 222016
 

Sakura Trick - Haruka×Yuu logoBefore I say anything else or show you any photos; I would like to thank a certain Mr. Isohata, who happens to run [this eBay shop] called “Toys Glory” right here. He might not always provide the cheapest offers, but let me tell you this: That man delivers! Not only did he manage to surprise me by being able to get me a really rare, exclusive (and in the Western World: pretty much unobtainable) [Tokisaki Kurumi] version, no, he also managed to get me todays’ two little gems, which I couldn’t manage to find anywhere else anymore. And it didn’t take him longer than 48 hours to get his hands on them even – in a sealed state! Hell, I don’t know how he does that, but if you’re sitting in the Western world and you’re looking for something rare with no other options left… Just drop him a message, chances are that if anyone can get that rarity for you, it’s probably him! Oh, and his English is pretty good, best I’ve read corresponding with Japanese people, so no worries there!

Now, that I’m a fan of Yuri Anime (=”girls’ love”, sometimes also inappropriately called “shoujo ai”[1] in the West) is probably not exactly a secret anymore, but from my point of view, there just aren’t many good series in that department. Or let’s say… unobstructedly enjoyable ones. I should really prepare my top list for the genre, but it’ll take a while longer I guess. But to cut to the chase: If you’re looking for a really fluffy, kinda innocent/naïve slice-of-life Yuri Anime, look no further: There is only one. And that’s Sakura Trick / 桜Trick.

Sakura Kiss

You can probably guess where this is going…

I was always kinda disappointed by different figures from different Yuri Anime, because essentially, they’re never posable. And what good are they, if you can’t… uhm… combine them.

Also, it seems Anime released by the infamous [Studio Deen] aren’t seeing a lot of love from figure sculptors (because most of Deens’ series are really low quality), but recently they’ve been improving quite some. And Sakura Trick? Hell, it’s freaking beautiful. Especially if you own a pair of Yuri goggles. :roll:

But there ARE two figures from Sakura Trick after all – the two main characters – which fit the bill. Unfortunately they’re from Waves’ Beach Queens series (“Premium” branch in this case though), which surely aren’t my favorites. Reason? Well, dressing up any and every girl from random Anime in Bikinis just to show them off with as little fabric on their bodies as possible isn’t exactly my thing. But ok, in this case, it’s forgiven and forgotten! We’re talking about Sonoda Yuu × Takayama Haruka after all. ;)

Wave went through the trouble of making the heads on these exchangeable for posing purposes. That means they had to integrate plastic sockets into the heads to be able to connect the ball joint, because the two are made of quite hard polystone, not PVC. The material’s a kind of artificial stone made from polyurethane resin and stone aggregates to give it a porcelain-like feel to the touch. It doesn’t smell like PVC does, it’s supposed to allow for more refined detail in sculpting and you need to be careful – because it can shatter easily.

The scale on these is 1/10, not 1/8, so they’re rather tiny. Let’s have a look, now shall we?

As said, the sockets are pretty heavy and feel well made and all, but… they’re in the way as well. Because if you want to pose the two figures, eh, properly, the sockets won’t let you because they put too much distance between the two. But first things first, let’s change those heads:

Theeere we go. Yuu sure sports some nice sculpting around her belly! Well, there is a small flaw on her hand, but to the naked eye this is not too noticeable, so I’m fine with that. And now, as for the actual posing:

Aw, adorable.

Now, as for the detail level, it may not seem overly great, but consider the scale! 1/10 is quite a bit smaller than 1/8 after all. Ah, just see for yourself:

Sakura Trick - Haruka×Yuu size comparison

This is how a 1/10 scale figure compares to a Nendoroid and a 1/8 scale, both of which are Hirasawa Yui from K-On! Not counting the baseplates, the heights are (from left to right): 15.2cm / 5.98″, 9.8cm / 3.86″ and 18.5cm / 7.28″.

Well, in the end, those two were pretty expensive. They weren’t cheap at launch already, probably because they’re pretty niche after all, and I had to pay roughly twice the original price. It wasn’t breaking the bank or anything, but no matter the quality – rarity costs money. If you’re willing to go (and pay for) the extra mile when it comes to harder-to-get stuff, see paragraph 1. ;) If you’re actually in Japan, this should be much easier I guess, but from Europe or the US, options are limited after all.

Now, let me schedule that third rewatch of Sakura Trick… Because there’s no Yuri like this one…

[1] Shoujo/Shōjo (jap. 少女) mostly means “little girl” or “young girl”. The term “shoujo ai” was meant to just mean “girls love” in the western world, but this is easily mistakable, as the term is being understood as “pedophilia” in Japan. My personal assumption being that it just means something like “love for really young girls”. Saying that you like “shoujo ai” to the wrong person is one mistake you don’t wanna make, ever!

Apr 192016
 

H.265/HEVC logoLike I said, I’ll keep doing these. Following version [1.9+108], here comes another build of the x265 encoder for Windows XP+ and Windows XP x64/Server 2003 x64+, this time it’s version 1.9+141. I’m not sure for how long the developers at Multicoreware are going to keep up support for NT 5.1/5.2 based operating systems, but for as long as they do, I’ll keep releasing builds for the old MS operating systems. Just keep in mind that I’m not running automated build & test systems, so I’m going to release selected binaries every 1-2 months or so. If you need a specific version, please just request it (or try and build it yourself, see previous posts).

Whenever Multicoreware does drop support I’ll still continue as long as it’s easily patchable. We can’t be sure of anything though, they’ve dropped deep color support (10-bit/12-bit per color channel) on 32-bit x86 platforms before, so…

Well, here is 1.9+141:

Once more, this has been built with Microsofts’ VisualStudio 2010 SP1 + yasm 1.3.0, and tested doing a 2-pass encode & quick output video verification for all color depths. Requires the MS VC++ 2010 runtime, you can get it here: [32-bit version], [64-bit version].

Apr 192016
 

Banpresto: Hanayamata Kyun-charas - logoAnd while I’m waiting for a real rarity, here we are with more Anime Chibi figures in the meantime! You want more, right? Yeah, chances are pretty high you don’t, but here they are anyway. Amongst Moeblob Anime series (“cute girls doing cute things” as they say in the US), there are a few with either no or less high-profile merchandise available, and the Anime Hanayamata is one example of them. Not the worst of all (think Gochuumon), but yeah.

Not that the series should be that good actually, it’s extremely formulaic in nature and is comprised of characters made from 100% standard templates. Some of those shows are really uninteresting, but some I still like a lot for no apparent reason other than… Moe infection? Or maybe it’s really just well made somehow.

Well, whatever, I wanted some small chibis of the main cast, but alas, good old Goodsmile Company hasn’t made any Nendoroids of them, so what now?

Luckily those ‘roids have been so ridiculously successful, that several companies started to try and come up with competitive products – one of them being Banpresto with their “Kyun-Chara” series. Besides wanting the Hanayamata characters in PVC form, it’s also an opportunity to compare them with the current top dog in the market. Let’s see (CTRL+click to enlarge, as always)…

Banpresto: Hanayamata Kyun-charas - whole group

The main cast, from left to right: Machi, Naru, Hana, Yaya and Tami – The names alone already radiate Moe.

So what’s this even about? Aside from the typical coming-of-age and all-girls friendship/bonding stuff, it’s focused on some kind of modern freestyle dance called [Yosakoi], which combines classical Japanese dance movements with modern music, mostly JPop stuff I guess. I found that intriguing as I’d never heard of it before, and it wasn’t the typical school band or Idol stuff. Being artistically interesting (animation, drawing style etc.) I got kind of hooked. “Kind of” probably being an understatement… :roll:

Let’s look at the individual characters before the quick Kyun-Chara vs. Nendoroid comparison:

Cutesy, flowery stuff it is. Hana’s one of the two main characters, and by far the more lively one. Also: The classic “Western, Aryan exchange student” (yeah, I used that word just now, you know why, Japan!). I’m not going to comment on my impressions regarding quality before the Nendoroid comparison, but let’s just say, there’s good and bad stuff. Let’s continue for now:

And there we have our wallflower, Sekiya Naru. If you’re vaguely familiar with this type of show, I won’t need to say much more than that, just one thing: Her name is also a part of “Naruko”, the wooden clappers they’re holding. Originally used to chase away birds from fields, it’s now a musical accessory. Next girl:

Now if there ever was a run-of-the-mill Tsundere (Search for it on the web, if you don’t know the lingo, and if you really want to know), here she is. The rose theme probably fits with her being the jealous type as well, even if the color doesn’t match perfectly. But we already got a girl with a yellow theme, she’ll come last… First comes Miss Princess:

Despite the Lily (=Yuri) sometimes being a symbol for love between girls, this is not the case here. Nishimikado Tami is just the groups’ typical well-mannered, calm and introverted rich girl. Like all five of them, she’ll have to overcome one “drama” in the course of the series. That’s, if you can even call it that. It’s an 98% lighthearted show after all. And now, for the last one:

Tokiwa Machis’ the most stiff and stern of the five, and she’s late to the game as well, so not much time for her to soften up. She doesn’t all turn fluffy even at the end, which is probably a good thing. While she’s another Tsundere, her character is slightly less formulaic than Yaya.

How Hanayamata managed to take all this run-of-the-mill stuff that has been done to death for hundreds of times and still make it unbelievably enjoyable is still beyond me. Maybe it’s really the artwork. Or the music. Or the writing (nah, can’t be, lol). Whatever, it’s absolutely nice feel-good stuff. If you can take several kilograms of pink sugar per episode that is. ;)

Ah, I wanted to compare the little figures to the #1 in the field, GSCs’ Nendoroids, right? Let’s pick two pairs and have a quick look:

First of all, I thought the Kyun-Charas would be smaller. 7cm they said, but it’s more like 8.5cm (3.35″). They’re more petite however, having slimmer legs, slimmer waists etc, so in essence the are deformed more strongly. Also, they’re not posable like Nendoroids, so what you see here is all you get. Legs can be removed, but they don’t all have the same joints, so exchanging anything but heads is impossible. They’re not made for that.

Now, let’s talk quality: There are two things where Banpresto is still clearly behind. First, the deburring of the plastic. Parts of the Kyun-Charas will lack proper deburring and thus have slightly frayed edges. That just looks a bit cheap, so well-rounded, smooth edges are a must to achieve a flawless look.

The second are the color gradients when it comes to hair. Naru doesn’t seem to even have any. Machi does, but as you can see it’s pretty inferior to the Nendoroids, even the early ones.

The faces are ok however, definitely up to the level of GSC. And the clothes even surpass the Nendoroids I own, that’s a really good level of detail. So… it’s a mixed bag. Some parts are top-notch, while others are still a bit lacking, even if we don’t consider the non-posable character of Kyun-Charas.

So, if there were ‘roids, I’d probably have bought those instead. But the Kyun-Charas aren’t too shabby either. Just don’t expect them to use up less space than Nendoroids like I did, they’re almost equal in that department.

Aaand the next ones to appear on stage are some really hard-to-get specimens, think “Yuri”. If you like that, you may wish to check back…

Apr 082016
 

H.265/HEVC logoPreviously, I have shown you [how to compile x265 on Windows] using Microsoft Visual Studio 2010 in a way that results in binaries compatible with Windows NT 5.1/5.2, or in other words: Windows XP, XP x64 and Windows Server 2003. And while that works for most purposes, today I’d like to show you how to build an actual multilib binary, that can handle all three color bit depths supported by x265, the standardized 8- and 10-bit (MAIN and MAIN10 profiles) as well as 12-bit (MAIN12 profile). With that, it’s all in one exe instead of three. As before though, multilib x265 is only supported on 64-Bit Windows. But first, once again…

1.) Giving you the binaries

There were a lot of improvements since the last version I published back in February of course, also performance-wise. So here’s the current version from Multicoreware for both 32-bit and 64-bit Windows, compiled with MSVC 2010 SP1 and yasm 1.3.0. This requires the Microsoft Visual C++ 2010 runtime to work, see previous article:

This time around, the binaries have been tested as well! On regular 32-bit Windows XP, only fundamental binary compatibility was tested. However, all versions, so the 32-Bit one and the 64-Bit multilib ones have been ran through a 2-pass ABR encoding test with output verification for 8-bit color depth (32- & 64-bit) as well as 10- and 12-bit color depths (64-bit only) on Windows XP Professional x64 Edition using the following command line (see previous post for details):

avconv -r 24000/1001 -i input.h264 -f yuv4mpegpipe -pix_fmt yuv420p -r 24000/1001 - 2>NUL^ 
 | .\x265.exe - --y4m -D 10 --fps 24000/1001 -p veryslow^
 --open-gop --ref 6 --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 -o pass1.h265 & avconv^
 -r 24000/1001 -i input.h264 -f yuv4mpegpipe -pix_fmt yuv420p -r 24000/1001 - 2>NUL^
 | .\x265.exe - --y4m -D 10 --fps 24000/1001 -p veryslow --open-gop --ref 6^
 --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 -o pass2.h265

Needless to say, they should work fine on Windows Vista/7/8/8.1/10/Server 2008/Server 2012/HS 2007/HS 2011 as well.

From time to time, I’ll release new binaries, so you might wanna check back every few months or so, if you’re interested. You can also request a build in the comments if you’re growing impatient and need a specific version more quickly because of some bugfix / feature improvement in x265.

2.) Compiling an XP/2003-compatible x265 multilib binary yourself

First, please look at the previous article I linked to in the beginning, point 2. You need the software prerequisites listed in 2a and you might still wish to read through 2b to understand some of the stuff better. You don’t need to actually run any of the commands shown there though.

Now, the multilib build is done a bit differently from the rest, as everything is scripted, so this is 100% command line work, no graphical cmake, no running the full Visual Studio IDE. Usually, with all software in place, sitting in the root directory of the x265 source tree, all you need to do is to go to build\vc10-x86_64\ and run ./multilib.bat. This won’t give us an XP/2003-compatible binary however, and the reason lies within the build script multilib.bat, here is the stock version:

expand/collapse source code (multilib.bat)
  1. @echo off
  2. if "%VS100COMNTOOLS%" == "" (
  3.   msg "%username%" "Visual Studio 10 not detected"
  4.   exit 1
  5. )
  6.  
  7. call "%VS100COMNTOOLS%\..\..\VC\vcvarsall.bat"
  8.  
  9. @mkdir 12bit
  10. @mkdir 10bit
  11. @mkdir 8bit
  12.  
  13. @cd 12bit
  14. cmake -G "Visual Studio 10 Win64" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON
  15. if exist x265.sln (
  16.   MSBuild /property:Configuration="Release" x265.sln
  17.   copy/y Release\x265-static.lib ..\8bit\x265-static-main12.lib
  18. )
  19.  
  20. @cd ..\10bit
  21. cmake -G "Visual Studio 10 Win64" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF
  22. if exist x265.sln (
  23.   MSBuild /property:Configuration="Release" x265.sln
  24.   copy/y Release\x265-static.lib ..\8bit\x265-static-main10.lib
  25. )
  26.  
  27. @cd ..\8bit
  28. if not exist x265-static-main10.lib (
  29.   msg "%username%" "10bit build failed"
  30.   exit 1
  31. )
  32. if not exist x265-static-main12.lib (
  33.   msg "%username%" "12bit build failed"
  34.   exit 1
  35. )
  36. cmake -G "Visual Studio 10 Win64" ../../../source -DEXTRA_LIB="x265-static-main10.lib;x265-static-main12.lib" -DLINKED_10BIT=ON -DLINKED_12BIT=ON
  37. if exist x265.sln (
  38.   MSBuild /property:Configuration="Release" x265.sln
  39.   :: combine static libraries (ignore warnings caused by winxp.cpp hacks)
  40.   move Release\x265-static.lib x265-static-main.lib
  41.   LIB.EXE /ignore:4006 /ignore:4221 /OUT:Release\x265-static.lib x265-static-main.lib x265-static-main10.lib x265-static-main12.lib
  42. )
  43.  
  44. pause

So I took all the options from the files generated by the original cmake when doing the normal build, and added them to the script to ensure our output binaries would be XP-compatible. This is the fixed build script:

expand/collapse source code (multilib.bat, patched for XP/2003)
  1. @echo off
  2. if "%VS100COMNTOOLS%" == "" (
  3.   msg "%username%" "Visual Studio 10 not detected"
  4.   exit 1
  5. )
  6.  
  7. call "%VS100COMNTOOLS%\..\..\VC\vcvarsall.bat"
  8.  
  9. @mkdir 12bit
  10. @mkdir 10bit
  11. @mkdir 8bit
  12.  
  13. @cd 12bit
  14. cmake -DCMAKE_BUILD_TYPE="Release" -DCMAKE_CONFIGURATION_TYPES="Release" -G "Visual Studio 10 Win64" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DWINXP_SUPPORT=ON -DENABLE_SHARED=OFF -DENABLE_CLI=OFF -DMAIN12=ON
  15. if exist x265.sln (
  16.   MSBuild /property:Configuration="Release" x265.sln
  17.   copy/y Release\x265-static.lib ..\8bit\x265-static-main12.lib
  18. )
  19.  
  20. @cd ..\10bit
  21. cmake -DCMAKE_BUILD_TYPE="Release" -DCMAKE_CONFIGURATION_TYPES="Release" -G "Visual Studio 10 Win64" ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DWINXP_SUPPORT=ON -DENABLE_SHARED=OFF -DENABLE_CLI=OFF
  22. if exist x265.sln (
  23.   MSBuild /property:Configuration="Release" x265.sln
  24.   copy/y Release\x265-static.lib ..\8bit\x265-static-main10.lib
  25. )
  26.  
  27. @cd ..\8bit
  28. if not exist x265-static-main10.lib (
  29.   msg "%username%" "10bit build failed"
  30.   exit 1
  31. )
  32. if not exist x265-static-main12.lib (
  33.   msg "%username%" "12bit build failed"
  34.   exit 1
  35. )
  36. cmake -DCMAKE_BUILD_TYPE="Release" -DCMAKE_CONFIGURATION_TYPES="Release" -G "Visual Studio 10 Win64" ../../../source -DWINXP_SUPPORT=ON -DEXTRA_LIB="x265-static-main10.lib;x265-static-main12.lib" -DLINKED_10BIT=ON -DLINKED_12BIT=ON
  37. if exist x265.sln (
  38.   MSBuild /property:Configuration="Release" x265.sln
  39.   :: combine static libraries (ignore warnings caused by winxp.cpp hacks)
  40.   move Release\x265-static.lib x265-static-main.lib
  41.   LIB.EXE /ignore:4006 /ignore:4221 /OUT:Release\x265-static.lib x265-static-main.lib x265-static-main10.lib x265-static-main12.lib
  42. )
  43.  
  44. pause

You can just rename your original script for backup and put the fixed code in its place, build\vc10-x86_64\multilib.bat, then run it on the command line. If all the required tools are present, it will compile a 12-bit library, then a 10-bit library (both static) and finally an 8-bit binary that will have the other two libraries statically linked in. The final x265.exe can then be found in build\vc10-x86_64\8bit\Release\. To check whether it’s the real thing, look for the bitness by running .\x265.exe --version while sitting in that folder on the command line. You should see something like this:

x265 multilib binary

A x265 multilib binary shows that it’s “8-bit+10-bit+12-bit”

Per-color-channel bitness can be defined with x265s’ command line option -D. So that’d be -D 8, -D 10 or -D 12. Note that only 8- and 10-bit are part of the official Blu-Ray UHD/4k specification however.

3.) A side note

In case you’re new to this, you might not get why “8-bit” and “10-bit” etc. Aren’t color spaces supposed to be 16-bit, 24-bit, 32-bit etc.? Well, it seems that in the world of video processing, people don’t refer to whole color space bitness, but rather individual color channel bitness. So with three channels (red, green, blue for instance), you’d have 8/10/12 bits per channel, so that’s 24-, 30- and 36-bit total, or 16.7 million, 1 billion and 64 billion colors.

The more important part – and the reason why nobody encodes to 12-bit – is the internal arithmetic precision of x265 though (same applies to x264). At 8-bit color depth, arithmetic precision is also at 8-bits. When you hop over to 10-bit, you can’t use 8-bit operations and data types any longer, so everything is done at 16-bit precision. This makes the code slower, but also more efficient in preserving color gradients. Since 10-bit H.265/HEVC is officially a part of Blu-Ray UHD/4k, this would be the sweet spot, unless you’re dealing with devices too slow to play it.

Going to 12-bit won’t boost the precision further, it just gives you more colors, that most of today’s displays won’t be able to show anyway. Not much benefit.

So that’s that.

Have fun! :)

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.