[gregsadetsky]

As many have figured out, these are pre-generated mp4 files. There's no 'magic' in the video files themselves (i.e. the video is not generated on the fly)

In https://thechoiceisyours.whatisthematrix.com/_nuxt/commons/a...

The client side generates an unobfuscated string such as:

red-a-b1-c1435-d-e2-f-g3-h2-i

where 1435 is the current local time (search for `key: "teaserSrcProps"` in the code to find the relevant function)

Then "17" is prepended to that string ("BOND_OBFUSCATION_SALT" in the source code), and then the video file name is simply the MD5 of the string.

To find the video URL:

    // change 1435 for any HHMM time
    timeStr = "red-a-b1-c1435-d-e2-f-g3-h2-i"
    videoFile = MD5("17" + timeStr) + ".mp4"
    url = "https://thechoiceisyours.whatisthematrix.com/generated/v7/high/" + videoFile

:-)

---

All 1440 red pill video URLs (tested all of them in bulk without downloading any using `wget --spider -i allurls.txt` — spider is a cool option!):

https://gist.github.com/gregsadetsky/cb4754d123f0ea1eae26820...

[rvlt]

That was my first idea and when i found out the video url i was quite pleased to figure out the solution.

Then the "generated" folder made me think, and i decided to test it a bit more, so i started the experience at 15:00 and 35 seconds, just the right amount to get to the time reveal just after the clock change, and i was blown away, the video shows 15:01 and not 15:00 as i expected, whatever they are doing here to replace the video at the exact time without us noticing it is quite crazy.

[flamejob]

I doubt they’re replacing the video at any point, it’s all probably prerendered videos for each time.

For a user who’s clock changes midplay, you would simply check the time with seconds before choosing the video to render, if it’s MM:35 or after you would play the MM+1 video instead of MM

[gregsadetsky]

Ah yes, that makes sense. I do remember seeing in the code that they add … 23 seconds? I think to the current time. I imagine that the time is shown in the video at the 23 secs mark?

So yes you’re right, they do take that (minute changes while watching the video) into account!

[chakhs]

I'm disappointed, would've been cool if it was done on the fly

[nacs]

Their static file approach makes sense.

There's "only" 1440 combinations and the site is going to get a lot more views than that so why bother re-rendering everything dynamically?

[wahern]

Technically you wouldn't have to re-render (i.e. recompress), you could just dynamically splice in different compressed audio frames. AAC (what MP4 uses) does this well, MP3 less so but for vast majority of listeners it's still indiscernible, especially if there's a slight audio gap. The CPU load is de minimis, though you do still need to track frames--can't just move blobs from disk to socket using sendfile(2). I did this for a radio streaming server that supported per-listener ads--everybody received the same content stream (or at least, one of several codec+format pipelines, i.e. RTP+AAC, FLV+MP3, etc), but when ad spots were detected they were dynamically swapped with different spots that varied per output stream. From the perspective of downstream software clients it was still always one long, unbroken encoded stream. I never got around to supporting compressed video frame splicing, but it would work the same way, modulo the fact that your key frames tend to be spaced out more so it wouldn't always be so seamless with ad hoc content (you'd definitely want a brief screen blackout or carefully placed key frames for the transition like you often see in broadcast television).

But while conceptually easy to do this, I've never seen other streaming servers do this, certainly not open source ones. And of course the most obvious, simplest way is to just pre-render a bunch of static files and serve using a dumb HTTP server.

[chakhs]

Thanks that's what I was looking for!

[chakhs]

Yes it does make sense. I just wished they did took the re-rendering approach so I could see how it can be done :)

[sva_]

Sadly my timezone wasn't set up correctly, apparently (I'll have to mess with hwclock, I guess.) Still a cool little teaser!

[Eriks]

b, e, g, h are all 1..3 ;)

https://gist.github.com/EriksRemess/62f946bda713da80c7905d1c...

[gregsadetsky]

Yeah, you’re totally right, and “red” can also be “blue” of course

I didn’t go into that but I should have mentioned it. There are also multiple resolutions for the videos…! It’s truly 1440 videos times all of the options…!

Have you have been able to decode what the b, e, g and h options mean?

[Eriks]

b, e, g, h are random number from 1 to 3

