델파이로 DirectShow 프로그래밍하기(1) - 서론

예전부터 한번은 DirectShow 강좌를 하고자 마음먹었습니다. 그러다가 이렇게 설을 앞두고서 일감이 없어서(간단하게 놀고 있어서 시간이 남아 돌기 때문에) 강좌를 하게 되었습니다.

욕심 같아서는 필터만들기까지 하고싶지만, 시간이 어떻게 될지는 모르겠습니다. 그러나 우선 강좌를 시작하기에 앞서서 DirectShow 프로그래밍을 가지고 어떠한 것들을 할수 있는가, 또한 DirectShow가 왜 꼭 필요한가에 대한 궁금증과 의문점을 하나하나 살펴보도록 하겠습니다.

 
[1] 시작하기에 앞서서 알아야할 백그라운드 필수 개념

저는 델파이 프로그래밍 1년차가 끝나기도 전에 DirectShow프로그래밍을 하게 되었습니다. 그때 제가 무슨 정신으로 할 수 있다라고 오버액션을 취했는지 알다가도 모를일이었습니다. 그당시 저에게는 COM은 두말할 것도 없고, 그보다 더 기초적인 OOP에 대한 개념조차도 머릿속에 들어가 있지 않았기 때문입니다.

그냥 c언어를 남들보다 조금 잘하니까 부딪혀보면 해답이 나오겠지하고 시작하였고요, 장님 코끼리 뒷다리 만지는 식으로 더듬더듬 더듬어나갔습니다.

그러나 만일 여러분이 DirectShow를 시작하고자 한다면 저처럼 이렇게 오랜 길을 장님처럼 주물럭거리며 느려터지게 발전해 나가지 않았으면 합니다. 오히려 OOP에 대한 이해를 먼저하고, 그 다음에 COM에 대한 이해를 하고서 시작한다면 더 빠르게 목적하고자하는 목표에 다다를 수가 있을 것이라고 감히 충고합니다.

OOP와 COM의 이해는 1년 정도의 완숙도를 가질 필요가 있다고 봅니다. 즉, 사전적인 이해가 아니라 실무에서의 한 두 프로젝트의 경험에 의한 '감'이 있고나서 시작하면 좋겠다고 생각합니다.
책을 통해서 익히는데는 풀타임으로 약 2달 정도면 가능하겠지만, 이것만 가지고는 턱도 없이 부족할 것이기 때문에 OOP와 COM에 눈을 뜨고서 한 1년 정도의 필드 경험을 익힌 다음에 시작하는 것이 좋지 않을까 하는 것입니다.

왜냐하면 저의 경우에 어느날 갑자기 DirectShow필터의 소스가 한눈에 확 들어온 적이 있었는데, 그토록 갈망했던 그 구조가 그렇게 쉽게 머릿속에 다가오자 오히려 맥이 빠질 정도였습니다.
그러나 뒤돌아 생각해보면 다 그럴만한 이유가 있었고, 저처럼 OOP와 COM의 전반적인 이해가 없이 무턱대고 대양에 빠져서 허우적대는 식으로 갈팡질팡하는 것 보다는 오히려더 실무 경력 1년 정도의 시간을 두고나서 시작하는 것이 훨씬 더 효과적이라는 생각이 들기 때문입니다.
마치 구구단을 완전히 암기하지 못한 사람이 미적분을 공부하는 것과 같은 것이라고 할까요...

물론 이것은 궁극적인 목표가 Filter개발이라는 점을 염두에 두고 한 말입니다. 만일 여러분이 일반적이고 간단한 동영상 플레이어를 조작하는 어플에 만족한다면 그보다 훨씬 저렴한 노력으로 DirectShow를 익힐 수도 있을 것이라고 격려해주고 싶습니다.
그러나 분명한 것은 DirectShow는 필터를 개발하지 못하면 그 성능을 절반도 제대로 사용할 수 없다라는 점입니다. 그러므로 최종목표는 항상 필터개발이라는 사실을 명심하도록 하세요.

[2] DirectShow의 특징. 버퍼공유

DirectShow의 특징이라면 한두개가 아닐 것이다. COM으로 이뤄진 것이라는 것, 내부적으로 DirectDraw를 사용했다는 것, 등등... 그러나 가장 중요한 것은 DirectShow의 구조적인 특성일 것이고, 거기서 가장 중요한 점이 바로 버퍼를 공유한다는 점이다. 이 사실에 밑줄을 쫙 거주길 바랍니다.

