Moving From Livepeer Studio: Webhooks, Playback Gates, and URL Import
Teams moving from Livepeer Studio told us two things take the longest to port: VOD and webhooks. We read Studio’s source (it is open) and went through every webhook event, payload field, and playback-policy option it offers, then compared each one against FrameWorks. This release closes the gaps that would have forced a Studio integration to change its logic.
The goal was narrow: a team should be able to point its existing webhook receiver and playback gate at FrameWorks, change the parts that are named differently, and keep the logic behind them.
A 204 used to lock out every viewer
Section titled “A 204 used to lock out every viewer”The clearest example came from the playback gate. A webhook playback policy asks your server whether a
viewer may watch: FrameWorks sends the request, and your answer decides. Studio treats any 2xx as
“allow”. We only accepted 200.
That difference is invisible until you migrate. Plenty of access endpoints answer 204 No Content,
because there is nothing to say beyond yes. Pointed at FrameWorks, such an endpoint denied every viewer
of every gated stream, and nothing in its own logs looked wrong: it had answered yes each time. Any 2xx
now allows.
The same comparison turned up two smaller gaps in the gate. A policy can now store a small JSON context
that is sent back with every access request, which Studio calls webhookContext. It lets your endpoint
know which course or product a video belongs to without keeping its own lookup table. And a policy can
list the websites allowed to embed the content.
What an origin check can and cannot stop
Section titled “What an origin check can and cannot stop”Allowed origins stop a player copied onto someone else’s site. The check runs twice: when the player
looks up the stream, and again when the media session opens on the edge. For the second check, our
MistServer build now passes each viewer’s Origin and Referer to the access decision, and requests
from a different site get a separate session.
It is not DRM. A client that is not a browser can send any Origin header it likes. RTMP and SRT players
send no origin at all, so they are refused unless the list allows every site. Edges running a MistServer
build from before this release cannot report the origin, so origin-restricted content does not play from
them until they update. If you run your own edges, update them before you turn this on.
Events carry what Studio events carried
Section titled “Events carry what Studio events carried”Studio’s stream webhooks carry the stream’s playback ID, and ours now do too. Recordings now send an event when capture starts and another when it stops, the two points Studio reports.
One difference is deliberate. Clip, recording, and upload events do not carry a playback ID. A playback ID can be rotated, so a copy inside an event that is retried or replayed hours later can already be out of date. Key your records on the artifact ID and look up the current playback ID when you publish the video.
The migration guide maps each Studio event and field to its FrameWorks equivalent, including the one habit that does not carry over directly: how a Studio player passes the gate’s key.
Import a video from a URL
Section titled “Import a video from a URL”Studio lets you create an asset from a URL, and so does FrameWorks now. You pass a public link and get the asset and its playback ID back right away, with no upload step. The file is read from the source server and processed like any upload, with the same upload events, so a receiver that already handles uploads needs no new code.
The fetch connects only to public addresses, checked again on every connection and redirect, so an import URL cannot be used to reach a private network. The source server has to support range requests. For IPFS or Arweave content, pass a public gateway’s https link. The VOD guide has the details.
What stays different
Section titled “What stays different”Webhook signing uses Standard Webhooks rather than Studio’s Livepeer-Signature
header, so a receiver needs a new verification step, which existing libraries cover. Retries run for
about three days instead of one. There is no Task API, no per-stream transcode profiles, and no
creatorId or userTags on streams yet. The
gap list in the migration guide
tracks what is still missing, and the playback access guide
covers webhook policies and allowed origins.