Tuesday, April 26, 2011

First steps

Ffmpeg, on which I have decided to base the vidplay's decoding, is a library for C. Luckily, C and Python are integrable rather easily, since Python is based on C, and there are a number of ways to cause programs written in the two languages to interact. In some final draft I plan to compile a real installable Python library, but the quickest (and dirtiest) way that I know of to run C code from Python is the ctypes library.

In my first stages, I wrote a rough decoding function in C based on this tutorial. I hadn't really done considerable amounts of work in C before, so I found the code a bit confusing, but after some work made sense of it, and managed to modify it slightly to encode each frame of video to an array passed in standard RGB format and  pack it up nicely in a dll which I can call from Python.

In Python, I used Pygame's handy surfarray module to create a Pygame surface complete with image data from the decoded frame, converted it to a numpy array, and displayed it to the screen! My first step was achieved: data decoding and transfer.

Now, I wrote a quick Thread in Python to decode the data on the fly (Python 2.5, the preferred version for Pygame, does not support multiprocessing), and had the dll decode continuously to an array generated by ctypes and passed from Python. This was nice since I could handle all timing of playback in the C and Ffmpeg proper, and have Python play back each frame whenever it was ready and relevant. However, I reached my first major bottleneck, one that is inevitably hit in any processing-intensive Python project: Python is excruciatingly slow. On a virtual machine with a 1.5 ghz processor and 758 meg of memory, running XP, I achieved about 1.5 frames per second.

My code sits there now, ready for tinkering. I have to cut out much of the junk, delegate as much processing to the C code as possible, and see how much I can improve performance. If that proves to be not enough, I may move from using surfarray to the hardware-accelerated Pygame YUV overlay , but I really don't want to do this, since I have had some difficult time with hardware-acceleration in Pygame in the past, and am aiming for maximum compatibility. If multiprocessingincreases performance considerably, I may move up to Python 2.6 (though Pygame is not as well supported as in 2.5 there yet).


Friday, April 22, 2011

Snaky Playback - vidplay for Python

There exists a wonderfully simple and easy game programming environment for Python called Pygame: http://www.pygame.org/
I haven't created any games for the public yet (sorry, my scant readers) but I am using Pygame for various projects (they are a bit hush-hush for now).
Being used to the idea that everything in Python is easy, I thought that video playback would be a matter of play(videoname), and decided to build videos into my project. But oh no, life cannot be so sweetly easy. There seems  to be a dearth of video playback tools for python, all of them complex and/or badly maintained. The largest and most established option, pymedia, is much too complex for me to enjoy easily.There is a video playback option for Pygame in linux: http://www.pygame.org/docs/ref/movie.html , but this does not work on Windows, and this will not do at all!

With Windows video playback in mind I have set out to wrap a simple ffmpeg based video decoder in a dll library (and a .so library in Linux), which will then send the decoded data to a playback script I will write in python.I call the library vidplay so that I can ultimately do this in python:
import vidplay


And that's it!

Hopefully I can extend this to a legitimate ffmpeg-based python library in the future, but for this initial stage functionality will be king, though it may make usage a bit scrambled.

Wacom tablets

On some rather expensive whim, I bought a Wacom Bamboo Pen, which is a pen-based mouse input tablet that is useful for drawing using programs like Gimp, Inkscape, Photoshop, and CorelDraw.

The linux driver project seems to be in an in-between stage as it is being updated for newer xorg versions, but thanks to this article I was able to install it。.

However, there has been a slight change: xf86-input-wacom is unavailable, and
all I could get was wacom-dkms. Luckily, xf86-input-wacom can be built from source and I got it and compiled it directly from the linux-wacom project site as per the instructions here: http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Building_the_driver

I then proceeded to activate my Wacom Bamboo pen tablet in Gimp, which is done quite easily by just going into Edit->Preferences->Input Devices->Configure Extended Input Devices . Once in there, you can select all the Wacom options and change them from "disabled" to "screen".

With my newly pen enabled Gimp install, I made a logo for the blog.Enjoy the eggy goodness!

Good luck to all linux pen tablet users!

Welcome to Scrambled Code

Hello visitors (few though you may be). I have begun Scrambled Code as a place to keep track of progress in my various programming projects that I believe may be of some small (read: extremely tiny) interest to the coding community. I plan to post a log of my experiences in my coding projects, as well as solutions to any technical problems I experience in using my operating system of choice, Ubuntu Linux, and my operating systems of necessity, Windows XP and 7. I hope my posts can add something to the vast sea of information (and blathering insanity) that is the Internet.
I believe the following Japanese phrase is appropriate (Google translate does
not do it justice):