I’ve been working with data-driven tables a little bit recently, and the need came up to allow users to click on the table cells, and to persist a record of these clicks. Rather than store this in the database, it made more sense to use cookies. Not having worked with cookies for a while, I started playing around. I ran into a few gotchas.

FIRST GOTCHA: Cookies can only be managed in the context of a web server.

Everything started great. I found some sample code online to base the solution off of, and I began to I hooked all the events in, but data wasn’t persisting. No errors were being thrown. After some debugging work, it looked like it was never being set. Incidentally, this was because I was running the file off the file system (file://clickClick.html). No errors are thrown, no warnings are raised, it just won’t set unless you run it from a web server. After starting up Apache and running it from localhost, everything worked great. For a while.

SECOND GOTCHA: With jQuery, the unload event is on ‘window’, not ‘document’

My plan was to save the click results to a cookie when the page leaves, either via refresh or leaving the page altogether. Not bothering to read the documentation thoroughly, I tried this and expected it to work:

$(document).unload(function() {   ...   });

Turns out it didn’t. After some trawling of jquery’s documentation, I discovered it was the window object I wanted to hook into, not document. As with the cookies, this didn’t fire off an error, it just hooks into a user-created event that, unsurprisingly, is never fired by the browser. Switching ‘document’ to ‘window’ fixed this.

FINAL GOTCHA: Internet Explorer does not seem to support character indexing via [] operator

My method of saving data to a cookie is serializing a table into a string of ’1′s and ’0′s and storing it in a cookie, then reading that string back from the cookie and acting on it. Firefox and Chrome could handle reading individual characters fine by indexing the string like an array:

if(oldCookieVal[i] === '1') {
              ...
}

When testing on IE, I got an “unsupported property” error. Turns out IE treats strings like any other object, and will use indexing to perform a property lookup on the object. So if i = 3, instead of retrieving the fourth character in a string, IE was trying to do this:

if(oldCookieVal.3 === '1') {
              ...
}

Which broke the code. Switching to using the ‘charAt’ js function fixed this. Another solution would’ve been to split the string into an array before processing it.

With these lessons learned, I successfully created a working prototype of a solution. You can see the final result here. It has been tested on Firefox 3.5.19, 6.0.2, Chrome 14, IE 9, Safari 5, and Opera 11.01/11.51. Presently there’s an issue with Opera not hooking into the unload event through jQuery, but moving the cookie setting code into the ‘mousedown’ event handler solves this.

Popcorn 0.5 has also come out today, and includes some of the results of this effort. A custom player for use with Soundcloud has landed, which can be used with Popcorn simply, like so:

var popcorn = Popcorn( Popcorn.soundcloud( "contentId", "http://soundcloud.com/fitn/cotton-in-the-ears" } ));

Using the Soundcloud player with Popcorn like this will place Soundcloud’s player inside the HTML Element on the web page with the corresponding id “contentId”. The Soundcloud player will then play the track found at “http://soundcloud.com/fitn/cotton-in-the-ears”. This can then all be controlled through Popcorn, complete with timed track events. Be sure to check it and more out in the new release.

var undef;

var MediaElement = {
  load: function() {},
  play: function() {},
  pause: function() {},

  readyState: 0,
  currentTime: 0,
  duration: 0,
  paused: 1,
  ended: 0,
  volume: 1,
  muted: 0,
  playbackRate: 1
  // These are considered to be "on" by being defined. Initialized to undefined
  autoplay: undef,
  loop: undef,
};

Those are a subset of methods and attributes and a give a good start, though there is a whole lot more functionality that may be implemented if desired. Even though we have the attributes, one important mechanism is missing. Videos update at regular intervals, which is something we’ll need to account for in our video object. This is also incredibly easy to do. According to the spec, time updates should occur every “15 to 250ms”:

var msDelay = 250;

function timerTick() {
  // Run code here

  setTimeout( timerTick, msDelay );
}

