Video Mover: a configurable pipeline for multi-platform publishing

A pipeline of stages you can switch off

Video Mover is described as a content distribution automation pipeline for multi-platform content operations, and the project states its scope plainly, a video processing and publishing workflow for the kind of work a content team does repeatedly. The framing in the documentation is careful. It says the goal is not to replace the creative part but to hand the deterministic repetitive work of processing, captions, scheduling and publishing to a pipeline, so that people keep the decisions about material selection and final review. The workflow is a straight line:

Content input
    -> File watcher
    -> Video processing
    -> Metadata generation
    -> Scheduling
    -> Platform adapters
    -> Execution logs

The stages are separate modules that can be combined, replaced or switched off depending on the job, which is what separates this from a script that uploads one folder to one site. The project is MIT licensed, the primary language is Python, and the last push was on 2026-09-20 with the only tagged release, v1.0.0, dated 2025-04-04.

A Watchdog folder listener starts the run

The entry point of the pipeline is a directory watcher, and the documentation describes it as continuous monitoring of a chosen material directory with a new file triggering the processing task automatically, supporting unattended 24 hour running. That design choice has consequences worth naming. The pipeline is push based rather than pull based, so a team drops finished files into a folder and everything downstream happens, which suits a workflow where several people feed the same inbox. It also means the state of a run lives outside any single command, which is why the project emphasises full logging of task logs and execution state for locating failures and reviewing a process afterwards. The watcher is implemented with Watchdog, which appears in the dependency list, and the scheduling side uses APScheduler to maintain the task queue and the publication timetable in one place.

FFmpeg and OpenCV do the heavy transformation

The processing stage is the widest part of the project and it is built on FFmpeg and OpenCV as a configurable chain. The listed items cover automatic subtitles, custom titles, background music, picture in picture, muted cuts, mirroring, rotation, cropping, fade in and fade out, quality adjustment, and a set of visual effects including background blur, frame swapping, colour shifting and texture noise. Every function is independently configurable and freely combinable, and the documentation positions this as serving re-creation and material normalisation scenarios. The NVIDIA GPU path is worth calling out separately, since hardware encoding through a compatible NVIDIA card is described as noticeably shortening batch processing time, and that is the difference between an overnight job and a weekend job when the batch is large. The processing module lives in the Dedup directory, and the dependencies reflect the stack, with ffmpeg-python, opencv-python, numpy, Pillow, pydub, openai-whisper and pysrt all present, the last two pointing at subtitle generation and subtitle file handling.

An LLM drafts the title and tags, a person signs off

The metadata stage is where a language model is used, and the arrangement is the interesting part. The project connects to the Alibaba Cloud Bailian model, analyses the video content and generates a draft title and tag set, and the documentation is explicit that the draft is confirmed by a human before publishing. The stated design goal is that the machine handles the first pass and the person keeps the final judgement, which is a reasonable split for captions and tags where a wrong title is embarrassing but a wrong upload is permanent. The configuration note repeats the same discipline elsewhere: the API key should be provided through a secure local configuration method and never committed to the repository, and the current limitations list states that API keys, cookies and account configuration must not be committed to Git. The dependencies include both the openai and dashscope packages, and the openai-whisper package for transcription.

Playwright drives the upload forms, and the session is reused

Publishing is browser automation rather than a platform API, and the adapters cover TikTok, Douyin, Kuaishou, Bilibili, WeChat Channels and Xiaohongshu, automatically handling login state reuse and form filling. Reusing the login state is what makes the difference between a pipeline that runs unattended and one that asks a human to log in every time, and the setup instructions say that on the first run of a platform adapter you complete the account login and cookie initialisation when prompted, and then the cookies live in the account configuration. The account and platform settings are kept in the Upload directory alongside the adapters, and the main configuration file, my_apps.yaml, holds the input directory, target platforms, account files, proxy settings and scheduling parameters, with the platform and network parameters in one place. The extension story is explicit, new platforms or processing items are added through the plugin and Handler structure without changing the main flow, which is the standard way to keep a long pipeline maintainable.

Three third party patches are part of the install

The installation section contains the most useful and least pleasant detail in the documentation. Beyond cloning the repository and running setup.bat, which installs Python, Node.js, Playwright and the related dependencies, there is a dependency patch step that the documentation calls key. Three small changes have to be made inside the virtual environment, and they are the kind of detail that decides whether a project like this survives contact with a real platform. The first is in the f2 tiktok handler, around line 389, where the cursor parameter has to be passed as an int rather than a string. The second is in f2 utils, around lines 200 and 690, extending date string parsing so that both the YYYY-MM-DD form and a form with a time component are accepted. The third is in the tencent uploader around line 191, where the page navigation wait timeout goes from 1500 milliseconds to 10000 so a slow network is not mistaken for a failure. The project itself calls this out as the hidden cost of automation work, and the requirements list shows the scale of the dependency surface that has to be pinned, with f2, biliup, xhs, cf_clearance, eventlet, opencc-python-reimplemented and pywin32 among the entries.

The stated limits are honest and worth quoting

The current limitations section is short and specific, and it is the part to read before trusting the pipeline in production. When platform pages and interfaces change, the upload adapters may need updating in step with them, which is the ordinary cost of automating a site that has no public upload API. Some upstream dependencies have version compatibility requirements, so the advice is to pin versions and use an isolated environment, which is exactly what the three patches imply. The project has not yet established a complete automated test suite or CI, so a small scale validation is recommended before production use. And credentials should stay out of Git. The runtime requirements are also specific, with Windows, Python 3.12 or newer, Node.js 22.x, FFmpeg on the PATH and Chrome. The project states that the point of it is the decomposition and orchestration of a cross-tool, cross-platform workflow rather than any single video processing algorithm, and the fact that upstream libraries need patches to match real platform interfaces is named as the most common hidden cost of this kind of work.

Editorial conclusion

Adopt Video Mover if you publish your own material to several platforms and want the repetitive processing, scheduling and uploading automated, and read the adapter breakage notes first. Do not point it at material you do not own the rights to, and pin the dependency versions, because the setup already requires patches to three third party libraries.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. toki-plus/video-mover on GitHub