The math that we take for granted for rendering 3D was being invented, real time, to create this video. (Ed’s credited for having working out that math to handle things like texture mapping, 3D anti-aliasing and z-buffering.)

The story behind the video and how it was found recently is pretty cool too. Props to Robby Ingebretsen for sharing this!

40 Year Old 3D Computer Graphics (Pixar, 1972) from Robby Ingebretsen on Vimeo.

>4. Is it possible to include a Visual Studio solution in the
>distrubution to make it more convenient for Windows developers to
>use live555?
>5. Is it possible for live555 to generate adequate makefiles for
>Windows systems with development environments newer than Visual
>Studio 2003?

I have no current plans to change this. (These days, fewer and fewer people seem to be using Windows for development of system software.)

Regardless, Live555 works fine on Windows and is actually quite easy to build. Simply do the following:

1. Open the ‘win32config’ file and change the TOOLS32=... variable to your VS2008 install directory. For me, it’s TOOLS32=C:\Program Files\Microsoft Visual Studio 9.0\VC
2. In ‘win32config’, modify the LINK_OPTS_0=... line from msvcirt.lib to msvcrt.lib. This fixes the link error:
   LINK : fatal error LNK1181: cannot open input file 'msvcirt.lib'
3. Open the Visual Studio command prompt.
4. From the ‘live’ source directory, run genWindowsMakefiles
5. Now you’re ready to build. Simply run the following commands:

   cd liveMedia
   nmake /B -f liveMedia.mak
   cd ..\groupsock
   nmake /B -f groupsock.mak
   cd ..\UsageEnvironment
   nmake /B -f UsageEnvironment.mak
   cd ..\BasicUsageEnvironment
   nmake /B -f BasicUsageEnvironment.mak
   cd ..\testProgs
   nmake /B -f testProgs.mak
   cd ..\mediaServer
   nmake /B -f mediaServer.mak

That’s it. You should be good to go.

Outline

1. Video Window Class Definition
2. Creating and Destroying the Window
3. The Window Thread
4. The Message Pump
5. Rendering a Video Frame

Things to note:

• You will need a thread in your window class to “pump” window events.
• GDI does NOT do any color conversion, so you will need to convert each frame into the same format as the display (always RGB, usually 24 or 32 bits).

Video Window Class Definition

class VideoWindow
{
public:
    ...
private:
    static DWORD _ThreadMain(void*);
    static LRESULT WINAPI _MsgProc(HWND, UINT, WPARAM, LPARAM);

    CRITICAL_SECTION _lok;
    HANDLE _thread;
    HWND _hWnd;
    HDC _hDC;
    HDC _hFrameDC;
    HFONT _hFont;
    int _bpp;   // bit depth
    volatile bool _exit;
    int _x, _y, _w, _h; // Window dimensions
    int _imgWidth, _imgHeight, _imgLength; // Frame dimensions
    unsigned char *_imgBits;
};

Creating and Destroying the Window

void VideoWindow::Create(int x, int y, int w, int h)
{
    EnterCriticalSection(&_lok);
    _x = x;
    _y = y;
    _w = w;
    _h = h;
    _hWnd = 0;
    _exit = false;
    _thread = CreateThread( NULL, NULL, (LPTHREAD_START_ROUTINE)_ThreadMain,
        this, NULL, 0 );
    LeaveCriticalSection(&_lok);

    // Wait for window to be created. Cheap, but it works.
    while (!_hWnd) {
        ::Sleep(100);
    }
}

void VideoWindow::Destroy()
{
    // Safe to call from the destructor.

    EnterCriticalSection(&_lok);
    if(_hWnd)
    {
        _exit = true;
        LeaveCriticalSection(&_lok);
        WaitForSingleObject( _thread, INFINITE );
        CloseHandle(_thread);
        EnterCriticalSection(&_lok);
        DestroyWindow(_hWnd);
        _hWnd = 0;
    }
    if (_hFont) ::DeleteObject(_hFont);
    if (_hFrameDC) ::DeleteDC(_hFrameDC);
    if (_hDC) ::DeleteDC(_hDC);
    LeaveCriticalSection(&_lok);
}

