CedarX/JPEG-MJPEG Decoding

From linux-sunxi.org
Jump to: navigation, search

MJPEG/JPEG Decoding process

CedarX take care Decode JPEG and MJPEG(are set of JPEGs)

Generaly JPEG decoding can be described:

JPEG decoding process
(Huffman(VLD) decode )
        |
(Inverse Quantization(IQ))
        |
(Inverse Discrete Cosine Transform(IDCT)) 
        |
(YCrCb to RGB) (disp must do it)


CedarX need to be configured in order:


  • Set JPEG Restart Interval
MACC_MPEG_JPEG_RES_INT <- restart interval
  • Set JPEG Input format
[MPEG_BASE+0x1b] <- 0x3 | (format << 3)
format meaning
0x0 4:2:0 chroma subsampling
0x1 unknown
0x2 4:2:2 horizontal chroma subsampling
0x3 4:4:4 full chroma (but Cedar output is 4:2:2 hor.)
0x4 4:2:2 vertical chroma subsampling (but Cedar output is 4:2:0)
0x5... unknown
MACC_MPEG_IQ_MIN_INPUT <- TABLE

table are TWO 8x8 MATRIX first for chroma, second for luma. All 2 * 64 8bit values are written to this reg one after another (and copied to internal ve-sram ).

bits Value Description
31:16 0x0000 unknown
15:8 0-63 for chroma, 64-127 for luma position in matrix in zigzag order (order is same as in JPEG)
7:0 IQ coefficient from DQT in JPEG


  • Set Result buffer (Rotate-Scale buffer)

Must be physical address (in reseved space) and relative to DRAM start

MACC_MPEG_ROT_LUMA <- Chroma output buffer address
MACC_MPEG_ROT_CHROMA <- Luma output buffer address

Data output is in 32x32 pixel blocks, DEFE should be able to reorder and convert this according to A13 manual.

  • Set picture size in MCUs
MACC_MPEG_JPEG_SIZE <- HEIGHT:WIDTH

Height in upper bits (31:16), width in lower (15:0) beginning with 0 for up to one MCU

  • Set scale mode
MACC_MPEG_ROTSCALE_CTRL <- 0(1:1) (extra functions control register)
  • Reset huffman table
MACC_MPEG_JPEG_HUFFMAN_CTRL <- 0 (huffman control register)
  • Parse from jpeg and load Huffman table
MACC_MPEG_JPEG_HUFFMAN_LOAD <- TABLE

Cedar Huffman Tables are 2KiB of data written through this register. First half contains description of Huffman-tree, second half contains the data.

+----------+----------+----------+----------+---- - - - ---------- - - - ---------- - - - -----+
|  LumaDC  |  LumaAC  | ChromaDC | ChromaAC | Filled with zero (maybe more trees are possible) |
| 64 bytes | 64 bytes | 64 bytes | 64 bytes |                    768 bytes                     |
+----------+----------+----------+----------+---- - - - -----+---- - - - -----+---- - - - -----+
|                Luma DC Data               |  Luma AC Data  | Chroma DC Data | Chroma AC Data |
|                  256 bytes                |   256 bytes    |   256 bytes    |   256 bytes    |
+-------------------------------------------+---- - - - -----+---- - - - -----+---- - - - -----+

Each of the 64 byte tree-description has the following format:

First 16 halfwords: first bitstream used for datacodes in corresponding depth (or 0xffff if no more data)
Next 16 bytes: offset in data section for corresponding depth
Rest (16 bytes): Filled with zero

The 256 byte data sections contain the codes in same format as in JPEG.

  • Set VBV (limit address) maxumum reseved
this is for IRQ when we need more data than reserved in mem for new part
MACC_MPEG_VBV_END <- SRC_BUFF+ SRC_MAX_BUFF_SIZE-1
  • Enable IRQ (may be also set work mode need check))
MACC_MPEG_CTRL <- 0x0000007c
  • Set SRC Buff parameters


MACC_MPEG_VLD_OFFSET <- Offset in SRC buffer in bits (frame offset when may you have manyframes - mjpeg)
MACC_MPEG_VLD_LEN <- VLD LEN in bits
MACC_MPEG_VLD_ADDR <- (SRC address relative to DRAM start) | 0x70000000   How to access ram above 256MB?


  • Start
MACC_MPEG_TRIG <- 0xe  Trigger start
  • Wait IRQ (using ioctr)
Personal tools
Namespaces

Variants
Actions
Navigation
Tools