Lacking a DVD drive, [jg] was watching a TV series in the form of a bunch of .avi video files. Of course, when every episode contains a full intro, it is only a matter of time before that gets too annoying to sit through.
The usual method of skipping the intro on a plain video file is a simple one:
Manually drag the playback forward past the intro.
Oops that’s too far, bring it back.
Ugh reversed it too much, nudge it forward.
Okay, that’s good.
[jg] was certain there was a better way, and the solution was using audio fingerprinting to insert chapter breaks. The plain video files now have a chapter breaks around the intro, allowing for easy skipping straight to content. The reason behind selecting this method is simple: the show intro is always 52 seconds long, but it isn’t always in the same place. The intro plays somewhere within the first two to five minutes of an episode, so just skipping to a specific timestamp won’t do the trick.
The first job is to extract the audio of an intro sequence, so that it can be used for fingerprinting. Exporting the first 15 minutes of audio with ffmpeg easily creates a wav file that can be trimmed down with an audio editor of choice. That clip gets fed into the open-source SoundFingerprinting library as a signature, then each video has its audio track exported and the signature gets identified within it. SoundFingerprinting therefore detects where (down to the second) the intro exists within each video file.
Marking out chapter breaks using that information is conceptually simple, but ends up being a bit roundabout because it seems .avi files don’t have a simple way to encode chapters. However, .mkv files are another matter. To get around this, [jg] first converts each .avi to .mkv using ffmpeg then splices in the chapter breaks with mkvmerge. One important element is that the reformatting between .avi and .mkv is done without completely re-encoding the video itself, so it’s a quick process. The result is a bunch of .mkv files with chapter breaks around the intro, wherever it may be!
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.
According to [Mike Walters], the Elgato Cam Link 4K is a great choice if you’re looking for a HDMI capture device that works under Linux. But the bad news is, it wouldn’t work with any of the video conferencing software he tried to use it with because they expect the video stream to be in a different pixel format. For most people, that would probably have been the end of the story. But you’re reading this on Hackaday, so obviously he didn’t give up without a fight.
Early on, [Mike] found there was a software workaround for this exact issue. The problem isn’t that the Elgato can’t generate the desired format, it’s that the video conferencing programs just don’t know how to ask it to switch modes. The software fix is to create a dummy Video4Linux device and use that to change the format in real-time using ffmpeg. It’s a clever trick if you’ve got a conference call coming up in a few minutes, but it does waste CPU resources and adds some unnecessary hoop jumping.
Inspired by the software fix, [Mike] wondered if there was a way he could simply force the Elgato to output video in the desire format by default. He found a firmware dump for the device online, and found where the pixel formats were referenced by searching for their names in ASCII with hexdump. Looking through the source for the Linux USB Video Class (UVC) driver, he was then able to determine what the full 16 byte sequence should be for each video mode was so he could zero out the unwanted ones. Then it was just a matter of flashing his modified firmware back to the hardware.
But there was a problem: with the modified firmware installed, the device stopped working. After investigating the obvious culprits, [Mike] broke out the oscilloscope and hooked it up to the Elgato’s flash chip. It turns out that due to a bug in the program he was using, the SPI erase commands weren’t getting sent during the flash. This lead to corrupted firmware which was keeping the Elgato from booting. After making a pull request with his fixes, the firmware flashed without incident and the capture device now does double-duty as a webcam when necessary.
We could certainly think of easier and quicker was to roll your own webcam, but we’re glad that [Mike] took the time to modify his Elgato Cam Link 4K and document it. It’s a fantastic example of practical firmware hacking, even if you’re not in the market for a new high-definition video conferencing rig.
There is a treasure trove of history locked away in closets and attics, where old shoeboxes hold reels of movie film shot by amateur cinematographers. They captured children’s first steps, family vacations, and parties where [Uncle Bill] was getting up to his usual antics. Little of what was captured on thousands of miles of 8-mm and Super 8 film is consequential, but giving a family the means to see long lost loved ones again can be a powerful thing indeed.
That was the goal of [Anton Gutscher]’s automated 8-mm film scanner. Yes, commercial services exist that will digitize movies, slides, and snapshots, but where’s the challenge in that? And a challenge is what it ended up being. Aside from designing and printing something like 27 custom parts, [Anton] also had a custom PCB fabricated for the control electronics. Film handling is done with a stepper motor that moves one frame into the scanner at a time for scanning and cropping. An LCD display allows the archivist to move the cropping window around manually, and individual images are strung together with ffmpeg running on the embedded Raspberry Pi. There’s a brief clip of film from a 1976 trip to Singapore in the video below; we find the quality of the digitized film remarkably good.
Hats off to [Anton] for stepping up as the family historian with this build. We’ve seen ad hoc 8-mm digitizers before, but few this polished looking. We’ve also featured other archival attempts before, like this high-speed slide scanner.
It’s cold outside! So grab a copy of the Hackaday Podcast, and catch up on what you missed this week.
Highlights include a dip into audio processing with sox and FFMPEG, scripting for Gmail, weaving your own carbon fiber tubes, staring into the sharpest color CRT ever, and unlocking the secrets of cheap 433 MHz devices. Plus Elliot talks about his follies in building an igloo while Mike marvels at what’s coming out of passive RFID sensor research.
And what’s that strange noise at the end of the podcast?
The GOES-R series of Earth observation satellites are the latest and greatest NASA has to offer. As you might expect, part of the GOES-R job description is imaging Earth at high-resolution, but they also feature real-time lighting monitoring as well as enhanced solar flare and space weather capabilities. Four of these brand new birds will be helping us keep an eye on our planet’s condition into the 2030s. Not a bad way to spend around 11 billion bucks.
To encourage innovation, NASA is making the images collected by the GOES-R satellites available to the public through a collaboration with Google Cloud Platform. [Ben Nitkin] decided to play around with this data, and came up with an interactive website that let’s you visualize the Earth from the perspective of GOES-R. But don’t let those slick visuals fool you, the site is powered by a couple cron jobs and some static HTML. Just as Sir Tim Berners-Lee intended it.
But it’s not quite as easy as scheduling a wget command; the images GOES-R collects are separated into different wavelengths and need to be combined to create a false-color image. A cron job fires off every five minutes which downloads and merges the raw GOES-R images, and then another cron job starts a Python script that creates WebM time-lapse videos out of the images using ffmpeg. All of the Python scripts and the crontab file are available on GitHub.
Finally, with the images merged and the videos created, the static HTML website is served out to the world courtesy of a quick and dirty Python web server. The site could be served via something more conventional, but [Ben] likes to keep overhead as low as possible.
Skywatching is a fascinating hobby, but does have the rather large drawback of needing to be outside staring at the sky for extended periods of time. Then there’s the weather to contend with, even if you’ve got yourself a nice blanket and it isn’t miserably cold, there might be nothing to see if cloud cover or light pollution is blocking your view.
The software side is fairly straightforward: 10 second exposures are taken all night long, which can then be stitched together with ffmpeg into a timelapse video. [Jason] was concerned that the constant writing of images to the Pi’s SD card would cause a premature failure, so he set it up to write to a server in the house over SSHFS. Adding a USB flash drive would have accomplished the same thing, but as he wanted to do the image processing on a more powerful machine anyway this saved the trouble of having to retrieve the storage device every morning.