cactus/go-camo

Feature Suggestion: MP4 Support

Meow opened this issue · 3 comments

Meow commented

Specifications

Go-camo from the Docker Hub (tagged v2.4.13) seems to be failing to proxy MP4 content. I use it in conjunction with a custom version of akkoma, where I modified the code to output go-camo URL format (by default it created HMAC on the base64 encoded URL, I simply made it sign the URL before base64 encoding).

Right now I am forced to implement a hacky workaround in nginx configs, where if the file ends with "mp4" I let akkoma's built-in media proxy handle it, and if not, go-camo handles it. The reason for using go-camo instead of akkoma's built-in media proxy to begin with is performance, built-in proxy takes upward to 30 seconds to load an external image, while go-camo does so under one second, due to the round trip involved in my setup (with akkoma media proxy, it's browser -> webserver -> appserver -> webserver -> browser, while with go-camo it's merely browser -> webserver -> browser as I can let go-camo simply run on the webserver, each -> signifies a connection to a different server over the internet).

Version: v2.4.13
Platform: Docker (Debian Bookworm host, kernel 6.1 series)

Expected Behavior

MP4 file is proxied.

Actual Behavior

Go-camo outputs "Unsupported content-type returned."

Steps to reproduce

  1. Attempt to proxy MP4 content
  2. Observe the error
dropwhile commented

Are you using the --allow-content-video flag and it is still not working?

Meow commented

Are you using the --allow-content-video flag and it is still not working?

Oh wow, how did I not notice the option in the documentation... thanks for the heads up. Well, may I suggest that the error output is changed to suggest to enable that option in case a potentially-supported, but not enabled content type is attempted to be proxied? I'll close this original issue as it's not relevant anymore, it was me being a stupid.

dropwhile commented

I think the log spam for higher traffic sites would outweigh the discoverability of that logging you suggested.
I do think updating the README to highlight that functionality a bit more seems like a good idea though.