The Randall Museum in San Francisco hosts a large HO-scale model model railroad. Created by the Golden Gate Model Railroad Club starting in 1961, the layout was donated to the Museum in 2015. Since then I have started automatizing trains running on the layout. I am also the model railroad maintainer. This blog describes various updates on the Randall project and I maintain a separate blog for all my electronics not directly related to Randall.
2021-11-27 - New Version for Train Vision
Category RandallConcluding 4 days of work, this morning I installed the new version of the vision software on the Vision computer at the museum for the Train Vision Project.
The project has three cameras looking at the layout and displays live videos when it detects trains. In the initial version, that video was really choppy. It was fine when I was experimenting with this on the wifi at home, but the same cameras + laptop resulted in a really bad frame rate when using the sub-par wifi in the train room.
So I spent the Thanksgiving break entirely rewriting that part of the software. In the previous version I was using the FFmpegFrameGrabber to get the cameras’ RTSP h264 feed, analyzing the frames for motion, and then feeding them to the display by drawing them directly with a Canvas in a JPanel. That was really not optimal. In the new version, I replaced the custom viewers by instances of VLCj in Direct Rendering mode, so now I have VLC driving the RTSP feed, and I use the reverse where the VLCj decoded frames are fed to the motion analyzer. They all work in their respective threads with blocking queues for synchronization.
The result is that the videos are really better looking now. Not choppy anymore. I also reconfigured the cameras to boost the contrast and saturation as the image was rather bland -- I overdid that part a tad much, I need to tune it down now.
The only downside is that CPU usage really went up, which makes sense since I now have 3 VLC viewers in 1280x720 @ 15 fps doing their work where before I had 3 meager 640x480 feeds at some very irregular frame rate. But that’s fine, because now I can underclock the analyzer threads and run them at 5 fps -- they don’t need to detect motion on every single frame. Overall the software now runs at 50-75% on the 4 CPU i7 cores which is on par with what I had before, but with better quality.
The last thing I’ve done is add a statistics collector for debugging purposes that can export the motion events to the chrome://tracing json format:
That should allow me to fine tune the motion detection thresholds.