델파이로 DirectShow 프로그래밍하기(6) - 어플(2)

우리는 전편에서 COM의 인터페이스에 대하여 알아보았습니다. 그러나 아직까지도 인터페이스에 대하여 감이 잘 오질 않으실 것입니다. 그렇지만 조금은 참고, 중요한 몇가지에 대하여 정리해 보겠습니다.

  1) COM 오브젝트를 생성하기 위해서는 CoCreateInstance라는 함수를 사용하는데 이 함수에는 세가지의 매개변수를 지정한다. 하나는 COM 오브젝트를 식별하기 위한 GUID인 CLSID 이며, 또다른 하나는 IID_로 시작하는 인터페이스 식별자이고, 나머지는 리턴되어 받아낼 실제 인터페이스형 타입의 변수이다. 

  2) CoCreateInstance 함수를 사용하여 COM 오브젝트를 생성하면서 우리는 첫번째 인터페이스를 뽑아낸다.

  3) 하나의 인터페이스가 또다른 인터페이스를 QueryInteface를 사용하여 국수 뽑듯이 뽑아낼 수가 있다.  

  4) 인터페이스를 뽑아내기 위해서는 반드시 두가지의 매개변수가 필요한데, 하나는 IID_로 시작되는 식별자이며 또다른 하나는 리턴되어 받아낼 실제 인터페이스형 타입의 변수다. (일반적으로 I로 시작되는...)  그런데 식별자와 인터페이스 타입의 변수에 사용된 GUID는 동일한 값이거나 혹은 상속관계에 있는 값이어야 한다. 여기까지...

 
[1]필터그래프의 인터페이스.

필터그래프 매니저 COM 오브젝트(이하 필터그래프) 에는 수많은 인터페이스가 존재합니다. 헬프파일을 찾아보시면 25개 정도의 인터페이스를 발견하실수가 있을 것입니다. 이 중에서 우리는 3가지의 인터페이스만을 사용할 것입니다.
만일 여러분이 나중에 좀더 복잡한 DShow 어플을 개발하고자 할때에, 이렇게 수많은 인터페이스 중에서 필요한 것을 골라서 선택하여 사용하시면 될 것입니다. 그러나 현재로는 3가지 아주 핵심적인 인터페이스만을 생각해보기로 하죠.

첫째로 DShow 어플에서 생성되어진 수많은 필터들을 연결해주거나 끊어 주거나 해야 합니다. GraphEdit에서 여러분은 직접 필터들을 마우스로 드래그하여 화살표를 꽁지에서 꽁지로 연결해 주었을 것입니다. 이러한 연결을 해주는 서비스 인터페이스가 필요합니다. 이 인터페이스가 바로 IFilterGraph라는 놈인데요, 우리는 여기서 상속받아서 기능이 좀더 많은 IGraphBuilder라는 인터페이스를 첫시발로 CoCreateInstance을 사용해 필터그래프 생성과 동시에 뽑아내었죠. 자, IGraphBuilder라는 인터페이스가 필요한 이유는? 필터들을 연결해 주기 위해서라고 일단 간단히 생각합시다.

두번째로 필요한 것은 필터를 연결한다음에 이것들을 실행시켜줄 인터페이스가 있어야 합니다. 즉,  Run하고, Stop하고, Pause하는 기능을 가진(이것을 다른말로 스트림을 제어하는) 인터페이스가 필요합니다. 이것을 IMediaControl 이라고 합니다. 이 인터페이스는 필수입니다. 이게 없으면 필터들 연결만 하고 끝이겠죠. 동영상이 Play되지 못한다는 말이죠.

세번째의 인터페이스는 사실 없어도 되는 것이지만, 좀더 세련된 DShow 어플을 만들기 위해서는 필수입니다. 일단 IMediaControl를 사용하여 DShow를 작동시켜 동영상을  Play시키면 디폴트로 별도의 랜더링 윈도우가 뜨면서 실행되는데요, 이게 영 볼품이 없습니다. 자신이 만든 어플의 메인 폼위에서 실행되었으면 하는데요, 이렇게 영상이 랜더링 되는 위치를 설정할 수 있게 해주는 인터페이스가 바로 IVideoWIndow라는 인터페이스입니다. 이 세가지는 거의 필수라고 보시면 되겠습니다.

