I'm still here!

So I've been up to a bunch of stuff over the past few months, but unfortunately my Windows development including vidplay has not been moving very quickly thanks to my migration to Windows 7 64-bit, which despite the inconveniences of having to re-install and re-setup everything, is a great improvement over XP in Virtualbox, which was my previous setup. It hasn't helped that I've had to split my time over Linux and Windows as they are on separate disks now, and I've avoided the Windows partition a lot over my preferred Ubuntu.

Still, things are starting to rev up pretty well. I'm getting into 3d development with OGRE on Windows, as it's a pain to set up on Linux, and any games I make will have to support Windows as well as Linux. I'll post about my development scheme when I have it finalized (I'm compiling the samples for the second time as I write).

Okay, next post soon, I hope!

ちょっと待ってね。

Batch converting videos with ffmpeg on Windows

Recently I required edited videos with a specific bitrate. I supplied the video editor with a relevant ffmpeg command to convert his work into the format I need. He asked me how he could batch convert them, and I, a *nix user, was momentarily stumped. Then based on this tutorial, I created a one line batch script that will convert all files of a given type in the current directory:

FOR %%i IN (*.avi) DO ffmpeg -i %%i ... rest of command ... %%i.mpg

I hope this helps someone random on the interwebs!

コメントを投稿してくださいね！

Well, it's been over a month since my last post, so I feel like it's time that I updated a bit. I've run into my expected performance issues with vidpy, and I haven't yet figured out how to get things to work with pygame's yuvoverlay(). For the next two weeks or so the project is on hiatus as I use pygame's built-in movie() module to play back sub-par MPEG1 video for my current (commercial) project, but I hope to bring vidpy into a workable state and thereby push multi-format support into my project during the summer. In the meantime, as a distraction, I've been playing with Android development and HTML5's canvas.

Android is complex and a bit slow, and HTML5 Canvas is VERY slow, but I hope to have some interesting demos or minigames out before the end of the summer. My vacation's just started and it's already moving by too quickly!
夏休みは始まった。夏の遊びは楽しみです！

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

仕事は始まった

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

vidplay.play("videoname.mpg")

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!
卵の画像おくれて有り難うございます、google画像検索！

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):
よろしくお願いします！