Y2A-Auto: a self-hosted YouTube to AcFun and bilibili pipeline

What Y2A-Auto automates, and for whom

Y2A-Auto is a single application that takes a YouTube video and pushes it to AcFun or bilibili. The README describes the scope as "从下载、ASR、字幕翻译、字幕质检、内容审核到上传，全流程自动化" (from download, ASR, subtitle translation, subtitle QC and content review through to upload, fully automated). It is written in Python, licensed GPL-3.0, and the repository's top level holds app.py, a Dockerfile, docker-compose.yml, and modules/ alongside templates and static assets for the web UI.

The intended user is someone running their own server who wants a repeatable repost workflow rather than a manual edit-and-upload session. The README lists a Web management backend with a task list, manual review and forced upload, plus a settings center split into groups: runtime overview, accounts and network, content review, AI models, subtitle handling, speech recognition, video transcoding, monitoring and maintenance, and security. That is a lot of surface for a tool whose core job is moving one file from one platform to another, and it tells you the project expects operators, not casual users.

Two audiences are a poor fit. Anyone without working YouTube cookies will not get past the first step, because the README marks cookies as required (必须) for YouTube, AcFun and bilibili. And anyone who only wants to archive YouTube videos should use yt-dlp directly; Y2A-Auto does not exist to be a downloader, it exists to finish a repost.

The pipeline: yt-dlp, ASR, subtitle QC, review, upload

The data flow follows one direction. yt-dlp fetches the video and its cover image. Speech recognition then produces subtitles on demand or automatically, and the README names Whisper and Voxtral as the supported engines. A subtitle transformation engine handles the text: splitting long lines, normalizing punctuation, filtering filler and repeated words, detecting hallucinated text and noise tags, and flagging passages whose text density is too high. Post-processing covers time offsets, minimum duration and merging of adjacent gaps. Translation and QC run through an OpenAI-compatible endpoint.

Content review uses Alibaba Cloud Green, which is visible in requirements.txt as alibabacloud_green20220302 pinned to 2.20.4 with alibabacloud_tea_openapi and alibabacloud_tea_util alongside it. AI also generates the title, description, tags and a partition recommendation. Upload then goes to AcFun, bilibili, or both, controlled by UPLOAD_TARGET_DEFAULT.

The scheduling layer uses APScheduler, and the monitoring feature is separate: it polls YouTube channels or keyword searches in latest or historical mode, filters by video type, and adds matches to the task queue. That path needs YOUTUBE_API_KEY for the YouTube Data API v3, and the README notes that the monitoring API has its own proxy settings (YOUTUBE_API_PROXY_ENABLED and YOUTUBE_API_PROXY_URL) which do not inherit the download proxy. Splitting those two is a sensible detail: a download proxy tuned for large transfers is often the wrong route for small JSON API calls.

Installing Y2A-Auto with Docker and configuring the first task

The README recommends Docker because it removes the need to install Python, FFmpeg and yt-dlp by hand. Before starting anything, prepare the cookie files it lists as required: cookies/yt_cookies.txt for YouTube, cookies/ac_cookies.json for AcFun, and cookies/bili_cookies.json for bilibili. These come from a browser extension export, and the README explicitly says not to commit them to the repository.

With the cookies in place, the compose file starts the service on port 5000 and persists config, db, downloads, logs, cookies and temp as bind mounts:

docker compose up -d

The README states that the default image is fqscfqj/y2a-auto:latest from Docker Hub, and that you can switch to ghcr.io/fqscfqj/y2a-auto:latest if you prefer the GitHub Container Registry. After the container is up, open http://localhost:5000. The README advises configuring login protection, platform accounts and the YouTube cookie first.

If the startup log shows a PermissionError when writing to config/, db/ or logs/, the fix in the README is to create the directories and give them to the UID/GID the container uses, which defaults to 1000:1000:

mkdir -p config db downloads logs cookies temp
sudo chown -R 1000:1000 config db downloads logs cookies temp

Rootless Docker and userns-remap change that mapping, and the README points to Docker's own documentation for the UID/GID mapping rules rather than restating them. For a local run instead of Docker, the README gives Python 3.11+, FFmpeg and yt-dlp as prerequisites, then a PowerShell sequence that creates a virtual environment, installs requirements.txt and runs app.py, after which the service answers on http://127.0.0.1:5000.

FFmpeg 5.1, the x265 fallback, and the failures the README admits

The sharpest documented constraint is the FFmpeg version floor. The README states that subtitle burning uses -fps_mode cfr to control frame rate, and that this option arrived in FFmpeg 5.1; 5.0 and earlier only recognize the deprecated -vsync. If FFMPEG_LOCATION points at a 5.0-or-older build, the software encoding path fails outright with Unrecognized option 'fps_mode', and the README is explicit that non-hardware encoders have no downgrade retry, so the task errors out. The bundled FFmpeg and the auto-downloaded BtbN latest build are both far above that version, so this only bites people who override the path.

A second, softer failure mode concerns codecs. Setting VIDEO_CPU_CODEC=x265 requires an FFmpeg build with libx265, which needs --enable-gpl --enable-libx265. When that library is missing, the README says the encoder degrades to libx264 and continues burning subtitles instead of dropping them. That is a deliberate asymmetry: a missing video codec costs quality, a missing option string costs the whole task.

