notes from bobby

At a high level, not very hard to lift and put in servo (despite not touching in 2 years)
Nicely asynchronous
Depends a bit on XPCOM threading stuff, but most of the explicit stuff is non-XPCOM
May want to pull in or not, as needed
abstraction boundray is between media decoder and HTMLMediaelement
it's teh main-thread media state stuff
that communicates with the HTMLMediaElement
the decoder is then async with the state machine on its own thread
and the decoder itself has async links with all the platform stuff
which is all under it
and all on top of thread pools
Generally should work OK
None of it is too hard
More interesting is around source control

Probably need a slight refactor of mediadecoder.cpp to make import easier (hopefully w/ no virtual calls to piss off the media team)
Helps having anthony pro-servo/rust there

Then, threading backend & xpcom dependencies
XPCOM stuff already pretty abstract, but possibly easier to shim to XPCOM (to abstract NSGetCurrentThread, etc.). That's the big question
Also a lot of the PDM decoder models through the gecko media process (open264, EME, etc.) has Gecko IPC so need to figure out what to plug into that.
Otherwise, fairly tractable
"Patrick 80% in two weeks"

Assigning somebody to it for 2 quarters or 1 quarter to investigate & plan would help
Even just a week would get it laid out
Then, resourcing estimate
Then anything like 1 to 4 quarters is reasonable

On a technical level, DO use the media stack from Gecko, especially for the soft support
Totally async, mozpromise is great