Repository navigation
[Feature]: Support BiliBili Cookie injection to unlock 1080p/4K streams and bypass WAF risk control (-352) #287
Description
Activity
- addedarea: backendTypeType-Server API or extractionTypeType-Server API or extractionarea: self-hostingSelf-hosting, installation, updates, and deployment stackSelf-hosting, installation, updates, and deployment stackpriority: mediumMedium priorityMedium priority
on Sep 19, 2026 It's already in beta, so if u can test it, it'd be cool to get some feedback. Otherwise, just wait for the next release ;p (I don't have a Bilibili account, so I can't test it myself! :0)
Or u can test it directly on the beta, Beta Website Public Instance
Aquarius-Situla commented
on Sep 26, 2026 ContributorAuthorMore actionsHi @Priveetee, thanks for the update! We tested the Bilibili session feature on our self-hosted beta instance (
1.8.2-beta.324web /1.8.2-dev.937server) with a logged-in Bilibili account:-
QR Code Login & Session Encryption:
- The QR code generation, scanning via the official Bilibili mobile app, and encrypted session storage (
BILIBILI_SESSION_ENCRYPTION_KEY) in PostgreSQL work great! - Extraction requests successfully authenticate and fetch high-resolution DASH stream representations (1080p, 720p, etc.) without triggering WAF risk control
-352.
- The QR code generation, scanning via the official Bilibili mobile app, and encrypted session storage (
-
Observations & Feedback:
- The central stack repository (
TypeType-Video/TypeType).env.exampleanddocker-compose.ymlcurrently don't exposeBILIBILI_SESSION_ENCRYPTION_KEYtotypetype-server. I have opened a PR to add it to the environment templates so self-hosters can easily configure it. - On the frontend player side, we noticed two minor UX issues during DASH playback (a false-positive "Original audio unavailable" toast due to Bilibili's single-language audio tracks, and representation height matching in the quality selector). We are opening separate PRs in
TypeType-Frontendto address these.
- The central stack repository (
Thanks again for the great work on Bilibili support!
Reacted by Tax_Tux-
Aquarius-Situla commented
on Sep 26, 2026 ContributorAuthorMore actionsJust a quick follow-up: we opened the following PRs addressing the issues we identified so far:
- Central Stack: feat: add BILIBILI_SESSION_ENCRYPTION_KEY to compose and environment templates #291 (adds
BILIBILI_SESSION_ENCRYPTION_KEYto environment and compose templates) - Frontend: fix: silence original audio unavailable toast on single-language streams TypeType-Frontend#33 (silences false-positive "Original audio unavailable" toast on single-language streams)
- Frontend: fix: improve resolution height extraction and matching in QualitySelector and PlayerDefaults TypeType-Frontend#34 (improves resolution height extraction and matching in QualitySelector and PlayerDefaults)
Please note that these PRs only resolve some of the known surface issues (toast spam, compose envs, and height matching). Based on our testing results on the self-hosted beta instance, the high-resolution playback issues don't seem to be completely resolved yet (playback may still feel blurry or struggle to consistently switch/stick to higher DASH representations).
We will continue testing and investigating further, but wanted to get these initial fixes in first so other maintainers can build on them.
- Central Stack: feat: add BILIBILI_SESSION_ENCRYPTION_KEY to compose and environment templates #291 (adds
Thanks again for the thorough testing and for opening PRs #291, #33, and #34. Could you retest BiliBili playback on TypeType 1.9.0 and let me know whether higher-resolution streams now switch consistently and stay sharp? If playback still looks blurry, details about the selected quality and what you actually see would be really helpful. I’ll keep this issue open while we investigate.
Aquarius-Situla commented
on Sep 30, 2026 ContributorAuthorMore actionsHi @Priveetee! I retested Bilibili playback on TypeType 1.9.0 on my self-hosted instance with an authenticated Bilibili account.
On stock 1.9.0, playback was indeed locked to 480p, and the Quality selector wasn't showing up in the player settings.
Looking into
bilibili-manifest.ts, the cause seems to be:videoScore()explicitly gave 480p the top score/priority.buildBilibiliDashManifest()only picked the first video candidate (videos[0]) when constructing the DASH manifest, creating an AdaptationSet with only one single representation.- Because only a single representation was in the MPD, Dash.js had no alternative bitrates/resolutions to switch to, and the player automatically hid the Quality menu since only 1 quality was available.
I refactored
bilibili-manifest.tsto include all available representations in descending order of resolution (1080p, 720p, 480p, 360p) grouped by codec family, and tested it on my deployment. Videos now start in full 1080p right away, and all resolutions appear and switch cleanly in the player's Quality menu.I have opened a PR with the fix and test cases here:
TypeType-Video/TypeType-Frontend#36Reacted by Tax_Tux- addedarea: frontendFrontend web appFrontend web appbugSomething isn't workingSomething isn't workingand removedfeature requestNew feature or requestNew feature or request
on Sep 30, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
Type of request
New feature
What problem would this solve?
Currently, watching BiliBili videos on TypeType suffers from two major limitations:
Low Video Quality (Capped at 360p / 480p):
Unauthenticated BiliBili video stream requests are restricted to 360p or 480p by Bilibili's official guest policy (
try_look=1). There is currently no way to supply account credentials or cookies, making HD/4K playback impossible even for users with Bilibili accounts or VIP status.Datacenter IP Risk Control (
-352):When hosting TypeType on cloud VPS / datacenter server IPs (ByteVirt, Hetzner, AWS, etc.), Bilibili's anti-scraping WAF frequently intercepts extraction requests with:
{"code": -352, "message": "风控校验失败"}This causes channel feeds and search results to return 0 items.
What would you like to see?
I would like to see a mechanism to inject BiliBili account cookies into TypeType, similar to how YouTube authentication is handled.
The underlying PipePipe / NewPipeExtractor engine already supports BiliBili tokens natively:
Suggested implementation options:
Allow configuring
BILIBILI_COOKIE(orSESSDATA,bili_jct,buvid3) indocker-compose.yml. On server boot, TypeType-Server can pass this to:Allow instance administrators to paste the cookie string under
/admin/settings.Similar to YouTube Remote Browser, provide a QR code login flow to capture and store cookies automatically.
Benefits:
-352for self-hosted instances on cloud VPS.Area
Token / remote login