WhiteBlue FD Studio 3

무려 2500k의 FLV가 니코비디오에 업로드되어있다.
문제는 여기서 그치지 않고 ニコニコ動画 ベンチマーク라고 검색해보면 수많은 2000k
혹은 그 이상의 영상이 올라와 있는 것을 볼수있다.
물론 관리자가 그런것은 삭제를 하지만 실로 놀라운일이 아닐수 없었다.

어떻게 올린것인지 짐작은 하고있었다. 바로 MetaData를 변경해 사양을 속이는 경우인데
업로드날짜를 살펴보면 1년전은 가능했을법도 하지만 지금은 막혀서 안될지도...

혹시나 해서 확인사살해볼겸 찾아보니 http://okwave.jp/qa3874107.html?ans_count_asc=1
이런 문서가 나왔는데 역시나 내 예상이 적중.
유튜브에서는 된다고 하는데 현재는 모르겠다. 어떻게 하는것인지 좀 찾아볼 가치는 있을것 같다.
화질이 우수하다면 솔직히 유튜브도 나쁘진 않다. 내가 애초에 WebFLV를 벤치마킹한것도
니코동화와 유튜브. 특히 영상플레이쪽 측면에선 완전히 유튜브의 것을 따라했었다.

다른 방법은 없을까 한번 확인해 보아야겠다.

오늘자로 WebFLV3 v3.1 final release
최종갱신이력이라면

- UCC해킹지원 -> 거의 작동안함 ㄱ- (왜 업데이트한건데?)
- 니코동화 흐르는 덧글 기능향상 (영상파트쪽은 이것으로써 퍼포먼스향상연구 완료)

드디어 니코동화의 흐르는 덧글의 분석 및 기능구현이 완료되었다.
역시 한화면에 30개 한정으로 보여주도록 하니까 1000개의 메세지라도 문제없이 처리가 가능했었다.
다만 역시나 비트레이트가 높으면 안됀다. 데드라인은 거의 비트레이트 1500k 근처
니코동화와 동일한 사양인 600 ~ 800k 사이가 가장 이상적이다.

- 우선 표시된 덧글은 5초간 화면에 머무르다가 화면밖으로 사라진다.
- 한 화면에 보여줄 덧글은 30개. 그 상태에서 덧글을 입력하면 바로 입력되는게 아니라 스텍이 30개 미만일때까지 기다렸다가 삽입한다. (미구현)
- 30개를 넘어서면 스텍에 쌓지않고 무시
- 배열연산속도를 따져보니 1000개라서 걱정되었는데 속도가 빨라서 그다지 문제가되지 않는다고 판단. 매 프레임마다 1000개의 배열을 검색하는 과정을 삽입. 온스크린 덧글을 추출한다.

뭐 대충 생각나는대로 적는다면 이정도이고 Timer 를 사용해 약 10ms 정도의 속도로 렌더링을 하면 이렇게 된다.
물론 이쪽은 무거운 Flex이기 때문에 니코보다 퍼포먼스면에선 떨어진다. 그래도 이정도면 월추 비슷하지 않을까?

이제 다음 버젼은 3.2
상당한 기능이 추가될 것이다.
대략 정리해보면

1. 메세지리스트
2. 과거로그
3. 덧글쓰기관련

이정도가 되지 않을까 싶다.
인자 슬슬 니코동화 플레이어와 많이 비슷해져가는 느낌이 든다.

아래는 샘플영상

비트매니아IIDX - quasar 원핸드영상: http://www.starocean.co.kr/webflv3/index.php?msg=http://www.starocean.co.kr/webflv3/sm4792048.xml&vid=http://www.starocean.co.kr/webamp3/smile.flv

슈거단센 (우마우마): http://www.starocean.co.kr/webflv3/index.php?vid=http://www.starocean.co.kr/webamp3/Sugardansen.flv

스타오션3로 INORI (MV모음집): http://www.starocean.co.kr/webflv3/index.php?vid=http://www.starocean.co.kr/webamp3/so3dc_mv_inori_nico.flv

작년(2007년) 5월부터 시작된 WebFLV의 개발.
처음부터 WebFLV의 목표는 나 혼자만이 쓰기위한 플레이어였다.
당시 나는 니코동화에 푹 빠져있었고, 급기야 그것을 내손으로 모방해보고 싶은 충동에 WebFLV를 만들게 되었다.
물론 처음 계기는 그것이 아니었지만 니코동화가 결정적인 원동력이 되어주었다.

한가지 배아픈건 내가 만든 소스가 아무런 댓가없이 푸딩TV와 테레비에 넘어갔다는 것이었다. 아마 푸딩TV의 것은 전에 회사에서 서비스 준비할때 다른 프로젝트때문에 소스를 다른사람에게 넘겼는데 그사람이 어처구니없이 파란 푸딩TV로 넘겨버린것 같다.
테레비는 내가 흔쾌히 준것이지만 어떻게 하다보니 그렇게 되버렸다.
아무튼 내가 오리지날이라는 자부심으로 자기위로를 해야만 했다 ㅠ.ㅠ

각설하고 니코동화의 예기.
처음 흐르는 메세지는 마냥 신기하기만 했다.
그냥 시간에 따른 메세지를 흘려보내는줄 알았다.
그러다보니 메세지 갯수가 늘어나면 버벅이기 시작했다.
고민에 빠진끝에 설상가상으로 회사에서 큰 프로젝트가 넘어와서 당분간 개발을 연기할수밖에 없었지만 틈틈히 시간을 내서 만들고 있었다. 그러기를 1년. 드디어 프로젝트가 끝나고 다시 WebFLV개발에 매달렸다.
그러는 동안 어느새 WebFLV는 버젼 3.0으로 넘어가고 있었다.
3.0에선 FLEX3로 플랫폼을 바꿔 개발을 했다.

먼저 FLEX3의 Framework이라던지에 대한 지식이 필요했고 거기에 맞는 개발패턴이라던지 여러가지를 알아야만 했다. 때문에 플랫폼이식만 무려 4개월이 걸려버렸다.
물론 이것도 회사에서 또다시 맡은 프로젝트때문에 시간을 내서 틈틈히 연구하고 만들었으니까 그렇지만 그렇지 않았다고 해도 그만큼은 걸렸을 것이다.

플랫폼이식을 마치고 한동안 회사를 그만두고 방에 틀어박혀 게임만 하고있었는데
어느날 생각이나서 다시한번 매진하게 된것이다.

일단 현재 있는 설계를 좀더 탄탄하게 바꾸고 UCC해킹기능을 추가하고 (작동은 거의 안하지만 ㄱ-)
이제 남은것은 니코동화의 흐르는 메세지의 연구와 기능업그레이드이다.
현재 있는 것이 너무 불안정하고 무겁기에 한번 니코동화의 SWF를 까봐야했다.
미안하긴 하지만 디컴파일 해서 까봤다.
까는김에 내가 소스를 준 테레비 서비스의 것도 한번 까봤다.

역시나 테레비도 내가준 소스를 준해서 상당한 커스텀을 해 개발을 했었다.
다만 이쪽은 내가 원하는 기능이 전부 갖춰져있지 않았다.
물론 부드럽긴 하지만 이건 아니다 싶은것이다. Seek가 불가능하다는점과 덧글을 쓰면 강제이동이 맘에 안들었다.

일단 테레비는 패스. 이제 니코동화의 것을 볼 차례다.
일단 애니메이션 수식은 어렵지 않게 찾을수 있었다 (밤을 샜지만 ㄱ-)
적용해보니 많이 달라진건 없는것 같은데 수치가 정말 미묘했다.
결국 사이즈를 512 * 384, fps는 25, 비디오는 30fps, bitrate를 니코동화의 것과 똑같이 맞춰서 실제 니코동화와 조건을 완벽하게 맞추고 테스트 해봤더니 그제서야 니코동화와 완전히 똑같은 성능으로 돌아가고 있었다. 처음에는 그것이 비트레이트와 사양때문이라고 생각했다.

그러나 문제는 거기서 그치지 않았다.

자세히보니까 스텍에 메세지를 쌓고 그것을 읽어와 뿌려주고 있었고
이 스텍의 내용은 시간이 변함에 따라 계속적으로 변하고 있었다.

내가 테스트한건 184개였는데 스텍의 내용은 30개 제한
실제 니코동화는 1000개의 메세지를 전부 보여주고 있었다.
내가 구현한것으로 1000개로 늘려보니 역시나 뻗는다 ㄱ-
스텍 30개라는것은 한 화면에 보여줄 갯수를 의미했다.
즉, 매 시간마다 스텍의 내용을 업데이트하고있고, 그 스텍은 현시간에서 보여줄 메세지의 스텍으로 이루어져 있고, 스텍은 시간이 최근에 등록된 순으로 정렬이 되어있는 것이고
메세지를 렌더링 하면서 매 프레임마다 30개의 메세지를 화면에 뿌려주는 것이다.

컴퓨터의 연산적인 측면에서 볼때 렌더링쪽이 부하가 많이 걸린다는 것을 생각하면 당연한 것이었다.
다만 한가지 문제에 봉착한것이 있다.
만약 스레드 갯수가 1000개라면 매 프레임마다 스레드를 검사해 현시간에서의 최근등록 30개순으로 보여주어야 할까 하는것이다.
초당 25프레임이라는 것을 감안하면 상당한 부하가 예상되는것이었다.
현재 이부분에 대한 고민이 필요할것 같다.
시간의 흐름에 따른 제한된 갯수의 메세지를 화면에 렌더링하는 것 말이다...

이전 포스트: 5부 - avisynth와 먹싱, 인코딩, 추출

앞서서 마스터버젼의 영상을 만들었을 것이다.
아니 안만들었다고 해도 앞의 내용은 짚고 넘어가야 하는 것이다.
우리는 이제 ucc에 올리기 위해 웹용버젼으로 제작할 것이다.

