Thursday, February 24, 2011

Discussing: Video and the Web (part 2)

After last week’s blog post, there were a few discussions from other customers (and apparently a couple of otherwise-quiet readers) on some more elemental aspects of video. There are a lot of resources on the web for such explanations, covering a range of topics. But for sake of simplicity, let’s discuss it a bit here too.
There are three primary components to digital video:
  • The video and audio tracks: fairly obvious!
  • The codec: what type of compression is used to reduce the overall file size of the video and audio tracks.
  • The container: the ‘structure’ of the file.

Codecs are critical to ensure the overall experience. ‘Raw’ video which hasn’t been compressed is HUGE which isn’t very workable (too intense for computers to handle smooth playback and to be delivered online). Pretty much all video you see today is compressed to some degree, even HD video delivered by common TV services.
The container is easiest understood by the file’s type; common types include .avi, .mpg, .wmv, and .mov. Video playback software is often tied to a few specific formats. For instance, Windows Media Player works well for .avi, .mpg, and .wmv. Apple’s Quicktime software (and its brethren, like iTunes) are geared to work best with .mov, .m4v, and .mp4. Adobe’s Media Player was primarily tuned for .flv and .f4v (Adobe dropped support for its Media Player in 2010). Those are just a few examples; there are many other variations of software and containers out there.
And to make all the more confusing, there is cross-over between codecs and containers – MPEG is a codec AND a container. An MPEG file (container) doesn’t necessarily have to use an MPEG codec and, likewise, an MPEG codec can be used in a variety of containers. Additionally, there are several different versions of the MPEG codec (i.e. mpeg 1, mpeg2, mpeg4). AND, don’t forget, there are variations of codecs and considerations to make in relation to the audio portion of a video file as well (.mp3, .aac, .pcm, etc)!
There are some good resources on the variations of formats/containers and codecs here and on Wikipedia (1&nbsp, 2&nbsp, 3&nbsp).
There’s little debate these days that h.264 – a variation on the mpeg codec - is the most popular codec to use for most video. As noted, there are plenty of options out there but h.264 is currently a preferred option. There is debate regarding patent concerns but, that aside, a large amount of the video you see today is likely encoded with h.264…though perhaps in a variety of ‘containers’.
There are other options, of course. MPEG2 itself is still a solid codec; it’s still used for most DVD encoding for example. While showing some age itself, many digital cameras capture with a ‘DV’ codec variation, though that is usually converted into something a bit more manageable for web delivery. DivX and Xvid are also older, but popular, MPEG4 variants.
The former ‘VP6’ codec by On2 Technologies was an up-and-coming format…then On2 was acquired by Google in 2009…but fortunately, Google has since opened the spec, now called ‘WebM’ (aka VP8). VP6 is still a well-performing option in Adobe’s Media Encoder when creating FLV files. The ‘Ogg’ format (which is a ‘container’) is well-regarded in many circles with its ‘Theora’ video codec and ‘Vorbis’ audio codec. Ogg can spark its own discussion, but suffice to say that while the quality is there, it does not seem to be a common output option for most video tools yet.
Many of these codecs are in heavy competition among various camps to be either the default codec, or at least a globally-supported codec, in the upcoming HTML5 specification. It may be years before we find a solution; either an absolute ‘winner’ or enough flexibility in the spec (and willingness in the browser developers) to come to a solution which can play within a browser without a ‘helper’ application like WMP or Flash.
Until that time, however, the Flash video format remains our preferred delivery. The only device that’s a problem for are Apple’s Mobile Devices. Our bet is Adobe will refine the player enough to counter Apple’s more serious complaints. So it would seem the most prudent course of action is to support Flash while the HTML5 spec continues to mature. Additionally, with the range of mobile devices continuing to expand - and those will have Flash support - we’re not too worried about missing a significant audience by sticking with Flash, whether for general video or eLearning delivery.
Of course, if you have a known Apple-device-loving target audience, well then, we can architect a project to deliver the product to that customer base. There’s always a solution!

-Posted by: Erik L.

Tuesday, February 15, 2011

Discussing: Video and Web Delivery

