_공부하는 개발자_

엘리먼트에서 보았듯이, 패드는 외부와 연결하는 엘리먼트의 인터페이스입니다. 데이터는 한 엘리먼트의 소스 패드에서 다른 엘리먼트의 싱크 패드로 흐릅니다. 엘리먼트가 처리할 수 있는 구체적인 미디어 타입은 패드의 캐퍼빌리티로 노출이 됩니다. 캐퍼빌리티에 관한 자세한 사항은 뒤에 알아보도록 하겠습니다(8.2절 참조).

8.1. 패드

패드 타입은 방향과 유효성 이 두 가지 프로퍼티로 정의됩니다. 이미 언급했듯이 GStreamer는 소스와 싱크 패드로 두 가지 방향으로 정의됩니다. 이 용어는 엘리먼트 내의 관점에서 정의됩니다. 엘리먼트는 싱크 패드로 데이터를 수신하고, 소스 패드를 이용하여 데이터를 생성합니다. 그림으로 싱크 패드는 엘리먼트의 왼쪽에 그립니다. 반면 소스 패드는 오른쪽에 그립니다. 이러한 그래프에서 데이터는 왼쪽에서 오른쪽으로 흐릅니다.

8.1.1. 다이나믹 (썸타임) 패드

어떤 엘리먼트는 엘리먼트가 생성될 때 모든 패드를 가질 필요가 없을 수도 있습니다. 예를 들어 Ogg 디먹서 엘리먼트에서 이런 경우가 발생할 수 있습니다. 엘리먼트는 Ogg 스트림을 읽고, Ogg 스트림에서 엘러먼터리 스트림(vorbis, theora)을 찾게되면, 각각 스트림을 가지는 다이나믹 패드를 생성합니다. 마찬가지로, 스트림이 끝나면 패드를 삭제합니다. 이러한 원칙은 예를 들어 디먹서 엘리먼트에 굉장히 유용합니다.

gst-inspect oggdemux를 실행하면, 엘리먼트가 ‘sink’라고 불리는 싱크 패드 하나를 가지는 것을 확인할 수 있습니다. 다른 패드는 동작을 중단하고 있는 상태입니다. 이런 패드는 경우에 따라 존재하기 때문에(“Exist:Sometimes”) 패드 템플릿에서 확인할 수 있습니다. 재생하는 ogg 파일 타입에 따라, 패드가 생성될 것입니다. 다이나믹 파이프라인을 만들 경우, 이러한 점이 상당히 중요하게 작용할 것입니다. 엘리먼트에 시그널 핸들러를 추가하여 엘리먼트가 섬타임 패드 템플릿으로 새로운 패드를 생성하는 것을 알려주게 할 수 있습니다. 아래의 코드는 그 예를 보여줍니다.

“pad-added” 콜백으로 파이프라인에 엘리먼트를 추가하는 것은 드문 일이 아닙니다. 이렇게 할 때, 새로 추가되는 엘리먼트를 gst_element_set_state ()나 gst_element_sync_state_with_parent () 함수를 사용하여 파이프라인의 목표 상태로 전환해주어야 하는 것을 잊으시면 안됩니다.

8.1.2. 리퀘스트 패드

엘리먼트는 리퀘스트 패드도 가질 수 있습니다. 이런 패드는 자동적으로 생성되지 않습니다. 오직 요청에 의해서만 생성됩니다. 이것은 멀티플렉서(multiplexers), 어그리게이터(aggregators)와 티(tee) 엘리먼트에서 상당히 유용합니다. 어그리게이터는 여러 입력 스트림 내용을 합쳐 하나의 출력 스트림으로 내보내는 엘리먼트입니다. 티 엘리먼트는 이와 반대로 작용합니다. 하나의 입력 스트림을 복사하여 각각의 출력 패드로 내보냅니다. 애플리케이션이 스트림의 복사가 필요할 때마다, 간단하게 티 엘리먼트에 새로운 출력 패드를 요청하면 됩니다.

아래의 코드는 티 엘리먼트에서 새로운 출력 패드를 요청하는 방법을 보여줍니다.

gst_element_get_request_pad ()는 패드 템플릿의 이름을 기초로 하여 엘리먼트에서 패드를 가져오는데 사용할 수 있습니다. 다른 패드 템플릿과 호환되는 패드를 요청하는 것도 가능합니다. 멀티플렉서 엘리먼트와 연결을 원하고, 호환 가능한 패드를 요청해야 하는 경우, 이러한 기능은 상당히 유용합니다. 위의 두 번째 코드에서, gst_ element_ get_ compatible _pad ()를 사용하면 호환성 있는 패드를 가져올 수 있습니다. 코드에서 입력과 상관없이 Ogg 멀티플렉서에서 호환 패드를 요청합니다.