MP4

So why were there 3 requests for the video? Let's break each one down.

First Request

The first one is a GET request for the video file, and a Range header is included that says "Give me the bytes from 0 to the end of the file" (all of 'em).

GET https://tubely-66345.s3.us-east-2.amazonaws.com/landscape/fvV0PgksFF-ThNVOO_g8Dm8_zy8nZbT5pv1rsclfLhU.mp4
Range: bytes=0-

The response is a 206 Partial Content and has a few headers:

Content-Length: 148447946
Content-Range: bytes 0-148447945/148447946

In other words the entire file is 148447946 bytes, or about ~148MB, and this response returned the full range...

...wait what??? Why is the "size" of the response only ~34kB if the entire file was returned??? That's only ~0.0002 of the file! Well, to be efficient, the browser stops downloading the response once it's had enough. It's the browser's trick to get just enough of the file to get started.

Second Request

The second request is another GET request to the same URL, but this time, the browser is specifying a more specific range of bytes to download:

Range: bytes=146472960-

And the response is another 206 with just a couple of megabytes in the body, and these headers:

Content-Length 1974986
Content-Range bytes 146472960-148447945/148447946

The browser is downloading just the end of the file now... interesting...

Third Request

The last one is also a GET to the same URL, but this time with this range:

bytes=32768-

In other words, it's just getting a bit more from the start of the file.

The moov Atom

So what's the deal? Why not just start from the beginning? Why this jumping to the back of the file? Well, in a "traditional" mp4 file (as our current Boots videos are), the "moov" atom (which contains metadata about the video) is at the end of the file.

But the client needs that metadata before it can start playing the video! So the browser is smartly poking around using Range requests to get that metadata as quickly as it can. We can speed up this process by pre-processing the video to have "fast start" encoding by moving the moov atom to the start.

Assignment

Update the server to pre-process uploaded videos so they always have "fast start" encoding.

Ensure ffmpeg is installed and available in your PATH

ffmpeg -version

Create a new function called processVideoForFastStart(filePath string) (string, error) that takes a file path as input and creates and returns a new path to a file with "fast start" encoding. It should:
1. Create a new string for the output file path. I just appended .processing to the input file (which should be the path to the temp file on disk)
2. Create a new exec.Cmd using exec.Command
  - The command is ffmpeg and the arguments are -i, the input file path, -c, copy, -movflags, faststart, -f, mp4 and the output file path.
3. Run the command
4. Return the output file path
Update handlerUploadVideo to create a processed version of the video. Upload the processed video to S3, and discard the original.
Delete all your other videos from your Tubely account, we don't need them.
Create a new video called "Boots Horizontal Fast Start" with any old description and upload the horizontal video.
Do the same thing as before: network tab -> disable cache -> refresh. Now you should only see 1 request to the start of the file instead of 3! Yay, small optimizations! (But more importantly, we understand what's going on now)

Run and submit the CLI tests.

It might take a minute... it's downloading a lot of video.

The body of the last GET request is binary, so we hide it from the terminal output.
The test still checks internally for a moov atom at the start of the file — you won't see it printed.