You have to start with hardware you trust. This hardware has a difficult to breach trusted core chip. In that trusted core chip, it has a secret cryptographic signing module.
Each component in turn has a slightly less secure identity that it validates with the core chip, and the entire system refuses to work if they aren't all valid and running valid firmware and software.
Next you produce a series of trusted timestamp tokens that include the crytographically secure hashes of the video segments in a blockchain.
Each token is signed by a 3rd party trusted timestamp server, and includes the hash of the previous token plus a hash of the current segment of video.
PreviousToken: HASH_TEXT
CurrentBlob: HASH_TEXT
Timestamp: XXX GMT
TrustedTimestampSignature: BLAH BLAH BLAH
They transmit
PreviousToken: HASH_TEXT
CurrentBlob: HASH_TEXT
to the trusted server, who responds with
PreviousToken: HASH_TEXT
CurrentBlob: HASH_TEXT
Timestamp: XXX GMT
TrustedTimestampSignature: BLAH BLAH BLAH
and this resulting token is guaranteed to have been produced prior to the time written there by the 3rd party timestamp server.
The above is then signed by the trusted hardware
PreviousToken: HASH_TEXT
CurrentBlob: HASH_TEXT
Timestamp: XXX GMT
TrustedTimestampSignature: BLAH BLAH BLAH
Latency: ZZZ nanoseconds
MaxLatency: YYY nanoseconds
HardwareFailures: QQQ
TrustedHardwareSignature: BLAH BLAH BLAH
where the trusted hardware promises that the video blob was produced by the video hardware within a certain number of nanoseconds of the timestamp from the 3rd party server being placed on it.
Then the hardware and software proceeds to record the next segment, which in turn uses a hash of the above to link it to the previous segment.
When you are all done, you transmit one token to the proctor:
PreviousToken: HASH_TEXT
CurrentBlob: HASH_TEXT
Timestamp: XXX GMT
TrustedTimestampSignature: BLAH BLAH BLAH
Latency: ZZZ nanoseconds
MaxLatency: YYY nanoseconds
HardwareFailures: QQQ
TrustedHardwareSignature: BLAH BLAH BLAH
From this, you cannot get the video the student produced.
But if the student produces that video later, plus the tokens that where not transmitted, the proctor can prove that the video provided was recorded during the exam, was continuous, and was from trusted hardware.
I included enough information in my token that if a technical problem happened (there was a network outage that was long enough to make the security not work, for example), the proctor can determine that this happened from the metadata.
So if someone tries to cheat by inducing networking errors or hardware failures, this shows up before investigation for cheating from other evidence. And if there is such a failure, they can get the student to do another exam and ignore the contents of the failed one, without even looking for other signs of cheating, based on whatever criteria they choose.
Alternatively, your system could just treat any hardware failures, or communication latency beyond a certain value, as a refusal to continue to sign the tokens.