꿈을 찾아서

이제 우리는 TBaseDShow의 마지막 함수인 다이렉트쇼 카테고리에서 원하는 장치를 불러오는 함수에 대하여 이야기를 할 것입니다.

[1] 카테고리에서 입력장치 불러오기 

여기서 우리는 한가지 인식하고 넘어가야 할 것이 있습니다. 그것도 구체적이며 비주얼하게 말이죠. 일단 GraphEdit 를 실행하여 '필터삽입윈도우'를 띄웁니다. 그곳에는 수많은 카테고리가 존재할 것입니다. 먼저 DirectShow Filters라는 카테고리를 클릭하여 아래로 쭉 풀어 놓습니다.
(이 필터삽입 윈도우의 크기가 고정되어 있는게 정말 불만이다. 앞으로 여러분은 필터를 만드실 경우가 있는데요, 만드신 필터를 이 GraphEdit를 사용하여 시뮬레이트를 하여야 합니다. 그런데 필터를 레지스트리에 등록해 놓고서, 이곳 GraphEdit의 DriectShow Fitler라는 카테고리에서 찾을 때마다 참 번거롭습니다. 보시다시피 등록되어 있는 필터들이 너무 많아서 좁은 창안에 한꺼번에 보이지 않을 뿐더러... 아무튼 이래저래 불편합니다. )


DirectShow Filters 카테고리 안에 놓여진 수많은 필터를 보시면 두개의  GUID가 나란히 놓여져 있는게 보이실 것입니다. 아마도 여러분의 눈에는 하나의 GUID(혹은 다른말로 CLSID)만 보이실 지도 모르겠습니다. 이것은 '필터삽입 윈도우'가 작아서 입니다. 수평스크롤바를 클릭하여 오른쪽으로 이동시키면 나머지 GUID도 보이실 것입니다. 이것의  한 예로 다음과 같습니다. 

  Video Renderer
    DisplayName : @device:sw:{083863F1-70DE-11D0-BD40-00A0C911CE86}\
                                                                                                {70E102B0-5556-11CE-97C0-00AA0055595A}
    FileName : C:\WIndows\system32\quartz.dll
    Merit : 00400000
    pin: 00 
    Version : 2


대충 위와같이 보이실 것입니다. 자, 위에서 보시다시피 하나의 필터에 두개의 CLSID가 보입니다. 이게 웬 하늘에 봉창 떨어질 일입니까. 하나의 COM Object에 두개의 CLSID가 있다니요. 하지만 당황하지 말고, 다른 필터들을 살펴보시기 바랍니다. 모두 두개의 CLSID가 있는데요, 앞의 CLSID는 하나같이 동일한 값이라고 확인 하실 수 있습니다. 자, 앞의 CLSID는 바로 카테고리의 CLSID를 의미하는 것입니다. 이것을 정리하면 아래와 같습니다.  
   
    DisplayName : @device:sw(종류):{카테고리 클래스 관리자의 CLSID}\{필터 CLSID 또는 ID} 

만일 우리가 특정한 카테고리에서 원하는 필터나 장치의 인터페이스를 가져오고 싶다면, 우리는 제일먼저 해당하는 카테고리의 CLSID를 알아야 할 것입니다. 그렇다면 여기서 우리는 한가지 의문이 들 것입니다. DirectShow Filters 카테고리 안에 있는 필터의 경우에는 별도로 카테고리 CLSID를 알지 못해도 CoCreateInstance를 사용하여 잘만 생성하여 사용하였는데, 왜 다른 카테고리에 있는 장치(혹은 광의의 필터)의 경우에는 반드시 카테고리 CLSID를 알아야 하는 것인가 하고... 

이 의문에 대한 해답은 이렇습니다. 우리가 DShow를 사용하기 위해서는 반드시 필터그래프 매니저를 필요로 합니다. 즉, 필터그래프가 필터들을 연결시키고, 스트림의 Run, Stop, Pause등과 같은 필수적인 제어를 하기 때문입니다. 그런데 필터그래프에 필터를 추가하기 위해서는 반드시 IBaseFilter 라는 인터페이스가 필요한데요, 이 인터페이스가 모든 COM 객체나 혹은 예전방식의 어떤 장치들(VFW 방식의 압축코덱이나  혹은 WDM 디바이스 드라이버)에 존재하는 것은 아니라는 사실입니다. 

