Last present for 2013 - Magnolia DAM video and pdf preview

Lets start with a small quiz: Can you find 3 differences in the pictures below?

Yeah, you got it. That was an easy one. :)

Surprisingly, implementing preview for extra asset types has been relatively simple as well. When coming up with the architecture of DAM, the Magnolia team chose to not generate previews and thumbnails of assets directly in the module, but rather delegate this functionality to the imaging module. And in typical Magnolia fashion, the part of the DAM responsible for linking the DAM with imaging is encapsulated in a configurable image provider.

To implement this module, all I had to do was create a custom image provider for the DAM and configure extra thumbnail and portrait image generators in the imaging module. Ideally I would have only changed the existing image decoder or the image operation chain and not done anything with the image provider of the DAM, but unfortunately I discovered that the ImageDecoder interface of the imaging module has a little bit of a rigid API and provides its read() method only with InputStream without further info. This works fine for various types of images where all the DefaultImageIOImageDecoder does is delegating to ImageIO, but it's not enough when working with other media types such as video or pdf. Yes, an alternative implementation could examine the binary data in the stream to read the header and find out if this is an image or a video or a pdf, but what we can't read from the input stream is info that would typically come from the user, such as which page of a pdf or which frame/second of a video to use for a generated thumbnail.

Having discovered this limitation, the choice I made for implementation was using an alternative DAM image provider that still has enough info - at least about the type of media, and using separate image operation chains, overloading the load operation in each of them with the implementation of the load specific for a given media.

The limitation of this approach is that load ops are specific to the way how the DAM stores binaries and can't be reused for other scenarios, but perhaps the imaging module will give more power to the decoder in a future release, and the above described limitation will be void.

The version of the preview module linked below provides a thumbnail and portrait view for pdfs, using swinglabs pdf-renderer. For video (mp4, m4v), it uses JCodec and for other video types (mov, avi) Xuggle.

Let's have a closer look at the configuration in case you want to try support for other video types:

As you can see, each media type is associated with the appropriate [thumbnail|portrait]-xxx image operation chain to give you the freedom to swap between jcodec and xuggle or to add more types associated with each. The key is the part of the mime type for a given media that is after the slash (application/pdf, video/quicktime, …).

A couple extra words on the implementation details:
- while the implementation of load operations has been pretty straightforward with chosen architecture, you should be aware of the fact that for generating frames from video files, each of the codecs uses 512K of memory buffer per video and Xuggle uses a temp file on top of that.
- this first implementation will always use the first page of pig and the first frame/second of the video for the thumbnail.
- JCodec works perfectly for pretty much anything that is using H264 encoding, but I've found it's not really able to work well with quicktime (hence the use of Xuggle for that).
- Xuggle jar is bit bigger (about 66MB) and makes about 99% of the size of the resulting bundle.

While this is a separate module and on forge for now, I expect that this functionality gets integrated in the Magnolia bundle soon, one way or another. You should be save to use this module in your system already, although as I mentioned above due to possible future changes in the imaging module, the implementation details of preview might change as well.

While you choose to experiment with the module, it would be very useful if you can report back types or samples of media that module can't handle so it can be improved further.