I. GStreamer 소개 : 2장. 설계 원칙

2장. 설계원칙 

2.1. 정확하고 강력함

GStreamer는 하기와 같은 사람을 위해 정확한 인터페이스를 제공합니다.

• 미디어 파이프 라인을 만들기 원하는 애플리케이션 프로그래머. 프로그래머는 한줄의 코드 입력도 없이 대규모의 강력한 도구 집합을 이용해 미디어 파이프 라인을 생성할 수 있습니다. 복잡합 미디어 조작을 상당히 쉽게 만들어 줍니다.
• 플러그인 프로그래머. 플러그인 프로그래머는 자신이 만든 플러그인을 만들기 위해 정확하고 간단한 API를 제공받게 됩니다. 대규머의 디버깅과 추적 메카니즘이 통합되어 있습니다. GStreamer는 플러그인 개발의 예로 사용할 수 있는 대규모의 실제로 동작하는 플러그인의 집합을 가지고 있습니다.  

2.2. 객체 지향적

GStreamer는 GLib2.0의 객체 모델인 GObject를 상속합니다. GLib 2.0이나 GTK+에 익숙한 프로그래머는 GStreamer에도 익숙할 것 입니다.

GStreamer는 시그널과 객체(Object) 프로퍼티 메카니즘을 사용합니다.

모든 객체는 객체의 다양한 프로퍼티와 캐퍼빌리티에다한 쿼리를 실행 시간에 수행할 수 있습니다.

GStreamer는 GTK+와 유사한 개발 방법 제공을 목적으로 하고 있습니다. 이러한 사항이 객체 모델, 객체의 소유, 레퍼런스 카운팅 등에 적용됩니다.

 

2.3. 확장성

모든 GStreamer의 객체는 GObject의 상속 방법을 사용하여 확장할 수 있습니다.

모든 플러그인은 동적으로 로딩이 되며, 확장이나 업그레이드를 독립적을 수행할 수 있습니다.

 

2.4. 바이너리 플러그인 지원

플러그인은 실행 시간에 로딩되는 공유 라이브러리입니다. 모든 플러그인의 프로퍼티가 GObject의 프로퍼티를 사용해 설정할 수 있기 때문에, 플러그인을 위해 헤더파일을 설치할 필요가 없습니다(사실 방법도 없습니다).

자체 포함하는 플러그인을 만들기 위해 특별한 주의가 필요합니다. 플러그인과 연관된 모든 것은 실행시간에 질의를 처리해야 하기 때문입니다.

 

2.5. 높은 성능

높은 성능은 하기의 사항에 의해 얻을 수 있습니다.

• GLib의 GSlice 얼로케이터
• 플러그인간 극단적으로 가벼운 연결. 데이터는 최소한의 오버헤드를 동반하여 파이프 라인으로 전송됩니다. 플러그인 간 데이터를 전송하는 보통의 파이프 라인에서는 데이터 전송에 오직 포인터만이 사용됩니다.
• 타겟 메모리에 직접 작업을 수행할 수 있는 메카니즘 제공. 예를 들어 플러그인은 X 서버의 공유 메모리 공간에 데이터를 직접 쓸 수도 있스빈다. 버퍼는 또한 사운드 카드의 내부 하드웨어 버퍼와 같은 임의의 메모리를 가리킬 수 있습니다.
• memcpy 사용을 최소화하여 레퍼런스 카운팅과 카피 수행. 서브 버퍼는 관리가 가능한 조각으로 효율적으로 나누어집니다.
• 커널에 의해 스케쥴링 되는 전용 스트리밍 스레드
• 특별한 플러그인을 사용하여 하드웨어 가속이 가능
• 플러그인 스펙에 있는 플러그인 레지스트리를 사용하여 플러그인이 사용되는 순간까지 플러그인 로딩 지연 

 

2.6. 확실한 코어와 플러그인 구분

GStreamer의 코어는 핵심적으로 미디어에 얽매이지 않습니다. 코어는 바이트와 비트만을 압니다. 코어는 기본 엘리먼트만 포함하고 있습니다. GStreamer의 코어는 심지어 cp와 같은 저수준의 시스템 툴을 개발하기에 충분한 기능을 가지고 있습니다.

미디어 핸들링을 위한 모든 기능을 코어 외부에 있는 플러그인에 의해 제공됩니다. 이런 플러그인이 코어에게 미디어의 타입에 따른 제어 방법을 알려주게 됩니다.

 

2.7. 코덱 실험을 위한 프레임 워크 제공

GStreamer는 코덱 개발자가 다양한 알고리즘을 실험과 Xiph.Org 파운데이션에서 개발한 Theora와 Vorbis와 같은 오픈/자유 멀티미디어 코덱 개발 시간 단축을 위한 쉬운 프레임 워크가 되길 원하고 있습니다.