admin wrote:
If quant matrices change, though, there is no workaround and we have to wait for a driver fix.
Is your workaround safe in that case ? Also, it's possible that i didn't understood this statement properly, and you were not comparing this case with your workaround.
And i thought you were not sure your workaround may not break things in specific cases, but as it was just my thought/feeling, it may be wrong also.
The CUVID bug was this: When a sequence header is encountered that differs from the previous one, the next GOP is erroneously marked as bad link, meaning the referenced frames in the preceding GOP are discarded. That caused macroblocking at that point. A sequence header change should NOT mark the GOP as bad link.
In the case of the stream offered here, the only change in the sequence header was the signaled bit rate. But CUVID does not use this field in any way (other than when comparing the sequence header). That allowed me to simply always write it as 0, so that CUVID would not see a change in the sequence header. If, however, the quant matrices would change, I cannot write those to 0 because decoding would then fail miserably. In that case, the CUVID bug would be triggered with no possible workaround.
So: The workaround is unconditionally safe because it simply writes a field that is never used. I never thought it would break anything. But I did speculate that some streams may be encountered for which the workaround is useless.