예를 든다면 Video Compressors 카테고리에 있는 코덱들은 대부분 VFW의 구조를 가지고 있습니다. 이 구조는 COM 객체가 아니라 일종의 DLL 함수들만이 뿔뿔이 존재할 뿐입니다. 그런데 만약 여기서 IBaseFilter를 가져오지 못한다면 DShow는 예전방식의 모든 압축코덱이나 혹은 입출력 디바이스 드라이버를 사용하지 못할 것인데요, 이것은 말도 안돼는 것이겠죠.(MS가 세상물정에 어둡거나 혹은 볼랜드 같이 완전히 새로운 패러다임의 작품을 만들기를 시도한다면 모르겠지만... 쩝.)

자, 결론적으로 말하자면 DShow의 구조가 아닌 COM 객체나 혹은 예전방식의 모듈에서 IBaseFilter라는 인터페이스를 바인딩해주는 서비스가 별도로 필요하게 된 것인데요, 이 서비스를 받기 위해서 카테고리의 CLSID가 필요한 것이라고 생각하시면 되겠습니다. (이 서비스가 바로 IMoniker라는 일종의 COM의 인터페이스인데요, 이것은 비단 DShow에서만 사용하는 것은 아닙니다. 하기야 수많은 DShow의 인터페이스를 반드시 DShow에서만 사용하라는 법은 없는 것과 마찬가지일 것입니다. 우리가 TList를 데이터베이스와 같이 특정한 곳에만 사용해야 한다는 법칙이 없는것과 마찬가지 일 것입니다. )

여기까지 우리는 DirectShow Filters 카테고리 이외의 카테고리에서 원하는 장치(혹은 광의의 필터)를 얻기 위해서는 반드시 카테고리 CLSID를 알아야 하며, 그 이유는 DShow 방식의 구조가 아닌 객체나 모듈에서 IBaseFitler를 얻기위한 서비스에 반드시 필요한 요소이기 때문이라고 설명하였습니다. (제가 장치를 광의의 필터라고 하는 것은 바로 위에서 설명했던 것처럼 IBaseFilter라는 인터페이스를 얻을 수 있기 때문입니다.)

우리가 RS232시리얼 통신 프로그램을 만드는데 있어서 그 통신모듈을 직접 제작할 필요가 없이 잘 알려진 컴포넌트나 라이브러리를 사용하듯이, 델파이에서 DSPack를 가지고 DShow용 어플을 제작하면서 굳이 IMoniker서비스를 받기까지의 로직을 별도로 구현할 필요가 없다고 생각합니다. 하지만 정 궁금하시다면 DSPack에 있는 소스를 보시면  별로 어렵지 않다고 생각하실 것입니다. 아무튼 우리는 DSPack에서 미리 구현되어 있는 TSysDevEnum라는 클래스를 사용하여 아주 간단히 이러한 서비스를 받아 볼수가 있습니다.  그 전에 우선 주요한 카테고리의 선언을 보시면 다음과 같습니다.  

  CLSID_VideoInputDeviceCategory   //비디오 입력장치.
  CLSID_AudioInputDeviceCategory   //오디오 입력장치.
  CLSID_VideoCompressorCategory  //비디오 압축코덱
  CLSID_AudioRendererCategory      //오디오 랜더러.


위의 것들은 모두 DSPack의 DirectShow9.pas 파일에 정의되어 있습니다. 이곳에는 위의 4가지 말고도 모든 카테고리의 정의가 선언되어 있는데요, 이것을 필요할 때마다 찾기가 번거롭습니다. 그래서 차라리 TBaseDShow의 유닛에다가 몽땅 주석과 함께 옮겨 놓던지 하는게 좋습니다. 이상하게도 자주 까먹습니다. 

자, 이제 우리가 원하는 함수의 모습은 아래와 같습니다.  (저 같은 경우는 SysEnum 변수를 TBaseDShow의 멤버객체로서 정의해 놓고 사용해 왔는데요, 왜 그랬는지 기억이 가물가물 나지 않습니다. 현재 TSysDevEnum 의 내부 로직을 살펴보니까 로컬로 사용해도 무리는 없을 것 같아서 이해하기 쉽게 변경하였습니다.)

  function TBaseDShow.GetCamFilter: IBaseFilter;
  var
    SysEnum: TSysDevEnum;
  begin
    SysEnum := TSysDevEnum.Create;
    try
      SysEnum.SelectGUIDCategory(CLSID_VideoInputDeviceCategory);
      Result := SysEnum.GetBaseFilter(0)// 가장 첫번째 장치를 가져온다.
    finally
      SysEnum.Free;
    end;
  end;



