Cleaning up behind Adobe Edge Preview

Over at Labs.Adobe.com there's a new release of Adobe Edge (Preview 5). For those who want to try it out, but have already used Adobe Edge Preview 4 (or prior) we want to share some important news:

It's not enough just to drag the Edge folder to your recycle bin and empty the trash!

Ok, why not? Turns out that elements of Edge (no pun, for those who have used this JavaScript-based HTML5 interactivity tool) remain on your computer in various places.

Consider this typical request for help from one of the Adobe forums (based on the error message "A conflicting or prerelease version of Adobe Edge Preview exists on this computer. The conflicting version must be removed before installing from the current media"):

I removed Edge Preview n by trashing and emptying the trash, not by the uninstall. That message persists. I can find nothing in the Libraries (I’m running OSX Lion on my iMac) either under Application Support or Preferences that is leaving a trail that would show the installer that Edge 3 still exists on the computer. How can I solve this problem and install [the next preview version of] Edge? 

Anyone who has faced this problem has seen this error screen:

The answer to the vexing problem (not necessarily solved by reading the above error screen)comes in the form of an older, smaller application (around since the beginning of the Adobe Creative Suite 5 - CS5 - days): the CS Installer Cleaner Tool more formally known as the Adobe Creative Suite Cleaner Tool.

Launching the cleaner tool presents the user with a few options:

In this case, the user had vestiges of Adobe Edge Preview 1 still on the machine, so the cleanup tool worked by selecting "Adobe Edge Preview 1" and clicking on "cleanup" to eliminate those pesky Preview 1 elements.

One piece of confusing information: upon choosing Cleanup, the software prompts you to try an uninstall first. It's sort of overkill, as you wouldn't be using the cleaner tool if dragging the folder to the recycle bin and emptying the trash had worked in the first place, but feel free to click "Try Uninstall" before clicking the "Cleanup" button.

Once the Cleaner Tool works its magic, the machine will install the next version of Adobe Edge Preview n with no problems and you're underway. A few quick pointers about Adobe Edge Preview 5 can be found in an article we wrote for StreamingMedia.com (direct link to article here).

DASH it all?

MPEG-DASH has been ratified by 24 national bodies, a topic covered in a recent StreamingMedia.com article and also at StreamingLearningCenter.com (run by Jan Ozer).

Now that we, as an industry, have reached a tentative agreement on how to handle adaptive streaming over HTTP through consistent parsing of manifest files (MPD or Media Presentation Description in MPEG DASH parlance) there's another question remaining: what's next?

The next two steps, as noted in both the Streaming Media article and our own white paper, is the acceptance of a common file format and a common encryption scheme (CENC).

Following ratification of CENC and adoption of the common file format, there's a huge need to deal with interoperable, DASH-compliant players. In fact, this element may be the biggest challenge of all—getting encoded content to consistently play back on every device or platform.

It's the same issue we faced during the two reports (1, 2) on Android handset and tablet video playback, where core services of Android didn't necessarily translate into consistent playback of RTSP or even YouTube videos on a variety of playback devices from the same handset manufacturer.

So Transitions is issuing a challenge, as part of our 2012 Q1 Best Workflows testing: bring us your DASH-compliant player, whether it's in beta or gold master, and we'll put it through its paces against other DASH-compliant players, using consistent fMP4 and M2TS content. Here's looking at you, Qualcomm, Ericsson and even Microsoft and Adobe...

Why are fMP4 and MPEG-DASH so important?

Quote from a white paper Transitions just completed on fragmented MP4 (fMP4) and MPEG-DASH:

Proponents say that the Common File Format (CFF) and Common Encryption (CENC) scheme will represent two important steps toward large-scale online video distribution via adaptive delivery of fragmented elementary streams.


Since CFF can also be used outside of the bounds of UltraViolet, significant interoperability may also exist between UltraViolet disc-based playback and online video platforms, in much the same way that the DVD Forum’s published specifications for DVD playback guaranteed interoperability between DVD players. It’s not out of bounds to think of CFF as the DVD standard for the web.


To get a better understanding of the power of fragmented MP4, first look at the sidebar in the white paper on "combinatorial complexity" for which Netflix contributed a real-world example. Even without CFF and CENC, Netflix is proving the case that fMP4 scales much better than the HLS approach (with a far lower asset management impact).

The white paper has been several months in the making, starting first as separate concepts by two key companies in the streaming space: Adobe Systems and Microsoft Corporation. Each has their proprietary solutions, but both are committed to seeing fragmented MP4 (fMP4) offer a potentially viable alternative to legacy streaming solutions.

After several meetings, both companies chose to jointly work with Transitions to create a white paper noting the benefits of fMP4 and, to a slightly lesser extent, the potential benefits of MPEG-DASH (a proposed standardization of dynamic streaming over HTTP that I mentioned in a prior blog post).

Special thanks to Microsoft and Adobe for providing financial resources and access to subject-matter experts, who spent time expanding on key concepts and the ever-changing nature of fragmented MP4 and the MPEG-DASH ratification process.

The full white paper can be found here.

[Addition: Adobe and Microsoft have both published blog posts, outlining their support for fMP4 and mentioning reasons for working together: Adobe's Kevin Towes blog post  Microsoft's Chris Knowlton blog post]

Flashless for Mobile? Not Exactly

There's quite a bit of confusion about the impact of Adobe's decision (or what exactly the decision was) in regards to Flash Player of Mobile. Rightfully so, as the company didn't spell out its intent to its users at the same time it pushed out news to analysts during the 9 November analyst day briefing.

