chealion.ca

WORDS. On the internet. Oh my.

Using AWStats 7.0 with S3 Logs

The necessary code changes from Amazon's Tutorial on using AWStats with S3 Logs take place at line 17,764 with version 7.0 and not 10,657.

The hint? Just do a search for # HTTP request. Keep only GET, POST, HEAD for any version of AWStats.

Of note, as of the published date AWStats 7.0 does not count the files viewed correctly. I'm not sure why.

Using Compressor to Make H.264 MP4s

In April I pushed to GitHub my RewraptoMP4 Script I put together to help assist in creating proper MPEG-4 container files while being able to use the x264 QuickTime component in Compressor. Compressor only allows you to specify the codec being used when exporting to a QuickTime file, however it is possible to use QuickTime Player after the fact to convert a QuickTime Movie to an MPEG-4 without transcoding so long as the codecs are supported in the MPEG-4 container spec.

My primary reason for the extra work is that Google Chrome will not recognize a .mov file as a valid wrapper for video in HTML 5's <video> tags.

Using Compressor

You need to make your Compressor preset using x264 as a normal QuickTime movie preset (use the table below to help with settings if necessary). You'll then want to grab the script from GitHub and add it as a script to your preset.

Scripting Compressor isn't very straight forward, while you can use AppleScript or launch a script using Compressor they fail to mention that the script must be saved as an application and the file is accessed by using on open.

Helpful Table of Limitations

DeviceMax ResMax Bit RateH.264 Settings
iPhone640x4802.5 MbpsCan only use Baseline profile Level 3.0 with CAVLC
iPod touch640x4802.5 MbpsCan only use Baseline profile Level 3.0 with CAVLC
iPhone 3G640x4802.5 MbpsCan only use Baseline profile Level 3.0 with CAVLC
iPod touch 2G640x4802.5 MbpsCan only use Baseline profile Level 3.0 with CAVLC
iPhone 3G S640x4802.5 MbpsCan only use Baseline profile Level 3.0 with CAVLC
iPod touch 3G640x4802.5 MbpsCan only use Baseline profile Level 3.0 with CAVLC
iPad1280x720"Unlimited"Can only use up to Main Profile Level 3.1
iPhone 41280x720"Unlimited"Can only use up to Main Profile Level 3.1
iPod touch 4G1280x720"Unlimited"Can only use up to Main Profile Level 3.1
G1480x320600Lack of documentation for anything Android
Droid X1280x720?Lack of documentation for anything Android - can't play more than 24FPS

Android information is rather limited. Official Android information is near non-existent.

Thanks to:
- http://www.proactiveinteractive.com/software/compressor/index.php

Using HTML 5's Video To Serve Baseline and Main Profile Content

At work I was trying out to see if I could use the new video tag in HTML 5 to show two different versions of the same video; one optimized for devices that accept only the Baseline profile (eg. iPhone 3G S and older, many other phones) and one optimized for larger devices (eg. iPad, iPhone 4 that support the Main profile). Turns out it works absolutely fabulous by using the codecs section in the type (Thanks to Dive into HTML 5 for the documentation).

  
    

The video codec for H.264 is: avc1.YYYYXX where YYYY represents the profile, while XX is the level (multiplied by 10 and turned into HEX):

Profile     Value   
Baseline    42E0
Main        4D40
High        6400
Extended    58A0

Level       Hex Value   
3.0         1E
3.1         1F
4.1         29
5.1         33

Now when I visit with an iPhone 3G it loads the baseline version, while my iPhone 4 and iPad both load the Main Profile version. For my current project I use video for whenever Flash isn't available and it does leave a gap for Firefox and Opera users who don't have Flash but according to our web stats they don't actually exist.

It's also important to note that Android users are also left in a lurch because any version lower than 2.0 doesn't support <video>, and those that do can't handle a <source> element having a type value like above. To top it all off it isn't able to play or show controls on a video on it's own. You have to add some JavaScript to your page in order to play to pass the click event and tell it to play.

Mail.app, Outlook, Attachments and Disappearing Text