위에서 가장 첫번째 장치를 가져온다는 부분에 유의하셔야 합니다. 사실 여러분은 장치의 이름으로도 검색하실 수가 있습니다. 예를 들어 압축코덱은 수많은 종류가 PC마다 순서의 기준이 없이 등록되어 있기 때문에 위와 같이 '몇번째 놓여있는 것을 가져와' 하는 것은 위험한 일입니다. 따라서 분명히 압축코덱과 같은 것들은 카테고리에서 이름으로 찾아야 할 것입니다.
그러나 카메라의 경우는 다릅니다. 압축 코덱의 경우와는 반대로 카메라의 경우에는 특정한 USB 드라이버의 이름에 맞게 DShow 어플이 제작되어서는 안되기 때문입니다. 그래서 어쩔 수 없이 카테고리의 순서에서 찾아서 장치를 가져옵니다. 혹시 여러분이 동영상 채팅같은 것을 할 경우에 클라이언트 프로그램을 실행시킴과 동시에 다음과 같은 문구를 보신적은 없으신지요. 

   '현재 컴퓨터에 비디오 입력 장치가 1개이상이 발견되었습니다. 몇번째 장치를 사용할 것인지를 선택하세요.'

위와 같이 선택 다이알로그 창이 뜨는 것을 보신적이 있으신지요. 이것들은 모두 위와같은 이유 때문인 것입니다. 
(장치가 1개 이상인 경우가 보통은 드물지만 DShow 개발자들에게서는 흔히 일어납니다. 예를 들어서 PCI 슬롯에  TV수신카드(혹은 BT878보드)나 엠팩보드가 동시에 꽂혀있고, USB에는 USB용 카메라까지 꽂혀 있으니까요. 그래서 예전에 저같은 경우는 PC를 살때 파워서플라이를 항상 일반인 용보다 월등히 성능 좋은 것을 사용해야 했던 기억이 납니다.) 

이제, TBaseDShow를 비로소 완성하였습니다. 이것의 풀소스를 아래와 같이 적겠습니다. 

unit cBaseDShow;

interface
uses
  Windows, SysUtils, Classes, Registry, DirectShow9, ActiveX, ExtCtrls, DsUtil;
 

type
  TBaseDShow = Class
  private
  public
    //필터그래프와 인터페이스...
    FilterGraph: IGraphBuilder;
    MediaControl: IMediaControl;
    VideoWindow: IVideoWindow;
 

    constructor Create;
    destructor Destroy; override;
    function GetCamFilter:IBaseFilter;
    function CreateFilterGraph(var Graph: IGraphBuilder): Boolean;              //필터그래프를 생성한다.
    function CreateFilter(const clsid:TGUID; var Filter:IBaseFilter): Boolean;  //각종 필터를 생성한다.
    function FindPinOnFilter(const Filter: IBaseFilter;                         //필터에서 내가 원하는 핀을 찾아주는 함수.
                             const PinDir: TPinDirection; var Pin: IPin): HRESULT;

  end;
 

implementation

 

{ TBaseDShow}

 

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;
  //GraphEdit로 현재의 필터그래프 구성을 볼수 있게한다.
  AddGraphToRot(Graph,ID);
  Result := True;
end;

 

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;

 

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;

function TBaseDShow.GetCamFilter: IBaseFilter;
var
  SysEnum: TSysDevEnum;
begin
  SysEnum := TSysDevEnum.Create;
  try
    SysEnum.SelectGUIDCategory(CLSID_VideoInputDeviceCategory);
    Result := SysEnum.GetBaseFilter(0)// 가장 첫번째 장치를 가져온다.
  finally
    SysEnum.Free;
  end;
end;

end. 
 

DirectShow란 무엇인가를 극명하게 보여주는 것이 바로 이 GraphEdit입니다. 이것을 사용하는 것이 바로 DShow를 눈으로 보는 것이다라고 말할 수 있기 때문입니다. 만일 여러분이 DirectX SDK를 설치하셨고 제가 앞서 말씀드렸듯이 바탕화면에 바로가기를 설정해 놓았다면 이제 이 프로그램을 실행시켜 보시길 바랍니다.

  

 