사실 윈도우에서 동영상을 제어하는 방법이 꼭 DirectShow만 있는 것은 아닙니다. 예전의 API를 사용해서 어플을 만들었던 VFW(Video for Window)라는 방식도 있지요.
즉, DirectShow와 VFW는 윈도우즈 운영체제에서 동영상을 제어하는 어플을 만드는 두개의 유일한 방식이라고 할수가 있습니다. 좀더 엄밀하게 말하면 VFW가 먼저 나왔고 그 다음으로는 마이크로 소프트사가 하는 방식이 원래 그렇듯이 DirectShow가 VFW를 흡수통합하는 형식으로 나왔다는 점입니다.

그렇다면 어째서 마이크로소프트(이하 마소)는 DirectShow를 별도로 제시하여야 했을까요. DirectShow(이하 DShow)는 DirectX의 일 부분으로서 SDK에 포함되어 있습니다.
즉 초기의 DirectX에는 DirectShow가 포함되어 있질 않았다는 것이죠. 마소는 절대적으로 DShow가 필요했고, 그러한 필요성을 절실히 느낄 수 밖에 없었을 터입니다. 그 이유가 바로 버퍼공유라는 단하나의 이유 때문이라도 말이죠.

우리가 동영상을 로딩하면 일반적으로 카메라에서 BT878류의 화면캡쳐보드나 혹은 USB를 통해서 어디론가 연속적인 이미지가 쌓일 수밖에 없습니다.
일단 USB 종류의 설명은 제외하기로 하지요. 왜냐하면 제가 USB 드라이버를 다뤄본적이 없기 때문에 여기서는 일단 BT878이라는 화상 캡쳐보드 혹은 일반적으로 TV수신카드)를 예로 설명하겠습니다.
(사실 직접 디바이스 드라이버를 제작한적은 없습니다. 그러나 드라이버 제작자와 함께 작업을 하면서 상당히 많은 사실을 접할 수가 있었습니다.)

카메라는 일반적으로 감시용카메라(아날로그)가 되겠습니다. 이것을 BT878카드에 꼽아서 DShow 어플을 제작하는 것인데요, 주로 산업현장이나 주정차 시스템같은 곳에 많이 연계되어 사용하고 있습니다.
USB 카메라를 이용하는 화상통신 프로그램도 완전히 동일한 DShow 응용 어플이라고 할수 있겠습니다. 왜냐하면 WDM 디바이스 드라이버라면 그 위에서 작동하는 DShow는 아무튼 동일한 것이기 때문이죠. 어쨌든 좀더 복잡한 예로 BT878을 예로 들어 보겠습니다.

감시용 카메라는 아날로그 신호를 만듭니다. 이것을 BT878보드에 보내게 되고요, 이 보드에서 아날로그 신호를 디지털화 작업을 하게 됩니다. 그리고 이 디지털 데이터가 윈도우의 첫번째 버퍼링 대상이 되는데요, 윈도우는 이 데이터를 가장 신속하게 다뤄질 수가 있는 시스템 메모리에 적재합니다. 엄밀히 말하면 윈도우가 그렇게 하는 것이 아니라 WDM 디바이스 드라이버가 그렇게 한다고 볼수가 있겠죠.
아무튼... 이 시스템 메모리는 일반적인 응용 어플에서 엑세스 할수가 있는 곳이 아니고, 또한 그 때문에 굉장히 빠르고 안전한 우선권이 있다는 점만 말해주고 싶습니다. 따라서 어플에서 이 데이터를 사용하기 위해서는 다시 일반적인 메모리에 복사(버퍼링)하는 작업이 필요하고요, 이것이 다시 그래픽카드의 메모리로 전송되게 됩니다.

이것을 다시 간단히 말하면...
BT878에서 만들어진 디지탈 그래픽 데이터는 WDM 드라이버에 의하여 윈도우의 시스템 메모리에 한번의 버퍼링이 되어지고, 여기서 다시 일반 어플이 사용하는 메모리에 복사(버퍼링)이 되며 또다시 이것이 그래픽카드의 메모리로 보내지게 된다는 점입니다.
이때 그래픽카드로 전송하는 방식은 AGP 몇배속인가 하는 방식으로 보내지기 때문에 속도가 엄청나게 빠르다는 사실을 참고하시면 되겠습니다. 그래픽카드를 꽃는 슬롯을 눈여겨 보시면 다른 슬롯보다 조금 다른 형태임을 보실수가 있을 것입니다. 이것을 AGP라고 합니다. PCI방식보다 훨씬 빠르다고 하죠.

