VideoJS play speed on mp4 data instead of URL

We have been saving all mp4 files to a filesystem known as seaweedfs, and now we have moved it to s3.

we have an endpoint in Phoenix API as

get "/cameras/:id/archives/:archive_id/play", ArchiveController, :play

While we were on seaweedfs. The endpoint was returning us a URL to that MP4 file as

|> redirect(external: "#{seaweed_url}/#{exid}/clips/#{archive_id}.mp4")

and now on S3 it’s giving us back as

  {:ok, content} = do_load("#{exid}/clips/#{archive_id}/#{archive_id}.mp4")
  |> put_resp_header("content-type", "video/mp4")
  |> text(content)

whereas do_load is a very simple method to load data from S3 as

  def do_load(path) do
    case ExAws.S3.get_object("bucketname", path) |> ExAws.request do
      {:ok, response} -> {:ok, response.body}
      {:error, {:http_error, code, response}} ->
        message = EvercamMedia.XMLParser.parse_single(response.body, '/Error/Message')
        {:error, code, message}

We are sending a request to a server (Phoenix API) from a rails application on a play button, which may then load that mp4 data into a video player. (videojs). When it was a straight URL the video was playing very fast, but as now it’s an mp4 data content-type, the video player is taking much time for first download all that data and then play it.

I am looking for some suggestion to make it more faster. We don’t need to make mp4 files public to get a straight URL from s3, But Still, want to serve it through API.

Is there any way to make it faster? Any suggestion if you would make , it will be helpful. Thanks

You can use HLS with or something similar.

Or stream the response and send it in chunks. Currently you wait for it to be downloaded completely in your do_load

ExAws.S3.get_object("bucketname", path) |> ExAws.request

and then for some reason use |> text(content)? Wouldn’t send_resp be more appropriate?

Since text/2 would try to overwrite your content type header

and possibly turn iodata into a string (to_string(data)) which would be very inefficient.


We settled with pre-auth url for that file from s3.