자, 이제 이 나머지 인터페이스를 어떻게 뽑아낼까요? 우리는 처음에 필터그래프에서 IGraphBuilder라는 인터페이스를 FilterGraph라는 변수에 받아내었습니다. 요놈을 가지고 나머지 인터페이스를 뽑아내어 봅시다. 
일단 변수선언을 다음과 같이 합니다. 

    MediaControl: IMediaControl;
    VideoWindow: IVideoWindow;

그리고 다음과 같이 QueryInterface를 사용합니다.

  FilterGraph.QueryInterface(IID_IMediaControl, MediaControl);
  FilterGraph.QueryInterface(IID_IVideoWindow, VideoWindow);

자 이렇게 나머지 두개의 인터페이스를 얻을 수가 있었습니다. 그렇다면 여기까지 한가지 의문이 들 것입니다. 우리가 필터그래프 COM 오브젝트를  CoCreateInstance 함수를 사용하여 생성하였는데, 소멸(제거)는 어떻게 하는 것이지라고 말이죠. 자, 이것은 아주 중요한 이야기니까 별도의 설명을 해야하겠습니다. 

[2]COM의 소멸. 

자, 조금 헷갈리는 분야가 나왔습니다. COM  Server는 대체 무엇이고 COM Object는 또 무엇인가. 위의 제목이 COM의 소멸이라고 했는데 그렇다면 COM Server의 소멸을 의미하는 것인가, 아니면 COM Object 의 소멸을 의미하는 것인가. 기타 등등.  여러분은 이제 COM Server와 COM Object(혹은 객체)를 분별해야만 하는 시점이  다가온 것입니다.  

COM Server의 종류에는 Out of Process 방식과  In Process 방식의 두가지가 있습니다. 전자는 Exe형식의 완전한 독립된 응용어플로 생각하시면 되고요, 후자는 DLL 형태를 취하고 있습니다. 자, 형태론적인 관점에서 보면 두개의 차이가 명확해집니다. 그리고 내부적인 차이도 사실 무척이나 다릅니다. 여기에 대해서 잠깐 쉬었다 갈까요.

우리가 일반적으로 프로그램을 실행하면 하나의 프로세스가 생성되어서 윈도우즈 운영체제로 부터 연속된 메모리 주소를 부여받게 됩니다. 32비트 컴퓨터니까 2의 32승인 약 4G바이트의 메모리가 되겠죠. 그런데 여러분도 아시다시피 아무리 많은 응용프로그램을 실행시켜도 각각의 프로세스(혹은 프로그램)은 상대방의 메모리 주소를 전혀 침범하지 않고 잘만 작동합니다. 게다가 멀티 작업까지 가능하네요. 이게 대체 어떻게 된 것일까요.
하나의 프로세스가 실행되면서 윈도우즈 운영체제로부터 받는 메모리 주소는 사실 실제적인 물리주소가 아니라 가상 메모리의 주소를 받기 때문에 가능한 것입니다. 윈도우즈는 각각의 프로세스가 절대로 상대방의 물리적인 메모리 번지를 침범하지 못하도록 세심한 주의를 기울여 가상번지를 할당해 주고 있으므로 안심하고 멀티 태스킹 작업이 가능한 것입니다.

그런데 위의 사실을 역으로 생각하면 두개의 독립된 프로세스가 서로 상대방의 메모리를 침범하기란 운영체제가 허락하지 않는한 불가능한 일입니다. 그러나 이것을 가능하게 하는 두개의 방식이 있는데요, 하나는 공유메모리를 사용하는 것이고요, 또다른 하나는 바로 COM에서의 마샬링을 사용하는 것입니다. 저는 이제까지 공유메모리만 사용해오고 있었는데요, 예전에 한번 접근속도가 느린것 같아서 마샬링이란 것을 고려해 보았던 적이 있습니다.

