Education
keeplearnin: Learning Platform for Organisations and Instructors
Our learning product that brings courses, live classes, mentoring, certificates and corporate training into one platform. Built on MicroFrame; not live yet.
What the platform does
Status: in development, not yet live.
Fiyola is an OTT platform built around vertical short-form video and drama/series content. It targets the mobile-first audience segment existing horizontal platforms have yet to fully address. It gives an established content platform a vertical channel for reaching that audience.
The platform is designed to integrate with broadcasting infrastructure already in place — unified subscriber management and SSO mean it extends an existing content ecosystem rather than fragmenting it. The streaming pipeline covering content management, encoding, distribution and playback ships as part of the platform, so it can be deployed at scale without being built first.
Capabilities
Fiyola is built on MicroFrame and not yet live. The list below is the capability set it is built for.
- Unified subscriber management and SSO with existing content ecosystems
- A vertical channel aimed at younger viewers, designed to open a new revenue line for the platform that adopts it
- Streaming infrastructure to adopt instead of building it from scratch
- Horizontal format flexibility for later platform and catalogue growth
- End-to-end streaming pipeline — ingestion, adaptive bitrate encoding, CDN distribution, playback
- Native iOS and Android apps with a purpose-built vertical video player
How it is built
- Native mobile applications with a custom player tuned for vertical playback
- .NET backend microservices for content management and user APIs
- FFmpeg-based adaptive bitrate encoding pipeline for portrait format
- CDN-backed delivery designed for low startup latency
- DRM-protected offline download
The sections below describe the architecture and the reasoning behind it, as designed.
Vertical is a different encoding ladder, not a rotated one
A portrait rendition ladder cannot be a landscape ladder turned sideways. The pixel budget is distributed differently for the same perceived quality, the top rungs of a 16:9 ladder spend bitrate on a width that a phone in portrait never shows, and the bottom rung matters far more than it does in long-form because it is what a viewer on a weak mobile connection actually gets. The ladder is defined against portrait source from the start.
Segment length is the trade-off that sits next to it: shorter segments mean faster startup and quicker adaptation when the network changes, at the cost of more requests and more per-segment overhead across the whole catalogue. Short-form pulls that decision toward the shorter end, which is the opposite of where a film-length VOD service lands.
Short-form makes startup time the dominant metric
In long-form, a second of startup amortizes over an hour of watching. In a feed where the viewer swipes every few seconds, startup latency is the experience — it is paid on every item, not once per session. The player is therefore designed to prefetch and pre-buffer the next items while the current one plays, so a swipe resolves against data already on the device.
That is a budget decision, not a free win: prefetching spends the viewer’s data allowance and the device’s bandwidth on content that may never be watched. So the prefetch depth is bounded, and in-flight prefetch for items the viewer has swiped past is cancelled rather than allowed to complete.
Why native, and why a custom player
Three things a swipe-driven vertical feed depends on are only properly available natively: the platform’s hardware decoders, precise control over buffering and prefetch behaviour, and the platform DRM stack. The last of those is decisive on its own — the iOS and Android DRM systems are not interchangeable, and neither is optional if the content is licensed. A general-purpose embedded player gives up the buffer control that the prefetch strategy depends on, which is the reason the player is purpose-built rather than adopted.
DRM also reaches back into the backend. Offline download means a persistent licence with its own lifetime, distinct from a playback licence, and both have to be tied to the subscriber’s current entitlement. Licence issuance is where access is actually enforced: a CDN URL is a location, not an access control, so entitlement is resolved server-side at licence request rather than inferred from whether a client could reach a file.
Adopting an existing subscriber base rather than owning one
The platform authenticates through the incumbent’s SSO and reads entitlement from it. The design constraint that follows is a deliberate one: the vertical product must not become a second source of truth for who is a subscriber and what they are entitled to. So subscriber identity and entitlement stay external, and the platform owns only content, playback and engagement data.
The boundary is drawn there specifically so adoption does not require a subscriber migration — a migration would be the largest and riskiest part of the work, and it is the part that adds nothing to the product.
Ingestion is a job graph, and encoding is the expensive node
The pipeline runs ingest, then a transcode fan-out per rendition, then packaging, manifest generation and CDN publication. Each step is a retryable job keyed to the asset and the specific rendition, so a rendition that fails is re-run on its own rather than triggering a re-encode of the whole asset — which matters because encoding is where the time and the compute cost are.
Encoding load is bursty by nature: a catalogue drop is a spike and the steady state between drops is close to nothing. The transcode tier is therefore separated from the API tier and scaled independently, so encoding capacity can follow that curve without the request-serving path being sized for it.
Packaging produces more than one output, because the two mobile platforms’ players and DRM systems expect different segmented formats. That is a fact of the ecosystem rather than a choice, and it is absorbed in the pipeline so that neither the content model nor the apps have to carry it.
The horizontal door is kept open by not assuming portrait
Vertical is the first profile, not a property baked into the schema. Aspect ratio, rendition ladder and player layout are attributes of the asset and its delivery profile, so extending into horizontal VOD later is adding a profile rather than migrating a content model — which is the concrete form of the flexibility the platform claims, and it costs nothing except the discipline of not hardcoding an assumption that was true on day one.