A long-time customer of ours was recently asking about video formats for their web-delivered courseware; there are so many variations with so many possibilities for delivery, it was a good discussion to help clarify the options. In this case, the customer wanted to record a presentation and make it available online. They had their own video team (though that’s a service we can provide as well) who wanted to know how we’d prefer the final files to be delivered.

So, when it comes to preparing your video for online delivery, what’s the best option?

Flash video is, by far, the most common format used on the web. There has been some advancement beyond Flash, with the idealistic goal of avoiding any proprietary ‘plugins’ (i.e. Flash Player, Windows Media, Quicktime, etc.) to play video on the web, but until the issue of which codecs HTML5, and all web browsers, will support is fully resolved…Flash video remains the best solution.

Adobe’s FLV format works very well, in our experience. Since Flash is an open format (only Adobe’s Flash Player – or ‘plugin’ – remains closed), many tools can output an FLV or F4V formatted video file. The output options depend on what tool is used to publish the video, but Adobe’s Media Encoder itself offers these options:
  • FLV format: On2 VP6 video, MP3 audio
  • (Sorenson’s Spark codec was also an option with earlier versions of Media Encoder)
  • F4V format: H.264 video, AAC audio
  • MP4 format: H.264, AAC audio
  • 3GP format: H.264, AAC audio
There are several options for the video output (i.e. blur, resizing, bit rate). Generally, sticking with whatever the Media Encoder defaults to may be best…though do consider whether you need the extra file size a stereo project will add. You can knock a decent number of bytes off a video by converting stereo audio to mono, and perhaps by knocking down the bit rate a bit.

Do note that the F4V container requires Flash Player 9 (v9.0.115.0), whereas FLV support goes back to Flash Player 7. And you really do want to use Adobe’s media encoder if you plan on delivering your video via a streaming server (i.e. Flash Media Server) as such streaming requires accurate and complete metadata along with the video, something third-party tools may not fully support.

Flash video (FLV/F4V) offers other advantages as well with the ability to protect it with rights-management keys if delivered via a streaming server, the ability to set custom cue points, expanded metadata and file stream support, and even audio book options. Flash is not alone in those features, of course, but is a nice compilation of such possibilities. Learn more about FLV and F4V formats...

For the customer we had the discussion with, we recommended the final video be provided in two formats:
  1. Final edited output as an h.264 MP4 video. This is the control, with which we can do further editing and recompression if needed.
  2. Web-ready output as an FLV video at a preset dimension.
The FLV footage we can plug into the SCORM-compliant presentation that is otherwise prepared. If, on review, the customer wants a different size, or additional edits, etc. then we can go back to the MP4 footage, edit, and republish as needed. While the FLV footage will require the Flash Player to be installed on the end-user’s computer, with a 98% (or higher) penetration rate, we have yet to find that to be a problem.

We’d love to hear about your experiences! Do you agree with this approach? Do you have an alternate approach for your eLearning video?

-Posted by: Erik L.

Tuesday, February 1, 2011

LMS API methods and mobile

Between developing custom content for folks who already have an LMS, and discussions with a few prospective customers, it’s come to our attention that not just a couple other LMS products make use of ActiveX controls or Java applets to facilitate the SCORM API.

When developing Inquisiq, we considered the various options and settled on what seems to be the most common approach – simple javascript. There was some concern that decision could possibly conflict with some 508/Accessibility requirements, but that issue hasn’t been apparent in the several years in which Inquisiq has been on the market.

There are advantages and disadvantages to the other methods; ActiveX can be tightly controlled but requires a Windows PC, Java is cross-platform but requires the JRE to be present (and is often a bit more demanding on the client computer).

Our Inquisiq LMS is pure ASP, .NET, and javascript. The only aspect of our LMS requiring a plugin is the 'Certificates' feature which uses Flash (which has a 98% penetration rate, so we figure that fairly innocuous).

We are in the process of testing our LMS on mobile devices and, so far, it works pretty well. There are some tweaks and adjustments to make, and there’s still a lot of movement in the mobile devices sector, so there’s still time before we officially push Inquisiq as ‘mobile compatible’, but it’s pretty close – already tested and running well in IE, Firefox, Safari, and Opera.

Have you had a chance to try Inquisiq on a mobile device? We’d love to hear about your experiences and suggestions!

-Posted by: Erik L.