Release v1.8.4: smoother playback for heavy sources, and tags for upload tokens - #753
Merged
Merged
Conversation
The player always started on the source file. A 3440x1440 AV1 clip at 60 fps is fine on a GPU with an AV1 decoder, but a browser without one falls back to software decoding, which cannot keep up: the audio plays on while the picture freezes, then skips ahead out of sync. Nothing buffers, so the stall-based downgrade never notices, and the 1080p H.264 transcode sitting next to it plays perfectly. The server now reports each video's RFC 6381 codec string and bitrate, built from the ffprobe data it already stores. Before mounting, the player asks navigator.mediaCapabilities about each source and starts on the best one the device decodes in hardware, else the best it decodes smoothly, else the source as before. Every quality stays in the menu. Without a codec (older rows the builder cannot describe, VP9) or without the Media Capabilities API (plain-http instances), nothing changes. The editor still always opens the uncut original.
fix: start on a transcode when the source will not play smoothly
A tool could send tag_ids on an upload but had no way to find out which
tags exist. /api/tags does not recognise upload tokens, so it answers them
as an anonymous visitor: only tags already on a public video. A tag
created a moment ago is on nothing yet, and it is exactly the one somebody
setting up an upload has come to choose.
/api/upload/token/options now returns tags as {id, name, color}, sorted
by name. It keeps /api/tags' rule about who sees what. A token whose
account can view private media gets every tag. Any other token gets the
tags on something public, plus the tags on nothing at all, since an unused
tag gives away nothing about private media. The only tags left out are
the ones that appear solely on private media, which /api/tags hides from
the same accounts. Images count as well as videos.
Documented in docs/UploadTokens.md, including that tag_ids is still not
checked against the list.
feat: list tags in the upload-token options
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Everything on
developsince v1.8.3 (PRs #749 and #752). No database migrations.Playback
VideoInfo.json()now includescodec(an RFC 6381 string) andbitrate, built from the stored ffprobe data by the newmedia_codecs.pynavigator.mediaCapabilities.decodingInfo()about each quality and starts on the best one decoded in hardware, then the best one decoded smoothly, then the source. Every quality stays in the menuUpload tokens
GET /api/upload/token/optionsnow lists tags, so a tool like Firesync can offer a tag picker fortag_ids(feat: list tags in the upload-token options #752)/api/tagsdocs/UploadTokens.mdVersion
🤖 Generated with Claude Code