Calling video comparison to improve the security strength

[oscar-davids]

Calling video comparison functions on results received from different Os

Specific updates (required)

• Add downloading function here to download segmToCheckIndex-th trusted segment.
• Also here call GetSegmentData function to download untrusted segment.
• Call CompareVideoByBuffer to compare two segments before calling CompareSignatureByBuffer.

How did you test each of these updates (required)

• Call video comparison function in chooseResults().
• Passed Unit Test.

Does this pull request close any open issues?

Fix #315

Checklist:

• Read the contribution guide
• make runs successfully
• All tests in ./test.sh pass
• README and other documentation updated
• Pending changelog updated

[leszko]

Looks, good! Good work @oscar-davids

Added 2 minor comments. Other than that, here are some comments things to consider:

1. Traffic-wise, we add downloading the whole segment. I guess it's ok, but just want to double-check it.
2. One optimization would be to check first pHash and only if pHash matches, then download the segment. But not sure we need it because we actually expect pHash to match in most cases.
3. One other optimization could be that we actually download the segment from untrusted O twice. One for the fast verification and later to download the result here. Again, maybe we don't need to change it right now.
4. I didn't check if ffmpeg.CompareVideoByBuffer() works fine and the implication on having some false-negative results.

[oscar-davids]

1. Traffic-wise, we add downloading the whole segment. I guess it's ok, but just want to double-check it.

Yeah, there is additional traffic for downloading the random n-th segment.

2. One optimization would be to check first pHash and only if pHash matches, then download the segment. But not sure we need it because we actually expect pHash to match in most cases.
3. One other optimization could be that we actually download the segment from untrusted O twice. One for the fast verification and later to download the result here. Again, maybe we don't need to change it right now.

I prefer the second optimization path because I think it is a little late to check validity at that time here with the third way.

4. I didn't check if ffmpeg.CompareVideoByBuffer() works fine and the implication on having some false-negative results.

For H264 encoding, it showed 100% accuracy in GPU vs CPU cross-comparison. I think we need to re-evaluate the H265 codec.

[AlexKordic]

Well Done!

[leszko]

LGTM 👍

Thanks for adding the unit test!