ffmpeg is an extraordinary program, it seems to deal with just about any video format I care to throw at it.
If you are not one of the enlightened, ffmpeg is a command line tool which supports transcoding of content from one format to another. Many of the $10 video converters on-line are simply rips offs of the ffmpeg code base with a crap UI on top. (see the mmfpeg hall of shame for uncredited use)
As with any command line tool, the complexity of the arguments kill it for most. But generally you will be encoding for a particular device or standard format and so a quick google will give you the options you need.
I’ve been using ffmpeg to convert video content (including iplayer films) for Sony Walkman NWZ-A815 (which is very particular about the video size and bitrate).
I can’t even remember what the options do, but I wrote a python script to transcode all videos in a directory and spits out about 290mb per hour of video (assumes ffmpeg.exe is in your path).
import glob
import os
fileNames = glob.glob("*.*")
print(fileNames)
commandTemplate = "ffmpeg.exe -i \"%FILENAME%\" -b 567k -s 320x240 " + \
"-vcodec mpeg4 -ab 220k -ar 44100 -ac 2 -acodec libfaac \"%FILENAME%_TRANSCODED.mp4\""
for file in fileNames:
if not "TRANSCODED" in file:
command = commandTemplate.replace("%FILENAME%", file)
print("Executing: ",command);
os.system(command)
I’ve had a Kaoss Pad KP3 for a couple of years now. It’s a ‘hands on’ audio effects processor which has a touch pad that can be operated by fingers.
see the video below to get an idea:
The KP3 supports a MIDI out facility which pumps out MIDI events in response to touch pad or knob twist events. I’ve been meaning to write a driver program for this as I think there are some interesting possibilities in the field of live audio and video effects at events.
Just spotted that ‘Crayon physics’ has been ported to the iPhone. I’d be interested in how well it works with a finger.
In case you haven’t seen it. It’’s a game in which you have to get a ball from one platform to another by drawing 2D shapes which ‘come alive’ – obeying the laws of gravity. For example, if you draw a closed roundish shape with your finger at the top of the screen, it becomes a heavy boulder which falls to the ground, being deflected by anything in its path.
See here:
Some time ago I introduced the PC version of the app to a customer (a handset manufacturer) and suggested that it would make an excellent product differentiator if they bundled it exclusively with their soon to be released touch phone.
At the time, the word differentiation was on just about every power point deck with big companies craving for original ideas, encouraging “blue sky thinking outside of the box” (to use Ian Pegler speak).
Anyway, the idea was not taken up, but I thought it at least interesting to document the reasons why I think this game should have been snapped up for ROM:
It’s playful – you can waste some time at the doctor’s waiting room without really caring too much if you have to put the game down (a bit like snakes)
It has a viral quality – it’s the sort of game you want to show your friends
It offers design/UI cachet so craved by some of the handset manufacturers
It’s 2D – 3D was one of the worst things to happen to game play
I wonder if it could work on the Nokia5800 touch. I’m not sure if the screen is big enough for Crayon Physics to really work, but certainly the stylus is the perfect tool for drawing.
Box2D
Incidentally, a lot of these recent physics toys are based on the excellent Box2d algorithms and library. Box2D was originally a C++ API for simulating constraints in a 2D plane. It’s fast and visually pleasing rather than an accurate physics simulator.
It has been ported to Flash and Nintendo DS, and you can see some of the demos.here.
And for those who are interested, a Symbian/S60 port has been attempted here.
My head hurts. For some reason the mobile industry loves to confuse something really simple like a screen sizes.
There are three aspects to screen size.
Pixel dimensions – on an LCD display, this is simply the physical number of columns and rows of pixels which make up the display.
Resolution - Pixels per inch/cm. Two values for x,y tell you how far apart the rows and columns of the display are from each other, the density.
Display size – A ruler measure the physical width and height of the screen.
It’s possible to have a 1024×720 display the size of a postage stamp if the resolution is very fine.
This can get confusing, but explicitly using “Pixel dimensions”, usually clears up any misunderstanding. The problem is that pixel dimensions are often specified in esoteric video terms such as 1/4VGA. Here are some of the “resolution” labels which I’ve encountered at work in the last week.
Pixel Dimensions
Width
Height
Number of pixels
QCIF
144
176
25344
QVGA
320
240
76800
CIF
352
288
101376
1/4HD 720p
640
360
230400
VGA
640
480
307200
D1
720
480
345600
HD 720p
1280
720
921600
The names are a mish mash of video standards and display standards and the disjointed nomenclature also makes it hard to compare dimensions. I forget if a QVGA is larger than CIF, or a VGA larger than 1/4HD.
I wonder if we could save a lot of hassle and just use the actual numbers. “320×240″ is not that much more to write than QVGA and has the advantage that landscape orientation can be indicated by switching the numbers to “240×320″. Crazy diagram: - Wikipedia::DisplayResolution
Camera optics are complex things. Anyone who has ever read a photography magazine or tried to follow a discussion on-line will have been baffled by jargon such as F stops, focal length, film speed, wide, telescopic, tilt and shift, and so on.
The basics can be learned relatively quickly, but sensing the best combination of light, lenses and stop which will capture a scene the way you want is a big investment in time and experiment. It’s the art of photography.
So given the many factors to choose from to get a ‘good’ image. It’s not surprising that camera marketing folk have capitalised on the mega pixel. It’s a simple scalar analogous to the GHz of the PC world. In other words, more is better, and that’s all you need to know.
It doesn’t take much investigation to work out the lack of correlation between image quality an mega pixel is often coincidental. Nokia have started to put much better Carl Zeiss lenses on their N series phones (and in some cases protect them from pocket dust which has a much more drastic effect on image quality). But still, a lot of people I encounter seemed to have been been inflicted with a pathological pixel inadequacy.
Of course, with a simple quality metric comes a irrational arms race. Marketing express their requirements to engineering in terms of ‘more pixels than competitors’ rather than image quality, simply because that’s what the free-market demands.
So I was quite pleased when a friend who studied fashion photography passed this link on to me: http://6mpixel.org/en/
It describes the image depredation due to noise which occurs when using really dense sensors. I.e more mega pixels are not just a waste of disk space but also there is a point where the quality degrades. It’s very interesting to see actual sensors lifted from various cameras.
Please do your bit, go see a psychiatrist about your pixel envy.
I saw it again today after a few years out of sight, out of mind. It has grown at least another 60 inches. I’m taking about a C++ constructor in some production code which is 1876 lines of code long. Yes, an object so complex that it takes close to a minute to scroll through it using MSDEV.
I felt nauseous on seeing it. It’s a bit like one of those Channel 5 documentaries “Woman who weight less than her tumour” or some other attention deficit grabbing title. You just can’t imagine how it can grow so big without someone noticing.
I can imagine the development team seeing a new requirement which involves finding the right point in the constructor to instantiate their new object. “Let’s give it to the new guy”.
Surely at around line 999 you must realise that your architecture or you supplier’s is FUBAR’d.
Please let me know if you are aware of bigger one.
I recently had cause to run some of my old benchmarking code on a couple of recent Nokia devices. I wrote one benchmark to quanify the tradeoff beteween RAM and performance when comparing the bit depth (and hence RAM foot print) against the blit time (drawing performance).
The performance graph below shows the median performance figures achieved when copying to the screen, bitmaps of different depths (those supported by Symbian OS9.0).
The rate is measued in Frames Per Second (FPS) which is a value arrived at by taking one over the mean time for a single bitblit. As an example, if it takes 500ms to draw one frame, then 1/0.5 = 2 FPS).
There are two striking results from the data
The native bitdepth of the sceen EColour16MU is massively faster than any other display mode (on both devices)
The N95 is more than twice as fast as the E61 at all bit depths
It’s fairly simple rule that on these devices, performance dependent use cases should always use EColour16MU. And from experience this can be generalised as “For performance – match your offscreen bitmap to the depth of the screen”.
I’ve had two Sony cybershot cameras over the last few years, and they were a marvelous introduction to digital photography. One feature I particularly like was the multishot mode where sixteen shots are taken in quick succession.
From a technical point of view, the shots can be taken rapidly because each shot is a reduced resolution image stored as tiles in a single photo frame.
(click on the image for a larger view)
I quite like seeing the images laid out like this, they look similar the supersampler Lomo cameras with 4 lenses on them. However, I often want to play the frames back in an animation. This could be done using photoshop to copy each frame out and paste as a new layer and then save it as an animated GIF, however it’s too fiddly and error prone. So I decided to write a python program to help.
After some hunting around. I found the wonderful PIL (python image library). This library doesn’t do everything I need, notibly it can’t write mutiframe GIFs.
The code simply chops an image up into bitmaps(.bmp) which you can assemble with your favourite animation software. The reason for choosing bitmaps is to avoid further lossy compression.
This to me demonstrates the power of throw away ’scripting’ in the creative process. If you can express an idea or automate a laborious process in a few lines of code then the programming environment itself part of the creative tools suite rather than applications created by the programming environment. Fab.
