Standalone — Lottie Import, Preview, Render & Export Pipeline

This section documents the standalone animation capabilities of yoAnime Studio — the part that runs entirely on Windows without requiring PowerPoint. Everything described here is handled by the internal WPF application through SkiaSharp, FFmpeg, and custom service layers.


1. Overview

yoAnime Studio is a local, offline‑first animation environment designed for importing, previewing, analyzing, and exporting Lottie animations.
The standalone engine consists of:

  • A Lottie importer (metadata reader + validator)
  • A preview renderer (Skia/Skottie)
  • A frame renderer (Skia + optional external CLI renderer)
  • A transcoder/export pipeline (FFmpeg)
  • A multi‑job export queue
  • A project library system
  • A user‑safe storage architecture

This page explains how each of these components works internally.


2. Lottie Import Pipeline

Responsible class: LottieAssetService

When a user drops or opens a .json Lottie file, the import workflow does the following:

2.1 File Loading

  • Reads the JSON file from disk
  • Streams content to avoid large in‑memory spikes
  • Computes SHA‑256 hash for caching, deduplication, and re‑export detection

2.2 Metadata Extraction

The importer extracts:

  • Frame rate (FPS)
  • Duration
  • Width & Height
  • Layer count
  • Embedded asset references

2.3 Validation Steps

  • Checks for missing assets (images, fonts)
  • Detects unsupported Lottie expressions
  • Flags corrupt JSON

If the file loads successfully, it enters the Project Library with its hash and metadata.


3. Real‑Time Preview Pipeline

Responsible class: SkiaLottiePreviewService

This component powers the live preview panel you see in the Studio window.

3.1 Skottie Animation Engine

Uses SkiaSharp’s Lottie module (Skottie) for:

  • Smooth playback
  • Frame scrubbing
  • Looping
  • Zooming
  • Background color switching
  • Letterboxing/pillarboxing

3.2 GPU‑Assisted Rendering

  • Skia creates surfaces in BGRA format
  • Rendering is DPI‑aware
  • Output is composited into WPF host controls

3.3 Frame-Accurate Inspection

Every seek or scrub computes a new frame:

  • Skottie updates the animation time
  • A new surface is drawn
  • Frame is converted into a WPF‑friendly bitmap

This enables pixel‑perfect inspection even for high‑resolution animations.


4. Frame Rendering Pipeline (Export Path)

Responsible Classes:

  • SkiaLottieRenderService (in‑process)
  • ExternalLottieRenderService (CLI‑based renderer)
  • AnimationRenderStrategy (smart routing)

When the user exports MP4/GIF/WebM, yoAnime must first render individual PNG frames.

4.1 Render Strategy Layer

AnimationRenderStrategy chooses between:

  • Skia in‑process renderer (default)
  • External CLI renderer (if configured)

4.2 Skia Frame Rendering

  • Loads Lottie JSON
  • Steps through every frame (based on FPS × duration)
  • Draws each frame to a Skia surface
  • Saves to numbered PNG files:
frame_00001.png  
frame_00002.png  
frame_00003.png  
...

4.3 External Renderer (Optional)

If an external animation tool is configured:

  • yoAnime invokes RLottie‑style CLI commands
  • Collects frames generated externally
  • Handles temp folder cleanup and error fallback

5. Export Pipeline (MP4, GIF, WebM)

Responsible class: FfmpegTranscodeService

Once frames are rendered, yoAnime invokes FFmpeg to generate final export formats.


5.1 MP4 Export

  • Uses H.264 or libx264 encoder
  • Ensures even-width/even-height video frames
  • Applies target FPS and bitrate
  • Allows HD/UHD resolution scaling

5.2 WebM Export

  • Uses VP9 encoder
  • Suitable for UI animation workflows
  • Supports transparency (when configured)

5.3 GIF Export

GIF rendering requires palette optimization:

  1. Generate palette (palette.png)
  2. Use palette during GIF creation
  3. Apply dithering
  4. Optimize frame delays

The pipeline ensures color accuracy while keeping filesize reasonable.


5.4 Pipeline Progress Parsing

FFmpeg progress is parsed from standard output:

  • Reads timestamps
  • Maps back to percentage
  • Emits incremental progress events

6. Export Queue System

Responsible class: ExportJobQueueService

The job queue enables:

  • Multiple simultaneous exports
  • Retry logic
  • Graceful error handling
  • Deterministic ordering

6.1 Job Lifecycle

Each export job moves through:

  1. Queued
  2. Rendering frames
  3. Transcoding
  4. Completed
  5. Failed

Jobs are stored with:

  • File hash
  • Target format
  • Timestamp
  • Output path

6.2 Concurrency

  • Export jobs run in a background worker
  • Uses SemaphoreSlim for controlled parallelism
  • Avoids UI blocking

7. Project Library

Responsible class: AnimationStudioProjectService

The project library:

  • Stores metadata of all imported animations
  • Persists user recents into a JSON file
  • Validates file existence on re‑launch
  • Handles corruption detection and automatic repairs
  • Uses atomic writes to prevent partial file states

7.1 Storage Structure

%LOCALAPPDATA%/yoAnime/yoAnimeStudio/
    projects.json
    samples/
    temp/
    exports/

7.2 What’s Stored Per Project

  • File path
  • Hash
  • Lottie metadata
  • Export history
  • Custom names/thumbnails (future feature)

8. File Paths & Storage System

Responsible class: AnimationStudioPaths

  • Controls all local directories
  • Avoids protected system paths
  • Ensures MSIX compatibility
  • Creates separate subdirectories per project

Temporary data example:

%LOCALAPPDATA%/yoAnime/yoAnimeStudio/temp/ae4d12fa3/

Export output example:

%LOCALAPPDATA%/yoAnime/yoAnimeStudio/exports/sample_loop.mp4

9. Standalone Workflow Summary

Lottie JSON → LottieAssetService → Metadata/Validation
           → SkiaLottiePreviewService → Live Preview
           → AnimationRenderStrategy → Frame Renderer (PNG)
           → FfmpegTranscodeService → MP4/GIF/WebM
           → ExportJobQueueService → Multi‑Job Processing
           → AnimationStudioProjectService → Project Library

This entire workflow runs locally, does not require internet, and does not require PowerPoint.