On Publisher with DM Enabled, card renditions don't work for videos

[shsteimer]

Describe the bug First,

Environment

• AEM Version: 6.5.9
• Asset Share Commons Version: 2.0.6
• Author, Publish or both: Publisher

To Reproduce Steps to reproduce the behavior:

1. Set up an aem author and publisher with DM Enabled. deploy asset share commons and load some videos, and publish those videos.
2. when viewing on publisher, the card rendition shown on the search results screen doesn't render a proper thumbnail

With DM enabled, the 319x thumbnail rendition uses special handling to send that request to the DM preview server. Here is an example of that node structure

"cq5dam.thumbnail.319.319.png": {
        "jcr:primaryType": "sling:OrderedFolder",
        "jcr:createdBy": "workflow-process-service",
        "jcr:created": "Fri Sep 10 2021 09:34:14 GMT-0700",
        "sling:resourceType": "cq/dam/custom-rendition",
        "jcr:content": {
            "jcr:primaryType": "nt:unstructured",
            "jcr:mixinTypes": [
                "cq:ReplicationStatus"
            ],
            "cq:lastReplicationAction": "Activate",
            "cq:lastReplicatedBy": "admin",
            "jcr:lastModifiedBy": "workflow-process-service",
            "cq:lastReplicated": "Fri Sep 10 2021 09:48:00 GMT-0700",
            "rendition.handler.id": "dynamic.media.rendition.handler",
            "dam:query": "wid=319&hei=319&fmt=png&fit=constrain,true",
            "jcr:lastModified": "Fri Sep 10 2021 09:34:14 GMT-0700"
        }
    }

I changed it so the card rendition is handled bythe external redirect rendition dispatcher for and sends it to DM, and it works for videos and images, but starts failing for PDF documents (which DM doesn't handle rendering an image for) and for anything not published in DM (though that I think would be a reasonable constraint).

I think what I really want is a "smart" rendition dispatcher, which is type aware, using the external for videos, and the internal for all other file types, but it seems that the rendition dispatcher servlet is not asset type aware.

Before I go and write a custom dispatcher to handle cards, I figured I'd open a bug here and see if this is something that "should" be handled here?

Additional context I'm not sure if this is a product bug, an ASC bug, or something misconfigured on our publishers, but starting here :)

[davidjgonzalez]

This has been reported before - the problem is ASC just calls the OOTB asset thumbnail servlet to get thumbnails. DM Videos have a weird way of generating video thumbnails which isnt handled by the asset thumbnail servlet.

I think the cleanest way to get this at this time is to do what you propose.

[shsteimer]

@davidjgonzalez did you see the PR I submitted #661 While it isn't 100% of what I described in terms of a smart dispatcher, I think it creates a framework that can used to solve it in most cases, and also allows for other advanced rendition routing for thumbnails based on the asset type.

[davidjgonzalez]

I did!! I like it - the only thing i was thinking of (though dont see an obvious way right off the bat) is to be able to specify which computed property name should return the "type" (incase you want to customize it) -- but its in a POJO so not sure a clean way to inject a config without changing method signatures - which might be premature

[shsteimer]

I agree that it's a bit pre-mature, but if you want it, I don't think it would require changing signatures of existing methods, just adding new methods to interfaces...

I'm already adding AssetRenditionParameters::getAssetType instead of that I could add AssetRenditionParameters::getProperties then on AssetRenditionDispatcher and 2 methods and associated config values for property name and property values. All of the matching logic is currently in the servlet, so it could stay there.

But even typing that out it seems messy and keeping it just to types is simpler, since there already is an element of type matching in the AssetRenditionDispatcher, it's just only applied to the rendition selection in the authoring UI and not to the rendition servlet.

I guess with all that said, my preference is to keep it just to types for now, until there is a use case which requires more advanced property based selection.