인코딩 방법은 앞서 소개했으니 다 알거라 생각하고 여기서는 해당 UCC용으로 설명하려한다.

우선 UCC에서는 크게 2가지 포멧을 지원한다.
flv, mp4 가 그것이다.
mp4를 bypass하는 곳은 드물지만 일본의 zoome.jp, nicovideo.jp가 있다.
flv를 bypass하는 곳은 nicovideo.jp, migame.tv가 있다.
migame.tv가 아니면 전부 일본서비스인데 각각 사양이 전부 다르다.

일단 mp4가 올라가는 zoome.jp는 영상, 오디오 합쳐서 1500k를 넘지 말아야한다. 물론 코덱은 H264
nicovideo.jp는 프리미엄과 일반이 다른데 역시 H264로 636k가 넘지 말아야한다. (일반) 프리미엄은 800k정도이긴 한데 돈내야 하니까 패스 ㄱ-
일단 nicovideo.jp는 flv, mp4전부 636k만 넘지 않으면 그대로 올라간다.

migame.tv는 flv만 지원하지만 제한없이 올라간다는 강점이 있다. 광고가 신경쓰이지만 현재 국내환경에서는 이곳이 유일하다.
여담이지만 3000k 정도로 만들어두길 권하는데 이유는 그 이상 넘어가면 감상하는데 무리가 생기니까 3000k정도가 웹에선 가장 적당하다.

mp4로 인코딩 하려거든 앞서 megui로 다시 해당사양에 맞춰 다시 인코딩하면 된다.
flv의 경우는 1부에서 설치한 flvenc로 하면 된다.
간단하게 bat에 드래그앤드롭으로 해결할수 있으니까 별도의 설명은 생략한다.


후기
여기까지 모든 과정을 소개를 했다.
물론 부족한점이 많겠지만 일단 이블로그의 대부분의 방문자가 인코딩 관련 정보를 찾는 사람이었고 나 역시 그동안 쌓아온 지식을 정리할겸해서 6부작으로 다루어보았다.
최대한 자세하게 다룬다고 적었지만 아무튼...
도움이 되길 바라며...

이전 포스트: 4부 - 프레임의 기초와 H264에 대해

앞서 우리는 H264코덱과 프레임의 기초에 대해 살펴보았다.
자, 그럼 기초지식은 모두 갖춘 셈이니 본격적으로 인코딩에 들어가보도록 할까?
1부에서부터 따라왔다면 여러분의 PC엔 이미 avisynth가 설치되어 있다.

이 포스트 시리즈에선 megui를 주력 인코더로 사용하고 있는데 가장 좋기 때문이다. 물론 주관적이긴 하지만 나는 megui를 즐겨쓰기 때문에 역시 여기서도 megui기준으로 설명한다.

먼저 megui로 인코딩을 하려면 avisynth 스크립트를 작성해야한다. (avs라고도 부른다)
친절하게도 megui는 avs 스크립트 작성기가 있으니까 tool -> avisynth script creator를 실행해 작성기를 띄운다. 인터페이스가 직관적이니까 따로 설명은 필요없는데, 중요한건 megui는 audio를 자동으로 감지하지 못하기 때문에 edit 탭을 보면 audio=false 라고 되어있을 것이다. 이것을 수동으로 true로 바꿔주어야한다.
만약 자막과 함께 같이 인코딩 하고싶으면 TextSub("파일명") 을 사용하는데
보통 영상파일을 맨위에서 열고 그 밑에서 자막을 여는것이 좋다.
역시 파일의 전체경로포함해줘야 한다.

avisynth에 대해선 나도 잘 모르거니와 megui에서 편집기로 작성해 만드는것밖에 모르니 이정도로 해주고 넘어가도록 한다.
여담이지만 avs를 사용하면 virtualdub에서도 mp4라던지를 열수가 있게된다. 보통은 안열리지만 avs를 거친다면 열수 있게 된다.

megui에 대한 자세한 내용은 ba7man님의 포스트를 참고하면 사용법은 익힐수 있을것이니 사용법을 알고 싶으면 이쪽을 참고해주시라

그럼 이후부턴 megui를 쓸수 있다는 가정하에 진행한다.
만약 영상에서 특정부분을 잘라서 특정부분만을 인코딩 하고 싶다면 tool -> avs cutter로 잘라내면 된다.

앞서 포스팅에서도 썼듯이 인코딩은 rawdata로 인코딩하는것이 좋다고 했으니
video -> rawavc
audio -> m4a
로 enqueue해 인코드한다.
queue analysis pass를 영상인코드전에 실행하면 인코딩에 앞서 영상을 분석하는 단계를 거치게 할수 있다. 화질에 도움이 되는지는 모르겠지만 ㄱ-

이제 encode를 행하자. 끝나고나면 이제 컨테이너에 담는일만 남았는데
megui에서도 muxer를 지원하니 muxer로 스트림을 담아서 파일로 만들면 된다.
역시 queue에 작업목록이 올라올테니 확인하고 수행하면 된다.

본인은 avi, mp4는 megui의 것을 사용하고 mkv는 mkvmerge를 사용해 muxing하는데 단순히 mkvmerge가 정식 mkv muxer니까 사용하는것 뿐이다. gui도 있으니 1부에서 받을수 있다.

반대로 영상파일에서 rawdata를 뽑아낼수도 있는데 1부에서 소개한 yamb로 mp4의 rawdata를 뽑아낼수 있고, mkvextract로 mkv의 rawdata를 뽑아낼수 있다. avi는 모르겠다 ㄱ-
그래서 난 avi컨테이너를 안쓰는 편이다.

여기까지 인코딩과정에 대해 살펴보았다. 물론 부족한것도 있겠지만 아무튼 이정도만으로 충분히 도움이 되리라고 본다.

마스터버젼을 여기까지 만들었으니 이제 UCC에 올려야 하지 않겠는가?
그것은 다음포스트에서 다뤄보도록 하지...

다음 포스트: 6부 - UCC에 업로드

이전 포스트: 3부 - 동영상의 기본구조에 대해

앞서 동영상파일의 기본구조에 대해서도 알아봤으니 이제 본격적으로 인코딩을 해보자.
일단 인코딩하기에 앞서 제일 중요한것은 비트레이트이다.
물론 고급옵션을 건드리면 화질향상을 노릴수는 있지만 큰 차이는 별로 없다.
따라서 높은 화질을 요한다면 역시 비트레이트는 높게 잡아주는것이 좋다.

그렇다고 한없이 높게 잡아주는것도 아니다.
보통 800 * 448정도라던지 하는 사이즈라면 3000~4000k 정도라면 충분하며
1280*720정도라면 5000~6000k 정도면 아주 충분히 소장용버젼의 가치가 있는 화질이 나온다.
그 이상은 차이가 별로 없기 때문에 의미는 없다고 보는게 좋다.
물론 이것은 게임영상의 예기이다.
보통 애니메이션이나 필름(영화)영상은 2500k ~ 3000k 정도면 충분히 소장용 화질이 나온다.
실제로 현재 H264코덱으로 릴되고있는 애니나 필름영상도 모두 2500~3000k 정도로 릴되고있다.
물론 1080p정도 사이즈가 되면 5000k정도로 올라가긴 한다.

일단 본인조차도 H264코덱에 대해 깊이 아는것이 아니라서 부족할지도 모르지만 현재 H264로 릴하는 립퍼들 역시 이 코덱에 대해 깊이 알고있는것이 아니라서 화면이 깨진다던지 하는 부분이 나오는 모습을 자주볼수 있다.
그도 그럴것이 현재 H264 코덱은 현재진행형으로 개발단계에 있기 때문이다.
즉 미완성 코덱이란 예기이다.
또한 인코딩옵션이 워낙 많고 방대해서 립퍼들이라도 그것을 전부 다 알고있는 사람은 없지 않을까 싶다.
그만큼 H264코덱이 다루기 어려운 코덱이긴 하지만 화질하나는 정말 끝내주게 좋은 코덱이다.
다만 하드웨어를 많이 가린다는것과 압축률이 워낙세서 디코드하는데 부하가 좀 심한편이라는게 단점이긴 하다.

일단 옵션을 전부 설명하는것은 무리이고 중요한 옵션을 몇개만 다루어보고자 한다.
설명은 megui 기준으로 할것이다.

일단 아래의 설명에 들어가기전에 아래의 포스팅을 짚고 넘어가시라

본인의 x264 옵션설명

<프레임의 기초>
프레임이란 무엇인가하면 그전에 동영상데이터가 어떤 구조로 이루어져 있는지 알아두어야 한다.
먼저 영상데이터는 이미지의 연속으로 이루어져있다.
그림을 한장한장 그려서 연속적으로 넘기는 방식으로 이루어져 있다.
이 상태의 데이터를 무압축데이터라고 부른다.
영상의 압축은 이러한 그림의 한장한장을 어떻게 압축하느냐에 달려있는데
코덱이라는 녀석이 이 데이터를 압축하고 해석하는 능력을 가지고 있다.

먼저 코덱이 어떻게 영상을 압축하는가를 알아보면
일단 코덱에서는 모든 프레임의 픽셀정보가 아니라 중요한 프레임이라고 예상되는 프레임을 자동으로 감지해서 그 프레임의 픽셀정보만 남겨두고 나머지는 전부 날려버린다. 그런 실제 픽셀정보가 담긴 프레임을 키프레임이라고 부른다. 나머지는 전부 예측으로 보여준다. 즉, 실제 픽셀정보에 기반해 보여주는게 아니라 단순한 코덱에서의 예측으로 보여준다는 소리이다. 모든 코덱이 이러한 방식으로 이루어져 있는데, 보통 키프레임은 코덱이 자동으로 잡아주는데 장면과 장면이 바뀌는 지점에서 알아서 삽입을 한다.

이렇게 키프레임과 키프레임 사이의 영상을 어떻게 예측해서 보여줄것인가를 디코딩이라고 부르고, 이러한 키프레임과 키프레임 사이의 예측정보를 어떻게 만들것인가를 인코딩이라고 부른다.

