May 312017
 

HakuNeko logo1.) What for?

Usually, porting my favorite manga ripper [HakuNeko] would involve slightly more exotic target platforms like [FreeBSD UNIX]. This changed with version 1.4.2 however, as this version – the most current at the time of writing – would no longer compile on Windows machines due to some issues with its build toolchain. And that’s the most common platform for the tool!

This is what the lead developer had to say about the issue while even suggesting the use of [FMD] instead of HakuNeko on Windows:

“The latest release does not compile under windows due to some header include contradictions of sockets […]”
    -in a [comment] to HakuNeko ticket #142 by [Ronny Wegener], HakuNeko project leader

Normally I wouldn’t mind that much and keep using 1.4.1 for now, but unfortunately this is not an option. Quite a few Manga websites have changed by now, breaking compatibility with the previous version. As this is breaking most of HakuNekos’ functionality for some important sites, it became quite unusable on Windows, leaving Linux as the only officially supported platform.

As using virtual machines or remote VNC/X11 servers for HakuNeko proved to be too tedious for me, I thought I’d try to build this by myself. As the MSYS2/MinGW Windows toolchain seemed to be broken for 1.4.2, I tried – for the very first time – to cross-compile on Linux, choosing CentOS 7.3 x86_64 and MinGW32 4.9.3 for the task. This was quite the challenge, given that HakuNeko comes completely unprepared for cross-compiling.

2.) First, the files

Took me many hours / days to get it done – 100% statically linked too – and it’s finished now! What I won’t provide is an installer (don’t care about that), but here are my v1.4.2 builds for Windows:

As of today, those versions have been tested successfully on the following operating systems:

  • Windows XP Professional SP3 / POSReady2009
  • Windows XP Professional x64 Edition SP2 w. Server 2003 updates
  • Windows Server 2003 R2 x64 SP2
  • Windows Vista Enterprise x64 SP2
  • Windows 7 Professional x64 SP1
  • Windows 10 Professional x64 build #1607

Please be aware that not all of the functionality has been tested by me, just a few downloads that wouldn’t have worked with 1.4.1, a few more random downloads here and there, plus chapter-wise .cbz packaging. It’s looking pretty good I think. Here are some sample screen shots as “proof” of it working (click to enlarge):

HakuNeko 1.4.2 downloading "Kobayashi-san Chi no Maid Dragon" on XP x64

HakuNeko 1.4.2 downloading “Kobayashi-san Chi no Maid Dragon” on XP x64 (Note: I own that Manga in paper form)

3.) What has been done to make this work?

3a.) Initial work:

First of all, cross-compiling is a bottomless, hellish pit, a horrible place that you never want to enter unless a.) The build toolchain of the software you wanna compile is very well prepared for it or b.) you really have/want to get your hands on that build or c.) you hate yourself so much you have to hurt yourself or d.) you actually enjoy c.).

The reasons for choosing cross-compiling were that Ronny Wegener had said, that the MSYS2/MinGW32 build would fail on Windows, plus it would require GCC version 5.3 to link with the bundled, pre-built static libraries (OpenSSL, cURL, wxWidgets).

So I thought it would be more likely to work if I were to run my own MinGW setup on Linux, not relying on the bundled stuff but linking against the libraries that come with MinGW32 4.9.3 on my platform of choice – CentOS 7.3 Linux.

One exception was the GUI library wxWidgets 3.0.2 that I had to cross-compile and statically link by myself as well, but luckily, that’s easy despite its size. wxWidgets is one piece of software that does come well-prepared for cross-compiling! In my case, that made it as simple as this (parallel compile with 6 CPUs):

$ ./configure --prefix=/usr/local/i686-w64-mingw32 --host=i686-w64-mingw32 --build=x86_64-linux \
 --enable-unicode --with-expat --with-regex --with-opengl --with-libpng --with-libjpeg --with-libtiff \
 --with-zlib --with-msw --enable-ole --enable-uxtheme --disable-shared
$ make -j6
# make install

3b.) HakuNeko build toolchain / Makefile modifications for cross-compiling:

HakuNeko is much harder, and I don’t even remember half of what I did, but most of it was manually editing the ./Makefile after $ ./configure --config-mingw32 would have produced something rather broken.

Let’s get to it, file paths are relative to the source root. First, edit the following parts of the ./Makefile (you need to look for them in different places of the file). First, the PREFIX, should be in the bottom half of the file:

PREFIX = /usr/local/i686-w64-mingw32/

CC and the CFLAGS:

CC = i686-w64-mingw32-g++
CFLAGS = -c -Wall -O2 -std=c++11 \
 -I/usr/local/i686-w64-mingw32/lib/wx/include/i686-w64-mingw32-msw-unicode-static-3.0 \
 -I/usr/local/i686-w64-mingw32/include/wx-3.0 -D_FILE_OFFSET_BITS=64 -D__WXMSW__ -mthreads \
 -DCURL_STATICLIB -I/usr/i686-w64-mingw32/sys-root/mingw/include