The README also documents the environment variable FFMPEG_AUTO_DOWNLOAD, default true, which fetches FFmpeg on Windows when it is absent. On Windows the official release package usually bundles FFmpeg and FFprobe, and the README warns that hand-built packages must keep the ffmpeg/ directory complete. None of this is unusual for a media pipeline, but it means the tool's reliability is partly a function of which FFmpeg binary you point it at, not just the application code.

Credentials, review gates, and the AI endpoint negotiation

Three credential paths exist and they are not equal. YouTube needs cookies, either from cookies/yt_cookies.txt or synced from a CookieCloud service, which the README supports in auto, legacy and aes-128-cbc-fixed encryption modes with a one-click test and sync in the web UI. AcFun and bilibili support QR code login, and bilibili additionally accepts imported cookies in Netscape or JSON format. Cookie expiry is not something the README promises to detect in advance, so a repost that suddenly fails on authentication is a maintenance event you should expect.

Content review is a gate, not a suggestion. Alibaba Cloud Green runs before upload, and the README separates manual review, forced upload and content safety detection as distinct behaviors. AUTO_MODE_ENABLED defaults to false, which means unattended posting is off until you turn it on. UPLOAD_APPEND_REPOST_NOTICE defaults to true, appending a repost notice automatically. For anyone reposting third-party material, those two defaults are the difference between a supervised queue and an automatic one.

The AI configuration is more accommodating than most. OPENAI_BASE_URL accepts either an API root such as https://api.openai.com/v1, which defaults to Chat Completions, or a full /chat/completions or /responses endpoint, in which case the protocol is selected and normalized automatically. Responses requests get their messages, JSON output format and token limit parameters converted, and the return value is normalized for translation, QC and smart segmentation. When a compatible service rejects response_format, token limits, a custom temperature or a particular instruction role, the README says the system negotiates down level by level based on the actual endpoint error, and falls back to a minimal model plus user message payload if the gateway only returns a generic schema error. That is a real engineering effort at compatibility, and also a sign that the target is a moving set of third-party gateways rather than one stable API.

Where it overlaps with yt-dlp and where it does not

The obvious alternative for the download half is yt-dlp itself, which is already a dependency here and is listed in requirements.txt as yt-dlp[default] with a comment saying it is kept rolling because extractor fixes are time-sensitive. The difference in approach is that yt-dlp is a general extractor and downloader with no concept of a destination platform, no subtitle translation, no content review and no upload step. If your goal is to fetch videos, yt-dlp is the smaller tool and the one you should use.

Y2A-Auto's value is everything after the download. It carries the file through speech recognition, subtitle transformation and QC, AI metadata generation, a Green review call, and finally an authenticated upload to AcFun or bilibili, with a queue, a monitor and notifications attached. That difference matters for the decision: yt-dlp asks you to write the glue, while Y2A-Auto asks you to accept its glue, its settings taxonomy and its credential model. If you already have a working script that downloads and uploads, replacing it with this project is a rewrite, not an upgrade.

One narrower overlap is worth naming. The monitoring feature polls YouTube channels and keywords on a schedule, which yt-dlp can approximate with a cron job and an archive file. Y2A-Auto adds latest and historical modes, video type filters, history records and config file recovery on top of that, and it needs a YouTube Data API key. Whether that is worth the extra moving parts depends on how many channels you track.

Licence, maintenance and what upgrading costs you

Y2A-Auto is GPL-3.0. If you deploy it as a service for other people, or modify and redistribute it, the copyleft terms apply to the distributed work. That is a description of the licence, not legal advice; check with someone qualified if your deployment model is unusual. Two bundled assets deserve a look before you ship anything: the README states that the fonts in fonts/ are a built-in dependency used for subtitle burning and that their licence is in fonts/LICENSE.txt. Subtitle rendering embeds those fonts into video output, so the font licence travels with your uploads in a way the application licence does not.

On maintenance, the last push to the default branch was on 2026-09-14, and the most recent release is 4.10.3 from the same day, with 4.10.2 earlier that day and 4.10.1 on 2026-08-25. That is a recent cadence, and the repository is not archived. The dependency list explains part of why: yt-dlp is deliberately unpinned, and the comment says extractor fixes are time-sensitive. In practice that means you should expect to rebuild or pull a new image when YouTube changes something, and you should not pin the image tag for long stretches if downloads start failing.

The upgrade cost is mostly configuration drift. requirements.txt pins flask to the 3.1 line, openai to >=1.66.0 and <3.0, and httpx to >=0.27 and <0.28, while the Dockerfile pins torch and torchaudio to 2.6.0 as the verified line for silero-vad 6.2.x JIT models. A local install that resolves those differently from the container is a plausible source of behavior that differs from the documented path. config/config.json is generated on first run, so back it up before pulling a new image if you have tuned the settings groups by hand.

Editorial conclusion

Adopt Y2A-Auto if you already run a server, hold valid YouTube, AcFun and bilibili cookies, and want the download, subtitle, review and upload steps handled by one process with a browser UI. Do not adopt it if you only want to download YouTube videos: that is yt-dlp's job and this project wraps it in more machinery than a download-only workflow needs. Before committing, verify that your FFmpeg is 5.1 or newer, since the documentation states that the software encoding path fails with Unrecognized option 'fps_mode' on 5.0 and earlier, and check whether the AcFun and bilibili cookie files you can export match the formats the project expects.

Frequently asked questions

Official sources

1. fqscfqj/Y2A-Auto on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases