I would perhaps wait until rav1e 0.4, because there is a bug in the FFmpeg wrapper (of which I am the author) right now that breaks timestamps. If you wish to build with rav1e master, you can apply this to fix it: https://github.com/dwbuiten/FFmpeg/commit/ac4cf898c1960d72bc... (removing the configure check)
It hasn't made it upstream yet since I can't bump the minimum required version in FFmpeg git until rav1e tags 0.4.
Only from clients supporting HTTP only. Note that RFC 2324 [0] defines the Hyper Text Coffee Pot Control Protocol or HTCPCP, which is an extension of HTTP and implementors of clients for this are free to return 418 if necessary. Also, RFC 7168 [1] which extends the protocol as HTCPCP-TEA now fully supports teapots, and is probably a better choice for modern clients. Also of interest is the SNMP MIB for remote management of 'Drip-Type Heated Beverage Hardware' which is defined in RFC 2325 [2] although this does not appear to have been updated with teapot, samovar, urn or other non-filter-coffee management data...
Implementing tea making device remote management would probably be a good candidate for a GSoC project or even a startup if you can find a VC gullible enough to fund you!
Well I believe few people use the built in http module in go. Not sure if you're testing would allow for 3rd party frameworks but the Iris framework loves to claim fastest go web server. Gorilla or gin are also popular.
As for the structure of it you would like have everything split out into goroutines with a worker pool of goroutines ready to ferry the data from request to backend and back to client.