There's a particularly nasty implementation detail that doesn't seem to come up often but is just waiting to bite just about every Mac user in the ass. Mail.app allows users to attach files inline allowing them to be part of the flow of the text or in the case of one of my users be right alongside the paragraph talking about the changes in that paragraph. Or like me, right below the email you're sending and above the replied emails because of Mail.app's defaulting to top posting. The issue isn't being able to put attachments inline, but the fact that by default Mail.app will encode the attachment in the same spot in the email file causing other email clients to see the rest of the email as a set of attachments.

The fix: Make sure "Always Insert Attachments at End of Message" is checked off (preference key is AttachAtEnd - boolean for you MCX minded folk) and you can now attach inline as you would normally want to without having Outlook eat your message.

Mail.app.jpg

Thunderbird will display the text correctly, but you'll lose it and it will only appear as an attachment once that email is forwarded or replied to: (Part 1.1.3 is the text "There's an attachment"). You'll also notice the horizontal rule separating between the different HTML portions of the email.

Thunderbird.jpg

What program completely falls flat on it's face is Outlook; it just puts all attachments off to the side and you have no idea what's in the those ATT documents and your client sure as hell isn't going to read them. So you've sent the email, the email was successfully sent, the text will be visible on their webmail systems, on their mobile device (Blackberry or iPhone), and even visible in other mail clients but because it's technically an attachment Outlook won't display it inline by default. (For the same reason they won't show images by default in emails - the cookie tracking and that it's a great attack vector)

Outlook.jpg

Of note, this only occurs when sending from Mail.app. Outlook can attach items inline and have no issue as it attaches the images at the end of the email.

Correct view:

OutlookCorrect.jpg

Comments, No Comments, and When It Doesn't Matter

Today I've been heckling D'arcy Norman on Twitter about his plan to try out turning off comments on his blog. The discussion of comments versus no comments is not new but has come to the forefront again because of Gruber's defence of not allowing comments.[^1] D'Arcy has done a good job showcasing several opinions on the matter - so good read his post first.

Why would I want comments on my site? They provide a relatively frictionless (provided no registration is required) way for a reader to respond to something I have written to power Google's index.[^2] This includes developers responding to my criticisms of their applications, or some method of feedback. The feedback is part of the reason I even write comments anywhere else. It's still very possible to get a large volume of feedback relevant and helpful to the article/essay/what-have-you without detracting from it. (eg. Coding Horror as an example - not always, not perfect but on a whole a decent example) Comments at one time also help differentiate the "new media" from the "old media", it promoted the idea that the reader could be involved instead of just a a passive listener.

Why do I think I should remove comments from my site? Spam and focusing on the content. I don't like being required to run Akismet, or remembering the issues of using Moveable Type 2.x and the necessity of MT-Blacklist. Erasing the spam issue is definitely enticing, especially with some many other avenues of feedback.

Additionally once comments grow beyond a certain quantitative threshold they simply become drive by soapboxes or discussion boxes with little to no control of their direction (unless heavily moderated) and relevance to the whole point of the page's existence. If you really want people to discuss with each other about something you've put forward as a conversation piece? Consider setting up a proper forum[^3] for the thread control so it doesn't feel like a discussion has been shoehorned into something that doesn't quite fit correctly. Personally the whole point of my corner of the web is not to make conversation pieces but to showcase something I actually want to broadcast more widely to the world.

But wait. Why should I even care if they're on or off? Be practical - for many comments are your first way to get feedback without the roadblocks (registration, emailing, etc.) that are necessary to keep the volume manageable for higher volume sites. Comments don't scale with the purpose of a blog, website, whatever you want to call your little corner of the world wide web. If you're small enough they don't exist, if you're big enough they overshadow or fail completely miserably at being either a way to leave a note for the author or as a discussion board. So in the big picture - the choice doesn't matter. What matters is whether they are a positive or a negative impact to you, the moment it's negative kill it - there's no saving the signal when the noise gets too loud. If it's positive, keep it.

Don't sweat it and focus on writing (or doing your thing).