DShow는 필터들의 연결입니다. 이 말을 쉽게 해설하기 위해서 저는 GraphEdit라는 유틸을 사용할 것입니다. 일단 이 프로그램을 실행시켰다면 간단하게 동영상을 한번 랜더링(실행)시켜 보도록 합시다.
File 메뉴의 Render Media File... 을 실행시키고 동영상 파일하나를 선택합니다. 만일 여러분의 컴퓨터에 현재 동영상을 재생하는데 필요한 코덱이 설치되어 있다고 하더라도 이곳에서는 다음과 같은 메시지가 나올 수가 있습니다. '비디오 스트림을 재생할 수 가 없습니다. 적절한 압축 풀기 프로그램을 찾을 수가 없습니다.' 그러면서 오디오 부분만이 설정이 되어 화면에 나타날 수가 있습니다.

해결방법은 몇가지가 있겠으나, ffdshow를 설치하라고 권하고 싶습니다. 인터넷에서 다운받아서 ffdshow를 설치하시기 바랍니다. FFDShow는 오픈소스로서 공개되어 있습니다. 여기에는 XVid, DivX를 비롯하여 아무튼 Mpeg 압축의 스탠다드 코덱들이 총 망라되어 있습니다. 곰TV도 이 소스를 가지고서 만들었다는 이야기가 있는데요, 확인해 보지 않아서 모르겟습니다만 충분히 가능성 있는 이야기입니다. 만일 여러분이 Mpeg 알고리즘을 공부한다면 기초가 될 소스가 바로 이 FFDShow 소스일 것입니다. 혹시 FFShow를 찾기 힘들다는 분은 XVid 코덱을 다운받아 설치하시면 될것 같습니다. 아무튼 해결하시고요...  (FFDShow는 실행판과 소스판이 별도로 존재합니다. 이곳 자료실에 소스판을 올려놓아도 좋을까 고민이 좀 되네요.)

문제가 해결되었다고 보고요, graphedit를 보시면 화면 가득히 박스들이 보이실 것입니다. 그런데 이 박스들이 그냥 있는게 아니라 화살표를 꽁지에 꽁지를 물고 늘어져 있는 것이 보이실 것입니다. 이 박스 하나 하나가 바로 필터객체를 의미하며 화살표의 연결방향이 바로 연속적인 스트림의 진행방향을 의미합니다.

일단 여기까지 설명하고 실행을 시켜 보도록 하겠습니다. 위의 단축버튼중에서 왼쪽에서 여덟번째을 보시면 일반적인 동영상 실행 아이콘으로 표시된 스피드 버튼을 찾으실 수가 있을 것입니다. 이것을 클릭하시면 별도의 동영상 랜더링 윈도우가 뜨면서 동영상이  재생되는 것이 보일 것입니다. 자 별로 대단한 것은 아닙니다만 우리는 간단히 동영상을 로딩해서 랜더링하고 있는 것입니다. 

이제 윈도우를 종료하고 다시 GraphEdit로 돌아와 봅니다. 화면 상단에 가득 채워진 정체불명의 박스들을 한번 마우스로 집어서 이동시켜 봅니다. 여러분이 원하시는대로 움직이는데 유독 화살표는 자신이 원래 잡고있던  위치에서 벗어나지 않으려고 늘어지거나 줄어들거나 할뿐입니다.
즉 스트림의 방향은 수정할 수가 없다는 말인데요 이것은 사실 중요한 의미입니다만, 여기서는 단지 그렇다라고 이해하시면 되겠습니다. 여기서 박스(이하 필터라고 하겠습니다.)을 클릭한채 Delete키를 누르면 선택한 필터를 삭제할 수도 있습니다. 지금 삭제하지는 마십시요. 나중에 확인하도록 하고요, 여기까지를 일단 정리하여야 하겠습니다. 

[2] 필터들의 연결과 방향.

그래프 에디터에 보이는 수많은 필터들을 보시면 화살표 방향이 왼쪽에서 오른쪽으로 흘러간다는 것을 확인하실 수가 있을 것입니다. 이것을 좀더 자세히 들여다보죠. 일단 가장 왼쪽에 있는 필터를 우리는 소스필터라고 부릅니다. 말 그대로 스트림의 근원이라고 생각하시면 됩니다. 여기서부터 모든 스트림이 시작될 것입니다.

