Skip to content

Muxed adoption honors the requested height - #42

Merged
Linuxuser67 merged 1 commit into
mainfrom
muxed-height-pick
Sep 18, 2026
Merged

Linuxuser67 merged 1 commit into
mainfrom
muxed-height-pick

Conversation

@Linuxuser67

Copy link
Copy Markdown
Owner

x.com downloads landed on the lowest quality in every path: with no pin the muxed adoption took the crate's best_audio_video_format, which is first-in-extractor-order (x.com lists ascending) and ignores the quality cap entirely — and a stale pin degraded into the same fallback.

select_muxed_format replaces it: smallest muxed height at or above the cap, else the tallest (same semantics as the HLS preset). Only directly fetchable files qualify, so DRM/link-less entries can't shadow a playable one. Together with the dialog writing the picked height into quality, a dropped pin now degrades to the chosen height instead of the lowest listing.

Tests: height-cap matrix (best/1080p/720p/480p over ascending muxed listings) plus updated adopt/stale-pin expectations; negative-controlled against the old first-in-order pick. 203 passing, clippy clean.

@Linuxuser67
Linuxuser67 merged commit 6fc6beb into main Sep 18, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant