Learning goal
After watching, you understand what MaskingOps is, when a project crosses the threshold from "I'll mask each video by hand" to "I need an operations layer," and the four main surfaces it provides: a dashboard, batch processing, QA review, and an archive view that hands off to stage 5.
Transcript
Cold open
You've masked one video. Then ten. Then five hundred. At some point the laptop tab full of progress bars stops working. That's the line MaskingOps is on the other side of.
When you cross the threshold
Four signs you've crossed the line:
- More than ~20 videos to process. Manually tracking which one's done, which failed, which needs QA — it stops being possible in your head.
- Multiple people working on the same corpus. You need shared state, not a folder of files on someone's desktop.
- Reviewers need to certify outputs before archive. You need a review queue, not a Slack thread.
- Processing happens on shared compute (HPC, SURF, cloud). Jobs need to be submitted, monitored, retrieved, and tracked.
The four surfaces
MaskingOps wraps the MaskAnyone pipeline with four surfaces. Each one handles a part of the operations problem.
Surface 1 — Dashboard
Single pane of glass: how many videos in the corpus, how many processed, how many failed, how many waiting for review. Stop-the-world questions answered at a glance. Status counters at the top. Recent activity below. If something failed five hours ago, the dashboard surfaces it — you don't have to dig in logs to find out.
Carbon design system. Looks deliberately neutral — this is a tool you'll have open while screen-sharing with privacy officers and IT. Aesthetics are a trust signal.
Surface 2 — Batch processing
Submit a whole folder. MaskingOps queues every video, picks the right masking template, dispatches jobs to whatever compute backend you've connected — local Docker, an HPC, SURF — and reports back when each one finishes. Run jobs in parallel. Priority-tag the urgent ones. Re-run a failed batch with one click instead of fishing through job IDs.
Surface 3 — QA review
This is the surface a data steward lives in. Every processed video lands in a queue with a status: pending, in review, approved, rejected. The reviewer opens a card, watches the masked output, runs the structured QA sampling protocol — the one from the Quality-check deep-dive — and clicks approve, reject, or send-back-for-refinement.
Every action is logged. Who approved what, when, against which processing parameters. That log is what survives the project — and what an auditor will read.
Surface 4 — Archive prep
Where approved outputs queue up for stage five. Approved videos arrive here with their processing parameters, QA log, and masking-method metadata already attached. From here it's one step to FAIR packaging and DANS deposit — which is Tutorial 05. Notice what's NOT here: anything that didn't pass QA. The archive surface only sees clean, signed-off outputs. No accidental publishing of failed runs.
A typical MaskingOps week
Concretely, here's what a research week using MaskingOps looks like.
Monday morning. An RA uploads fifty fresh interview videos through the batch surface. MaskingOps queues them, dispatches to the HPC overnight.
Tuesday morning. Dashboard says forty-seven succeeded, three failed. The three failures are tagged with the reason — OOM on a 4K clip, for example. RA re-queues them with a downsampled flag.
Wednesday through Friday. The data steward opens the QA queue, reviews each masked video against the lab's sampling protocol. Approves nine, rejects one — that one goes back with a comment for refinement.
End of week. Forty-six videos sitting in the archive-prep surface with full audit trails. Ready to FAIR-package and deposit.
Recap
MaskingOps: four surfaces over the same MaskAnyone pipeline. Dashboard for stop-the-world questions. Batch processing for scale. QA review for sign-off. Archive prep for handoff. Every action logged, every approval traceable.
Final stage of the pipeline — Archiving. FAIR metadata, DANS deposit, what gets shared and what stays restricted.