[^1]: RIP daringfireballwithcomments.net - it was hilarious and a perfect example as to why Gruber should keep his site just the way it is. [^2]: My traffic consists of 3 people who follow using RSS and about 30 people a day from random search terms. [^3]: This doesn't have to be proper forum software such as phpBB and such but they do offer the more advanced features one would want when dealing with diverging threads of discussion.

Curious Notes about WebM on YouTube

When looking at one of the trailers (Tetro: Original Trailer) that has been transcoded into WebM. I wanted to compare YouTube's x264 settings versus their WebM settings. I've also uploaded some 1080p footage for more recent footage (in case the H.264 settings had changed between Dec. 2009 and now - which AFAIK they haven't) to compare. It's also important to note that the HTML5 access to YouTube videos is only available on non-monetized content.

During my testing I noticed that in the HTML5 Beta on older versions of Chrome and Safari (aka H.264 using browsers) when you select 360p for your video size, YouTube does NOT give you a 360p file - it is actually smaller in terms of resolution (480x270) and has to be upscaled. This is most likely a reason why my initial thoughts on Twitter didn't match with what I had on paper.

Disclaimer: Subjective paragraph to follow - I'm not an expert and I'm judging just by general visual quality to my eye.

A quick visual inspection shows the WebM version in 360p seem noticeably sharper in terms of details than the 480x270 H.264 which had to be upscaled. The 720p WebM version was close enough to it's H.264 counterpart. However I did definitely notice with the 360p version, a "quality bump" every once in a while as described in the ratecontrol section of a blog post by one of the x264 developers when criticizing the VP8 specification.

Using MediaInfo Mac the following settings can be found:

Tetro Trailer (Originally encoded 12/26/09)

Resolution Container - Codec Total Rate (kbps) Video Bit Rate File Size (MiB) Notes
640x360 WebM - VP8/Vorbis 812 ? 14.2
480x270 MPEG4 - H.264/AAC 500 393 VBR 8.7 Baseline Profile - HTML 5's "360p"
640x360 FLV - H.264/AAC 677 568 11.8 Main Profile
1280x720 WebM - VP8/Vorbis 2887 ? 50.4
1280x720 MPEG4 - H.264/AAC 2172 2045 37.8 High Profile



Part of the reason I chose Teatro is that it has some excellent DOF changes, the other reason is that I just liked the visual style of the trailer. It was also the first trailer I clicked on that worked in the HTML5 beta that didn't resort to using Flash because it has been monetized.

12 Second Test Clip Uploaded Today

Resolution Container - Codec Total Rate (kbps) Video Bit Rate File Size (MiB) Notes
640x360 WebM - VP8/Vorbis 709 ? 709 KiB
480x270 MPEG4 - H.264/AAC 508 415 VBR 751 KiB Baseline Profile - HTML 5's "360p"
640x360 FLV - H.264/AAC 542 466 835 KiB Main Profile
1280x720 WebM - VP8/Vorbis 1736 ? 2.61
1280x720 MPEG4 - H.264/AAC 2120 2005 3.06 High Profile



What's the conclusion for what YouTube is offering? Visually, WebM can be made to look quite decent - especially for what I believe is it's target market; the web and mobile devices. However on higher resolution and higher bit rates, H.264 definitely appears better. I don't think most people will notice - they're close enough with the current settings. However I do believe that the WebM settings are more fine tuned than the x264 settings to get a little bit more video quality. Encoding my sample 12 second video with a relatively recent version of x264 locally with some rather generic settings is more visually appealing than YouTube's.

Even though H.264 is definitely better on paper, I think VP8 will do just fine as a replacement for Theora and a competitor to H.264 for use on the web. For the near future (next 3 months IMO) you won't see a lot of WebM footage available as the playback availability is extremely limited.

i5/i7 MacBook Pros do NOT support Jumbo Frames

While doing some research I discovered (first with the 27" iMacs) and now with the new MacBook Pro line that runs the i5 or the i7 processors; Apple has slotted in an ethernet controller that does NOT support Jumbo Frames.

See page four of the PDF of the Broadcom 5764 Chipset

Own This World : iPhone app review

This review referred to the version 1.3. Version 2.0 and 2.1 have been released that make the game even better (and address most of my issues with it). Go check them out.

Own This World is a location based game for the iPhone by Big Nerds in Disguise a company in Calgary, Alberta. I discovered the program via yycapps and purchased it to try it and support a fellow Calgarian company. After a week of playing it solidly I wanted to share my opinions.

The game itself is an odd (but extremely neat) cross between Risk and real life ("a geo-dependant online game" - yycapps), pitting different users against each other in their own backyards by spending time accumulating troops in territories in order to accumulate more resources and hopefully rule the world (by actually travelling the world).

It's a very intriguing and novel idea but suffers from some design flaws that takes the diminishes the fun of the game.

The Good

The application design is very straight forward, giving you a map of your current location overlaid with the territories used in game. The application performance is relatively decent, moving around on the map and it starts up in only 10 seconds on my iPhone 3G. The best part is that the opening 10 seconds or so counts down meaning the time waiting for the application to finish starting up counts towards gaining troops. It's a little touch that makes the experience as a casual game much more pleasant.

The game itself is not a fast moving game, in many ways it feels like a day based turn based online game of old. OTW however makes it very interesting (read: addictive) once you get involved with other players, either through attacks or simply taking over a territory. The activity and frequency of "violence" means that the troop counts (at least in Calgary) haven't become insurmountable leaving the game approachable by new users; especially in the more heavily populated (by users) regions of the city.

OTW promotes getting out and investigating the city, and even enjoying heavy traffic in order to spend more time in zones you normally only pass through - so you can rack up troops in hopes of being able eventually overthrow the leader. It also requires that the user be in the territory that they actually want to attack and have at least 1 troop giving attacks a new tangible cost - especially if wanting to strike back at someone who has several other territories. It drops the sniping and requires the player to be more active within the game.

OTW also offers (via in game purchase) the ability to create your own world so that you can play the game with just friends and ignore the rest of the public. It will carry over your current troops in different territories - it'd be a great way to turn some of the bits of the game I really dislike (see below) into advantages.

The Bad

The largest downsides to the game is that leaving the game on all the time chews through your battery like no tomorrow as it opens a new network connection every 30 seconds to talk to the server. Turning off the screen I found didn't help as it would often mean that the application would not record your time accurately (instead of 1 troop every 30 seconds, it seemed to be 5 or 6 every 10 minutes or just stop once I let the screen turn off). The slow pace of the game and the requirement to actively go check your status in the game can be a bit tedious at times.

The UI of the game itself for the most part is straight forward and intuitive but several bits just don't feel like they "fit" (subjective warning) with the iPhone. The sliding information bar below the map in the Conquest view just doesn't feel right. Maybe it's the ALL CAPS, or the font choice but it looks very out of place. Especially if you have a double width status bar (eg. Internet Tethering, on a call, etc.)

By far however the worst part of the UI design is the user selected colours; from the RGB selection sliders in the User Info (functional but not very friendly) right through to using the user's selected colour everywhere their name appears in the game. Black on black does not easy reading make.

In terms of attacks, there is no defence against attacks. If your hours of work establishing troops is blown away by someone driving by who has several hundred territories or purchased resources your only recourse is to rebuild. After all it's a game like Risk where territories are won and lost frequently. Don't bet on making a stronghold aim for gaining lots and lots of territories if you want to last - and so if your job isn't conducive to road trips outside the city, consider making time on the weekends.

The Ugly

The ugly bits are by far the largest reason I'm uninstalling the game from my iPhone. The first is the ease of being able to track a person in real life - by using the User search I can see where someone last checked in and if I really care enough it's quite easy to know the areas of town where a person is likely to live and/or work. I find that the tracking information is too easily discernible and it leaves a bad taste in my mouth - however it's not a fault of the game itself but a downside of the concept. My best recommendation is that unless you're playing in your own world with friends, be aware of mixing your game identity and your personal identity. The odd part is that you can't find out any other details about the users - how many territories they have or other details unless they are on the leaderboard.

The other bit that really rubs me the wrong way is the $0.99 micro transaction that allows users to buy 100 of each resource, and once I had been on the end of where a person was just throwing money at the problem to attack my territory if only because it's insanely more economical for the player when dealing with more than a couple hundred troop difference. It doesn't actually level the playing field in any respect, it means those who feel like pissing away a loonie or 4 away can take someone from 12000 troops (~100 hours of having the app running on your phone) to nothing (as seen in downtown Calgary). It's infinitely faster than building up your resources and/or fighting within the city for territories. It harms the game balance that exists. I can understand the reasoning behind such an option - it's something I find takes away from the game in it's current form.

Conclusion

It was a lot more fun than I expected but honestly not worth the time investment and/or the sheer battery life drain. It was intriguing and reasonably well done but has too many flaws to give it more than the 3/5 stars I rated it on the App Store. I know I couldn't have made an app that well, it's definitely not an app I'd recommend buying but definitely worth looking at as an example of where gaming on a smartphone opens up new interesting challenges.

Google Chrome on the Mac - When beta doesn't mean beta

I've been using Chromium (the developer version of Chrome) since May side by side the WebKit nightlies. They're very fast and I like Chrome quite a bit however I won't be moving to Chrome/Chromium as my main browser. Yet. After all it's still a beta and under very active development.

And like any craptastic method of making sure one has an easy time of making an article/blog post/etc. a set of pros and cons as to what I like and dislike about Chrome/Chromium)

Pros:

  • Super fast, uses a newer version of WebKit than Safari. (If you like Safari but want the new versions of WebKit - use nightly.webkit.org - will never use Vanilla Safari again)
  • Automatically updates itself silently (Chrome only, Chromium must be manually updated
  • Updates often so new features and bug fixes in WebKit show up quite quickly.
  • Bookmark Sync (this came online last week). Awesome.
  • If one tab crashes the entire program doesn't crash. Huge. Not as huge since Safari started sandboxing Flash but huge none the less.

Cons:

  • Silently installs an auto updater that is hard to remove and impossible to control in a managed environment.
  • Extension support not easily accessible
  • Bookmark Management is near non-existent. It's a completely broken feature at this time.
  • No Click To Flash yet. Flash Blocker is a poor substitute.
  • Tabs just become a set of mountains when too many are open.
  • Top Sites look alike feature isn't as customizable. Oddly I use Chrome's Top Site feature but not Safari's.

I like it a lot but I believe calling it a beta is disingenuous. A beta usually refers to something feature complete and in bug testing. My usage however says that it's very solid but that new features are being added all the time. The reality is that Google Chrome is being treated like a web application - iterated fast and often and there is no real distinction between alpha, beta or a final "1.0" version number. Just a stable and unstable branch and the version number to correspond to where development is at.

It's a bit more chaotic but represents a change in how developers can approach development, after all there are no instances of a user using a version 3 or 4 versions old when you make sure everyone is using the latest version all the time.

Xdebug, Leopard, and 64-bit shenanigans.

In order to profile some in house web application development and find out a couple bottlenecks that were appearing I went looking for a decent PHP profiler and found Xdebug. Because I am using the built in version of PHP on the Leopard Server, and a MacPorts version on Snow Leopard (we also have an application that fails miserably on PHP 5.3) it lead to some fun installing Xdebug on the Leopard machine since I didn't want to reconfigure apache2 to use PHP 5.3 from MacPorts.

The crux of it is to grab the source of Xdebug, and then when configuring prefix your standard ./configure --enable-xdebug with the statement CFLAGS='-arch ppc64' or CFLAGS='-arch x86_64' as necessary. Compile xdebug as a 64-bit extension and it will actually work with a 64-bit version of Apache. With MacPorts it was as simple as enabling the xdebug variant and letting it recompile PHP.

I highly recommend using webgrind. It gave me more useful results than MacCallGrind, and didn't require an hour hoping MacPorts could compile all the dependencies for kcachegrind (which would require graphviz as an additional install). Now I have some numbers to tell me where to look for proof old me is a moron.