The above code will execute the “timerTick” function every 250 ms. I’ve created a timed loop using setTimeout instead of setInterval because setInterval has the unfortunate side-effects of not firing at reliable times as well as eating errors. In other words, setTimeout is used so that the program will let me know if it’s not working properly, as well as it will not be delayed by other js code that is executing on the page.

With this in place, these two code snippets can be tied together (with less than 10 extra lines of code) to create a basic video wrapper:

var undef;
var msDelay = 250;

var MediaElement = {
  load: function() {},
  play: function() {
    this.paused = 0;
    // So we can keep track of the instance
    timerTick.call( this );
  },
  pause: function() {
    this.paused = 1;
  },

  readyState: 0,
  currentTime: 0,
  duration: 0,
  paused: 1,
  ended: 0,
  volume: 1,
  muted: 0,
  playbackRate: 1,

  // These are considered to be "on" by being defined. Initialize to undefined
  autoplay: undef,
  loop: undef
};

function timerTick() {
  // The player was paused since the last time update
  if ( this.paused ) {
    return;
  }

  // So we can refer to the instance when setTimeout is run
  var self = this;

  // Run code here

  setTimeout( function() {
    timerTick.call( self );
  }, msDelay );
}

And just like that, you have a custom HTML5 “Video”. Check out a simple demo or view the source here.

I’ve been doing a lot of twiddling with this lately, and see lots of applications for it. A simple example is a slideshow, made up of an array of images timed to change every, oh, five seconds or so. This is no different from an ordinary video where thousands of images change at a rate of 24 or more times per second. If this ordinary array of images were wrapped to look like a video, it could then be tied into Popcorn and let loose. Not only could a slideshow be started, stopped and seeked through but other neat options begin to open up.

What if we want to dynamically caption the slide show images? What if we want to cue an <audio> element to play a sound for different sections of the slide show? What if we want to show additional information about the images or author like Twitter, Google Maps or more? This functionality is readily-available through Popcorn’s plugins. But if we really want to get creative…

We could make one of the images in the slide show actually be a <canvas> element hosting a Processing.js sketch which plays for a few seconds in the middle of a slideshow. In that Processing.js sketch we could then have JavaScript that runs completely independent of Popcorn but may interact and control it to create a relationship where the player and video feed off of each other. We could also simplify things and just go back to our array of ordinary images but increase the cycling time from once every 5 seconds to once every 1/24 of a second to create fluid motion. Doing this would emulate a video in every sense, but 100% dynamic images means 100% dynamic video content.

Eventually, I see the only limit being imagination.

HTML5 Video (like HTML5 Audio) implements a standard interface called “HTMLMediaElement”. You can check out the spec here. To get a video-like object going, all one has to do is have a JavaScript object define the methods and attributes of this interface. Such is the nature of open web, where innovation only requires knowledge and expectation of an interface. While some work in this area has been done for the 0.4 version of Popcorn (out now), the real playground will open for the 0.5 release where it will be as easy to create custom “player plugins” as it is right now to make ordinary plugins.

Time to start getting inspired.

• SRT
• WebSRT, now known as WebVTT
• SSA
• ASS
• SBV
• TTML

One caveat in this wide support is that, like TTXT before them, the initial implementation will have much of the style information being ignored for now. This won’t affect SBV or standard-compliant SRT files, but the remaining will have their styling information stripped from them… for now. We hope to be supporting style information soon, however. In the mean time those formats that support HTML-compliant in-text styling information will work courtesy of the browser’s native display capabilities.

For example, since many media players have expanded on the basic SRT support to handle underlining with the <u></u> tags, existing SRT files with these tags will not break. However, SSA-style commands, which follow a syntax like this:

{\commandArg1} or {\command(Arg1,Arg2,…)}

are also found in SRT files. Even though styling these tags is not immediately supported, the commands still won’t show up as part of the subtitle text: they will be hidden from view. So if you have a subtitle file and want to use it, what do you do? Just include popcorn, the parser plugin and the subtitle plugin in the web page like so:

