Just a guess but I assume this was done by starting an upload with the API which gave the guy the ID but then not streaming the actual video file until it was recorded.
Looking at an example of the API in use ( https://developers.google.com/youtube/v3/docs/videos/insert#... ) that certainly seems plausible although I would imagine that there would be a timeout making it difficult.
edit: after looking at the other guy mentioning the time machine reference, my theory would be that he just spammed this API until he got a plausible URL and only then recorded and uploaded the video, probably would take a while but not forever considering how loose the URL actually is to delorean
Edit: I don't know the answer but I assume from all the APIs I worked with in the past, but if you get the URL before the upload is completed then yeah it's pretty easy to "fake".
Maybe with this API, but when uploading a YouTube video through YouTube, you definitely get the URL before the actual upload finishes. I don't imagine it'd be terribly hard to reverse-engineer that API.
My guess is that you can start an upload, get the ID, and then stream unimportant and non-comitall video headers and chunks (e.g. subtitle tracks or other metadata) slowly enough to keep the server from closing the connection on you. Then you can just record your video and start uploading actual video chunks once ready.
Or maybe YouTube doesn't have a huge timeout for starting your upload, so you don't even have to do all of that.
Not for me. When I'm uploading a video even when it's at 0% I see "The URL of your uploaded video will be: blah"
So it seems you can get the URL immediately... maybe then stop the upload mess with the video and then resume the upload... but I assume the resume feature takes a hash or something to make sure it's the same file..
Yes, I thought I saw this too many years ago when I was making youtube videos, and uploading would be slow or broken. Although I never tried changing the video after getting the URL.
Have you confirmed this? In the example the ID is retrieved from the finished upload response, but on the actual YouTube website does tell you the video link with the ID in advance, and the API parameter 'part' does appear to allow you to get the ID.
Start uploading a video, pause the upload, you could already get the ID of the vid, render rest of the video and then continue the upload that now contains the ID of the video :D
Here's a guess: upload from a browser running on Linux, and create a FUSE filesystem that blocks read() calls until you've generated the video.
I tried it with a named pipe ("mknod /tmp/foo.mp4 p") and it gave me an error, but before the error, the web page blocked during upload, but it showed me the URL that will be used (before I gave it a single byte of data).
My first guess is that new versions of videos can be uploaded if they're similar enough (not sure how it would judge that? visually???) and/or are updated shortly enough after upload.
Edit: Oh, I didn't even see the time travel reference in the ID. Maybe the ID is generated from metadata, and there's some endpoint where he was able to throw random metadata at it in an automated process until it came out looking somewhat like "delorean". Or he was able to get ahold of the algorithm locally for a quicker version of that process. In any case, I doubt he backwards-engineered anything.
edit: after looking at the other guy mentioning the time machine reference, my theory would be that he just spammed this API until he got a plausible URL and only then recorded and uploaded the video, probably would take a while but not forever considering how loose the URL actually is to delorean