The full making-of and nostalgia-trip combo video:
Download the source code: 90stube-0.0.1.zip (79.1 kB, sha1: 68ae63e910e61c0e91e690adcfb771158adc1bb4)
90sTube is a Python 3 Flask server that also uses bash, ffmpeg, and YouTube-DL. After extracting the files, you should be able to install the Python dependencies from the Pipfile (for Pipenv) or requirements.txt (for pip). The dependencies you will need to provide yourself are bash and ffmpeg.
YouTube-DL breaks and gets updated pretty quickly as websites change. If YouTube-DL is not working when it should, try updating to the latest version.
To run 90sTube, the command is:
FLASK_APP=90stube flask run
There's no integrated search functionality right now, so to watch whatever video, you will need to copy the video ID to the URL:
The actual proxy is a simple Python Flask server using Jinja 2 to template the designs coming out of ImageReady. The video page has a simple <embed> tag that points to a different URL on the Flask server. That handler calls a bash script that pipes Youtube-DL to ffmpeg and streams the result to the client (in theory).
There was an earlier prototype that created MOV files with SVQ1 video and PCM audio which let it work on QuickTime on Windows, but it had a couple issues. SVQ1 encoding is very slow with ffmpeg (and ffmpeg's Cinepak encoding is even slower), and I had to run the result through mencoder to get it to play at all. Not sure why the MOVs created by ffmpeg wouldn't play, but I wasn't able to figure it out.
... when I'm using the site on a Mac? Wouldn't it have been better to run Photoshop 5.5 on the iMac?
A: Everyone knows that Windows is for graphics and design work while Macs are for gaming.
The "video/mpeg" format currently served by 90sTube works pretty well on a Mac, where the default media player is QuickTime. For whatever reason, the MPEG-1 + MP2 files won't play on Internet Explorer 5 on Windows 98. The <embed> triggers Windows Media Player, but Windows Media Player doesn't want to play the file. Not sure why.
The easy solution would be to create a few more links underneath the video for Windows users that embed a file (perhaps AVI) that works on Windows. So, there would be four links - two for Mac, two for Windows. That's rather inelegant, although elegancy didn't seem to be an expectation for streaming video back in 1999.
The 90sTube proxy downloads the thumbnail images, converts them from WebP to JPG with a low quality. This solves three basic problems: 1) the client can speak HTTP, not the shady encrypted HTTPS protocol, 2) the client doesn't understand what a WebP is anyways, and 3) lowering the quality will make the image load faster on a 56K modem.
The QuickTime MOV container format, for some reason,* puts all the info about the file's audio and video tracks at the end of the file (the MOOV atom). That means you can't understand the data until you've downloaded the whole file, at which point you can start playing it.
That's why there are so-called "faststart" MOV files that put the MOOV atom at the beginning of the file, so that you can start playing the file as soon as you download the beginning. That's great.
But in the transcode-and-stream use case, we run into a problem. We don't know enough about the yet-to-be-encoded video to write a correct MOOV until we've finished encoding all the audio/video data (* this answers the asterisk from two paragraphs ago), so we can't stream the MOOV to the client until we've finished transcoding the file. That really ruins our plan to start streaming the video to the client while we're still in the middle of transcoding the file.
The solution is to essentially make the whole video file a bunch of little video file pieces all stuck together, with each piece having its own MOOV. So you can encode some video, give it a MOOV, and pass it along to the client while you start encoding the next piece. This is a "fragmented" MOV. Since MP4 is based on MOV, the same applies to MP4.
Does QuickTime 4 even supported fragmented MOVs? Since I couldn't get QT4 to play hardly any of my MOVs anyways, that question remains open...