Pre-release evaluation
Test RTC and media gateways, processing and transcoding, plugins with video frame and audio sample access, or GPU filtering. Choose the capabilities your product needs and request pre-release access. Availability and package scope are confirmed individually.
The download supplies CPU and optional GPU file-processing examples. RTC and plugin evaluations use their matching setup. The CoreMF runtime requires separately arranged evaluation access and terms. Check availability ↗
Choose your evaluation
Try calling, screen sharing and background effects in a cloud-hosted meeting demo. For media gateways, evaluate RTMP/RTSP/SRT ingest into RTC/SFU delivery and recording with your selected inputs.
Cloud meeting demo planned; the direct link will be added when the endpoint is ready.
Explore RTC and gateway integration ↗Add custom processing or AI through native, Python or JavaScript plugins with individual video frame and audio sample access. Select compatible development materials and any model separately.
Choose your plugin interface ↗Decode, resize, process audio and encode a file. Start with the supplied CPU example; no GPU is required.
Try CPU processing ↗Apply shaders, color effects and animated composition to the same footage. Use this optional example when GPU graphics matter to your product.
Try GPU filtering ↗1 / Select the runtime
Confirm your inputs/outputs, target OS, application language and required modules. Choose SDK, Runtime Container or Server delivery for your integration. GPU hardware is needed only for pipelines that use it; codecs and interfaces follow the selected package.
The supplied file examples need no AI model or custom plugin. RTC needs reachable endpoints; custom processing needs its matching plugin and any model. Evaluation expiry, resolution/duration limits and permitted use are agreed before access is issued.
Compare SDK, Runtime and Server delivery ↗2 / Try the processing example
Extract the archive and make the supplied runAPI
available on PATH. From the archive's top folder, run the commands
below. The CPU configuration selects software AV1 at 640×360 and AAC
audio; request these encoders in your runtime. Use a new output
filename for each run.
cd cpu
runAPI -i ../waterfall-input.mp4 \
-af gain -audio-filter-config @../audio-gain.json \
-o cpu-workflow-output.mp4 -p tc -s 640x360 -r 25 \
-gpl off --hw-codec off --hw-decoder off -j cpu-workflow.graph.jsonSet-Location cpu
runAPI.exe -i ../waterfall-input.mp4 `
-af gain -audio-filter-config "@../audio-gain.json" `
-o cpu-workflow-output.mp4 -p tc -s 640x360 -r 25 `
-gpl off --hw-codec off --hw-decoder off -j cpu-workflow.graph.json
Run inside cpu/ so the runner reads its supplied codec
configuration. Open the output in an AV1/AAC-capable player and
inspect the exported graph. No GPU filter or hardware codec is used.
Optional / GPU example
Run from the archive's top folder, returning from cpu/
first if needed. This example requires the GPU production filter, a
supported GPU/driver and a working hardware H.264 encoder. It
rejects software rendering.
runAPI -i waterfall-input.mp4 -f glproduction \
-filter-config @waterfall-gpu.json \
-af gain -audio-filter-config @audio-gain.json \
-o gpu-workflow-output.mp4 -p tc -s 1280x720 -r 25 \
-gpl off --hw-codec auto -j gpu-workflow.graph.jsonrunAPI.exe -i waterfall-input.mp4 -f glproduction `
-filter-config "@waterfall-gpu.json" `
-af gain -audio-filter-config "@audio-gain.json" `
-o gpu-workflow-output.mp4 -p tc -s 1280x720 -r 25 `
-gpl off --hw-codec auto -j gpu-workflow.graph.json
Automatic selection needs a supported hardware encoder in your
build. GPU filtering and hardware encoding are separate stages.
-gpl off controls encoder selection; it does not
change the runtime's license.
3 / Inspect and integrate
Play the complete output and inspect the exported graph and selected encoders. Check resized video and audio for the CPU path; effects and composition for the GPU path. For RTC or plugins, measure your actual network and processing workload.
See the recorded input/output demonstration ↗
Use the delivered application example and
CoreMF_API.h for graph configuration and lifecycle.
Configure pipelines in code or JSON, add the relevant processing
and validate correctness, latency and resource use against your
requirements.
Recorded October 30 Windows development checks: CPU AV1/AAC output fully decoded with 350 video frames at 640×360/25 fps. Optional GPU H.264/AAC output fully decoded with 349 frames at 1280×720/25 fps. These are file-workflow checks; platform/package qualification and RTC capacity remain separate. Test conditions ↗
Both checks used a Windows x86-64 development runtime and the 350-frame input. The CPU path used software AV1 encoding with hardware decode/encode disabled. The GPU path used Intel UHD 770, a real GPU renderer, automatic eligible hardware H.264 encoding and AAC audio. Frame-for-frame GPU equivalence is not claimed.
The native Windows -mft alternative failed at encoder
drain and is not the verified path. Development runtime
dependencies were supplied separately; Windows package
relocatability was not qualified by this run.
Linux/macOS, other GPU/encoder combinations and customer packages need their own checks. Full engineering record ↗
Extend your evaluation
Explore the object tracking integration recipe ↗ with a separately supplied plugin/model, or discuss custom integration ↗. Configure and control graphs through C/C++, Python, Node.js, Java or Go with the matching SDK. Confirm Linux/Ubuntu, macOS or Windows availability for your selected modules.
Build with CoreMF
Tell us the media I/O, target platform and main requirement. We can define the package and acceptance criteria.