생활공공기관
도구
- 스마트폰,태블릿 화면크기비교
- 양쪽 윈도우키를 한영한자키로(AutoHotKey)
- 매크로: Robotask Lite
- 파일이름변경: ReNamer Lite
- 파일압축: 반디집
- 공공서식 한글(HWP편집가능, 개인비영리)
- 오피스: 리브레오피스(LibreOffice)
- 텍스트뷰어: 이지뷰어
- PDF: FoxIt리더, ezPDF에디터
- 수학풀이: 울프램 알파 ( WolframAlpha )
- 수치해석: 셈툴, MathFreeOn
- 계산기: Microsoft Mathematics 4.0
- 동영상: 팟플레이어
- 영상음악파일변환: 샤나인코더
- 이미지: 포토웍스
- 이미지: FastStone Photo Resizer
- 화면갈무리: 픽픽
- 이미지 편집: Paint.NET, Krita
- 이미지 뷰어: 꿀뷰
- 국립중앙도서관 소장자료 검색
- KS국가표준인증종합정보센터
- 대한무역투자진흥공사(KOTRA) 해외시장뉴스
- 엔팩스(인터넷팩스발송)
- 구글 드라이브(문서도구)
- MS 원드라이브(SkyDrive)
- 네이버 N드라이브
- Box.com (舊 Box.net)
- Dropbox
- 구글 달력
- 모니터/모바일 픽셀 피치 계산
- Intel CPU, 칩셋 정보
- MS윈도우 기본 단축키
- 램디스크
- 초고해상도 관련
- 게임중독
- 표준시각
- 전기요금표/ 한전 사이버지점
- HWP/한컴오피스 뷰어
- 인터넷 속도측정(한국정보화진흥원)
- IT 용어사전
- 우편번호찾기
- 도로명주소 안내, 변환
- TED 강연(네이버, 한글)
- 플라톤아카데미TV
- 세바시
- 명견만리플러스
- 동아사이언스(과학동아)
- 과학동아 라이브러리
- 사이언스타임즈
- 과학잡지 표지 설명기사
- 칸아카데미
- KOCW (한국 오픈 코스웨어) 공개강의
- 네이버 SW 자료실
- 네이버 SW자료실, 기업용 Free
- 계산기
공공데이터베이스
PC Geek's
CRF 가 CQP보다 낫다는 글/ H.264(x264)동영상 인코딩 용어 설명 본문
[앞서의 글]에서 이어지는 내용이다.
MeGUI 2460 버전의 x264 옵션 정리 - 김코덱 2012
일반적인 x264 옵션 설명이 잘 돼 있다. 그리고 같은 사이트의 다른 글
x264의 비트(레이트) 배분 방식: ABR, CRF, 2패스
CRF모드와 CQP모드, 그 외 ABR, 2pass, 3pass 등을 설명.
저 블로그에는 다른 용어 설명도 있는데, 좋은 글같다. 알기 쉽다.
저 설명에 따르면, 이런 식인 모양: 설명을 요약한다. 이건 내 기억을 위해 적은 것이고, 원본쪽이 잘 된 글이니 거길 보라. 난 이거 전문가가 아니므로 잘못 이해했을 수 있다.
파일을 몇 개 블럭으로 나누고, 각 블럭을 구성하는 데이터에 변환 공식을 적용해 나온 값을 계수라고 하고, 이 계수를 사전에 정한 특정 숫자(QP)로 나누어 몫만 저장하고 나머지는 버림(손실). 그리고 그걸 비손실압축해 저장. 복원할 때는 그 몫에 QP를 곱해 나온 계수'을 역변환 공식을 적용해 원래 데이터를 재구성.
이런 식이므로, QP가 작을수록 정보가 많이 보존되고, QP가 클수록 정보를 많이 버리게 됨. 실제로는 더 복잡하지만 기본 원리는 이 비슷하다고.
파랑박스에 있는 다른 글 요약
CQP인코딩은 QP가 일정하므로 움직임이 많거나 화면이 복잡하면 비트레이트가 올라가는 식이라 화질은 모든 프레임이 비슷한 장점이 있음. 그리고 짐작할 수 있듯이 파일의 비트레이트와 용량은 인코딩이 끝나기 전에는 알 수 없음(그러니까 스트리밍용으로는 안 좋다는 말이겠지).
그런데 아래 CRF설명에도 나오듯이 느린 장면을 저압축하고, 휙휙 지나가는 장면은 고압축하는 것이 사람이 "느끼기에" 더 적은 용량으로 같은 품질을 보장하는 것처럼 보인다고 한다. 또 복잡한 장면에서는 조금쯤 원본과 다르게 재구성해도 알아채지 못한다고 한다. 따라서, 움직임이 빠른 장면, 복잡한 장면은 비트레이트를 그렇게 높이지 않아도 되는 꼼수가 있다고 함(그리고 내 생각에, 디코더쪽에서 텍스처를 써서 대충 때울 여지도 줄 지도). 그리고 단순하고 정적인 장면은 압축 효율도 높고, 알고리즘의 움직임 예측 효율도 높아지므로 비트레이트가 떨어진다고. CQP를 제외하고 QP를 인코딩 중간에 고치는 다른 방식들은 이런 걸 고려함.
2pass ABR은, 원본 영상을 두 번 읽는다. 원본 파일을 몇 개 블럭으로 나눠 놓고, 첫 번째 읽을 때 각 부분의 상대적인 복잡도를 평가함. 각 블럭의 복잡도는 결국 CQP모드에서 각 블럭의 비트레이트같은 개념이라 보면 됨. 그걸 가지고 그 영상 전체의 비트레이트값을 정하고, 그 값보다 비트레이트가 더 필요한 블럭, 덜 줘도 되는 블럭에 어느 정도로 배분할 지 결정한다. 비트레이트를 어느 정도로 배분할 지를 정하는 옵션이 --qcomp (저 글에서는 qcomp를 기준으로 설명하는데, 글에 덧붙은 말로는 작성시점 기준으로 요즘은 MB-tree를 적용한 방식. MB-tree방식은 프레임, 블럭의 복잡도를 단순계산하는 게 아니라 자주 참조되는 프레임, 블럭이 더 많은 디테일을 보존하도록 대역폭을 더 주는 것이라고) 인데, 거듭제곱의 지수가 되는 숫자이므로, 1이 되면 비트레이트는 CQP와 비슷하고 0이 되면 CBR(Constant BitRate)과 비슷하게 된다(실제로는 뒤에 말한 스케일링이 들어가니 이 다음부터는 다르다). 0.6이 기본값.
여기까지 읽으면 알겠지만 이 값이, 복잡하고 움직임이 많은 장면을 얼마나 뭉개줄 지를 정한다(원본 블로그 그림 참고. 빨강선이 CQP, 파랑선이 2pass ABR, 노랑선이 CBR). 보통은 단순한 장면을 그럭 저럭 볼 만 한 수준을 기준으로 고압축옵션을 모색하니까.
두 번째 읽으면서 실제 인코딩을 한다. 1패스까지의 과정에서 원본 영상의 비트레이트를 계산했지만, 인코딩하는 사람이 사전에 입력한 결과물 영상의 비트레이트는 아직 계산에 넣지 않았다. 원본영상의 비트레이트를 결과물 영상이 가져야 할 비트레이트로 나눈 값이 스케일 팩터로 이것을 적용. 그리고 인코딩할 때 부하를 줄이기 위해 1패스에서는 2패스보다 cpu를 덜 먹는 계산을 하므로 거기서 오는 오차를 보정하른 알고리즘도 적용. 그리고 QP를 인코딩 중에 변화시키는 옵션도 적용.
1pass ABR은 영상 전체의 복잡도를 평가하지 않고 앞부분 일부만 읽어 영상 전체의 이미지를 상상해 사용할 파라메터를 생성하고, 그걸 적용해 바로 인코딩. 따라서, 아무래도 오차를 고려해 약간씩 여분을 줄 수 밖에 없으므로 2pass ABR과 비교하면 복잡한 부분은 더 뭉개고 단순한 부분은 대역폭을 더 써서 성능이 조금 떨어짐. (생각해보면 장점은, 인코딩하는 데 시간이 덜 들고, 비트레이트 컨트롤이 되며, 그 특성상 파일의 끝을 몰라도 되고 실시간에 준하는 스트리밍 방송에 사용할 수 있다는 점. 예를 들어, 화면 성질이 크게 달라지지 않는 50분짜리 대담 방송을 5분 지연 방송으로 스트리밍하는 데 쓸 수 있겠네)
CRF는 그래프로 표현하는 비트 배분 방식은 2pass ABR과 같음. 다만, 1pass ABR처럼 일정 구간까지만 미리 읽어 복잡도를 구하고, --qcomp값을 적용한다. (얘기로 봐서는 파일전체를 몇 개 블럭으로 나눠 블럭마다 그렇게 하는지 아니면 첫 블럭에만 적용하는 지는 모르겠다)
ABR과 다른 점은, 스케일링을 주어진 목표 비트레이트 수치를 가지고 하는 게 아니라, 주어진 CRF값을 가지고 함. 따라서, 원본을 2pass ABR과 CRF로 각각 옵션을 주어 인코딩했는데 우연히 결과물의 비트레이트가 같다면 결과물의 비트 배분은 비슷할 것. 그리고, CRF값이 비트레이트의 절대값을 정하지 않으므로, 비트레이트가 사전에 정해지지 않음. 따라서 영상의 복잡도를 모르는 상태에서 대충 이 정도 CRF면 볼 만 하더라는 식으로 값을 줄 수 있음.
FFmpeg and H.264 Encoding Guide https://trac.ffmpeg.org/wiki/Encode/H.264
에서 몇 가지 해석:
Constant Rate Factor (CRF)
1패스 인코딩 중 가장 좋은 압축 효율(김코덱 블로그에 따르면, 구간 몇 개로 나눠 구간마다 2패스 인코딩을 하는 셈이라는 걸로 나는 읽었다). 인코딩 전에 비트레이트와 파일크기를 지정할 수 없는 게 단점(이것은 CQP도 같다).
CRF값은 0~51사이. 0은 무손실, 51은 최고압축. (위의 김코덱 블로그에 따르면 52~63은 비상용이라 함) . 볼 만 한 값은 18~28. 18이면 기술적으로는 무손실(CRF 0)이 아니지만, (원본에 문제가 없다면) 보기에는 무손실처럼 깨끗하게 보일 것이다. 보통 시행착오를 해가며 봐줄 만 한 최고값을 찾아 고압축한다.
이 값에 따른 결과는 지수적인데, CRF값을 +6하면 비트레이트는 대략 반으로 줄어들고 -6하면 두 배가 된다.
CRF Guide http://slhck.info/articles/crf
문서 해석
여기서는 18-23 사이가 볼 만 하다고 말함. 그 다음 내용으로 넘어가서,
개념 알기
일정한 품질로 인코딩하햐려면 보통, 영상의 매 프레임을 같은 정도로 압축한다. 기술적으로 말해, 일정한(Constant) QP(Quantization Parameter)를 유지한다는 것이다. QP는 주어진 픽셀 블럭에서 얼마나 많은 정보를 버리느냐 하는 걸 지정한다.
한편, Constant Rate Factor (CRF)는 각 프레임을 다른 정도로 압축한다. 그러기 위해 추가로 사용하는 정보는 움직임(motion)이다.
사람 눈은 움직이는 물체보다는 정지한 물체를 더 자세하게 인식한다. 그래서 영상 압축기는 물체가 움직일 때는 더 압축하고(= 세세한 묘사를 버리고), 정지해 있을 때는 덜 압축한다(= 세부 묘사를 버리지 않는다). 결과적으로 만들어진 영상은 (같은 용량일 때) 품질이 더 나아 보일 것이다.
어떻게 쓰나?
만약 x264 로 압축한다면, 일정한 품질을 위해 기본적으로 CRF를 쓴다.
그런데 다른 방식, Constant QP가 어쨌거나 품질은 더 나은 거 아냐?
아니다. CQP는 그냥, 시청자가 눈치채지 못하는 영역을 덜 압축해서 용량을 낭비할 뿐이다. 시디리핑해 만드는 MP3가 고주파 대역을 잘라버리는 것보다 더 나쁘다. 순수주의자의 논쟁은 여기선 하지 말자. 1
당신이 컴퓨터라면, CRF가 CQP보다 품질이 나쁘다고 말할 수도 있다. 그럴 수 있어. 그러나 당신이 인간이라서 말이지, CRF가 언제나 더 낫게 보일 것이다. CRF는 당신이 가장 많이 보는 부분을 가장 덜 압축하고, 당신이 가장 덜 보는 부분을 가장 많이 압축한다.
싱글패스 인코딩을 하는 사람들은 언제나 CRF모드를 쓰는데, 요즘은 CQP를 써야 할 이유는 없다.
조금 더 기술적인 설명
Constant QP로 인코딩하면 모든 프레임에서 QP=18 이다. CRF는 움직임이 많은 프레임에선 QP를 20으로 늘리고 움직임이 적은 프레임에선 16으로 줄일 것이다. 무슨 뜻이냐 하면, 평균 품질이 최대신호대잡음비(PSNR) 기준으로 보면 조금 저하되지만, 사람이 인지하는 이미지 품질은 올라간다는 얘기다.
CRF로 인코딩할 때, QP가 조금씩 변한다. 움직임이 많은 장면에서는 QP를 올린다. 왜냐 하면, 그런 장면에서 사람눈은 상황이 어떻게 돌아가는 지에 관심이 가 있어서, 개별 프레임을 고압축해도 알아차릴 시간이 없기 때문이다(당연히 화면을 정지하면 티가 날 것이다). 움직임이 적은 장면에서는 QP값을 낮게 주어 덜 압축한다. 왜냐 하면 그런 장면에선 눈은 이미지 자체를 뜯어볼 시간이 충분하기 때문이고 인코더는 그런 장면은 되도록 소스에 비해 열화되지 않기를 바란다.
CRF는 PSNR 계산으로 평가한 품질을 희생해 (평균적인) 사람이 느끼는 품질을 향상시키는 기술이다. 등가교환, 꼼수
움직임이 많으면 품질이 떨어진다고 했는데, 그러면 내 디지털TV처럼 벽돌이 나오는 거냐?
CRF 방식 자체는 그런 영상에서 보는 벽돌의 원인이 아니다. 그건 대역폭(비트레이트)이 너무 낮아서 그런 게다.
소스에 따라 각 비트레이트에 알맞은 CRF는 다르다. 그래서 어느 영상은 RF(Rate factor) 15를 주면 1500kbps가 나오지만, 다른 소스 - 좀 지저분한 소스- 에선 RF 20에서 그 비트레이트가 나온다. CRF나 CQP로 인코딩한다는 말은, 이 정도 품질을 얻기 위해 비트레이트는 상관하지 않겠다는 말이다. 즉, RF(와 QP)는 비트레이트와 1:1로 대응하지 않는다.
TV방송 화면에 벽돌이 생기는 건, 영상의 벽돌이 생긴 부분의 디테일을 다 표현하려면 그 방송 채널에 할당된 대역폭으로 부족하기 때문이다. 아무리 복잡하거나 빠른 움직임을 표현해야 하는 상황에 처하더라도 할당된 비트레이트 위로는 절대로 넘어가지 않으면서 가능한 만큼 표현한다.
그래도 말이지.. 저품질이 나빠?
CRF(Constant rate factor)로 인코딩하면, 복잡한 부분에선 손실이 있는 게 사실이야. 그렇지만 적당한 품질을 유지하도록 설계돼 있다. 단순한 부분보다 조금 저품질인 정도. 복잡한 부분은 (표현할 정보량 자체가 많기 때문에) 그렇게 해도 복잡한 부분은 단순한 부분보다 비트레이트가 더 높은데, 주어진 rate factor(RF)를 만족하기 위해 비트레이트가 장면마다 오르락내리락하기 때문이다. 단순한 부분에에는 낮은 RF를 적용하고(디테일일 살리고) 복잡한 부분에는 높은 RF를 적용해서(디테일을 죽여서) 비트레이트는 비슷하게 만들 수도 있다.
만약 CRF 25로 인코딩하면 움직임이 많은 장면에서 벽돌을 볼 텐데 이건 그냥 비트레이트가 낮기 떄문이다. 그 설정에서 복잡한 부분은 QP 27을 적용하고 있을 텐데 이건 심하다. 그리고 단순한 부분에는 QP를 23만 쓸 텐데 품질이 확 좋아지려면 더 작은 값을 써야 한다. 하지만 만약 CRF값을 23~17사이에서 적당한 값을 고른다면, 그런 일은 없을 것이다.
- 예를 들어, 움직임이 많은 동영상에서 고품질 스틸샷을 캡쳐하고 싶어하는 걸그룹 팬이나, 영화나 애니의 장면 하나 하나를 세세하게 뜯어보고 싶어하는 사람, 짤방을 얻고 싶어하는 사람일 것 같다. [본문으로]
'소프트웨어와 콘텐츠 > 트랜스코딩' 카테고리의 다른 글
곰인코더 설치기 (0) | 2017.06.06 |
---|---|
샤나인코더(동영상 변환): HEVC 인코딩 가능 (0) | 2017.05.28 |
미디어코더 트랜스코딩, 음성트랙과 영상트랙 결합 (0) | 2017.05.24 |
음악파일을 몇 가지 포맷으로 변환해 본 기록 (대역폭 스펙트럼과 파일 크기) (0) | 2017.05.15 |
미디어코더(MediaCoder) H264 CUDA 인코딩 옵션 잡아준 것 메모 (0) | 2016.11.25 |
미디어코더 AAC 트랜스코딩 메모/ 데이터 용량 잡담 (2) | 2016.11.20 |
미디어코더(MediaCoder) 사용 노트 (0) | 2016.11.15 |
flac -> aac, flac -> ogg 변환 테스트 (0) | 2015.12.15 |
Viewed Posts
|
Recent Comments
|
Recent Posts
|