Thumbnails in backend#1708
Conversation
Currently when generating a thumbnail, we create it here in the frontend and then send it to the backend. With this patch, we instead send the timestamp it was generated from to the backend. The goal is to let the backend generate the actual thumbnail, instead of the frontend. This avoids quality issues when generating thumbnails from low resolution videos in the frontend. It also allows for respecting institituion specific thumbnail settings (e.g. encoding profiles). The downside is that this relies on workflow properties. As such, admins will have to adapt their workflows or thumbnail generation will be broken for them. This change should not impact the user experience of using the editor frontend.
|
This pull request is deployed at test.editor.opencast.org/1708/2026-06-03_15-05-20/ . |
snoesberger
left a comment
snoesberger
left a comment
There was a problem hiding this comment.
Thanks for your work! I tested the PR together with the corresponding backend PR opencast/opencast#7698 locally in different scenarios and found some issues:
- direct publish Presenter/Presentation/Dual stream events -> thumbnail resolution 1280 x 720 ✅
- Presenter video with Editor generated thumbnail -> thumbnail resolution 1280 x 720 ✅
- Presentation video with Editor generated thumbnail -> thumbnail resolution 1280 x 720 ✅
- Dual stream with Editor generated Presenter thumbnail -> thumbnail resolution 1280 x 720 ✅
- Dual stream with Editor generated Presentation thumbnail "use for all tracks" -> thumbnail resolution 640 x 360 ❌
- Changing the Presenter or Presentation video generated thumbnail for a published event afterwards with a newly generated thumbnail ✅
- Discard Presenter or Presentation video generated thumbnail for a published event afterwards -> nothing happens if I press the button "Discard" ❌
- Upload a new thumbnail image for a published Presenter, Presentation or Dual stream event which already has a generated thumbnail -> picture upload dialogue opens, but the picture isn't added ❌
- Changing Dual stream Presenter thumbnail for a published event afterwards with a newly generated Presentation thumbnail ("use for all tracks") -> newly generated Presentation thumbnail is ignored and old Presenter thumbnail still being used ❌
- Changing Dual stream Presentation thumbnail for a published event afterwards with a newly generated Presenter thumbnail ("use for all tracks") -> newly generated Presenter thumbnail is ignored and old Presentation thumbnail still being used ❌
- Thumbnail picture isn't shown in correct resolution in Paella 8 (probably a Paella player issue and not related to this issue) ❌
To summarize my observations: changing the thumbnails for an already published event and the handling of thumbnails for dual stream events has some issues and needs improvements.
Was not working for timestamp thumbnails, because I forgot to adapt the code for that
Should be fixed in the backend now.
"Discard" button should be properly enabled/disabled again (note that "discard" only allows you to undo all changes made to the thumbnail during the current editor session)
Should be fixed now.
Should now use correct thumbnail, same for the other way around
I did not take a look at this. |
It's not quite fixed yet, but the behaviour has changed. If I generate a thumbnail from the presentation track and press "use for all tracks", it looks fine in the editor, but in the published event, the presenter thumbnail, for the time chosen in the presentation track, is shown as the preview instead of the presentation thumbnail.
Thanks for the clarification, "Discard" now works as described.
Yes.
Same problem as described in the first point. |
Not only sends the timestamp a thumbnail should be generated from, but also the flavor type of the video it should be generated from. This is necessary when "useWithAllTracks" is used, because it adds a thumbnail from one video to other videos.
|
Thanks for catching that yet again. "UseForAllTracks" should now also work fine for the published event. |
snoesberger
left a comment
snoesberger
left a comment
There was a problem hiding this comment.
Thanks for catching that yet again. "UseForAllTracks" should now also work fine for the published event.
Thanks @Arnei for also fixing the issue with "UseForAllTracks". I have now been able to successfully test all of my thumbnail use cases. But I haven't looked at the source code, perhaps someone else could check that it looks reasonable.
2 participants
THIS PR WILL BREAK THUMBNAIL GENERATION WITHOUT THE RELATED BACKEND PR: opencast/opencast#7698
Fixes #814.
Currently when generating a thumbnail, we create it here in the frontend and then send it to the backend. With this patch, we instead send the time stamp it was generated from to the backend.
The goal is to let the backend generate the actual thumbnail, instead of the frontend. This avoids quality issues when generating thumbnails from low resolution videos in the frontend. It also allows for respecting institution specific thumbnail settings (e.g. encoding profiles).
The downside is that this relies on workflow properties. As such, admins will have to adapt their workflows or thumbnail generation will be broken for them.
This change should not impact the user experience of using the editor frontend.
How to test this
Requires changes in the backend. Can otherwise be tested as is.