Android Camera & Video, OpenGL

Ahh, somehow I ended up hacking most of the Saturday rather than taking advantage of the relatively pleasant weather to do something better. Addicted I guess. If the weather holds today ... maybe i'll get out.

I was just going to have a quick look at android camera operation, but one thing lead to another ...

After I got a basic camera view working, I wanted to work out how to present it in opengl. So I got pretty side-tracked trying to work out some opengles2 stuff - the examples and suggestions on the net were usually small fragments or for opengl1 - until I found the android sdk sample they all came from which had everything I needed (GL2CameraEyes or somesuch, my workstation is off now). GLES2 is a bit of a pain and requires a lot of scaffolding to get started, but I guess it is what it is.

So yeah, camera to texture, texture to display, etc.

Also checked out taking photos, and recording videos - although the latter requires a preview view, and wouldn't work with a GL 'preview' window so I gave up on that in this context.

The basic objects are a bit bare, but they provide enough functionality to be usable, and are generally fairly simple to use once you know how.

"Broadcast Quality"

One thing that is a bit disappointing is the frame rate achievable. Even with a simple GL render loop it doesn't match the frame-rate properly and you get skips and drops. It's almost like the screen and GL are refreshing at different rates. I tried a dirty-refresh-on-camera-frame, as well as update-continuously-refresh-texture-when-camera-frame, but both ways were simply not smooth.

For fucks sake even a fucking Commodore 64 could generate video-rate-smooth graphics.

(Even something like GL gears, a simple demo which should easily manage a solid and smooth 60fps, is not properly smooth, although it might be the internal animation calculations that are out).

Because of this, and the stupid choice to use a 60hz panel (my laptops run at 50hz for this very reason), one of the few things that might actually be useful on a tablet - watching recorded tv shows or movies - is actually a pretty crappy experience (if you can even get it to work in the first place). Movies on a 50hz display running at 25fps look a LOT LOT better than telecined crap on a 60hz one.

People are so used to totally woeful 'pc graphics' these days nobody even notices or cares (horrah: at least there's no bloody tearing!).

Even tv stations no longer seem to care about 'broadcast quality' any more - I guess the old guard engineers who knew the difference are being replaced by kids who spent more time on youtube than watching broadcast tv). Sport looks like it's been shot with a pocket camera and run through a single-pass of ffmpeg encoding at middling settings - severely blocky from lack of bandwidth and just not very good. And we're often getting American version of movies now - i.e. which have been fucked up by being telecined to 60fps to start with - and here they are just blasted out at 50fps using simple nearest-frame or sometimes average frame 5+6 output both of which looks totally totally shithouse (9, 7, and 10, i'm looking at you). And even when they do have PAL source, sometimes the interlaced frames are flattened to 25fps(AND THEN SCALED!!!), and encoded at 25fps progressive: which is astoundingly bad.

So why did I buy that giant TV for again? Well at least I can read the current score or the news ticker from the couch ...