ffmpeg -i input.mp4 -x264opts keyint=15:min-keyint=15 -c:v libx264 -preset slow -crf 22 output.mp4

Links:

• FFMpeg x264 encoding guide
• x264 encoder settings

The City of Thornton does in fact have two separate water sources and we don’t always use both so the character of your water can actually vary a bit throughout the year. Thornton owns a significant share of the water in Standley Lake in Arvada. This water comes from Clear Creek. The Coors Beer commercials are accurate. This water is very clean and low in pollutants as I will summarize below.

Our second water source is the South Platte River. We divert water from the South Platte and store it in our gravel lakes until it is needed. While still better than many water sources, The South Platte is certainly exposed to more contaminants then our Standley Lake water.

In most years, water is drawn from Standley Lake nearly all year – only ceasing for maintenance to the treatment plant. Meanwhile, water from the South Platte is used to supplement our supply when demand spikes in the summertime.

Typically, we start using South Platte water in March and we might stop using it around October or November. This year we turned off our South Platte supply in late September, so the City is currently receiving only Standley Lake water. It is difficult to guess what ratio of our two water supplies you might receive at your residence when we do utilize both sources.

Now that you know the reasons behind the variability in Thornton’s water quality, I’ll throw several numbers at you which should represent your water quality at different times of year. These values were measured at a residence near your location that we sample year round. This residence is located near [redacted]. All values are in ppm:

	Standley Lake (Winter) –	Both (Summer) –	South Platte Only
Calcium	56.3	85*	97.1
Magnesium	8.4	14*	18.1
Total Hardness	152	276	280
Calcium Hardness	100	200	236
Sulfate	51	92*	137
Chloride	36	76*	74
Bicarbonate	52.1	139.2	173.4

* = estimates based on the average of both sources during this time frame

Hopefully that’s enough detail to answer your questions. If you have any more questions or need more specific data certainly let me know and I’d be happy to help.

1. Open lighttpd.conf

2. Add ".py" to the static-file.exclude-extensions variable to prevent people from viewing the raw python code:

static-file.exclude-extensions = ( ".py" )

3. Add "mod_cgi" to the server.modules variable:

server.modules = ( "mod_cgi" )

4. Add the association between *.py files and the python interpreter to the cgi.assign variable:

cgi.assign = ( ".py" => "/usr/bin/python" )

5. Make sure you have a “breakage” log defined… this helps debugging because python errors will get written here:

server.breakagelog = "/var/log/lighttpd/breakage.log"

6. Restart lighttpd

For more mod_cgi configuration options, read this.

1. ifconfig

 ... 
 RX packets:522 errors:0 dropped:0 overruns:0 frame:0
 TX packets:406 errors:0 dropped:0 overruns:0 frame:0
 ...

2. cat /proc/net/dev

Inter-| Receive ... 
 face | bytes packets errs drop fifo frame ... 
 eth0:  87689 785 0 0 0 0 ...
 ...

3. cat /proc/net/udp

 so local_address rem_address ... drops
 277: 00000000:0044 00000000:0000 ... 0 
 ...

4. cat /proc/net/snmp

...
Tcp: ...
Udp: InDatagrams NoPorts InErrors OutDatagrams RcvbufErrors SndbufErrors
Udp: 453 0 0 452 0 0
...

You can also see this on a per-process basis using cat /proc/<pid>/net/{udp,dev,snmp}

Check out iftop also.

“Foshizzle” is a modified version of the Clang compiler which supports Ebonicode++ (an alternate C++ syntax). Foshizzle supports all the existing features of Clang, but with extensions to more fully express your gansta style. All the regular C++ syntax still works, but you can now substitute Ebonicode++ keywords and operators (see below).

Here’s a sample method that calculates factorials (Note: the semicolons can be replaced with a certain expletive):

int factorialz(int n)
{
    int rezult be 1;
    slongas (n bepimpin 0)
    {
        rezult be rezult dimes n;
        dissin n;
    }
    putou rezult;
}

I can’t take all the credit. I was inspired by the Iowa State students that first created Ebonicode (webpage no longer available).

Here are my Clang modifications: ebpp-clang30rc4.patch

Build instructions are near the end of this post.

How It Happened

