Tuesday, April 22, 2014

A Brief Look at x265 vs x264

The next-gen open-source video codec known as x265 (h.265 / HEVC) is starting to gain some traction, since it is now included in the popular FFmpeg utility and its various derivatives, so I figured I'd do some poking around and see how it compares with the ubiquitous x264 (h.264 / AVC). NOTE: x265 is still extremely new and unoptimized, while x264 is mature and stable, so this isn't really a fair fight just yet.

For this comparison, I downscaled a 720p video to 480p with both codecs. For x264, I used a CRF value of 21, high profile, 'medium' quality preset with a 'film' tuning (these settings were chose for simplicity rather than quality). For x265, I used an RF value of 21, 'medium' quality preset with 'ssim' tuning.

During the encoding, x264 used all 8 of my AMD Bulldozer cores at approximately 95% utilization, with an average encoding speed of ~75 fps. In comparison, x265 reached only approx. 65% CPU utilization, with an average encoding speed of just 12 fps.

As expected, the videos were comparable in quality, with a slight edge going to x264 (maybe related to differences in my settings, or maybe differences in the codecs, themselves; I'm not sure and didn't delve deep enough to find out), as you can see in these sample shots (click for full size, which is still pretty small):
However, underlying that slightly better quality, x264 used roughly 47% more bits per second to encode. That is, x265 had a final bitrate of 624 kbps vs x264's 919 kbps.

So, x265 already produces a significantly more efficient encoding than x264 but the processing power required for that encoding is much greater (roughly one-sixth the framerate). Moreover, decoding is all done on the CPU right now, as no GPUs have built-in decoder chips for h.265, so that means greater power usage and shorter battery life when viewing.

x265 is already impressive in efficiency but the drawbacks of increased computational costs in both encoding and decoding and drastically slower encoding speeds make it currently unattractive to me. I'll be keeping a close eye on development, though, since it's only a matter of time before the tradeoffs are corrected (improvements in the codec), negated (implementation of hardware encoding/decoding) or rendered moot (improvements in general computation power). After all, it wasn't so long ago that x264 was considered immature, unoptimized and poorly supported in hardware vs xvid / ASP. ;)

Thursday, April 10, 2014

Interlacing Shader for CRTs

In the comments of my TVs and Retro Gaming post, GPDP and Monroe88 mentioned the need for a shader that would take a 480p signal from an emulator and either add 100% black scanlines on "240p" content or blank alternating fields each frame. In other words, they needed a shader that would interlace the default progressive signal, which would allow them to run their displays at 480p for all retro console emulation instead of having to switch back and forth between 320x240 (most games for NES, SNES, Genesis/Mega Drive etc.) and 640x480 (for games that utilized the added lines of resolution that interlacing provided, such as 2-player mode in Sonic 2, SNES' R.P.M. Racing, and tons of PSX games).

So, here's the shader in RetroArch-compatible Cg format:
- HLSL compilers
- Cg compilers
Author: hunterk
License: Public domain
struct input
float2 video_size;
float2 texture_size;
float2 output_size;
float frame_count;
float frame_direction;
float frame_rotation;
sampler2D texture : TEXUNIT0;
void main_vertex
float4 position : POSITION,
out float4 oPosition : POSITION,
uniform float4x4 modelViewProj,
float4 color : COLOR,
out float4 oColor : COLOR,
float2 texCoord : TEXCOORD,
out float2 oTexCoord : TEXCOORD,
uniform input IN
oPosition = mul(modelViewProj, position);
oColor = color;
oTexCoord = texCoord;
float4 main_fragment (in float2 texCoord : TEXCOORD, uniform input IN) : COLOR
float4 res = tex2D(IN.texture, texCoord);
float y = 0.0;
// assume anything with a vertical resolution greater than 400 lines is interlaced
if (IN.video_size.y > 400.0) y = IN.texture_size.y * texCoord.y + IN.frame_count;
y = 2.0 * IN.texture_size.y * texCoord.y;
if (fmod(y, 2.0) > 0.99999) return res;
return float4(0.0);
It has two branching 'if' statements, which is horrible for performance in shaders, but this one is simple enough--and only needs to run at 2x--that it shouldn't matter.

UPDATE: In the comments, Monroe88 mentioned another very useful shader for use with 31 kHz CRT monitors: aliaspider's TVoutTweaks, which lets you add some nice effects, such as composite color correction and horizontal bandwidth (blends things like SNES' pseudo-hires transparency and other dithering effects), which will make the image a little closer to a 15 kHz TV. See Monroe88's comment below for more info and a pic.

