오늘자로 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

'개발 > FLEX' 카테고리의 다른 글

WebFLV3 개발일지 20081015: 니코동화 흐르는메세지 분석  (0) 2008.10.15
Posted by MOBIUS!
,

작년(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프레임이라는 것을 감안하면 상당한 부하가 예상되는것이었다.
현재 이부분에 대한 고민이 필요할것 같다.
시간의 흐름에 따른 제한된 갯수의 메세지를 화면에 렌더링하는 것 말이다...

'개발 > FLEX' 카테고리의 다른 글

WebFLV3 개발일지 20081016: WebFLV3 v3.1 버젼업  (0) 2008.10.16
Posted by MOBIUS!
,