I periodically venture off into the h4x0r wilderness and pour myself into some random project. It always starts out innocently enough, but the project soon takes on a life of it’s own. This time was no different… except it happened over Thanksgiving (much to my wife’s chagrin).

Being the charismatic socialite that I am (sarcasm), I was digging through the C++11 spec on Thanksgiving. What struck me was how much of my language design course I had forgotten, and it really bugged me. It’s one of those required courses in the CompSci graduate program that I loathed having to take, but turned out to be invaluable (don’t get me started on the database and UI design courses… blah).

Long story less long, I started refreshing on compilers (read this for inspiration). I’d heard about Clang and LLVM awhile ago, and I remembered their focus on modularity, maintainability, and all sorts of other *ability’s. I figured it’d be a good place to start, so I download the source code and dug through it (watch this video for background on Clang).

Stepping through Clang in a debugger sounded like a great way to start, but I quickly had mental stack overflow through the recursive parsing code. Okay, time for plan B. Common wisdom says that a good way to learn a piece of code is to try and fix a bug. So I went to the Clang bug list looking for a starter task, but all the “interesting” tasks were way too large in scope for a Clang newb like me.

Time to invent plan C: make a small tweak to the language and see if I can get it working. I remembered a few years ago that some students from Iowa State built an Ebonicode compiler for a language class they had. It got quite a few laughs around the office and was always wishing for a working compiler. So I decided take their idea and replace ‘while’ with ‘slongas’… and an hour later I had it working (which is testament to the readability of the Clang code… it’s very well commented).

Not satisfied to stop there, I moved on to other keywords… simple, once you get comfortable with how the code’s laid out. “What about operators and punctuators?”, I wondered. After a few failed attempts, it dawned on me that C++ has aliases for operators (‘and_eq’ can be used in place of ‘&=’, etc). Instead of heavily modifying the parser/lexer, I started looking for how Clang handled these aliases… maybe I could just add some more. Turns out, it fairly simple to add new aliases, so ‘==’ got overloaded with ‘sameas’, ‘!=’ got overloaded with ‘aint’, etc… and it worked! Sweet!

After all that, I dug a little into the preprocessor and figured out how to support ‘#mahomie’ in place of ‘#include’. Simple enough. I dug a little into the build stuff and changed the name from ‘clang’ to ‘foshizzle’… cool. I little bit of frustration later, and I had it recognizing ‘*.opp’ and ‘*.ho’ as source and header files, respectively.

Three days after I started, I had a fully functional Ebonicode++ compiler and a lot deeper understanding of how a production C++ compiler works. I can’t stress enough that this project would never have happened if the Clang code wasn’t written so well. Kudos to the Clang team.

I really enjoyed this project, and I hope you get half the fun out of it I did. Next time you have a coding task, consider adding a litta gansta sizzle

C++ To Ebonicode++ Mapping

•  *.cpp -> *.opp
• *.h -> *.ho

Many thanks to Sean Tegtmeyer for helping with the syntax definition.

Building Foshizzle

I highly suggest building Clang without my changes first and verify that you have it working correctly. Then it should be simple to apply my patch and rebuild. I did all my work on Fedora 16, so your mileage may vary on other distros or OSes.

Note: If you have any problems building LLVM or Clang, please refer to their build page: Getting Started

1. Create a new directory (e.g. “foshizzle”).
2. Within the “foshizzle” directory, create the following directories: “build”, “src”, “install”
3. Checkout the LLVM source code into the “src” directory:
• svn co http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_30/rc4 ./src
4. Create a new directory for the Clang source within the LLVM “tools” directory:
• mkdir src/tools/clang
5. Checkout the Clang source code into the “src/tools/clang” directoy:
• svn co http://llvm.org/svn/llvm-project/cfe/tags/RELEASE_30/rc4 ./src/tools/clang
6. Change directories into the “build” directory.
7. Configure the Clang/LLVM build and point it to the “install” directory you created earlier:
• ../src/configure --prefix=<path>/<to>/<foshizzle>/install
8. Build (takes quite a while): make
9. Install: make install
10. Compile some test code to make sure it works: install/bin/clang++ yourtestcode.cpp

Only continue on once the unmodified version of Clang is working.