그리고 그 다음 필터를 보시면 AviSplitter 필터를(혹시 여러분이 일반적인 영화 파일이 아니라 조금 예외적인 동영상을 오픈했다면 이 필터가 보이지 않으실 수도 있습니다.) 보실수가 있는데요, 이것을 파서 필터라고 합니다. 파서필터에 대해서는 나중에 다시  설명할 기회가 있을 것입니다.

그리고 여기서 스트림이 비로소 두개로 나눠지게 되는데요, 위쪽으로 흘러가는 화살표 방향으로는 비디오 스트림이, 그리고 아랫쪽의 방향으로는 오디오 스트림이 각각 흘러가게 됩니다. 그런데 중요한 것은 여기까지의 스트림은 아직까지도 압축된 상태라는 점입니다. 다시 말하면 비디오 영상을 기준으로 각각의 프레임의 데이터 크기가 동일하지 않다는 말이죠.

예를 들어 320*240의 화면에 RGB24라면 320*240*3 byte씩의 데이터가 버퍼링되어 흘러가는 것이 아니라는 것이죠. 여기까지는 압축된 데이터이기 때문에 어떨때에는 9kByte가 되었다가  또 어떨때에는 몇백Byte가 되었다가 합니다. 물론 Mpeg 압축일 경우이고요, 만약에 동영상 스트림이 Jpeg로 압축되었다면 마찬가지로 각 프레임의 데이터 크기가 변하겠지만 Mpeg처럼 엄청나게 변하지는 않겠죠. 
( 상식에 속하지만 혹시 모르는 분을 위하여 간단히 설명하겠습니다. 동영상을 압축하는 방식으로는 일반적으로 프레임을 기준으로 앞프레임과 뒷프레임을 비교하여 그 차이점을 예측,비교하여 압축하는 기업이 있습니다. 이것의 대표적인 방식이 Mpeg방식이라고 합니다. 이러한 방식은 키프레임을 중심으로 변화량을 예측하거나 차이점만을 추려내어 압축하기 때문에 스트림의 변화가 상당히 큽니다.) 

다시 간추리자면 AviSplitter필터에서 갈라져 나온 두개의 스트림은 각각 영상과 음성의 스트림이며 여기까지는 압축된 데이터가 흘러가고 있다는 점입니다. 그리고 그 다음으로 비로소 압축을 해제하는 DeCoder필터가 붙게 되는데요, 각각 영상 DeCoder 코덱과 음성 DeCoder코덱이 붙게 됩니다.
이 각각의 DeCoder 필터에서 흘러나오는 스트림이 비로소 압축이 해제된(다른 말로는 뻥튀기되어 데이터가 엄청 불어난) 데이터이며 이것을 가지고 여러가지 합성을 하거나 변형을 하거나 할수가 있는 것입니다. 그리고 다음으로는 완전한 동영상 스트림 데이터를 랜더링할 수 있는 랜더러 필터가 붙게 되는 것이죠. 물론 각각의 비디오 랜더러 필터와 오디오 랜더러 필터를 의미합니다.  이것을 한번 부족하나마 도식으로 그려봅시다. 


  소스필터 --> 파서필터 --> 비디오 DeCoder 필터 --> 비디오 랜더러 필터. 
                             |-----> 오디오 DeCoder 필터 --> 오디오 랜더러 필터. 


자... 이제 간단하게나마 결론을 내 봅시다. DirectShow는 필터들의 연결이며 이 각각의 필터는 시작과 끝이 있다.
즉 소스필터로 시작해서 랜더러 필터로 끝난다. 여기까지 대충 정리가 되었다면 다음으로 넘어갑시다.
(우리는 나중에 이러한 필터들을 직접 코딩상에서 구현하여 연결하고 랜더링까지 할 것입니다. 간단하죠. 필터를 만들고 연결하고 랜더링한다. 이것이 DirectShow의 전부입니다. 한가지 개인적인 생각입니다만 마이크로소프트 계열의 소프트웨어적인 특성은 내부는 어쩔수 없이 복잡하지만 전체적인 구조는 간단하게라는 슬로건을 내걸고 있는 듯 싶습니다.
이것은 볼랜드 진영의 전체적인 구조는 복잡해도 좋지만 내부는 될수 있으면 간결하게라는 방향과 완전히 반대적인 성향인 것 같고요... 물론 완전히 제 개인적인 생각이지만요. 그래서 마소는 항상 시장변화에 유들유들할 수가 있는 것이고 볼랜드는 그러한 변화의 대처에 늦을 수밖에 없는 것이 아닌가 싶네요. 모든지 장점이 있다면 단점이 있듯이, 이제부터 여러분은 이 악몽같이 복잡한 DirectShow의 내부로 초대받아야 할 것입니다.)