<head>
   <script src="../../popcorn.js"></script>
   <script src="../../plugins/subtitle/popcorn.subtitle.js"></script>
   <script src="popcorn.parserSRT.js"></script>
</head>

These files will register all the appropriate code with popcorn, meaning all that’s left is to specify the subtitle file. This is done on the video element via the data-timeline-sources attribute:

<video id='video' controls data-timeline-sources="data/data.srt" >
  <source id='mp4' src="../../test/trailer.mp4" type='video/mp4; codecs="avc1, mp4a"'>
  <source id='ogv' src="../../test/trailer.ogv" type='video/ogg; codecs="theora, vorbis"'>
</video>

And with that bit of work, Popcorn will do what it does best, which is to take care of the rest.

So I started researching. Given that this dealt with IO, I wanted to make sure I adhered to a few good practices, and to learn about others. For this, I had to consider the low-level implementation details. First consideration…

Cluster Size

Windows file systems (NTFS, FAT and exFAT) allocate space on the hard drive according to something called cluster size. File allocation on the hard drive must be a multiple of the cluster size. Files up to the cluster size (lets say 4 KB) will take up that much space on the disk. If the file contents amount to less (lets say a 2 KB text file), the rest of the drive space is padded. This is done for speed reasons. Files larger than the cluster size (6 KB) will have extra clusters allocated to allow for the entire file to be stored (8 KB on disk). The relationship can be generalized as:

disk space = round up ( file size / cluster size )

One downside of this is that every file which isn’t equal to exactly the cluster size has wasted space. Another is that since the OS reads in information in entire clusters, performance suffers if file size is less than the cluster size (only some of the data on the cluster is relevant). While the age of terabyte hard drives makes the first downside negligible, the second should still be a concern. However, given this being an academic exercise, I opted to make my high scores file be the cluster size.

So just how big might the cluster size be? Optimal cluster size varies by file system, operating system and hard drive size, but by and large a reliable figure is 4KB. According to Microsoft this is the default on NTFS for any Windows NT 4.0 machine, or anything newer than Windows 2000 with a hard drive size under 16 TB. Given that the game will require DirectX 9 and will likely run on a home computer, the Windows 4-6 family is almost certainly to be the host OS, and NTFS is a near-guarantee for the file system. So until 16 TB hard drives are common, I should be safe with a 4KB file size

Cache Line Size

Here’s where I had to begin to take a lot of consideration and care. With varying types of memory in computers (registers, L1 Cache, L2 Cache etc) I wanted to try and make my data structures as accommodating as possible. For this, I wanted to be sure they would fit on the L1 Cache as cleanly as possible. This way, more data could be kept there for quick transfer to the CPU rather than having to retrieve values from secondary memory like RAM. Turns out, both AMD and Intel recommend that for this, structure size should be an integral multiple of the cache line size, and aligned on that byte boundary. In other words, an L1 Cache with a cache line size of 64 works best on a 64 (or 128) byte structure stored in memory at an address divisible by 64.

Turns out, nearly all modern processors are 64-bit and work off a 64 byte L1 Cache. It’s not a guarantee to say than an n-bit processor will have a n-byte L1 Cache line size, but based on my research in the Pentium family, it’s a fair assumption. So I started trying to juggle how to work with these 64 bytes. I didn’t see score going above 4 billion, so 4 bytes seemed sufficient for this. I wanted to store a date as well, which at an 8 byte value seemed enough. With 12 bytes down and 52 to go, it seemed 64 was a bit much. Aiming for 32, I then gave an extra 4 bytes for a bit field. 16 bytes down, 16 to go. And I needed a name. 16 bytes makes for an array of 8 wchar_t variables, which meant a name of 7 letters could be supported (plus 1 null byte on the end). Why wchar_t? I wanted to go beyond the 1-byte “char” to not limit myself to ASCII characters.