Saturday, March 29, 2014

TVs and Retro Gaming / Emulation


Retro gaming is a hobby of mine and, as I started looking into hooking my retro consoles up to modern displays, I found a bunch of incomplete information and dead links scattered among various enthusiast forums, along with misunderstandings and oft-repeated misinformation. So, after diving down the rabbit hole and exploring a bunch of different options, I decided to post my findings in the hopes of saving others from making any costly, avoidable mistakes.


I have a big LCD HDTV with a HTPC connected that I use for watching videos and playing emulated games, and I can use various shaders to achieve an aesthetically satisfying approximation of how my retro games looked on CRT TVs. However, there are a number of reasons to use the real hardware instead of emulation, such as emulation accuracy deficiencies--which can render some games unplayable or unenjoyable--and/or latency concerns.

Sadly, modern displays like my HDTV make retro consoles look like absolute crap and can create/exacerbate latency issues, as they recognize the consoles' double-strike/"240p" signal as 480i(nterlaced)--and rightly so, since standard NTSC signals are always 480i regardless of how they're presented; the 240p standard was not created until decades later and even then it wasn't referring to the signal from retro consoles--and attempt to deinterlace them. This adds at least 1-2 frames (16-32 ms) of latency as the deinterlacer tries to combine 2 sets of fields to create a full picture, and that's before the signal even reaches the TV's upscaling circuit, which then adds even more latency (how much is added by the scaler can vary wildly from display to display).

To avoid this whole mess, we have a couple of options:


If you really want to use your big, digital HDTV but want to minimize latency, you'll want to sidestep the deinterlacing/slow-scaling issue by plugging your console into an external line-doubler/scaler. The cadillac in this area is the XRGB-Mini Framemeister, which is a Japanese import and costs an arm and a leg (about $475 at the time of this writing). This sexy lady will take your "240p" input, double the lines to a true progressive signal and then upscale it to an HD resolution that gets piped to your HDTV via HDMI, all essentially laglessly. It will even add in a scanline effect, if you want. If, like me, you don't have $500 to piss away on this sort of thing--awesome as it may be--there are some cheap Chinese boxes that can handle the upscaling and deinterlacing (but not the scanline effect) at a slightly lower quality and substantially lower price. This seems like a good compromise to me, though the loss of scanlines is unfortunate. However, if your upscaler has a VGA output (like these) and your HDTV also has a VGA input, you can put a separate scanline generator, like the SLG-3000 or Toodles' T-SLG, in between and get close to the same quality as the XRGB-Mini for much cheaper.

