KouShare-dl: a Go CLI for a Chinese academic video platform

A site specific downloader, not a generic video grabber

KouShare-dl is a command line tool for downloading videos and courseware from the Koushare academic video website, and for recording live broadcasts. It is written in Go and built on Cobra, and it is published to the public domain, which the README describes as letting you use it, modify it and redistribute it as you see fit.

What makes it site specific is the whole feature set. It logs into a Koushare account, queries the site's own video and live metadata endpoints, downloads HLS segments, fetches the slides that accompany a lecture, and records live rooms on a schedule. A generic downloader that understands a URL and a manifest would know how to fetch an HLS stream once you had a link, but it would not know the video id scheme, the API that returns title and speaker, or the relationship between a video and its slide deck.

The repository layout reflects that decomposition. There are top level packages for live/, slide/, user/ and video/, with cmd/ holding the Cobra commands, internal/ for shared code, ks.go at the root, and a test/ directory. The Go module requires chromedp for browser automation, along with cobra and fatih/color, which is a short and readable dependency list for what the tool does.

The audience is a student or researcher with access to the platform who wants the material offline. Everything in the design follows from that.

The README is in Chinese, and this review translates the parts that matter for adoption.

Login opens a real browser and leaves the verification to you

The login design is the most interesting part of the tool, and it is deliberately conservative. The README states plainly that the tool does not crack, hide or replace human verification.

The default is browser login:

ks login

This opens a dedicated Chrome profile used only for KouShare-dl and navigates to the site login page. The README notes that it no longer enables Chrome's automatic testing software flag, and that it preserves the verification cookies you complete yourself, so that repeated runs do not keep appearing as a brand new browser. After a successful login it reads the accessToken and refreshToken cookies the site writes, stores the credentials locally and closes the window. The dedicated profile does not read your everyday Chrome data.

There is also a phone number mode, kept from the older command habit:

ks login 13800138000

That path opens a local temporary page in your normal Chrome, and you are asked to complete the Tencent human verification yourself. Once you pass it, the program sends the SMS and shows a prompt for the six digit code in the terminal. The README explains why this path avoids trouble: the flow never visits www.koushare.com, so it does not trigger the site's homepage EdgeOne verification.

Both modes have documented limits. The default wait is ten minutes, adjustable with --timeout 15m. The phone mode opens a Chrome window with no address bar or tabs and closes it after the slider, and if Chrome or Chromium is not found you can point at the binary with --browser-path /path/to/browser. The local callback in phone mode listens only on 127.0.0.1, and the verification result is used only to send that one login SMS.

Headless machines import tokens instead of a browser

On a server with no graphical interface, the browser flow is not available, so the tool accepts credentials directly through environment variables:

KOUSHARE_ACCESS_TOKEN='...' KOUSHARE_REFRESH_TOKEN='...' ks login

This is the same import path that the README describes for restricted content: public material does not need the homepage to be visited, but for content behind a check you complete the verification and login in a browser yourself, then import your own token.

Two compatibility flags remain, --access-token and --refresh-token, along with a legacy --har flag. The README is candid about why they are not the first choice. Command line arguments can end up in your shell history, and a HAR file contains sensitive session information, so browser login is the recommended path for daily use.

Two more details are worth knowing. The credentials file permissions are restricted so that only the current user can read and write it, and the file lives next to the executable, where the logout section says you can also remove it by hand:

ks logout

Deleting the .ks.token file in the program's directory has the same effect. Running ks login again refreshes the stored credentials, and when the token expires you run it again.

The command set: save, slide, record, merge, clean

Every command follows the form ks [command] <flag>, where the command is required and the flags are optional.

  clean       清除指定目录下的所有tmp临时文件
  help        查看某个具体命令的更多帮助信息
  info        获取视频或直播的基本信息
  login       打开浏览器登录并自动保存凭证
  logout      退出登陆
  merge       合并下载的视频片段文件
  record      录制指定直播间ID的直播，命令别名为live
  save        保存指定vid的视频（vid为视频网址里最后面的一串数字），命令别名为video
  slide       下载指定vid的视频对应的课件
  upgrade     升级为最新版本
  version     输出版本号，并检查最新版本

The identifier scheme is simple. A video has a unique id, the vid, and it is the trailing number in the page URL, so the URL for video 7412 ends in 7412. Live rooms use a live id instead, and ks info takes it with the --live flag.

The info command is the reconnaissance step the README recommends before downloading anything. For a video it returns the title, speaker, organisation, date, duration, location, slide status and a summary. For a live room it returns the title, status, organiser, start time, replay status, view count, series and latest notice.

The README also explains a behaviour change worth knowing: with the newer API the video size can only be read from a full HLS manifest, so the info command no longer pre-requests the size. That is a small example of how a tool tied to a site's internal API has to change when the site changes.

Quality flags, segment concurrency, and no resume support

The flag table is where the tool's behaviour becomes concrete, and it contains one trap worth flagging. There are two -p entries and two -q entries in the same list, one for each of the commands that use them: -p is the output path for downloads and the target path for the clean command, and -q is the quality for a download and the quiet flag for cleaning. The README resolves this by telling you to run ks help [command] to see which flags are valid for a given command, since only some flags apply to each one.