이정도로 프레임의 기초를 마치도록 하고 이제 실제 중요한 옵션에 대해 알아보도록 하자.

<Main 탭>
●General 영역
- Mode: 인코딩모드를 지정한다. quantizer, 2pass, 3pass, quality, ABR 모드가 있고 Turbo 모드에 체크를 하면 인코딩시간이 줄어든다고 한다.
- Bitrate: 비트레이트나 quantizer값등의 모드에 따른 세부수치를 지정하는데 lossless에 체크를하면 무손실압축으로 작동하지만 추천하는바는 아니다 ㄱ-

▼ ABR: 1pass 인코딩이다. 비트레이트를 일정하게 부어준다.
▼ Quantizer: 지정된 값으로 영상을 가변비트율로 비트레이트를 부어준다. 용량이라던지 비트레이트를 알수가 없다는 단점이 치명적이지만 화질하나는 보장한다. 보통 10까지는 무손실급, 15정도는 울트라초고화질, 18정도가 초고화질, 22정도가 고화질에 속한다. 26정도가 웹에서 볼만한 고화질수준 28정도가 웹에서 볼만한 중간급 화질정도이다. 이 값은 소스에따라 전부 틀려진다. 얼마의 값을 부어줄건지는 경험을통해 알게된다고 한다.
▼ Quality: Quantizer와 마찬가지로 가변비트율이다. 차이는 잘 모르겠다 ㄱ-
▼ 2pass: 영상을 2번 나누어 인코딩 하는데 첫번째는 대략적인 분석, 두번째에 실인코딩이 들어간다.
▼ 3pass: 2pass와 같지만 이녀석은 3번 이상의 인코딩을 여러번 거칠수 있다. 오더는 1,3,2인데 1,3,3,2는 4pass, 1,3,3,3,2는 5pass가 된다. 3을 여러번 늘리는것으로 pass수를 늘릴수 있다. 얼마까지 늘어나는지는 모르겠지만 보통 5pass면거의 화질보정이 멈춘다고한다.

●Deblocking 영역
- strenth / threshold: 정확한 설명은 잘 모르지만 (영어가 된다면 모르겠지만, 전문용어라 영어가 된다고 쳐도 이해하긴 어려울것이다.) -3 ~ 3까지 변하는데 마이너스로 갈수록 샤픈해지고 플러스로 갈수록 스무스하게 되는데 보통 HD립 영상들은 -3, -3으로 세팅한다고 한다. 화질이 깨끗한 원본인 경우 0,0 으로 세팅할것을 권장하고 좀더 자세한 정보를 알고 싶다면 이하의 사이트를 방문해 보길 권한다

종스비님의 x264 deblocking 값에 따른 화질차이
오호라님의x264 Deblocking 값에 따른 화질 비교

●Misc영역
- fourCC: Hex로 열면 맨 앞에 나오는 4글자를 말한다. 이 값에 의해 디코딩할 코덱을 찾아 연결해 재생하는데 쓰이는데 보통은 아무거나 주어도 상관없지만 Vegas7 정도의 편집기에서 열려거든 avc1으로 세트하지 않으면 안됀다. 또한 플래시의 기술을 사용해 제작된 UCC들도 avc1 이라고 넣는것이 좋다. -> avc1 이 본래 H264의 표준 fourCC이다.

<RC and ME 탭>
●ME 영역
모션감지라고 해서 그것과 관련된 세팅이다. 본래 코덱에서는 데이터를 압축할때 키프레임 단위로 압축을 하고 예측을 해서 보여주는데, 보다 자세한 내용은 위의 본인의 x264 옵션설명과 프레임의 기초부분을 참고해서 보시고, ME라는 것은 이런 예측정보에서 움직임을 잠지해 내는 것을 말한다.
- Chroma ME: 모션감지능력을 보다 효과적으로 행한다. 화질에 현격한 영향을 주므로 체크한다.
- MERange: 모션을 감지할 최대영역이다. 값이 클수록 화질이 올라가지만 반대로 인코딩시간도 올라간다. 일단 고화질애니메이션의 경우는 32로 세팅한다. 게임영상도 마찬가지로 32로 세팅.
- Scene Change Sensitivity: 장면변화의 예민한 정도를 나타낸다. 값이 높을수록 과도한 장면변화가 있는 부분에서 보다 키프레임을 많이 삽입해 퀄리티를 높인다. 초고화질정도의 영상이라면 80정도로 세팅한다. 기본값인 40으로 놓는 립퍼도 있다.
- MEAlgorithm: 모션감지 알고리즘을 선택한다. 고화질의 경우는 Multi hex정도를 넣는다
- Subpixel Refinement: 모션감지에 있어서 영상에 파티션을 어떻게 줄것인가를 결정하는 옵션이다. 6정도가 좋고 7로 주면 아주 쩌는 화질이 나온다.

●Misc 영역
- Keyframe Interval: 키프레임을 주는 최대간격을 말한다. 값이 적을수록 키프레임이 많이 들어가지만 용량이 상승
- Min GOP Size: 키프레임의 최소간격을 말한다. Max의 10분의 1을 세트하는것이 보통이다. 이 값은 fps값과 같은 값을 세트하면 되지만 뭐 상관없다.

●Quant Options 영역
- CABAC: Context Adaptive Binary Arithmetic Coding을 사용한다. 보통 CABAC를 사용하면 디코딩에 부하가 많이걸리지만 압축률 역시 좋아져 용량도 절약한다. 하지만 끄면 디코드의 부하가 적어지는 대신 압축률이 낮아져 용량역시 늘어난다. 보통 켜는 편이다.
- No Dct Decimation / No Fast P-Skip: 화질과 퀄리티에 영향을 많이 준다. 둘다 켜도록 뭐하는진 나도 모른다 ㄱ-

<Advanced 탭>
●Quantizer Matrices: 화질에 역시 가장 중요한 역할을 차지하는 녀석이다. 보통은 기본으로 쓰는데 1부 포스트에서 올린 Matrix를 받은경우에는 여기에 그것을 세트하면 된다. 화질보정과 관계가 있다.


여기까지 중요한 옵션을 살펴봤는데 나머진 나도 모르거나 까먹은 부분이다 ㄱ-;
신경 쓰인다면 1부 포스트에서 올린 x264 profile부분을 참고해도 좋다.

좀더 자세한 정보를 보고싶거든 아래의 블로그를 방문해 보시라

http://blog.naver.com/PostView.nhn?blogId=jongsbee&logNo=20054878124&categoryNo=0&viewdate=&cpage=1&postListTopCurrentPage=1

물론 H264는 더 자세하게 알고싶거든 doom9.org 를 방문할것을 권하지만 이쪽은 영어권 사이트이다. H264에 대해 더 깊이있게 알려거든 영어는 필수로 알아야한다. 국내에선 깊이있는 정보는 얻을수 없다는것을 명심해라. 물론 일본어도 알면 좋은데 일본의 립퍼들의 정보도 상당한 도움이 된다.

오디오 인코딩은 간단하니까 넘어간다. 역시 megui에서 인코딩하면 된다.
소장용이라면 320, 448, 640k로 세팅하고 웹공개용은 192k정도면 충분한 고화질이다.
니코비디오 같은곳은 128k정도 추천.

일단 코덱에 대해 살펴봤는데 아직 본격적인 인코딩을 들어가기엔 이르다.
다음포스트에선 avisynth에 대해 살펴보고 실제 인코딩과 먹싱등에 대해 알아보도록 한다.

다음 포스트: 5부 - avisynth와 먹싱, 인코딩, 추출

이전 포스트: 2부 - 캡쳐 및 편집

캡쳐 및 편집을 마쳐 Huffyuv영상 - 무압축음성의 AVI를 만들어 놓았다면
여러분은 이제 마스터버젼의 소장용 영상을 만들어야한다.
마스터버젼의 영상은 무엇으로 하든 자유이다.
본인이 좋다고 생각되는 포멧으로 만들면 된다.
물론 마스터버젼을 만들지 않아도 상관은 없다.
그런데 여러 경험상 이전에 만들어두었던 영상을 나중에 반드시 또 쓰고싶은 경우가 생기는데 화질을 끌어올리고 싶다면 소장용 마스터버젼을 만들어두는것을 권장한다.
뭐 건너뛰어도 상관은 없다.
일단 오늘은 그것은 차치하고 동영상의 기본구조에 대해 살펴보고자 한다.

여기서는 본인의 취향을 기준으로 진행하도록 한다.
나는 H264코덱을 굉장히 좋아하기 때문에 H264 - AAC 코덱으로 인코딩해 mp4에다가 담아 마스터버젼을 완성한다. 하지만 언제나 이것을 고집하는것은 아니고 XBOX360콘솔의 경우 디지털출력을 AC3로 하기 때문에 이경우는 AC3사운드를 사용해 mp4가 아니라 mkv에다가 담아넣는다. 그도 그럴것이 mp4는 ac3를 담을수 없기 때문이다.

아마 인코딩에대해 처음인 사람은 담는다느니 mkv니 mp4라느니 하는것에 대해 물음표만 띄울텐데 이제 인코딩하기 전에 사전지식을 알아보도록 한다.

먼저 동영상파일의 구조에 대해 간략하게 살펴보도록 한다.

동영상파일은 크게 두부분으로 나뉘어져 있다.
첫번째는 RAWDATA,  두번째는 CONTAINER인데
어떤 인코딩툴이 전부 마찬가지이듯이 모든 영상은 안에 RAWVIDEO, RAWAUDIO를 담고있다. 이 RAWDATA들은 인코더가 만든 데이터들인데 코덱에 따라 데이터의 형식이 전부 다르다. 만약 H264로 인코딩했다면 RAW데이터는 avc 형태로 만들어지고 h264 혹은 264라는 형식의 확장자를 갖게된다. 확장자는 그냥 단순한 이름일뿐 모두 avc형태이다. AAC로 인코딩했다면 역시 aac라는 확장명을 가지는데 이것역시 확장명도 단순한 이름에 지나지 않는다.

