John's blog

No nonsense video transcoding on windows

posted 14 Sept 2012, 02:28 by John Stavrakakis [ updated 14 Sept 2012, 02:29 ]

I am a fan of FFMPEG for most audio/video conversions, but when on windows, I cannot *easily* do the DIY scripting I can on Linux. WinFF is a GUI program for Windows/*NIX that neatly wraps around FFMPEG. Two really good things about it:

huge number of presets for almost any video conversion (in my case H264 for web)
spits out the ffmpeg command line options to show you what is about to happen, and lets you edit them!

be sure to use -threads 8 to keep your machine busy. Free of course, as it uses FFMPEG.

Capturing light scatter using Trillion FPS camera

posted 12 Sept 2012, 04:26 by John Stavrakakis

http://web.media.mit.edu/~raskar//trillionfps

This is fantastic work on deciphering the scattering effects of light. The problems they target include medical, engineering, but I know that light transport problems from the real world are extremely difficult to emulate in computer graphics. Such data would actually aid in more realistic simulation of complex environments. The limitations of electronic circuits do cause accuracy loss and calibration methods must be very pedantic. I wonder if they reduce the air pressure, approaching that of a vacuum, will the accuracy of scatter improve by a significant amount?

GIT log viewer

posted 27 Aug 2012, 00:56 by John Stavrakakis

I needed to find out the number of hours I had worked on for a project. As I worked, all my activity was recorded with a message in the commit with the git repository. To gauge the amount work, I needed to see roughly the number of changes made in lines of code as an underestimate of time spent (lets not exclude pen and paper stuff!). Using a viewer application such as gitx made the process much easier, even though it is not designed for auditing hours. One does appreciate a nicely laid out interface.

I could not find anything that quantitatively estimates number of hours based on a git log. It would be interesting to measure how much work a commit actually constitutes. There is even more information available about the work done using the timestamps on each file.

Jump point search

posted 22 May 2012, 22:01 by John Stavrakakis

A fresh approach to path finding algorithm by NICTA student Daniel Harabor. Looking at his algorithm, it is a modified A* search with extra conditions to make sure that only a unique paths are explored. It checks the next neighbouring space for obstacles, if there are none, then they can be skipped as such a path does not contribute to a unique walk.

It is one of those logical approaches "why didn't someone think of it before". The results are very good and the accompanying screenshots give a nice visual comparison to other approaches:

http://harablog.wordpress.com/2011/09/07/jump-point-search

Would be a good path finding algorithm just for the speed increase. It is claimed as optimal, though I cannot convince myself of that.

SCons + Mesa = stalled

posted 19 Mar 2012, 01:03 by John Stavrakakis

Latest mesa no longer includes the MSVS project/solution files needed to build on Windows.

For compilation on Windows SCons is used.

This means you need to download and install:

Mesa of course
Latest Python
Latest version of SCons

Now setup operating env for compiling Mesa with SCons:

Append path environment variable in windows: ;C:\Python27;C:\Python27\Scripts;C:\MinGW\bin
Extract Mesa to mesa-dir
Open CMD
cd to mesa-dir

scons platform=windows toolchain=crossmingw machine=x86 statetrackers=mesa drivers=softpipe,trace winsys=gdi

All seemed to be going well until:

scons: Building targets ...
Archiving build\windows-x86-debug\gallium\auxiliary\libgallium.a ...
The command line is too long.

125 characters max on command line? I'm flabbergasted. It is suggested that a parallel python extension might solve this, but Mesa 7.5 will do the job (OpenGL 2.1). Sorry to anyone looking for solution here.

Oops. The keyboard no longer works on this new machine. Getting stranger by the day.

Using ColorBuffer and DepthBuffer from OpenGL

posted 5 Mar 2012, 20:18 by John Stavrakakis [ updated 5 Mar 2012, 20:19 ]

If you ever have a need for both colour buffer and depth buffer, than this might interest you.

In the simplest way, you could render all your objects to screen and simply use glReadPixels:

GLint viewport[4];

glGetIntegerv(GL_VIEWPORT, viewport);

int imgsize = viewport[2] * viewport[3];

unsigned char *pixmap = (unsigned char*)malloc(sizeof(unsigned char) * imgsize * 4);

glReadPixels(0, 0, viewport[2], viewport[3], GL_RGBA, GL_UNSIGNED_BYTE, pixmap);

...

unsigned char *depthmap = (unsigned char*)malloc(sizeof(unsigned char) * imgsize * 1);

glReadPixels(0, 0, viewport[2], viewport[3], GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, depthmap);

Then operate on the memory of pixmap and depthmap at your leisure.

If you find that you could do most operations on the GPU, then it is worth using textures to avoid heavy read back operations. Frame buffer objects are the best way to approach this. For most purposes, the depth buffer is unimportant for read back, this is where a RenderBuffer object is defined and used to store the depth without letting the programmer deal with it.

GLuint rboId[1];

GLuint fboId[1];

GLuint textureId[1];

// texture created here

glGenTextures(1, textureId);

...

// create a renderbuffer object to store depth info

glGenRenderbuffersEXT(1, rboId);

glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, rboId[0]);

glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT,

width, height);

// create a framebuffer object

glGenFramebuffersEXT(1, fboId);

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fboId[0]);

// attach the texture to FBO color attachment point

glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,

GL_TEXTURE_2D, textureId[0], 0);

// attach the renderbuffer to depth attachment point

glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT,

GL_RENDERBUFFER_EXT, rboId[0]);

check_fbo_status(); // see if everything is ok

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0); // Unbind

To obtain both the colour and the depth, simply create two textures with the appropriate parameters (as in glReadPixels read back) and skip the render buffer construction. Instead of attaching the render buffer object to the FBO for depth, use the texture name instead.

GLuint rboId[1];

GLuint fboId[1];

GLuint textureId[2];

// texture created here

glGenTextures(2, textureId);

... // parameters for color buffer texture

glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, width, height, 0,

GL_RGBA, GL_UNSIGNED_BYTE, 0);

... // parameters for depth texture

glTexImage2D( GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT16, width, height, 0,

GL_DEPTH_COMPONENT, GL_FLOAT, 0);

// create a framebuffer object

glGenFramebuffersEXT(1, fboId);

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fboId[0]);

// attach the texture to FBO color attachment point

glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT,

GL_TEXTURE_2D, textureId[0], 0);

// Attach the texture to FBO depth attachment point

glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT,

GL_TEXTURE_2D, textureId[1], 0);

check_fbo_status(); // see if everything is ok

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0); // Unbind

To use it all, swap the framebuffer to FBO, and restore it (0) when done.

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fboId[0]); // bind

render();

glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0); // Unbind

WebGL playground

posted 27 Feb 2012, 01:28 by John Stavrakakis [ updated 27 Feb 2012, 01:28 ]

http://cake23.de/turing-fluid.html

I have to say it is nice to look at. [Firefox, OS X Lion, Core 2 Duo] Uses about 15% CPU, but after a while the fan has to kick in because there is some serious number crunching.

There is however, very little data required for download and execution of this demo. Unless the client hosts all the data needed to run a proper simulation, such graphics programs can only be defined parametrically. Alternatively, one could perform the simulation where the data is and stream 2D or 3D to the web browser.

Cross platform issues for OpenCL

posted 30 Jan 2012, 16:35 by John Stavrakakis

A while back I had to reinstall windows after an SSD drive failed. I was surprised to find that tried and tested OpenCL code was not working. There are three reasons why:

1) A newer version of the OpenCL driver was released by AMD in that time. It now follows the specification strictly for accessing vector components:

// old code style

float4 vertex;
vertex[0] = x;
vertex[1] = y;
vertex[2] = z;
vertex[3] = 1.0;

// OpenCL strict code style

float4 vertex;
vertex.x = x;
vertex.y = y;
vertex.z = z;
vertex.w = 1.0;

This is referred in a thread on intel forums: http://software.intel.com/en-us/forums/showthread.php?t=101684

2) One standard way of getting file size is to use stat. But this seems to cause problem with newline on windows, even after duplicating the text in windows format.

Reading the file with stat

    struct stat statbuf;
    FILE *fh;
    char *source;

    fh = fopen(filename, "r");
    if (fh == 0)
        return 0;

    stat(filename, &statbuf);
    source = (char *) malloc(statbuf.st_size + 1);
    fread(source, statbuf.st_size, 1, fh);
    source[statbuf.st_size] = '\0';

    printf("File %s read as string -->%s<--\n", filename, source);

CL file

__kernel
void newline_creates_garbage()
{
}

CMD output

File projection2.cl read as string
-->__kernel
void newline_creates_garbage()
{
}═══<--

3) Build log was not big enough to display all the above errors, for each wrongly placed index, for each unidentified character. The build log is too big.

Obtaining error log

    char build[4096];
    clGetProgramBuildInfo(program, devices[0], CL_PROGRAM_BUILD_LOG, 4096, build, NULL);   CLERR(clGetProgramBuildInfo, __LINE__);
    lulog("Build Log:\n%s\n",build);

4096 is not enough space for errors!
There is no query for how large the build log will be. The return value does specify the written amount. One could check to see the limit, resize the buffer, then rebuild. Then again, this is only needed for Debug, so leave it out for Release version.

There is nothing wrong with OpenCL C bindings as I had feared!

glut argc >= 1

posted 23 Jan 2012, 00:12 by John Stavrakakis

Oh dear. I spent so much time trying to find out why a windows build of glut was not working. Turns out that I changed the parameters for glutInit(argc, argv); where program parameters are passed in. Since I was working between platforms I just made some mock parameter

char *argv[] = {""}; argc = 0;

Well, on Linux/OSX, having argc = 0 was ok. This translated to memory allocation inside glut for a zero sized memory copy of the parameters. Not so for windows! While I am forever grateful for having source code to dive into, it can also be the wrong place to spend time to find out why things went wrong...

I solved a precision issue when computing a reconstruction. The problem was based on single float, whereas double was used in one, initial transformation of that encode/decode process.

(gdb) print dwx1 (encoding stage)

$3 = 191.49999834373966

(gdb) print fwx1 (decoding stage)

$4 = 191.5

Such cases cannot cause harm, but it is still treated carefully as the error would cause a different scan line to be used. I can foresee that this will affect correctness after certain optimisations are applied. This is because they depend on the knowledge of a particular number of points to be on the scan line.

This algorithm depends on homogenous data types. All floats or all doubles!

Xcode you are #1...problem

posted 11 Jan 2012, 13:44 by John Stavrakakis [ updated 11 Jan 2012, 14:29 ]

I turn off as many features as possible yet it continues to crash every day. On occasion, you will be the excessive resource hog that brings the computer to a crawl. Yes, of all the 8GB that I have it is still not enough. Having force quit and restarted Xcode 4 times in the past hour, even after rebooting PC, it is in the way of progress.

Update: To configure Netbeans for use with C++ OpenGL, OpenCL, GLUT you simply add the library directories in the project options:

The binary file found in the framework directory. You need to select all files.

Aside from the long application startup time, and project loading, the resource usage remains at 388MB real and 488MB virtual. Compiles, runs with less delay than Xcode.

Recent site activity

// old code style

// OpenCL strict code style

Reading the file with stat

CL file

CMD output

Obtaining error log