Add -DPORTABLE, if you want to build the portable version of HakuNeko.

Then, the Windows resource compiler, controlled by RC and RCFLAGS:

RC = /usr/bin/i686-w64-mingw32-windres
RCFLAGS = -J rc -O coff -F pe-i386 -I/usr/i686-w64-mingw32/sys-root/mingw/include \
 -I/usr/local/i686-w64-mingw32/include

And finally, the static linking part, which is the hardest stuff to get done right, LD, LDFLAGS and LDLIBS:

LD = i686-w64-mingw32-g++
LDFLAGS = -s -static -static-libgcc -static-libstdc++ -mwindows -DCURL_STATICLIB
LDLIBS = -L/usr/local/i686-w64-mingw32/lib   -Wl,--subsystem,windows -mwindows \
 -lwx_mswu_xrc-3.0-i686-w64-mingw32 -lwx_mswu_webview-3.0-i686-w64-mingw32 \
 -lwx_mswu_qa-3.0-i686-w64-mingw32 -lwx_baseu_net-3.0-i686-w64-mingw32 \
 -lwx_mswu_html-3.0-i686-w64-mingw32 -lwx_mswu_adv-3.0-i686-w64-mingw32 \
 -lwx_mswu_core-3.0-i686-w64-mingw32 -lwx_baseu_xml-3.0-i686-w64-mingw32 \
 -lwx_baseu-3.0-i686-w64-mingw32 -L/usr/i686-w64-mingw32/sys-root/mingw/lib -lcurl -lidn -liconv \
 -lssh2 -lssl -lcrypto -lpng -ljpeg -ltiff -lexpat -lwxregexu-3.0-i686-w64-mingw32 -lz -lrpcrt4 \
 -lwldap32 -loleaut32 -lole32 -luuid -lws2_32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lcomdlg32 \
 -ladvapi32 -lwsock32 -lgdi32

Took a while to find the libraries (and static library order!) necessary to satisfy all the dependencies properly.

If you need it, here is the modified Makefile I’ve used to cross-compile:

  • [HakuNeko Makefile] for cross-compiling HakuNeko 1.4.2 for Windows on CentOS 7.3 x86_64 Linux (needs statically linked & installed wxWidgets first).

3c.) Source code modifications:

However, something will still not be quite right, because some of the crypto libraries will provide the MD5 functions MD5_Init(), MD5_Update() as well as MD5_Final(), and those are already defined by HakuNeko itself. This will break the static linking, as redundant definitions won’t work. We’ll rely on the libraries (libcrypto, libssl), and comment the built-in stuff out in src/v7/v7.c:

  1. void MD5_Init(MD5_CTX *c);
  2. void MD5_Update(MD5_CTX *c, const unsigned char *data, size_t len);
  3. void MD5_Final(unsigned char *md, MD5_CTX *c);

…becomes:

  1. /* void MD5_Init(MD5_CTX *c);
  2.  * void MD5_Update(MD5_CTX *c, const unsigned char *data, size_t len);
  3.  * void MD5_Final(unsigned char *md, MD5_CTX *c);
  4.  */

On top of that, the configure system may have generated src/main.cpp as well as src/main.h. Those are bogus files, turning the entire tool into nothing but one large “Hello World” program. Plus, that’s hard to debug, as the binary won’t even output “Hello World” on a Windows terminal when it’s built as a GUI tool. I only found the issue when testing it with Wine on Linux. ;)

Please delete src/main.cpp and src/main.h before continuing.

Now, if you’re really lucky, you should be able to run something like $ make -j6 and watch everything work out nicely. Or watch it crash and burn, which is the much, much more likely scenario, given I’ve likely only given you half of what I did to the build tools.

Well, in any case, no need to run $ make install of course, just grab the binary build/msw/bin/hakuneko.exe and copy it off to some Windows machine, then try to run it. If you’ve built the portable version, you may wish to rename the file to hakuneko-portable.exe, just like the official developers do.

4.) The future

Let’s just hope that the developers of HakuNeko can get this fixed for versions >=1.4.3, because I really, really don’t want to keep doing this. It’s extremely painful, as cross-compiling is exactly the kind of living hell I heard a lot of people saying it is! I think it’s a miracle I managed to compile and run it at all, and it was so frustrating and tedious for somebody like me (who isn’t a developer).

The statement that this took “hours / days” wasn’t an exaggeration. I think it was something like 10-12 man hours of pure frustration to get it done. I mean, it does feel pretty nice when it finally works, but I wouldn’t bet on myself being able to do this again for future versions…

So please, make it work on Windows again, if possible, and keep HakuNeko cross-platform! It’s still my favorite tool for the task! Thanks! :)

Feb 272017
 

Nekopara Chocola logo…he was just too lazy to take pictures, especially given my rather stupid photography setup. Hah, but it’s not like I stopped buying weird stuff and the figures I’m gonna show you today are just a fraction of what I got, so here we go!

1.) The Nekos / Catgirls from Nekopara

