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

이제 여기까지 종합적인 코드를 완성해 보겠습니다.

type 
  TBaseDShow = class(TObject)
   private 
   public  
     FilterGraph      : IGraphBuilder;   //필터그래프의 인터페이스
     MediaControl   : IMediaControl;  //필터그래프의 인터페이스 
     VideoWindow  : IVideoWindow;  //필터그래프의 인터페이스 
     constructor Create;
     destructor Destroy; override;      
     function CreateFilterGraph(var Graph: IGraphBuilder): Boolean;
   end; 

implementation

constructor TBaseDShow .Create;
begin
  inherited Create;
  CoInitialize(nil);        //COM을 초기화한다.
  CreateFilterGraph(FilterGraph);   //필터그래프를 생성한다.
  FilterGraph.QueryInterface(IID_IMediaControl, MediaControl);  //필터그래프의 또다른 인터페이스 얻어오기
  FilterGraph.QueryInterface(IID_IVideoWindow, VideoWindow); //필터그래프의 또다른 인터페이스 얻어오기
end;

 

destructor TBaseDShow .Destroy;
begin
  if Assigned(MediaControl) then MediaControl.Stop;         //비디오 랜더링을 중단한다.
  While Assigned(VideoWindow) do VideoWindow := nil;
  While Assigned(MediaControl)  do MediaControl := nil;
  While Assigned(FilterGraph)     do FilterGraph := nil;
  CoUninitialize;         //COM을 셧다운시킨다.
  inherited Destroy;
end; 

function TBaseDShow .CreateFilterGraph(var Graph: IGraphBuilder): Boolean;
var
  ID : Integer;
begin
  Result := False;
  if Failed(CoCreateInstance(CLSID_FilterGraph,
                              nil,
                              CLSCTX_INPROC_SERVER,
                              IID_IFilterGraph,
                              Graph))
  then Exit;
  Result := True;
end;

 

위의 코드를 보면 Destory부분에 약간의 예상외 로직이 보이실 것입니다. 우선 첫번째로 필터그래프를 소멸시키기 전에는 반드시 비디오 스트림의 흐름을 정지시켜야 할 것입니다. 그래서 MediaControl.Stop이라는 코드가 첫번째로 삽입된 것이고요, 두번째부터 인터페이스를 해제시키는 로직에 While문이 있다는 것에 조금 의아하셨을지도 모르겟습니다. 

DShow는 간혹가다가 원인 불명의 다운현상을 발생시킵니다. 이유는 여러가지가 있을 수 있겠습니다만, 주로 적절치 못한 구조의 필터나 혹은 WDM 장치 드라이버가 아닐까 생각합니다. 아무튼, 다운이 되는 경우는 주로 동영상을 플레이하거나 반대로 정지시키는 시점에서 발생한다는 것인데요, 상황에 따라서 완전히 다운되는 경우도 있고 아니면 잠시 대기상태에서 빠져나올 수도 있습니다. 
이때 완전히 다운되는 것은 막지 못하겠지만, 잠시 대기상태에서 빠져나오는 것은 위의 방식 처럼 While를 사용하여 해결할 수가 있다는 것이죠. 실제로 While문을 사용한 후부터 어플이 상당하게 안정화 되었음을 느낄 수 있었습니다.  밑져야 본전이니까 그냥 버릇처럼 사용하시면 될 것이라고 봅니다. 어차피 다운되면 다운 되는 것이니까요.  

  => While Assigned(FilterGraph)     do FilterGraph := nil;

[1]필터를 생성하는 함수.

이제 우리는 TBaseDShow Class에다가 다음 세가지 함수를 추가해 넣을 것입니다. 첫째는 필터를 생성하는 함수이고, 두번째는 필터의 핀을 찾아내는 함수이며, 마지막으로 각각의 다이렉트쇼 카테고리에서 음성이나 비디오 입력장치 등을 얻어 오는 함수입니다.

우선 필터를 생성하는 함수는 사실 필터그래프를 생성하는 함수와 90%이상 동일합니다. 왜냐하면 필터 자체가 하나의  COM Object이기 때문에 CoCreateInstance함수를 사용하여야 하기 때문입니다. 필터그래프를 생성했던 것과 동일하게, 만들고자 하는 함수 안에는 CoCreateInstance 함수 하나만이 달랑 위치해 있게 될 것입니다.
자, 그렇다면 굳이 이렇게 필터를 생성하는 함수와 필터그래프를 생성하는 함수를 별도로 구분하여 만들어 놓을 필요가 있을까하고 생각하실 것입니다. 두가지 모두 COM Object이기 때문에 COM Object를 생성하는 함수를 하나 만들어 두고, 필터그래프나 필터를 생성할때 동일하게 사용하면 되지 않을까하는 생각이 들기도 하실 것입니다. 결론은 그렇게 해도 됩니다. 다만 저는 이렇게 두가지 별도의 함수로 만들어 놓은 것이 실보다는 득이 더 많다고 생각한 것일 뿐입니다.

