Add support for python adapters when compiling with emscripten#95
Add support for python adapters when compiling with emscripten#95JeanChristopheMorinPerso wants to merge 7 commits intoOpenTimelineIO:mainfrom
Conversation
Signed-off-by: Jean-Christophe Morin <jean_christophe_morin@hotmail.com>
Signed-off-by: Jean-Christophe Morin <jean_christophe_morin@hotmail.com>
Signed-off-by: Jean-Christophe Morin <jean_christophe_morin@hotmail.com>
Signed-off-by: Jean-Christophe Morin <jean_christophe_morin@hotmail.com>
| <meta charset="utf-8"> | ||
| <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, minimum-scale=1, user-scalable=no"/> | ||
| <title>Raven</title> | ||
| <script src="https://cdn.jsdelivr.net/pyodide/v0.26.4/full/pyodide.js"></script> |
There was a problem hiding this comment.
I'm getting pyodide from a CDN, but we should probably look at other options.
shell_minimal.html
Outdated
| const micropip = pyodide.pyimport("micropip"); | ||
| await micropip.install( | ||
| [ | ||
| 'https://jcmorin.dev/otio-wasm/opentimelineio-0.18.0.dev1-cp312-cp312-pyodide_2024_0_wasm32.whl', |
There was a problem hiding this comment.
We should move this out of there I think.
There was a problem hiding this comment.
The tricky thing is that we can't upload wasm32 wheels to PyPI. So we'll have to find a place to host it.
| // ... And free it when we're done. | ||
| _free(stringOnWasmHeap); | ||
| } | ||
| if (element_event.target.files[0].name.endsWith('.aaf')) { |
There was a problem hiding this comment.
Maybe otioz too? What other formats are in binary?
There was a problem hiding this comment.
AAF and OTIOZ are binary, the rest are all text.
| var stringOnWasmHeap = _malloc(lengthBytes); | ||
| stringToUTF8(timeline_json, stringOnWasmHeap, lengthBytes); | ||
|
|
||
| Module.ccall("js_LoadString", "number", ["number"], [stringOnWasmHeap]); |
There was a problem hiding this comment.
We should not call this for otioz (which raven supports natively)
There was a problem hiding this comment.
Does it support OTIOZ when running in WASM? If so, how well does it handle the memory mapping situation? We may end up wanting to go down the route of the new File System API (Chromium support ✅, but no Safari/Firefox I'm pretty sure), so that it doesn't have to read the whole thing into memory directly.
There was a problem hiding this comment.
I have not tried, but I don't see why it wouldn't work.
I took a quick look at the new shiny file system API stuff but didn't go deep enough to understand the pros and cons memory wise. Do you have a link that would talk more exactly that?
There was a problem hiding this comment.
https://developer.chrome.com/docs/capabilities/web-apis/file-system-access
Give this a quick glance. I don't really know this translates into WASM but my thinking was really just that we could just access the file in-situ without passing it all the way into the WASM-mapped 2GB/4GB memory this way. I just figure that with an OTIOZ when there's actually media, you'll hit the limit pretty much immediately.
…lecting a different file Signed-off-by: Jean-Christophe Morin <jean_christophe_morin@hotmail.com>
…a loop Signed-off-by: Jean-Christophe Morin <jean_christophe_morin@hotmail.com>
Signed-off-by: Jean-Christophe Morin <jean_christophe_morin@hotmail.com>
3 participants
Fixes #60
This is still WIP. It works but we still need to tweak some things and make the experience smoother.
As a proof, see the video below that shows an AAF being loaded in the browser:
Screenshare.-.2024-12-05.9_49_12.PM.mp4
I'm basically creating this PR (and marking as a draft) for visibility and so that my work doesn't get lost in my fork.