The first (as you may be able to guess from the logo) are the Nekopara mini figures, from the extremely successful and totally not steamy[1] visual novel series of the same name. Actually, the project will now even get an Anime OVA due to an equally successful [Kickstarter project] that I totally did not pledge for (I guess I still need to do something about my name showing up in the credits :roll: ).

I had planned to ask people to pledge for the extension to that – their [slacker backer] campaign – but it has already overshot the last stretch goal, so not much of a point unless to really want to get your hands on the OVA and/or the merchandise. At least we get a Nyanko bonus OVA now as well. Anyway, here are some pictures – unfortunately I didn’t get a hold of the limited preorder bonus anymore, as usually, click to enlarge:

Nekopara Nyankos

The chibi figures of our kitties, f.l.t.r.: Azuki, Cinnamon, Coconut, Vanilla, Chocola, Maple, Shigure (who’s actually human) and Miruku/Milk. Cute as fuck!

Ah yes, sorry for the licensing stamps. I was too lazy to create the usual two versions, one for here and one for off-site use. If somebody really wants a clean version of some of the photos, let me know in the comments – the license won’t change though.  Let’s look at the individual kittens, pair-wise:

 

Those two are the main catgirls, featuring a touching backstory of having been abandoned when very young and then saved by the main character whose role the player takes in the visual novel. Said backstory will be featured in a mini VN as well as a mini Anime OVA thanks to the Anime crowdfunding campaigns breaking through the $800.000 and $1.000.000 stretch goal milestones. They’re the youngest amongst the cats, and of unknown breed. Also, they’re twins, despite not looking the part.

Next:

 

Here we have the local tsundere loli Azuki (I do like her attitude!), a Munchkin cat, who is the oldest of the pack and the pretty perverted Cinnamon, whom we will see more of in the final VN that’ll come out some time this year – I forgot the actual release date. She’s supposed to be a Scottish Fold.

More:

 

Besides being the largest of the pack (in several ways), Coconuts’ most distinct feature are probably her dichromatic eyes. She’s the second-youngest and pretty naïve as well. The other one here is Maple, an American Curl who tends to get into fights with Coconut on a regular basis. Maple will also be shown more of in the final VN. And two more to go:

 

As said, Shigure is no actual catgirl, but the main characters sister, and a huge brocon as well (although there is no corresponding siscon going on here). She raised all of the first six catgirls shown above, and she supposedly did a great job with that. To the right we see Milk (Hepburn pronunciation “Mi-ru-ku”), who is a side character, not a member of the main cast. She’s a very young kitten helping her owner at a [Takoyaki] stand, and she’s cute as hell.

Yay for genetically engineered catgirls! (We seriously need a Kickstarter campaign for that!)

[1] The games feature explicit content only if you buy the original versions. If you get the games on Steam, they will be censored. There are content restoration patches for those versions as well, but in essence, you can get both uncensored as well as a slightly cheaper, censored versions. The Anime OVAs will not contain any explicit content.

2.) Illyasviel von Einzbern

I had actually sworn to myself that I would never ever watch Magical Girl stuff again (I did it once, in the late 90s’). But then, there came the Yuri, and when there is Girls Love, there’s just no way I’m gonna hold back, no matter the setting. So yes, I did watch all of Fate/Kaleid Liner Prisma☆Illya, and it’s… pretty questionable stuff, at least in season 2 & 3 if I remember correctly. This is Loli Yuri, you have been warned! In any case, let’s go all pink, sigh…

 

Yeah, I know. Just don’t say anything. I feel conflicted and embarrassed enough posting her here! Let’s take a closer look:

Illya, angle shot

Angle shot – I mean, yeah, she’s beautifully crafted, the detail level is high, and it’s a very dynamic pose. The problem with this clearly lies elsewhere :roll:

Let’s take a look at her face:

Illyas' face

Yep, Phat Companys’ sculptors and color producers did a pretty much perfect job here…

It gets much worse though…

Cardholder Analysis 1

This is wrong for too many reasons. Please do not watch the Anime, for I fear you might learn all of them.

You know, I’d love to tell you that my one complaint with this figure is the lack of detail on her card holder, and that I took this photo to show you said lack of detail… And of course, the card holder being totally out of focus here has nothing to do with anything! And that there is an actually correctly taken shot of this doesn’t mean anything either! Ah yeah, here:

Cardholder Analysis 2

The card holder *does* indeed lack some detail however… The FuRyu figure of her has the detailed pattern on it for instance.

Now if we can agree that none of this ever happened, we’re all good! But then again, I could’ve just not posted her in the first place, guess I feel like a criminal who does want to be caught after all.

Well, whatever, so what’s left? There will be two more scale figures in the future, of which one is particularly beautiful – look forward to a nice Kimono for once! And there are also some Nendoroids who’re missing for now, and depending on when a certain Madoka★Magica 2-figure set is really coming out, there will be another two to add to the list.

Guess I still have a lot of pictures to take. Could be that this blog will once more shift from technical stuff to weird Anime merchandise in next few weeks. :roll:

Feb 242017
 

