기본 콘텐츠로 건너뛰기

h.264/avc의 in-loop deblocking filter

출처 - http://www.sosori.com/2009/09/h264avc%EC%9D%98-in-loop-deblocking-filter.html

h.264/avc의 in-loop deblocking filter에 대해서 그냥 제가 아는대로만 설명해 보려고 합니다.
뭐 제가 전문가도 아니고 대충 개념정도만 알고있는거라서 참고만 하시는게 좋을것 같습니다;

보통 디블럭이라고 하면 후처리 필터라고 알고 계실겁니다. mpeg압축방식처럼 영상을 여러개의 블럭으로 나눠서
인코딩 하는 경우 부작용으로 블럭화 현상이 생기는데(깍두기라고도 하죠) 이런 블럭화 현상이 있는 영상을
보정해주는 걸 보통 deblocking필터라고 합니다. avisynth의 deblocking필터라든지 mpeg2나 mpeg4의 디코더에 있는
deblock필터 등등에 해당하는 얘깁니다. 하지만 h.264/avc의 in-loop deblocking필터는 보통의 후처리 필터와는
약간 개념이 다릅니다. 기본적으로는 deblocking필터이지만 어떤 과정에서 사용되느냐가 다른 후처리 필터들과는
다른점이죠. 인코딩관련 블로그나 게시판을 봐도 이름이 비슷하기 때문에 보통 이 둘을 같다고 생각하시는 분들이
많은것 같아서 이 둘의 차이점에 대해서 말씀드리겠습니다.

먼저 단순한 후처리 필터로써 deblocking필터가 사용되는 인코딩과정이나 재생과정을 생각해보면,
-----------------------------------------------------------------------------------------------
  원본소스 -> 후처리(deblocking) -> 인코딩
                                                     인코딩된 영상 -> 디코딩 & deblocking -> 디스플레이(재생)
-----------------------------------------------------------------------------------------------
이런식이죠. 보통의 이런 후처리 deblocking필터는 인코딩과정 내에서는 아무런 영향을 주지 않습니다.
하지만 in-loop deblocking은 그 이름처럼 인코딩 과정내에 삽입되어 작용을 합니다.
예를 들어, 원본소스가 3개의 프레임(A,B,C)으로 이루어진 영상이고 3개의 프레임을 I,P,P프레임으로
인코딩한다고 가정하면...

in-loop deblocking을 사용하지 않는 압축방식은 다음과 같습니다.
  1) A프레임을 I프레임으로 압축 - 참조 프레임 없이 intra코딩 합니다.
  2) B프레임을 P프레임으로 압축 - 이미 압축된 A프레임을 참조하여 inter코딩 합니다.
  3) C프레임을 P프레임으로 압축 - 이미 압축된 B프레임을 참조하여 inter코딩 합니다.

in-loop deblocking을 사용하는 압축방식은 다음과 같습니다.
  1) A프레임을 I프레임으로 압축 - 참조 프레임 없이 intra코딩 합니다.
  2) B프레임을 P프레임으로 압축 - 이미 압축된 A프레임에 deblocking필터를 적용한 후 참조하여 inter코딩 합니다.
  3) C프레임을 P프레임으로 압축 - 이미 압축된 B프레임에 deblocking필터를 적용한 후 참조하여 inter코딩 합니다.

이렇게 in-loop deblocking을 사용하는 경우, 이미 압축된 프레임에 deblocking필터를 적용한 후에 참조하여
inter코딩을 하기때문에 더 효율적인 움직임예측이 가능해져서 residual data(움직임예측오류데이터)를 줄일 수 있습니다.
또한 in-loop deblocking을 사용하는 압축방식을 잘 생각해보면 in-loop deblocking은 "h.264/avc의 압축과정"에서
발생하는 블럭화 현상을 제거하여 압축효율을 높이는 것이지 원본소스의 블럭화 현상 제거와는 별로 상관이
없다는것을 알 수 있습니다. 따라서 원본소스가 어찌됐든 in-loop deblocking은 압축효율을 높이기 위해 항상
사용하는게 좋겠죠.(h.264/avc의 모든 프로파일에 적용되는 옵션입니다) 그리고 비교적 비트레이트가 낮은  h.264/avc영상을 볼 때

