Monday, November 24, 2008

HandBrake with Live Video Previews

The HandBrake team has released version 0.9.3, which includes official, sanctioned builds of the GTK GUI in both 32- and 64-bit formats. This new version also brings a number of improvements that have been enjoyed by those of us using the SVN builds for some time to the rest of the HB users. However, new features are constantly being added, and the codec pool is always being updated, so I will continue to post the latest bleeding-edge builds here on my site, starting with svn1952, which includes live video previews (!), as well as a more recent version of the x264 and ffmpeg codecs.

Update (5/15/09): I have working binaries of the latest code available in my PPA repository. Directions for adding it to your package manager are available here.

Here's how the live preview looks. You can really get in there and see the direct impact of your changes. This leads to better cropping and a better sense for your end product. (this is my Mac x-forwarding GHB from my Ubuntu box. As you can see, the live previews even work through that):

For those of you who wish to compile on your own hardware (recommended for those with newer Core 2 Duo CPUs), the process is exactly the same as my previous SVN instructions, except for the addition of 2 new dependencies: libgstreamer0.10-dev and libgstreamer-plugins-base0.10-dev. I've updated the instructions there to reflect the change.

Saturday, November 15, 2008

How to run ZSNES Super Nintendo Emulator on 64-bit Ubuntu Linux

ZSNES is my favorite SNES emulator in the Windows world, but it can be a real pain to get going in 64-bit Linux. Most tutorials will suggest you set up a chroot jail and maintain a parallel set of 32-bit libs so that you can run the 32-bit version, but this is both a hassle and overly complex for many users.

I tried to compile my own binaries from source to avoid this, but I kept running into architecture errors and ended up throwing in the towel after a few hours of fiddling. Luckily, a ZSNES developer known as Nach has provided specialized precompiled binaries for a variety of architectures that worked a treat for me.

Just follow this link, scroll down a bit, and then download the binary that matches your architecture. I have an Athlon 64 X-2 4000+, so I selected the Athlon64-SSE3 binary.

Next, install libsdl-dev either through Synaptic or by typing sudo aptitude install libsdl-dev into a terminal.

Once downloaded and decompressed, you should find your binary inside, which you can run by double-clicking it or typing ./zsnes into a terminal. If you double-click and nothing happens, try running it through the terminal to spot any errors. I personally encountered this error:
Unable to poll /dev/input/event8. Make sure you have read permissions to it
repeated 9 times (1 for each /dev/input/event* 0-8).

I was able to get around this by running ZSNES as root (i.e., sudo ./zsnes), which is certainly not ideal, but I haven't found a way around it yet.

