Incorrect extension for transcoded AV

[donaldgray]

Engine contains a list of known "friendly" transcode names, e.g. audio-mp3-128 for 128k mp3 transcode. Note that the original concept for the friendly names was that they don't have any meaning, they could be "thebest" and would be mapped to a specific transcode policy. However, the implementation processes them in TimeBasedPolicy to extract the type, audio, and extension, mp3.

The extension parsed from the friendly name is used to generate the output location in S3, which is the end of the /iiif-av/ path for that resource. So in this case mp3 is used as the extension.

However, the ElasticTranscoder policy that this maps to, "System preset: Audio MP3 - 128k", is used to determine the extension, via the "Container" property, that CleanupHandler looks for when removing assets and also when generating AVTranscode metadata. In most examples, webm, mp4, mp3 etc, this is fine.

However, for ElasticTranscoder AAC policies, this is incorrect. The policy, e.g. audio-aac-128 maps to "System preset: Audio AAC - 128k". However, the "Container" for this is "mp4", meaning that:

• The extension used to save output is aac as it uses friendly name
• The cleanup handler would look for mp4 as it uses transcoder policy
• The assetApplicationMetadata would use mp4 as extension, which maps to video/mp4. This results in manifests rendering a "type": "Video" resource.

We need to figure a more reliable way of working out the extension for a transcode, and use this for all permutations. It may be that we need to map to a more expressive property than a simple string, which would allow us to remove any meaning from the keys, audio-aac-128 could be replaced by e.g.

"smalllossy": {
  "policy": "System preset: Audio AAC - 128k",
  "extension": "aac",
  "bitrate": 128,
  "type": "audio"
}

Given #925 and ElasticTranscoder imminent retirement, it may be worth revisiting this when replacing.