1. Download my patch file: ebpp-clang30rc4.patch
2. Change directories to where the Clang source is (src/tools/clang).
3. Apply the patch: patch -p0 -i ebpp-clang30rc4.patch
4. Change back to the “build” directory.
5. Build: make
6. Install: make install
7. Test: install/bin/foshizzle++ yordopecodez.opp

You can also build the sample code below.

Sample Code

baseclaz.ho, friendclaz.ho, main.opp

Building

install/bin/foshizzle++ main.opp

Program Output

baseclaz: protected = 1, private = 1
derivedclaz: protected = 0, private = 1
friendclaz: friend private = 0

Factorial(7) = 5040

error C2146: syntax error : missing ';' before identifier 'foo'
error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

The fact is that Visual Studio doesn’t implement C99… it implements C89 (for compatibility reasons). So, you don’t have access to familiar types like:

• int8_t, int16_t, int32_t, int64_t
• uint8_t, uint16_t, uint32_t, uint64_t
• INT8_MIN, INT8_MAX, etc
• The fprintf macros PRId32, PRIu32, etc
• strtoimax(), etc

Fortunately, Alexander Chemeris has written msinttypes: an implementation of stdint.h and inttypes.h for Microsoft Visual Studio. It is licensed under the BSD license, so the headers are actually usable commercially (no viral GPL). This following quote probably goes without saying (emphasis mine):

Note though, that just adding these headers does not make Visual Studio compiler fully C99 compliant.

This project has saved me a bunch of unwanted coding. Thanks Alex!

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.

How does GC, work, generally? Why is it important? The GC inside of the CLR is of a specfic type – ephemeral, concurrent (the server version has always been concuurent and now with Background GC on the client in CLR 4, GC is concurrent on the client as well, but there are differences…)

I particularly liked his summary of the 3 things you need to remember about rvalue references:

1. By overloading a function like this:
   

   
   void foo(X& x); // lvalue reference overload
   void foo(X&& x); // rvalue reference overload
   

   
   you can branch at compile time on the condition “is foo being called on an lvalue or an rvalue?” The primary (and for all practical purposes, the only) application of that is to overload the copy constructor and copy assignment operator of a class for the sake of implementing move semantics. If and when you do that, make sure to pay attention to exception handling, and use the new noexcept keyword as much as you can.