If you take this route, be aware that the default location for saved games will not be ~/.zsnes as it normally would be. Instead, it will be located in /root/.zsnes (since you're running as root). This in mind, you may have to copy your .srm files into this directory for them to be recognized. When I first got my copy to run, I couldn't get it to recognize any of my saved files, even though I tried changing the path for saved files under the preferences. However, once I copied the files into the /root/.zsnes directory, everything showed up just dandy.

Using the native 64-bit binary referenced above also had another unexpected (perhaps coincidental) positive effect of making my gamepad's d-pad work correctly. Using dfreer's zsnes32 binary worked well for me in most respects, but it just wouldn't recognize my Logitech Precision gamepad's d-pad. The buttons worked fine, but when it came time to assign the directions, it would just sit there dumbly, even though jscalibrator and cat /dev/input/js0 both showed plenty of action. This problem remained no matter how many kernel modules I loaded (usbhid, analog, etc.), until I tried Nach's binary. Now it works just fine. Go figure...

This information was written for Ubuntu 8.10 Intrepid Ibex, but it should be applicable to other distros as well.

Friday, October 24, 2008

Intrepid Ibex broke my Netatalk

I mostly use Macs, but all of my media files are stored on a home server that runs Ubuntu. I had been using Gutsy and sharing my files using netatalk, an open source implementation of Apple's AppleTalk protocol, and everything was working swimmingly.

However, as soon as the beta for the newest version of Ubuntu--known as Intrepid Ibex--was released, I upgraded to it and was shocked to find that I could no longer connect through netatalk using my Macs (they're running 10.5 Leopard). Every time I tried, it would fail with this error:
A volume failed to mount.
The volume [directory name] could not be mounted
I fiddled with configurations on both ends to no avail, so I decided to try a workaround: I uninstalled the version of netatalk from the Intrepid repos (sudo aptitude remove netatalk) and then downloaded outdated deb binaries for netatalk and its only other major dependency, libdb4.2, from the Gutsy repos.

Install (sudo dpkg -i [package name]) libdb4.2 first (it'll give you a warning about downgrading from a higher version), then netatalk, and then let the service start. You should now be able to connect to your shares again.

Leave me a comment if this doesn't fix your problem and I might be able to help.

Monday, September 29, 2008

How To Compile HandBrake With New Psy Options Enabled

Update: It looks like the new x264 version is committed to the SVN repo now, so you should be able to just perform Steps 1, 2, and 5 (i.e., a normal SVN checkout and compile) to get the new psychovisual options.

Update (5/15/09): I have working binaries available in my PPA repository. Directions for adding it to your package manager are available here.

Here are directions to download and install the latest development code for HandBrake that can take advantage of the revolutionary new psychovisual additions to the x264 codec (known as psychovisual rate distortion [psy-rd] and psychovisual trellis [psy-trellis]).

Step 1: check out the latest source code from SVN:
svn co svn://svn.handbrake.fr/HandBrake/trunk HandBrake
Step 2: navigate to the new directory
cd HandBrake/contrib
Step 3: edit the download location for the x264 codec in your favorite text editor (I prefer nano):
nano version_x264.txt
then, either delete or comment out (put a # in front of it) the address that is already there and replace it with this:
http://download.m0k.org/handbrake/contrib/x264-r979-6d4af8d.tar.gz
Step 4: return to the HandBrake directory:
cd ..
If you just want to use the CLI version (Linux users have no choice), you're almost finished and can go straight to Step 5. If you are using OS X or Windows, though, you can update the GUI interfaces to reflect these new options by applying the appropriate patch (for OS X or for Windows)

To apply the patch, move it into the HandBrake directory and type into a terminal:
patch -p0

Step 5: compile as usual:
make
That should get you all set. The new options require a subme value of ≥6, which should be the new default (and should be reflected in the GUIs and presets). If you have any questions or concerns, leave me a comment and I'll try to help.

Friday, September 19, 2008

HandBrake With New Adv. x264 psy-rd

Update: I just finished conducting some tests using live, film-grained content and the details are posted below the cartoon data.

x264 just committed some fancy new features, known as psychovisual rate distortion and psychovisual trellis, to their git repository. These features are supposed to produce a subjectively superior picture by maintaining detail and minimizing blurriness during the encoding process (I guess; read more about it here, at the blog of Dark Shikari, a developer for the x264 codec).

However, if you read the posts at the Doom9 forums linked in his blog post, they mention that Peak Signal To Noise Ratio (PSNR)--basically the only objective measure of picture distortion available to me--will always be negatively affected by the new features, and freeze-frames will also look worse. This makes the new features sound a little like voodoo to me, since I tend to favor objective measures over subjective ones. Regardless, I decided to try it out.

I used a bitrate of 250 in an mp4 container with these adv. x264 settings:
ref=5:mixed-refs:bframes=6:bime:weightb:b-rdo:me=umh:subme=7:
filter=0,-1:trellis=2:threads=2
For the psy encoding, I followed those settings with these psy-specific options (first number sets the psychovisual rate distortion [value from 0.1-1] while the second controls the psychovisual trellis [again, 0.1-1]):
psy-rd=1,1
If I understood things correctly, psy-rd only works with a subme setting ≥6, btw, so keep that in mind if you want to use the psy settings. Here are a couple of screenshots from an episode of Futurama encoded using otherwise identical settings (v0.9.2 on the left [no psy], svn 1734m [psy-enabled] on the right):

As you can see, it's a pretty noticeable difference favoring the psy shot, especially in a few key areas. Of note, you can see significantly less blocking on the dark spots on the cloud in the psy shot, and the top platform against the red sky is much sharper.

Now for the numbers:

As expected, Avg. PSNR fell from 42.602 to 41.557 in the psy encode, and Global PSNR fell from 40.655 to 39.641.

Dark Shikari and the Doom9 guys said that encoding speeds would be relatively unchanged, and mine fell only slightly from approx. 20 fps to approximately 18 fps. However, despite using the exact same bitrate option, my filesize increased from 56.6MB to 58.1MB, a difference which may partially explain the picture improvements.

Apparently, the psy options really shine in retaining small details, which are necessarily absent from cartoon sources, so I intend to do another comparison soon using some live-action sources, including at least one with visible film grain.

Stay tuned.

Another potential concern to keep in mind is that, as usual, QuickTime can have trouble with these new options, especially using the Perian codec pack. It can make strange graphical glitches and generally look like shit. Stick to VLC if possible.

Update: I conducted similar tests to those performed on the cartoon source using the Kubrick classic, Dr. Strangelove. This source has some serious film grainage thanks to its age, so we can really see what psy-rd is all about.

I've taken my clips and dropped them into an animated gif, so click on the picture to see the comparison:

The first thing that really jumped out at me is that the psy version is much darker overall, with a much higher contrast ratio (i.e., the blacks are blacker, whites whiter, and the picture looks less gray). It's arguable whether the detail is better in these still-shots with psy-rd added, but it looks much sharper in motion.
Now the difference between the 2 encodings really comes out. Again, the psy-enabled shot is darker overall, with a higher contrast ratio, and the film grain is highly evident. In contrast, the non-psy shot looks as though a smoothing filter has been run over it, steamrolling the details.
Here, just as in the previous comparison, the differences are stark and easily noticeable. Hell, you can almost read the letter through the backside of the page!

Now for the numbers:
As in the earlier experience, avg. PSNR fell from 43.616 in the non-psy encoding to 42.602, while global PSNR fell from 43.371 to 42.347. Again, frames per second remained relatively stable between the 2 encodes.

Conclusions:
After the somewhat underwhelming cartoon-based comparison, I was undecided as to whether I would upgrade to the psy-enabled version, but this comparison has definitely sold me on it. In certain cases that have a lot of small, fine details (such as with Dr. Strangelove), the psychovisual analyses can create a 250 kbps video that rivals an 800-1000 kbps xvid encoding. This means smaller file sizes and faster streaming, which is always a good thing.

Let me know if you have any questions or comments.

For directions on compiling your own binary with the psy options enabled, visit my post here.

Cari Farmasi

Farmasi Di Kuala Lumpur dan Selangor Selangor / KL Area NO SHOPS NAMES ...