Videodl (videofetch): a pure Python video downloader for Chinese and Western platforms

The gap Videodl fills: site-specific parsing in plain Python

General-purpose downloaders are built around a small number of generic extractors. Videodl takes the opposite route. Each supported platform gets its own client class, and the README lists those clients in a table with a ParseURL column, a Download column and a link to the core code file, for example videodl/modules/sources/bilibili.py and videodl/modules/sources/baidutieba.py. That structure is the point of the project: when a platform changes its player or its signing scheme, the fix lands in one Python file rather than in a shared extractor that has to stay compatible with everything else. The README states the repository is created solely for learning purposes and that commercial use is prohibited, so the intended audience is researchers, students and developers building personal or experimental pipelines. The README also names academic research, dataset construction and multimedia processing workflows as use cases, which fits a codebase you are expected to read and extend rather than treat as a black box.

How the client modules work: parse first, then download

The README's support table separates two capabilities per platform: ParseURL and Download. That split describes the data flow. A client receives a page or share URL, resolves it to a playable media URL (and, where relevant, a title and metadata), and the downloader then fetches that media. The repository layout backs this up: videodl/modules/sources/ holds the per-site clients, while videodl/modules/cdm/ ships .wvd files and videodl/modules/js/ ships JavaScript and .wasm assets for YouTube, Tencent, CCTV and xmflv. Those bundled assets matter. Several platforms require running player JavaScript or a DRM-related device file to derive a usable stream URL, so the package carries Node.js and widevine components rather than downloading them at runtime. The requirements.txt confirms the weight of that approach: nodejs-wheel, pywidevine, DrissionPage, curl-cffi, m3u8, pycryptodomex and cryptography all appear as install dependencies. A pure Python downloader that also needs a bundled Node runtime and a browser automation library is not a small dependency tree, and the README does not present it as one.

Installing videofetch and running the videodl CLI

The package is distributed on PyPI under the name videofetch, and setup.py registers a console script called videodl, so the command name and the package name differ. Install from PyPI, then confirm the entry point resolves:

pip install videofetch
videodl --help

The Makefile offers a source route as well, using python setup.py install or python setup.py develop for an editable checkout. The README does not document the CLI flags in the available documentation, so treat the interactive prompt as the starting point: the requirements include questionary and rich, which the project uses for terminal prompts and formatted output. The README points to videofetch.readthedocs.io for the full documentation, and that is where argument names and per-platform options should be checked before scripting anything.

The daily check workflow tells you which clients still work

The most useful thing in this repository is not the downloader itself. It is the monitoring. A GitHub Actions workflow named check_videodl.yml runs on a schedule, and the README links a live status dashboard that it describes as auto-updated every day via GitHub Actions, with roughly three randomly sampled preview clips. There is also a daily_test_results/ directory in the repository root and a release tagged checkvideodldaily. If you are deciding whether to depend on Videodl, this is the evidence to read first: it reports, per platform, whether parsing and downloading currently succeed. The changelog explains why that matters. The v0.9.0 release notes describe fixing all broken video clients for the common video client, removing APIs that no longer provide free parsing services, and adding multiple general-purpose parsing interfaces. v0.8.9 removed support for eastday.com and added the Malaysian Oriental Daily News and iYF.tv. Support is not stable, and the project treats removal as a normal maintenance action rather than an incident.

Where Videodl breaks, and when it is the wrong tool

The failure mode is structural. Videodl depends on interfaces the README describes as sourced from public networks, and those interfaces disappear. The v0.9.0 notes record exactly that happening at scale. When a platform closes a free parsing endpoint, the client for that platform stops working until someone rewrites it, and the fix may be removal rather than repair. Second, the licence is a hard boundary: the README states commercial use is prohibited, and setup.py declares the classifier Free for non-commercial use with a PolyForm Noncommercial 1.0.0 badge in the README. If you are building a product, this is disqualifying regardless of technical fit. Third, the dependency set is heavy for a project described as lightweight: a bundled Node.js wheel, DrissionPage for browser automation, and widevine tooling mean install size and platform compatibility are real considerations, and the README does not document rollback or pinning strategy for those pieces. Finally, the README does not document error handling, retry behaviour or rate limiting, so anyone running bulk jobs is working without stated guarantees.

Videodl compared with yt-dlp's extractor model

yt-dlp is the obvious alternative and the comparison is about architecture, not features. yt-dlp centralizes extraction in a large set of extractor classes inside one maintained codebase and publishes a stable command-line contract with documented flags. Videodl splits the same job into per-site modules under videodl/modules/sources/ and leans on bundled JavaScript and device files for the platforms that need them, which is closer to how a browser would fetch the stream. The practical difference: yt-dlp's interface is predictable enough to script against, while Videodl's value is coverage of Chinese platforms and the daily status dashboard that tells you which of those clients is alive today. If your target is YouTube and you want a documented CLI, Videodl's bundled YouTube JavaScript and widevine assets are overhead you do not need. If your target is Douyin, Kuaishou or Migu and you want to read the parsing code, the per-site layout is easier to reason about than a shared extractor.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-23, so it is being worked on. Releases are frequent and small: v0.9.1, v0.9.0 and v0.8.9 all landed within about a month, each adding or removing platform support. That cadence is the upgrade cost. Because fixes are per-site, upgrading is how you get working clients, and skipping versions means running clients the maintainer has already declared dead. The requirements.txt pins upper bounds on nearly every dependency (requests>=2.32.5,<3, DrissionPage>=4.1.1.2,<5, pywidevine>=1.9.0,<2), which limits surprise breakage but also means a dependency that stops being maintained blocks the project until the pin moves. On licensing: the README and setup.py both mark this as non-commercial, and the README states that downloading paid videos requires a paid membership on the respective platform. That is a statement about the project's expectations, not legal advice, and the README also offers to remove content on request. Anyone shipping this inside a company should treat the licence as the first question, not the last.

Editorial conclusion

Adopt Videodl if you need a Python-native downloader for the Chinese platforms it covers and you can accept the PolyForm Noncommercial licence. Skip it for commercial products, and check the daily status dashboard before relying on any single site client, because the maintainer removes dead APIs in point releases.

Frequently asked questions

Official sources

1. CharlesPikachu/videodl on GitHub
2. Issues
3. Project website
4. README
5. Releases