As per Sokar's request.
It's not entirely ideal that we're copying the "should be in playlists" criteria here
and in the playlist manager, but it's simple enough (is DONE, is public, matching upload location, tags are a superset of playlist tags) that it should be fine.
This was originally done to ensure the crop settings worked no matter what the source resolution was,
but in practice the source resolution is stable (1080p) and the double-resize loses a lot of quality
if you actually want to scale *up* the cropped image.
By picking the "one-off overlay" option for a thumbnail, you swap specifying a template name
for being able to upload a one-off template that is then combined with the requested frame.
The rendering is done by restreamer, and we do it explicitly whenever
a) Generate Thumbnail Preview is pressed
b) The video is submitted
The rendered thumbnail is then included in the submission as a "custom" thumbnail.
The default thumbnail template params (crop and location) do not change
when this mode is selected, so they'll effectively be the default params of the previously-selected
template. In most cases this will be what you want since almost all our templates share the same
params, and custom one-offs will too.
- On load + change of template, set from template defaults
- On load, set from video if not null
- Show only in template mode
- Use when previewing image
- Send when submitting
It turns out that `fadefast` and `fadeslow` both take about twice as long as `fade` to do a job so similar there's no good reason to keep either in our accepted transitions list, especially when the former is so misleadingly named. (Amusingly, in my testing, `fadefast` was actually the slower of the two.)
The professor system for annotating the data was never fully finished and isn't needed
for our purposes. We can always resurrect it later, but for now it's easier to just get rid of it.