이러한 rawdata들을 스트림이라고 부른다.
영상스트림, 음성스트림이라고 부르고 rawvideo, rawaudio라고도 부르기도 한다.
이 녀석들은 코덱으로 인코딩한 데이터의 원시데이터이다.
즉 영상을 mp4로 만들었는데 mkv로 바꾸고싶다
그럴경우엔 이 rawdata를 추출해서 단순히 mkv컨테이터에 담기만 하면 땡인것이다.
avi로 바꾸고싶은 경우는? 역시 rawdata를 추출해서 avi컨테이너에 담으면 땡이다.
보통 이런 지식을 모른다면 무식하게 또 재인코딩을 할것이다.
그럴 필요가 없는것이 우린 이미 인코더에서 rawdata를 손에 넣었기 때문에 컨테이너만 바꿔주면 땡이라는 것을 알수 있기 때문이다.

그러면 이제 컨테이너가 무엇인지 감이 잡힐 것이다.
컨테이너는 이러한 rawdata들을 담는 그릇과 같은 역활이다.
여기에는 비디오데이터, 오디오데이터가 들어가며 mkv같은 컨테이너의 경우는 chapter, subtitle, cover-image 등이 들어가기도 한다.
또한 컨테이너는 담겨진 비디오와 오디오데이터의 간략한 메타정보나 인코딩사양등의 정보를 기록해 보존해두는 역할도 한다.
아마 본적이 있을것이다. 동영상파일에 마우스커서를 가져다대면 비디오의 제목이라던지 인코더, 비트레이트, 코덱 뭐 이런 정보가 뜨는 모습을...
아니 KMP로 열면 파일정보에 이러저러 정보가 뜨는 모습을 보았을 것이다.
이것은 muxer라고 불리는 종류의 소프트웨어가 컨테이너에 비디오와 오디오를 담아 파일로 만들면서 파일에 기록해둔 메타정보이다.

그러면 이제 대충 인코딩할때 어떻게 해야하는지 감이 잡히는가?
바로 rawaudio 와 rawvideo 를 먼저 인코딩해서 muxer로 컨테이너에 담으면 된다.
물론 인코딩할때 rawdata로 만들어 달라는 옵션을 달아야한다.
megui의 경우는 x264에 RAWAVC, xvid에 RAWASP 로 인코딩하는 옵션이 달려있다.
물론 mp4box, mencoder, x264 등의 많이 알려진 H264 인코딩 소프트웨어들도 모두 이러한 기능을 지원하고 있다. 다만 이러한 소프트웨어들은 전부 커멘드라인 방식이라는 점이 치명적이긴 하지만 bat 배치파일로 만들어서 쓰면 상당히 유용하게 쓸수도 있다.
이건 나중에 살펴보도록 하고

이렇게 동영상파일의 구조에 대해 살펴보았다.
아마 많은 립퍼들도 그렇게 할거라 생각하지만 나 역시 인코딩할때 mp4, mkv로 바로 만들지 않고 rawdata로 인코딩한다.
인코더에서 rawdata로 인코딩해 비디오스트림, 오디오스트림을 만들어서 확보해둔 후에 muxer로 붙여쓰면 되기 때문이다.
avi컨테이너에 x264코덱으로 만든 영상들은 모두 이렇게 만들어지는 영상들이다.

다음 포스트: 4부 - 프레임의 기초와 H264에 대해

이것역시 아래의 마리사는 엄청난것을... 과 마찬가지로 처음 인터넷에 공개되었을때 낼름 저장해두었던것.

다운로드

역시 다른이름으로 저장

아마 꽤나 유명한 녀석이 아닐까 싶은데
이놈이 처음 인터넷에 공개되어 화재가 될때 낼름 원본SWF를 저장해두었던 기억이난다.
한동안 잊고있었는데 하드디스크를 뒤지다보니 나와서 낼름 올려본다.

다운로드

SWF니까 다른이름으로 저장하길 추천

이전 포스트: 1부 - 준비

1부에서는 몬스터X를 이용한 캡쳐의 준비를 마쳤다면 이제 본격적으로 캡쳐에 들어간다.
캡쳐는 1부에서 설치한 MxCapture를 사용한다. 캡쳐시 듀얼디스플레이로 출력할것을 권했는데 이유는 간단하다. 딜레이를 줄이기 위해서이다. 애니나 영화등은 상관없지만 액션성이 강한, 타이밍이 중요한 게임이라면 예기가 다르다. 순간의 찰나의 시간차에도 생사가 오가는 그런 게임은 이런 딜레이가 치명타가 되기 때문이다. MxCapture는 캡쳐시에 디스크에 기록하는 과정에서 시간차가 발생하기 때문에 듀얼로 구성해 한쪽은 HDTV나 모니터를 통해 컴포넌트 출력으로 연결해 디스플레이하고 다른한쪽은 캡쳐보드쪽에 디스플레이하는데 1부에서 이 과정은 마쳤으리라 생각하니 넘어간다. (힌트를 주자면 DVD분배기)

먼저 출력세팅일텐데 TV방송이라면 자동으로 잡히겠지만 XBOX360같은 게임은 콘솔기기에서 세팅을 해주어야한다. 콘솔이라면 1080p까지 될텐데 아쉽게도 몬스터X는 1080i까지 되므로 1080p는 세트하지 말고, 권장세트는 720p를 추천한다. 그도 그럴것이 1080i 라고해도 인터레이스방식은 가로줄이 어쩔수없이 생기기 때문에 추천하는바가 아니다.

오디오세트는 취향에 따라 세트하면 되는데 SPDIF광출력으로 연결한 경우라면 SPDIF로, 스테레오로 연결한 경우라면 아날로그(アナログ)로 설정한다. 혹시 출력이 5.1ch이라면 설정에서

이것을 잊지 말도록 한다.
아마 소스가 아날로그5.1ch이 아니라 디지털5.1ch이라면 소리가 안나거나 찢어지는 소리가 날텐데 그것은 스피커에서 디지털소스를 디코드할수 없기 때문이니까 어쩔수 없다. 어차피 extbsgui로 변환하면 제대로 들리니까 걱정할 필요는 없지만 그래도 신경쓰인다면 리시버를 장만하던지 디코더를 장만하던지해라. 그것도 안됀다면 포기하고 스테레오(아날로그)로 설정하도록... 어차피 소장용이 아닌이상 웹에 올릴거라면 현재의 UCC포털의 기술로는 5.1ch은 재생할수 없다 -> 전부 스테레오로 다운믹스해 디코드한다. (원본에 영향을 미치는것은 아니다.)

여기서 알아두어야 할점은 오디오 출력이 AC3인지 AAC인지 어떤지 여부를 알아두는게 좋다. AC3 -> AAC, 혹은 AAC -> AC3로 가면서 음질열화라던지가 있을수 있으니까 본래의 출력에 맞춰주는것이 보존용으로써는 가장 좋기 때문이다. 이것은 인코딩시에 자세히 알아보도록 하고

이제 프리뷰를 눌러서 출력을 해본다. 화면이 약간 흐리거나 그런 느낌이 날텐데 오버레이세팅을 통해 색보정을 해줘야 한다. MxCapture에 오버레이 컨트롤러가 있으니 그것을 사용해 색보정을 자신의 취향에 맞게 설정해준다.

설정해준후에 일단 간단하게 시험인코딩을 해본다. 제대로 캡쳐가 되는지 어떤지를 확인하는 것인데, 이 테스트를 제대로 하지 않고 넘어간 경우 캡쳐가 끝나서 확인하는데 제대로 캡쳐가 안됀경우가 수시로 종종 발생하기 때문에 반드시 거치고 넘어가야한다.

캡쳐시에 fps는 어디까지 되는지는 모르겠으나 59.94는 무난히 캡쳐가 가능했었다. 아마 적어도 사양이 램이 2기가~4기가, CPU가 듀얼코어이상, 하드디스크가 7200rpm 그래픽카드가 ATI정도는 되어야 무난할것이다. 권장은 4기가램, 쿼드코어, 하드디스크가 7200~12000rpm, ATI그래픽카드 정도이긴 하지만....

캡쳐는 AVI 포멧에 Huffyuv로 세트했으니 그렇게 될것이다.
무손실 압축이라곤 하지만 거의 뭐 무압축이나 다름없다 ㄱ-
거의 습관적으로 캡쳐후에 바로 인코딩을 거치는데 MAD무비같은것을 만든다면 인코딩없이 이상태에서 곧바로 편집작업에 들어가는것이 좋다. 왜냐면 H264같은것은 베가스7 같은 편집툴에서 디코드하는데 엄청난 부하가 걸리는데다가 XVID, DIVX같은것은 화질을 생각하면 캡쳐원본에서 곧바로 편집하는것이 화질을 기대할수 있고 시간적으로도 인코딩과정없이 곧바로 들어가기 때문에 시간도 절약할수 있기 때문이다.
다만 베가스7은 제대로된 5.1ch 의 편집이 안돼기 때문에 이경우에는 splitter로 일일이 잘라서 편집해주던가 아니면 다른 제대로 편집이 가능한 어플리케이션을 이용해야한다. 이부분은 본인도 고민중이다. 이 경우에는 오디오는 따로 편집해서 컨테이너에 먹스해야할것이다.(각각 따로작업하란 예기)

편집에서는 되도록이면 huffyuv를 사용할것을 권한다. 이편이 가장 화질을 보전할수 있기 때문이다.

미리 말해두지만 편집할때는 용량에는 자비심을 가지면 안됀다. 개인적으로는 약 500GB정도의 여유공간을 남겨두고 작업하는것을 권한다. 거의 뭐 무압축이나 다름없다보니 의외로 용량이 많이 들어간다. 넉넉한게 이득. (약 1.5TB정도 구축해두는것을 권장)

