...

Handling of unavailable renditions

A main difference between the old transcode system and the new transcode system is that renditions might not be immediately ready when they are requested.

Previously, asset streamer URLs would never be returned for renditions that weren’t ready for downloadgenerated yet. However, with the new transcode system, asset streamer URLs are returned for renditions that can be generated but are not necessarily ready.

For users of the SDK, this is relevant for all URLs that are returned in the AssetResponse class from the services IAssetSearchService and IAssetService.

For users of the API, this is relevant for the URLs that are returned in responses from the endpoints prefixed with <api-url>/DigizuiteCore/LegacyService/api/assets/search, . Furthermore, it is relevant for URLs returned from Search2 searches at <api-url>/DigizuiteCore/LegacyService/api/assets/<asset-id>, and dmm3bwsv3/SearchService.js.

By default, when requesting a rendition of an asset with the asset streamer (prefixed with <api-url>/DigizuiteCore/LegacyService/api/assets.

Previously, no asset streamer URLs would be returned for renditions before they were ready.

Search2

New thumbnail formats

With the 5.10 release, the thumbnail and preview formats that are defined out of the box have been reworked. By default, this is handled automatically and no manual actions should be required.

The main difference between the old and the new thumbnail formats is that they are now webp files with transparency. The old thumbnails were jpeg files without transparency.

As described above, the thumbnails for existing assets are not automatically re-generated. If the existing thumbnails should be re-generated, this can be done by setting up an automation that uses the “Generate asset renditions” step with the “Force generate” flag enabled.

Since the file type of the thumbnails has been changed, the asset streamer returns the response header Content-Type: image/webp instead of the correct response header Content-Type: image/jpeg for existing thumbnails. Most browsers should be able to display the thumbnails despite of this. If it becomes an issue, the existing thumbnails can either be re-generated as described above, or the thumbnail formats can be modified to be of the type jpeg.

Search2

Search2 assetstream), the request will not terminate before the rendition is available. This process can take a while. If you do not want to wait for renditions to become available, the query parameter mode=getFallbackImageIfUnavailable can be added to the request when using the API. With this query parameter set, a fallback image will be returned with the HTTP status code 202 if the requested rendition is not immediately available.

Note that most modern browsers limit the maximum number of simultaneous HTTP connections. Thus, if you show a lot of images simultaneously (e.g. thumbnails in an asset list), strongly consider adding the mode=getFallbackImageIfUnavailable query parameter to your requests to limit the number of simultaneous HTTP connections. Please be careful that you do not cache the fallback image as the requested image.

If you are using the INewAssetStreamerService.GetAssetDownloadStream method in the SDK, note that the mode discussed above can now also be set. Furthermore, be aware that the default HTTP client used by the SDK has a timeout of 100 seconds. Thus, if you request a rendition that takes more than 100 seconds to become available, your request will time out before the rendition is returned. To disable this timeout, use the following setup in your application startup logic:

services.AddHttpClient(DigizuiteApiConstants.HttpClientName)
    .ConfigureHttpClient(c => c.Timeout = Timeout.InfiniteTimeSpan);

Note that this removes the default timeout of 100 seconds from ALL HTTP request performed with the SDK. However, it is still possible to control the timeout per-request by passing a cancellation token to the used SDK method. The effective timeout is always the smallest of the passed cancellation token and the timeout configured for the HTTP client used by the SDK.

Search2

Search2 is being deprecated, and it is highly advised to start using the new API or the SDK.

If you are still using Search2, please be aware of the following:

• Search2 allows the tables media_transcode_proxy_destination and media_transcode_proxy to be referenced in both input and output, providing access to information about

...

• renditions. Information about renditions generated with the new transcode system can not be accessed through

...

• these tables

...

• .

• Search2 allows URLs for renditions of old media formats to be retrieved with the functions urlAbsolut, urlRelative, downloadUrlAbsolut, and downloadUrlRelative. It has been ensured that this still works, even if the targeted old media format has been mapped to a new format. If an old media format has not been mapped to a new format, these functions work in exactly the same way as previously.

...

• However, a few caveats should be mentioned in the case where an old media format is mapped to a new format:

  • A URL is always returned, even though a rendition of the asset in the old media format can not be generated. As an example, this means that a thumb URL is included for an asset in the default GetAssets search, even if it can not be generated. Previously, the thumb URL would be null in this case. Thus, it must be ensured that clients do no rely on the URL in a search to be null when it

...

• • can't be generated.

  • If the urlRelative or downloadUrlRelative function is used, the returned relative URL will be relative to <api-url> instead of <api-url>/dmm3bwsv3 as it was before.

If the caveats above are addressed, Search2 can still be used to retrieve valid URLs for old media formats that have been mapped to new formats, ensuring that the new transcode system is used. However, it is generally recommended to start rewriting applications that use Search2 to use the new API or SDK instead. If this is not possible, it is still possible to opt-out of using the new transcode system by ensuring that no old media formats are mapped to new formats.

On-demand transcoding

A key . However, be aware that this will not be supported in future releases.

New thumbnail formats

With the 5.10 release, the thumbnail and preview formats that are defined out of the box have been reworked. By default, this is handled automatically and no manual actions should be required.

The main difference between the old transcode system and the new transcode system thumbnail formats is that renditions can now be generated on-demand. In particular, this means that

New thumbnail formats

...

they are now webp files with transparency. The old thumbnails were jpeg files without transparency.

Note that the thumbnails for existing assets are not automatically re-generated. If the existing thumbnails should be re-generated, this can be done by setting up an automation that uses the “Generate asset renditions” step with the “Force generate” flag enabled.

Since the file type of the thumbnails has been changed, the asset streamer returns the response header Content-Type: image/webp instead of the correct response header Content-Type: image/jpeg for existing thumbnails. Most browsers should be able to display the thumbnails despite of this. If it becomes an issue, the existing thumbnails can either be re-generated as described above, or the thumbnail formats can be modified to be of the type jpeg.