GStreamer의 클럭과 동기화
복잡한 미디어를 재생할 때 각 오디오 및 비디오 샘플은 특정 시간에 특정 순서로 재생되어야 함. 이를 위해 GStreamer는 동기화 메커니즘을 제공함.
GStreamer는 다음과 같은 사용 사례를 지원함:
- 비실시간 소스: 파일에서 미디어를 읽고 동기화된 방식으로 재생하는 경우. 이때 오디오, 비디오, 자막 등 여러 스트림을 동기화해야 함.
- 라이브 소스에서의 캡처 및 동기화된 멀티플렉싱/믹싱: 마이크나 카메라에서 오디오와 비디오를 캡처하고 이를 파일로 멀티플렉싱하는 경우.
- 네트워크 스트리밍(버퍼링): HTTP를 사용해 스트리밍 서버에서 콘텐츠를 접근하는 경우.
- 라이브 소스에서 캡처 및 지연 시간 조정된 재생: 예를 들어 카메라에서 캡처하고 효과를 적용하여 결과를 표시하는 경우.
- 미리 녹음된 콘텐츠로부터의 동시 라이브 캡처 및 재생: 이전에 녹음된 오디오를 재생하면서 새로운 샘플을 녹음하는 경우.
GStreamer는 GstClock 객체, 버퍼 타임스탬프, SEGMENT 이벤트를 사용하여 파이프라인 내의 스트림을 동기화함.
클럭 실행 시간
컴퓨터에는 여러 시간 소스가 있음(예: 시스템 시간, 사운드 카드, CPU 성능 카운터 등). GStreamer는 이러한 여러 시간 소스를 위한 GstClock 구현을 제공함. 클럭 시간은 0부터 시작할 필요는 없으며, 일부 클럭은 특정 시작 날짜나 마지막 재부팅 시점부터 카운트하기 시작함.
GstClock은 gst_clock_get_time()을 사용하여 해당 클럭에 따른 절대 시간을 반환함. 절대 시간은 계속해서 증가함.
실행 시간(running-time)은 이전의 절대 시간 스냅샷인 base-time과 다른 절대 시간 간의 차이임
GstPipeline 객체는 PLAYING 상태로 갈 때 GstClock 객체와 base-time을 유지함. 이 클럭은 파이프라인 내의 모든 요소와 공유되어, 파이프라인의 실행 시간에 맞춰 동기화가 가능함.
버퍼 실행 시간
버퍼 실행 시간을 계산하려면, 해당 버퍼의 타임스탬프와 그 전에 발생한 SEGMENT 이벤트가 필요함. SEGMENT 이벤트를 GstSegment 객체로 변환한 후, gst_segment_to_running_time() 함수를 사용하여 버퍼의 실행 시간을 계산함.
버퍼의 실행 시간이 클럭 시간과 일치하도록 동기화하는 작업은 주로 싱크 요소에서 수행됨. 이 요소들은 파이프라인의 지연 시간을 고려하여 버퍼 실행 시간에 더하고 동기화 작업을 수행함.
버퍼 스트림 시간
버퍼 스트림 시간은 미디어의 총 길이 내에서 0과 총 길이 사이의 값으로, 버퍼 타임스탬프와 그 전에 발생한 SEGMENT 이벤트를 기반으로 계산됨.
버퍼 스트림 시간은 다음에서 사용됨:
- 현재 스트림 위치를 보고하는
POSITION 쿼리. - 탐색 이벤트 및 쿼리에서 사용되는 위치.
- 제어 값 동기화에서 사용되는 위치.
버퍼 스트림 시간은 스트림 간 동기화에 사용되지 않음. 스트림 동기화는 실행 시간을 기반으로 함.
시간 개요
여기서는 GStreamer에서 사용하는 다양한 타임라인에 대한 개요를 다룸. 아래 그림은 100ms 샘플을 재생하고 50ms에서 100ms까지의 구간을 반복하는 경우의 타임라인을 나타냄.
GStreamer 클럭과 다양한 시간
버퍼의 실행 시간은 항상 클럭 시간과 함께 증가하며, 버퍼는 실행 시간이 클럭 시간에서 base-time을 뺀 값과 같을 때 재생됨. 스트림 시간은 스트림 내의 위치를 나타내며 반복 시 뒤로 돌아감.
클럭 제공자
클럭 제공자는 파이프라인에서 GstClock 객체를 제공할 수 있는 요소임. 이 객체는 PLAYING 상태일 때 절대 시간이 증가하는 값을 제공해야 하며, PAUSED 상태에서는 클럭을 일시 중지할 수 있음.
클럭 제공자는 미디어를 일정한 비율로 재생하는 요소로, 이 비율은 시스템 클럭 비율과 반드시 일치하지 않음. 예를 들어, 사운드 카드가 44.1kHz로 재생하더라도, 시스템 클럭에서 1초가 지난 후 사운드 카드가 정확히 44100 샘플을 재생했다고 보장할 수 없음. 실제로 오디오 장치는 재생된 샘플 수를 기준으로 한 내부 클럭을 사용함.
파이프라인이 PLAYING 상태로 전환될 때, 모든 요소는 자신이 클럭을 제공할 수 있는지 확인함. 파이프라인에서 클럭을 제공할 수 있는 마지막 요소가 클럭 제공자가 됨.
지연 시간 (Latency)
지연 시간은 타임스탬프 X에서 캡처된 샘플이 싱크로 도달하는 데 걸리는 시간임. 이 시간은 파이프라인 내의 클럭을 기준으로 측정됨. 라이브 소스가 있는 파이프라인에서는 지연 시간이 발생할 수 있음. 예를 들어, 오디오 소스가 처음 샘플을 캡처할 때 타임스탬프가 0이고, 클럭 시간은 1초 이상이 될 경우, 싱크는 이 버퍼를 늦어서 드롭함. 이를 해결하기 위해 싱크에서 지연 시간 보상 기능을 사용해야 함.
지연 시간 보상
파이프라인이 PLAYING 상태로 전환되기 전에, 파이프라인은 LATENCY 쿼리를 통해 각 싱크의 지연 시간을 계산하고, 가장 큰 지연 시간을 선택하여 LATENCY 이벤트로 설정함. 이를 통해 모든 싱크는 동일한 지연 시간만큼 재생이 지연되므로 동기화됨.
동적 지연 시간
파이프라인에 요소를 추가하거나 제거하거나 요소 속성을 변경하면 파이프라인의 지연 시간이 변경될 수 있음. 요소는 지연 시간 변경을 요청할 수 있으며, 이때 애플리케이션은 새 지연 시간을 쿼리하고 재분배할지 결정할 수 있음. 지연 시간 변경은 시각적 또는 청각적인 결함을 일으킬 수 있으므로, 애플리케이션에서 허용되는 경우에만 수행해야 함.
버퍼링
버퍼링의 목적은 파이프라인에서 충분한 데이터를 축적하여 중단 없이 매끄럽게 재생될 수 있도록 하는 것이다. 일반적으로 (느린) 네트워크 소스에서 데이터를 읽을 때 사용되며, 라이브 소스에도 사용할 수 있다.
GStreamer는 다음과 같은 용도를 지원한다:
- 데이터를 재생하기 전에 메모리에서 일정량의 데이터를 버퍼링하여 네트워크 변동을 최소화한다. (스트림 버퍼링 참조)
- 네트워크 파일을 로컬 디스크에 다운로드하고 다운로드된 데이터에서 빠르게 탐색한다. (다운로드 버퍼링 참조)
- (세미) 라이브 스트림을 로컬 디스크에 링 버퍼로 캐싱하여 캐시된 영역에서 탐색할 수 있게 한다. (타임시프트 버퍼링 참조)
GStreamer는 애플리케이션에 현재 버퍼링 상태에 대한 진행 상황을 보고하고, 애플리케이션이 어떻게 버퍼링할지와 언제 버퍼링을 멈출지 결정할 수 있게 한다.
가장 간단한 경우, 애플리케이션은 버스에서 BUFFERING 메시지를 듣는다. BUFFERING 메시지 내의 백분율 지표가 100 미만이면 파이프라인이 버퍼링 중이다. 100% 메시지를 받으면 버퍼링이 완료된다. 버퍼링 상태에서 애플리케이션은 파이프라인을 PAUSED 상태로 유지하고, 버퍼링이 완료되면 다시 PLAYING 상태로 전환할 수 있다.
스트림 버퍼링
이 경우, 우리는 느린 네트워크 소스에서 데이터를 읽어 queue2 같은 버퍼링 요소에 전달한다.
버퍼링 요소는 바이트 단위로 낮은 경고선과 높은 경고선(워터마크)을 설정한다. 버퍼링 요소는 다음과 같이 워터마크를 사용한다:
- 높은 워터마크가 도달하면
BUFFERING 메시지로 100%를 표시하고, 애플리케이션에 재생을 계속하라고 지시한다. - 재생 중에 낮은 워터마크에 도달하면 다시
BUFFERING 메시지를 보내어 파이프라인을 일시 정지시킨다. 이를 재버퍼링 단계라고 한다. - 재생 중에, 큐의 수준은 높은 워터마크와 낮은 워터마크 사이에서 변동하면서 네트워크 불규칙성을 보상한다.
다운로드 버퍼링
서버가 고정 길이 파일을 스트리밍할 때, 애플리케이션은 파일 전체를 로컬에 다운로드할 수 있다. 버퍼링 요소는 다운로드된 파일에서 탐색할 수 있도록 push 또는 pull 방식의 srcpad를 제공한다.
타임시프트 버퍼링
이 모드에서는 서버 콘텐츠를 다운로드할 수 있는 고정 크기 링버퍼를 유지하여 캐시된 데이터에서 탐색할 수 있게 한다.
라이브 버퍼링
라이브 파이프라인에서는 캡처와 재생 요소 간에 고정된 지연 시간이 도입된다. 이 지연 시간은 queue(예: jitterbuffer)나 다른 방법(오디오 싱크)에 의해 발생할 수 있다. 버퍼링 메시지는 이 지연 버퍼링을 사용자에게 알리기 위해 방출된다.
버퍼링 전략
여기서는 BUFFERING 메시지와 BUFFERING 쿼리를 기반으로 구현할 수 있는 몇 가지 버퍼링 전략을 소개한다.
No-rebuffer 전략
이 전략은 파이프라인에서 데이터를 충분히 버퍼링하여 재생이 중단 없이 계속되도록 하는 것이다. 필요한 것은 파일의 총 남은 재생 시간과 총 남은 다운로드 시간이다. 버퍼링 시간이 재생 시간보다 짧다면, 중단 없이 재생을 시작할 수 있다.
동적 제어 가능한 매개변수
동적 제어 가능한 매개변수
시작하기
GStreamer 속성은 일반적으로 g_object_set()을 사용하여 설정되지만, 이러한 호출을 신뢰성 있게 타이밍을 맞추는 것은 불가능에 가깝다. 제어기 시스템은 스트림 시간에 맞춰 GObject 속성을 조정하는 간단한 방법을 제공한다.
제어기는 시간을 고려하여 작동하며, 제어 소스(GstControlSources)를 속성에 바인딩하여 이를 수행한다. 제어 소스는 보통 0.0에서 1.0 범위의 값을 제공하며, 제어 바인딩은 제어 값을 GObject 속성에 매핑하여 값을 변환하고 스케일링한다. 실행 중에는 요소들이 현재 스트림 시간에 맞춰 GObject 속성을 업데이트하기 위해 지속적으로 값 변화를 가져온다. GStreamer는 여러 가지 GstControlSources와 제어 바인딩을 제공하지만, 애플리케이션에서 직접 이를 확장하여 정의할 수 있다.
제어 메커니즘의 대부분은 GstObject에 구현되어 있으며, GstControlSources와 제어 바인딩의 기본 클래스는 코어 라이브러리에 포함되어 있지만, 기존 구현은 gstcontroller 라이브러리에 포함되어 있다.
적절한 헤더를 포함하는 것 외에도, 애플리케이션은 gstreamer-controller 공유 라이브러리를 링크해야 한다.
GstControlSource를 GObject 속성에 연결해야 한다. 이는 제어 바인딩을 사용하여 이루어진다. 하나의 제어 소스는 여러 개의 속성에 연결할 수 있다 (다른 객체의 속성에도 연결 가능).
스레드
GStreamer는 본질적으로 멀티 스레드 시스템이고, 완전히 스레드 안전함. 대부분의 내부 스레딩은 애플리케이션에서 숨겨져 있어서 애플리케이션 개발을 더 쉽게 만듦. 그러나 일부 경우에는 애플리케이션이 파이프라인의 일부에서 여러 스레드를 강제로 사용하는 등의 영향을 미칠 수 있음. GStreamer는 애플리케이션이 파이프라인의 일부에서 스레드를 강제로 사용할 수 있도록 허용함.
GStreamer에서의 스케줄링
각 요소는 어떻게 스케줄링될지를 결정함. 요소는 패드를 푸시 기반 또는 풀 기반으로 스케줄링할 수 있음. 예를 들어, 요소는 스레드를 시작해서 싱크 패드에서 데이터를 풀링하거나 소스 패드에서 푸시를 시작할 수 있음. GStreamer는 요소가 스케줄링되는 방식에 대해 어떤 제한도 두지 않음.
스레딩을 시작하는 요소들은 "스트리밍 스레드"라 불리는 스레드를 시작함. 스트리밍 스레드는 GstTask 객체로, 요소가 스트리밍 스레드를 만들 필요가 있을 때 GstTaskPool에서 생성됨.
GStreamer에서 스레드 구성하기
GStreamer는 스레드 상태를 알려주는 STREAM_STATUS 메시지를 버스에 전송함. 이 메시지는 스레드 생성 시, 스레드에 할당할 커스텀 GstTaskPool을 구성할 수 있는 정보를 제공함.
스레드를 생성할 때마다 GST_STREAM_STATUS_TYPE_CREATE 유형으로 알림을 받음. 이 때 GstTaskPool을 구성할 수 있으며, 커스텀 스레드 풀을 사용하여 스트리밍 스레드를 구현함.
스레드 우선순위 올리기
간단한 파이프라인에서 fakesrc 요소가 스트리밍 스레드를 시작하고 데이터를 fakesink로 푸시함. 스트리밍 스레드의 우선순위를 변경하려면, STREAM_STATUS 메시지를 처리하여 해당 스레드의 우선순위를 높일 수 있음.
우선순위가 높은 스레드 만들기
GStreamer에서 스레드를 강제로 사용할 수 있는 방법 중 하나는 queue 요소를 사용하는 것임. queue 요소는 스레드 경계를 설정하며, 이를 통해 파이프라인에서 두 개의 독립적인 스레드를 사용할 수 있음. queue는 기본적으로 데이터를 처리하는 스레드를 분리하고 버퍼로서 기능할 수 있음.
이와 같은 방식으로, GStreamer는 스레드 간의 데이터 흐름을 안전하게 처리하며, 다양한 데이터 버퍼링과 동기화 문제를 해결할 수 있음.
자동 플러깅 Autoplugging
이전의 첫 번째 애플리케이션에서는 Ogg/Vorbis 파일을 위한 간단한 미디어 플레이어를 만드는 방법을 배웠음. 하지만 이제는 스트림의 미디어 유형을 자동으로 감지하고 시스템에서 사용 가능한 모든 요소를 통해 최적의 파이프라인을 자동으로 생성하는 애플리케이션을 만들고 싶을 것임. 이 과정은 "자동 플러깅"이라고 하며, GStreamer에는 고품질의 자동 플러그거들이 있음. 자동 플러거를 찾고 있다면 Playback Components로 바로 넘어가면 됨. 이 장에서는 자동 플러깅과 유형 찾기(typefinding)의 개념을 설명하고, GStreamer가 어떻게 미디어 스트림의 유형을 동적으로 감지하고 이를 바탕으로 파이프라인을 생성하는지 설명함. 이 원칙들은 트랜스코딩에도 사용할 수 있음. GStreamer는 이 개념의 완전한 동적 특성 덕분에, 새로운 미디어 유형을 지원하기 위해 자동 플러거를 수정할 필요 없이 자동으로 확장할 수 있음.
미디어 유형을 통한 스트림 식별
우리는 이전에 미디어 유형을 식별하는 방법으로 캡슐화된 개념을 소개했음. 대부분의 컨테이너 포맷(예: Ogg)은 스트림을 설명하는데 속성이 필요하지 않으며, 미디어 유형만 필요함. GStreamer는 이 미디어 유형을 통해 스트림을 자동으로 식별함. 예를 들어 Ogg와 같은 미디어 유형이 각 패드에 연결될 때, GStreamer는 이들 패드가 예상하는 데이터 유형을 알고 있음. 이렇게 하면 GStreamer는 미디어 스트림을 자동으로 감지하고 적합한 파이프라인을 구성할 수 있음.
미디어 스트림 유형 감지
미디어 스트림을 로드할 때, 그 스트림의 유형이 바로 알려지지 않음. 즉, 파이프라인을 선택하기 전에 먼저 스트림 유형을 감지해야 함. GStreamer는 이를 "유형 찾기"라는 개념을 사용함. 유형 찾기는 파이프라인의 정상적인 일부로, 스트림 유형이 알려질 때까지 데이터를 읽음. 이 동안, GStreamer는 해당 스트림을 인식할 수 있는 모든 플러그인에게 데이터를 제공함. 하나의 타입 파인더가 스트림을 인식하면, 해당 타입을 감지한 후, 타입 파인더는 신호를 방출하고 그 이후에는 패스스루 모듈로 작동함. 만약 유형을 찾지 못하면, 오류가 발생하고 더 이상 미디어 처리가 진행되지 않음.
유형을 찾은 후, 애플리케이션은 이를 바탕으로 미디어 스트림을 디코딩할 파이프라인을 자동으로 설정할 수 있음.
플러그인에서의 타입 파인더 기능 구현
GStreamer에서 플러그인은 타입 파인더 기능을 구현할 수 있음. 플러그인 구현 시, 해당 미디어 유형에 대해 미디어 유형을 제출하고, 일반적으로 사용되는 파일 확장자 및 타입 찾기 함수도 정의함. 해당 함수가 호출되면, 플러그인은 이 미디어 스트림이 특정 패턴을 따르는지 확인하고, 이를 인식할 경우 타입 파인더에게 알려줌.
파이프라인 조작
이 장에서는 애플리케이션에서 파이프라인을 조작하는 다양한 방법을 소개함. 다룰 내용은 다음과 같음:
- 애플리케이션에서 데이터를 파이프라인에 삽입하는 방법
- 파이프라인에서 데이터를 읽는 방법
- 파이프라인의 속도, 길이, 시작 지점을 조작하는 방법
- 파이프라인의 데이터 처리 과정을 듣는 방법
이 장의 일부는 매우 저수준이므로, 이를 따라가려면 프로그래밍 경험과 GStreamer에 대한 깊은 이해가 필요함.
프로브 사용
프로빙은 패드 리스너에 접근하는 것처럼 이해할 수 있음. 기술적으로, 프로브는 gst_pad_add_probe()를 사용하여 패드에 부착할 수 있는 콜백 함수임. 반대로, gst_pad_remove_probe()를 사용하여 콜백을 제거할 수 있음. 프로브가 부착된 동안 패드에서 발생하는 활동을 알려줌. 프로브를 추가할 때 어떤 알림을 받을지 정의할 수 있음.
프로브 유형:
- 버퍼가 푸시되거나 풀림: GST_PAD_PROBE_TYPE_BUFFER를 지정. 패드가 푸시 또는 풀 방식으로 예약될 수 있음.
- 버퍼 리스트 푸시: GST_PAD_PROBE_TYPE_BUFFER_LIST를 사용.
- 이벤트가 패드를 통해 이동: GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM, GST_PAD_PROBE_TYPE_EVENT_UPSTREAM 등을 사용.
- 쿼리가 패드를 통해 이동: GST_PAD_PROBE_TYPE_QUERY_DOWNSTREAM, GST_PAD_PROBE_TYPE_QUERY_UPSTREAM 등을 사용.
데이터 프로브
데이터 프로브는 패드를 통해 데이터가 흐를 때 알림을 받음. GST_PAD_PROBE_TYPE_BUFFER와 GST_PAD_PROBE_TYPE_BUFFER_LIST를 사용하여 이런 종류의 프로브를 생성할 수 있음.
데이터 수정
데이터 수정이 필요하다면 GStreamer 요소를 직접 작성하는 것이 더 적합함. GstAudioFilter, GstVideoFilter, GstBaseTransform 등의 기본 클래스를 사용하면 쉽게 작성할 수 있음.
미디어 파일의 특정 구간 재생
이 예제에서는 미디어 파일의 2초에서 5초 구간만 재생하고 종료하는 방법을 보여줌. uridecodebin을 사용하여 파이프라인을 설정하고, 해당 구간으로의 시킹을 수행함.
데이터 삽입 및 추출
자체 소스를 사용해 데이터를 삽입하거나, 파이프라인의 출력을 추출하려는 경우 appsrc와 appsink를 사용할 수 있음. 이 방법들은 기본 클래스 지원 없이 동기화 및 상태 변경을 철저히 이해하고 있어야 함.
appsrc를 사용한 데이터 삽입
appsrc는 푸시 또는 풀 모드에서 데이터를 파이프라인에 삽입할 수 있게 해줌. 앱이 데이터를 삽입하는 방법은 gst_app_src_push_buffer() 함수나 "push-buffer" 액션 신호를 사용하는 방식임.
appsink를 사용한 데이터 추출
appsink는 파이프라인에서 데이터를 추출하는 더 쉬운 방법임. pull-sample과 pull-preroll 신호를 사용하여 데이터를 추출할 수 있음.
포맷 강제 설정
특정 포맷을 설정하려면 capsfilter 요소를 사용할 수 있음. 예를 들어, 비디오 크기나 오디오 비트 크기 등을 강제할 수 있음.
PLAYING 상태에서 포맷 변경
capsfilter의 caps 속성을 변경하여 PLAYING 상태에서도 포맷을 동적으로 변경할 수 있음.
파이프라인 동적 변경
파이프라인을 동적으로 변경할 때 중요한 사항들을 다룸. 예를 들어, 요소를 제거하거나 추가할 때 데이터 흐름에 영향을 미치지 않도록 해야 함. 또한, 삽입된 요소가 올바르게 상태가 설정되어야 하며, 필요시 알맞은 변환 요소를 삽입해야 함.
파이프라인에서 요소 변경
파이프라인에서 요소를 변경하려면, 먼저 데이터 흐름을 차단하고, EOS 이벤트를 보내 데이터를 비우고, 요소를 교체한 후 다시 연결해야 함.
영상 효과 변경 예시
이 예제에서는 영상 효과를 1초마다 변경하는 방법을 보여줌. videotestsrc와 다양한 비디오 필터를 사용하여 효과를 동적으로 변경함.
4. GStreamer 을 위한 고급 인터페이스
앞서 두 부분에서는 GStreamer 애플리케이션 프로그래밍의 많은 내부 사항과 그에 해당하는 저수준 인터페이스를 배웠음. 하지만 많은 사람들은 그렇게 많은 제어(및 코드)를 원하지 않으며, 대부분의 어려운 내부 처리 작업을 대신해주는 표준 재생 인터페이스를 선호할 것임. 이 장에서는 자동 플러그거, 재생 관리 요소 및 그와 유사한 것들의 개념을 소개함. 이러한 고급 인터페이스들은 GStreamer 기반 애플리케이션 프로그래밍을 단순화하는 데 목적이 있음. 다만, 유연성은 감소시킬 수 있음. 어떤 인터페이스를 사용할지는 애플리케이션 개발자가 선택해야 함.
재생 구성 요소
GStreamer는 애플리케이션 개발자의 작업을 단순화하기 위해 여러 고급 구성 요소를 포함하고 있음. 여기에서 다룬 모든 구성 요소들은 현재 미디어 재생을 목표로 하고 있음. 이러한 각 구성 요소의 목적은 GStreamer 파이프라인과 최대한 밀접하게 통합되도록 하면서, 미디어 유형 탐지 및 고급 GStreamer 개념에서 다룬 여러 복잡한 주제들을 숨기는 것임.
우리는 현재 사람들에게 playbin(Playbin 참조)이나 decodebin(Decodebin 참조)을 필요에 따라 사용하는 것을 권장함. Playbin은 미디어의 간단한 재생과 관련된 모든 것에 추천되는 솔루션임. Decodebin은 더 많은 고급 기능을 추가할 수 있는 더 유연한 자동 플러그거로, 예를 들어 플레이리스트 지원, 오디오 트랙의 크로스페이드 등이 있음. 하지만 그 프로그래밍 인터페이스는 playbin보다 저수준임.
Playbin
Playbin은 표준 GStreamer API(예: gst_element_factory_make())를 사용하여 생성할 수 있는 요소임. 이 팩토리의 이름은 "playbin"임. GstPipeline(따라서 GstElement)이므로 playbin은 자동으로 이 클래스의 모든 기능을 지원함, 여기에는 오류 처리, 태그 지원, 상태 처리, 스트림 위치 가져오기, 탐색 등이 포함됨.
playbin 파이프라인 설정은 playbin 요소의 인스턴스를 생성하고, "uri" 속성에 파일 위치를 설정한 후, 요소를 GST_STATE_PLAYING 상태로 설정하는 것만큼 간단함(위치는 유효한 URI여야 하며, 예: file:///tmp/my.ogg 또는 http://www.example.org/stream.ogg). 내부적으로 playbin은 미디어 위치를 재생하기 위한 파이프라인을 설정함.