Firefox + HTML5 + XP logo1.) Introduction & Explanation

This is one thing that has brought to me by two users ([SK1] on [Voodooalert]German flag and [liquidLD] who talked to me about this on IRC), and because I got a bit pissed off by it myself, I decided to look into the matter. Basically, HTML5 video on Windows XP / XP x64. But not just with webm (VP8/VP9), but also with H.264/AVC. Let’s face it, a lot of videos on the web rely on H.264 and sometimes you simply can’t watch certain videos or you won’t get all the available resolutions. Of course you could just rely on Adobe Flash, but since Google basically took over with their Pepperflash plugin and their Chrome browser no longer supports XP, it’s not the best move either. Especially when you think about Adobes’ history with critical security loopholes in Flash. HTML5 is just much, much safer, and free as well, and Firefox still supports XP.

Note that this guide is thus based on Firefox exclusively. Anything starting with version 47 should work, official support came in 49, and I’ll be using the current version, 51.0.1 at the time of writing.

So, why doesn’t it “just work” in the first place? It did a few years back, right? Because H.264 playback relies on a DRM plugin, on Linux it would be the Google Widevine plugin, on Windows it’s the Adobe Primetime plugin. So yes, Firefox does support DRM out of the box. But even if content isn’t signed and encrypted, the browser still relies on those plugins to play H.264. And the problem is, that Adobe found some problems with that plugin on XP, so they disabled support on the platform. Their version 17 plugin is still being rolled out with the browser however, and it is binary-compatible with XP, so let’s show you how to re-enable it!

2.) Making it work

On Windows XP and XP x64, the plugin should reside in the folder:

%USERPROFILE%\Application Data\Mozilla\Firefox\Profiles\<your profile folder>\gmp-eme-adobe\17\

That folder should contain the files eme-adobe.dll, eme-adobe.info and eme-adobe.voucher. If it doesn’t (maybe because you have a DRM-free version of Firefox), just create the folder structure yourself, get the necessary files from [here] and place them in that folder.

Having the files present won’t enable Adobe Primetime for you however as you can see on about:plugins (Note: The Cisco stuff you can see there is just for WebRTC, so it’s unusable for HTML5 <video>), we still need to tweak a few things on the about:config page of Firefox. Look for the following properties and set them to the values shown below. If a property doesn’t exist yet – media.gmp-eme-adobe.forceSupported most likely won’t – just create them yourself, all of them are boolean properties and all of them need to be set to true:

media.gmp-eme-adobe.enabled		true
media.gmp-eme-adobe.forceSupported	true
media.gmp-eme-adobe.visible		true
media.gmp.decoder.enabled		true
media.eme.enabled			true
media.mediasource.mp4.enabled		true
media.mp4.enabled			true

After making those changes, you’ll need to restart Firefox. Now you might already be good to go, but on some configurations, about:plugins might show something like this:

HTML5+H.264 on Firefox not yet working

Adobe Primetime seems enabled, but there is no file information? So it’s not actually loading the eme-adobe.dll yet (click to enlarge)

If that happens, open your preferences menu on the top right, click on “Add-ons”, then “Plugins” or just go to about:addons. What you should be seeing is this:

 

However, if Adobe Primetime shows a notice saying that it’s going to be “installed shortly”, forget it. Just do it manually on the plugins’ options page you can see on the right image. To do so, click “Check for Updates”. The warning should be gone momentarily. After that, re-check about:plugins, and you should be getting this:

Adobe Primetime fully enabled

Adobe Primetime fully enabled (click to enlarge)

3.) Testing

Now you can do a quick check on the [Youtube HTML5 page], and it should confirm that everything’s working:

Youtube confirming full HTML5 video support

Youtube confirming full HTML5 video support including H.264 and Media Source Extensions (click to enlarge)

With MSE, even Javascript players (like the Flowworks player) bytestreaming H.264 to Firefox should work! Of course, that’s not very thorough. What you’d want is a real playback test, since you can never be sure what you’re getting on Youtube without a bit of extra work. Decent playback tests are currently available on [Quirksmode], and it should look like this:

Firefox playing HTML5 H.264/AVC video in Firefox on Windows XP x64

Firefox playing HTML5 H.264/AVC video on Windows XP x64 (click to enlarge)

With this, even stuff like Netflix works, because you’re getting not just H.264 playback, but also DRM support. Now, whether DRM support is a good thing or not… You’ll have to decide that for yourself. I’m not supportive of DRM content on the web, but if you want to view or listen to such content, you can!

Just one last word of warning though: Adobe has ended their support for XP with a reason, as the Primetime content decryption plugin has shown problems and instabilities on XP! I’ve been using this for about a week now, and I’ve had one case of a video getting stuck, which is a typical symptom of Primetime throwing up on you. Don’t worry though, Firefox won’t crash. Just move the video slider a bit or restart the video, and it’ll work again! You don’t even need to restart the browser, and such occurrences seem to be quite rare, so I’m fine with it.

There you go!

4.) Thanks

