undefined | Better HN

0 pointsgregsadetsky4y ago0 comments

Sorry, what do you mean? In a way, they are “cached” — by being pre-rendered files, all that the web server (s3/cloudfront, really) has to do is serve the file to the user…

Are you saying that the video files should have been cached, or..?

Thanks

0 comments

dynamite-ready4y ago

I'm saying that these URL's:

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.

gregsadetskyOP4y 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

j / k navigate · click thread line to collapse