우선 첫째로, 필터그래프나 필터를 생성할 때마다 그 두가지를 분별해서 생각할 수 있게 해주며, 두번째는 사실 범용적인 COM Object를 생성하는 방식은 매개변수 하나를 더 설정해야 하는데요, 이것은 필터를 생성할 때마다 상당히 번거롭습니다. 필터가 한두개라면 모르지만 앞으로 10개 이상의 필터를 자유롭게 생성해야 하는데 동일한 매개 변수를 매번 설정하는게 참 번거롭기 때문입니다. 아무튼 이것은 코딩의 관점이니 구태여 저의 형식을 강요하지는 않겠습니다. 자, 그러면 아래의 완성된 로직을 보겠습니다.

function TBaseDShow.CreateFilter(const clsid: TGUID; var Filter: IBaseFilter): Boolean;
begin
  Result := False;
  if Failed(CoCreateInstance(clsid,
                                             NIL,
                                             CLSCTX_INPROC_SERVER,
                                             IID_IBaseFilter,
                                             Filter))
  then Exit;
  Result := True;
end;

위에서 보시면 아시겠지만, 필터그래프를 생성시키는 로직과 거의 비슷합니다. 설명은 드리지 않았지만 매개 변수중의 하나인 CLSCTX_INPROC_SERVER가 의미하는 것이 바로 In Process형의 COM Server임을 나타낸다는 것을 짐작하실 것입니다. 이것을 도움말 파일에서 찾아보면 다음과 같습니다. '이 파라미터는 개체가 동적 링크 라이브러리 (DLL)로서 처리 되어 애플리케이션의 처리의 일부로서 실행되는 것을 나타낸다.' 예상했던 것과 동일한 정의가 되어있음을 확인할 수가 있습니다.

자, 이제 함수의 매개변수중 두번째 IBaseFilter를 보아 주시기 바랍니다. 이 인터페이스는 모든 필터들이 반드시 상속 받아야할 인터페이스입니다. 그러나 반드시 있어야 할 인터페이스라고 해서 없으면 필터를 생성하지 못한다라는 것은 아닙니다. (실제로 확인은 해보지 않았지만 이것도 COM  Object의 일종이니 객체가 생성되긴 할 것이라고 봅니다.)

이 인터페이스가 없으면 필터그래프에 등록할 수가 없기 때문입니다. 앞서서 우리는 필터그래프가 어떠한 역할을 하는지를 말씀드렸습니다. 즉, 필터들을 필터그래프 자신에게 등록하고 그것들을 서로 연결시켜주는 서비스를 해준다고 하였지요. 이렇게 필터그래프에 등록할때에는 반드시 공통되는 인터페이스가 필요한데요, 이것이 바로 IBaseFilter라는 인터페이스입니다. 이 부분을 미리 살짝 보여드린다면 다음과 같은 코드가 될 것입니다.  

  1)  DongFilter : IBaseFilter;      //인터페이스형 변수선언. 
  2) CreateFilter(CLSID_DongFilter,DongFilter);     //필터를 생성한다. 
  3) FilterGraph.AddFilter(DongFilter ,'DongFilter Filter');    //필터그래프에 생성한 필터를 등록한다. 
 
위에서 보시듯이 순서대로 생각하시면 되겠습니다. 먼저 필터의 IBaseFilter 형 타입의 변수를 선언합니다. 그리고 두번째로 생성하면서 동시에 IBaseFilter 인터페이스를 얻어옵니다. 마지막으로 이  IBaseFilter형 타입의 변수를 필터그래프에 추가해 줍니다.(뒤쪽의 'DongFilter Filter'라는 것은 일종의 TPanel에서 Caption  정도라고 생각하시면 되겠습니다.)  여기까지...

[2]필터의 핀 인터페이스를 얻어오는 함수.