결론적으로 말씀을 드리면 이렇듯 간단한 동영상 어플을 만드는데에도 영상의 버퍼링이 두번이상이나 필요하게 됩니다. 만일 어플에서 영상을 가공처리한다면 또다시 몇번의 버퍼링이 필요한 터이겠죠. 이 버퍼링이 얼마나 어마어마한 것인가를 먼저 느끼셔야 합니다. 그렇지 않다면 DShow는 아무짝에도 소용이 없습니다. 동영상의 버퍼링은 정말로 무시무시한 괴물 같은 것입니다. 특히 영상의 크기가 배가 될수록 버퍼링의 크기는 그것의 제곱비례하게 됩니다.

이 말이 무슨 말인가 하면... 640*480의 동영상을 받아서 처리한다고 해보죠. 초당 30프레임이고요, RGB24를 기본으로 사용한다고 생각해봅신다.(일반적으로는 YUV지만 생각의 편리를 위해서). 1프레임에 약 1M의 메모리가 필요하다고 한다면(640*480*3 Byte이므로 거의 1M라고 하자),  1초에 약 30M의 데이타가 전송되어야 합니다. 만일 버퍼링이 응용어플에서 3회에 걸쳐 이뤄졌다고 해봅시다. 그렇다면 컴퓨터는 내부적으로 초당 약 90M의 버퍼링을 처리해야 할 것입니다. 이것은 어마어마한 양의 데이터입니다. 아마도 CPU점유율이 그리 낮지는 않으리라고 봅니다.

만일 우리가 동영상 프로그램을 개발하면서 버퍼공유를 하지 못한다면, 우리는 계속적으로 버퍼링을 해야만 할 것이고 이것은 곧 엄청난 시스템 자원을 필요로하게 됨을 의미합니다.
마소가 굳이 DShow의 서비스를 제공할 수 밖에 없는 이유가 되는 것입니다.

여러분이 간단한 동영상을 편집해 보았다면 이 위력이 얼마나 큰 것인지를 실감하실 수가 있을 것입니다. 동영상의 데이터는 일반 어플의 데이터와는 상상할 수도 없을만큼 비대합니다. 따라서 버퍼링이 곧 죽음이고, 그만큼 마소에서는 버퍼공유가 절실히 필요했다고 할수가 있을 터입니다.

이즈음에서 저의 경험담을 이야기해보겠습니다.
저는 몇년전에 동영상 합성시스템을 개발한적이 있었습니다.
그당시 컴퓨터 사양이 CPU 1.7 ~ 2.5G 정도였습니다. 640*480영상을 백그라운드와 자신의 모습, 그리고 앞에서 움직이는 이펙트영상, 이렇게 세가지를 동시에 크로마 합성하고자 하였으나 결국은 실패하였습니다.
왜냐하면 그당시 컴퓨터 사양으로는 절대무리였다는 사실을 깨닭기까지 저의 기초지식은 너무나 터무니 없었기 때문입니다.

우리는 동영상을 생각할때 버퍼링과 함께 또다른 괴물도 마주하고 있음을 깨닭아야 합니다. 그것은 바로 압축이라는 메두사입니다. 그 알고리즘만 봐도 돌이 되어 버린다는 괴물이죠. 결국 그당시 저는 480*480의 형태로 세가지 영상을 실시간 합성해내는데까지 성공하였습니다. 그러나 아직도 640*480의 3가지영상을 실시간 합성 해내는 것은 쉬운일이 아닙니다.  
왜냐하면 컴퓨터가 1초당 내부적으로 버퍼링할 수 있는 크기는 제한적이기 때문입니다. 아직까지 우리의 PC는 1초당 수G바이트씩 버퍼링을 하지 못합니다. 이것은 CPU의 속도와는 다른 마더보드의 속도와 관련이 있습니다.

아무튼 가장 중요한 것은 DShow의 가장큰 특징이자 존재이유가 바로 버퍼공유라는 것이며, 이것은 동영상의 어플을 제작할때 성능차원에서 기본적으로 다뤄져야할 매우 중요한 요소중의 하나라는 점입니다.

[3]동영상 프로그래밍을 할때 주의할 점.

이 사항을 기고해야 하는지, 아니면 나만의 아픈 기억으로 담고 있어야 하는지 모르겠습니다. 그러나 만일 나와 비슷한 경험을 하는 분이 있다면 조금 유의하라는 점에서 드리고 싶은 말씀이 몇가지 있습니다.

