Every now and again Netflix hosts a hack day, where developers at the company whip up tools that will pause a video when you fall asleep, let you password-protect your user profile, or create custom playlists.
The company held the latest Netflix Hack Day in the first week of March and one team got Netflix to run on an NES game console… seriously.
The darNES hack creates an 8-bit user interface for Netflix and a menu system that can be controlled using the NES game controller. It evenplays videos… they have awful resolution, color depth, and frame rates.
Don’t expect Netflix to release darNES to the public anytime soon.
Another hack that probably won’t see the light of day? BEEP.
That stands for Binge Encouragement and Enforcement Platform and it’s a silly hack that uses face-tracking technology to discover when you’re looking away from the screen. Get distracted by something that’s not playing on Netflix? The screen goes bright red and your computer emits a loud beeping sound to remind you that you’re missing crucial seconds of the latest episode of Unbreakable Kimmy Schmidt… or Kitten Party.
One actually kind of useful hack is called Say Whaaat!!! It displays subtitles when you hit the pause button — even if subtitles are turned off. This lets you catch missed dialog without leaving subtitles on all the time and saves you from having to rewind and listen to the same phrase 6 times before you realize it was in Klingon.
You can check out some of the other Hacks at the Netflix Tech Blog… including one that keeps your partner from watching shows without you by requiring both partners to enter their PIN numbers before a video starts.
Theoretically it’s possible that some of these hacks could eventually be incorporated into the Netflix service… but the company isn’t making any promises.
Is there room left to fake color depth by flickering ? I’ve seen such hack used on Atari demo scene.
This might cut down on my monthly bandwidth. What is the bitrate on that resolution?
Well, it had to fit on a 56k card, and lasted about 10 seconds at least. I’d say about 5kbyte/s unless there were other footage and/or the video was longer than 10 seconds. Probably uncompressed to save CPU time. What I’m more amazed is the fact the NES had the processing power to actually draw this on the screen.
That makes sense, but I honestly don’t believe this was done entirely on the NES or the cart.
I think they had a computer streaming the content on the lowest quality available, and then transcoding it to something 100x lower quality, and then wired into the cartridge somehow.
Another possibility is that they had a small SOC (rasp pi?) built into the cartridge, and it was doing all the work.
There’s no way the NES was able to downscale, even 480 resolution video to this. The CPU power needed to transcode it would orders of magnitude above what the NES contains.
Well, let’s say we use 16 fps and have 10sec video. We can encode it to any format we might want. We already established that we have 5kbyte/sec, so it’s about 320 bytes/frame. We use 4 colours, and 8×8 pixel sprites, so we have 4 pixels / byte uncompressed. The monocolored sprites can be encoded in one byte, the rest would take 16bytes / sprite uncompressed, so about 20 custom sprites / frame. It seems however more efficient to make an analysis and build a sprite tree, something like in the Lempel-Ziv-Welch algorithm. It’s tight, but if there are a lot of monocolored segments and we reuse the rest of the sprites I think we can shoehorn the sample video into the ~50 kbytes with a custom format. The NES has hardware support for sprites and also for fast sprite swapping, and it actually has 4 kbytes of dedicated sprite memory that would hold 256 sprites, and one frame is about 300 sprites (which is neat, because now each 8×8 pixel sprite is 1 byte, so we can cover 320 sprites on each frame from the allocated 320 byte and we only needed 300), and there are many repeats. You can preload the next frame’s sprites ahead too. Moreover you can leave the unmoving sprites from the previous frame on screen to save processing power or could compress heavily because of the unmoving parts with the LZW algorythm (unmoving sprite is only 1 bit now, but some sprites might take up to 2 bytes because of this). I think the system is actually capable of showing this without any custom hardware.
Sure that sounds possible, but what handled the source video? How did a 1500kbps video turn into that low res video?
I don’t know as much about the NES as you do. Can it really handle that data. Nevermind the actual conversion, where did the data even sit during that time?
Oh, you mean you think the source video was actually streamed from Netflix? Nah, my guess it was downloaded, converted and slapped into the code on the card. The NES don’t have any network interface to begin width, and there was no ethernet cable sticking out from the set on the video. Or maybe you are right and there was a RasPi in the cartridge with a WiFi adapter that was downsampling the video to the format the NES could display.
It sure seems like that is what the claim is, I wouldn’t call such a project “Netflix on a NES”, unless it was being streamed.
Well, I was seeing it more like a ‘demake’, like these:
or this:
If it was really streaming from netflix, then you are right, there has to be a WiFi-enabled system in the cartridge.
Okay, guess I was right, it’s stored on the card (which is actually 256 kbyte, so modifying my initial calculations, you get 80 unique sprites for each frame with a buffer for 320 sprites, while a frame is only 300 sprites large).
https://hackaday.com/2015/03/13/darnes-stores-cached-netflix-on-nes-cartridge/