이제부터 조금 까다로운 필터의 핀 인터페이스를 얻어오는 함수에 대하여 설명해야 하겠습니다. 그런데 이 함수를 논하기전에 우선 필터의 핀이란 대체 무엇인지를 알아야 할 것입니다. 여러분은 전에 GraphEdit을 사용해서 필터를 비주얼하게 생성시켰던 것을 기억하실 것입니다. 이 필터들의 꽁지와 꽁지를 마우스로 잡아당겨서 화살표로 연결시켜주었는데요, 바로 이 꽁지부분을 필터의 '핀'이라고 지칭하는 것입니다. 사실 GraphEdit에서 보기에는 '핀'의 모습이 거대한 필터의 크기에 비하여 너무 보잘 것이 없습니다. 그래픽상으로는 그냥 조그마한 점에 불과한 것인데요, 실제 필터의 내부에서는 배보다 배꼽이 더 크게 구현되어 있습니다. 즉, 모든 로직의 대부분이 이 필터의 '핀'에 집중되어있다는 것입니다.

이것이 무슨 의미인지를 예를 들어서 보겠습니다. 우선 아래의 간단한 클래스를 보시겠습니다.

  TDong = class(TObject)
    Img : TImage;  //멤버객체(혹은 멤버필드)
   end;

위에서 보시면 아시겠지만 TDong이라는 클래스 안에 Img라는 TImage형 타입의 멤버객체가 또다시 존재하고 있습니다. 필터의 핀도 이와 거의 동일한 존재입니다. 즉, 필터가 하나의 COM Object라 한다면 핀은 그 COM Object 안에 포함된 또다른 형태의 멤버 COM Object라는(위에서 Img와 같은) 것입니다. 여기까지 이해가 되셨다면 왜 제가 처음에 배보다 배꼽이 더 크다고 비유하셨는지 아셨을 것입니다.
위의 TDong이라는 클래스에서 TDong이라는 객체는 사실 껍데기에 불과하고 달랑 TImag형 멤버객체인 Img 변수가 더 큰 비중을 차지하는 것처럼 보여집니다. 바로 필터의 '핀'이라는 것도 이와 같은 방식으로 필터 안에 놓여져 있기 때문에 그러한 비유를 한 것입니다. 필터에 있어서는 '핀' 이 전부라고 생각해셔도 무방할 정도입니다.  이것은 나중에 필터를 집적 만들어 보시면 아시게 될 것입니다.  일단은 이정도 이해 만을 가지고 다음으로 넘어가겠습니다.

자, 그렇다면 이제 문제의 핵심을 살펴봐야 겠습니다. 우리가 어떤 COM Object 에서 인터페이스를 뽑아내기란 식은죽 먹기였습니다. 바로 QueryInterface라는 메소드를 사용해서 가능했던 것이죠. 그러나 COM Object 안에 포함되어있는 또다른 멤버 COM Object의 인터페이스를 뽑아내는 것은 간단한 일이 아닙니다.
그래서 필터에서 그것을 가능하게 하기 위하여 메소드를 하나 제공해 줍니다. 바로 FindPin 이라는 메소드 입니다. 즉 Dong 이라는 IBaseFilter 인터페이스형 변수가 있다면, Dong.FindPin(Pin이름, 받아낼 '핀' 타입변수) 이런 형식으로 핀 인터페이스를 얻을 수가 있습니다. 그러나 저는 이 방식을 사용하지 않습니다. 이것에 대하여 부연설명을 해드려야 겠습니다.

핀의 인터페이스를 얻는 방식으로는 두가지 접근방식이 있습니다. 하나는 핀의 이름으로 검색하는 것이고, 또다른 하나는 핀의 위치로 검색하여 얻어내는 것입니다. 예를 들어 다음과 같은 필터가 있다고 합시다. 입력핀은 1 개이고 출력핀은 3개 정도입니다. ( 필터에서 핀은 수없이 많이 만들 수가 있음.)
 

                                       Dong.ax 필터.
                              ┌──────────┐ 
                              │                               ■  (출력핀1)
                              │                              │
              (입력핀1)  ■                                ■  (출력핀2)
                              │                              │ 
                              │                               ■  (출력핀3)
                              └──────────┘


위에서 만일 '입력핀1'을 얻고자 한다면(정확히 말씀드리자면 입력핀1이라는 COM Object의  IPin 인터페이스) 우리는 '입력'이라는 방향을 알고 있고 위에서 첫번째 순서라는 것을 알고 있기 때문에 이러한 조건을 가지고 원하는 핀을 얻을 수가 있습니다. 또한 '출력핀3'을 얻고자 한다면 '출력'이라는 핀의 방향을 알고 있고, 위에서 세번째에 있기 때문에 이러한 조건을 가지고 '출력핀3'을 얻을 수가 있는 것입니다.

