---
title: Alternative structures
description: Other project and authoring models Odori could support, and why videos plus JSX is the default.
---

## Filesystem alternatives

| Structure | Strength | Cost | Decision |
| --- | --- | --- | --- |
| `videos/` at repository root | Clear first-class convention; works with or without Next.js | Adds another root source folder | Default |
| `src/videos/` | Familiar to libraries using `src/` | Weakens the visible convention | Configurable |
| `app/videos/` | Colocates with Next.js routes | Confuses URLs with compositions | Not recommended |
| `packages/videos/` | Strong monorepo isolation | Heavy for small projects | Supported as a configured root |
| One package per video | Independent deployments and ownership | Excessive setup and poor sharing | Large-studio option |

## Authoring alternatives

**JSX entry**

`video.tsx` exports static metadata and a React timeline. This is Odori's
default because components compose naturally and React remains visible.

**Object manifest**

A `video.ts` scene array is easier for machines to inspect but creates a
parallel configuration language and makes composition less natural.

**Direct Odori React**

Direct Odori frame hooks and ordinary React provide total freedom. Authors
can bypass structured `<Scene>` boundaries without leaving the Odori
runtime.

**Visual timeline data**

A JSON timeline is portable and editor-friendly, but it limits React
expressiveness and makes source ownership less direct.

## Registration alternatives

Runtime filesystem globbing is concise but bundler-specific. Manual registration
is portable but repetitive and easy to drift. Odori generates a static import
manifest, retaining portability and code splitting while keeping registration
out of user source.

## Rendering alternatives

- **Local Chromium and FFmpeg** are ideal for development and CI.
- **Dedicated workers** provide predictable hosted rendering and isolation.
- **Serverless rendering** scales well for bursty workloads but needs chunking,
  artifact assembly, and provider-specific operations.
- **Client-side encoding** can help with lightweight cuts but is not the default
  for consistent production codecs, fonts, and large assets.

The authoring contract remains deployment-independent. Preview and export share
the same frozen manifest regardless of renderer.