8 ms·

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 h

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/app.js 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/cb4754d123f0ea1eae26820d5aefdde1 https://gist.github.com/gregsadetsky/cb4754d123f0ea1eae26820...

sva_ 5y ago
Sadly my timezone wasn't set up correctly, apparently (I'll have to mess with hwclock, I guess.) Still a cool little teaser!
higgins 5y ago
Hmm...each of these videos is rendering the same clips for me. The web player will render new ones though.
- gregsadetsky 5y ago
  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 5y ago
    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 5y ago
      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/high/2cb454dc2997dd6cd846253971034e59.mp4 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/high/ee0ceec841c3ee13d35aae7f323d942b.mp4 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 https://www.youtube.com/watch?v=MeRmoU7VxIA Found on https://www.reddit.com/r/matrix/comments/pjww65/whatismatrixcom_inner_workings/ https://www.reddit.com/r/matrix/comments/pjww65/whatismatrix...
Eriks 5y ago
b, e, g, h are all 1..3 ;) https://gist.github.com/EriksRemess/62f946bda713da80c7905d1c059385b7 https://gist.github.com/EriksRemess/62f946bda713da80c7905d1c...
- gregsadetsky 5y ago
  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?
  - diimdeep 5y ago
    Is there larger resolution than 1080p ?
    - gregsadetsky 5y ago
      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 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/low/1e4bc704804d64a331506f2f64b93e8f.mp4 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 5y ago
        15k is getting very blue in terms of temperature. Maybe bitrates? Those would also fit.
        5y ago
dynamite-ready 5y ago
Might these not have been cached?
- gregsadetsky 5y ago
  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 5y ago
    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
chakhs 5y ago
I'm disappointed, would've been cool if it was done on the fly
- nacs 5y ago
  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 5y ago
    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 5y ago
      Thanks that's what I was looking for!
  - chakhs 5y ago
    Yes it does make sense. I just wished they did took the re-rendering approach so I could see how it can be done :)
rvlt 5y ago
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.
- gregsadetsky 5y ago
  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!
- flamejob 5y ago
  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

sva_ 5y ago

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

higgins 5y ago

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

gregsadetsky 5y ago
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 5y ago
  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 5y ago
    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/high/2cb454dc2997dd6cd846253971034e59.mp4 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/high/ee0ceec841c3ee13d35aae7f323d942b.mp4 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 https://www.youtube.com/watch?v=MeRmoU7VxIA Found on https://www.reddit.com/r/matrix/comments/pjww65/whatismatrixcom_inner_workings/ https://www.reddit.com/r/matrix/comments/pjww65/whatismatrix...

Eriks 5y ago

b, e, g, h are all 1..3 ;) https://gist.github.com/EriksRemess/62f946bda713da80c7905d1c059385b7 https://gist.github.com/EriksRemess/62f946bda713da80c7905d1c...

gregsadetsky 5y ago
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?
- diimdeep 5y ago
  Is there larger resolution than 1080p ?
  - gregsadetsky 5y ago
    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 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/low/1e4bc704804d64a331506f2f64b93e8f.mp4 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 5y ago
      15k is getting very blue in terms of temperature. Maybe bitrates? Those would also fit.
      - 5y ago

dynamite-ready 5y ago

Might these not have been cached?

gregsadetsky 5y ago
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 5y ago
  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

chakhs 5y ago

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

nacs 5y ago
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 5y ago
  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 5y ago
    Thanks that's what I was looking for!
- chakhs 5y ago
  Yes it does make sense. I just wished they did took the re-rendering approach so I could see how it can be done :)

rvlt 5y ago

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.

gregsadetsky 5y ago
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!
flamejob 5y ago
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