h264 Hi10P: There Another Mess for You to Deal Again, Linux Distro Devs…

Like it or not, Linux (along with *BSD and other open-source OSes) always lags behind Windows in multimedia functionality. It’s not really a big deal for average Hollywood Blockbuster Fags, since DVDRIP or even worse CAM-TS are still much the same as the prehistoric age, still the same AVI format and inferior SubRip external subtitles. But when it comes to anime-fags, surely they’ll be annoyed, since anime fansubbing (read:piracy) scene always pushing hard to the latest power-ups in multimedia technology. Substation Alpha, Matroska container are to name a few, and while only 5 out of 8 Windows desktop can play Matroska format, they came up with ordered-chapter Matroska, and now the latest h264 Hi10P format which puts frowns on the faces of Windows and Linux animefags alike.

But the pathos is always heavier for us Linux hipsters. The ordered chapter Matroska hasn’t made its way to mplayer, the most functional media player for Linux platform. A less popular but newer mplayer fork called mplayer2 has implemented it, but we can see it here that the Linux multimedia developers are reluctant when it comes to catching up with the latest developments. In ordered-chapter case, the reason is security, because they suspected that linked files can be manipulated to do some harm to the computer. An even worse case, Aegisub build for Linux is still less-stable than its Windows counterpart, crashing every now and then (Aegisubs developers are clearly Windows-minded, since the keyboard shortcut for ‘Quit’ is Alt+F4, even in the Linux port). Aegisub devel teams don’t seem to care much for other than Windows, as the failure of the latest source code to compile against newer FFmpeg versions indicates that they still use older (prehistoric) FFmpeg. To date, Assdraw hasn’t even seen a fork for OSes other than Windows.

The Firsthand Experience

Now my friends from Indonesian fansub community are blabbering about the shining-new h264 Hi10P. This is a format of h264 which encodes each color channel in 10 bits, as opposed to the older (and normal-world standard) h264 which uses 8 bits. This means more fidelity at a given bitrate, and possibly smaller file size (profit for those trapped in developed countries where broadband means 5kBps). Well, I put my trust on my rolling-release distro, checking repository, assuring x264 installed in my system was the newest, and it was. I checked the help texts, no option for Hi10P. I found a header file from x264 package which defined bit depth as 8. It seemed that my x264 from the distro was hardcoded for 8 bit encoding. Next step, I searched in x264 user-build package, none of which supported 10 bit.

OK, let’s do it the hard way. I grabbed the source, wrote a distro-specific build script. My guess was right, x264 is either hardcoded for 8 bit or 10 bit, but no switch to choose one of either on-the-fly. A compile-failure solved by disabling software scaler. Package build succeed. Here’s my distro-specific build script.

Time to test it. For the test material I used the live-action PV of Morning Arch from a DVD ISO. It is interlaced, and has 702×480 display size. For adjustment I run the source through these filters before passing them to x264: linear-blend to deal with the interlacing, crop filter to remove vertical black bands, contrast enhancement (the video looks like it was ripped from a bleached 16mm roll), and the last, denoise to suppress noise induced by contrast enhancement. The encoding is done by x264 and mplayer in tandem, using a yuv4mpeg FIFO. I set the quality as CRF 26.

It was pretty much a heavy burden for my Core2Duo, 1GB laptop. CPU load skyrocketed to 100% while CPU temp rose to 81’C (8 degrees below critical), and the chromium browser lagged. Nevertheless my laptop managed to finish it without getting overheated. The result seemed to be very promising: an 19MB raw h264 stream, or a total of 31MB Matroska file with Ogg audio, ripped from a 343MB DVD ISO. You can grab the torrent here.

Well, I was ready to test it with mplayer2. But it was not my lucky day, mplayer2 spat out error messages and refused to play the video. It turns out that the distro’s official version of FFmpeg doesn’t support Hi10P. The latest git version has the support, but it takes forever to clone the entire git branch, so I’ll save that later when I get a better internet.

Now I am waiting for feedback from leechers who had downloaded my rip.

Concluding Remarks

While being a tough guy in networking, programming and security area, Linux (and other *NIXen) is pretty weak in multimedia. Even a rolling-release, bleeding-edge distro couldn’t always provide support for newest multimedia quirks. Most fansubbers out there are working on Windows PCs. While things like stable Aegisub and encoder’s ‘Swiss Army Knife’ – the Avisynth with its powerful .avs script – are common staple stuffs for them, they are luxuries that we, Linux average users, can’t afford. This leaves a pretty big tasks for Linux multimedia developers, to catch up with Windows. The most important of them being the Avisynth frameserver, for its self-documenting format will save us from long, multiple line CLI arguments. Without a working Linux/*NIX fork of Avisynth, pretty much encoders out there will have no reason to leave Windows.

h264 Hi10P: There Another Mess for You to Deal Again, Linux Distro Devs…

4 thoughts on “h264 Hi10P: There Another Mess for You to Deal Again, Linux Distro Devs…

    1. haha…. ngejalanin Windows di VirtualBox bikin laptop cepat panas….

      sebetulnya buat linux ffmpeg dan mplayer2 sudah lebih dulu mendukung hi10p, malahan ryuumaru awalnya menyarankan mplayer2 daripada cccp, tapi entah kenapa versi ffmpeg dan x264 dengan dukungan hi10p belum dimasukkan ke repositori kebanyakan distro

  1. >It turns out that the distro’s official version of FFmpeg doesn’t support Hi10P.
    >The latest git version has the support, but it takes forever to clone the entire git branch

    It takes less time to clone the entire git branch than it does to download a 720p hi10p episode of your favorite japanese cartoon.

    If you have problems cloning that little bit of data, you shouldn’t even bother with 10bit.

    1. The problem is not ‘how large is the data?’, but more of ‘‘could I connect, and if I get connected, could I maintain the connection?’ My ISP puts a very tight bandwidth throttling, which drops the connection if there are too many request, and even often disconnects an established link for no reason at all. When I was in my hometown, cloning git is just impossible, because my git client can’t maintain the connection to the git server.
      Anime (or Japanese ‘cartoon’) download is different. There are many back-up connections from other peers, if I my link to a peer gets dropped, I can still download from other peers. That’s why I can download gigabytes of Japanese ‘cartoon’ series.
      Well, the situation is different now since I moved to a larger city. The connection gets faster and there is no more problem with git download (although I still have to reload the dashboard three times to approve and reply your comment 😀 ).

Leave a reply to hirafitri Cancel reply