Big thanks fly out to [the guys at MSFN] who came up with all of this. I basically got 100% of my information from them, so thank you! You rock! :)

Update: If you update your version of Firefox to the latest and final 52.0 ESR (extended support release), the last version which will be officially supported until 09-2017 for XP, you might notice that Adobe Primetime just disappeared after the update. That’s because the installer may delete the property media.gmp-eme-adobe.visible from your prefs.js. To reenable it, you’ll have to manually recreate the boolean property and set it to true:

media.gmp-eme-adobe.visible		true

Restart Firefox after the change, and the plugin should reappear on about:plugins and about:addons!

Jan 252017
 

H.265/HEVC logo1.) Introduction

After doing a [somewhat proper comparison between x264 and x265] a while back, I thought I’d do another one at extremely low bitrates. It reminded me of the time I’ve been using ISDN at 64kbit/s (my provider didn’t let me use CAPI channel aggregation for 128kbit/s), which was the first true flat rate in my country. ‘Cause I’ve been thinking this:

“Can H.265/HEVC enable an ISDN user to stream 1080p content in any useful form?” and “What would H.264/AVC look like in that case?”

Let me say this first: It reaaally depends on how you define “useful”. :roll:

Pretty much nobody uses ISDN these days, and V.9x 56kbaud modems are dying out in the 1st world as well, so this article doesn’t make a lot of sense. To be fair, I didn’t even pick encoding settings fit for low-latency streaming either, nor are my settings fit for live encoding. So it’s just for the lulz, but still! I wanted to see whether it could be done at all, in theory.

To make it happen, I had to choose extremely low bitrates not just for video, but audio as well. There are even subtitles included in my example, which are present in Matroska-style zlib-compressed [.ass] format, so compressed text essentially.

For the audio part, I chose the Fraunhofer FhG-AAC encoder to encode to the lowest possible constant bitrate, which is 8kbit/s HEv2-AAC. That’s a VoIP-focused version of the codec targeted at preserving human speech as well as possible at conditions as bad as they get. And yes, it sounds terrible. But it still gets across just enough to be able to understand what people are saying and what type of sounds are occurring in a scene. Music and most environmental sounds are terrible in quality, but they are still discernible.

For video, I picked a 2-pass ABR mode with a 50kbit/s target bitrate, which is insanely low even for the Anime content I picked (my apologies, Mr. “[Anime is not what everyone watches]”, but yes, I picked Anime again). Note that 2D animated content is pretty easy on the encoders in this case, so the results would’ve likely been a lot worse with 1080p live action content. As for the encoder settings, you can find those [down below] and as for how I’m taking the screenshots, I’ll spare you those details, they’re pretty similar to the stuff shown in the link at the top.

Before we start with the actual quality comparison, I should mention that my test results actually overshot their target, so they’re really unsuitable for live streaming even in the ISDN case. I just didn’t care enough for trying to push the bitrate down any further. Regular streaming would still be possible with my result files, but not without prebuffering. See here:

$ ls -hs *.mkv
2.6M Piaceː Watashi no Italian - Episode 02-H.264+HEv2AAC-V50kbit-A8kbit.mkv
2.0M Piaceː Watashi no Italian - Episode 02-H.265+HEv2AAC-V50kbit-A8kbit.mkv
 76M Piaceː Watashi no Italian - Episode 02.mkv
$ for i in {'Piaceː Watashi no Italian - Episode 02.mkv','Piaceː Watashi no Italian - \
Episode 02-H.264+HEv2AAC-V50kbit-A8kbit.mkv','Piaceː Watashi no Italian - \
Episode 02-H.265+HEv2AAC-V50kbit-A8kbit.mkv'}; do mediainfo "$i" | grep -i "overall bit rate"; done
Overall bit rate                         : 2 640 kb/s
Overall bit rate                         : 88.6 kb/s
Overall bit rate                         : 69.2 kb/s

The first one is the source (note: From [Crunchyroll], legal to watch and record in my country at this time), the second my x264 and the third my x265 versions. Let’s show you the bitrate overshoot of just the video streams in my versions:

$ for i in {'Piaceː Watashi no Italian - Episode 02-H.264+HEv2AAC-V50kbit-A8kbit.mkv','Piaceː \
Watashi no Italian - Episode 02-H.265+HEv2AAC-V50kbit-A8kbit.mkv'}; do mediainfo \
--Output="Video;%BitRate/String%" "$i"; done
71.1 kb/s
51.6 kb/s

So as you can see, x264 messed up pretty big, overshooting by 21.1kbit/s (42.2%), whereas x265 almost landed on target, overshooting by a mere 1.6kbit/s (3.2%) overall. And still… well… Let’s give you an overview first (as usual, click to enlarge images):

2.) Quality comparisons

Note that the color shown in those thumbnails is not representative of the real images, this has been transformed to 256 color .png to make it easier to download (again, if your browser supports it, .webp will be loaded instead transparently). This is just to show you some basic differences between what x264 and x265 are able to preserve, and what they are not. Also, keep in mind, that “~50kbit/s nominal bitrate” means 71.1kbit/s for x264 and 51.6kbit/s for x265!