2. std::move turns its argument into an rvalue.
3. std::forward allows you to achieve perfect forwarding if you use it exactly as shown:
   

   
   template<typename T, typename Arg>
   shared_ptr<T> factory(Arg&& arg)
   {
       return shared_ptr<T>(new T(std::forward<Arg>(arg));
   }

I also like his definition of lvalues and rvalues in the introduction:

The original definition of lvalues and rvalues from the earliest days of C is as follows: An lvalue is an expression e that may appear on the left or on the right hand side of an assignment, whereas anrvalue is an expression that can only appear on the right hand side of an assignment.

In C++, this is still useful as a first, intuitive approach to lvalues and rvalues. However, C++ with its user-defined types has introduced some subtleties regarding modifiability and assignability that cause this definition to be incorrect. There is no need for us to go further into this. Here is an alternate definition which, although it can still be argued with, will put you in a position to tackle rvalue references: An lvalue is an expression that refers to a memory location and allows us to take the address of that memory location via the & operator. An rvalue is an expression that is not an lvalue. 

NOTE: I only had the PCF file provided by work, and the group password was encrypted. If you know your group password, then you can just run VPNC directly or write a conf file yourself.

My setup:

• Fedora 12 x86_64
• Running in VirtualBox 4.1.6 with bridged networking (I didn’t try it with NAT)
• Connecting to a Cisco VPN server at work

Connecting:

1. Install VPNC (`sudo yum install vpnc` in Fedora)
2. Download the pcf2vpnc Perl script (cached)
3. Convert your Cisco PCF file to VPNC conf format: `perl pcf2vpnc company.pcf vpnc.conf`
4. Connect to the VPN server: `sudo vpnc ./vpnc.conf` (you will be prompted for you username and password)
5. (optional) Run `ifconfig` to see the tunnel interface that was created

eth0     Link encap:Ethernet  HWaddr 08:00:DE:AD:BE:EF
         inet addr:192.168.1.10  Bcast:192.168.1.255  Mask:255.255.255.0
         ...

lo       Link encap:Local Loopback
         inet addr:127.0.0.1  Mask:255.0.0.0
         ...

tun0     Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
         inet addr:10.200.100.1  P-t-P:10.220.116.219  Mask:255.255.255.255
         ...

Disconnecting:

1. Run `sudo vpnc-disconnect` (don’t forget the `sudo`)

That’s it. Cheers!

static const uint32_t kCrc32Table[256] = {
    0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
    0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
    0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
    0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
    0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
    0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
    0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
    0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
    0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
    0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
    0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
    0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
    0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
    0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
    0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
    0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
    0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
    0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
    0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
    0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
    0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
    0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
    0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
    0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
    0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
    0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
    0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
    0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
    0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
    0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
    0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
    0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
    0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
    0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
    0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
    0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
    0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
    0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
    0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
    0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
    0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
    0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
    0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
    0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
    0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
    0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
    0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
    0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
    0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
    0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
    0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
    0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
    0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,
    0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
    0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
    0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
    0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
    0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
    0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
    0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
    0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
    0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
    0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
    0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d,
}; // kCrc32Table

class Crc32
{
public:
    Crc32() { Reset(); }
    ~Crc32() throw() {}
    void Reset() { _crc = (uint32_t)~0; }
    void AddData(const uint8_t* pData, const uint32_t length)
    {
        uint8_t* pCur = (uint8_t*)pData;
        uint32_t remaining = length;
        for (; remaining--; ++pCur)
            _crc = ( _crc >> 8 ) ^ kCrc32Table[(_crc ^ *pCur) & 0xff];
    }
    const uint32_t GetCrc32() { return ~_crc; }

private:
    uint32_t _crc;
};

Note: I always have uint32_t defined in Windows, so you may have to define it yourself or use the Microsoft intrinsic unsigned __int32.

The picture below shows the 2 most common configurations for a Netem box:

I’ve always used the first configuration, but it doesn’t really matter.

1. Find a Suitable System

• Any “reasonable” machine that can run Fedora 14 (I use an old Pentium 4 box since I don’t need to simulate a high-speed link)
• It must have 2 network interfaces
• It’s nice to use a smaller box if you want it to be portable

2. Install bridge-utils

Make sure you are root, and run:

brctl

to see if bridge-utils is installed. If it isn’t, run:

yum install bridge-utils.

3. Bridge the 2 Network Interfaces

First make sure to clear the network configuration for your interfaces:

ifconfig eth0 0.0.0.0
ifconfig eth1 0.0.0.0

Then create the bridge and bring it up:

brctl addbr br0
brctl setfd br0 0
brctl addif br0 eth0
brctl addif br0 eth1
ifconfig br0 up

Note that we disable the forwarding delay (‘setfd’). This makes the bridge pass traffic through it immediately instead of the configured delay time.

One final set I had to perform is disabling kernel-level filtering on the bridge. This is done by writing 0 to the bridge nodes under proc:

for f in /proc/sys/net/bridge-*; do echo 0 > $f; done

Note: If for some reason none of this works for you, check out the Linux Foundation page on network bridging.

4. Configure Netem

Netem is actually used in conjunction with the Traffic Control application, tc. I’m not going to go into detail here, but suffice it to say that tc allows you to do packet shaping and adjust packet scheduling. Check out the tc man page for more information.

tc allows you to specify the “queueing discipline” (or “qdisc” for short) used for sending outbound packets on an interface (the fact that it operates on outbound packets only is important to remember). Basically, a qdisc defines how outbound packets are ordered and sent. To view the current qdisc setup on your box, type:

tc qdisc

The default qdisc is pfifo_fast. We’re going to change this to use a combination of Netem and Token Bucket Filter.

Note: For the following examples, I assume eth0 is connected to the network (client-side), and eth1 is directly connected to the server.

Limiting Bandwidth

The Token Bucket Filter (tbf) is used to limit how much data can exit the network interface per second… perfect for simulating WAN bandwidth limitations. Let’s assume we want to emulate a client-side WAN connection of 768kbps down and 128kbps up. Assuming the server is connected to eth1, the eth1 interface receives inbound traffic from the server and eth0 sends that traffic outbound to the client. Since we know the a qdisc works on outbound traffic only, we need to limit eth0 for our download speed of 768kbps. Conversely, we configure eth1 for our upload speed of 128kbps.

tc qdisc replace dev eth0 root handle 1:0 tbf rate 768kbit burst 2048 latency 100ms

tc qdisc replace dev eth1 root handle 2:0 tbf rate 128kbit burst 2048 latency 100ms

We use the ‘replace’ command to overwrite any qdisc setting that’s there (you can use the ‘del’ command to simple remove qdiscs). We set the qdisc as the ‘root‘ of the tree, and configure the tbf ‘rate‘ accordingly. The ‘burst‘ and ‘latency‘ parameters control the initial number of tokens in the bucket and how long queued packet can hang around before being dropped, respectively.

Adding Latency

We can append qdiscs that will allows us to use different tools to control how our simulated WAN behaves. In this example, I’ll use Netem to artifically add 57ms of latency to the download connection with a random variantion of +/- 13ms:

tc qdisc add dev eth0 parent 1:1 handle 10: netem delay 57ms 13ms

And So Much More…

The Netem page on the Linux Foundation website has many other great examples, so there’s no point in me copying them here. If you’ve made it this far and are still interested, I highly encourage you to check out their page.

>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.

1. It’s installed by default on most distros (as opposed to the sysstat tools).
2. It gives the idle time in percentage normalized to 100% (as opposed to /proc/stat which requires knowledge of the jiffy’s interval, which can vary).

function cpu_load(interval)
   interval = interval or 1
   local f = io.popen('top -bp$$ -d ' .. interval .. ' -n 2')
   local s = f:read('*all')

   -- Find the idle times in the stdout output
   local tokens = s:gmatch(',%s*([%d%.]+)%%%s*id')

   -- We're interested in the 2nd 'top' idle time
   local ii = 1
   for idle in tokens do
      if ii == 2 then
         return 100.0 - tonumber(idle)
      end
      ii = ii + 1
   end
end

You can call it from the Lua shell as:

> load = cpu_load()
> print(load)
43.7

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);
}

