Trusted Timestamping
I think, if you continue down this line of thinking, you will end up with something very similar to Trusted Timestamping Servers.
The core idea of trusted timestamping is that you submit a file to the server and it signs an attestation saying that it saw the file with hash aabbcc112233 at time X. This is typically used for both proving the initial publication time (and who published it), as well as proving that the file has not been modified since.
You need the trusted 3rd party because if the end-user creating the video is the same person signing it, then there's nothing stopping them from re-signing it after they edit it.
Why not just save the video stream on the server?
That said, I don't think you really need any fancy crypto here; the simplest solution is probably best. Have the student live-stream their cameras to an exam-monitoring website. The website logs the video stream in its database as it comes in, and it can detect and alert if the live stream had any breaks or disruptions long enough for manual editing to potentially have taken place.
Create a blockchain of the video stream
Update addressing comments.
Ah, you have the extra privacy requirement that students do not want their video stored on 3rd party servers (that should have been in the question!).
In that case, what makes this problem hard is that you can't wait until the end of the exam and publish a single hash for the entire video because that gives the student too much time to edit a middle section of the video. The solution that comes to mind would be some kind of hash-block-chaining (not "The Blockchain (Bitcoin)" but "a blockchain"). Either the sender or receiver breaks the video stream into, for example, 10 s "blocks", hash each block as they are produced/recieved, and stream the hash for each block along with the video in real-time. You do "block-chaining" by including in each block the hash of the previous block. In math notation:
h_0 = hash(videoblock_0)
h_1 = hash(videoblock_1 || h_0)
...
h_n = hash(videoblock_n || h_n-1)
This preserves privacy because the server only needs to store the hashes and not the video itself. This is streaming-friendly because you are producing hashes throughout the stream and each hash covers the entire stream up to that point. This is efficient because the server only needs to store the most recent hash (h_n), and that is enough to later verify if a provided video was tampered with at any point in the stream (though to detect where it was tampered you would need to save every block hash).