short_videos and the PHP link parsing layer behind it

One URL in, one JSON contract out

The project is a parsing service for share links. You hand it a URL, or a whole block of share text with a link buried in it, and it returns structured JSON with the media link, the cover, the author, the duration and the publishing time.

The list of content types is broader than video. It handles video, image galleries and live photos, and it returns the same shape for all three, which is the design decision that makes the project useful. A consumer does not have to branch on content type to know what the response means. For Douyin it also returns the background music, the alternative quality links, and for galleries the original images rather than a compressed version.

The documentation describes the Douyin path specifically as a cookie free detail interface, needing neither a login nor a captured cookie, and handling video, gallery and live photo content in one go. The quality handling is also described in detail: the original quality is resolved automatically through a 302 on the vid, and there is automatic fallback across multiple bitrate levels, so a request that would otherwise return a lower quality link tries the others first.

The point of the whole design is the uniform contract. The repository carries a specification document for it in the `docs/` directory, with a Chinese version and an English one named `Unified-Video-Parsing-JSON-Format-3.0.md`, so the response shape is documented rather than reverse engineered from the sample response in the readme.

That is the part worth crediting. A dozen hand written parsers that all return the same structure is a real contribution, and it is a much better foundation than a dozen parsers that each return something different.

One file per platform, and an aggregate entry that dispatches by keyword

The code layout makes the extension story obvious. Each platform has its own file under `api/`, and the table in the documentation maps every one of them to a path.

Douyin has a dedicated directory with `douyin.php` as the entry and `DouyinParser.php` holding the parsing core, described as the detail interface plus the original quality 302. There is a second Douyin implementation as a Cloudflare Worker, `api/douyin-cloudflare workers/workers.js`, and a separate one for profile page batch parsing at `api/douyin-home/home.php`, which is the one entry point that does need a login cookie because it calls the feed interface.

The other platforms are single files: `api/kuaishou/ksjx.php` for Kuaishou, `api/xiaohongshu/xhsjx.php` for Xiaohongshu, `api/bilibili/bilibili.php` for Bilibili with its part list and duration, `api/weibo.php` and `api/weibo_v.php` as an interface version and a crawler version for Weibo, `api/toutiao.php`, `api/pipigx.php`, `api/ppxia.php`, `api/zuiyou.php`, and two directories for the AI video platforms, `api/doubao/` and `api/jimengai/`.

The NetEase Cloud Music parser is the outlier: `api/wyy.py` is Python and Flask rather than PHP, so the project is not entirely single language even though the deployment story is PHP only.

The entry point for most users is `api/sv.php`. It auto detects the platform from keywords in the URL and forwards to the matching single platform endpoint. The platform keywords and the per platform interface paths are maintained in a configuration block at the top of that file, and by default it calls the single platform interfaces under the same deployment directory, though it can be changed to forward to full URLs at another site.

That design is the practical win: a caller writes one integration and gets every platform, and adding a platform later does not change the caller's code.

Deploying is a clone, a copy, and no configuration at all

The deployment story is short, which is consistent with the zero dependency claim. The environment requirements are PHP 8.0 or later with the curl and json extensions enabled, a web server such as Apache or Nginx, and no Composer, zero dependencies.

You clone the repository:

git clone https://github.com/jiuhunwl/short_videos.git
cd short_videos

And then you deploy the whole directory to the web site root, or to any subdirectory, with no configuration needed. That is the entire procedure. There is no build step, no package resolution, no environment file.

The optional third step is the Cloudflare Workers variant. If you want the Douyin parser on Workers rather than PHP, you go into the `api/douyin-cloudflare workers/` directory, read its README, and paste `workers.js` into the Worker editor to deploy. Having both a PHP and a Workers implementation of the same parser means you can place the Douyin endpoint close to the platform and the rest of the service wherever your web server lives.

The single request form is a URL parameter, and the parameter accepts a whole share text block rather than only a clean URL, which is convenient because the copy text that these apps produce usually contains extra words around the link:

curl "https://api.bugpk.com/api/douyin/douyin.php?url=https://v.douyin.com/xxxx/"

The aggregate form is the same shape with a different path, `api/sv.php?url=` followed by the link, and is the one to reach for when you do not want to detect the platform yourself.

One deployment note that will bite if you skip it. The aggregate forwarding needs the web server to handle concurrent requests, and the documentation says Nginx or Apache with PHP-FPM both do. The `php -S` built in server is single process, so a self request blocks, which is why it is only suggested for local debugging of the single platform endpoints.

The 403 problem and the proxy that exists because of it

There is one operational problem in this design that deserves its own explanation, because it explains a whole directory in the tree.