The Window Thread

DWORD VideoWindow::_ThreadMain(void* ctx)
{
    VideoWindow *p = (VideoWindow*)ctx;
    EnterCriticalSection(&p->_lok);

    LPCSTR className = "VideoWndClass";
    LPCSTR windowName = "MyWindowText";
    WNDCLASSEX wcex = {
        sizeof(WNDCLASSEX),
        CS_OWNDC | CS_HREDRAW | CS_VREDRAW,
        _MsgProc,
        0L,
        0L,
        NULL,
        NULL,
        NULL,
        (HBRUSH)GetStockObject(BLACK_BRUSH),
        NULL,
        className,
        NULL
    };

    RegisterClassEx(&wcex);   

    p->_hWnd = CreateWindow(className, windowName, WS_OVERLAPPEDWINDOW,
        p->_x, p->_y, p->_w, p->_h, ::GetDesktopWindow(), NULL, NULL, NULL);

    p->_hDC = ::GetDC(p->_hWnd);
    p->_bpp = ::GetDeviceCaps(p->_hDC, BITSPIXEL);
    p->_hFrameDC = ::CreateCompatibleDC(p->_hDC);

    p->_hFont = ::CreateFont(18, 0, 0, 0, FW_BOLD, FALSE, FALSE, FALSE,
        ANSI_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS,
        ANTIALIASED_QUALITY, DEFAULT_PITCH | FF_DONTCARE, "Arial");

    ShowWindow(p->_hWnd,SW_SHOW);
    UpdateWindow(p->_hWnd);

    while( !p->_exit )
    {
        MSG msg;
        if(PeekMessage(&msg,p->_hWnd,0,0,PM_REMOVE))
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }

        LeaveCriticalSection(&p->_lok);
        Sleep(50); // A better way to do this is to use a message
        EnterCriticalSection(&p->_lok);
    }
    LeaveCriticalSection(&p->_lok);
    return 0;
}

The Message Pump

LRESULT WINAPI VideoWindow::_MsgProc(HWND hWnd, UINT msg, WPARAM w, LPARAM l)
{
    if (msg == WM_PAINT && l)
    {
        VideoWindow *p = (VideoWindow*)l;
        EnterCriticalSection(&p->_lok);

        HGDIOBJ  oldFont  = ::SelectObject(p->_hDC, p->_hFont);
        COLORREF oldFtColor = ::SetTextColor(p->_hDC, RGB(255,255,255));
        COLORREF oldBkColor = ::SetBkColor(p->_hDC, RGB(64,64,64));

        // Render image
        //
        // NOTE: This assumes you've already coverted the image to the proper
        // RGB bit-depth (_bpp) and copied the data into _imageBits.
        //
        HBITMAP hBMP = ::CreateCompatibleBitmap(p->_hDC, p->_imgWidth,
            p->_imgHeight);
        ::SetBitmapBits(hBMP, p->_imgLength, p->_imgBits);
        HGDIOBJ oldBMP = ::SelectObject(p->_hFrameDC, hBMP);
        ::BitBlt(p->_hDC, 0, 0, p->_imgWidth, p->_imgHeight, p->_hFrameDC,
            0, 0, SRCCOPY);
        ::SelectObject(p->_hFrameDC, oldBMP);

        // Draw some text over the image
        RECT rect;
        ::SetRectEmpty(&rect);
        ::DrawText(p->_hDC, p->_imageText, -1, &rect, DT_CALCRECT);
        ::DrawText(p->_hDC, p->_imageText, -1, &rect, DT_CENTER | DT_VCENTER);

        if (hBMP) ::DeleteObject(hBMP);

        LeaveCriticalSection(&p->_lok);
    }
    return DefWindowProc(hWnd, msg, w, l);
}

Rendering a Video Frame

