1997년 실시간 온라인 바둑 강의 시스템을 만들고 난 뒤부터 줄 곳 PC 화면을 실시간으로 송출하는 알고리즘을 만들어 왔습니다. 물론 업무에 시달리면서 틈틈이 해왔기 때문에 대부분의 시간은 집중하지 못하였지만, 근래 4년 동안은 상당히 많은 시간을 이 분야에만 매달려 왔습니다.
일단 PC 화면을 압축하는 방법 중에는 H264와 같이 이미 검증 된 솔루션을 사용해도 무방합니다. 하지만, 이는 압축하는 데 CPU 성능을 상당히 요구하며, 해상도가 큰 화면에서는 버겁습니다. (제 고객 중에는 1680x1050 해상도로 강의하시는 분도 계심)
또한 영화와 같이 변화와 컬러의 분포가 고른 동영상의 경우라면 몰라도, PC 화면처럼 변화가 대부분 극소적이 영역에서 그치고 컬러의 분포가 고르지 않는 경우에는 일반적인 방법보다는 제가 만든 압축 방법이 휠씬 압축률이 높습니다. (몇 개월 전, 1024x768 크기를 화질의 열화 없이 1시간 동안 녹화한 온라인 강의 자료가 40MB 도 안되었습니다)
압축률보다 더 문제가 되는 것이 있습니다. 많은 사람에게 실시간으로 전송해야 하는 문제입니다. 이 때문에 더 많은 시간을 보내게 되었는데, 이 와중에 제 최신 압축 라이브러리를 구매하신 어떤 고객은 경쟁사의 제품보다 내 솔루션의 압축률이 휠씬 못하다고 불평한 적도 있었습니다. 알고보니 그 분의 경쟁사 제품이 제 예전 솔루션이더군요. (압축률은 높지만 실시간으로 다수의 사용자에게 전송하는데 단점이 있는 알고리즘)
현재도 압축률을 좀 더 끌어 올릴 수 있는 방법들이 있습니다. 이미 테스트도 완료한 것들입니다. 하지만, 실제 서비스에는 적용 못하고 있습니다.
가장 문제가 되는 부분이 "바로 실시간으로 다수의 사용자에게 동시에 전달"이라는 부분입니다.
지금 제가 사용 서비스하는 하마티(http://www.himytv.com/)에서는 강사가 보낸 데이터를 서버에서 모든 수강자의 상태에 따라 화면을 각각 재구성하는 방법을 사용합니다. 이부분에서 서버의 CPU 사용을 낮추고, 최대한 화면 전송을 부드럽게 진행하기 위해서 그 동안 수 많은 시행착오를 거치게 되었습니다.
오늘은 그 중에 까다로운 기술 하나를 적용하고 밤새 테스트 장비에서 테스트를 마무리하였습니다. 이제 반드시 적용하고 싶은 기술은 하나가 남았네요. (이 부분이 아까 언급한 고객의 경쟁사가 사용하는 예전 압축 알고리즘, 이제 최근 알고리즘과 병행하여 사용 중)
되돌아보면 그 동안 정성을 들였던 시간에 비한다면, 참으로 간단하고 초라한 기술을 얻어낸 것 같습니다.
그리고,
깨달은 것이 있다면,
"얼마나 열심히 하는 가"보다 "얼마나 현명하게 일했는 지"가 더욱 중요하다는 것 입니다.
재귀 호출 (2) | 2013.12.17 |
---|---|
클래스 상속과 인터페이스 구현의 차이 #2 (6) | 2013.12.12 |
HiMyTV 방송 서버 구조 #2 - DB에 대한 비동기 처리 (0) | 2013.07.22 |
HiMyTV Player 만들기 #3 - Core Module에 대한 이해 계속 (0) | 2013.07.13 |
HiMyTV Player 만들기 #2 - Core Module에 대한 이해 (0) | 2013.07.13 |