#ifdef WIN32
    #ifndef NAN
        static const unsigned long __nan[2] = {0xffffffff, 0x7fffffff};
        #define NAN (*(const float *) __nan)
    #endif
#endif

This code is adapted from an MSDN example.

Note: This post assumes you are already familiar with the socket extensions for IPv6 (RFC 3493).

Linux and Mac
Good news… they both fully support RFC 3493.

Windows
Windows IPv6 support varies based on which version you’re targeting. Microsoft started adding IPv6 in Windows 2000, and they’ve continued adding more of the socket extensions as time went on. Most of the core functionality is present in XP, and what’s missing is easily replaced by using Winsock calls directly (more on this later).

Windows gained IPv6 support while RFC 2553 was still the supported standard. Since then, it has been deprecated by RFC 3493. However, Microsoft doesn’t want to break existing code written against it’s API, so the older API lives on. The main impact of this is that sockaddr_in6 and sockaddr_storage are slightly different on Windows than Mac and Linux. The size of the structures across platforms is the same (the sa_family_t member was shortened), it’s just that the Windows structures don’t begin with the length member. For example:

// Linux and Mac
struct sockaddr_in6 {
    uint8_t      sin6_len;    /* Added in RFC 3493 */
    sa_family_t  sin6_family;
    ...
};
struct sockaddr_storage {
    uint8_t      ss_len;      /* Added in RFC 3493 */
    sa_family_t  ss_family;
    ...
};

// Windows
struct sockaddr_in6 {
    sa_family_t  sin6_family;
    ...
};
struct sockaddr_storage {
    sa_family_t  ss_family;
    ...
};

I’ve never had a problem with this, because the size of sockaddr_in6 is easily determined (sizeof(sockaddr_in6)) and I always end up casting sockaddr_storage to the specific type (sockaddr_in or sockaddr_in6) based on ss_family.

Besides the data structure differences, it’s important to remember that Microsoft added IPv6 support over multiple versions. Support first appeared in Windows 2000, but more of the extensions have been added over time. Most of the core functionality was present in XP (including multicast), but not everything is implemented as of Windows 7. It’s annoying, but I will say that what’s missing is easily replaced by using Winsock calls directly.

