The old "docker build" no longer does caching the way it used to, and our cache logic doesn't work.
The new cache logic uses buildah, which is an alternate image build tool.
Buildah comes pre-installed on GHA.
When building, it pushes each layer as it goes to the cache repo.
It queries the repo for layers that are already built, so we don't need to explicitly pull
any specific tags and cache from them.
If caching is not enabled we still use docker as normal, so local development is not affected.
Local automatic caching will still apply.
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.)