Taluvi Media

Roadmap

Taluvi Media is a broadcast platform for labels: radio stations first, then audio and video on demand, live sound and live picture. This is what is built and what comes next.

The order is the order of building. A stage stands after the stages it is built on, and each says why it stands where it does. There are no dates here.

  • Shipped1
  • In development2
  • Planned8
  • Later2

  1. Foundation: customers, catalog, stations

    Shipped

    A customer holds a catalog and operates stations. A station is on air around the clock with no process behind it: what plays is a pure function of the clock, the library and the rotation, and listeners fetch segments that were cut once.

    • Multi-tenant from the first table: every row and every stored object carries its customer, and every query names it.
    • Sign-in, organisations and roles through a shared identity service; a program acts for a customer with an API key.
    • Catalog of titles with their sheets (ISRC, credits, tempo, key). Masters upload in parts; the original is kept and never replaced.
    • Mastering in Rust, native and in WebAssembly: loudness and true peak (BS.1770), corrective EQ, width, look-ahead limiter.
    • Ingest in a container started per job, which holds a token for that job and nothing else: AAC-LC at 48 kHz in six-second MPEG-TS segments.
    • Stations as HLS: a schedule computed from the clock, rotations that change at an item boundary, station idents.
    • Listener report from playlist requests, without storing an address; every play logged with the operator at that moment.

  2. Usage per customer

    Planned

    What each customer used: seconds delivered, data stored, time on air, time spent processing. The base for billing, and for knowing what a feature costs to run.

    • Delivered seconds and bytes, counted where a segment is handed out, without holding the request up.
    • Stored bytes per customer per day, from the sizes written down when an object is stored.
    • A day is closed into a table of record and does not change afterwards; a correction is a new row.
    • Usage is kept apart from the play report: plays say which title was heard, usage says how much was delivered.
    • An API route and a console page for the customer; streaming is counted in seconds, storage by size.

    Why here

    First, because every stage after it delivers something that has to be counted, and the stations that run today are already there to count. Adding a meter to a finished feature is harder than building the feature on one.

    Built on 00 Foundation

  3. Signed playback and audio on demand

    In development

    A listener chooses a title and plays it from the start. A title is either public, or plays only through addresses signed for a short time.

    • A playlist per title over the existing segments, first to last, marked as ended so a player can seek and pause.
    • Addresses signed over customer, title, version and expiry; one that has run out or was made for another title opens nothing.
    • Per title: public or not, download or not, and a release date before which it does not play on demand.
    • Plays counted per title once enough of it was heard, and reported even where a sheet is incomplete.

    Why here

    Before video and before the player, because the signature and the rule for who may play are the same for everything played on demand. It needs no new media work: a title on demand is one more playlist over the segments a station already plays.

    Built on 00 Foundation01 Usage per customer

  4. The player

    Planned

    One player of our own, as a web component with no framework inside: embeddable on any page and usable inside another application.

    • HLS through Media Source Extensions, and natively where the browser plays HLS itself.
    • Asks the API for an address, renews it before it runs out, and reports what was played.
    • One package for sound, picture and live, so access and reporting are written once.

    Why here

    After signed playback, because renewing a signed address while it plays is the part no stock player does. Before video and live, because both are played through it.

    Built on 02 Signed playback and audio on demand

  5. Media library: images and video masters

    Planned

    An asset is an image or a video that belongs to a customer, separate from a title, with a sheet of its own.

    • The asset model: sheet, rights holder, accepted formats, who may upload and delete.
    • One upload flow for masters and assets, with limits per kind; video masters of several gigabytes.
    • Image variants and delivery; a Media tab in the console.

    Why here

    Before video on demand, because a video has to be something in the catalog before it can be streamed. The upload in parts exists for audio masters and is widened, not copied.

    Built on 00 Foundation

  6. Video on demand

    Planned

    A customer uploads a video; it plays for anyone, or only through signed addresses, in our player.

    • The master arrives encoded and stays in our storage. Streaming starts on a managed video service behind our API.
    • A player is given its address by our API and never by the provider, so replacing the provider changes one place.
    • Public or signed playback, captions, poster frame and duration.
    • A video carries a reference of the customer’s own, and usage is reported per reference, so a customer can pass costs on.
    • First customer: Plinken, our own product, moves its video streaming onto the platform.

    Why here

    Here, because it is the sum of the four stages before it: an asset, a signed address, the player and a meter. What is new is only the streaming itself.

    Built on 01 Usage per customer02 Signed playback and audio on demand03 The player04 Media library

  7. Releases, playlists and share links

    Planned

    What people play is an album in its order, or a selection someone put together. What a label hands out is a link it can take back.

    • A release with its cover, kind, date, UPC, catalogue number and P-line; a playlist as any other selection.
    • Each title stays a stream of its own: starting the seventh does not fetch the six before it.
    • Share links a customer makes per audience and revokes one by one; an embed that carries a share link, not an address.
    • A music video names its title, so its plays reach the same report as the recording’s.

    Why here

    After on demand works for one title and one video, because a release is a list of things that each already play on their own.

    Built on 02 Signed playback and audio on demand03 The player05 Video on demand

  8. Live sound on a station

    In development

    A DJ or presenter takes a station over for a set. Listeners stay on the station’s address, and the station returns to its schedule afterwards.

    • A DJ desk in the browser with its audio engine in Rust and WebAssembly: decks, mixer, limiter, program and headset outputs.
    • Encoded AAC packed into MPEG-TS segments at the source and handed in with a token good for that session.
    • The playlist changes over to the live segments at a segment boundary and back when the set ends or goes silent, without the sequence a player follows ever jumping.
    • The desk says what it plays, so a live set is in the play report like any other hour.
    • Other sources that can make segments the same way; first among them a Plinken space.

    Why here

    It needs nothing from the on-demand stages, only the station and the meter. The source makes the station’s own segments, so there is no ingest server and nothing to transcode.

    Built on 00 Foundation01 Usage per customer

  9. Transitions between songs

    Planned

    From a plain crossfade up to mixing on the beat, on a station that still has no process behind it.

    • A crossfade is made once per pair of songs, kept, and placed between them in the stream.
    • When the station deals its next songs, neighbours in key and close tempos are preferred.
    • Beat positions per title, and time-stretching without a change of pitch, for mixing on the beat.

    Why here

    After live sound, because both change what the schedule has to count: a stretch of the timeline that is not one item after another.

    Built on 00 Foundation07 Live sound on a station

  10. Live picture and channels

    Planned

    A VJ or performer sends live video to the platform for distribution, from OBS, a hardware encoder or a browser. A channel is where a customer’s broadcasts live.

    • A live input belongs to a customer; its publish address and key come from our API and can be replaced.
    • WHIP, SRT and RTMPS in, starting on managed live ingest behind our API.
    • Everything a person can do to go live, a program can do with an API key.
    • A broadcast can be recorded and is then a video on demand of the same customer.
    • A channel with a schedule over prepared videos, worked out from the clock the way a station’s is.

    Why here

    After video on demand, because it reuses its player, access rule and meter, and because a recorded broadcast becomes a video on demand. It is independent of live sound: different source, different machinery.

    Built on 01 Usage per customer03 The player05 Video on demand

  11. Billing

    Planned

    A price list, invoices and limits, made from the usage table.

    • Prices per second streamed and per size stored.
    • Invoices per customer from closed days; limits, and what happens above them.
    • For us: each customer’s usage beside what the same period cost to deliver.

    Why here

    After the features that produce usage, because prices are set against what delivering them really cost, and that is only known once they have run.

    Built on 01 Usage per customer05 Video on demand07 Live sound on a station09 Live picture and channels

  12. Machines of our own

    Later

    Delivery stays at the edge. Machines come only for what the edge cannot take in or charges for by the minute.

    • Ingest for sources that need a public address and UDP: SRT and RTMP of our own.
    • Encoding video ourselves into HLS in our own storage, replacing the managed service as the deliverer.
    • Machines started for a broadcast and removed after it; each holds a token for its job and no access of its own.
    • One endless stream per station for older players and directories that do not play HLS.

    Why here

    Last of the platform work, because the usage and cost figures say when it pays, and because nothing before it needs a machine.

    Built on 01 Usage per customer09 Live picture and channels10 Billing

  13. Further out

    Later

    Ideas that the stages above are kept open for. None is scheduled.

    • A station’s own host: links between songs written and spoken ahead of their place in the schedule, and marked as synthetic.
    • A channel run by a program: it makes and schedules videos ahead and goes live only for what cannot be made ahead.
    • Listeners who sign in and are given access one by one.

    Built on 08 Transitions between songs09 Live picture and channels

Last gone through on 13 November 2026. Taluvi Media is owned and operated by Taluvi OÜ.