...
It has been ensured that the automatic switch to the new transcode system is seamless in all applications and integrations developed by Digizuite. However, the new transcode system has a few caveats to be aware of for anyone that uses the Digizuite API or SDK:
Handling of unavailable renditions.
Search2.
New thumbnail formats.
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
...
Search2
...
New thumbnail formats.
weren’t ready for download. However, with the new transcode system, asset streamer URLs are returned for renditions that can be generated.
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 <api-url>/DigizuiteCore/LegacyService/api/assets/search, <api-url>/DigizuiteCore/LegacyService/api/assets/<asset-id>, and <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 allows the tables media_transcode_proxy_destination and media_transcode_proxy to be referenced in both input and output, providing access to information about transcodes/renditions. Information about renditions generated with the new transcode system can not be accessed through these tables. If one of these tables is used in a search, it is recommended to start using the API or the SDK to retrieve information about transcodes instead. This can be done using the endpoint <api-url>/DigizuiteCore/LegacyService/api/assets/search or IAssetSearchService in the SDK.
...
A key difference between the old transcode system and the new transcode system is that renditions can now be generated on-demand. In particular, this means that
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.
...