We're updating the issue view to help you get more done. 

Document, fix and improve thumbnail support

Description

This task is about addressing a number of related issues considering Opencast 6.x new thumbnail feature:

Archive tag for the uploaded thumbnail (bugfix)
When a user uploads a thumbnail image, it needs to be made persistent. The current implementation missed to add the tag 'archive' to the attachment added to the media package. Without that tag, the Opencast default workflows will not include the uploaded thumbnail in snapshots they create.
As it would be somewhat nasty to hard-code this, I've added the configuration property thumbnail.uploaded.tags.

Untangle the flavor of the source track from the flavor of the uploaded thumbnail (enhancement)
The flavor of the attachment created for the uploaded thumbnail was determine by thumbnail.source.flavor.type and thumbnail.source.flavor.subtype. This mixes up the identification of the source track with the flavor of the uploaded thumbnail which is confusing and limiting.
I've introduced thumbnail.uploaded.flavor to make break up the undesirable entanglement. The configuration property thumbnail.source.flavor.type could then be removed as not used otherwise.

Document the thumbnail configuration (documentation)
As there are quite a number of configuration properties related to configure the thumbnail feature, I've felt like there should be some documentation about this.
I've refactored the existing documentation related to the Admin UI in the Admin Guide and added a page describing how the configuration properties for the thumbnail feature work.

Don't hard-code encoding profiles (enhancement)
During all the work, I've found that the encoding profile used to downscale the thumbnail preview image is hardcoded which is undesirable and weird to document. I therefore introduce the new configuration property thumbnail.preview.profile.downscale.

Renamed some configuration properties (maintenance)
I've renamed thumbnail.default.track.primary and thumbnail.default.track.secondary to thumbnail.source.flavor.type.primary and thumbnail.source.flavor.type.secondary for two reasons: Those configuration keys are used together with thumbnail.source.flavor.subtype to create the source flavors. Also, those configuration properties are currently not only used for the default thumbnail (even though this is not necessarily a great things...).

Steps to reproduce

None

Status

Assignee

Sven Stauber

Reporter

Sven Stauber

Criticality

None

Tags (folksonomy)

None

Components

Fix versions

Affects versions

6.0

Priority

Minor