Well, there are at some issues at play here:
a) Currently ingress shaping does not account for the dropped packets aggressively enough, resulting in less drop feedback for the senders. (Upstream) Cake has an experimental ingress keyword with which t attempts to drop more aggressively. To test for this you might be available to set the ingress shaper to 50% of the line-rate so that sqm dropps more aggressively to begin with.
b) Many newer “streaming sources” actually do not stream at the intended bandwidth but put large bursts at maximum available bandwidth followed by periods of quiet. Making it somewhat unruly for a shaper to deal with.
c) Some “streamers” actually started to use TCP protocols that use queueing delay as signal to reduce the sending bandwidth instead of dropped packets, assuming that unmanaged queues show a large increase in transmission latency on congestion. But since sqm explicitly tries to keep the encountered delay short these senders often do not seem to get the congestion signal and keep “spamming” the downstream (as the queue backspills into the ISP upstream equipment), and if they drown out/delay the latency critical packets already of that stage where sqm has no way to selectively prioritize them.
It is not guaranteed that any of these issues are actually causing your problem though…