Hi Tyler,
Thanks for the feedback, to be clear, I'm not putting in the "\x3d" into the URL, the ad server (DoubleClick Campaign Manager) is formatting it that way. Below is a screenshot of how the URL is entered within the ad server UI (with "&" and "=") and the VAST tag the ad server responds performs this "\x3d" encoding on the "=" characters (apparently it's the hex ASCII representation), so we have no control over this behavior by DoubleClick:

Would you say this is then a bug on the ad server side to be encoding the URL with these ASCII hex representations of "=" and "&" signs? Note that the JW Player and Zedo player do *not* have a problem handling the "\x3d" encoding and other VAST validators indicate the VAST is compliant. I used these other two VAST validators to playback the video in HTML5 rendering mode:
If you switch to using the Google IMA3 on the JW Player site the ad won't play, otherwise it does play. At the very least I would expect the IMA to play the video and not freeze all playback content for 15 seconds and destroy the user experience due to a click through URL that may not be valid. If you take the oddly formatted URL and put it into the URL field of Chrome or Firefox it can handle the URL gracefully, even if not technically correct.