MFlow v0.2.0 — Native Media Engine Foundation 🚀

MFlow v0.2.0 begins the transition from a multimedia execution framework into a fully independent media engine.

The goal is simple:

Move less data. Do less work. Measure everything.

✨ What's new

🧩 Native media architecture

MFlow is designed to process media through its own execution architecture instead of depending on FFmpeg or another external multimedia executable.

The engine is being built around:

INPUT
  ↓
STREAM PLANNER
  ↓
WORK GRAPH
  ├── VIDEO
  │    ↓
  │  DECODE → FILTER → ENCODE
  │
  └── AUDIO
       ↓
     DECODE → PROCESS → ENCODE
  ↓
MUX
  ↓
OUTPUT

⚡ Work-aware processing

MFlow is designed to avoid operations that are not required by the requested result.

For example, when a stream can be copied without modification, the engine should be able to avoid unnecessary decoding and re-encoding:

INPUT
  ↓
STREAM ANALYSIS
  ↓
COMPATIBLE STREAM
  ↓
DIRECT COPY
  ↓
OUTPUT

Instead of:

DECODE → CONVERT → ENCODE

This architecture is the foundation for future stream-copy and zero-copy optimizations.

💾 Memory architecture

The project continues developing its memory management layer around:

reusable buffers
controlled allocations
reduced memory copies
buffer lifetime tracking
future zero-copy execution

🧵 Execution engine

The scheduler and pipeline system introduced in v0.1 continue to form the execution layer of MFlow.

The long-term goal is to make scheduling media-aware rather than simply distributing generic tasks across CPU threads.

🖥️ Hardware-aware design

MFlow's architecture is being prepared for hardware-specific execution paths.

The intended model is:

GPU DECODE
     ↓
GPU FILTER
     ↓
GPU RESIZE
     ↓
GPU ENCODE

without unnecessary:

GPU → RAM → GPU

transfers.

🎯 What makes MFlow different?

MFlow is not intended to be a command-line clone of FFmpeg.

The project is being designed around a different execution philosophy:

Understand the requested result first, then perform only the work required to produce it.

This means the stream planner can eventually reason about:

which streams are actually needed
whether decoding is necessary
whether re-encoding is necessary
whether a format conversion is necessary
where data should live
which processing stages can be fused
which hardware path should be used
how buffers can be reused

🏗️ Current status

MFlow v0.2.0 is an early native-engine milestone.

This release establishes the architecture required for native multimedia processing. It should not yet be considered a complete replacement for mature multimedia frameworks.

Native container parsers, codecs, muxers and hardware acceleration are being developed incrementally.

🛣️ Next milestones

v0.3

Native media container layer
Stream model
Packet model
Timestamp handling
Native demux foundation
Real media fixtures
Media-specific benchmarks

v0.4

Native codec implementations
Frame management
Pixel formats
Audio sample formats
Native encode/decode paths

v0.5

Zero-copy execution
Buffer lifetime planning
Pipeline fusion
Asynchronous I/O
Hardware acceleration foundations

v1.0

Stable native media API
Multiple containers
Multiple video codecs
Multiple audio codecs
Hardware acceleration
Cross-platform releases
Reproducible performance benchmarks

📊 Benchmark philosophy

MFlow does not publish performance claims without reproducible measurements.

Benchmarks should document:

CPU
GPU
RAM
operating system
compiler
MFlow version
input media
output format
processing parameters

🔓 Open source

MFlow is completely open-source and licensed under MIT.

The project is being developed with a long-term goal of providing an independent, efficient and locally executable multimedia engine.

MFlow v0.2.0

Native media engine foundation.