Skip to main content

Last present for 2013 - Magnolia DAM video and pdf preview

Posted by rah003 on December 31, 2013 at 7:25 AM PST

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,

screenshot-2.png359.04 KB
screenshot-1.png307.21 KB
screenshot-3.png70.04 KB
screenshot-4.png48.96 KB