Merging 1000 duplicates of the same batch:
v1: 98ms
v2: 101ms
v3: 116ms
v4: 116ms
So as expected v3 and v4 have a small cost with duplicates for optimizing for non-overlapping,
but even with ridiculous numbers duplicates are fast to process anyway.
It can do 24h of batches in 180ms, ~180x faster than v1.
I'm a little concerned it's overly specialized for that role and will be slow to merge duplicate batches,
but those operations involve tiny amounts of data by comparison so it doesn't really matter.
which is really just the second implementation but generalized to N-way merge instead of 2-way.
Basic benchmark results:
v1 v2 v3
1 hour (60 batches): 19ms 31ms 23ms
24 hours (1440 batches): 34s 130s 17s
So it's about as fast as v1 when it doesn't matter, and twice as fast when it does.
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