Restarting tokens is quite simple. They were designed to provide resynchronization after an error. Since most JPEG images are transmitted over problem-free channels, they are rarely needed. The restart interval is defined with the FFDD token as a 2-byte number. This indicates how many MCUs between restart markers. When you encounter a restart marker (FFD0-FFD7), reset the DC (Y, Cr, Cb) to 0, and the bitstream starts at the byte boundary (after FFDx). It is just a matter of counting through the restart interval again and again when decoding an image. The restart marker values will increase from FFD0 to FFD7, and then start again with FFD0. The value of the marker itself is not very important, but it may indicate the absence of large pieces of data. Here is an example of how I do this in my decoder. I discard restart markers in my stream reader.
iRestartCount = iRestartInterval; for (y=0; y<Height_in_MCUs; y++) { for (x=0; x<Width_in_MCUs; x++) { <decode an MCU> if (iRestartInterval) // if there is a restart interval defined { if (--iRestartCount == 0) { iRestartCount = iRestartInterval; // reset restart inverval counter iDCPred0 = iDCPred1 = iDCPred2 = 0; // reset DC predictors if (*iBit & 7) // adjust bitstream to start on the next byte boundary { *iBit += (8 - (*iBit & 7)); } } // if restart interval expired } // if restart interval defined } // for x } // for y
Update:. Reloading tokens now serve a new purpose - to allow multi-threaded JPEG encoders and decoders. Since each “strip” of the MCU has DC reset values at the beginning of each restart interval and starts at the byte boundary, each restart interval can be independently encoded or decoded by another stream. The encoder can now arbitrarily divide the task into N threads, and then "glue" the data along with restart markers. For decoders, this is not so simple. If restart markers are present, each interval can be assigned to a different thread. If this does not happen, you can do some preliminary decoding to split the job into several threads.