...
When upgrading existing environments to 5.10, the new old transcode system is automatically still used as much as possible. The old transcode system can still be used in . However, it is highly advised to migrate to the new transcode system while being on 5.10, but it since the old transcode system is deprecated and can not be used in future versions. Thus, it is highly advised to fully use the new transcode system instead of the old transcode system as soon as possible.
This page describes the main things to be aware of in relation to the migration to the new transcode system.
Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Automatic migration
...
Migration
In 5.10.0-5.10.7, the old transcode system was automatically migrated to the new transcode system when upgrading. This resulted in the same changes as the changes obtained by following the manual migration process.
From 5.10.8, the migration from the old transcode system to the new transcode system must be performed manually.
Migration script
To manually migrate from the old transcode system to the new transcode system, the following SQL script can be used: https://github.com/Digizuite/scripts/blob/main/transcode_system_migration.sql.
The script migrates as many old media formats as possible are automatically migrated to new formats. In particular, a new format with the same name as the old format is created, and then the old format is mapped to the new format. This is only done for old media formats that can be mapped to a supported format type in the new transcode system. Please contact R&D if you have a use case for a format type that is not supported in the new transcode system.
...
All changes to the old media format are ignored.
Renditions are no longer generated based on profiles. Thus, if renditions of the old media format were previously being generated when an asset was published to a specific channel folder, this is no longer the case. Pre-generation can be set up for the new format. However, please carefully consider if this is necessary now that the transcode system supports on-demand transcoding.
Existing renditions are not re-generated. Thus, the existing renditions will be used when requesting renditions of existing assets in the new format. This is also the case if generating the rendition with the new format definition would lead to a different rendition than the existing rendition. As described in https://digizuite.atlassian.net/wiki/spaces/DD/pages/3708157997/DC+5.10+Breaking+changes+-+Transcode+system#New-thumbnail-formats, it is possible to use the “Generate asset renditions” automation step to force existing renditions to be re-generated.
For new assets, the new transcode system and the new format are used to generate renditions. This is also the case if a rendition of the old media format is requested.
Renditions of the format can still be requested with the ID of the old media format. This is mainly relevant for backward compatibility reasons.
...
Things to be aware of
Although as many old media formats as possible are migrated to new formats with the SQL migration script, there are a few cases that can require manual actions:
Unsupported media format type: The new transcode system supports a limited set of format types. All old media formats that do not have a corresponding format type in the new transcode system can not be automatically migrated to a new format. If a media format is used and has not been migrated, consider if one of the supported format types in the new transcode system can be used instead. Otherwise, reach out to R&D to share your use case.
All non-migrated media formats can be identified by running the following SQL query against the database after upgrading:
.View file name identify_non_migrated_formats.sql
Special ImageMagick commands: If an old media format is defined with an ImageMagick command that refers to a local file on the server, renditions of the corresponding migrated format can not be generated with the new transcode system. This can e.g. be the case if a custom profile or a special watermark is used. An example of such an ImageMagick command is:
%infile%[0] -profile "D:\my\local\file\path\custom_profile.icc" %outfile%
. If a local file is referenced, the corresponding migrated format must be edited manually.The media formats for which this potentially is an issue can be identified by running the following SQL query against the database after upgrading:
.View file name identify_problematic_conversion_commands.sql
Configuration Management
When diffing in configuration management, please be aware of the following:
All new formats that have been created as part of the automatic format migration, as described above, will appear as delete actions when diffing in configuration management.
All member groups that had one of these old formats configured as a download quality will have an update action, updating the download qualities to the corresponding new formats.
The
Original
format might have an update in thedownload_replace_mask
field if the customer has a different download replace mask than[%AssetId%]
configured.
...
Manual migration guide
A customer can be migrated from the old transcode system to the new transcode system by following these steps:
Ensure that there are no diffs in Configuration Management.
On a 5.10 environment, run the migration script https://github.com/Digizuite/scripts/blob/main/transcode_system_migration.sql.
Clear the LegacyService cache.
Calculate a diff in Configuration Management and export the following actions:
Update column:
All
format
actions.All
member_group
actions.
Delete column:
All
format
actions.
If the OOBE configuration layer is not used, please be aware that selecting a custom video thumbnail in MM will not work without setting up an automation that force generates thumbnails when the FrameAccurateThumbnail
metafield changes. An example of an automation that does this can be found here: https://github.com/Digizuite/configurations/blob/master/OOBE/5.10.0/automations/oobe_republish_on_frameaccurate_thumbnail_changed.dcl.
...
Although not strictly necessary, the introduction of the new transcode system provides a good basis for revisiting the formats that are defined for existing customers. Maybe some of the old media formats are no longer needed. Maybe some of the automatically mapped formats can be mapped better manually, for instance, utilizing the support for webp
and transparency.
Re-run automatic migration
As mentioned in https://digizuite.atlassian.net/wiki/spaces/DD/pages/3710091372/DC+5.10+Formats+-+Migration#Automatic-migration, as many existing media formats as possible are automatically migrated when updating to 5.10. However, the automatic migration can always be re-run by running the following script against the database:
View file | ||
---|---|---|
|
This is, e.g., relevant if the automatically migrated formats were accidentally deleted with Configuration Management.