#define CACHE_LINE_SIZE 32
#define NAME_SIZE (CACHE_LINE_SIZE - sizeof(int)*2 - sizeof(long))/2
typedef struct score_t {               // Engineered to be CACHE_LINE_SIZE bytes in size
 int score;                            // Most commonly used member first, used in ordering (4 bytes)
 int flags;                            // Score flags (4 bytes), helps natural alignment of next item (the date)
 long date;                            // Time stamp (8 bytes)
 wchar_t name[NAME_SIZE];              // Player's name, takes up remainder. Place last to ease natural alignment
};

With this structure, I was able to fit 2 scores in one cache line. Upon seeing if I could fit 4, I realized something. At a 16 byte struct size, I would’ve stripped out the bit field, which if you do the math would allow for 3 letters to be specified as the earner of the high score. That sounded familiar…

Pac-Man Hi Score

Notice how there’s only three letters in the name field? A lot of old 8-bit games only allowed for 3 letters… Pac-man (above), Galaga, Contra, and Mario among them. Given the knowledge that they ran on an 8-bit processor and the assumption that an 8-byte cache line size was involved, along with an assumption that the character set was likely limited to ASCII characters, you have the following variation on the above:

#define CACHE_LINE_SIZE 8
#define NAME_SIZE (CACHE_LINE_SIZE - sizeof(int))
typedef struct score_t {               // Engineered to be CACHE_LINE_SIZE bytes in size
 int score;                            // Most commonly used member first, used in ordering (4 bytes)
 char name[NAME_SIZE];                 // Player's name, takes up remainder. Place last to ease natural alignment
};

Do the math and it works out that there is just enough room for 3 letters to be given. Sure, the size of an int wouldn’t've been 4 bytes on that processor, but I’m going to guess that based on the perfect Pac-man high score being realized at 3,333,360 that 4 bytes were allocated for the score field all the same. Maybe first, middle and last initials weren’t the real reason for having a 3-letter high score entry.

At the end of it all, I used the first code snippet in my game: 4,096 bytes of high scores at 32 bytes/score makes for a hefty 128 high scores. However the real joy I took out of this wasn’t the code but gaining new insight into some of my first games, with a  like-mindedness of trying to eke out every cycle possible. Code on.

What does this mean?

For developers, it’s easy to add onto popcorn. Their page covers just about everything you could need to know, and once you learn the intuitive API it’s all systems go. For this initial TTXT support it was as simple as using the existing subtitle plugin and writing a custom parser to convert a TTXT file into subtitle objects. Probably about 40 executable lines of code needed in all.

For Popcorn.js users, I can see this being quite advantageous as well. With the ease of adding functionality, new features are able to be developed quickly and with minimal impact on what’s already in use by Popcorn.js. This means the web pages using Popcorn can only get more dynamic as time goes on.

Back to TTXT: It is a robust standard. I’ve studied the spec and am beginning to learn it all, but thus far only the text information from a file is processed; not the styling information One of the benefits of TTXT is it’s rich support for styles down to a per-subtitle, per-character level. This means one subtitle can be half 12pt Arial font, half 36pt Courier. Another subtitle could be all Verdana and in red, except for a desired letter to be blue. This styling information is what I’m least familiar with about the standard.

My friend Anna has already put the call out if anyone has some more complicated TTXT files to contribute to be studied and run by our parser. I’d like to re-issue the call here, and would be interested in hearing from any developers or film makers who have more familiarity with this standard.

In 1970s, there was a 8-bit CPU war going on between (amongst others) Intel and Motorola. Motorola’s team in charge of development of a new chip were soon moved to the small-time MOS company. To make a long story short, the team ended up producing the 6502, a competing 8-bit processor at 1/6 the cost of Intel’s and Motorola’s leading designs, sparking “a series of computer projects that would eventually result in the home computer revolution of the 1980s”. How influential was the 6502? For starters, it came bundled with the wildly popular Commodore, Apple and Atari home computers of the time, with variants of the 6502 also gracing Nintendo’s NES and Atari’s 2600 video game systems.