Overall, x264 fucks up big time. There are frames with partial macroblock drops and completely blank frames even! Also, a lot of frames lose their color either partially or completely as well, making them B/W. And that’s given that x264 even invested 42.2% more bitrate than what I aimed for!

x265 has no such severe issues, all frames are completely there in full color, and that at a bitrate reasonable close to the target. Let’s look at a few interesting cases side by side:

Scene 1 (left: x264, middle: x265, right: source file):

There are some indications of use of larger CTUs (coding tree unit, H.265s’ replacement for macroblocks) in x265s’ case, which is supposed to be one of its strong points, especially for very large resolution encoding (think: 4K/UHD, 8K). While larger blocks can mean loss of detail in that area, it’s ok for larger areas of uniform color, which this Anime has a ton of. H.264/AVC can’t do that so well, because the upper limit for a macroblocks’ size is rather low with 16×16 pixels. You can see the macroblock size pretty clearly in the blocky frame to the left. You need to look a bit more carefully in x265s’ case, but there are a few spots where I believe it can be seen as well. In my case the CTU size for x265 was 32×32px.

Hm, maybe --ctu 64 would’ve been better for this specific case, but whatever.

Lets look at two more mostly color-related comparisons:

Scenes 2 & 3 (left: x264, middle: x265, right: source file):

 

In the first case it seems as if x264 is trying to preserve shades of green more than anything, but in the second case, something terrible happens. There is a lot of red in the scene before this one, and there is quite some red on those can labels as well. It seems x264 doesn’t know where to put the color anymore, and the reds bleed almost all over the frame. And it stays like that for the entire scene as well, which means for several seconds. The greens and browns are lost. Block artifacts are excessive as well, but at least x264 managed to give us whole frames here, with some color even.

Well, the color kinda went everywhere, but uhm, yeah…

Two more:

Scenes 4 & 5 (left: x264, middle: x265, right: source file):

 

I really don’t know what’s with x264 and the reds. Shouldn’t green have priority? I mean, not just in the chroma subsampling, but in encoding as well? But red seems what x264 drops last, and it happens more than once. Given the detail and movements in that last part, even x265 fails though. Yes, it does preserve more color, but it doesn’t come remotely close to the source at this bitrate.

And that other frame with the cuteness overload? There are a lot like those, where x264 just kinda panics, drops everything it has and then frantically tries to (re?)construct the current frame, sometimes only partially until the next I-frame arrives or so.

So that’s it for my quick & dirty “ultra low bitrate” comparison between x264 and x265, at pretty taxing encoding settings once again.

3.) Additional information

x264 encoding settings:

$ mediainfo Piaceː\ Watashi\ no\ Italian\ -\ Episode\ 02-H.264+HEv2AAC-V50kbit-A8kbit.mkv | grep -i \
"encoding settings"
Encoding settings                        : cabac=1 / ref=16 / deblock=1:-2:0 / 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=0 / chroma_qp_offset=-2 / threads=18 / \
lookahead_threads=4 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / \
constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / \
open_gop=1 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / \
rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=50 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=81 \
/ qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:0.60

x265 encoding settings (note: 10 bits per color channel were chosen, same as for x264):

$ mediainfo Piaceː\ Watashi\ no\ Italian\ -\ Episode\ 02-H.265+HEv2AAC-V50kbit-A8kbit.mkv | grep -i \
"encoding settings"
Encoding settings                        : cpuid=1049087 / frame-threads=3 / wpp / pmode / pme / \
no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=0 \
/ level-idc=0 / high-tier=1 / uhd-bd=0 / ref=6 / no-allow-non-conformance / no-repeat-headers / \
annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / \
keyint=250 / bframes=16 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=40 / \
lookahead-slices=0 / scenecut=40 / no-intra-refresh / ctu=32 / min-cu-size=8 / rect / amp / \
max-tu-size=32 / tu-inter-depth=4 / tu-intra-depth=4 / limit-tu=0 / rdoq-level=1 / signhide / \
no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=5 \
/ limit-refs=1 / limit-modes / me=3 / subme=4 / merange=57 / temporal-mvp / weightp / weightb / \
no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=6 / no-early-skip / rskip / \
no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / rdpenalty=0 / psy-rd=1.60 / \
psy-rdoq=5.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / \
bitrate=50 / qcomp=0.75 / qpstep=4 / stats-write=0 / stats-read=2 / stats-file=265/v.stats / \
cplxblur=20.0 / qblur=0.5 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.00 / cutree / \
zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / \
videoformat=5 / range=1 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 \
/ max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / \
slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05

x264 version:

$ x264 --version
x264 0.148.x
(libswscale 3.0.0)
(libavformat 56.1.0)
built on Sep  6 2016, gcc: 6.2.0
x264 configuration: --bit-depth=10 --chroma-format=all
libx264 configuration: --bit-depth=10 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat license: nonfree and unredistributable
WARNING: This binary is unredistributable!

