Now that totem uses playbin2 (and decodebin2), an issue I never noticed has just popped up.

In decodebin2, during preroll (filling up the stream groups) the max-size-time of the multiqueue is 5s, allowing pretty much every heavily interleaved file to be prerolled correctly...

... but then when that group is exposed, the max-size-time is set back to 2s ... which makes all files with an interleave greater than 2s screw up massively (read: qos kicks in, stuttery playback with low bandwith/cpu-usage but high interleave files/streams).

The max-size-time limit is too low for most files.

My proposal is, when exposing the gruops, to *not* modify the max-size-time (i.e. leaving it at the 5s initial value) but still reduce the max-size-buffer/max-size-bytes sizes.

With that modification, the 100+ files I tested which have that regression now work fine.

I'm marking this as a blocker, otherwise we're going to have a *really* bad experience with playbin2 (and totem now it supports it) for the next 3 months.

This doesn't prevent us from doing the *proper* fix which is for demuxers to output GST_EVENT_BUFFER_SIZE events with their interleave parameters and multiqueue taking them into account for its limits (i.e. ending up with the perfect multiqueue limits).