[2] 여러가지 필터들의 카테고리.

이제 여러분은 GraphEdit의 다른 면을 보셔야 합니다. 조금더 디테일하고, 조금더 번거로우며, 조금더 난해한 구조에 익숙해져야 합니다. 동영상을 Render Media File... 로 간단하게 로딩하여 랜더링하였지만, 실은 이것들이 거저 연결된게 아닌 것입니다. 자, 이제 우리는 동영상을 랜더링하는게 아니라 USB 카메라로부터 받아 들여진 스트림을 랜더링해야 합니다. (USB카메라가 없다면 DShow를 배우기에 아직 준비가 덜 되었다는 의미가 됩니다. 가능하면 USB 카메라를 준비하셔서 그것의 해당 디바이스 드라이버를 설치하시기 바랍니다. )

GraphEdit의 메뉴중에서 New를 눌러서 기존에 있던 필터들의 연결을 제거합니다. '저장하기'라는 옵션이 뜬다면 저장하지 말고 '아니오'를 선택합니다. 이제 GraphEdit의 메인화면이 깨끗해 졌을 것입니다. 여기에서 우리는 카메라에 해당하는 소스필터를 생성해야 합니다. 이러한 필터를 우리는 직접 불러와 줘야 하는데요, GraphEdit상단의 단축버튼 중에서 왼쪽에서 11번째의 버튼을 선택합니다. 마치 네모난 상자에 양쪾으로 조그만 꼭지점이 매달려 있는 듯한 모습을 하고 있는데요, 이것이 바로 현재 사용자의 컴퓨터에 설치되어진 각종 필터들의 나열을 보여줍니다.

이 버튼을 클리하면 윈도우가 하나 뜨면서 그 캡션에 'Which Filters do you want to insert?'이라고 적혀 있을 것입니다. 이곳에서 아무거나 클릭을 하면 바로 GraphEdit의 메인화면에 선택한 필터가 생성되어 집니다. 여기서 모든 카테고리를 살펴보실 필요가 없습니다. 중요한 카테고리를 다음과 같이 정리하였습니다.

* Audio Capture Source --> 오디오를 캡쳐하기 위한 장치(혹은 광의의 필터)들의 모음입니다. 
* Audio Compressors    --> 오디오 스트림을 압축하기 위한 필터들의 모음입니다.  
* Audio Renderers         --> 오디오 스트림을 랜더링하기 위한 필터들의 모음입니다.
* DirectShow Filters        --> 가장 중요한 DirectShow용 필터들의 모음입니다. 이곳에는 다른 카테코리에 포함 되 
                                          어 역할되어지는 필터들도 포함되는데요, 이 사항에 대해서는 아래에서 해설하겠습니다.
*Video Capture Sources  --> 비디오를 캡쳐하기 위한 장치(혹은 광의의 필터)들의 모음입니다. 
*Video Compressors        --> 비디오 스트림을 압축하기 위한 필터들의 모음입니다. 

위에서 조금 깊숙히 들어가야할 필요성이 있다고 봅니다. DirectShow Filters의 카테고리에는 온갖 잡다한 필터들이 모두 포함되게 됩니다. 이곳에는 소스필터, 파서필터는 물론 비디오, 오디오 압축과 DeCoder필터들까지 포함되게 되는데요, 그렇다면 한가지 의문이 들 것입니다. 아니 엄연히 카테고리가 별도로 있는데, 어째서 DirectShow Filters라는 카테고리에는 이렇듯 다양한 필터들이 들어가 있는 것이지? 그렇다면 뭣 때문에 처음부터 카테고리를 나눠 놓은 것인가라고... 

