samirkumardas
commented
2 years ago Thank you for the video and details. I admit this issue exists, and resetting is an aggressive way of recovering it. The problem is that jmuxer can not do little when it occurs because it happens in the browser rendering section, and buffers get stuck all the way and start throwing exceptions repeatedly.
Still, I don't know any graceful way of recovering it. I tried a couple of ways to instruct the browser in such cases before, but every attempt was failed. I will be looking into it if I get any solution for it. I need suggestions from other experts if anyone had the issues and fixed them.
Interesting is that you see every browser act differently in such cases. Try running in Firefox, for example.
Hi,
I was experiencing this problem that seems to happen when the stream loses one packet (my stream has a GOP of 1 second). I've noticed a recent merge that basically resets the whole stuff when this happens, but that reset is very aggresive visually as it takes quite much to restart.
I'm sending the same h264 signal to jmuxer and to a desktop app that is decoding using the nvidia decoder. I have attached the video showing when the error occurs. You can notice that, in the nvidia decoder, a frame is lost and the decoder can somehow get by, showing some ghosting in the final image. However in jmuxer the recovering is a hard resetting and is more noticeable.
It would be great if the decoder could behave as the Nvidia decoder does, or at least if recovering from the error (which in my case it happens quite often) could be less aggressive.
I completely understand this is a volunteer project, so take this only as a request. Congratulations for this great tool and thanks your effort with it !
jmuxer_test.zip