4 ms·

I'm saying that these URL's: https://gist.github.com/gregsadetsky/cb4754d123f0ea1eae26820d5aefdde1 https://gist.github.com/gregsadetsky/cb4754d123f0ea1eae26820

I'm saying that these URL's: https://gist.github.com/gregsadetsky/cb4754d123f0ea1eae26820d5aefdde1 https://gist.github.com/gregsadetsky/cb4754d123f0ea1eae26820... May have be generated dynamically on the fly (probably programmatically editing / splicing the vids), but the developers, knowing that some people were going save the URLs, cache what's generated for a time so you can access it again without the expense of regen (also splicing in the different clips). I'm just speculating though. It's part of what makes this promo really cool. I'd love to see a breakdown. As promo sites go, it's very smart.

gregsadetsky 5y ago
Ah, got it, thanks. I don’t think that we have definitive proof that the video files are not being generated every time, but most evidence points to that. (There might be some metadata in the mp4 that could help resolve this more definitely) Considering the complexity of doing on the fly video splicing (even if the results are cached) vs the ability for big studios like WB to do the splicing offline in a controlled environment that they’re used to, it’s probably safe-ish to assume everything was generated in advance. It also definitely helps with QA - you can be more sure that the splicing worked if you can test some/any/all files before serving them via CloudFront vs relying on a complex-enough piece of tech. A breakdown of the tech behind this from WB would be interesting to read for sure! Cheers