Motion-JPEG Decoder Application

MJPEG Decoder Mini

Motion JPEG, designated as MJPEG, is an informal name for multimedia formats where each video frame or interlaced field of a digital video sequence is separately compressed as a JPEG image. It is often used in mobile applications such as digital cameras. Compared to MPEG-2, the major difference is that the inter-frame prediction is not applied. Each frame starts with hex 0xff 0xd8 and ends with 0xff 0xd9, as can be seen in fileString1frame.h and fileString2frame.h.

This version of MJPEG decoder consists of 7 processes, namely TG, DEMUX, IQ, ZZ, IDCT, LIBU, and MERGE, working in a feed-forward fashion. The interconnect of these processes can be seen from generated dotty file (see Fig. [fig:mjpeg_nonscaled] and Fig. [fig:mjpeg_scaled]).

In this version of the MJPEG application, the packet sizes for reading/writing from/to a channel are the same and they are constant. These sizes are defined in the processnetwork.xml specification of the MJPEG application.

• The TG process splits a video, frame by frame, and dispatches the frames to the subsequent DEMUX via two different channels: a size channel tg_to_demux_C1 for sending the size of the frame and a frame channel tg_to_demux_C2 for sending the frame itself. To maintain a fixed size for each frame, we always send MAX_ENCODED_FRAME bytes to the frame channel, which might contain a few redundant bytes. The TG process will only be activated one time for each run.
• The DEMUX process merges the original DEMUX and VLD tasks. It gets data from TG, finds markers in the JPEG flow, extracts VERBOSE information on picture, table, and data, and then unpacks and predicts DCT coefficients. This process will be activated only once per frame.
• The IQ process will be activated once per frame and it will unquantify 8x8 DCT blocks.
• The ZZ and IDCT processes will be activated 1200 times per frame. The ZZ will reorder an 8x8 DCT block.
• The LIBU process will be activated once per frame.
• The MERGE process will reassemble the decode blocks and display the decoded frame by default. This process will be activated once per frame.

More detailed information can be found in the corresponding source code.

Set-up and Run the DAL-MJPEG Application

• The MJPEG video is stored in fileString.h file, static compiled into the binary.
• The encoded image size should be smaller than MAX_ENCODED_FRAME
• Set NUMBER_OF_FRAMES in jpeg.h to the number of frames needed to be decoded. This information is needed for detaching all processes at the end of the execution (for instance, for finishing the cycle-accurate MPARM simulation). This number can be obtained from the functional simulation, for instance.
  Note: In the distributed DAL-MJPEG application, three streams with 1, 2, and 31 frames are provided, corresponding to fileString1frame.h, fileString2frame.h, and fileStringAll.h, respectively. The macro NUMBER_OF_FRAMES should be adapted accordingly if fileString.h is changed.
• The static allocated memory can be reduced by shrinking the decoded image size, which currently is 1024*1024 (corresponding to 1 MB).

View the Decoded Video

Add the following flags in Makefile.inc for the compilation of the system: COMP_ARG = -DVIEWER and LINK_ARG = -lpthread -lX11 (if X11 is not found, you might need to add, in addition, something like -L/usr/X11R6/lib)

Scale to a Larger Process Network

This version of MJPEG decoder is scalable at frame level, i.e., the TG process can distribute frames to a parameterized number of concurrent routes, which contain the complete chain of processes DEMUX, IQ, ZZ, IDCT, and LIBU. The decoded frames are collected in the MERGE process. How many routes to scale can be set in the processnetwork.xml specification. Currently, a TDMA scheme is applied for frame distribution in TG. Fig. [fig:mjpeg_nonscaled] shows the non-scaled version of the MJPEG process network, while Fig. [fig:mjpeg_scaled] illustrates a process network scaled with a factor of 3.

In order to obtain a scaled version of the MJPEG decoder, two files have to be modified:

• In application8.xml, modify NUM_OF_PAR_PORTS to the number of separate paths needed.
• In src/jpeg.h, modify the macro with the same NUM_OF_PAR_PORTS with the same value.