Backend Development 20 min read

Design and Implementation of Bilibili OGV Content Production System

The article details Bilibili’s OGV content production system, explaining why the traditional UGC workflow is insufficient, describing a supply‑chain‑style work‑order architecture with demand, plan and task entities, flexible key‑value data storage, input validation, a state‑machine‑driven task lifecycle, phased rollout, automation, and future extensions.

Bilibili Tech
Bilibili Tech
Bilibili Tech
Design and Implementation of Bilibili OGV Content Production System

This document explains the motivation, business scenarios, architectural design, and implementation details of the OGV (Original Generated Video) content production system at Bilibili.

Why build this system? The existing C‑end content creation workflow (inspiration → material editing → upload → submission) is insufficient for OGV, which requires more complex production steps, richer metadata, and tighter collaboration between multiple internal teams.

C‑end content creation overview describes the typical UGC workflow: inspiration → material editing → upload → submission, followed by internal processing before the content reaches end users.

UGC vs. OGV highlights that UGC is a single‑video, lightweight creation process, while OGV resembles a series or drama with multiple episodes, richer media assets, community scores, and episode lists. Consequently, OGV cannot be produced using the same lightweight tools as UGC.

Problem pain points include fragmented personnel collaboration, many manual steps, low production efficiency, diverse input information, and complex, non‑scalable processes.

Proposed solution adopts a supply‑chain‑style work‑order model, introducing demand, plan, and task entities to formalize the production workflow and make it traceable.

Business model defines three core stages: media asset entry, video production, and strategy binding. Each stage has distinct input requirements.

Data model uses a non‑structured key‑value table to store input materials, context, and state change logs, enabling flexible schema evolution without frequent database changes.

Input diversity handling introduces an input validator that abstracts validation rules for each task type, ensuring that required fields are present and correctly formatted.

Example: Video Production Task Attribute Rules (Java)

public class TaskVideoProductionEncodeCategory extends AbsAttrRuleCategory { @Override protected String initCategoryName() { return "压制型视频生产任务输入信息规则"; } @Override protected List initAttrRuleList() { List attrRuleList = Arrays.asList( AttrRule.builder() .attrName("视频类型").attrCode(AttrCode.CATEGORY_ID) .validateRule(AttrValidateRule.notBlankStrValidate) .isMust(true).group("archive").order(1) .build(), // ... (other attribute definitions omitted for brevity) ... ); return attrRuleList; } }

State machine for video production tasks (Java)

public class TaskVideoProductionEncodeStatemachine extends AbsStatemachine { @Override protected List initStatemachineNodeList() { List statemachineNodes = Arrays.asList( StatemachineNode.builder() .status(Status.WAIT_ENCODE) .desc("待压制") .nextStatus(Arrays.asList( NextStatus.builder() .status(Status.ENCODING).pushHandler(Handler.ENCODING).pushPostHandler(PostHandler.ENCODING) .build(), NextStatus.builder() .status(Status.CANCEL).pushHandler(Handler.CANCEL).pushPostHandler(PostHandler.CANCEL) .build())) .isInit(true).isFinal(false).isPositive(true).isCouldUpdateMaterial(true) .materialGroupUpdateRangeList(Arrays.asList("encode", "upload", "archive")) .build(), // ... (other state nodes omitted for brevity) ... ); return statemachineNodes; } }

The state machine abstracts task status transitions, supports automatic progression, priority queues, and ensures tasks move through defined states correctly.

New task development mode emphasizes knowledge梳理 (knowledge structuring) and integration with surrounding systems, enabling rapid onboarding of new business processes.

Phased implementation describes four stages: foundational infrastructure, core OGV workflow, AI‑enhanced material generation, and cross‑business scenario enablement (e.g., smart image stitching for premium members).

Current architecture shows a shift from a loosely coupled workflow to a work‑order‑based model with demand → plan → task → material storage, supported by a centralized production system.

Production execution provides batch task initiation and full‑cycle automation, freeing operators from intermediate steps and allowing them to focus on higher‑value activities.

Summary and outlook notes that the system has industrialized OGV content production, solidified previously scattered knowledge, and improved efficiency and data collection. Future work includes deeper process mining, extending the model to other scenarios (e.g., premium member advertising), and increasing automation across upstream/downstream integrations.

Reference : "Domain‑Driven Design Problem Domain Analysis – Bilibili OGV Business Example" (https://mp.weixin.qq.com/s/sEN57LXO4Dl6gEZPbXuftQ).

System ArchitectureBackend DevelopmentState MachineWorkflow AutomationContent ProductionOGV
Bilibili Tech
Written by

Bilibili Tech

Provides introductions and tutorials on Bilibili-related technologies.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.