Here we go again. A discussion around rich media and what it means for the EMC Documentum platform. “Poor” media such as PDF and Office-documents have their natural place and support in the Documentum platform. However, I realize that one of the arguments that I often use to describe the differences between Documentum and other ECM-platforms is the breadth of file formats it supports. Especially compared to Sharepoint which due to its close ties to MS Office is mainly focused on these file formats and everything else is second class citizen.
The question is to what degree my claims are accurate in practice. Is Documentum the platform that handles “all” types of content or is that just something that is true on paper. Let´s examine what rich media support really is and what it could be.
First of all, I’d like to break it down into components like this:
- Core architecture support for file extensions, large file sizes (over the magic 2 GB limit) and some streaming architecture.
- Metadata support and extraction functionality for image and video/audio file formats (i.e. EXIF)
- Transformation/rendition capabilities for image and video/audio file formats.
- User interface that supports image, video and audio content (viewer, storyboards, thumbnails, gallery views and metadata).
- Tools to organize image/video/audio content in albums, tags, geolocation, event detection based on dates (basically iPhoto on the server in a web browser)
- Tools to annotate and provide additional context around image/video/audio content.
- Analytics that can extract information from the actual content (face detection/recognititon, speech-to-text, voice recognition, pattern matching etc)
- Modification tools that lets you perform basic editing of image/video/audio content (rotate, split/merge clips etc)
The obvious question here is where you draw the line between features supported by your ECM-platform in the browser and what you expect people to do in Adobe Photoshop, Final Cut Pro X and Adobe Audition? The reason to put it on the ECM Web client is to leverage the computing power in the server, reduce need for desktop installs and possibly make it easier to perform basic rich media operations without having to learn Photoshop for instance.
Currently some of this is supported in the old DAM application but it is slow and looks old today. Media Workspace actually provide quite decent functionality along this front but is basically killed off due to the demise of Flash. Media Workspace has great support for nr 4 in my list and some organization feature from nr 5 through the support for collections. EXIF metadata is extracted and viewable in the Media Workspace client as well as some video metadata.
The new clients are not there yet though. The inline viewer for xCP does not support video at this time but support images. The new HTML5 viewer will only support PDF initially it seems. D2 has the possibility to support the Brava viewer which supports viewing videos in MP4, MOV and FLV formats. There is some video annotation support which allows you to annotate a specific frame in the video which is stored back as a dm_note object.
So there is some and I repeat some rich media support in there but it is spotty and not a coordinated approach on the client side. This does no reflect the situation server side though where there are quite capable modules available in the underlying platform. That is especially true for the Audio/video transformation services which is currently based on a broadcast-level tool called Telestream Flipfactory which really can do everything you need to do on audio and video. From Documentum D7 AVTS is instead based on FFMPEG and MTS is based on ImageMagick. However, that is capable of – few of those features are actually exposed or configured. Basically customers of AVTS are sitting on an unpolished diamond, possibly without knowing it. To me it is now a mismatch between what the platform can offer and what user’s are able to do when it comes to rich media.
What about the use case then, is there a business requirement for this? To start with the internet giants Facebook, Flickr, Youtube and Instagram has showed us how easy you can do rich media content management. User’s have adopted it and they have learned how to do it. However, traditionally rich media in the ECM or Digital Asset Management space has been focused on “creative content creation” which means graphical artists, fotographers and their needs. Often in an ad agency context where it has been about creative content workflows that need to be managed and in the end billed properly. The Disney use case here at Momentum 13 is a good example. An application that supports their business-to-business operation of selling and licensing creative content to companies. Fairly advanced use cases in general.
But what about the more casual or “light” DAM which Facebook image management represent. Isn’t there a a use case for that? There must be organisations that need to organize rich media that is created internally. I can think of real estate agents, insurance companies, car dealers just to name a few. In the military we are handing out digital cameras left and right and there is a big need to be able to make something useful of this in the long run.
Isn’t there a market opportunity for EMC here to provide DAM light on a true (already rich media-enabled) ECM platform to allow customers to manage rich media in line with everything else instead of buying a siloed product for just photo management?