---
name: bilibili-authorized-download
description: Download and verify a user-specified Bilibili video that is public or playable through the user's existing signed-in session, including DASH .m4s track discovery and lossless muxing. Do not use to bypass membership, regional, paywall, or DRM restrictions.
---

# Bilibili Authorized Download

Deliver a normal playable media file while preserving the site's access boundary.

## Access boundary

- Start with a normal extractor or public API. If it exposes only a preview, do not treat that as the full video.
- Use an existing signed-in browser session only when the requested page can already play the full work for the user. Confirm this from visible player state, such as the full duration.
- Do not inspect or export cookies, local storage, passwords, Widevine keys, or license responses.
- Stop if access would require bypassing membership, region controls, a paywall, or DRM. Treat `pssh`, `tenc`, `senc`, `encv`, `enca`, missing-key errors, or decryption errors as DRM signals.
- Signed CDN URLs discovered in an authorized player are temporary capability URLs. Do not preserve them in deliverables, project notes, or logs longer than the active task.

## Discover DASH tracks

When browser session state is necessary, use the available Chrome/browser-control skill and follow its instructions.

1. Start playback long enough for media requests to appear, then inventory observed page assets.
2. In runtimes that expose `pageAssets`, Bilibili `.m4s` requests may be classified as `other`, so `pageAssets.bundle()` can reject them. In that case, filter the inventory by `.m4s` URL or MP4 content instead of retrying an unsupported bundle kind. Other runtimes must use only their documented asset/network APIs; do not invent a `pageAssets` method.
3. Identify tracks from the media itself, not from filenames or size alone:
   - `hdlr` value `vide` plus `hev1`, `hvc1`, `avc1`, or `av01` identifies a video candidate.
   - `hdlr` value `soun` plus `mp4a` identifies an AAC audio candidate.
   - Use `ffprobe` when available; a small range probe of the MP4 header is a fallback.
4. Prefer the highest-quality clear video track and a compatible clear audio track that the current account is authorized to play.

## Download and package

- Put temporary tools and separate tracks under the task's work directory; put only the completed user-facing file in its output directory.
- Stream signed URLs promptly because they expire. Use resumable transfer when practical, and verify downloaded byte counts against `Content-Length` when present.
- Use an existing FFmpeg/ffprobe installation when available. If absent, use a reviewed portable build under the work directory rather than changing the system installation.
- Losslessly mux separate tracks with stream copy. Use [scripts/mux_verify.ps1](scripts/mux_verify.ps1) for a deterministic Windows workflow:

```powershell
./scripts/mux_verify.ps1 -Video video.m4s -Audio audio.m4s -Output final.mp4 -Ffmpeg ffmpeg.exe -Ffprobe ffprobe.exe
```

For macOS/Linux or Windows with Python 3.10+, use the cross-platform helper from this skill directory:

```bash
python3 scripts/mux_verify.py --video video.m4s --audio audio.m4s --output final.mp4
```

It accepts local clear tracks only, verifies codecs, durations, and decoding at the start/middle/end, and publishes the file only after checks pass. It refuses existing outputs and does not download anything. The final output filesystem must support hard links (for example APFS or NTFS); if it does not, use a supported local output directory and copy the verified file through the normal file workflow.

## Validate before delivery

- Confirm one video stream, one audio stream, expected codecs, and nearly equal track durations.
- Decode short samples near the start, midpoint, and end; do not rely only on file size or container metadata.
- Report the final path, size, duration, video/audio specifications, and any relevant access caveat.