John Beales

We all know the sinking feeling when we have to test a website in Internet Explorer. You built the site, it looks beautiful in Firefox and maybe Safari too, but now you have to open up Internet Explorer 6, 7, and 8, and make sure it plays nice with all three of them. Even better, Microsoft has made it so that you can only have one version of IE installed on a computer at a time. True, you can use things like Multiple IEs or other similar products, but they never play quite right.

Fortunately, Microsoft has supplied us with Virtual PC images of Windows with Internet Explorer installed. Unfortunately, Virtual PC is a Windows-only program so you need a PC to run them on. Or do you?

You don’t! If you’re using OS X you can use VMWare Fusion to run those Microsoft VPC images, after a little tweaking. It is much easier if you have a copy of Windows available to you during the install process, (that’s how I did it), but I don’t believe this is an absolute necessity. Here’s how it works:

Basically, you need to download the VPC images, extract them, and convert them into VMWare Fusion virtual machines. It sounds trickier than it is.

First, download and extract the VPC images. If you can use Windows to do this it’s easy, (the images have self-extractors), if not try p7zip, (see instructions in this forum thread).

[edit: July 15, 2009]: Then, somehow, you have to convert your VHD files into VMC files. The easiest way to do this is to use Microsoft’s VPC to make a new virtual machine from the VHD files, but you do need windows to do that. You will be converting these .VMC files into VMWare native virtual machines.
[/edit]

To convert the VPC images to something else, use VMWare vCenter Converter. It’s a stand-alone program for Windows or Linux that easily converts VPC images to VMWare Fusion virtual machines, as well as several other formats. You can even choose between Fusion 1.x and Fusion 2.x. It will even install the VMWare tools pagkage for you. I did the conversion under Windows, but there’s probably a way to get the linux version to run under OS X, at least hopefully.

Once the conversion is complete, fire up OS X & VMWare Fusion and open your new Virtual PC image. There are some things that run on the first startup of each machine, give it a few minutes then hit cancel on all of the “Please insert the XP SP3 CD” messages that remain, it doesn’t seem to hurt Windows. I think it’s looking for a battery driver in my case, (maybe I should try to install the Bootcamp battery driver?).

That’s it, enjoy testing. I am able to run, slowly, all 3 IE versions with the Windows XP images, and my computer isn’t as slow as when I run only my Bootcamp Vista install under VMWare Fusion. I’m thrilled to have these 3 new debugging tools at my disposal.

Have you ever created new clean XHTML template, applied it to a CMS with years of back content, and discovered that the years of legacy HTML looks terrible?  Because you’re using a new XHTML doctype many, if not all, of the presentational attributes in the old HTML no longer work, however, CSS can be used to fix this.

You may say that the whole point of building a new template with XHTML & CSS is so that we won’t have any of the old <p align="right"> in our code, and you are right, but in situations when there can be thousands of pages of content it is often not practical to re-code them all using CSS, that’s where the attribute selectors come in.

Here is a very basic stylesheet that will help get you started:
img[align="right"], table[align="right"] {float:right;}
img[align="left"], table[align="left"] {float:left;}
img[align="center"], table[align="center"] {display:block;margin-left:auto;margin-right:auto;}

p[align="center"] {text-align:center;}
p[align="left"] {text-align:left;}
p[align="right"] {text-align:right;}