void VideoWindow::Render(const unsigned char* frame, int w, int h, int stride)
{
    // Convert frame to the proper RGB bit depth to match _bpp and copy it
    // into _imgBits buffer. Update _imgWidth, _imgHeight, and _imgLength as
    // necessary.

    ::PostMessage(_hWnd, WM_PAINT, 0, (LPARAM)this);
}

ct>

Here’s a copy of the video if it is ever removed (13MB, 3gp).

There are many pages describing how to resample audio using the ffmpeg command line application, but what about doing resampling in your own program? To do that, you need to use the avcodec library (libavcodec.so on Linux and avcodec.dll on Windows).

1. Include avcodec.h
2. Call avcodec_init() to initialize the FFMpeg library.
3. Create a resampling context using av_resample_init() that describes how you want the resampling done.
4. Call av_resample() to do the actual resampling on your audio buffer.
5. When you’re done with the resampling context, delete it with av_resample_close().
6. Finally, link your application against avcodec, avutil, and zlib (it won’t work on Linux without this one).

Here it is in pseudocode:

#include "libavcodec/avcodec.h"

avcodec_init();

struct AVResampleContext* ctx = av_resample_init( ... );

av_resample( ctx, ... );

av_resample_close( ctx );

That’s it… seriously!

Sample Code (Linux):

Here’s a sample program I wrote that takes a raw 44.1kHz/16bit/mono audio file and plays it back using the pulseaudio API. The catch is that it allows you to specify a “skew” parameter which will cause the audio to dynamically speed up and slow down (via resampling). The amount of resampling is controlled by a sine wave, which is what drives the speed changes.

Download: resample.tar.bz

To unpack and build, type:

$ tar -xjvf resample.tar.bz
$ make

First, run the sample with no skew:

$ ./resample audio_16b_44k_mono_pcm_raw 0

Now, try it with a heavy skew:

$ ./resample audio_16b_44k_mono_pcm_raw -10000

For the thread “How VSync works, and why people loathe it“:

There is a technique called triple-buffering that solves this VSync problem. Lets go back to our 50FPS, 75Hz example. Frame 1 is in the frame buffer, and 2/3 of frame 2 are drawn in the back buffer. The refresh happens and frame 1 is grabbed for the first time. The last third of frame 2 are drawn in the back buffer, and the first third of frame 3 is drawn in the second back buffer (hence the term triple-buffering). The refresh happens, frame 1 is grabbed for the second time, and frame 2 is copied into the frame buffer and the first part of frame 3 into the back buffer. The last 2/3 of frame 3 are drawn in the back buffer, the refresh happens, frame 2 is grabbed for the first time, and frame 3 is copied to the frame buffer. The process starts over. This time we still got 2 frames, but in only 3 refresh cycles. That’s 2/3 of the refresh rate, which is 50FPS, exactly what we would have gotten without it. Triple-buffering essentially gives the video card someplace to keep doing work while it waits to transfer the back buffer to the frame buffer, so it doesn’t have to waste time. Unfortunately, triple-buffering isn’t available in every game, and in fact it isn’t too common. It also can cost a little performance to utilize, as it requires extra VRAM for the buffers, and time spent copying all of them around. However, triplebuffered VSync really is the key to the best experience as you eliminate tearing without the downsides of normal VSync (unless you consider the fact that your FPS is capped a downside… which is silly because you can’t see an FPS higher than your refresh anyway).

If the thread is ever unavailable, you can download a PDF version HERE.

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

If this video ever gets deleted from YouTube, you can download it HERE.

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

If this video ever gets deleted from YouTube, you can download it HERE.

UPDATE 3-17-2009: FabChannel is no longer around Click HERE to download a clip from another concert (*.mp4 file playable in QuickTime).

Click HERE to visit Marcus Miller’s website.

Josh,