다음 포스트: 3부 - 동영상의 기본구조에 대해

순위	개수	키워드명
1	22	몬스터x
2	9	h264
3	6	몬스터X
3	6	megui
4	5	x264
5	4	mkv avi
5	4	X264
5	4	mkv 인코더
6	3	고화질인코딩
7	2	h264 인코더

내 블로그 방문 검색어순위이다.
1위는 부동의 몬스터x
그 뒤를이어 h264와 megui가 추격하고있지만
1위를 넘보기엔 글른듯...
내가 몬스터x 관련 글을 쓴것이 캡쳐보드 Monster-X 게임영상 인코딩
이 포스팅인데 좀 보니까 대충대충 쓴티가 팍 난다 ㄱ-;
사실 인코딩에관해 포스팅 하나에 전부 담는다는것은 좀 무리가 있지 않나 싶다.
조금씩 차근차근 길게 주제를 가지고 다뤄봐야 할 문제같다.

전에 한번 몬스터X를 사용한 캡쳐법을 다룬적이 있는데 다시 보아도 좀 뭔가 날림인듯 ㄱ-
이번엔 자세하게 제대로 다뤄보려한다.

<준비물>
몬스터X, 젠더, DVD분배기, 컴포넌트 케이블, 콘솔, 모니터
캡쳐소프트 (MxCapture), extBsGui, avisynth, megui, flvenc, mkvmergeGUI, mkvextractGUI, yamb

뭐 준비물은 이정도려나? (아주 기본적인 구성)
먼저 나는 디스플레이를 듀얼로 구성해 캡쳐를 한다.
왜냐하면 캡쳐소프트인 MxCapture는 하드디스크에 기록하는 과정에서 약간 딜레이가 발생하는데, 타이밍이 중요한 게임에서는 굉장히 치명적이다. 따라서 분배기로 한쪽을 컴포넌트를 입력받을수 있는 모니터에 연결해 그것을 보면서 캡쳐한다. 물론 HDTV가 있다면 그쪽에 연결해도 상관 없다.

PS3 혹은 XBOX360의 게임캡쳐는 일단 세팅을 720p로 선택해야 한다. 왜냐면 몬스터X가 1080p를 인식하지 못하기 때문이다. -> 아쉬움
PS2 혹은 PSP의 경우는 각각 480i (PS2), 480p (PSP)인데 PS2쪽은 게임쪽에서 프로그레시브출력을 하지 않는이상 전부 480i로 출력한다. 따라서 가로줄이 어쩔수 없이 생기게 되어있다. 아무리 캡쳐보드라도 소스가 인터레이스라면 가로줄은 무조건 생기게 되어있는 것이다.

※끝에 붙는 문자가 i 이면 인터레이스방식, p 이면 프로그레시브방식 이란 뜻이다.

캡쳐소프트 설치 및 설정
설치를 했으면 이제 인코딩도구를 설치한다.
먼저 extBsGui를 설치한다.

extBsGui
이제 megui를 설치한다. 이놈이 x264 인코딩소프트이다.

megui
이제 yamb를 설치할 차례이다.

yamb 설치
이제 mkv관련 소프트를 설치한다.

mkvmerge, mkvextract 설치
이제 남은것은 단 하나. flvenc이다.

flvenc 설치

이것으로 일단 준비물의 모든 준비과정을 마쳤다.
이제 남은것은 캡쳐와 인코딩



개인적으로 만들어 쓰는 프로필인데 써도 그만 안써도 그만이다.
쓸 사람은 쓰도록 하고, Matrix는 커스텀Matrix파일이다. 역시 쓸사람은 쓰도록...

여기까지 대충 설치과정을 달려왔다. 뭔가 좀 복잡하고 어려워보이고 설치할게 이리도 많은지 하는 생각이 들겠지만 전부다 도움이 될만한 것들이다. 앞으로의 포스팅에도 저 많은것들이 사용될테니 되도록이면 megui, flvenc, mkvmerge, mkvextract, extbsgui, yamb 정도는 설치하는게 좋다. (결국 전부 다란 소리 ㄱ-)

다음 포스트: 2부 - 캡쳐 및 편집

- NicoVideo: 니코비디오 인코딩용
- onepiece profile: 원피스의 H264립퍼가 세팅한 설정을 그대로 세트한것
- ps3-xbox360-with-advanced: 게임영상을 아주 쩌는 화질로 나오게끔 한것. 소장 혹은 감상용으로 사용하길 추천

나는 소장용 마스터버젼과 웹공개용 버젼으로 2개를 인코딩하는데
솔직히 게임용 고급옵션 적용한 프로필도 적당히 손봐서 쓰길 권한다.

이번에 x264 고급옵션관련해서 이것저것 공부해보고 인코딩도 시험해 보았지만
애니의 2000k 급의 화질을 게임에서 얻으려면 2배. 약 4000k 정도를 부어주어야지 그만한 화질을 낼수 있다는 것이다.
사실 애니는 적당히 옵션을 주어도 고화질을 낼수 있지만 게임은 이와는 달라서 2배정도를 부어주어야 한다.

다만 이건 감상용일 경우고 사실 UCC에 올리는건 2000k 로도 충분하긴 충분하다.

게임영상의 경우는 소장용버젼이라면 quantizer 18~22 정도를 주기를 권장한다.
덤으로 버추얼덥에서도 avs를 읽어들일수 있던데 이로써 버추얼덥에서도 mp4 h264를 읽어서 편집하는것이 가능 ㄱ-

커스텀매트릭스는 doom9에서 발견한건데 써보니까 효과가 상당히 좋다.
소스가 좋은품질이라면 HighDetail을 사용

HighDetail -> 쩌는 화질용
HRM -> 웹용 고화질용
MRM -> 중화질용
LRM -> 저화질용
Smooth -> 스무스하게 보여주고 싶을때

정말 2008년이 魔가 낀 해일까? 오늘아침 탤런트 최진실이 사망했다는 소식도 들려왔다.
얼마전에 안재환씨가 사망했다고 한거 같은데...

나도 올해는 잘 되는일이 없었던것 같다. 회사를 그만두고 다른 대기업에 들어가려고 지원을 했는데, 주변인들은 잘 될거라며 실력있으니까 걱정말라고 하지만 나는 왠지 불안하고 떨리기만 한다. 이런 느낌은 수능이후 처음 느껴보는 것이다.

최근 석달전 스타오션3DC를 연재하겠다던 계휙도 mncast의 정책변화로 하기 싫어져서 무산되었고, 니코비디오에 다시 처음부터 올릴려니 처음엔 올리다가 점점 엄두가 나질 않아 거의 포기상태이다. 편수도 123편이나 되었는데...

위의 그림이 현재 나의 상태를 말해준다.
우울하기만 할뿐이다. 왜일까?
우울하다, 자살한다는 사람들을 보면 그 심정을 이해할수 있을것 같을 정도이다.

그동안 내가 찍어왔던 영상중에 쓸만한거 몇개 골라서 아이팟에 넣어보려니까 정말 쓸만한건 몇개 되지 않았다.
정말 많이 노력하고 찍어왔던거 같은데 건질만한게 이리도 없었다니...
더군다나 내가 그렇게 노력을 쏟아부었던 게임플레이 영상쪽은 완전 전멸이다.
내가 플레이하고 찍어놓고도 마음에 드는 영상이 단 한개도 없다니...
역시 난 이것밖에 안돼는 놈일까?

얼마전 내가 자주가던 커뮤니티인 테일즈코리아도 개편후 완전히 규모가 달라졌다. 이제 더이상 내가 알던 그런 테코가 아니었다.
뭔가 하나 쉼터를 잃는듯한 그럼 느낌이다.
테오이를 나온이후 정을 붙이던 곳인데, 지금은 최근 슬레이어즈 레볼루션을 계기로 다시 정을 붙이기 시작한 리나찬님의 슬레이어즈밖에 없는것 같다.
루리웹이야 뭐 맨날 가는곳이고[...]
음, 생각해보니 다음넷 동방카페도 있었군... 거기야 뭐 이미지게시판에서 그림보는 낙으로 가는거고 ㄱ-

그러고보니 점점 노는물이 소박해지고 작아지는것 같다.
처음에 테오이라는 커다란 단체에 있다가 노는인원이 얼마 안돼는 테일즈코리아에 있다가 이제는 정말 몇명밖에 모이지 않는 오붓한 가족같은 분위기인 리나찬님의 사이트이다.

요즘 뉴스를 보면 한숨밖에 안나오고 누가 세상을 떠나고 그런것밖에 나오지 않는다.
회사를 그만두고 XXX대기업에 모든것을 믿고 다른 회사는 가지 않고 놀고있는데
퇴직금조차 받지못해 노동부에 신고를 해놓은 상태지만 이것역시 불안하다.

내가 믿음을 잃은것일까? 그 일이 있은 후 부터 벌써 10년이 지났다.
이제 다시 그분곁으로 돌아가야하지 않을까 하는 생각이 요즘 자주든다.
어릴적에 내 목숨을 건져주신 그분생각이 요즘 너무 자주나곤 한다.
아무래도 그분께서 나를 부르시려고 하는것 같다.

이제와서 생각해보면 지난 10년간 내가 해놓은 일이 과연 무엇일까 하는 생각을 해보곤 한다.
둘러보면 정말 해놓은게 하나도 없다.
게임고수? 그것이야 뭐 자기만족이고 즐기라고 있는것이고...
액션스크립트? 그건 밥벌이잖아...
역시 그분 도움없인 나는 아무것도 할수 없단 말인가?
나 자신이 비참하고 한심해보인다.

이제 나는 어떻게 되는거지?


쓸데없는 푸념을 늘어놓았는데, 누가 이 블로그 찾아와주기나 하겠어?
인코딩관련 포스팅을 몇개해서 그걸로 방문자가 찾아오는거지....

