E-Paper Display Shows Movies Very, Very Slowly

How much would you enjoy a movie that took months to finish? We suppose it would very much depend on the film; the current batch of films from the Star Wars franchise are quite long enough as they are, thanks very much. But a film like Casablanca or 2001: A Space Odyssey might be a very different experience when played on this ultra-slow-motion e-paper movie player.

The idea of displaying a single frame of a movie up for hours rather than milliseconds has captivated [Tom Whitwell] since he saw [Bryan Boyer]’s take on the concept. The hardware [Tom] used is similar: a Raspberry Pi, an SD card hat with a 64 GB card for the movies, and a Waveshare e-paper display, all of which fits nicely in an IKEA picture frame.

[Tom]’s software is a bit different, though; a Python program uses FFmpeg to fetch and dither frames from a movie at a configurable rate, to customize the viewing experience a little more than the original. Showing one frame every two minutes and then skipping four frames, it has taken him more than two months to watch Psycho. He reports that the shower scene was over in a day and a half — almost as much time as it took to film — while the scene showing [Marion Crane] driving through the desert took weeks to finish. We always wondered why [Hitch] spent so much time on that scene.

With the proper films loaded, we can see this being an interesting way to really study the structure and flow of a good film. It’s also a good way to cut your teeth on e-paper displays, which we’ve seen pop up in everything from weather stations to Linux terminals.

12 thoughts on “E-Paper Display Shows Movies Very, Very Slowly

    1. You’d then need a separate device to decode the video and send the frames to the STM32, plus you’d need connectivity of some sort to send the frames to it in the first place. This way it’s all self-contained.

    2. It’s definitely feasible with an AVR chip if you preprocessed the data, dumped the entire concept of a filesystem and just used the microSD card as a massive SPI memory chip.

      1. You can do FAT32 and even exFAT with an AVR (See SdFat-beta project on github), so I think you could keep a file system. And there’s TJpgDec, so you might even be able to get with pre-processing the film to MJPEG. Code space would be tight.

        1. It is doing FAT32, but, exFAT would be a trivial move. FAT32 supports up to 4TB volumes. The issue I had to work around is most microSD cards no longer support SPI. But, if you use “fullsd.c” then it uses them in SCSI mode and you’re good to go. Should work fine on even massive stores. Because you’re down in the very low color depth modes, other, more traditional compression schemes would likely work better. For me, I didn’t need any compression, being 2 pixels per byte, so I just rolled with it.

    3. Can’t run ffmpeg on thaso so you’d either need to implement your own decoder or preprocess all the frames.

      I guess you could stream them from a media server that can transcode to motion jpeg but I don’t know how mediaservers react when you pull 5 frames every 2 minutes. Sounds likely they’ll time you out and abort.

  1. I too was captivated by the original idea https://hackaday.com/2018/12/30/the-very-slow-movie-player-does-it-with-e-ink/

    At the time, no source code was available – so I cooked up something simple that ran on a Raspberry Pi https://github.com/andrewlow/VSMP

    Personally – I picked a visually amazing film to run on one of the big wall mounted TVs at the office – Inception. I did a full HD rip at high quality (MakeMKV & HandBrake) to get it to 6GB so I could fit it on the SD card I was using.

Leave a Reply to arnoldexe Cancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.