Math.floor(Math.random() * 3) + 1

edit: b, e, g, h are different segments included. So all unique segments are in these videos:

blue-a-b1-c0000-d-e1-f-g1-h1-i 1f3dbdfd6a7c3d574b6b9eb8d07a3567.mp4

blue-a-b2-c0000-d-e2-f-g2-h2-i 241eb47071c89d8f18b0948763d6389a.mp4

blue-a-b3-c0000-d-e3-f-g3-h3-i 498ec3ba6719291e77b2a8870c744bdf.mp4

red-a-b1-c0000-d-e1-f-g1-h1-i ea2222b8b7a5c72396f76d65cf56890a.mp4

red-a-b2-c0000-d-e2-f-g2-h2-i bac726340f5486d9e02942c243e5b56b.mp4

red-a-b3-c0000-d-e3-f-g3-h3-i ce1aef26388b49562eab495b597e8fbc.mp4

[gregsadetsky]

Oh, so you’re saying that there are only 3 unique video segments, but you might get a 1..3 random number for all b, e, g and h arguments…?

So 1440 per-minute videos * 2 pill colors (red/blue) * 3^4 segments (1..3 values for each b, e, g, h argument) * 2 video qualities (high/low)!

[Eriks]

3 different segments per key/argument, 4 keys/arguments, 2 colors = only 24 random segments inserted

[gregsadetsky]

Sorry do you mean that not all b, g, etc. argument values are possible?

So b1 g2 for example might be possible, but b2 g1 might not exist?

i.e. are values truly random / uniformly distributed?

[diimdeep]

Is there larger resolution than 1080p ?

[gregsadetsky]

Someone posted a trailer they found (that has since been removed) with “7000k” in the url, so… maybe?

https://news.ycombinator.com/item?id=28448361

Having looked at it a bit more, I only see "low" and "high" mentioned as qualities. You can replace "high" with "low" in the list of URLs I included (see my gist, posted above) and they seem to work e.g.,

https://thechoiceisyours.whatisthematrix.com/generated/v7/lo...

There is an intriguing list in the source code though:

  ["4000k", "5000k", "6000k", "7000k", "8000k", "9000k", "12000k", "15000k"]

which ... could be a list of (pretty extreme) resolutions? Or are these color temperatures?

[cwizou]

15k is getting very blue in terms of temperature. Maybe bitrates? Those would also fit.

[gregsadetsky]

You've been vindicated, it's definitely bitrate! :-)

See: https://news.ycombinator.com/item?id=28464228

[Eriks]

Looks like there are just two resolutions - "high" 1080p, "low" 720p

h = ["high", "low"]

[higgins]

Hmm...each of these videos is rendering the same clips for me. The web player will render new ones though.

[gregsadetsky]

The clips are pretty much the same, except for when the time appears on the screen, which happens somewhere in the middle of the videos, no?

[higgins]

At least for me, for each of the videos in that gist the only difference between them was the timestamp at the beginning of the video. All the movie clips were the same. :/

[gregsadetsky]

Since I first replied to your comment, people have figured out that there's more than just the 'time' (that appears at 0:23 in the video) that changes from one video to another. There are 'parameters' that get encoded in the video file name/URL's MD5 hash as well. Compare these two videos:

Original video file name: blue-a-b1-c1234-d-e1-f-g1-h1-i

which is this url: https://thechoiceisyours.whatisthematrix.com/generated/v7/hi...

Another video file name: blue-a-b3-c0555-d-e3-f-g3-h3-i

which is this url: https://thechoiceisyours.whatisthematrix.com/generated/v7/hi...

Notice the differences due to the b, e, g and h values:

- at 0:13 the video is different

- at 0:18 the video is different

- at 0:23 the displayed time is different (12:34 versus 5:55)

- at 0:35 the video is different

- at 0:39 the video is different

- at 0:42 the video is different

---

This is also really helpful to see all of the clips :-)

https://www.youtube.com/watch?v=MeRmoU7VxIA

Found on https://www.reddit.com/r/matrix/comments/pjww65/whatismatrix...

[dynamite-ready]

Might these not have been cached?

[gregsadetsky]

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

[dynamite-ready]

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.

[gregsadetsky]

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