http://terebe.com/user/player.trb?vid=fed7be42204a52708aefeebd01c325c0
(회원제)

얼마전 (한참전) 내가 만들었던  WebFLV로 서비스를 시작한곳이 있는데 그곳이 바로 테레비
사실 저기 동영상위에 흐르는 덧글도 내가만든 WebFLV의 기능을 가지고 고쳐쓴걸텐데
나름 자부심이 있다고 할까? 내가 만든것을 베이스로 개발되어지고 있으니까...

잡소리는 치우고 저 니코동화 유성군의 타이쿤버젼. 한글로 나온다 ㄱ-
보면서 웃겨서 자빠졌다.

웃겨뒤진 메모

AAAB - 댄싱랩소디 - 커팅커보트

집중으로 해놓고 지형지물을 이용해 구석으로 유인한후 저렇게 공놀이해주면 콤보넣는도중에 레벨이 올라간다 ㄱ-
상당히 재밌는듯

공성전. 너무 재밌다. 몇번이고 반복플레이를 했는데 공성전을 이런 재미로 하는구만?
왜 리니지같은데 그렇게 환장하는지 좀 알것같다...
하는김에 시추에이션보너스까지 노려봤다.
걍 돼는대로 막플레이 했으므로 존내허접하네 어쩌네 하는 테클은 사절

인피닛 언디스커버리가 드디어 도착했다.
아 얼마나 기다렸던가 ㅠ.ㅠ
이제 당분간 버닝모드에 들어간다.

그간 인피닛 기다리면서 한동안 손안댔던 BMS를 좀 가지고 놀아봤는데
루나틱레이브2 라고 새로운 플레이어가 나왔길래 좀 건드려 보았는데
마침 BOF2008 마감시즌.

특히 SHIKI님의 곡이 마음에 들어서 해봤는데 왠걸
무려 3곡. 더군다나 한곡은 왠일로 시키씨가 보컬을 넣었다 [...]

SHIKI ~ Lapis (7Key Hyper)
배경애니메이션이 너무도 쩐다. 엄청나게 화려한 BGA에 압도당하고 곡도 무지좋았던 곡이다.

SHIKI ~ Pure Ruby (7Key Hyper)
패턴이 참 재밌던 곡. 역시 시키씨의 특유의 패턴이 참 재밌었던 곡이다. 곡 자체도 좋다.

아직 BOF2008곡 다 안해봤는데 천천히 하지 뭐...

http://find.2ch.net/?STR=beatmania+%CA%D2%BC%EA%A5%B9%A5%EC&COUNT=50&TYPE=TITLE&BBS=ALL

비트매니아의 원핸드로 플레이하는 사람들을 위한 스레드인데
우연히 웹을 돌아다니다가 발견했다.
나도 지금은 음악게임을 접었지만 과거 10년간 음악게임을 하면서 거의 한 7년은 원핸드플레이를 고집해온것 같은데, 비트매니아IIDX의 7키원핸드를 플레이한 경력은 한 2~3년정도밖에 되지 않는다.

보니까 플레이하고나면 팔이 아프고 팔목등이 열을받아 뜨겁게 되는 경우가 있는데 (음, 이건 나도 매번 느끼는 것이었다.) 일본애들은 보냉제나 아이스캔음료나 수돗물로 차갑게 한다고 한다. (왜 이것은 생각을 못했을까?)
한번 하고나면 팔이 굉장히 아파 당분간은 휴식을 해줘야 했는데 쉬고난후 다시하면 아파오던 증상은 아마도 아직 팔이 뜨거워서일것이다 라는 생각이 든다.

다른것은 나도 이미 거쳐온것이라 패스했고
손가락의 단련과 손목의 위치.
사실 나는 약지와 새끼의 손가락힘이 부족해서 다양한 패턴을 만드는데 어려움을 느끼고 있었다. 때문에 Xepher 하이퍼난이도를 한번하고나면 손에 힘을 너무 준 나머지 한번플레이로 쉬어야 하는 상황까지 갔었는데 손가락힘이 부족해 너무 힘을줘서 일것이다.
그리고 이유는 모르겠지만 누를수 없는 배치라 생각하는 부분의 70%는 손목의 위치라고 하는 설명인데 확실히 손목을 낮게 잡았을때랑 높게 잡았을때의 느낌은 다르다.
손목을 높게 잡으면 나는 어깨까지 들려올라가서 오른팔에 부담이 너무 많아 주로 손목을 낮게 잡고 하는데 글쎄... 잘 모르겠다.

아무튼 이 스레를 보니까 또다시 접었던 음악게임을 하고싶어지네 -_-;;;
접은후에도 심심풀이로 몇번씩은 했었지만 다시한번 파볼까?
그렇지 않아도 요즘 비트콘이 눈앞에 자꾸 아른거리긴 하는데 ㄱ-

원문: http://zoome.jp/whiteblue3/diary/4/
video: H.264 quantizer 26 (788kbps) with Advanced Option
audio: AAC-LC 192kbps
오래전에 만들었던 자작차분입니다.

DL: http://toez2dj.net/zeroboard/zboard.php?id=d_pds&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&keyword=a%20beautiful%20wing&select_arrange=headnum&desc=asc&no=1360

고급옵션을 사용한 영상테스트겸해서 찍어보았습니다.
애니메이션쪽은 고급옵션을 적당히 사용하면 높은화질을 기대할수 있지만 게임영상은 애니메이션영상과는 달라서 얄짤없이 소용없습니다. quantizer를 주지 않는이상 높은화질은 기대할수 없습니다. (설령 20pass를 준다고 해도 소용없습니다.)
quantizer의 경우는 용량이나 비트레이트를 예측할순 없지만 그래도 고화질을 기대한다면 써보시길 권합니다.
그러나 UCC에 올릴때 quantizer로도 어쩔수 없는 경우는 포기하세요.

※quantizer를 줄때 영상사이즈가 너무 크면 재생시 음성과 영상의 싱크가 맞지 않는데 정상입니다. 보존용 영상을 만들어둘때 쓰세요. 다만 UCC에 올릴려면 사이즈를 줄여야하는데 640 * 480정도를 추천합니다. 대략 quantizer 15정도면 울트라초고화질에 해당합니다.

원문: http://www.digital-digest.com/articles/x264_options_page1.html

이곳의 내용에 본인의 경험을 덧붙였습니다.

<2. 프레임의 기초>

현대의 비디오압축기술은 3가지형태의 타입으로 만들어진다. 하나는 Intra(I) frame (일반적으로 keyframe이라고 부른다). 다른하나는 Predictive(P) frame, 그리고 마지막으로 Bidirectional(B) frame이다. 위 3가지의 프레임은 referencing, 즉 프레임과 프레임사이의 정보 전체가 아니라 픽셀정보의 차이점에 대한 정보만을 저장하는 방식으로 데이터를 압축하는데 이 과정에서 해당프레임의 정보를 가져올수 없어 여러가지 문제가 발생하기도 한다.

- I-Frame: 이미지 전체를 포함하고있으며 최소한의 압축상태로 되어있다. 비디오Seeking을 수행하게 되면 이 I-Frame을 기준으로 찾아가게 된다.
만약 다음 I-Frame이 비어있는경우 seeking의 수행이 느려질수 있다.

- P-Frame: I-Frame혹은 뒤에 따라올 P-Frame간의 데이터정보의 차이에 대한 정보를 저장하고있다. 이러한 프레임과 프레임 사이의 차이점을 referencing이라고 부른다. 즉, 다시말하면 P-Frame은 실제 데이터가 아니라 프레임과 프레임에 존재하는 서로다른 픽셀정보의 차이를 저장하고 있다는 뜻이다. 그러므로 여기에는 충분한 데이터를 지니고 있어야하며 그렇지 않은 경우 I-Frame이 더 많이 필요하게 된다. 이것이 인코딩기술. (모션보정)

- B-Frame: 이것 역시 프레임과 프레임사이의 픽셀차이정보를 담고있다. 다만 이놈은 reference할수 없다. (다른프레임에서 이프레임의 정보를 읽어낼수 없다는 뜻이다. P-Frame은 이것이 가능하다.) 따라서 이녀석은 최소한의 정보를 남겨둔채로 압축을 행한다. x264의 경우 "B-Frame피라미드"를 지원하는데, 이것이 무엇이냐면 B-Frame에서 다음에 올 B-Frame에 대한 정보를 읽어낼수 있지만 그 다음에 올 B-Frame에 대한 정보는 읽을수 없는 방식의 기술이다. 따라서 최소한의 정보만을 담고있다.

자, 그럼 I,P,B프레임에 대한 해설이 끝났으니 이제 실제로 동영상이 어떻게 압축되는지 알아보자.


<3. x264 기본옵션>
- mode

• bitrate single pass:  고정비트레이트로 비디오를 한번만 인코드한다
  
• quantizer single pass: quantizer값으로 비디오를 한번만 인코드한다. 값이 작을수록 화질이 좋아지고 값이 클수록 화질이 나빠진다.
• quality single pass: 주어진 비디오를 quality 백분율값으로 인코드한다. 만약 90으로 준다면 주어진 비디오에서 90%의 퀄리티로 떨어뜨려서 압축한다는 뜻이된다.
• 2 pass: 영상을 두번에 걸쳐서 인코드한다. 첫번째는 영상을 분석해 정보를 세트하고. 두번째는 첫번째에에서 세트한 정보로 실제인코딩을 한다.
• 3 pass: 2 pass와 같지만 추가로 인코드를 더 실행해 퀄리티를 보정해간다. 보통은 1,2,3의 순으로 행한다고 착각하기 쉽지만 그 반대로 1,3,2의 순으로 (물론 1,3,3도 유효. 현재 megui가 사용하는 automate 3pass가 이 오더를 따르고 있다) 두번째에 3이 들어가는데 3이 들어가는곳에 인코드를 한번 더해 1,3,3,2가 되면 4pass, 같은 방법으로 1,3,3,3,2가 되면 5pass 인코딩이 된다. 이러한 횟수는 계속 늘려갈수 있지만 어디까지가 한계인지는 모른다.
  본인이 본것으로는 1200k 로 20pass를 실시해 12000k 급의 퀄리티를 낸 것도 본적이 있다.