일단 동영상 프로그래밍은 상당히 재미가 있지만, 경제적인 측면에서는 상당히 그렇지 않다는 점을 알려 드리고 싶습니다. 그 이유는 몇가지가 있겠으나 일단 우리나라의 속물적인 소프트웨어 개발현실에서 깊은 알고리즘에 대한 이해를 요하는 연구스타일의 코딩은 설 자리가 없기 때문입니다.
이게 무슨 말인가 하면, 동영상은 상당히 고급 프로그래밍 기법에 속합니다. 필터제작은 기본이고 사실 Mpeg압축 알고리즘까지는 들어가야 제대로된 사업용 어플을 생산해 낼 수가 있다고 봅니다.
그러나 우리나라의 개발 현실은 그렇지 않습니다. 무조건 뚝딱 만들어 내라고 강요하고, 그러다보니 제대로된 소프트웨어가 개발될 리가 없습니다. 여기까지는 아마도 이해가 쉬우리가 봅니다. 왜냐하면 이정도는 일반적인 우리나라 개발현실이기 때문입니다. 그러나 슬프게도 동영상쪽은 여기서 한발 더 들어가 악조건에 파묻혀야 합니다.

동영상에 대한 아이템을 가지고 개발을 의뢰하는 사람들은 대부분 어떤 환상에 사로잡혀 있습니다. 시스템이 뒷바침되어 있질 않음에도 불구하고, 실상은 몇백만원짜리 그래픽편집카드가 필요한 시스템 구성을 단순하게 응용 어플로 개발해달라는 식입니다. 이들은 대부분 한탕 크게 해보자는 식이고, 히트해서 떼돈을 벌 것이라는 몽상에 사로잡혀  있는 경우가 대부분입니다. 

먼저 이들을 조심해서 피해나가야 할 것입니다. (이들은 결과물이 만족하지 않을 경우에는 개발비를 지급하지 않는 경향이 있다. 턴키가 아니더라도 직원으로서 개발한다고 하더라도 급여가 제대로 나오기가 힘들다.
왜냐하면 이들이 생각하는 개발기간과 실제 개발기간이 너무 차이가 나기 때문에 어느정도 급여가 나오다가 중간에 조금만 더, 조금만 더 하는 식으로 버티는 꼴이 되기 쉽기 때문이다. 이 즈음에는 이미 준비해뒀던 실탄이 바닥나 있을 터이다.)

두번째로 조심해야 할 것은 어두운 쪽의 그룹들이다. 이들은 주로 야시시한 것들, 음난한 것들 이거나 혹은 조폭들과 연계된 체인점 사업 아이템 등등이다. 이들과 거래를 하거나 이러한 회사에 입사할 때에는 조심하는 것이 좋다. 왜냐하면 어떠한 약점을 잡아서 회사에 목메 달려고 할지 모르기 때문이다. 사내 도청을 조심해야 하고, 특히 계약관계에서 계약서를 면밀히 살펴봐야 한다. 잘못 코끼면 일여년동안 거의 노예처럼 노동을 강요당하기 쉽다.

동영상계열의 프로그래밍은 우리나라에서는 참으로 지저분한 분야가 되어버렸다. 그 이유는 일단 개발회사들이 영세하고, 두번째로 프로그래밍에 대한 이해부족으로 SI처럼 생각하기 때문이다. 당장 눈앞에서 삐가번쩍하게 돌아가야 고개를 끄덕여주는 클라이언트에게 알고리즘개발이란 엄두도 낼수가 없는 거창함일 뿐이다.

따라서 나는 동영상 프로그래밍을 그리 추천하지는 않는다. 이제껏 동영상 프로그래밍을 하면서 받아야 할 인건비의 사분의 일도 제대로 받을 수가 없었기 때문이다. 그러나 내가 이렇게 여기에 강좌를 하는 것은 동영상 프로그래밍이 전문적인 영상합성이나 편집분야가 아니더라도 얼마든지 작은 부분으로서 유익하게 다뤄져야할 필요성이 있을 터이기 때문이다. 

다이렉트쇼의 서론은 이쯤에서 접는 편이 나을것 같습니다. 그러나 강좌를 진행하다가 계속해서 서론부분에 해주고 싶은 말이 있을 때에는 추가하는 방식으로 진행해 나가겠습니다. 

 

출처 : 델마당  dong님의 글(dongsoft)