The video seems simple profile level 3 mpeg4 video in mpeg TS.

It seems none of the error resilience features of mpeg4 have been used when encoding it. Which is a pitty, had slices been used then the decoder could resume decoding of a frame at the next slice start, had data partitioning been used then the more important low resolution information and motion vectors would have been coded first in each slice making errors less likely to damage them. And had rvlcs been used then slices could have been decoded from both the start and end again, limiting the impact of bit errors.



I know nothing about how the video was generated or how it was transmitted, but if there was some FEC in there then then it should be possible in principle to re-run FEC decoding after manual fixing up all mpeg-TS and mpeg4-ES headers. And as such manual fixing would decrease the errors, FEC would then have fewer errors to deal with and might in a few rare cases be able to fix a few more errors.



Also if some kind of CRCs have been used, CRCs can also be used to correct bit errors as long as the number of errors is sufficiently small, which each CRC would need to correct, the exact number that could be corrected that way depends on the packet size and crc polynomial being used.



My [outside the industry, and not a video expert either] guess is that the the reason they didn't enable them here is that the mpeg data has been extracted from a telemetry stream, and what we are seeing is after their own decryption/forward error correction/CRC was performed. For minimizing data rate or other reasons perhaps they decided not to double up error-correction, since it was already being done. I suspect they are probably required to encrypt the data stream for ITAR reasons and therefore couldn't release pre-error-corrected raw telemetry even if they wanted to.And by the way-- amazing effort so far, by all involved.