Amphibious Thoughts

I had the idea to build a kind of solid state video player using Linux and Puredata with an Arduino. The educated reader might ask “Why PD?” and, of course, is right. The simple answer is: Because I can and its easy.

I take the latter back. When I came up with this I had totally ignored, that Puredata/Gems Pix_Film object doesn’t play sound. This means, video and sound have to be played in separate players and then be synced. Some research in PDs list gave me an example I started working with and I was partially successful. Video and sound sync well with a [vline~] but with high resolutions the sound glitches. This can be reduced by trying different video codecs (motionjpg is supposed to work pretty well) but still I wasn’t able to play 1280×1024 videos without the sound dropping sometimes. I didn’t have this problem using the [pix_buffer] object, but this way the video is loaded into the RAM uncompressed, which takes up tons of space and limits the possible length of videos loaded/used. This was on my MacBook with 2x2GHz and an onboard Intel 9400m graphics card. I will try it on Linux in the next days, lets see, if it works better.

However, I expect no wonders and theres no sense in building a solid state video player that needs hardware this expensive (and energy intensive). I want to use one of these fit-pcs, loving their small design and power consumption. For them to work with videos of that resolution I need to use their hardware acceleration, which might prove difficult on Linux (I heard nothing good about the support of intels gma500) and even worse when relying on PD/Gem, which uses OpenGL to render video. So the plan now is to use a common video player like VLC or mplayer and remote control it via network/localhost. That should take care of the hardware acceleration and still make use of the serial interface and interaction possibilities of PD. Stay tuned…

This patch syncs video and audio