An important issue in the abortion debate is the argument over when life begins; at conception, at birth, or somewhere in between? I’ve heard many opinions over the years, but one (from a fellow engineer) has always struck me as a possible solution. The logic of the argument goes like this: ‘life’ and ‘death’ are inverse states of existence. Therefore, the set of criteria that define ‘life’ and ‘death’ should also be inverse quantities. Thus, we should define ‘life’ by the inverse of the criteria we use for ‘death’, since those criteria are pretty well accepted both legally and morally (of course there are always edge-cases). For example: if someone is pronounced dead when their heart and brain consciousness stop, then life is defined as conscious brain function and a heart beat (over-simplified of course).

This is a very pragmatic argument. It view’s the woman’s body as analogous to a life-support system, thus rendering null the argument that life begins when the baby can exist outside the mother’s womb. This is an important step, because technology renders this a moving target… at some point, an artificial womb may be able to carry an embryo to full term. I’d be interested to get your thoughts on this.

-Tom

Josh responded to my question on his video podcast LifeReport.

Thanks Josh for the response, but you are too gracious with the praise!

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

Okay, now the large size (video source: D1 MPEG-4 30 fps):

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

In summary:

• Everything you tell the police can be used AGAINST you, but it can NEVER be used to help you (because it’s hear-say at that point).
• There is no way talking to the police can help you.
• You may admit guilt (even if innocent) with no benefit in return.
• Even if you are innocent, it is easy to get carried away and tell a small lie, which can destroy your credibility.
• Even if you are innocent, and only tell the truth, you will always give the police information that can help convict you.
• Even if you are innocent, only tell the truth, and say nothing incriminating, the police may not recall the conversation with 100% accuracy.
• Even if you are innocent, and only tell the truth, mistakes in your answers can incriminate you (either by misspeaking or drawing simple conclusions).
• Even truthful answers can be contradicted by mistaken or unreliable evidence, destroying you credibility.

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

I found the second part of the lecture especially interesting, where a veteran detective (George Bruch) backs up Duane’s arguments. Definitely recommend this one to friends.

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

That morning, Mr. Bridges was training a new recruit. The recruit successfully secured the plane’s front landing gear to the catapult, and Mr. Bridges went in to verify the recruits work. However, in a momentary lapse in judgement, he got too close to the jet intake and was sucked inside. Luckily, he put his arm up which helped get him wedged into the intake for a few seconds… those few vital seconds it took for his helmet to damage the turbine blades after it was sucked off his head. His helmet caused the blades to slow down and lessen the pressure inside the intake long enough for the pilot to shut the engines down. Miraculously, he crawled out under his own power.

I’ve embedded 3 videos of the incident (in the following order): a quick clip of what happened, a longer segment from Spike TV, and a much more detailed segment from the History Channel. Enjoy!

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

This last video requires you to wait a few seconds for the person to change the channel

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

And so the Death Star conspiracy goes:

We’ve all heard the “official conspiracy theory” of the Death Star attack. We all know about Luke Skywalker and his ragtag bunch of rebels, how they mounted a foolhardy attack on the most powerful, well-defended battle station ever built. And we’ve all seen the video over, and over, and over, of the one-in-a-million shot that resulted in a massive chain reaction that not just damaged, but completely obliterated that massive technological wonder.

Like many, I was fed this story when I was growing up. But as I watched the video, I began to realize that all was not as it seemed. And the more I questioned the official story, the deeper into the rabbit hole I went.

Read the full story HERE.

(requires Adobe Flash plugin… click HERE to watch it on YouTube)

I found this information interesting:

• The application code is written mostly in Python (the web app is not the bottleneck… the database RPC is)
• They use Apache for page content and lighttpd for serving video
• Thumbnails are now served by Google’s BigTable
• They’re running SuSE Linux with MySQL
• HW RAID-10 across multiple disks was too slow. HW RAID-1 with SW RAID-0 was faster because the Linux I/O scheduler could see the multiple volumes and would therefore schedule more I/O

You can read a good summary of the talk HERE from the High Scalability website.

TechCruch has a good article of the YouTube API.