Video distribution pipeline

Automate the work between a video and its publication

Preparing clips is a chain of small operations: download a source, find the parts, render a portrait version, choose an account, transfer the files and check that they arrived. Repeating those steps manually means keeping track of what has already happened and what still needs attention.

I built a persistent orchestration layer around an existing portrait-rendering workflow. It carries each source through preparation and delivery, with a queue I can inspect and control from Telegram. The destination is TikTok’s Inbox, where the clips can be reviewed before publishing.

Keep the right clips on the right account

Multiple accounts make scheduling more involved than taking the next file in a folder. The pipeline assigns sources according to unfinished work, then prioritizes rendering according to the clips already waiting for each account. One downloader and one encoder run at a time; upload and delivery workers are separate for each account.

All parts from a source stay attached to the same account. A later part cannot start uploading until earlier parts have reached the required delivery state. If the first part fails or has an uncertain outcome, the next part waits rather than leaving a gap in the sequence.

Accounts use stable internal identities instead of display names. Pauses survive a restart, and disabling an account stops new work while allowing delivery checks on accepted uploads to continue.

Recover without guessing what happened

The difficult case is a request that may have succeeded remotely just before the local process stopped. Automatically trying again could send the same clip twice. I separate upload acceptance, byte transfer, Inbox delivery, failure and publication instead of treating them as a single “done” state.

SQLite stores the queue, clip boundaries, upload attempts, account pauses and pending notifications. The upload initialization ID is saved before bytes are sent. After a restart, known IDs continue receiving status checks; an uncertain acceptance is held for human review instead of automatically creating another upload.

Completed downloads and renders are retained. Transactions claim work, and a process lock prevents two service instances from working the same queue. Migration also preserves old state and holds ambiguous historical uploads for review.

Stay in control from Telegram

Telegram is both an input and a control surface. After pairing a private owner chat, I can add a source, inspect the queue, check account status, pause or resume processing, assign an untouched source and explicitly retry a confirmed failure. Short source codes make these actions manageable without copying long identifiers.

Alerts have their own delivery queue, so a failed notification does not require repeating the video transfer. An alert is eligible only after confirmed Inbox delivery and at least 15 minutes after the transfer. The pause command lets the current operation finish, and delivery checks continue for work already accepted.

My contribution and the tools underneath

My focus was the Python orchestration: durable state, account routing, ordered jobs, recovery rules and human controls. I developed the project with AI coding agents, following my usual workflow.

The project reuses an existing scene-aware portrait-rendering path and relies on FFmpeg/FFprobe for media processing, TikTok for upload and delivery status, and Telegram for commands and alerts. I am presenting the integration and queue design here; I am not claiming to have invented every media-processing component.

• Python
• SQLite
• FFmpeg / FFprobe
• TikTok API
• Telegram bot
• Persistent queue

What is established, and what still needs a live run

The repository includes tests using temporary SQLite databases and mocked network calls for account identity, routing, isolated account limits, restart recovery, pairing, command replay, migration and notification retries. Those tests were not rerun for this portfolio review, and they do not establish that a live clip reached an account.

I have not established a verified end-to-end deployment result, a measured processing-time gain or audience-growth figures for this entry. The documented service runs on macOS and stops when the machine sleeps or powers off. Moving an existing workspace to another machine also requires updating its stored media paths.

The project shows the part of automation I find most interesting: deciding what the system can safely repeat, what it needs to remember and when it should ask for a human decision. Here, success means keeping a workflow understandable even when one of its steps fails.