원문: http://circle.zoome.jp/nicodou/media/1730
이놈이 바로그것 ㄱ-

- quantizer:
single pass에서만 가능한 것으로 주어진 값으로 인코딩을 하는데 값이 높을수록 화질을 떨어뜨린다. 10까지는 거의 무손실급의 화질을 내는 수준이고 15정도가 울트라초고화질, 16, 17 정도가 초고화질수준, 18, 19 정도가 고화질수준, 20부터 25정도 까지가 웹에서 볼수있는 고화질수준이고 그 이후부터는 중간급이라고 보면 된다. 보통 애니메이션이나 영화의 경우 세밀한 퀄리티와 높은 화질을 추구하지만 값이 작아지면 퀄리티는 올라가지만 용량도 그만큼 올라가기 때문에 값을 올려 용량을 줄이는 대신 생상패치를해 화질을 보정하는 경우가 많다.

- quality:
single pass에서 사용하며 영상을 해당백분율의 퀄리티로 인코딩한다.

- B-Frames:
인코딩에 사용할 B-Frame의 갯수를 지정한다. Adaptive옵션을 선택했을경우 이 수치는 유효한 Maximum값으로 인식한다. B-Frame은 사이즈를 줄이는대신 화질을 보정해주는 역할을 하는데 Adaptive옵션과 함께 사용하면 얼마나 많은 B-Frame을 사용할것인지를 선택하게 된다. 보통 3정도의 값을 권장한다.

- Reference Frames:
reference프레임에 사용할 최대프레임수를 지정한다. reference프레임이란 다음프레임에서 현재프레임의 정보를 읽어내는 것을 말하는데 값이 클수록 화질은 올라가지만 인코딩속도가 느려진다. 일반적으로 3에서 5정도의 값을 사용하며 애니메이션이나 영화의 경우는 8에서 10까지도 사용한다.

- Loop Filter:
보통 deblocking이라고 알려진 필터이다. 알파와 베타세팅을 서로 연결해주는 역할을 한다. 보통 계단현상이라고 영상에 사각형의 큰점이 보인적이 있을것이다. 그 값을 세팅해주는 부분인데 영상이 매우 좋은 깨끗한 화질이라면 0,0 정도를 세팅하면 된다.

- Alpha / Beta:
위의 Loop Filter에서 사용하는 녀석인데 Strengh (Alpha) 와 Threshold (Beta)라고 알려져있다. 알파는 디블록킹의 크기, 베타는 이것을 분석해 보여주는 역할을 한다. 보통은 0,0을 권장하지만 -2 아래나 3 위로 올리지 말라고 권하고 있다.

<4. x264 B-Frame옵션>
- direct mode:
이 옵션은 압축률에 영향을 준다. 기본값은 disable이고 보통 auto를 사용하지만 spatial 을 쓰는 경우도 있다.

- bias:
B-Frame에 얼마나 많은 bias를 사용할 것인지를 세트한다. (값이 클수록 더 B-Frame을 더 많이 쓴다는 뜻이 된다.) 100으로 설정한다고해서 adaptive와 같은 것이 되진 않은다.
기본값은 0이고 B-Frame을 세트한경우 적어도 1밑으로 세트해선 안됀다.

- adaptive:
유효한 B-Frame을 사용한다.. 기본값은 on. 이 값이 작동하려면 적어도 B-Frame이 1 이상 세트되어야 한다.

- pyramid:
피라미드를 사용한다.. 다음 B-Frame에서 이전 B-Frame을 reference할수 있게 한다. 기본값은 on이고 이 값이 작동하려면 B-Frame이 2 이상 세트되어야 한다.

- rdo:
RDO를 on/off한다. on으로 할경우 인코딩속도는 올라가지만 퀄리티는 보장 못한다. 최소한 B-Frame이 1 이상은 있어야만 "Subpixel Motion Estimation"옵션의 6,7 값을 사용할수 있다.

- weighted prediction:
weighted prediction을 사용한다.. 이 옵션은 보다 정밀한 결과를 내주지만 1개이상의 B-Frame이 세트되어야 한다. 기본값은 on

- bidirectional M.E:
bidirectional M.E를 사용한다. 다음 B-Frame에서의 모션을 미리 예측하는데 사용하며 기본값은 on

<5. x264 프레임 옵션>
- scene cut:
이 옵션은 장면이 미리 바뀔것을 예측하고 그곳에 적절한 키프레임을 삽입한다. 장면변화가 심한 영상에서는 이 값을 높게잡으면 된다. 기본값은 40이고 액션영화의 경우 +-5정도 주면 된다.

- cabac:
Context Adaptive Binary Arithmetic Coding를 사용한다. 재생에 직접적인 영향을 주는 부분인데 x264는 하드웨어적인 부분을 많이 가리기 때문에 재생시에 부드럽게 보여주기 위해선 이 값을 사용해야한다. 그렇지 않은경우 제대로 감상이 힘들정도가 된다.

- gop size (min / max):
이 값은 영상내에 얼마나 많은수의 키프레임을 삽입할것인지를 지정한다. min에는 framerate와 같은수치를 지정하면 1초마다 키프레임을 삽입하게 되고 1초단위로 seek를 수행할수가 있게 된다. 다만 이 값이 framerate에 영향을 받으며 값이 클수록 파일용량이 커지게 된다.
이와 비슷하게 max는 적어도 x 프레임마다 키프레임을 지정하게하는 역할을 한다. 키프레임이 없는 영상은 화질이 떨어지게되고 seek도 수행하는데 문제가 생길수 있다.
권장값은 framerate의 10배정도로 하는것이 좋다.

<6. x264 분석옵션>
- mixed references:
Reference Frame의 컨트롤을 보다 효율적으로 하게한다. 특정의 경우엔 Reference Frame을 높게 잡아야 하는 경우도 있다.

- no fase p skip:
fast p skip은 인코딩속도를 올리지만 화질이 그만큼 떨어지게 된다. 화질을 생각하면 off로 해둘것을 권장한다.

- motion estimation method:
빠르고 화려한 움직임을 감지해내는 방법을 세트한다. 어떤코덱이든 마찬가지이지만 여러프레임의 타입, 비트레이트가 할당된 프레임들사이의 차이점을 분석한다.

• diamond -> 가장 속도가 빠름
• hexagon -> 퀄리티가 약간 좋아진다.
• multi hex: 가장 일반적으로 세트하는 타입. 화질과 인코딩속도가 아주 좋다.
  exhausitive: 가장 느림. 세트하지 말것.

- subpixel motion estimation:
partition decision이라고 알려져있다. motion estimation에 있어서 가장 중요한 요소인데 1에서7까지의 옵션이 있다. 물론 1이 가장 빠르지만 화질이 가장 나쁜것이고 7이 제일 느리지만 화질이 가장 좋은놈이다. 보통은 6으로 세트하는데 7로설정하면 아주 쩌는 화질을 낼수있다. rdo b-frame을 사용하려면 이 값이 6이상 세트되어야 한다.

- trellis rd quantization:
이 값을 on으로 하면 화질을 끌어올릴수 있다. 하지만 인코딩속도가 매우 느려진다. 화질은 또한 주관적일수 있다. PC사양이 좋지 않다면 2pass이상의 인코딩에선 off해두길 권장한다.
single pass quantizer모드에선 절대로 on하지 말것. 어떠한 결과를 초래할지 장담할수 없다.

<7. x264 파티션옵션>
- partition:
파티션의 검색타입을 결정한다. 일반적으로 all로 세트하지만 특정경우는 P4*4옵션의 경우는 P8*8을 필요로 하는 경우가 있다.

- 8*8 dct:
이 옵션은 위의 것하고는 다르게 구분하는데, 이놈만 특수하게 command-line 플래그가 다르기 때문. 위에서 I8*8을 선택하였을경우 이 옵션이 필요하다.

<7. x264 입출력옵션>
- show progress indicator:
이 옵션은 재생시에 얼마만큼의 프레임을 재생하였고 남은프레임이 얼마인지 보여주게 한다. on으로 하는것이 좋고 원하지 않으면 꺼도 상관없다.

- disable psnr computation:
이 옵션은 noise redution 계산을 쓰지 못하게한다. 그냥 on으로 놔두길 권장한다.

- threads:
인코딩에 얼마나 많은 CPU thread를 사용할지 결정한다. 하이퍼스레딩이 되는 인텔 펜티엄 프로세서의 경우는 2. 듀얼코어의 경우도 2. 하이퍼스레딩이 되는 듀얼코어는 4로 설정한다.

- output type:
출력파일의 이름이다. 확장자를 .264로 둘경우 RAW데이터를 의미한다.

나 군대에서 휴가나오면 언제나 집에서 컴퓨터, 먹고, 자고, 싸고, 컴퓨터... 의 반복이었던 기억이 난다.
항상 휴가나오면 무엇무엇 해야지 하고 다짐했건만 언제나 같은 패턴의 반복이었다.
덕분에 복귀날짜되면 언제나 이것저것 잔뜩 후회만 남기고 다시 지옥같은 고참이 있는
마치 도살장 끌려가듯이 들어가곤 했다.

지금와서 생각하보면 정말 후회가 많이 남는 일이었다.
부대있을때 그렇게 컴퓨터가 하고싶었거든 ㄱ-

아무튼 그냥 생각나서 ㄱ-

감동의 원피스를 보지않은자, 애니를 논할 자격이 없다.

전에 회사에서 일하던 직장동료가 남긴 말이다.
나와 같은 고등학교 출신에, 매주 즐겨보던 애니메이션도 똑같았다.
원피스