정리하자면 핀을 검색하는 방식으로는 FindPin이라는 메소드를 사용하여 찾는 것과, 핀의 방향과 순서를 조건으로 에뉴무레이트(열거)하여 찾아내는 방식, 이렇게 두가지가 있다는 것입니다. 그런데 저는 주로 후자의 방식을 사용하는데요, 여기에는 이유가 있습니다. 

솔직히 말씀드리자면 FindPin 이라는 메소드가 실은 제대로 작동하지 않는 경우가 종종 있습니다. 여기에는 필터를 개발하는 사람들의 '소홀함'도 지적될 수가 있겠는데요, 아무튼 그 이유 여하를 떠나서 상당히 자주 잘못된 핀을 얻어올 수가 있다는 사실입니다.
제가 어디서 읽었는지는 가물가물 합니다만 그곳에서도 이렇게 핀의 이름으로 검색하지 말라고 경고한 것으로 기억납니다. 아무튼 저는 핀찾기에서 '조건'으로 에뮬레이트합니다. 그리고 남들도 이러한 방식을 선호하고 있다는 사실을 종종 확인할 수가 있습니다. 아주 시간이 없고, 그래서 미칠것 같은 스트레스에 휩싸여 있었을 적에 한번 '이름'으로 찾기를 시도한 적이 있었는데요, 결국 원하는 핀을 몇시간 동안이나 찾지 못해 헤메였던 기억이 생생 합니다. 
DShow는 이렇게 에뮬레이트 방식을 주로 사용합니다. 비단 핀찾기 뿐만이 아니라 나중에 카테고리를 뒤져야 할 때에도 에뮬레이트(열거) 방식을 사용할 것입니다.  자, 이제 핀을 찾는 함수를 다음과 같이 선보이겠습니다.  
      
     function TBaseDShow.FindPinOnFilter(const Filter: IBaseFilter;
                                                                 const PinDir: TPinDirection;
                                                                 var Pin: IPin): HRESULT;
     var
       IsConnected : Boolean;
       hr: DWORD;
       EnumPin: IEnumPins;
       ConnectedPin: IPin;
       PinDirection: TPinDirection;

     begin
       Result := S_False;

       if not Assigned(Filter) then exit;
       hr := Filter.EnumPins(EnumPin);
 

       if(SUCCEEDED(hr)) then
       begin

        while (S_OK = EnumPin.Next(1, Pin, nil)) do
         begin

           //핀이 연결되었는지 조사.
           hr := Pin.ConnectedTo(ConnectedPin);
           if hr = S_OK then
           begin
             IsConnected  := True;
             ConnectedPin := nil;
           end else IsConnected := False;
 

           //핀의 방향을 검사
           hr := Pin.QueryDirection(PinDirection);

           //매개변수의 핀방향과 동일하고 현재 연결된 상태가 아니라면 루프에서 탈출. 
           if (hr = S_OK) and (PinDirection = PinDir) and (not IsConnected) then break;

           pin := nil;
         end;

         Result := S_OK;
       end;
       EnumPin := nil;
     end;


위의 함수 내용에 대해서는 일일이 설명을 하지 않겠습니다. 기본적인 로직에 속하는 것이기 때문입니다. 하지만 여러분이 혹시 눈치채셨을지 모르겠지만 약간은 이상하다는 생각이 드실 것입니다. 그렇습니다. 위의 함수에서는 방향을  지시하는 매개변수는 있지만 위치를 지정하는 매개변수는 존재하지 않습니다. 

사실 위의 첫 모델에서는 위치를 지정하는 매개변수가 있었습니다. 하지만 점점 제 자신에 맞게 다듬다가 보니까 이렇게 단순화 된 것입니다. FindPinOnFilter함수는 C로 된것을 델파이로 포팅한 것입니다. 제 기억으로는 원래 더 복잡했던 것으로 기억합니다. 아무튼 여러분도 자신만의 FindPinOnFilter 함수를 개발하여 사용하실 날이 도래할 것입니다.

굳이 설명을 드리자면 위에서는 핀의 순서상에서 가장 첫번째로 '접속되지 않은' 핀을 리턴한다는 것입니다. 이 함수를 사용하여 실제로 핀(IPin 인터페이스)을 얻어내야 할 것입니다.  

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