place.stream.media.track

A track for a video stream, either part of the source or a custom additional track. One of: video, audio, subtitles.

Repository @stream.place did:plc:rbvrr34edl5ddpuwcubjiost not from the namespace authority
Details · record, key tid
Kindrecord
Record keytid
Authoritymedia.stream.place
Indexed

Record

record · key tid

Properties

If this is a derived track like a transcode or a transcript, what was the parent track?

video

string · at-uri

If this is a derived track like a transcode or a transcript, what was the source place.stream.video?

#commonMetadata

object

Metadata common to all media types. Contains subobjects for other media types.

Properties

durationMs

integer

duration of this track in milliseconds

language

string

IETF BCP 47 language tag corresponding to the content of this track

#trackView

object

Properties

cid

requiredstring · cid

record

requiredunknown

uri

requiredstring · at-uri

Similar lexicons

semantic match

Lexicons whose schemas describe something close to this one. Check them before publishing a new one that overlaps.

  • place.stream.media.defs

    not from the namespace authority

    A track backed by a MUXL container

  • Some audiovisual content.

  • place.stream.segment

    record not from the namespace authority

    Media file representing a segment of a livestream

  • Bluvy Tube-specific metadata for a published video, written to the creator's own repo alongside the app.bsky.feed.post record that actually carries the video (via app.bsky.embed.video). Not required or validated by the PDS or any other AT Protocol app — Bluvy Tube reads this back itself to render an owner-editable title/description/language overlay on top of the plain post text. Written by App\Service\VideoPublicationProcessor (native uploads) and rewritten by App\Service\PdsMetadataSyncService

  • place.stream.media.viewCount

    record not from the namespace authority

    A streamplace node's report of view counts for one place.stream.video over a closed time window. Published in the reporting node's server repo (not the streamer's), so a video served by multiple nodes accumulates multiple records — consumers are expected to sum across trusted reporters. The rkey is conventionally `<windowStart-as-tid>-<video-rkey>` so re-running the aggregator over the same window is idempotent. Counts represent the reporting node's best effort given the data it has; the `tracks