벌써 9년째 방영중인 일본의 애니메이션인데
한꺼번에 몰아서 보다가 요즘들어서는 매주 챙겨보고있다.
아니 그 이전에도 몇번 매주 챙겨봤는데 그때마다 놓쳐서 ㄱ-

아무튼 원피스를 다시보니까 역시 감동의 장면들을 잊을수 없다.

원피스에서 가장 감동적이었던 장면이다.
바로 쵸파가 바다로 나온 그 장면.
아직도 이장면은 잊혀지질 않는다.
아마 최초감상시엔 눈물이 나왔었지...
얼마전에 개봉한 극장판에서도 이장면에서 역시 또 눈물이 나올라고 한다.

최근의 감동적이었던 장면.
두번째로 감동적이었다고하면 역시 애니에스로비 탈출했을때다.
마지막동료의 합류순간...

근데 역시 몰아서보는건 좋지 않은거 같다.
매주올라오는 릴중 같은종류의 릴과 같은종류의 자막을 모아두는게 좋은데 매번 뒤죽박죽에 화질도 들쑥날쑥하니 원 ㄱ-

요 얼마간 포스팅이 없었던것 같다.
하긴 베스페리아 하느라 정신이 없었고
최근 보름간은 인피닛 언디스커버리 기다리느라 뻘짓을 좀 했었는데
루리웹 동영상게시판에서 하던 스타오션3DC 23주FD 연재도 어느덧 1부의 막을 내렸고
잠시의 휴식기를 가진뒤 시련의 동굴편을 계속 이어서 할 생각이다.
사실 플레이는 이미 한달도 훨씬 전에 2부까지 마쳐두었지만 -_-;
다음은 스피어211편인데 이것은 그냥 플레이보다는 이번 플레이의 핵심이기도 해서 잠시 휴식하고 다른게임하면서 시간을 보낸뒤 다시 하고싶을때 파고들 생각이다.

요 보름간 베스페리아를 쉬고 하던게 바로 이게임

슈팅은 1년도 훨씬전에 끊었는데 마침 이게임이 새로 나왔다길래 해봤다.
역시 슈팅은 나하곤 맞지 않는것 같다.
패턴화는 커녕 피하는것도 못하겠다.
역시 슈팅을 끊길 잘했다는 생각이 든다.

http://starocean.co.kr/thscore/

얼마전에 만든 동방슈팅의 스코어보드인데
마침 오픈소스가 있어서 한글화를 거쳐서 만들었다.
CGI를 몰라서 한 이틀 삽질해서 설치하고 한 이틀 투자해서 한글화를 거쳐 완성.

그런데 슈팅을 놓은사이 이렇게 요즘슈팅이 어려워졌던가?
스코어보드에 올라온 리플레이를 보니까 아주 미친듯이 퍼붓더라 ㄱ-
동방슈팅이 쉽네 어쩌네 하는 예기가 요 몇년간 화자가 되었었는데 작자인 ZUN상이 아주 작정하고 미친듯이 난이도를 올린듯하다.
그런데 이것도 쉽다고 한다고 하니 다음엔 더 어렵게 나올것 같다.

맨위의 그림... 아는 모 지인에게 주니까 심히 찔리신다던 ㄱ-

 에스텔의 버스트아츠 엑스트림스타의 변형기 냥냥과
리타의 변형주문 골드컷을 적절히 조합.
중대형급 이상만 됩니다.

구석에 몰고가서 저렇게 위치를 잘만 잡아주면 무한 ㄱ-
적당히 끊었지만서도....

http://www.nicovideo.jp/watch/sm4497234

일본에서도 반응이 뜨겁습니다?

이것을 마지막으로 베스페리아는 당분간 휴겜
이제 인피닛 언디스커버리를 하고 하다만 스타오션3DC도 하고 곧 내년 봄에 나올 스타오션4도 해야하고...

실전용으로 그동안 주력으로 사용한 리타, 에스텔, 유리의 콤보를 모아봤다.
퍼포용은 아니고 리타의 경우는 내가 주력으로 썼던 캐릭터이고
정술콤보 몇개 만들어봤다.
퍼포용으로 짠다면 더 넣을수도 있는데 실전용을 좋아하는지라 관뒀다.

2회차 특전을 이용했음.

캡쳐보드를 쓴지도 벌써 꽤 된거 같다.
블로그 방문기록을 살펴봐도 1위는 항상 부동의 몬스터X.
이참에 한번 몬스터X를 사용한 인코딩 노하우를 한번 포스팅해볼까 한다.

먼저 하드웨어는 당연히 준비되어야한다.
이쪽은 네이버 캡쳐보드카페에 가면 자세한 정보를 얻을수 있으니 그쪽을 가보고
여기서는 그것을 이용한 캡쳐, 인코딩, UCC업로드까지 다뤄보려 한다.

일단 캡쳐는 MXCapture를 사용해 캡쳐한다.
이 프로그램 사용법, 세팅법도 전부 네이버 캡쳐보드카페에 다 있다.
거길 참고하고

캡쳐를 하기전에 먼저 사전지식이 필요하다.

1. PV4와의 성능비교
아는 지인중에 PV4를 써본분이 계시는데 PV4와 Monster-X의 성능차이는 없다고 한다.
차이라면 색감이 PV4쪽이 더좋다는 것인데, 색보정으로 이부분은 충분히 커버가 가능하다.

2. interlace, progressive의 차이
interlace는 가로줄이 생기는 방식이다. 수신카드도 전부 이방식으로 소스를 입력받는다.
이건 화면에 이미지를 두번 나누어서 교대로 보여주는 방식인데 그래서 가로줄이 생긴다.
컴포넌트소스라도 interlace 방식으로 소스를 출력하면 역시 가로줄이 나온다.
progressive는 가로줄이 없는 방식이다. 컴포넌트, HDMI방식도 이방식 소스를 입력받는다.
흔히 고화질, HD급영상 소스라고도 불린다.

아무리 캡쳐보드를 사용하더라도 출력하는 소스가 interlace 방식이면 역시 가로줄이 나온다


사전지식은 이정도면 되고 이제 캡쳐를 하는데
PS2 게임 소프트는 기본적으로 언급이 없는이상 전부 interlace 방식, 즉 480i 방식으로 출력된다. 다시말해 특별히 프로그레시브방식으로 게임을 전환하지 않는이상 무조건 가로줄이 생긴다는 의미이다.
XBOX360의 경우는 아예 콘솔자체에서 출력사양을 설정할수 있어서 480p에서 1080p 까지 자유로이 사양을 조절할수 있는데 아쉽게도 몬스터X는 1080p는 지원하지 않는다. 캡쳐할땐 720p로 설정하도록...

XBOX360의 경우는 돌비 디지털 5.1ch로 출력이 가능한데
물론 5.1채널도 캡쳐가 된다. 광출력 (SPDIF)로 출력해 사용하면 되는데
문제는 디코더가 없기 때문에 소리가 깨져서 나온다.
이것은 지극히 정상이므로 신경쓰지 말도록.
역시 5.1채널 캡쳐법도 네이버 캡쳐보드 카페에 전부 나와있다. 비트스트림 캡쳐로 찾아보도록...

캡쳐를 했으면 아마 Huffyuv 영상에 무압축 음성에 AVI Muxer로 되어있을건데
음성이 5.1채널 비트스트림이라면 Virtual Dub을 통해 wav로 음성을 뽑아내 디코딩을 거쳐 제대로 소리가 나오도록 변환해 주어야 한다.

먼저 megui로 인코딩을 하는데, 특별히 만져줄건 없고
소스자체가 워낙에 품질이 좋기 때문에 대강 3000 ~ 4000k 영상으로 주어도 충분하다.
애니메이션 립퍼들중 mp4 x264로 배포하는 친구들은 2500k 로 립을 뜬다.
이 친구들은 megui 보다 더 막강한 커맨드방식의 인코더를 쓰긴 하지만 우린 그럴필요까진 없다. 커맨드방식이 더 옵션이 다양하고 많지만 어렵다. 여기선 걍 패스...

영상은 그렇게 만들고 음성의 경우는 5.1채널 변환을 거친 경우는 이 소스를 사용하고 걍 스테레오라면 기존방식대로 avs를 입력해주면 된다.

인코딩은 이렇게 마스터버젼을 완성했다.
그러나 UCC에선 좀더 낮은 사양의 flv로 변환해주어야 하는데
나는 커멘드라인 방식의 flv 인코더를 사용한다.
왜냐면 편하게 60프레임 영상까지 flv로 변환이 되니까다.
복잡한 절차 전부 필요없고 간단하게 드래그앤드롭으로 해결된다.
인코딩한 마스터버젼의 mp4를 드래그해 쓰면된다.
FLV4enc_D&D.bat 라는 파일이 있을건데 여기에 드래그앤드롭하면 된다.
사이즈를 조금 수정한 다른 비슷한 파일들도 보일것이다.




VFW의 On2 VP6 인코더가 설치되어있어야한다. (당연)
아마 통합코덱팩이면 설치되어있을 것이다.




화면 하단에 보이는 번짐같은 부분은 화면사이즈와 관계가 있는데
원본쪽, 출력쪽 어느쪽에도 영향을 미친다.
해결법은 정규사이즈로 하는것.

그렇게 flv 나온것을 UCC에 올리면 된다.

0'05''750

테일즈 오브 베스페리아 30인참 타임어택을 무려 5초대로 진입시키신
테일즈王 Nore139님.
그 칭호가 당연하다는듯이 2위와 차이가 무려 거의 1초차이 ㄱ-;
마의 5초의 벽을 넘다니... 사람이야?


역시 Nore139님 영상.
테일즈 오브 데스티니 DC판인거 같은데
무려 바르바토스의 심플난이도를 노데미지로 깨다니(...)
이게 정말 가능하긴 한가? 하고 어이없어했는데 하다니 ㄱ-;

아놔 이사람 대체 정체가 뭐야....