Direct media links from these platforms are frequently protected against hotlinking. The documentation states that when a video direct link returns a 403 from the anti hotlinking mechanism, you can use `api/svproxyurl.php` in PHP, or `cf_sv_proxy/worker.js` on Cloudflare Workers, to proxy and forward the request. The Workers variant has its own deployment documentation in `cf_sv_proxy/README.md`.

So the project ships a proxy specifically because the links it returns are often not directly fetchable from a third party server. That is a meaningful constraint on the design. The parsing works, the JSON is correct, and then the URL in it 403s unless every consumer routes through your own proxy, which concentrates your bandwidth and puts your server in the request path for every byte of media.

There is a second reading of that arrangement, which is the copyright one, and the project is unusually direct about it. The important notice in the documentation states that this project provides technical research and interface examples only, that the code is for learning, exchange and technical testing and must not be used for any illegal purpose. It goes further: the short videos, galleries, music and related assets obtained through this project remain the property of the original platform and the rights holders, including the authors, and users are required to make sure they have obtained the necessary authorisation and to use the content within a lawful and reasonable scope. Any direct or indirect consequence arising from use of the project is borne by the user.

The notice also says that if a rights holder believes content has been infringed or used improperly, they should contact the project and the maintainers will cooperate.

That is a legal disclaimer, not a permission. Running a public instance of a watermark removing service on someone else's content is a different act from testing the code on content you own, and the MIT licence covers the code rather than the media it fetches.

A dual runtime, and a whitelist file nobody explains

Two details in the tree deserve a look because they are not covered by the feature list.

The first is the dual runtime. The documentation describes a dual runtime design, a PHP interface plus a Cloudflare Workers version for Douyin, and lets you pick according to the deployment environment. The Workers build exists for the Douyin parser specifically, so the split is not symmetric across the platform set. There is also the Python and Flask NetEase Cloud Music parser, which means the claim of a pure PHP implementation with no Composer applies to the main body of the project rather than to every file in it.

The second is `download_whitelist.txt` at the repository root. It appears in the top level file listing and is not explained anywhere in the visible documentation. Given its name and its position next to the proxy endpoints, it plausibly holds a list of hosts or URLs that the download path is allowed to fetch, but the documentation here does not say what it contains or how it is used, so treat it as a file to read before you rely on the download behaviour.

Neither of these is a defect on its own. They are the kind of detail that a project documentation page does not always cover, and both are worth checking in the source before you put the service behind a public URL.

Upstream changes are the real maintenance risk, and the project is honest about it

Every parser here is a hand written client for somebody else's web interface, and that class of software has one predictable failure mode: the platform changes, and the parser silently returns nothing useful.

The documentation's own status column is informative. Each platform row is marked as available, and a note explains that Douyin content parsing keeps only the PHP version and the Cloudflare Workers version as combined entries, while profile batch parsing is a separate interface requiring a login cookie. The note about needing a cookie for the feed interface is an admission of a different kind of fragility, since cookie based endpoints are tied to an account rather than to an anonymous request.

The project publishes no GitHub releases, and the version numbers in the package listing are absent, so there is no release history to consult for a changelog. What you can observe is activity: the last push to the main branch was on 2026-10-19, two days before this review, and the repository is not archived. A project that updates parsers as platforms change is doing the right thing, and the one that stops updating is the one that breaks.

That is the argument for or against running your own instance rather than using someone else's public one. The public instance at api.bugpk.com is convenient and it is maintained by the same people, but it concentrates the dependency: if Douyin changes its interface, the instance you call changes behaviour, and if the operator decides to stop, your integration goes with it. Running your own copy of this code is a few files and a web root, and it puts the maintenance burden, and the control, on you.

The MIT licence is what makes that choice open. Anyone can read the code, modify a parser, or run the service privately, and the only conditions the licence imposes are the notice and the licence text.

Editorial conclusion

short_videos fits a developer who already has permission to redistribute the content in question and wants one JSON contract across several video platforms instead of maintaining a separate scraper per site. It is the wrong choice if you need a commercial service, because the project's own notice places responsibility for authorisation and for the consequences of use on the person running it, and the platform support is a set of hand maintained parsers that upstream changes can break at any time. Before deploying, verify three things: that the specific platform and content type you need is listed as available rather than planned, that your web server can handle the self forwarding the aggregate endpoint performs, since the documentation warns that the PHP built in server is single process and will block on self requests, and whether your traffic needs the 403 proxy path, which exists because the direct links are often protected against hotlinking. The code is MIT licensed, the last push was on 2026-10-19, and the repository publishes no releases.

Frequently asked questions

Official sources

1. Issues
2. jiuhunwl/short_videos on GitHub
3. License: MIT
4. Project website
5. README