I suspect that there are a couple of obnoxious complications; but at least one handy ffeature you get 'for free' in designing a suitably trustworthy and open camera.
On the minus side, openness and trustworthiness are...slightly at odds. For high reliability, you want a camera that signs footage with a key that the user cannot access, except for the specific purpose of the signing, and time-stamps the footage with a secure RTC that cannot be tampered with once initialized. If the user can access the signing key, they could simply strip the original signature metadata, modify the video, and then have their video editing program neatly sign everything back up as though it were fresh off the camera. Similarly, if the RTC could be manipulated it would be much easier to elide inconvenient context(of course, if the signing key isn't protected the RTC is irrelevant because you can just rewrite the timestamps and sign the altered footage).
This set of requirements basically turns into our old friend the TPM once you have a go at implementing a general purpose version of it. Additional DRM-esque verification between the CCD/CMOS sensor and the encoder might also be necessary to prevent a man-in-the-middle processing and rewrite of the data passing over the MIPI interface before it reaches the video encoding and signing steps. Basically HDCP; but for input.
These issues aren't insurmountable(nor are they obviously necessary to reach sufficient plausibility for admissibility as evidence); but they don't mesh well with free and open design, since they place a 'trusted' root in a black box where the user can't see it.
A second issue, likely to complicate some(though definitely not all) rooted/3rd-party-firmware camera modifications is that power efficiency demands appear to have driven gopro-style cameras a fair distance away from general-purpose computing. As best I can tell, the gopros are based on Ambarella Camera SoCs, which do have a general purpose ARM core; but a very feeble one. All the heavy lifting happens in dedicated blocks for the MIPI interface, h.264 encode and decode, and mass storage control.
Depending on exactly which SoC is used(other vendors also exist; and smartphone chipsets commonly include many of the same functional blocks) and how high the video bitrate is it may or may not be possible for a software change to add cryptographic hashing and signing operations into the video processing chain, which is otherwise composed of fixed-function blocks that shove data from the sensor to the SD card as fast as possible. Much more likely to be possible on a full smartphone(where Android Camera RAW and similar have increasingly demanded low level access to the image processing chain), much less likely on low-cost/long-run-time heavily embedded devices that have just enough CPU to catch button inputs, run a spartan GUI, and feed a few config parameters to the fixed function blocks. It's a hell of a lot more efficient than a PC-style UVC video input arrangement; but it may be a fairly opaque one.
Doom and gloom aside, while robust tamper-resistance/tamper-evidence is the goal to shoot for, the power of video evidence produced even on generic junk cellphones appears to be considerable, and the 'Ah, that bystander must have used his elite photoshop skillz to produce false evidence!' argument is currently confined to the fevered paranoia of patrolman's benevolent associations...
Plus, even if skepticism grows, there is the handy feature of silicon image sensors: like Tolstoy's unhappy families, every silicon sensor is defective in its own way. Unique pattern of more and less sensitive pixels, especially visible in dark field exposures and low light conditions generally. Definitely not as mathematically incontrovertible as a robust cryptographic implementation; but you get it thrown in for nothing with any sensor that isn't running in a liquid helium bath and it makes covert tampering, compositing from multiple cameras, or similar shenanigans much trickier.
One additional consideration: Given the enthusiasm of Our Peace Officers for 'safeguarding' and/or smashing recording equipment, a robust mechanism for exfiltrating captured video as quickly as possible seems like a worthy consideration. In the case of a device with a wireless data link, you'd want an upload client for one or more video services that can be operated with a 'write only' authentication token(rather than a stored username and password or full oauth). The credential must be stored, since you won't have time to type it in when the situation strikes; but it can't allow an attacker who physically seizes the device to delete footage or compromise the account. Hence a 'write only' auth token that allows uploading of additional video; but not modification or deletion of previously uploaded material or account particulars.
If wireless data is unavailable(uneconomic, jammed, underground) a short-range redundancy system that copies the output to one or more physically separate 'slave' storage units to preserve it in the event of the seizure of the visibly camera-like bit would be handy. A microSD card, battery, and antenna can fit unobtrusively virtually anywhere, and are much less likely to be noticed and seized if not attached to the lens module.