noe/tl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
No description
60 commits 1 branch 0 tags 902 KiB
Find a file
Your Name 52c700b843 fix: scroll timeline to deep-linked playhead on first load 
When a project opens with a ?f=<frame> query parameter, the playhead position
is now visible in the timeline view. Previously, the playhead was positioned
correctly in the UI but the timeline didn't scroll to show it. This triggered
scroll-to-seg-track on first render when playhead > 0 and segments are loaded.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-06-30 14:06:20 -04:00
scenes fix: thumbnail parser overflow, autostop-killed jobs, unified playhead 2026-06-30 09:48:08 -04:00
server feat: production deploy (Fly + R2) + frame controls and picker glow 2026-06-30 00:56:09 -04:00
tl fix: scroll timeline to deep-linked playhead on first load 2026-06-30 14:06:20 -04:00
.dockerignore feat: production deploy (Fly + R2) + frame controls and picker glow 2026-06-30 00:56:09 -04:00
.gitignore feat: production deploy (Fly + R2) + frame controls and picker glow 2026-06-30 00:56:09 -04:00
DEPLOY.md feat: production deploy (Fly + R2) + frame controls and picker glow 2026-06-30 00:56:09 -04:00
Dockerfile feat: production deploy (Fly + R2) + frame controls and picker glow 2026-06-30 00:56:09 -04:00
fly.toml fix: thumbnail parser overflow, autostop-killed jobs, unified playhead 2026-06-30 09:48:08 -04:00
manage.py Add Django backend: users, admin, OTIO + scene persistence 2026-06-28 23:45:49 -04:00
README.md feat: timeline links, network error handling, Tailscale access, mobile fixes 2026-06-29 19:24:40 -04:00
requirements.txt feat: production deploy (Fly + R2) + frame controls and picker glow 2026-06-30 00:56:09 -04:00

README.md

scene_analysis

  • tl/ — the lumet frontend (ClojureScript / reagent / re-frame). See tl/.
  • Django backend (this folder) — users, admin, and persistence of OTIO + the timeline scene.

Backend

The backend stores one Project per editing session: the uploaded OTIO source file, the playback fps, and the live scene (the {:tracks :groups} mark-group map the frontend keeps in app-db) as a JSON dump.

Run

python -m venv .venv && .venv/bin/pip install -r requirements.txt
.venv/bin/python manage.py migrate
DJANGO_SUPERUSER_PASSWORD=admin .venv/bin/python manage.py createsuperuser --noinput --username admin --email admin@example.com
.venv/bin/python manage.py seed_demo          # demo project from tl/.../one_two_three.otio
.venv/bin/python manage.py runserver 0.0.0.0:9001   # 0.0.0.0 so it's reachable over Tailscale/LAN

Admin: http://127.0.0.1:9001/admin/ (admin / admin). Upload OTIO and inspect the scene JSON there.

API (session auth; 401 if not logged in)

Method Path Purpose
GET /api/projects/ the current user's projects
GET /api/projects/<id>/scene/ {fps, scene}
PUT /api/projects/<id>/scene/ replace scene and/or fps (JSON body)
GET /api/projects/<id>/otio/ serve the uploaded OTIO file
GET /api/projects/<id>/revisions/ save history (who / when / summary)

Attribution

Annotations are the authored unit, so that's what's attributed — and the server is the authority (client-sent stamps are ignored, so authorship can't be forged). On each scene PUT the server diffs incoming annotation groups against the stored ones and stamps createdBy/editedBy (+ timestamps) from request.user; it also writes a Revision (user, time, +N ~N −N summary, snapshot of the annotation layer). A project is editable by its owner and any collaborators (managed in the admin), so different users get distinct stamps.

The frontend currently loads /one_two_three.otio and persists annotations to localStorage; pointing it at /api/projects/<id>/otio/ and the scene endpoints is the next wiring step (CORS/credentials needed across the dev ports).