Here’s the breakdown of IPv6 socket extensions by Windows version:

As you can see, you may still have to call Winsock directly depending on what version of Windows you are targeting. In my opinion, programming IPv6 on Windows is a lot easier if you only support XP and later, but I know that’s not always possible.

Summary

Modern operating systems all support IPv6. However, for business reasons, Windows has a slightly older version of the socket API which requires special consideration. My goal was to enumerate those differences to help make the transition to IPv6 smoother. Writing cross-platform code can be a fun challenge at times, but it’s also a little tedious. Hopefully, this post helps ease the pain.

// Returns the address family of an address or hostname.
// AF_INET, AF_INET6, or -1 on error.
int getaddrfamily(const char *addr)
{
    struct addrinfo hint, *info =0;
    memset(&hint, 0, sizeof(hint));
    hint.ai_family = AF_UNSPEC;
    // Uncomment this to disable DNS lookup
    //hint.ai_flags = AI_NUMERICHOST;
    int ret = getaddrinfo(addr, 0, &hint, &info);
    if (ret)
        return -1;
    int result = info->ai_family;
    freeaddrinfo(info);
    return result;
}

See RFC 3493 for more information on the latest socket API for dealing with IPv6.

Note: This is intended to be a pragmatic guide for engineers evaluating codecs. It is not a comprehensive treatment of the subject. The goal is to give readers a solid overview and some practical ideas.

Get Familiar with Psychoacoustics

Psychoacoustics is the study of how humans perceive sound. As you might expect, we humans don’t process sound in a perfect, linear fashion. The physical shape of the ear, the transfer function of the Basilar membrane, and the psychological interpretation of the data all affect how we perceive sound (and by extension, how “good” an audio codec sounds to us).

I highly recommend you start by reading this excerpt from Surround Sound: Psychoacoustics Part 1, by Tomlinson Holman (he created THX for Lucasfilm).

Understand the Codec

Make sure you understand the codec you are testing; not necessarily the implementation, but what tools (i.e. methods) the codec uses for compression. Many codecs have different “profiles”, which describe what subset of available tools are used (e.g. AAC). You should also have some idea how each compression tool works and any short-comings it has. This will help guide you in selecting reference audio samples and knowing what artifacts to listen for.

For an introduction to modern audio compression, read Audio Coding: An Introduction to Data Compression Part 1, and Part 2 (discusses MP3 and AAC). I actually suggest buying the book “Introduction to Data Compression”, by Khalid Sayood.

Understand the API

Make sure you actually read the codec documentation and look at any available code samples. This step has more to do with due-diligence than anything, as I haven’t seen a codec API we couldn’t work with, but you need to do this. This will also help you scope the work required to get a working encoder/decoder for future steps (if your lucky, the sample code can be used).

Choose the Reference Audio Samples

An effective test requires multiple audio samples with different characteristics. There are many types of artifacts a codec can introduce, and your choice of audio samples will dictate how easy they are to detect. It’s also important to pick samples that reflect the actual types of sound the codec to have to deal with. For example, if the final system will primarily be encoding speech, then you should choose more speech-oriented references as opposed to music samples.

Some characteristics you might consider:

• Transients (snare drum): Sensitive to pre-echo and noise “smearing”.
• Tonal structure (clarinet, saxophone): Sensitive to noise and “roughness”.
• Natural speech (male and female voices of various languages): Sensitive to distortion and smearing of “attacks”.
• Complex sound (bag pipes): Stresses the codec.
• High bandwidth (bag pipes): Loss of high frequencies and program-modulated high frequency noise.

It is also possible to use synthetic sounds and sweeps, but this is only recommended for the automated objective tests below.

As a basic guideline, you need 10-25 second “raw” samples recorded at the highest sample rate your system needs to work with. It is vital that the samples you choose have never been compressed with a lossy codec (mp3, AAC, etc)… that would severally limit the quality of your test. For sample rate and size, I suggest 48kHz 16-bit PCM, but a lower rate/size makes sense if the final system is limited in this area. It also makes sense to use a sample rate of 44.1kHz, since many quality audio samples can be ripped losslessly from CD. Just keep in mind that the objective PEAQ test mentioned below requires 48kHz 16-bit PCM, so up-sampling may be required.

