This change clears the carry whenever a new SOI is detected. We tested it in production for ~3 months and crashes due to image decoding issues have gone down >80% according to Firebase Crashlytics.
Depending on network connectivity, a camera might send an incomplete image. Displaying this results in a gray flicker, since the image cannot be properly decoded. This library "solves" this problem already by only sending the image off for rendering when an EOI sequence is detected.
However, wen an SOI sequence is detected after a broken image, the carry is not reset. This leads to "half of a broken image and a proper image" being sent to the Flutter Image tag together, which sometimes (depending on where the data cuts off) crashes it in Flutter < 3.2.
Even with the change in Flutter 3.2 that keeps the app from crashing in this case, I still think this is helpful to prevent future regressions.
This change clears the carry whenever a new SOI is detected. We tested it in production for ~3 months and crashes due to image decoding issues have gone down >80% according to Firebase Crashlytics.
Depending on network connectivity, a camera might send an incomplete image. Displaying this results in a gray flicker, since the image cannot be properly decoded. This library "solves" this problem already by only sending the image off for rendering when an EOI sequence is detected.
However, wen an SOI sequence is detected after a broken image, the carry is not reset. This leads to "half of a broken image and a proper image" being sent to the Flutter
Image
tag together, which sometimes (depending on where the data cuts off) crashes it in Flutter < 3.2.Even with the change in Flutter 3.2 that keeps the app from crashing in this case, I still think this is helpful to prevent future regressions.
EDIT: This was originally inspired by the issue described in https://github.com/mylisabox/flutter_mjpeg/issues/18