디코더에서 in-loop deblocking을 사용하지 않을 경우(ex:CoreAVC디코더에서 skip deblocking을 사용하는 경우)에 꽤나 심각한
블럭화 현상이 나타나는 이유도 알 수 있습니다. 참조 프레임에 deblocking필터를 적용하기 때문에 inter코딩 과정에서
deblocking필터에 의한 효과가 점점 누적되게 되고 재생시에 deblocking필터를 사용하지 않으면 누적된 차이가
화면에 그대로 나타나게 되는거죠. 참조 프레임을 사용하지 않는 Intra프레임(I프레임)을 만나면 정상화 되었다가 다시 점점 차이가
나타나는 모습을 볼 수 있습니다. 따라서 원래 인코더가 의도한 영상을 보려면 디코더의 deblocking필터는
특별한 경우가 아니라면(ex:컴퓨터의 사양이 낮아서 원활한 재생이 힘든 경우) 항상 사용하는게 좋습니다.

요즘 많이 쓰이는 h.264/avc인코더인 x264에서도 --deblock a:b 옵션으로 in-loop deblocking을
사용할 수 있는데 a,b값을 어떻게 정해야 할지가 가장 어려운 부분이죠..
보통은 a,b값이 높을수록 더 많이 deblock된다고 합니다만 a,b값 말고도 in-loop deblocking에 영향을
주는 요소들이 많이 있습니다. QP값이나 매크로블럭 타잎 등 여러 요소들에 의해서 deblocking을
적용할지 안할지가 결정되기 때문에 이 부분은 기본값인 0:0 에서 너무 차이가 나지 않는 범위내로
정하는게 좋을것 같습니다. 그리고 a,b값을 어떻게 정하더라도 QP값이 낮을수록(비트레이트가 높을수록)
in-loop deblocking의 작용이 줄어들기 때문에 웬만큼 저화질로 인코딩 하는 경우가 아니라면
a,b값을 조절하는게 인코딩된 영상에 그리 크게 영향을 주지는 않을겁니다.

여기까지 제가 아는대로 h.264/avc의 in-loop deblocking에 대해서 써봤는데요..
앞서 말씀드린대로 여기저기서 주워들은 내용이기 때문에 얼마든지 잘못된 내용이 있을 수 있습니다;
그리고 사실 인코딩을 하는 입장에서 몰라도 아무런 상관없는 내용이기도 하고요..그냥 보통의 후처리 필터와
어떤점이 다른지 또 어떤식으로 in-loop deblocking이 작용하는지 참고만 하시는 정도로 보시면 좋을것 같습니다. 

댓글

이 블로그의 인기 게시물

UNIX C errno 정리( 에러 번호 )

#define EPERM   1   /* Operation not permitted      */ #define ENOENT  2   /* No such file or directory        */ #define ESRCH   3   /* No such process          */ #define EINTR   4   /* interrupted system call      */ #define EIO 5   /* I/O error                */ #define ENXIO   6   /* No such device or address        */ #define E2BIG   7   /* Arg list too long            */ #define ENOEXEC 8   /* Exec format error            */ #define EBADF   9   /* Bad file descriptor          */ #define ECHILD  10  /* No child processes           */ #define EAGAIN  11  /* Resource temporarily unavailable */ #define ENOMEM  12  /* Not enough space         */ #define EACCES  13  /* Permission denied            */ #define EFAULT  14  /* Bad address              */ #define ENOTBLK 15  /* Block device required        */ #define EBUSY   16  /* Resource busy            */ #define EEXIST  17  /* File exists              */ #define EXDEV   18  /* Improper link            */ #define ENODEV  19  /* No such

시리얼(Serial) 이란?

