Appearance
MPE
gapPurpose
The Media Processing Engine (MPE) turns raw recorded takes into finished research videos. It sits between Core's capture workflow and playable output. The team still needs to confirm its owner and service location. This page explains its intended job and the processing steps supported by lt-core.
What it does
The intended media pipeline covers audio cleanup, face alignment, background handling, stitching, transcripts, subtitles and artificial-intelligence-assisted titles and abstracts. These responsibilities come from the technical stack notes, so they need engine-side verification.
Core expects structured output containing renditions, subtitle files, a poster and chapter timing. It validates and registers finished objects before projecting a Video. See the integration contract.
For maintainers: technology
The stack notes describe Python and Docker on Hetzner. The absent engine repository prevents checking runtime versions, implementation details or operational ownership. Core provides a development mock with a queued 30-second completion delay; worker scheduling may extend elapsed time.
How it connects
Core saves a request snapshot for each processing run and queues dispatch. MPE returns results to POST /api/v1/mpe/lt-works/{id}/results. Finished media belongs on the configured R2 output storage; raw chapters stay on Core's upload storage. Core registers existing objects rather than copying them.
On failure, the run records reasons and the work enters a processing-failed state. On success, projection creates a Video and Core advances to final researcher confirmation. See LT Work lifecycle.
Who can do what
No human MPE login surface is documented. Researchers and coordinators interact through Core and the app. Machine authentication is separate from these personas.
| Action | Anonymous | Researcher | Coordinator | Administrator | Editor |
|---|---|---|---|---|---|
| Submit a work that can trigger processing | No | Partial, through app/Core | Partial, after subject approval | Partial, impersonation | No |
| Inspect own processing state | No | Partial, through app/Core | Partial, visible works | Yes, Core diagnostics | No |
| Advance or fail a mock run | No | No | No | Partial, Core mock-driver action | No |
| Log in directly to MPE | Partial, unknown | Partial, unknown | Partial, unknown | Partial, unknown | Partial, unknown |
Environments and links
Staging finished mediahttps://media.stg.lt.orgR2 media base, not MPE service
Production finished mediahttps://media.lt.orgR2 media base, not MPE service
These output bases are documented in the Core contract. Local raw uploads may use local object storage, but mock completion requires its configured Cloudflare R2 output destination. See the mock completion client. MPE local, staging and production service URLs remain undocumented.
Where to read more
How a video gets published and MPE and Video.
Known gaps
The engine repository, service URLs, owner, operational permissions and implementation of the advertised processing steps need verification. The mock demonstrates Core's integration contract; it does not prove the real engine is deployed or feature-complete. Track these questions in Open questions.
For maintainers: source references
These references require repository access. Everything needed to understand this page is explained above.