x265 version:

$ x265 --version
x265 [info]: HEVC encoder version 2.2+23-58dddcf01b7d
x265 [info]: build info [Linux][GCC 6.2.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

Encoding & testing platform:

$ uname -sr
Linux 2.6.32-573.8.1.el6.x86_64
$ cat /etc/redhat-release 
CentOS release 6.8 (Final)
$ cat /proc/cpuinfo | grep "model name" | uniq
model name	: Intel(R) Core(TM) i7 CPU       X 980  @ 3.33GHz

4.) Answers

Q: “Can H.265/HEVC enable an ISDN user to stream 1080p content in any useful form?

A: It can probably stream something that at least resembles the original source in a recognizable fashion, but… whether you can call that “useful” or not is another thing entirely…

Q: “What would H.264/AVC look like in that case?”

A: Like shit! :roll:

Aug 032016
 

xmms logoYeah, I’m still using the good old xmms v1 on Linux and UNIX. Now, the boxes I used to play music on were all 32-bit x86 so far. Just some old hardware. Recently I tried to play some of my [AAC-LC] files on my 64-bit Linux workstation, and to my surprise, it failed to play the file, giving me the error Pulse coding not allowed in short blocks when started from the shell (just so I can read the error output).

I thought this had to have something to do with my file and not the player, so I tried .aac files with ADTS headers instead of audio packed into an mp4/m4a container. The result was the same. Also, the encoding (SBR/VBR or even HE-AAC, which sucks for music anyway) didn’t make a difference. Then I found [this post] on the Gentoo forums, showing that the problem was really the architecture. 32-bit builds wouldn’t fail, but the source code of the [libfaad2] decoding library of xmms’ mp4 plugin wasn’t ready for 64-bit.

xmms’ xmms_mp4Plugin-0.4 comes with a pretty old libfaad2, 2.0 or something. I will show you how to upgrade that to version 2.7, which is fixed for x86_64 (Readily fixed source code is also provided at the bottom). We’ll also fix up other parts of that plugin so it can compile using more modern versions of GCC and clang, and my test platform for this would be a rather conservative CentOS 6.8 Linux. First, get the source code:

I’m assuming you already have xmms installed, otherwise obtain version 1.2.11 from [here]!

Step 1, libfaad2:

Unpack both archives from above, then enter the mp4 plugins’ source directory. You’ll find a libfaad2/ directory in there. Delete or move it and all of its contents. From the faad2 source tree, copy the directory libfaad/ from there to libfaad2/ in the plugins’ directory, replacing the deleted one. Now that’s the source, but we also need the updated headers so that the xmms plugin can link against the newer libfaad2. To do that, copy the two files include/faad.h and include/neaacdec.h from the faad2 2.7 source tree to the directory include/ in the plugin source tree. Overwrite faad.h if prompted.

Step 2, libmp4v2:

Also, the bundled libmp4v2 of the mp4 plugin is very old and broken on modern systems due to code issues. Let’s fix them, so back to the mp4 plugin source tree. We need to fix some invalid pure specifiers in the following files: libmp4v2/mp4property.h, libmp4v2/mp4property.cpp, libmp4v2/rtphint.h and libmp4v2/rtphint.cpp.

To do so, open them in a text editor and search and replace all occurences of = NULL with = 0. This will fix all assignments and comparisons that would otherwise break. When using vi or vim, you can do :%s/=\sNULL/= 0/g for this.

On top of that, we need to fix a invalid const char* to char* conversion in libmp4v2/rtphint.cpp as well. Open it, and hop to line number 325, you’ll see this:

  1. char* pSlash = strchr(pRtpMap, '/');

Replace it with this:

  1. const char* pSlash = strchr(pRtpMap, '/');

And we’re done!

Now, in the mp4 plugins’ source root directory, run $ ./bootstrap && ./configure. Hopefully, no errors will occur. If all is ok, run $ make. Given you have xmms 1.2.11 installed, it should compile and link fine now. Last step: # make install.

This has been tested with my current GCC 4.4.7 platform compiler as well as GCC 4.9.3 on CentOS 6.8 Linux. Also, it has been tested with clang 3.4.1 on FreeBSD 10.3 UNIX, also x86_64. Please note that FreeBSD 10.3 needs extensive modifications to its build tools as well, so I can’t provide fixed source for this. However, packages on FreeBSD have already been fixed in that regard, so you can just # pkg install xmms-faad2 and it’s done anyway. This is likely the case for several modern Linux distros as well.

Let’s play:

xmms playing AAC-LC Freebsd 10.3 UNIX on x86_64

Yeah, it works. In this case on FreeBSD.

And the shell would say:

2-MPEG-4 AAC Low Complexity profile
MP4 - 2 channels @ 44100 Hz

Perfect! And here is the [fixed source code] upgraded with libfaad2 2.7, so you don’t have to do anything by yourself other than $ ./bootstrap && ./configure && make and # make install! Ah, actually I’m not so sure whether xmms itself builds fine on CentOS 6.8 from source these days… Maybe I’ll check that out another day. ;)

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 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
 

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…