Moving forward in history, we now have cutting edge HTML 5 running on web browsers on computers with 1,000,000 times the memory that the Atari 2600 could support (8 KB could still do amazing things). And now, the group from Visual6502.org has made a great visualization of the processor in action using HTML 5′s canvas. The demo comes with a custom program which can be executed step-by-step with each instruction lighting up different transistors on the processor.

The best part? There’s a github repo: it’s open source.

What to do?

Turns out, we can load BBB.js dynamically as needed from other js files. As many js developers know, you can check if a variable has been used by doing this:

typeof(bbb) === 'undefined'

This statement will return true if bbb has not been declared or assigned to. So with this, we’re already part-way there: we know if our library (bbb) was not included on our test page. So from here, we just need to load it. Guess we’ll have to make another XMLHttpRequest to get it!

if (typeof(bbb) === 'undefined') { // No record of global BBB, must've been forgotten on test page
  var xhr = new XMLHttpRequest();

  xhr.onreadystatechange = function() {
    if (xhr.readyState===4) {
      // Execute BBB.js and populate in bbb variable
    }
  }
  xhr.open("GET", '../BBB.js', false); // Not async, test code below depends on having global bbb object
  xhr.send(null);
}

So now we have a way of getting BBB.js if the HTML page doesn’t do it. However, BBB.js comes back as text. if put at the top of a file, the code above will simply retrieve BBB.js from the server and have it sit there. So we’ll have to execute the text as JavaScript. And for that… we use EVAL.

Long-touted as lazy, dangerous and inefficient, eval is great for executing text as JavaScript code. It’s often misused aand security and performance almost always take a hit. If you tell someone you’re using eval in your library, the natural reaction to expect is “REALLY?”. This, of course, after the typical recoil in horror. Turns out, resolving dependencies is one of the few things it’s good for. When added to the code above, it will execute the requested js file and (in the case of a library like BBB) will have a variable stocked full with your code and ready to use. Package the whole thing into a function and you have something like this:

function requireBBB(fileRef) {
  if (typeof(bbb) === 'undefined') { // No record of global BBB, must've been forgotten on test page
    var xhr = new XMLHttpRequest();

    xhr.onreadystatechange = function() {
      if (xhr.readyState===4) {
        eval(xhr.responseText); // Execute BBB.js
      }
    }
    xhr.open("GET", fileRef, false); // Not async, test code below depends on having global bbb object
    xhr.send(null);
  }
}

requireBBB('../BBB.js');

And this works. Or at least it should. It didn’t for me. Convinced that it was something wrong with this function, I plugged alerts on every other line of code. I used Firebug. I used everything at my disposal to figure it out. Finally, after far too long, I got a hunch. I pulled up the BBB.js file and found the first line to be this:

