Don't update sps if they are only repeated

[coldtobi]

This is an attempt to improve the mitigations from #365 and #366.

The mitigations in the PR assumes that sps with different pointers are incompatible; however, when new sps are encountered, always a new sps object is created, leading to an over-rejection of sps, as they might just have been repeated with compatible information. I guess this over-rejection might cause that images cannot be decoded, which would otherwise be decode-able.

It picks up the idea from #345 (comment):

One way would be just to look at the pointers of the SPS (fast and easy, but may reject more than required), or investigate if the SPS used for the image generations are "compatible".

This changes do exactly this: It (very conservativly -- as in "use new one if in doubt") checks if the old and new sps have identical information -- except the reference picture set, which I believe is supposed to be updated by new sps'). If they are basically identical, the old sps will be used instead of the new one, (of course, reference image set is updated from the new one)

I'm using standalone operator== and helper functions to avoid changing ABI of the library; if an ABI bump would be done, of course this should go to the respective classes.

I've tested the patch with several videos, they still play fine.

@farindk I'd really appreciate to receive your feedback; the reason is that I want to fix the many open CVE's for the package as it is currently in Debian and other distributions…

--
Cheers,
tobi

[farindk]

The CVEs have been fixed in another way, but I leave this open as it would be nice to have a check like this that can detect when there was an illegal SPS switch in the input stream.

[coldtobi]

thanks @farindk for your work on all of those issue. Do plan to cut a new release soon? Asking, because Debian is entering freeze in around two weeks and it would be nice to have your official version in the next stable…

[farindk]

@coldtobi Yes, I've just released v1.0.10.