easter egg: bad apple in favicon

[JasonYao]

This is a godawful, terrible, and useless to society idea.

So naturally I wanna see if it'd be possible. General user flow would be:

1. User goes to my website, inputs some variant of konami code (up, up, down, down, left, right, left, right, B, A and RETURN could do the trick
2. This fetches a compressed data pack of Bad Apple video in bit-map form (since it's a bitone already)

• We get this by exploding out the mp4 frame by frame at 24 frames per second, decimating each image to the resolution desired for favicons.
• Then, for each frame, we pack it into a buffer where each bit represents a pixel, so 4 bytes (for a 16 x 16 image size, there's 256 pixels, divided by 8 bits in a byte for 32 bytes of binary data for a single frame)

3. Upon reading this flat video content buffer, we process (iterate by 32 byte intervals) through it, generating an image in-memory
4. We then begin calling whatever it is that updates the favicon every 1s / 24 frames = 0.041s per frame (might wanna time how long the favicon update takes). Alternatively, we could just swap the image the favicon is pointing to every 0.041s, and keep the favicon link stable (not sure if favicon is just cached though)

Open questions to address at the start here

Step 1 can be done with an event listener, step 2 just with an API call to download bad apple which can be done pretty easily. Step 3 is an unkown, and there's a question of timing in step4 where we want to know how long the favicon update took.

• "Can I update the favicon programmatically?"
  • yes, https://stackoverflow.com/a/7116701
  • Followup: "how fast will it update?"

[JasonYao]

looks like 100ms it won't update, 150 seems to work, and 125 might work with a few frame drops. At:

Let's say we go with 30s of bad apple to start.

150ms interval

150ms interval time: 1000ms / 150ms = 6.6666 frames per second
30s of content * 6.6666 frames per second = 200 frames
200 frames * 32 bytes per frame = 6400 bytes

125ms interval

125ms interval time: 1000ms / 125ms = 8 frames per second
30s of content * 8 frames per second = 240 frames
240 frames * 32 bytes per frame = 7,680 bytes

[JasonYao]

https://stackoverflow.com/a/5568484 might have a mechanism for us to have a data link instead of a naive href, enabling us to keep this all in memory.

With that, we've shown that with the bare minimum capabilities, this project is feasible.

[JasonYao]

split this into 2:

article: "playing bad apple in favicon"

build log: talk through stages:

1. Enumerating Cknown unknowns (rendering speed of favicons etc from above)
2. building out a throwaway barebones demo that only tests for what i'm looking for
3. building out the image buffer script generation (can parameterize decimation size & frame rate)
4. building out buffer frame extractor that iterates over the image buffer, and testing that it works for a few frames
5. integrating this into my personal site

[JasonYao]

stage 3 notes

• Use youtube-dl to download the mp4 with brew install youtube-dl && youtube-dl FtutLA63Cp8
• opencv seems to be the most common python library to go from a .mp4 file into individual frames that are in python
• doing just the python install opencv gave black images, since it read in array of bytes as 0.
  brew install opencv
  which does brew install ffmpeg under the hood worked from https://stackoverflow.com/questions/15662827/writing-an-mp4-file-on-the-mac-with-opencv-ffmpeg

[JasonYao]

alternatives to mention:

• embedding the video directly
  • not as fun
• Converting the video to a gif and setting the favicon to the gif
  • gifs aren't supported outside of firefox (https://superuser.com/questions/1484570/how-can-this-stack-exchange-site-have-an-animated-favicon)
• Using canvas to update the favicon every 60ms (https://css-tricks.com/the-making-of-an-animated-favicon/)
  • might be possible, given that the rendering time is much faster than the max rendering time for the direct method
• directly setting the favicon and forcing a re-render
  • drawback: doesn't seem to work in FF for intervals of less than 125ms