That's right, we're now able to play movie files from an SD card on the ESP32. My little board from PCBWay is now getting slightly bonkers, it's Bowie Heath Robinson. It's definitely time for version 2. Thanks to the Patreons for their support, it's really appreciated, and they've been getting a few updates along the way. And also thanks to PCBWay for supplying these boards. We'll do a new version soon and make use of their services again. They are really great, give them a go. If you're more sensible than me, then you should probably just use an ESP32 board that has an SD card built in, or even just get a display board with one as well. And of course, there's plenty of SD card break-up boards that you can buy. But if you want to have a bit of fun, you can just connect an SD card directly to an ESP32. They use SPI, so in theory it's quite straightforward. There's only 4 signal wires plus power and ground. So I've got a bunch of these micro SD adapters, and if you're careful not to melt the plastic, you can tin the connectors and solder some wires on. There were two ground pins, so to cut down on wires I've just joined these together. We'll need a wire for ground and another for power. And then we need MOSI, chip select, MISO and finally serial clock. These can all be connected directly to our ESP32. And if you're very observant, you'll see me making a complete cock-up here. I've hooked up two of the wires to the USB data pins, that cause quite a bit of head scratching with things randomly connecting and disconnecting. The ground pin connects nicely to our spare ground pin, but unfortunately we've only got one 3.3 volt pad, and that's already used by the display. To avoid accidentally desoldering this, I'm going to take power from the top of these handy decoupling capacitors. Something with version 2 of the PCB is a whole bunch of power connectors. With the two wires moved so they don't conflict with the USB data pins, we now have a working SD card. That's very, very cool. Obviously the real challenge of this project is not connecting up the SD card, it's what we're going to store on the SD card. Most movie container formats are ludicrously complicated and require big libraries to read them, so I consulted with an expert on my options. One reasonable idea would be to convert the movies into two files, one containing the audio data and another containing the motion jpg data, which would just be a sequence of jpg files concatenated together. This would work quite well and would be very easy to process. Another option would be to create my own very simple custom format and interleave the audio and video data with some very simple headers. That's also not a bad suggestion, but there's a couple of downsides to both these approaches. We could probably do the first suggestion using the command line and ffmpeg, but it's a bit of a pain. The second option would need some custom code to convert the video files, which might be fun but feels like more work. The biggest downside with both these suggestions is that you wouldn't be able to view the converted video on your desktop, so it's just not very user friendly. The tiny TV guys use an AVI file to store their videos, and although this is still a bit complicated, this video container is simple enough for us to pass on the ESP32 with fairly basic code, especially if we make some assumptions about what will be in the file and we skip most of the metadata. We can generate an AVI file using ffmpeg, and the resulting file plays nicely on our desktop. If we have a look at the AVI file in a hex dump, we can see how it's made up. In a valid file, the first four bytes are RIFF. That's because the AVI file is actually a subformat of the resource interchange file format. The next four bytes are the length of the file, and then we have another four bytes that tell us this is an AVI file. Following on from this, we have chunks of list data. Within these we have data chunks. We need to find the list chunk that has the subtype movie. This is where our video and audio data can be found. So we just skip through the file, reading the chunk type and chunk length, and then if it's a list chunk, we can check what the subtype is. Once we find the movie subtype, we can start extracting the video and audio data. The video data has type 00DC, followed by four bytes for the length, and if we look at the data we can see that we just have a jpeg file. If we scroll down to the end of the jpeg file, we can find a chunk of audio data. This has the type 01WB. If we search for all occurrences of 00DC, we can see we have a bunch of jpeg frames. That's our motion jpeg. And if we search for 01WB, we can see our audio data. The only slight gotcha which caught me out is that the chunk data is all word aligned. So if you have a chunk data length that is an odd value, you have to read one extra dummy byte to keep within alignment. So it's a reasonably simple file to pass. We just need to locate the list chunk with the movie type and then read each chunk of video or audio data. So as with the network streaming in the previous video, I'm going to read the audio and video data independently. We'll read and play the audio data sequentially and use that to keep track of elapsed playtime. For the video data, we'll read each individual jpeg frame, but if needed we'll allow the code to skip over frames so we can keep instinct with the audio playback. This should keep the audio playing nicely without any stuttering, and we may just drop a few frames now and then due to slow rendering speeds. The code should work on pretty much any ESP32 board. I've got it running here on the cheap yellow display. So that's streaming video from SDcard. If you want to learn about the Wi-Fi streaming version, then watch the video up on the screen right now.