아무튼, 결론은요 exe형(Out of Process) 타입의 COM Server는 내부적으로 마샬링과 같은 복잡한 과정을 거친다는 것과(왜냐하면 실제로 완전히 다른 프로그램의 메모리 영역에서 서비스를 받아야 하기 때문에),  Dll형(In Process) 타입의  COM Server는 그런일이 없기 때문에 상대적으로 간단한다는 것입니다. 이러한 것은 그냥 머릿속에 배경지식으로 활용하시길 바랍니다.

자, 이야기기 또 삼천포로 빠졌습니다. 여기까지 우리는 COM Server의 두가지 큰 형태를 알아보았습니다. 여기에 한 가지를 덧붙여 말씀드리자면 다행스럽게도 우리가 사용하는 DShow는 In Process타입의 DLL형태를 취하고 있다는 것입니다.

만일 우리가 Dong.Exe라는 COM Server(Out of Process)을 개발하였다면, Dong.Exe자체를 하나의 COM Server 라 하며, 그 안에는 여러가지 종류의  COM Obect가 존재할 수 있을 것입니다. 또한 마찬가지로 Dong.dll라는 COM Server(In Process)을 개발하였다면 Dong.dll 자체를 하나의 COM Server라 할 것이고, 그 안에는 수많은 COM Object가 존재할 수 있을 것입니다. 자, 이제 COM Server와 COM Object에 대한 어느정도의 분별이 생기셨을 것입니다.

조금더 예를 든다면, 여러분은 나중에 간단한 형태의 필터를 개발하게 될 것입니다. 이것은 물론 In Porcess 형태의 일종의 COM Server입니다. 만일 여러분이 비디오 스트림의 상하를 거꾸로 변경하는 Convert.dll 필터를 개발하였다면, 바로 이 Convert.dll이 하나의 COM Server이자 동시에 달랑 하나뿐인 COM Object를 가지고 있을 뿐인 것이죠.

현재 DirectShow에는 기본 필터가 수십여가지 있습니다. 이 필터 하나하나가 각각 별도의  In Process COM Server 의 DLL 형태로 존재할까요? 그렇지가 않습니다. DirectShow는 하나의 Dll 형태의 Server에 많은 형태의 (필터그래프 매니저를 비롯한 다양한 종류의 필터) COM Object를 담아 두고 있습니다. 이 DLL 파일의 이름이 바로 Quartz.dll입니다. Quartz.dll이라는 In Process COM Server에는 수많은 DShow용 COM Object가 포함되어 있습니다.

처음에 DShow를 공부할때, 필터를 하나의 ax확장자를 가진 파일 단위로만 생각해서 헷갈렸던 기억이 납니다. 왜냐하면 DirectShow에서 제공하는 기본필터들을 찾아 보려고 CLSID로 레지스트리를 일일이 뒤졌는데 모두다 Quartz.dll이라고 설정되어 있었기 때문입니다. 필터는 하나의 COM Server가 아니라 하나의 COM Object입니다. 따라서 어떤 하나의 Dll 형 서버에 수많은 필터가(혹은 필터그래프 매니저와 같은 다른 COM Object가...) 포함되어 있을 수가 있는 것입니다.

여러분이 만일 CoCreateInstance로 COM Object를 생성시켰다면 COM 라이브러리는(여러분은 CoInitialize를 사용하여 이미 COM 라이브러리를 초기화 하셨습니다.) 매개변수 중 하나인 CLSID를 파악하여 레지스트리에서 해당 CLSID의  COM Object가 포함된 COM Server(하드 디스크 어딘가에 저장된 dll)을 로딩할 것입니다. 그런데 이미 로딩된 COM Server에 있는 어떤 COM Obejct를 또다시 CoCreateInstance를 사용하여 인스턴스화(객체화)하였다면 어떨까요? COM 라이브러리가 이미 로딩되어 있는 Dll을 다시 로딩하지는 않을 것입니다.

이제 우리는 In Process COM Server가 어떤 형식으로 로딩되는 것인지 아셨을 것입니다. 그렇다면 이제 COM Server가 어떤 방식으로 메모리에서 언로딩(소멸)되는지 알아보도록 하겠습니다.  


    Dong.DLL  In Process Server
    ┌──────────┐
    │                              │
    │  A COM Object    ─┼───▶ CoCreateInstance로 인스턴스화 ( Dong.dll이 로딩된다.)
    │  B COM Object       │
    │  C COM Object    ─┼───▶ CoCreateInstance로 인스턴스화 ( Dong.dll이 이미 로딩되어 있다.)
    │           .                  │
    │           .                  │
    └──────────┘ 