var bbb = (function(){

Seems  innocent. Run a self-executing anonymous function and store the result in locally-scoped variable bbb. Wait, what? We’d never run BBB.js outside of global page scope, so local scope was always window and it had always worked. However, eval’ing the library code from the xhr.onreadystate function, bbb isn’t put on the global window because that’s not the context the code is executing in. Instead, bbb became a member of xhr. The function then finished and bbb blipped out of existence as quick as it blipped in. A change in BBB.js to this:

bbb = (function(){

And everything works. The variable is declared as implicitly global and can be accessed elsewhere. The moral of the story: always store your library at global scope if you want to manage dependencies or otherwise avoid scope-related issues.

There is a downside to dynamic loading: performance. Every XmlHttpRequest means a hit on performance; ideally you want to put all js code in it’s own file, and the same for CSS. In fact, using this on-demand js-loading breaks #1 on Yahoo’s list of “Best Practices for Speeding Up You’re Website“. However, since users won’t really be needing the testing framework (and it will just be extra JS for the browser to work with if included in BBB.js) this should be okay. While I have yet to try it, I hope to do a bevy of performance testing using (amongst other tools) the Firefox extension YSlow before formally pushing out 0.3.1. Even without formal profiling, we’ve already caught a few other minor improvements to performance!

Stay tuned for 0.3.1…

UPDATE (Jan 20, 2011): After working on popcorn and learning a few things, there is a much better way than the use of eval. Seems JSONP makes use of dynamic script tags as a way of issues cross-origin requests. This works equally well to dynamically load libraries (like jQuery) and looks much cleaner than XHR:

var head = document.getElementsByTagName('head')[0];
var script = document.createElement('script');
script.src = "http://code.jquery.com/jquery-latest.min.js";
script.type = "text/javascript";
head.insertBefore( script, head.firstChild );

• Hooking up dummy server calls on chapter addition/deletion
• Toggle subtitles on/off
• Refactor Bookmark object to optimize for memory consumption
• Time In/Out Buttons for setting chapters rather than manual typing
• Popcorn-formatted metadata generation (will be sent to same dummy server)

With the first three being completed by my last BBB-related update. Since then, the list grew to a few more to include:

• Refactor: Automate library loading via DOMContentLoaded event
• Refactor: Create “storage” module from existing functions

With these 7 tasks (plus minor fixes here and there) the code base underwent quit a few changes, however the core API remained unbroken with existing code. For example, while the library can hook into the DOMContentLoaded event to load automatically, one can still manually call the init() function from the onload event of the body to load all internal values. See both options below:

bbb.setupWhenReady({playerId: "player", tocId: "tblOfContents", chapterStorage: "server.php", formDivId: "formDiv", statistics: true, watermark: true});

// OR
<body onload="bbb.init({playerId: 'player', tocId: 'tblOfContents', chapterStorage: 'server.php', statistics: true, watermark: true});">

Internally, setupWhenReady() calls the init() function with the passed parameters, but the function may be called anywhere within the HTML document. Also, setupWhenReady() will call the bbb.onReady() function when finished. Override this method to execute page-specific logic once the library has loaded. Another callback function, bbb.onChangeVideo(currChap), is called when changing chapters. Taking one argument (the new chapter), it can be used to update parts of the page with internal information about the playing video. If overriding, expect to receive a Bookmark object. See it all in use when it’s used to autopopulate the chapter creation form.

Another great usability feature now implemented is optional subtitles. I discussed this at length in my last BBB blog post, but the VideoJS library we’re using (at least version 1.4) would not allow for subtitles to be optional. If a file is specified, they would play. After a bit of work on Video.js however, they’re now togglable. As part of implementing this, a bug was also found and fixed where subtitles will now display properly when scrolling backwards through the video. Both of these fixes have since also been forwarded to the VideoJS team.

The big thing about this release for me, however, is the creation of popcorn metadata (in the bbb.generator module). Presently supporting 7 command types (Wikipedia, Flickr, Google News, LastFM, Twitter, Video Tag, and Footnote), the library internally handles all form generation and functionality, however placement can be determined by supplying the library with the id of a div on the page in which to place the form. Also, using this div ID and CSS Selectors, it’s easy to style the generated form at the page level. Unfortunately, hosting limitations to the tune of no file IO in JavaScript, no PUT requests to servers, and no file writing means it’s undemoable on its current host, but feel free to check it out all the same!

And so that being that, my portion of the 0.3 release of the BBB player is complete. Minor fixes or structural changes for this release include:

• Moving free-floating page-level setCookie, getCookie functions into bbb.storage module
• Beginning of a bbb.chapters module for storing and working with chapters (though functions from 0.2 remain outside at this time to maintain a consistent API)
• Error checking, validation and output formatting for chapter and popcorn metadata creation.

See the code base on my github, especially the 0.3 branch. While this work was all done through a class with Dave, I don’t want to be done quite yet! Hopefully there’s much more work, development and contribution opportunities ahead. Luckily, with open source, that’s always the case