Music is my life

한동안 주구장창 H.264 만 쳐다보고 있었더니 정말 토가 나올려고 한다.

이제 겨우 I-frame 디코딩을 완료했는데.. 아직도 할일이 너무 많이 남았다.

P-frame 과 dpb manage 를 더 해야하는데 이게 쉽지가 않을것 같다.

이런 상황에서 내게 떨어진 강의자료 만들기는 잠시간의 휴식인지? ㅋㅋ

일단 지금 떨어진일도 일정이 초읽기라서 이건 뭐 쉴수가 없다 ...

언능 끝내구 H.264 도 일단 소프트웨어만 끝내고 교수님께 MIMO 한다고 말씀드려야겠다..

H.264 혼자서 설계하긴 너무 크다 ㅠㅠ.. 괜히 덤빈거 아닌가몰라..

MIMO 는 쉽냐고 하시는 분도 계실거 같은데..안해봐서 몰라요 ^^;;;

투덜투덜...

지긋 지긋한 소프트웨어 분석이 끝(?) 나고 드디어 설계를 들어간다.

아키텍쳐를 설계하기 전에 하드웨어와 소프트웨어의 파티셔닝을 해야 한다.

SoC는 이제 더이상 낮선 개념이 아니다. 쉽게 설명하면 소프트웨어와 하드웨어를 같이 이용해 칩을 만드는 개념으로 보면 되겠다. 물론 정확한 개념은 아니지만 ^^;

H.264 디코더는 생각보다 작지 않은 프로젝트이다. 특히 혼자서 진행하기에는 많은 에로가 따른다. -_-

이미 많은 코어 모듈을 IP 로 가지고 있다고는 하지만 인터페이싱을 하는것도 힘들고, 인테그레이션 하는것도 힘들다.

생각 같아서는 새로 짜고 싶지만, 언제까지 남의것이 맘에 안든다고 새로 짤수만은 없다.

ARM 프로세서에서 소프트웨어를 튜닝하는 일은 쉽지가 않다 -_-; 하드웨어와 소프트웨어 사이의 인터페이스를 고려해서 소프트웨어를 수정하는일은 더욱 어렵다 -_-;

이럴땐 소프트웨어 분석능력이 딸리는 것을 실감한다 - _-; 시뮬레이션하는 수준의 코딩은 무리가 없는데..

좀 복잡한 소스를 분석하려니까 머리가 터진다...

프로프로세싱부를 소프트웨어에서 처리하고, parser 도 소프트웨어로 구현하기로 했다.
핵심 모듈은 cavlc 나 inter/intra prediction 모듈 deblocking-filter 는 하드웨어로 구현하고,
global 변수는 register 를 이용하고 몇개의 필요한 버퍼 메모리를 내부 SRAM을 사용하기로 했다.

보다 정확한 아키텍쳐는 분석을 좀 더 하고나서 나올 듯 한데 대략의 구조는 그렇다.

이제 클럭 예상과 메모리 I/O 분석만 좀 더 하면 설계를 마칠 수 있을 것 같다.

우선 FFMPEG 을 다 뜯어 고쳐야지 ㅠㅠ.. 너무 복잡해 =_=

ffmpeg 은 h.264 software decoder 중 성능이 2번째로 뛰어나고 open source 로 되어 있는 어플리케이션이다.
ffmpeg 을 arm  프로세서를 탑재한 Bluesky2440 보드에 porting 하는 방법

각 단계에 모르는 용어나 자세한 정보는 각자 찾도록 한다.

1. Linux host 설치
   a: samba ( 리눅스 <->윈도우  파일 관리 )
   b: tftp ( 리눅스 <-> Bluesky2440 이미지 전송 )
   c: nfs ( 리눅스 <-> Bluesky2440 파일 관리 편리 )
   d: gcc와 관련된 패키지들 업데이트
      ( ffmpeg 은 gcc 버전이 낮거나 glibc 버전이 낮으면 컴파일 중에 에러가 발생한다. )
   d: arm-linux-gcc ( 각 리눅스 버전에 맞는 것을 구한다 )