The audio samples can be stored in whatever container format you want (raw, WAV, etc) as long as your codec test application can unpack it. This is important to keep in mind… you don’t want to accidentally run the WAV header through the codec (yes, I’ve done this). The container format is more of a practical issue, but it was worth mentioning.

Generate Various Test Samples and Observe CPU Load

This step is pretty straight-forward: wrap the codec in an application and encode the reference audio samples at different bit rates. You should choose bit rates that represent the full spectrum of bit rates that will be used in the final system. While you’re encoding, track the CPU usage on the codec and how many cores it’s using. You may even want to do a separate test running many encodes in parallel (this works nicely if the CPU usage is too low to measure accurately). Make sure to consider application overhead and disk I/O when making measurements.

After encoding, you need to decode back to raw PCM. Clearly label your files so you know what bit rate each one was encoded with. These decoded test samples are what we will be comparing to the original reference samples.

Do a Subjective Test

How you conduct your subjective testing will depend on several factors, such as time constraints, cost, and the required test precision. At the low end, you could simply listen to the test samples in a pair of headphones and judge the quality yourself. For a high precision test, you could do a full ITU BS.1116 test using “expert listeners” in a controlled environment. While these examples represent the extremes, there are many permutations that can give you the desired quality of results.

The most common subjective test is called a “double-blind triple-stimulus with hidden reference” test. The listener hears three samples (commonly labeled A, B, and C) for a period of 10 to 25 seconds. A is always the original reference sample. The next two samples, B and C, are randomly assigned either the test sample from the codec or the original reference sample played again (called the “hidden reference”). The listener must then rate the difference between B and A, and C and A, not knowing which one is the test sample. The grading scale is:

• 5.0 Imperceptible
• 4.0 Perceptible, but not annoying
• 3.0 Slightly annoying
• 2.0 Annoying
• 1.0 Very annoying

Ideally, you would conduct several tests and average the results together. If you do the listening test yourself, your results will be limited to your listening skills and understanding of audio codec artifacts. Here’s a summary of factors that affect the quality of your results:

• The quality of the listener.
• The choice of audio samples.
• The number and duration of the testing.
• The testing environment, including speaker/headphone quality, room design, and listener placement.
• The quality of randomization of sample order to remove any correlation between samples.
• Proper statistical analysis of the combined test results.

A proper subjective test is both expensive and time consuming. It’s important to find the right balance for your particular needs.

Do an Objective Test

Evaluating a codec objectively requires testing methods that correlate well to actual human perception. You can’t simply measure the distortion introduced by the codec using traditional measurements like Signal-to-Noise ratio (S/N) and Total-Harmonic-Distortion (THD), because they don’t correlate well to perceived audio quality. Some distortion is imperceptible to the human ear, and codecs take advantage of this to increase the compression ratio.

Fortunately, the ITU has standardized an objective audio test called PEAQ (BS.1387). The acronym stands for Perceptual Evaluation of Audio Quality. PEAQ uses software to model the entire human auditory system (including blood flow noise in the inner ear) to generate a set of metrics that are used to give a final “quality” score. The original reference signal is compared to a signal run through the codec, and the result is a real number between 0.0 and -4.0. The result is interpreted on the following scale:

• 0.0 = Imperceptible
• -1.0 = Perceptible but not annoying
• -2.0 = Slightly annoying
• -3 .0= Annoying
• -4.0 = Very annoying

Obviously, values closer to zero are better.

The test was developed by a similar group of audio experts that developed BS.1116 (mentioned above) and the results have been validated against a long list of subjective tests done using expert listeners.

There are several free and commercial software packages available for doing PEAQ tests. The best free package I’ve found is AFsp from the McGill Telecommunications and Signal Processing Lab. There’s also peaqb, but there’s a comment that it gives incorrect results. AFsp worked great in my tests and included some helpful tools like CompAudio and InfoAudio.

Summary

Hopefully this post has given you a good starting point and some practical ideas for testing audio codecs. My goal was to provide a pragmatic approach with different options depending on what your actual evaluation needs are. This is in no way a comprehensive treatment of the subject; only an overview. I highly suggest reading some of the books I referenced if you’d like a deeper treatment of the subject. Either way, I hope you found this post helpful.