table[border="2"], table[border="2"] td {border:1px solid #000;}
table[border="1"], table[border="1"] td {border:1px solid #000;}
table[border="0"], table[border="0"] td {border:0;}

Although it would be nice to have one master stylesheet that we could drop in to a document and automatically have the old HTML look great, I believe that stylesheet would have to be extremely large, so I recommend using a base set of styles, (like the one above), and adding any extra styles to it that may be needed, (for example, img[border="5"] {border:5px solid #000} would not be needed every time).

What about browser compatibility? I’ve tested in FireFox 3, Safari 3, Internet Explorer 7, and Internet Explorer 6, and, if I remember correctly, Opera 9.  The only browser that didn’t render the styles as I would have liked to see them was IE6, which is no surprise, but also has a rapidly diminishing market share.

If you are looking for a way to keep your legacy HTML from looking terrible that doesn’t involve recoding it all, this may be the way for you to go.

Recently, I’ve been working on streaming live video from IP cameras to a Flash player on a website.  It sounds simple, but not so much, (if you’re in a hurry, skip to the solution).

The problem is that most IP cameras are not made for streaming live, full-motion, events to the web.  They’re made for surveillance at 11 FPS in Motion JPEG format, (that’s just a bunch of JPEG images coming one after another).  This is obviously not ideal from a bandwidth perspective at all.  The cameras that our project uses are Axis 207 and 210 cameras.  These cameras are capable of streaming MPEG-4 video, and when you look at the video in a web browser it looks pretty good.  When I first saw that, I was excited – I could just stream into a Flash media server, (We’re using Wowza Media Server Pro at the moment), and that would send everything off to the player, right?  Wrong.

It turns out that most, if not all, Axis products stream in MPEG4-ES, which flash cannot understand, and therefore our server rejects.  I had to find a way to change MP4V-ES to h.264.

The obvious solution to transcoding the video stream from MP4V-ES to h.264 is VLC.  While it looks like a media player that can handle a lot of formats, under the surface lies a powerful, command-line based, transcoding and streaming program.  I discovered that, in theory, I should be able to issue one command to VLC and have it receive the MPEG4-ES stream from the camera, transcode it to h.264, and stream it to the Wowza, which would handle the rest.

I started by opening a file, transcoding it to h.264, and streaming it to Wowza:

vlc -vvv /path/to/file/Extremists.m4v --sout "#transcode{venc=x264,vcodec=x264,vb=500,scale=1,acodec=mp4a,ab=32,channels=2,samplerate=22100}:rtp{dst=SERVER-IP-ADDRESS,sdp=file:///path/to/wowza/content/myStream.sdp}"

It was a little rough, as the testing server doesn’t have a lot of processing power, but it worked.  Awesome.  Now I just have to hook it up to the stream from the camera, right?

I added the camera as the source and removed the sound:

vlc -vvv rtsp://camera-ip-address:554/mpeg4/1/media.amp --no-sout-audio --sout "#transcode{venc=x264,vcodec=x264,vb=200,scale=1}:rtp{dst=SERVER-IP-ADDRESS,sdp=file:///absolute/path/to/wowza/content/myStream.sdp}"

With Wowza already running on the server, I typed that in to terminal, and it started to look good.  Then PAF! I get this error:

[00000385] access_output_udp private debug: mmh, hole (147841635484807 > 2s) -> drop

VLC seems to think that a frame, or some piece of information has been delayed 147841635484807 seconds.  I highly doubt that, but VLC is convinced.  Try as I might, I was not able to get VLC to realize that the frame, (or whatever bit of info), was simply missing a timestamp or something.

So, I figured I would debug just the connection to the camera.  I opened a VNC session, and ran this:

vlc -vvv rtsp://camera-ip-address:554/mpeg4/1/media.amp

To see if I could view the video.  I could, so I tried saving it to a file:

vlc -vvv rtsp://CAMERA-IP-ADDRESS:554/mpeg4/media.amp --no-drop-late-frames --no-sout-audio --sout "#std{mux=ts,access=file,dst=/tmp/camstream.m4v}"

This worked also.  It appears that the problem only occurs when I am trying to open, transcode, and send out the stream all at once.

I realized, if I can transcode from a file and stream, and if I can capture a stream and save it to a file, I should be able to do both at the same time.  It works!  The steps are, make the pipe:

mkpipe /tmp/vpipe

Then capture the stream and save it to the pipe:

vlc -vvv rtsp://CAMERA-IP-ADDRESS:554/mpeg4/media.amp --no-drop-late-frames --no-sout-audio --sout "#std{mux=ts,access=file,dst=/tmp/vpipe}"

And finally read from the pipe, transcode, and stream to the flash server:

vlc -vvv /tmp/vpipe --no-sout-audio --sout "#transcode{venc=x264,vcodec=x264,vb=500,scale=1}:rtp{dst=SERVER-IP-ADDRESS,sdp=file:///path/to/wowza/content/myStream.sdp}"

Shazam!

There are a couple of caveats, though:

• This sucks major processing horsepower.  Make sure you’ve got enough
• To make a stream work this way you have to have 2 copies of VLC running, plus your flash server.  That’s a lot of parts that could have a problem

Because of these caveats, I am still looking for an alternate solution, and may stream MPEG-4 to browsers until Axis has its h.264 products ready later this year.

Yesterday, I did find a second possible solution.  Instead of using the first instance of VLC to capture the stream, it is sometimes possible to use Darwin Streaming Server to capture the stream, then use 1 instance of VLC to transcode it. This seems to use much less processing power, but is not 100% reliable either.

A month ago I wrote about setting up an in-house subversion server on the cheap. After a month of using my setup it’s been pretty successful, and I’ve learned even more about subversion.

One of the things I had to do was set up a post-commit hook to publish changes to a webserver.  The site I did this for is still in development, and every commit needed to be pushed to the webserver for testing.  I did this using rsync, (or, since the SVN server is in Windows, cwRsync), and it’s a pretty basic rsync/openSSH setup, but that’s for another day.

What I am talking about today is actually creating the hook script.  What a pain in the ass.  It’s not actually hard to create the script and run it.  On Windows you just write a batch file, debug it, call it post_commit.bat, and drop it in the hooks folder of the repository you want to use.  Sounds simple, doesn’t it?  Why then, when you commit a revision, does Subversion hang, and the script not execute?  Because subversion runs hooks in a near-null environment. This means that nothing is set.  In Windows, not PATH variable.  In everything, pretty much no environment variables of any kind.  So, when you tested your script yourself it ran great because it had lots of support, but now Subversion is running it entirely alone.  Poor, lonely script.

It gets even more frustrating.  Since Subversion is running the script, there’s nothing being printed to the screen to tell you what’s going on, so debugging is like shooting bugs in the dark.

There are a couple of things you can do, however, to make your script work.  First, use an absolute, full, path for everything.  For Windows this means start with the drive letter.  For *nix this means start with a slash.  If that doesn’t work, there’s a trick that allows you to see what’s going on.  You can log the hook’s output to a file.  This way you can find out what’s going on, read the errors, and fix them.  Thanks to Dan Switzer for posting about it. His blog showed up in a Google search and ended my frustration.  In my case, it was some more environment that had to be set up for cwrsync to work properly.

A while ago I read about, and downloaded the new Versions subversion client.  I had never used subversion before except for grabbing a bit of code once in a while and was excited to try it out.  Even though I usually work alone the idea of versioning is very appealing – that way if anything goes wrong I can revert quickly to a previous working version.

Versions is great, but thats a topic for another post.  The problem I ran into was the 1-repository and 20 MB limit on the free Beanstalk account is too low for me, and the entry-level price of $15 a month is higher than I want to pay.  Maybe if I become a svn-a-holic I’ll pay it, but not right now. I looked at some other free subversion hosts, but decided to set up my own, without paying for anything.  First, the components:

1. The PC that is now my Subversion server.
2. VisualSVN Server, (it’s free, and I don’t have to deal with the command-line).
3. A WRT54G running dd-wrt firmware.
4. A DynDNS.org account, (so I can access the repository from the outside world – if you have a static IP you shouldn’t need this).
5. Your own domain name, (optional – just to make the DynDNS.org URL look nicer).

The basic setup is really simple.  Download VisualSVN Server and run the installer.  Choose where you want the program and the repositories to live.  It works like any other Windows installer and only takes a few clicks.  Once installed, the VisualSVN Server Manager provides a GUI to manage the server and you can set up a repository and a user with just a few more clicks.  It’s super easy. 

Once the VisualSVN server is set up you should be able to easily access the repositories from your LAN, but what if you want to work from a coffee shop?  

This is where DynDNS.org comes in.  If you don’t have a static IP address, and it changes all of the time, you will need an update service to make yourself findable from the outside internet.  I looked at several services, but ended up going with DynDNS.org because of its long history, it is free, and it allows enough requests per month that I don’t think I’ll ever hit the limit.   Go ahead and set up a DynDNS.org, (or your provider of choice), account and chose a domain, it’s Pretty simple.

Next, you will have to configure an update client for DynDNS.org.  This is a program that tells DynDNS.org when my IP changes.  Luckily, there is one built into dd-wrt.  In order for the router to know my WAN IP I had to set up the router to connect by PPPoE, (instead of the default DHCP setup, where it gets an IP address from the modem).  Luckily on dd-wrt this is very simple.  Under the setup tab there’s a drop-down for PPPoE, then you find your connection username & password and enter them in the boxes. Hopefully it will be just as easy for you. Once PPPoE is set up, go to DDNS, (a sub-tab of Setup), and enter your DynDNS.org info.  Remember to hit “Apply Settings” each time.

That’s all great, but what happens when you’re at a coffee shop and try to connect? Nothing.  DD-wrt has a pretty strong firewall.  There’s a little more setup still to do.  First, the computer with the SVN server needs to have a static IP within the LAN.  Since I don’t enjoy messing with windows network settings, I do this with the router.  Under the Services tab, in the DHCP server box, there is a place for static leases.  Enter your Subversion Server’s MAC address, hostname, (the computer name), and desired IP address there, then scroll to the bottom of the page and click “Apply Settings.” Now that we’ve got the static IP address, we can go to the NAT/QoS tab forward the the port that your Subversion Server uses to the static IP address you just set up.

Finally, to make things a little nicer, if you have a domain name, and your DNS provider allows you to add records, you can add a CNAME record to point a subdomain do your DynDNS.org domain, giving you access to your Subversion repositories via the URL subdomain.yourdomain.com.  Fancy!

One note on testing:  dd-wrt seems to be smart and knows if a request is coming from the LAN or the internet, so it’s kind of hard to test your remote access from within your LAN.   I was able to get around this by logging in to a remote desktop session of another windows computer that is far, far, away from my LAN.

That’s it, now you should have a fully-function SVN server of your own, without paying a penny. Have fun, and feel free to experiment with your code – you always have the previous version to roll back to!