[HN Gopher] Recording 660FPS Video on a $6 Raspberry Pi Camera (...
___________________________________________________________________
Recording 660FPS Video on a $6 Raspberry Pi Camera (2019)
Author : tosh
Score : 193 points
Date : 2021-12-27 15:35 UTC (7 hours ago)
(HTM) web link (blog.robertelder.org)
(TXT) w3m dump (blog.robertelder.org)
| mahalol wrote:
| Great timing on this article. I have a rpi4 and a pi cam v2 which
| I want to have some fun with and was in need of inspiration. I am
| currently using it as a security camera while I am away on
| holiday but wish to have a play both with slow motion video and
| perhaps some object detection using opencv. The latter I have
| already tried but all the articles I found seem out of date so I
| will need to spend some more time on.
| TomJansen wrote:
| Would it also be possible to increase the exposure time to above
| the 10 seconds which is officially supported by the raspberry pi
| V2 camera?
| adolph wrote:
| I'm interested in synchronizing sensor data to the camera stamps.
| For example, strain gauge to measure model rocket engine
| performance. Does anyone know of a project or approach that would
| allow for synced high speed sensors?
| AlexAltea wrote:
| This is possible by interfacing directly with the sensor MMIO
| registers. I've always found fascinating how much flexibility
| hardware provides, compared with the typically rigid
| functionality the drivers expose to userland.
|
| I wonder what we could make out of many high-end cameras if only
| we had enough patience and motivated people to reverse engineer
| everything that has been hidden away by comfort abstractions.
| vhiremath4 wrote:
| for anyone wondering, "MMIO registers" stands for "memory-
| mapped I/O" registers:
|
| https://en.wikipedia.org/wiki/Memory-mapped_I/O
| BolexNOLA wrote:
| If you want the answer to that question, look no further than
| the magic lantern project. It's not supported like it used to
| be, but those guys were incredible at unlocking what Canon
| DSLR's could really do. I was a legend in my film community
| when I booted it onto a 5Diii and got it shooting 1080p raw.
| All I did was follow their instructions lol
| austinpena wrote:
| Those guys were my intro to tech! I remember shooting RAW on
| an old 50d and Dual ISO on my 6d!
| lovelyviking wrote:
| Last time I've checked there was nothing like that for Nikon?
| What is the reason? Or there is something?
| formerly_proven wrote:
| I've heard that Canon's DIGIC processors are just slightly
| customized versions of the DaVinci media processors, which
| have a all documentation openly available, while Nikon's
| EXPEED processors are based on a closed product line by
| Socionext with basically zero public documentation and
| heavy customization.
|
| Though there used to be a project which worked on a few of
| the older EXPEED-based cameras.
| bserge wrote:
| Magic Lantern is a firmware mod for Canon cameras and it gives
| you more features and control over _your_ hardware. I love this
| kind of low level mods.
|
| https://magiclantern.fm/features.html
| sidpatil wrote:
| Also see CHDK [1], a FOSS firmware replacement for Canon
| point-and-shoot cameras.
|
| [1] https://chdk.fandom.com/wiki/CHDK
| pishpash wrote:
| Ironically, I find the popularity of hardware hacks to be a
| sign of general stagnation, because there were periods of
| time in the past when they would not give as much boost in
| performance as a new version of something in a few months to
| a year. They were typically not worth the time and would be
| rendered obsolete, but now more and more they are worthwhile.
| BolexNOLA wrote:
| Magic Lantern basically is the reason my t3i got me into film
| festivals lol
| pstoll wrote:
| Link is dead.
| pengaru wrote:
| works for me
| thecatster wrote:
| Dead for me too.
| cgriswald wrote:
| Does it work currently? I can't get the domain name to
| resolve.
| spijdar wrote:
| Okay, that's bizarre. When I first clicked the link, the
| domain name failed to resolve for me too. When I reloaded
| it, though, it resolved. If anyone else is having
| trouble, give it a bit and try reloading the page.
| nickphx wrote:
| the domain magiclantern.fm expired on 12/13/21, it's name
| servers were updated on 12/27 to EXPIRED.DNAPI.NET
| DOMAIN.DNAPI.NET
|
| 25.0%: Refused at domain.dnapi.net (193.227.117.66)
|
| 25.0%: Refused at expired.dnapi.net (194.50.187.66)
|
| 25.0%: Query timed out at dns1.idnz.net (108.166.170.106)
| While querying domain.dnapi.net/IN/A
|
| 25.0%: Query timed out at dns1.idnz.net (108.166.170.106)
| While querying expired.dnapi.net/IN/A
|
| Some opendns resolvers have it cached still: 176.9.31.214
| jandrese wrote:
| I've tried to resolve the domain via 8.8.8.8, 1.1.1.1,
| 9.9.9.9, 208.67.222.222, and 4.2.2.1 without luck. They
| all return _status: SERVFAIL_.
| lelandfe wrote:
| https://www.reddit.com/r/MagicLantern/comments/rpvv2n/fyi_s
| i...
|
| They are aware and are working on it.
|
| Archive: https://web.archive.org/web/20211210011209/https:/
| /magiclant...
| spondyl wrote:
| Seems confirmed by the Magic Lantern team: https://old.redd
| it.com/r/MagicLantern/comments/rpvv2n/fyi_si...
| helge9210 wrote:
| > everything that has been hidden away
|
| It's not hidden, it's stripped according to actual product
| specs.
|
| Industrial cameras (Basler/IDS) will give you access to most of
| the sensor capabilities if you want to prototype something.
| kbouck wrote:
| As webcams were hard to come by during the onset of the pandemic,
| I resorted to a raspberry pi + HQ cam + lens + raspistill preview
| + HDMI capture device (instead of usb). I won't defend the total
| cost (probably more than an acceptable webcam). The HQ cam
| results were quite good and seemingly high enough framerate (not
| 660 fps though!). Added benefit is interchangeable lens options
| including ones that will give the bokeh effect.
| adolph wrote:
| _The major limitation throughout this process is the speed at
| which memory can be copied and transmitted. Only 20-40 seconds of
| video can be recorded at a time due the memory exhaustion of the
| Raspberry Pi. Also limited is the resolution of the recording: On
| the $6 camera, a maximum of 640x64 resolution can be recorded due
| to limitations on memory bandwidth._
| randomluck040 wrote:
| Would it be possible to go for a lower framerate and gain more
| flexibility regarding the resolution?
| BolexNOLA wrote:
| That's how it works with more conventional camera set ups. I
| guess it just boils down to how they program it but there's
| no reason that shouldn't be the case.
| tosh wrote:
| Does anyone know if that means the Pi 4 can record for a longer
| period of time (it supports up to 8GB RAM iirc)?
| bick_nyers wrote:
| I haven't read the article, but the parent comment makes it
| sound as though it's not so much the capacity of the bus, but
| rather the speed of the bus itself. This is usually expressed
| in terms of a combination of CAS latency and frequency in
| MHz, the Pi 4 being DDR4, is likely in the neighborhood of
| 2133-3600Mhz. We don't often think of reading/writing to RAM
| as taking any time at all, but in all actuality the speed of
| memory is often a significant bottleneck in high performance
| systems.
|
| If we are just talking about 720p 30fps, then we likely
| aren't really that close to those memory bottlenecks, so the
| only limiting factor would be how much storage space you have
| available to that device.
| LaputanMachine wrote:
| According to the video in the article, the data rate is 66
| MB/s (100kB per frame). So a Pi with 8GB of RAM should be
| able to capture almost 2 minutes of footage.
| up6w6 wrote:
| Would parallelizing it to two distinct cores help with the
| issue?
| jandrese wrote:
| Not if you're bottlenecked on memory bandwidth or capacity.
| adolph wrote:
| From my reading of the issue, no. The limiting factor on the
| Pi side is available storage buffer. The camera sends raw
| files down the wire and the app caches them in RAM before
| concatenating them with ffmpeg. Could a Pi4 with USB3 NVMe be
| used? Maybe, if the writes are faster than the camera.
|
| https://www.jeffgeerling.com/blog/2020/fastest-usb-
| storage-o...
| seba_dos1 wrote:
| No, this is about memory bandwidth.
| justin66 wrote:
| It looks like the repo [0] hasn't been touched in a couple of
| years so it's tough to say what if anything would need to
| change, but this application sounds like it would benefit from
| a Pi 4.
|
| [0] https://github.com/RobertElderSoftware/PatientTurtle
| matheweis wrote:
| This could be a big step toward ultra low latency streaming with
| an rpi.
|
| I tried to do this (low latency streaming) circa 2016 and ran
| into two issues, one of which was the high framerate or subframe
| capture and the other was subframe encoding.
|
| With high framerate capture you can fake the subframe capture by
| capturing a whole frame and encoding just a subset.
|
| Now to get the h264 drivers to do subframe encoding...
___________________________________________________________________
(page generated 2021-12-27 23:00 UTC)