Besides the StreamingMedia.com article titled "Into (not so) thin AIR" (self-plug) there are two Adobe blog posts that may help explain where the company is going...or at least what it plans to still support:

Pritham Shetty's "Adobe Flash for Premium Video" blog post spells out what's in and what's out.

Mike Chambers's blog post, "Clarifications on Flash Player for Mobile Browsers, the Flash Platform and the Future of Flash" does a good job explaining the "why" of unsustainable growth in complexity Adobe faced in the wild-west atmosphere surrounding Android forking.

We conjectured, in the "thin AIR" article posted on StreamingMedia.com, that Android forking complexities could cause Adobe's costs to run rampant. It was helpful to get confirmation a few hours later, when Mike posted his Clarifications blog post, that Adobe had indeed seen this Great Wall of Android that it had to scale, and chosen a wiser path.

DASH of this, DASH of that...

It's apparent that MPEG-DASH is getting traction—or at least attention—if attendance at the 2011 StreamingMedia West show's panel on MPEG-DASH is any indicator.

It wasn't just standing-room, as alluded to in the StreamingMedia.com article, but was sitting-room only. It's been quite some time since I've seen this level of interest in a topic.

A few notes that didn't make it into the article:


MPEG-DASH will never define a codec, but with DASH-264 there's a move to use an H.264 codec in an MP4 container with a common file format (CFF) and common encryption (CENC).... There's also a possibility of adding DASH-264 into the HTML5 standard, since W3C requires a codec to be considered in HTML5 but MPEG-DASH itself is codec agnostic.


Interesting note about who has been participating and who has not:


Apple has been participating in MPEG-DASH from the beginning; they have contributed actively. We've not seen Google participating in DASH, but our codec agnostic approach means that WebM could be used within DASH (we can already do with profiles around M2TS).


What about royalties? An audience member's question got this reply:

From a licensing standpoint, there is a requirement to notify ISO of their intent to license; Qualcomm and Cisco have announced they'll offer royalty-free since HTTP adaptive streaming has been done for a number of years but to get to a standard we need to see a path forward to royalty-free licensing.

2011 Streaming Media Europe: Challenges for Android Video Delivery

In between trips to Nigeria and Ghana (for pro-bono work) I was able to speak at today's Streaming Media Europe 2011 conference, on the topic of Android video delivery.

The session presentation is available for download and StreamingMedia.com may eventually post the session video.

The presentation was a walk through the findings we reported in two white papers on the battery impact and performance impact of Flash Player for Mobile 10.1 (first report) and Flash Player for Mobile 10.2 / 10.3 (second report).

The findings, however, were the same for both tests: the native applications don't work nearly as consistently for video playback, and the impact of Flash Player for Mobile on battery life is a small price to pay for consistency in delivery (as in the actual ability to use hardware acceleration to play back full-screen, full-motion video).

PDF viewing in Apple's Preview looking fuzzy? Welcome to Acrobat X on Snow Leopard

I'm working through a few workflow scenarios with Acrobat X's scanning and optical character recognition (OCR) for an upcoming comparison study. Along the way, though, I have two quick insights in to Acrobat X.

First, it does a great job of shrinking the file size automatically after the text recognition is run. In many cases, I don't even have to run the "reduce file size" feature to bring multi-page documents to a manageable file size.

Second, the issue that cropped up under Apple's Preview in Acrobat 9, after I'd applied the "reduced file size" to shrink the file size, remains. The image will look blocky and jagged, as if a great bit of information has been abandoned.

I initially chalked the issue up to an error in the file reduction algorithms, but the advent of Acrobat X—with its better-than-average standard compression—brings the issue back to the forefront. Even without running the "reduce file size" feature in Acrobat X, any file that's been OCRed will appear jagged and blocky within Apple's Preview application.

Researching the topic online didn't turn up any clues, probably because Acrobat X is so new; since I couldn't ignore this issue, as it affects all the scans I was applying OCR to, I turned to my contact at Adobe's PR agency to get insight in to the issue.

It turns out that Adobe X's new rendering engine may steal a few pages from Acrobat 9's file size reduction score. In doing so, this presents a potential rendering issue in Apple's Preview.  According to my contact:

Acrobat X's new scan compression technology divides the image into 3 layers - Background (BG), Foreground (FG) & Mask. BG, FG images are highly down sampled while mask is kept at a higher resolution (to maintain text readability). 


The layering makes sense, as Adobe has always had the ability to choose Image-Text (where the image overlays the underlying OCR text) or Text-Image (where the text attempts to lay out in a patter closely resembling the image, but the text is the top layer).

I've always opted for Image-Text, as it allows the human looking at the document to read what's actually on the page, should he or she find the OCR text they copied from the PDF a bit, well, lacking.

My contact went on to provide some reasoning behind the miss-match of Preview and Acrobat Reader X, the latter of which seems to display the images in a much higher quality output:

Here is our hypothesis on the reason of low quality rendering by Preview. In order to render a page, it down samples mask to the resolution of FG (or maybe BG), so it loses on text crispness or quality that a high resolution mask provides. Adobe Reader/Acrobat, on the other hand, up samples images to the highest of the resolution of BG, FG and mask to get the rendered bitmap.


Is this the reality? I guess we'll have to see whether Apple issues an update to Preview in the near term. If not, I'm stuck either suggesting that every client upgrade to Acrobat Reader X, or choosing to completely forego the workflow of using QuickLook to view text-heavy OCRed documents.