What appears to be happening is that a slow client of a push stream channel will eventually fall back far enough to receive data from another channel.
I can reproduce it, but I had a hard time with it, sorry it's not a little more straight-forward. This zip file contains the best I could come up with:
That contains a docker-compose project that will push two mjpeg streams. docker-compose up should be all you need to get it running. If you load one of the streams (12) in chrome and set a throttle in the network tab (the "Fast 3G" preset reproduced it, so did a custom profile with 1500 kb/s down and no latency).
The test begins looking like this:
After a few minutes (usually 2, but sometimes more), the image is replaced with a garbled version of the image. For example,
Or possibly a fragment of the image from the other channel:
I don't see this problem with only one channel, and I don't see it with a fast client. It seems to be something with the combination of multiple channels and a slow client.
What appears to be happening is that a slow client of a push stream channel will eventually fall back far enough to receive data from another channel.
I can reproduce it, but I had a hard time with it, sorry it's not a little more straight-forward. This zip file contains the best I could come up with:
pushstream-test.zip
That contains a docker-compose project that will push two mjpeg streams.
docker-compose upshould be all you need to get it running. If you load one of the streams (1 2) in chrome and set a throttle in the network tab (the "Fast 3G" preset reproduced it, so did a custom profile with 1500 kb/s down and no latency).The test begins looking like this:
After a few minutes (usually 2, but sometimes more), the image is replaced with a garbled version of the image. For example,
Or possibly a fragment of the image from the other channel:
I don't see this problem with only one channel, and I don't see it with a fast client. It seems to be something with the combination of multiple channels and a slow client.