Mar 232016
 

Logo for the Akaza Akari and Hirasawa Yui Nendoroids as well as the Strike Witches Perrine Clostermann and Francesca LucchiniYeah, more PVC incoming; It’s getting a bit cramped in my display cabinet, as it wasn’t really made for displaying 1/8 scale figures anyway, but there is still a little bit of room, so here are some figures I’ve had sitting on my wishlist for quite a few months. And in best tradition, some of them are a bit “borderline acceptable”. Or all of them, depending on your stance. Ah, and my apologies for the license stamps on the images. I forgot to keep processed copies without the stamps for the weblog… Meh.

The first two are Nendoroids, once more some Hirasawa Yui from K-On! (’cause there is no such thing as enough Yui! But this one is going to be modified for a special purpose.), and Akaza Akari from Yuru Yuri, and then two figures from Strike Witches – needless to say my two favorites – Perrine Clostermann and Francesca Lucchini, both made by Alter. Here are the boxes:

1.) The Nendoroids

Now as I said, Yui is supposed to become more special, as I had an idea to get myself a bobblehead for my car based on her quite long ago. Thing is, bobbleheads seem to be something pretty US American, so there simply are none based on Anime characters, despite Nendoroids having the perfect dimensions for it. Thus, I’d need to build my own:

My first attempt was to just drive some nails into Yuis’ feet and legs, but while that works for a static application, it’s nowhere near stable enough for putting her in an actual car, so I’m probably going to switch to screws. The legs can be twisted a bit so she won’t bend over due to inertia, but the thing is that the legs are partially hollow, reducing the amount of material the screw can safely sit in. I’ll need to get longer ones that go all the way up and into the hip joints as well to stand a chance of this being stable enough. Otherwise some hole/bump in the road or some violent breaking maneuver might send her flying off the baseplate.

The bobbleheads’ neck itself will be solved by replacing the plastic joint with either a tension spring or a pressure spring with optional stiffening material. I have briefly tested this already with another roid and it works well enough. All I need is a solid enough mount.

Further progress will be reported on this blog, but I can’t say when, as that depends on the intensity of my typically pretty severe laziness. ;)

Now, Akari:

Strangely, I got the limited preorder version with the additional parquet-style baseplate, as you can see on the photos. I’m not sure whether this was just luck, or whether it wasn’t limited after all. Maybe they just had some in stock still, although that’d be weird, given the age of the figure. The “Akariiin!~” plate is also included, but I forgot to take a picture of it. Ehm, probably better that way anyhow.

2.) The Alter 1/8 scale figures

Alter’s known to produce some high quality stuff, and I got to see that for myself with the [K-On! complete set], and hell, that’s some pretty decent stuff! So how about the Strike Witches? While the series is basically just about cute girls fighting aliens (or whatever the “Neroi” really are) with magically empowered guns and rocket launchers while presenting the curious viewer a distinct lack of apparel, the series’ military advisers seem to have ensured a certain amount of details regarding the Witches’ array of weaponry. Not to the extent of Girls und Panzer maybe, but still. Let’s look at the cool and well-mannered Tsundere character first, this is Perrine Clostermann:

Not exceptional it seems, besides a pretty spacious setup for a 1/8 figure. Surely not bad either though. Let’s zoom in a bit:

The Bren gun doesn’t boast too much detail, but it looks good enough. Same goes for her propeller striker units (there is a “in motion disc version” of the rotors as well, but I put the still ones on). The nicest part is probably her face, featuring metal wire frame glasses, which do look pretty good, surely better than some thicker and more flimsy plastic would. The downside is, that there is no actual glass, just the frame. Also, her front bangs could’ve been done a bit better!

Now, let’s look at the Strike Witches’ resident Loli character, Francesca Lucchini:

Now, believe it or not, the most important part for me about her was the gun, an American Browning M1919A6 MG. Now I’m not really that much of a WW2 infantry weapons nerd, but I got the impression that Alter got that piece done really well, so let’s take a closer look:

Now that’s really Alter-level quality right there. It’s a bit of a shame that the ammo box isn’t opened up a bit wider so we can catch a better glimpse of the belt-feed, but it’s still awesome. The shoulder belt looks like she’s truly in motion as well, and while it’s not easy to put the weapon in her hands properly, it looks perfect when done right.

And now, since this series is totally not about panty shots and won’t have the girls flash them at you like several times per minute or anything….

Francesca Lucchinis pantsu

You’re totally not gonna see this like all the time in the series!!!!111 Actually, this is probably barely legal by European standards, given her Loli status, but ya know, Japan… Click to enlarge if you really have to!

In my defense: It’s pretty hard to take any kind of picture of hers while not having her flash her panties at least at some angle. :roll: But there you go, serving the classic “blue white stripes”pantsu fetish that seems to exist amongst certain viewers in Japan. Not that I’m complaining or anything. ;)

And now, there is barely any room left to put any more scale figures… Hmmm…

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!