2. Linux host 와 Bluesky2440 을 위한 설정
   a: tftp 를 이용해서 boot-image 와 kernel-image를 Bluesky2440 에 다운로드 한다.
   b: nfs 를 이용해서 Bluesky2440 을 리눅스에 mount 시킨다.
   c: Bluesky2440 부트로더를 수정해서 nfs로 동작하도록 수정한다. ( ip , devfs , nfsroot 등.. )  

3. ffmpeg을 arm 용으로 porting 한다.
   a: ffmpeg 을 linux 에서 설치해서 테스트를 해본다.
   b: ffmpeg을 arm 용으로 컴파일 하기 위해서 옵션들을 바꾼다.
   c: shared 옵션을 disable 로 하고 컴파일러를 arm-linux-gcc 로 바꾼다.
   d: static 옵션을 enable 로 하고 gpl 옵션도 enabler 시킨다.
   e: cpu나 arch 옵션을 arm 으로 하고 ,prefix를 nfs 마운트 된 arm 디렉토리로 설정한다.
   f: compile 하고 build 시킨다.
   g: 에러가 발생하면 경우에 따라서 ffmpeg 소스를 수정한다.
      ( 예: encode_422_bitstream, encode_gray_bitstream function 의 동작을 주석처리 )
   h: 동작이 잘 되는지 ffmpeg을 실행해서 확인 해 본다.

참고사이트
  http://forum.doom9.org/
  http://ffmpeg.mplayerhq.hu/
  http://www.emlinux.co.kr/

1. Integer Transform 특징
  - Spatial Redundancy 를 효율적으로 제거 하기 위해 사용
  - MPEG4 에서 사용하는 DCT 와 유사하다.
  - Time domain -> Frequency domain 의 변환을 한다.
  - Quantization과 겹친다.
  - Core Transform 과 Hadamard Transform 으로 구성
  - DCT 의 단점인 소수점 연산을 없애서 Inverse 과정을 했을때 오차가 없다.
  - Add 연산과 Shift 연산 만으로 구현이 가능하다.

2. Integer Transform 연산
  - Y = A  X  A^t * E
      A : 가로축 변환 계수 행렬
       A^t : A 의 transpose 행렬
       X : NxN block 의 데이터 행렬
       Y : Transpose 결과 계수
      E : 상수 배열
 
3. Core Transform
  - Luma 와 Chroma block 모두 4x4 block 으로 연산을 한다.
  - Y = AXAt 의 연산이 Y = CXC^t(*)E 의 형태로 바뀐다.
  - C 아 Ct 가 core transform 의 계수행렬이다.
  - C = {1,1,1,1,2,1,-1,-2,1,-1,-1,1,1,-2,2,-1} , Ct = {1,2,1,1,1,1,-1,-2,1,-1,-1,2,1,-2,1,-1}

4. Hadamard Transform
  - DC성분 값을 줄이는데 사용
  - 변화과 역변화이 같다.
  - Luma 와 Chroma block 의 모드별로 다르게 사용한다.

5. 4x4 Intra Predicted Luma block
  - Hadamard Transform을사용하지 않는다.

6. 16x16 Intra Predicted Luma block
  - 1개의 Macro block 에대해서 4x4 block 의 DC값의 크기가 비슷
  - 각 block 의 DC값 4개를 4x4 block 으로 만든 후 Hadamard Transform 수행
  - Wl = K Y K * C
           Wl : Luma Hadamard Transform 결과 행렬
           K : Hadamard Transform 의 계수
           Y : Core Transform 의 결과 block 의 DC행렬
          C : 상수
  - K = {1,1,1,1,1,1,-1,-1,1,-1,-1,1,1,-1,1.-1}

7. 8x8 Intra Predicted Chroma block
  - 인근 block간의 DC 값이 유사하여 변환 효과가 높다.
  - 각 block 의 DC 값 4개를 2x2 block 으로 만든 후 Hadamard Transform 수행
  - Wc = K` Y K` * C
           Wc : Chroma Hadamard Transform 의 결과 행렬
           K` : Hadamard Transform 의 계수
           Y : Core Transform 의 결과 block 이 DC 행렬
          C : 상수
  - K` = {1,1,1,-1}