출처 - http://www.ni.com/white-paper/2895/ko/#toc4 시리얼은 거의 모든 PC에서 표준으로 사용되는 디바이스 통신 프로토콜입니다. 시리얼의 개념을 USB의 개념과 잘 구분하십시오. 대부분의 컴퓨터에는 2개의 RS232 기반 시리얼 포트가 있습니다. 시리얼은 또한 여러가지 디바이스에서 계측을 위한 일반 통신 프로토콜이며, 여러 GPIB 호환 디바이스에는 RS232 포트가 장착되어 있습니다. 뿐만 아니라, 원격 샘플링 디바이스로 데이터 수집을 하는 경우에도 시리얼 통신을 사용할 수 있습니다. 시리얼 통신의 개념은 간단합니다. 시리얼 포트는 정보의 바이트를 한번에 한 비트씩 순차적으로 송수신합니다. 한번에 전체 바이트를 동시에 전달하는 병렬 통신과 비교하면 시리얼 통신은 속도가 느리지만 훨씬 간단하며 장거리에도 사용할 수 있습니다. 예를 들어, 병렬 통신용 IEEE 488 스펙을 보면 기기간 케이블링은 총 20 m 미만이어야 하며, 두 개의 디바이스간은 2 m 미만이어야 합니다. 반면 시리얼 통신은 최대 1.2 Km의 통신거리를 보장합니다. 통상 엔지니어들은 ASCII 데이터를 전송할 때 시리얼 통신을 사용합니다. 이 때 송신용 (Tx), 수신용 (Rx), 그라운드용 (GND)의 세 가지의 전송 라인을 사용하여 통신합니다. 시리얼은 비동기식이므로 포트는 한 라인에서 데이터를 전송하고 다른 라인에서 데이터를 수신합니다. 핸드쉐이킹용 라인도 사용 가능하지만 필수 요구사항은 아닙니다. 시리얼 통신의 가장 중요한 특징에는 보드 속도 (baud rate), 데이터 비트, 정지 비트, 패리티가 있습니다. 두 개의 포트가 통신하기 위해서는 이러한 파라미터가 반드시 적절하게 맞춰져야 합니다. 보드 속도는 통신의 속도를 측정하는 수치이며 초당 비트 전송 숫자로 표시됩니다. 예를 들어 300 보드 속도는 초당 300 비트를 의미합니다. 엔지니어들이 흔히 말하는 클럭 주기는 보드 속도를 의미합니다. 따라서 프로토콜에 4800

[C언어] epoll 설명

출처 -  http://biscuit.cafe24.com/moniwiki/wiki.php/epoll 1  준비 2  socket 프로그래밍 기본 3  비동기 입출력 (Asyncronous I/O) & 입출력 다중화 (I/O Multiplexing) 4  select 5  select 와  poll  그리고 epoll. 그 차이 6  epoll 프로그래밍 흐름 7  epoll 함수들 8  epoll References 빈폴도 아니고, 이폴이란 대체 무엇일까? 당신은 서버한대로 몇 명의 동시접속자를 수용할 수 있습니까? 최근에 인터넷에 떠돌아다니는  c10k_problem 은 대당 10K, 즉 1만명의 동시접속(concurrent users)을 받아보자는 문제다. 서버 프로그래밍을 해 본 사람이라면 이게 그리 만만한 문제가 아니라는 것을 직감할 듯 --; 요즘의 Massive 온라인게임은 '분산처리'가 기본이라 한 대에서 많은 이용자를 커버하기보다는 여러대가 하나의 세트로써 구성하는 것이 인기가 있고 다수의 커넥션보다는 소수 커넥션에서의 대용량 전송이 더 중요한 요소이기도 하다. c10k problem에 나또한 관심을 가지게 되었고, epoll 이 최근 급부상하는 솔루션으로 인기가 있다기에 한 번 파보자 하고 결심하고 이 글을 시작했다. 마침 wiki에도 관심이 있던 차라, wiki 공부도 할 겸해서 epoll 을 연구하는 과정을 이 wiki에 담아 보고자 한다. 1  준비  # * 누구를 위한 epoll 인가? epoll은 '한 대의 서버에서 아주많은 동시접속자를 처리하기 위한 수단'이다. 이미 당신이 그 수단을 알고 있다면 - epoll 이건 아니건 - 이 글은 별로 도움이 안될듯하다. 동시접속자가 천명을 넘지않는다면 구닥다리 방법을 이용하는 것과 큰 차이가 없으리라 본다. 또한, epoll은  Linux 프로그래머의 도구 이다. M$ wind