3 Automated Workflows to Prevent and Detect Bad 4K Video Uploads | Vikhyat Raghumanda

This video from Vikhyat Raghumanda of Humanitarians AI is the second part of a review of video quality control. The first part laid out five packages; this one shows how they combine into three end-to-end workflows. The point it stresses is not the individual steps but what separates the workflows. They are not three versions of the same thing, and they are not a menu from which to pick one.

Workflow A: prevent the wrong file size

Workflow A lives inside the local toolkit. A fellow pastes the starter block, builds as normal and renders. Before writing the file, the toolkit checks the size it is about to produce. If that size is not one of the two approved sizes, it stops and says what is wrong, and nothing is saved. The fellow fixes the problem, rerenders, runs the self-check and uploads. Because the wrong file is never created, nothing downstream ever sees it.

Workflow B: read the drive without downloading

Workflow B runs on a schedule and touches nothing. It lists every file from the drive's own record, so the whole folder can be read in seconds without downloading anything. The fellow's name, format and resolution are taken from the file name. The fast checks run first, and anything that fails them goes no further. Only the files that pass are downloaded for the slower frame check. The video describes B as existing so that no one has to open a video to find out whether it is usable.

Workflow C: organize failures and tell the submitter

Workflow C runs every step of B first, so the verdicts are settled before anything moves. Files then go into two folders that were made by hand in advance. A note sits beside each failing file with the corrected value, the fellow is sent that same line, and every move is logged. C is the only one of the three that writes, and it adds no information that B did not already have.

Why the order is the argument

The video summarizes the relationship in one line: A prevents, B describes, C organizes what B described. A sits upstream of B, and C only makes sense once B is trusted. Someone could run all three, only B, or only A. What they should not do is treat them as three bids for the same job.

What the checks cannot do

The video states one limit plainly. Submission guidance says the definitive 4K check happens on YouTube after processing, because a local file cannot prove how YouTube will handle it. None of these workflows removes that step. What they remove is the upload cycle spent on videos that were never going to pass.

Key takeaways

• The three workflows are complementary, not alternatives.
• Workflow A stops a render with an unapproved size before anything is saved.
• Workflow B is read-only, runs on a schedule and uses the drive's own file records.
• Fast checks run first, and only passing files get the slower frame check.
• Workflow C moves failing files into folders, leaves a note with the corrected value, notifies the fellow and logs each move.
• C should only be trusted once B is trusted.
• A final 4K check on YouTube still happens after processing.

Try it yourself

If you run this kind of review, decide which of the three workflows you would trust first. The video poses the question as whether you would rather be told earlier or told less often, which is a useful way to choose where to start.