Compensating for missing jpeg bytes
I am making a program for a microcontroller connected to a radio that needs to send JPEG image bytes to the computer. I want to know if there is a way to compensate for the situation where some JPEG bytes are lost. As it is now, even if 1 byte is lost, it corrupts the whole image. I could program it to have the microcontroller re-send the lost bytes, but I want to avoid losing one or two bytes of communication time, and I don't want to process the microcontroller too much. So, it would be ideal if I could just fill in the blanks with placeholders, because that way the image would be just a few pixels away, which is great.
source to share
You can use JPEG restart markers, but that will mean losing a number of MCUs or so when you get corruption, not just a few pixels (depending on how far you place them).
You need to add a Define Restart Interval marker at the beginning of the file (before scanning starts) to indicate the restart interval in macroblocks.
DRI 0xFF, 0xDD 4 bytes Define reboot interval . Defines the spacing between RSTn markers in macroblocks. This marker is followed by two bytes indicating a fixed size, so it can be treated like any other segment of variable size.
Then in your stream, at an interval where you have specified as many macroblocks, you insert a 2-byte restart marker using a counter that fluctuates between 0 and 7:
RSTn 0xFF, 0xDn (n = 0..7) none Reboot All r macroblocks are inserted, where r is the restart interval set by the DRI marker. Not used if there was no DRI marker. The low 3 bits of the marker code encode a value from 0 to 7.
On a restart mark, the predictor variables from block to block are reset, and the bit stream is synchronized to the byte boundary. Restart markers provide a means of recovering from a bitstream error, such as transmission over an unreliable network or file corruption. Since runs of macroblocks between restart markers can be independently decoded, these runs can be decoded in parallel.
So, every time your decoder encounters a 0xFF byte followed by 0xDn (0-7), you can resynchronize the byte boundary. The sequence 0xFF 0xDn cannot appear in a normal compression stream (any 0xFF must be followed by a run fill byte to avoid confusion).
source to share