The flags that matter for downloading include -q and --quality, where high is 超清, standard is 高清 and low is 标清, with the highest quality as the default. -c and --concurrency set how many HLS segments of a single video are downloaded at once, with a default of 12, and --video-concurrency sets how many videos are downloaded in parallel in batch mode, with a default of 3.

There is also -s and --series to download an entire series, -n and --name to set the output file name, -r and --replay for quick replay downloads, --password for a protected live room, -P and --proxy for an http, https or socks5 proxy, and -a and --autoMerge to merge the downloaded segments automatically.

The support table in the README records what is not there. Neither videos nor live streams support resuming a broken download. The FAQ addresses this directly: if a series download is interrupted by network fluctuation, there is no resume, so the work restarts. For a long lecture over an unstable connection that is a real limitation.

Building from source needs Go 1.27.1

The releases page hosts prebuilt binaries named ks.exe for Windows and ks for other platforms, and downloading one is the shortest path to trying the tool. The README also documents building from source, which requires Go 1.27.1 or a compatible newer version.

On Windows:

go build -o ks.exe -trimpath -ldflags "-s -w -buildid=" ks.go

On Linux:

go build -o ks -trimpath -ldflags "-s -w -buildid=" ks.go

The flags are the same in both, and the trimpath and linker options are there to strip build paths and symbols and drop the build identifier, which is what you want in a binary you redistribute.

The go.mod file matches the README and pins the module path to github.com/yliu7949/KouShare-dl with the same Go 1.27.1 directive. The direct dependencies are chromedp/cdproto and chromedp/chromedp for browser automation, fatih/color for coloured terminal output, and spf13/cobra for the command structure, with the usual set of indirect dependencies behind them.

The tool is a single binary with a single main file at the root, so running it is a matter of changing into its directory and calling it, which is exactly what the README's usage walkthrough does with cd and ks version on a Windows machine, expecting the version banner in response.

For the slides, there is an experimental PDF optimisation step that expects qpdf, and the path to its binary is set with --qpdf-bin, which has no short form.

The support table is a scope contract, not a feature list

The README includes a table describing which capabilities apply to which content type, and reading it carefully is the fastest way to know whether the tool fits your case.

For videos, series download, single download and quality selection are supported, resume is not, and paid products are only partially supported. For live streams, there is no series concept, single download and quality selection are supported, resume is not, and paid live products do not exist as a category. For slides, series and single download are supported, resume is not, quality does not apply, and paid products are supported.

Two rows in that table decide adoption. Paid video support is partial, which the feature list explains: the tool can download paid videos that the current account has legitimately bought and that are still within their validity period, and it cannot download unpurchased paid videos. The other is that slides are fully supported for paid products while videos are only partially so, which reflects the fact that the slide deck is a separate artefact from the recording.

The features list also names the live capabilities: recording a live room on a schedule, and downloading a replay where a standard replay address or a formal video id is available. That last clause is a constraint, since a replay without one of those identifiers is not reachable by the tool.

The README is explicit that it does not bypass the site's human verification, payment or any other access control, and that for restricted content the intended flow is to complete verification and login in the browser and then import your own token.

Where KouShare-dl is the wrong tool

The first case is straightforward: content you have not paid for. The tool states it cannot download unpurchased paid videos and does not bypass the verification or payment checks, and that boundary is a feature of the design rather than a missing feature. If your need is to get at material you have no entitlement to, this is the wrong tool and the wrong intent.

The second case is reliability. With no resume support anywhere in the table, a long download on a flaky link restarts from the beginning, and the FAQ offers no workaround for that. If your connections are unstable or your lectures are many hours long, the manual effort of restarting outweighs what the tool saves.

The third case is maintenance. The published releases are v0.9.0 on 2022-10-16, v0.9.1 on 2023-06-28 and v0.9.2 on 2023-07-25, so the last tagged build is from 2023, while the last push to main was on 2026-10-03. The code is being changed but there is no release cadence, which means the binary you download and the source you read may differ, and any script you write against the command surface has to be checked against the version you actually have.

The alternative approach is a generic HLS downloader pointed at the manifest URL, which works for any stream the site's player can play and needs no account, but it gives you none of the site specific parts: no id to URL resolution, no metadata, no slides, no live scheduling, no series handling. The difference in approach is that KouShare-dl encodes knowledge of one site's API and its conventions, and that knowledge is exactly what ages.

The licence deserves a note too. The project is released under the Unlicense, and the repository also carries a THIRD-PARTY-LICENSES directory, which is where the licences of the dependencies such as cobra and chromedp live. Keeping that directory intact when you redistribute a build is the practical obligation.

Editorial conclusion

Adopt KouShare-dl when you own or have paid for Koushare content and want it on disk for offline study, and skip it when you need content you have not bought, when you need resumable downloads, or when you need a maintained tool rather than a working one. Verify three things before you rely on it: that the site API it calls still returns what it expects, since the last release was v0.9.2 on 2023-07-25 even though the last push to main was on 2026-10-03, that the command and flag set still matches your script, because the flag table in the README lists overlapping shorthands such as two different -p entries and two different -q entries, and that the credential file at .ks.token is protected, since the tool keeps your access and refresh tokens on disk. The licence is the Unlicense, so the code carries no restrictions for reuse.

Frequently asked questions

Official sources

1. Issues
2. License: Unlicense
3. README
4. Releases
5. yliu7949/KouShare-dl on GitHub