위와같이 Dong.dll이라는 이름의 COM Server가 있다고 생각해 봅니다. 우리는  CoCreateInstance를 사용하여 A와 C라는 COM Object를 위의 순서대로 인스턴스화 하였습니다. 이제 이 상태에서 A와 C라는 COM Object가 소멸되면 COM 라이브러리는 Dong.dll을 자동으로 메모리에서 언로딩할 것입니다. 즉,다시말해서 하나의 COM Server에서 사용되어졌던 모든 COM Object가 소멸되면 해당 COM Server 는 자동으로 언로딩된다는 것입니다. (실제로 하나의 COM Server를 메모리에 로딩하거나 언로딩할때 실행되는 로직이 별도로 있습니다. 그래서 로딩과 언로딩이라는 직설적인 표현보다는 생성과 소멸이라는 말이 약간은 더 어울리는 것입니다. 하지만 여기까지는 일단 자동으로 로딩되고 언로딩된다고 이해하여도 상관은 없을 것입니다.)

자... 그렇다면 이제 어떻게 해서 COM Object를 소멸시킬 수가 있을지를 생각해 봅시다. 우리가 CoCreateInstance를 사용하여 필터그래프라는 COM Object를 생성하면서 최초로 IGraphBuilder라는 인터페이스를 얻어왔던 것을 기억하실 것입니다. 그리고 이 IGraphBuilder라는 인터페이스 형 타입의 변수에서 QueryInterface를 사용하여 나머지 주요 한 두개의 인터페이스인 IMediaControl과 IVideoWindow를 얻을 수가 있었습니다. 만약, 이 상태에서 세개의 인터페이스를 모두 제거한다면 필터그래프라는 COM Object는 자동 소멸하게 될 것입니다. 즉, 이것을 정리한다면 A라는 어떤 COM Object를 생성하여 그 안에 포함된 다수의 인터페이스 중에 몇개의 인터페이스를 얻어와 사용하다가, 그 얻어왔던 인터페이스를 모두 제거한다면 A라는 COM Object는 더이상 외부에 노출된 인터페이스가 없으므로 자동 소멸한다는 것입니다. 

이제 결론에 다다랗습니다. 그렇다면 얻어온 인터페이스는 어떻게 소멸시키는가? 이것은 너무 간단해서 싱거울 정도입니다. 얻어온 인터페이스 형 타입의 변수에 nil값을 주면 됩니다. 여기까지를 한번 종합해서 정리하겠습니다.  

  1) COM Server는 Exe나 DLL과 같이 하나의 파일 단위를 의미한다. 

  2) 하나의 COM Server 안에는 수많은 COM Object가 존재할 수 있다. 

  3) COM Server는 최초로 그 안에 포함된 COM Obejct가 CoCreateInstance로 생성될 때 COM 라이브러리에 의해(여러분은 처음에 CoInitialize라는 함수로 COM 라이브러리를 초기화하셨습니다.) 자동으로 로딩(생성)되며, 반대로 생성되었던 COM Server안의 모든 COM Object가 소멸되면 자동으로 언로딩(소멸)된다.

  4) COM Object는 그 안에 포함되어 있던 수많은 인터페이스 중에서 외부로 노출되어 졌던 모든 인터페이스가 해제되면 자동으로 소멸한다. 

  5) 인터페이스를 해제하기 위해서는 얻어온 해당 인터페이스형 타입의 변수에 nil을 대압하면 된다.  


  ****************************************** 중요. ********************************************* 
  COM에 대하여 위와같은 해설은 수박 겉핥기 식이라고 할 수가 있습니다. 별도의 책을 사서 한번쯤 휘둘러 읽어보실 필요가 있습니다. 그 시간이 정 안된다면, 김용성님의 Visual C++ 6완벽가이드(일명 눈깔책)을 구입하여 그 안에 정리된 COM 부분을 익히시는 것이 상당한 도움이 될 것이라고 생각합니다.  
  *********************************************************************************************

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