Wrong rendering batch optimization when using several VideoOutputs with custom video sources

When several VideoOutput elements are used with custom video sources (each providing a different image), it happens that all elements show the same image (usually the one of the VideoOutput with the highest z order).

Only when the z order or the opacity of the elements is changed, the actual images get rendered - though only step by step, depending on the number of VideoOutputs.
The attached demo program illustrates this issue.

We tracked down the source of the bug to a problem related to texture batches in the Qt Quick Scenegraph implementation.

In our case we are using RGB images, therefore QSGVideoNode_RGB gets instantiated. At the beginning, when it does not have a video frame to display (i.e. before its setCurrentFrame method gets called), its associated material does not contain a valid texture.
Afterwards (still before setCurrentFrame), with using multiple VideoOutputs, QSGVideoMaterial_RGB::compare gets called returning zero (because the materials being compared both have an invalid texture). When this happens, both nodes are assigned to the same rendering batch.

Later on, when QSGVideoNode_RGB::setCurrentFrame actually does get called, it updates its material and marks itself as dirty which should force a re-evaluation of the renderer's batches. This however does not happen (there seems to be a code path for this in qsgbatchrenderer.cpp, line 1209), but it does not seem to get triggered and therefore QSGVideoMaterial_RGB::bind() which would actually create a texture with the proper contents does not get called.

Note that this problem is not limited to QSGVideoNode_RGB. QSGVideoNode_YUV and possibly other classes outside Qt Multimedia that handle their texture comparison in a similar way are affected as well.