Think of it like this:

• Asset = Your content files stored in cloud storage (Azure Storage, S3). It's the "what."
• Streaming Locator = A published URL that viewers use to access the asset. It's the "how."

One asset can have multiple streaming locators with different access policies (public, DRM-protected, geo-restricted, etc.).

No. A single Streaming Endpoint can serve thousands of assets. Think of it as your origin server infrastructure.

You might create multiple endpoints for:

• Different geographic regions (US endpoint, EU endpoint)
• Different customer tiers (free vs. premium)
• Different content types (live vs. VOD)

MK.IO is cloud-agnostic at the control plane level. You can:

• Store assets in Azure Storage, AWS S3, or GCP Cloud Storage
• Run streaming endpoints in any region of any cloud
• Mix and match clouds for different workloads
• Migrate between clouds without re-encoding content

Your choice of cloud doesn't lock you into a specific provider's ecosystem.

Transforms are templates, Jobs are executions:

• Transform: "Encode to 1080p with ABR ladder" (reusable definition)
• Job: "Apply that transform to this specific asset" (one-time execution)

Create a transform once, then submit many jobs using it. This keeps encoding settings consistent across your library.

MK.IO sits above cloud primitives (like AWS MediaLive/MediaPackage or Azure Media Services) and provides:

• Multi-cloud abstraction: One API works across Azure, AWS, GCP
• Opinionated workflows: Best practices baked in, not DIY
• Advanced features: AI transcription, DRM, analytics out-of-the-box
• Managed operations: We handle scaling, monitoring, updates

Trade-off: Less control over low-level infrastructure, but faster time-to-market and lower operational burden.