When upgrading to 5.10, the new and improved transcode system is automatically used. The old transcode system can still be used in 5.10, but it is considered deprecated and will not be available in future releases.
If you are a consultant, please see DC 5.10 Formats - Migration for more information on how the migration to the new transcode system is handled and things to be aware of in relation to this migration.
This page describes the most important breaking changes related to the new transcode system.
EXIF
In the previous version of the old transcode system, it was possible to embed EXIF metadata in the generated qualities/transcodes. This is not supported in the new transcode system.
Note that EXIF data can still be extracted from physical files. See DC 5.10 Configuration of upload metadata tags for more information on this.
Old media formats
After updating to 5.10, at most 200 additional media formats in the old transcode system can be created. If a format in the new transcode can not be used to cover your use case and you need to create an old media format after upgrading to 5.10, please reach out to R&D to share your use case. Ideally, the new transcode system should be able to accommodate your use case.
API and SDK users
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 who uses the Digizuite API or SDK.
Handling of unavailable qualities.
Search2.
New thumbnail formats.
Source formats.
Handling of unavailable qualities
Previously, asset streamer URLs would never be returned for qualities that hadn’t been generated yet. However, with the new transcode system, asset streamer URLs are returned for qualities that can be generated but are not necessarily ready yet.
This is relevant for the URLs returned in the following cases:
SDK: All URLs in the
AssetResponse
class returned from the servicesIAssetSearchService
andIAssetService
.API: All URLs returned in responses from the endpoints prefixed with
<api-url>/DigizuiteCore/LegacyService/api/assets
. Additionally, it is relevant for URLs returned from Search2 searches at<api-url>/dmm3bwsv3/SearchService.js
.
By default, when requesting a quality of an asset with the asset streamer, the request will not terminate before the quality is available. This process can take a while. If you do not want to wait for qualities to become available, it is possible to get a fallback image returned with the HTTP status code 202 if the requested quality is not immediately available. This can be done in the following way:
SDK: Set the
mode
argument toGetRenditionBehavior.GetFallbackImageIfUnavailable
in theINewAssetStreamerService.GetAssetDownloadStream
method.API: Add the query parameter
mode=getFallbackImageIfUnavailable
to asset streamer requests prefixed with<api-url>/DigizuiteCore/LegacyService/api/assetstream
.
Note that most modern browsers limit the maximum number of simultaneous HTTP connections. Thus, if you show a lot of qualities simultaneously (e.g., thumbnails in an asset list), strongly consider using the mode
argument 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 SDK, be aware that the default HTTP client used by the SDK has a timeout of 100 seconds. Thus, if you request a quality that takes more than 100 seconds to become available with the INewAssetStreamerService.GetAssetDownloadStream
method, your request will time out before the quality 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 requests performed with the SDK. However, it is still possible to control the timeout per-request by passing a cancellation token to the SDK method used. The effective timeout is always the smallest of the passed cancellation tokens 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
andmedia_transcode_proxy
to be referenced in both input and output, providing access to information about qualities. Information about qualities generated with the new transcode system can not be accessed through these tables.Search2 allows URLs for qualities of old media formats to be retrieved with the functions
urlAbsolut
,urlRelative
,downloadUrlAbsolut
, anddownloadUrlRelative
. 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 quality 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 defaultGetAssets
search, even if it can not be generated. Previously, thethumb
URL would benull
in this case. Thus, it must be ensured that clients do not rely on the URL in a search to benull
when it can't be generated.If the
urlRelative
ordownloadUrlRelative
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. 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 and the new thumbnail formats is that 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.
Source formats
The new transcode system now supports a special SourceFormat
that can be used to refer to and get the source files of assets. A special “Original” format of this type is now defined out-of-the-box. If you have previously hard-coded the “Original” format in a list of available download qualities, this can lead to two “Original” formats being shown. It should no longer be necessary to have any special-case handling for getting source formats.