Another consideration, though, is that the XRGB-Mini also accepts SCART signals (see the 'Analog Signals' section below for more details), while the cheaper models like the one linked above only accept composite and S-video. :(

It's also worth noting that any of these upscalers will give you an extremely sharp picture, similar to what you get from unfiltered emulation with nearest neighbor scaling (i.e., super-sharp/pointy pixel edges), so this option is ideal for the pixel fetishists out there but may not be desirable to old-schoolers who grew up playing on crappy little CRT TVs.

If you chose to go the digital route, congratulations: you're done! Your upscaler is providing you with the finest picture available. However, you might still want to read the rest of the information here, as some of it may be useful to you anyway, particularly the parts about analog signal quality.

Personally, those digital, super-sharp pixels never looked good to me. I'm a big fan of the way CRT TVs look and how they handle those low-res images, so I am/was forced to purchase an analog CRT. Even on an old analog display, though, we still want to keep our picture as nice as possible, which brings us to our next concern:


As far as analog signals are concerned, the top of the heap is RGB, meaning you get an isolated signal for each color, which provides a crisp, clear picture when they're all combined. Just below that is S-video, which separates the luma signal (brightness information only; produces a black and white picture) from the chroma (color; R, G and B all together) signal so they don't interfere with each other. Far below that we have composite--the familiar yellow RCA jacks--which combines chroma and luma into a single signal where interference between the two (known as chroma/luma "crosstalk") significantly degrades the picture. Slightly below composite(!), we have RF, which takes the signal and encodes it into the same format used in over-the-air broadcasts (and you know how good those tend to look...). You can compare how these signals differ in quality by loading up an emulator with Blargg's NTSC filter, which has presets to emulate RGB, S-video, composite and RF.


In the USA, high-quality inputs, such as component and S-video, are not commonly found outside of large (24" and up), high-priced televisions, such as Sony's Wega line, so if you have a big house and plenty of room (and a strong back), you'll probably want to go for a real hoss of a TV with plenty of inputs. Sadly, most small CRT TVs have only coaxial/RF and *maybe* composite/RCA, which means your picture will always look pretty crummy. I lucked out and found an Apex 14" model with an integrated DVD player that also has S-video, which is good enough quality for me, so my retro consoles are now covered.

If--like me--you are satisfied with the quality of S-video and will only be hooking retro consoles up to your analog CRT, congratulations: you're done! If, however, you are a super-picky "videophile" and you think S-video is only fit for unwashed plebs and/or you want to hook your PC up to your CRT, there's more to consider:


Within the RGB family, there are about a million different subsets that each serve their own purpose. For TVs in the USA/NTSC world, we have "component" video (terrible, vague name, btw), which is also referred to by the color space it occupies, YPbPr. For PCs, we have VGA, which uses the familiar--typically blue--15-pin connector. For European/PAL-land TVs, we have 21-pin SCART.

Note: Europeans are lucky enough to have SCART as a standard input for CRT televisions, and many retro consoles--SNES, for example--can output this standard directly. This is a pure RGB signal and will provide the cleanest, most crisp analog picture around. HOWEVER!!, Japanese SCART and European SCART have a different pinout and, as such, are not compatible, even though they have the same connector. If you want to use a Japanese/NTSC SCART cable with a European/PAL TV with a Euro-SCART input, you will need a pin converter like this one. The aforementioned XRGB-Mini, as a Japanese device, should not require such a converter.

Aside from SCART, it's generally pretty difficult to get RGB from retro consoles, but it's usually possible if you're determined enough.

Now, even though all of these signals and connectors are technically RGB, they are incompatible with each other due to differing sync methods and signal frequencies, which means you'll need a display that is compatible with the signal and has jacks available. This brings us to:


One of the major limiting factors in a CRT is the horizontal scan rate, which is the frequency at which a display can move the electron gun from the left side of the display to the right and back again. CRT monitors, like the kind you would find attached to a crummy old Packard Bell computer, have a high horiz. scan rate of 31 kHz, while NTSC TVs have a comparatively low scan rate of 15 kHz. Furthermore, devices that expect the high scan rate of 31 kHz displays and send a high-resolution signal are not compatible with--and can actually damage--displays with the lower scan rate if connected. On the other hand, 31 kHz monitors can be coaxed into displaying a "240p" signal using driver hacks like CRT_EmuDriver or xrandr and/or custom xorg.conf modelines (for some excellent info on getting 240p in Windows, see Monroe88's comments after the post). This will produce the highest-quality image possible with an emulator:

The drawback to this setup is that each system you want to emulate needs to render in exactly its native resolution or else it looks like shit, with misshapen pixels and inconsistent scrolling everywhere. The specialized Groovy Arcade distro automates some of this, but you may still have to use your monitor's hardware calibration controls to get the image to fit/center properly. I found the constant tweaking to be a tremendous pain in my ass and not really worth it.

If you're in linux, here's how you can force your monitor to act like an NTSC TV (type into a terminal from an X-session desktop):
xrandr -q
This will tell you which display you're using and which modes are available by default. My display was hooked up to DVI-0 via a DVI-to-VGA adapter.
xrandr --newmode "240p" 5.979 320 332 368 380 240 242 246 263 +CSync
xrandr --addmode DVI-0 240p
(replace DVI-0 with whatever your card reports)
xrandr --output DVI-0 --mode 240p
Some older video cards (like my Radeon X600 pictured below) for PCs will have an S-video output next to their conventional VGA and/or DVI outputs, which allows them to connect directly to a standard 15 kHz TV with S-video input:

This is very convenient, but it comes at a price: the card presents an 800x600 resolution to the PC and then crunches that down to 480i (that is, a standard NTSC signal), and it *cannot* be convinced to do anything else under any circumstances (AFAIK). This output looks pretty good, but it's not nearly as crisp as the VGA 240p 31 kHz image, obviously:

On the other hand, it is only slightly worse than a direct S-video connection from console to 15 kHz TV:

While S-video will always be slightly blurrier than RGB, the 15 kHz display is simply not capable of producing an image as high-quality as the 31 kHz display's due to its lower resolution and larger, chunkier phosphors. If you have a TV with component/YPbPr jacks, you can use a VGA-to-component transcoder box--like this one--to keep a clean RGB signal from your PC to the TV. Since it's a 'transcoder,' you shouldn't suffer any signal degradation, ideally.

Sometimes you want to use your actual retro consoles rather than emulating on a PC--particularly in cases where emulation quality is still relatively poor, such as Sega Saturn or Dreamcast--but you still want to get the highest quality possible, which brings us to:


Broadcast monitors are high-resolution CRTs that were used by video professionals, such as broadcasters and video editors, to preview high-quality signals during the production process. They cost thousands of dollars new but are now cheap as dirt (relatively), since those professions have moved on to digital/HD signals and formats. Sony's PVM and BVM series of monitors are the most well-known and sought-after among retro gamers and, as such, often command a higher price than some similar products from other manufacturers. Nevertheless, the *VMs and other similar broadcast monitors tend to come with a variety of high-quality inputs, including one or more RGB equivalents (though often with separate sync, which can require conversion from, say, SCART). Another nice thing about these monitors is that they tend to come with nice, flat sides, unlike most TVs, which allows them to be rolled onto their sides easily for TATE mode games, like shooters.

Broadcast monitors are available in sizes up to 30" or so, though models that large are extremely hard to find and tend to be quite expensive, even now, due to their rarity. They are also very expensive to ship, due to their weight, which means many of the auctions on eBay are local-pickup-only (and tend to be in California...). The smaller models of 20" or less are much more common, and can usually be had for between $200 and $300 dollars at the time of this writing. A direct RGB connection from a console to one of these monitors should produce a picture as glorious as the aforementioned PC-VGA-to-240p-31-kHz setup, only without the hassles of modelines, hacked drivers, etc. Unfortunately, I don't have such a monitor, so I can't share any pictures :(

In the cases of either the 31 kHz or broadcast monitors, I personally find the image to be a bit sterile and actually prefer the 15 kHz option. I have opted to use the S-video-out on my video card for the convenience it provides, and the quality degradation is only about as bad as choosing bilinear vs nearest neighbor scaling in an emulator (i.e., fine for me, unbearable for perfectionists and pixel-lovers).

Anyway, here are some more PC-VGA-to-240p-31-kHz pics :D

Good detail shot of the scanlines and the black gaps visible between.
This is what happens to SNES pseudo-hires transparency (bsnes) for some reason :/

Some other considerations that I will add to this post soon: CRTs for 480p and higher consoles (PS2, Dreamcast, 360, etc.), 31 kHz at 1024x768 (shaders vs the real thing), I plan to add a decision-making flowchart with approximate costs at some point, as well.

Friday, March 21, 2014

Repairing/Replacing N64 Analog Stick

I recently purchased a small CRT TV and have been hooking my old consoles up to it, and I noticed the analog stick on my N64 controller was in pretty rough shape. The deadzone was gigantic and it was affecting my performance in some games, so I decided to look into repairing or replacing it with a new stick.

I settled on this replacement stick, available for $11 from Amazon at the time of this writing.

The replacement process is very easy and takes only a few minutes, with no special tools required other than a small philips-head screwdriver, though a flathead screwdriver and some needlenose pliers will make the job easier.

To start, just flip over the controller and remove the 7 large screws on the back, then remove the 2 small screws next to the memory card / rumble slot (they're easy to miss/forget):
You should then be able to lift the back panel off, which should reveal something like this:
The circuit board and rubber membrane for the Z-button are held down with little plastic clips on the sides of the analog stick assembly, so unclip the board and set the rubber membrane somewhere safe.
The R and L buttons are just sitting in their homes, held in by a tiny plastic peg-in-hole system, so you may wish to remove them at this time, as well, just to get them out of your way:
Next, remove the 4 small screws that hold the analog stick assembly in place (in my case, 3 silver screws on the sides and and bottom, and 1 black screw in the middle) and lift the assembly out. It will still be connected to the PCB by a connector, which you should be able to slide out (pictured below):

Mine was very stubborn and required holding the connector housing in place with my fingers while prying with a flathead screwdriver, alternately loosening the sides until it popped out.

Once it's out, you just do the steps in reverse. The connector assembly was the biggest hassle and required some squeezing with my needlenose pliers before it would snap into place. The wires on the connector are pretty small, so make sure you don't accidentally damage them while squeezing, and don't rip the connector housing off of the PCB!

I had an additional screw left over (the middle black one from the analog stick assembly; it's actually part of the OEM stick assembly), but I just stuck it into the hole they left in the new analog stick, even though it doesn't thread into anything.

And here's the finished product:
This stick is more like a Gamecube or Xbox 360 analog stick than the OEM N64 sticks, and as such feels much sturdier. The movement is also largely frictionless, unlike the OEM sticks, which makes it superior for games like Mario Party that really wear out the OEMs (and your palms). On the other hand, the sensitivity is really high and it's difficult to do precise aiming on games like Goldeneye and Perfect Dark, as the reticle tends to jump around a bit when you try to zero in on a small target (like a head...). For this reason, I will likely keep at least 1 controller with the OEM-style stick around for that sort of thing.

Friday, November 8, 2013

AT LP120-USB Turntable Mod

I got a sweet deal on an Audio Technica LP120-USB turntable from Essex, a place that sells factory rejects, refurbs, and other "almost new" products at a steep discount. The dust cover was busted up*, so I assumed that was why it was there. Unfortunately, it also exhibited some infuriating behavior whereby the left channel would randomly cut out, though I didn't discover this until much later. :(

I suspected the internal preamp was the most likely culprit, so I followed this tutorial describing how to bypass the preamp entirely and push the untouched phono signal straight out to the RCA cables (which I may replace with jacks soon, instead). Honestly, there's not much too it. You just cut out the board and splice up the RCA cables directly to the red/white/ground wires.
The removed preamp board.

I was pleasantly surprised when, in addition to fixing my channel dropout problem, the sound quality seems considerably better in the high frequency range. This improvement is why most people do the mod in the first place, and the above link contains some pre-mod and post-mod recordings to help potential modders decide if the improvement is worth their time and effort. I could not distinguish between the two recordings in ABX testing, but the difference in person is easily noticeable. For example, the natural crackles and pops on the records were very subtle and difficult to hear pre-mod but are easily audible post-mod. This may not sound like a particularly positive development, but it's unsettling to think that I was losing that much sound off the top before.

*I was able to piece everything back together with some super glue, but you can also purchase them new from Audio Technica (you can email their customer service) for around $30.

Wednesday, November 6, 2013

Quark Shaders for Higan/bsnes v093+

As of v093, Higan (previously known as bsnes) includes a new shader format based on OpenGL 3.3 / GLSL 1.5. This format is nice, powerful and roughly as flexible as RetroArch's Cg support. Hyllian, aliaspider and I set to work converting many of the most popular shaders to the new format, available from the Quark Shader Github repo.

If you're not familiar with git, you can download the full repo by clicking on the 'Download ZIP' button in the right-hand margin.

To use these shaders, place the entire *.shader directory into your Video Shaders directory. One caveat: the handful of shaders that utilize motion blur won't work with v093, but should be functional with v094+.

Monday, October 14, 2013

RetroArch Overlay Borders

RetroArch has long had support for fun borders/backgrounds that can fill the unused black space on HDTVs using a specially crafted shader combined with an image, as described in a previous post. However, this system can be finicky and it isn't very forgiving of different screen sizes and aspect ratios. There is another way to achieve a similar outcome, though, using RetroArch's built-in overlay system.
Gameboy border pictured with Harlequin's Gameboy shader
This system was designed to provide onscreen touch controls for the Android and iOS ports of RetroArch, but we can use the same hooks on PC to display our borders. All you have to do is add this to the bottom of your retroarch.cfg:
input_overlay = "/path/to/overlay.cfg"
(you can also find this option in the now-deprecated RetroArch-Phoenix launcher under the 'input' menu)

The overlay.cfg file is extremely simple, containing only 3 short lines (you can either copy these into a blank text file yourself or use the one I include in the download at the bottom of the post):
overlays = 1
overlay0_overlay = border.png
overlay0_descs = 0
This file tells RetroArch that there will only be 1 overlay, which image to load as the border (in this case, border.png, located in the same directory as the overlay.cfg) and that there will be no buttons attached to the overlay (that is, for touchscreen controls).

In addition to these border effects, you can also use this system to apply semi-transparent overlay effects, such as scanlines, which can be useful in very low-power settings, such as on Raspberry Pis or older cell phones that can't handle even lightweight scanline shaders. Even some MAME "rgb" effects can be used with this system with minor modification.

Depending on your setup, you may need to unlock your aspect ratio and/or manually set the aspect ratio to match your display. You may also need to use an integer scale shader, which I have included in the download package.

This system will work fine with the borders from my previous post, and here's a bunch more (formatted for 1920x1200 displays) from NeoGaf user richisawesome.

Here is the download (contains border.cfg, two example borders and an integer scale Cg shader):

Analytics Tracking Footer