이 질문에 대한 해답은 이렇습니다. 처음에 말씀 드렸다시피 DirectShow는 DirectX가 나오고 나서 한참 후에나 나온 존재입니다. 그 이전에 동영상 관련 프로그램을 하기 위해서는 VFW라는 API를 지원하였고요, 그것에 맞는 각각의 장치들이 존재하였던 것입니다. (아니, 엄밀히 말하면 장치 드라이버가 먼저 제공되었고 나중에 그것을 제어할 수 있는 VFW라는 API가 지원되었다라고 해야 맞을 것 같습니다.) 

여기에 나중에 DirectShow가 탄생하면서 기존의 구조를 흡수하는 방식을 취했습니다만 그것은 완전한 방식이 될수가 없었습니다. 왜냐하면 여러분도 보시다시피 DShow라는 놈이 참으로 유별나며 COM계열중에서도 그 독특성이 유별난 놈이기 때문입니다.
(사실은 DShow가 독특해서 완전한 합병을 할수가 없었다라는 표현은 정확한게 아닙니다만 DShow의 유별난점을 강조하기 위해 한 말입니다. 보다 사실적으로 말씀드리자면 기존의 VFW적인 방식은 Class방식이 아닌 라이브러리(dll) 적인 구조를 가지고 있었기 때문에 어쩔수가 없었다라고 보시면 될것 같습니다. 하지만 그럼에도 불구하고 DShow의 유별난 COM구조가 이렇게 중복 병합되는 카테고리 구조를 유발시켰다라고도 볼수가 있을 것입니다.)

아무튼 그래서 위에서 말씀드린 각각의 카테고리는 예전 VFW의 방식으로서 존재하는 것들입니다. 자, 한가지 예를 들어 봅니다. 위의 카테고리에는 Video Compressors라는 것이 있습니다. 이곳을 들여다보면 각종 압축 코덱들이 모여 있는 것을 보실 수가 있습니다.
그런데 다시 DirectShow Filters라는 카테고리를 들여다보면 여기에도 압축 코덱들이 한두개 눈에 보이실 수도 있습니다. ( 현재까지는 한개도 보이지 않을 수도 있습니다. 그러나 DirectShow관련 코덱들을 한두개 설치하다보면 어느새 이곳에도 압축코덱필터가 자리잡고 있는게 보이실 것입니다.) 자, 이 두개의 코덱의  성격은 어떤 점에서 다른 것일까요? 

예전에 저는 XVid의 소스를 해석한 적이 있었습니다. 여기서 저는 XVid라는 코덱의 소스가 실은 두가지로 되어 있는것을 보고 놀라기도 하였습니다. 그것은 내부에 하나의 완성적인 압축 로직이 있고, 이것을 DirectShow 필터 구조가 감싸고 있는 구조였기 때문입니다. 즉, 예전의 VFW 코덱의 구조를 안에 두고 그것을 다시 DirectShow 필터의 클래스 구조가 감싸안으면서 버퍼의 포인터만 연결되어져 있다는 점이었습니다. 

자, 이제 결론지어 보겠습니다. 위에서 보여드린 각각의 카테고리는 예전 VFW 방식의 분류를 의미합니다. 따라서 과거처럼 VFW의 API를 사용해서 완전히 동일하게 접근할 수가 있음을 의미합니다. 그러나 VFW방식으로는 결코 DirectShow Filters라는 카테고리에 속한 영역의 필터들에 접근할 수가 없습니다. 이들 필터들은 오직 DShow방식의 연결로서 사용되어 집니다. 또한 DShow방식은 과거 VFW 방식의 모든 카테고리에 접근하여 DShow방식으로 취급할 수  있는 서비스를 제공합니다. 이것이 바로 DShow(DirectShow) 이고, 차이입니다. 

만일 누군가가 VFW구조로 압축코덱을 개발하였다면 그는 오직 Video Compressors 카테고리에 설치할 수밖에 없습니다. 반대로 그가 DShow방식으로 압축코덱을 개발하였다면 그는 DirectShow Fitlers라는 카테고리에 코덱을 설치해야 할 것입니다. 하지만 DShow는 이 두가지 구조의 코덱을 동일한 방식으로(DShow적인 방식으로) 생성하여 실행시킬 수가 있습니다. (가물가물 한데요, DShow방식으로 압축 코덱을 개발하였다고 하더라도 Video Compressors 카테고리에 설치할 수가 있었는지... 가물가물하네요. 하지만 한가지 확실한 것은 그 반대는 안된다는 것입니다.)