Slow walking man

원래는 한 포스트로 다 쓸려고 했는데, 쓰다보니 너무 길어지고 continueAfterSetup에서 설명해야 할 것들이 너무 많아지는 감이 있어서 포스트를 두개로 나누었다. 아는 것도 어렵지만 아는 것을 글로 남기는 것은 전혀 또 다른 문제인 것 같다. ㅎㅎ

그럼 RTSP서비스로부터 SDP를 받고 이로부터 각 SubMediaSession에대해 setup명령을 전송하는 과정까지 설명했던 지난 포스트에 이어서 이번 포스트에서는 이 이후 단계인 continueAfterSetup부터 살펴보자.

continueAfterSetup은 RTSP서버로 SETUP명령을 보내는 sendSetupCommand 함수가 호출 된 후 서버로부터 처리 완료 신호가 클라이언트 단으로 도착했을 때 실행되는 콜백함수로 sendSetupCommand함수의 인자로 전달되었었다. 여튼 setup이 완료되어서 미디어 데이터를 전달받을 환경이 조성되어 실행되는 continueAfterSetup은 아래와 같다.

역시 잘 안보이지만 눈을 크게 뜨고 보자.. =_=

콜백으로 전달되는 함수들은 모두 static이기 때문에 인자로 전달되는 rtspClient 포인터로부터 이 함수가 어떤 rtspClient의 콜백으로 호출되었는지 밝히는 부분이 함수 첫 281 ~ 287에 나와있다. 이건 뭐 그다지 중요한 내용은 아니고 중요한 내용은 297로부터 시작된다.

사실 297이 이 전체 샘플코드의 핵심이다.

이 코드를 이용해서 전체 샘플코드가 사용할 파이프라인을 구성하고 있기 때문이다.

297줄에 보면 DummySink 인스턴스를 하나 만들고 subsession이 가지고 있는 sink에 할당한다.

이 과정을 통해 이DummySink가 subsession에 연결되어

"subSession (Source를 포함하는 객체) - DummySink"

구조의 파이프라인이 구축된다. 그리고 나서 306줄과 같이 startPlaying함수를 통해 파이프라인이 동작하도록 명령한다. 단, 이 playing이라는 의미는 파이프라인이 활성화 상태로 들어가게 한다는 의미이지 실제로 미디어 서버쪽에 미디어를 재생하라는 RTSP의 PLAY신호를 보낸다는 의미는 아니다.

실제 PLAY신호는 모든 Subsession들에 대해서 setup이 완료 되고 난 이후에 sendPlayCommand라는 함수에 의해서 RTSP서버쪽에 전달되어 실제 데이터 전송을 요청하게 된다.

==추후 갱신==

Live555에 보면 RTSP스트림을 받을 수 있는 소스코드를 이미 제공하고 있다.

하나는 openRTSP.c이고 다른하나는 testRTSPClinet.c라는 소스코드이다.

openRTSP는 RTSP규약을 전부다 구현해 놓은 Client 프로그램으로 재생 정지 되감기 등의 RTSP기능을 가지고 있다. 즉, 좀 보기 복잡하다.. ㅎㅎ 반면에 testRTSPClient는 RTSP스트림을 받는 것만 구현이 되어 있어서 기능은 그닥 뭐 볼건 없지만, Live555가 제공하고 있는 파이프라인 구조라든지 RTSP client와 server간의 동작을 간단히 살펴 보는데는 더할 나위 없이 좋다. 

무엇보다도 내가 만들고자 했던 프로그램은 항상 Live영상만 H.264로 전달하는 IP Camera의 RTSP서비스를 활용하기 때문에 다양한 RTSP규약의 기능을 별로 알필요가 없어 구지 어려운 소스코드를 볼 필요가 없었다. =_=

어쨋든 이번 포스트에서는 testRTSPClient를 대상으로 해서 어떻게 RTSP서비스로부터 데이터를 수신할 것인지, 그리고 어떻게 파이프라인을 구성해서 활용하고 있는지를 살펴볼 것이다.

먼저 main부터 살펴보자

이미지로 찍어 올렸더니 잘 안보인다.

소스코드는 testRTSPClient.c에 들어가 있기 때문에 그 소스코드를 열어 보시면 좋겠다.

어찌됐든 위 부분이 console타입의 testRTSPClient프로그램의 도입부인 main함수이다.

생각외로 매우 조촐하다.

보이는 함수도 별로 없고 심지어는 지역변수도  별로 없다.

Main함수가 이토록 조촐한 이유는 Live555가 MFC의 메시지 드리븐 방식과 비슷하게 동작하기 때문이다.

(메시지 드리븐이라는 말은 큐에 메시지가 들어가고, 각 메시지가 발생한 순서대로 처리되는 방식을 의미한다.)

Live555에서는 이런 메시지 드리븐 방식의 동작구조를 TaskScheduler가 제공하고 있으며, main초반부에 보면 TaskScheduler를 생성하여 사용하고 잇는 것을 볼 수 있다. 아울러 그 다음에 생성된 UsageEnvironment는 이전 포스트에서 설명 했듯이, OS와 Live555의 기능 사이에서 소켓등 OS에 종속된 기능들을 추상화 하여 Live555에 제공하는 역할을 한다. 이 클래스 때문에 Live555함수의 기능들은 OS 따라 함수코드를 바꿀 필요 없이, UsageEnvironment만 바라보고 소스코드의 일관성을 유지 할 수 있다. 실제로 OS에 따라 바뀌는 것은 UsageEnvironment이다.

(OS에 따라 UsageEnvironment를 상속하여 적합한 UsageEnvironment를 제공해야 하며 Windows, Linux에서는 BasicUsageEnvironment를 사용하면 된다.) 

어쨋든 main에서는 이제 프로그램의 아규먼트로 입력받은 RTSP URL를 인자로 하여 openURL함수를 호출한다.

그리고서는 메시지 큐가 정상적으로 동작을 시작하도록 taskScheduler의 doEventLoop를 실행한다.

이 doEventLoop는 글로벌 변수로 어떤 변수를 받는데, 이 글로벌 변수가 0이 아닌 값이 들어가면, 이벤트 루프를 종료하고 return 0; 문으로 넘어가 프로그램이 종료되게 한다.

그럼 이제 RTSP URL로 뭘하는지 실제 OpenURL 함수의 구조를 살펴보자.

openURL함수는 아래와 같다.

역시 이미지로 올렸더니 흐릿하니 잘 안보인다. testRTSPClient.c를 확인하시라.. =_=

openURL에서는 ourRTSPClient를 하나 생성해서 해당 URL로 대표되는 RTSP서비스를 처리하도록 하고 있다.

그 다음에 sendDescribeCommand를 이용해 RTSP서버로 DESCRIBE명령을 전송한다. sendDescribeCommand의 인자로 주어진 continueAfterDESCRIBE는 콜백함수 포인터로, 서버로 보낸 DESCRIBE명령에 대한 응답이 돌아왔을 때 호출될 콜백함수의 포인터이다.

RTSP서비스를 제공하는 RTSP서버에 DESCRIBE명령을 전송하면 RTSP서버는 클라이언트로 SDP ( Simple Description Protocol ) 문서를 전달한다. 문서라고 하니까 무슨 파일로 되어 있는 그런걸 떠올릴 수 있는데 파일은 아니고 단순히 어떤 문자열에 불과하다. 이 SDP문자열에는 해당 RTSP서비스가 제공하고 있는 미디어스트림의 종류 등 정보가 들어가 있다.

예를 들자면.. 아래와 같은 SDP는 오디오, 비디오 2종류의 미디어를 제공하고 있다는 의미이다..

m=audio 49170 RTP/AVP 0 8 97

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:97 iLBC/8000

m=video 51372 RTP/AVP 31

a=rtpmap:31 H261/90000

특히 "m=audio", audio미디어를 49170포트로 Realtime Transport Protocol / Audio Video Payloadtype

 에 정의된 0,8,97번 즉, PCMU/8000, PCMA/8000, iLBC/8000으로 제공하고

"m=video", video미디어는 51372포트로 Realtime Transport Protocol / Audio Video Payloadtype 에 정의된 31번

즉, H261/90000으로 제공한다는 의미를 가지고 있다는 의미이다.

물론 이런 정보를 알아내기 위해서 SDP를 공부할 필요는 없다.

Live555에서 SDP를 파싱해서 우리가 이해 가능한 정보로 바꿔주는 기능을 제공해 주니 두려워 않아도 좋다.

그럼 이제 continueAfterDESCRIBE함수에서 어떻게 이 SDP를 처리하고 있는지 살펴보자. 

허허... 그림이 커질수록 점점 더 안보이기 시작하고 있다..=_=

어쨋든 눈을 부릅뜨고 한번 보자. 참고로 이 continueAfterDESCRIBE는 static 함수로 어떤 rtspClient의 DESCRIBE명령로부터 콜백 된 함수인지 모르기 때문에 Live555에서는 함수의 인자로 rtspClient를 전달해준다. 그리고 3번째 인자로 resultString을 건네주는데 이게 SDP 스트링이다.

이걸 SDP를 파싱해서 쓰기 위해서 205줄과 같이 MediaSession을 만든다. 인자로 sdp문자열을 전달하는데 이렇게 되면 자동으로 SDP에 들어있는 미디어 스트림 정보마다 MediaSubsession이 생성되어 MediaSession에 추가된다.

그리고는 221 줄과 같이 각 MediaSubsession에 대해 setup을 시도한다. setup은 각 MediaSubsession이 제공하는 미디어 스트림데이터를 받을 수 있는 서버-클라이언트 간 환경을 조성하는 과정이다. setupNextSubsession( ) 함수는 rtspClient를 인수로 받아 이과정을 수행한다.

참고로 ourRTSPClinet를 살펴보면 아래와 같이 RTSP연결을 의미하는 MediaSession, RTSP연결에서 제공하는 미디어 스트림연결을 의미하는 MediaSubsession, 그리고 각 MediaSubsession을 순회할 수 있는 MediaSubSessionIterator정보가.. 정확히는 이런 정보를 가지고 있는 StreamClientState 인스턴스가 들어가 있다.

자세한 부분은 이 포스트를 전체적으로 한번 읽어보고 중단점을 걸어 한단계씩 넘어가다보면 어떻게 ourRTSPClient가 각 MediaSubSession등의 정보를 저장하고 있는지 알 수 있을 것이다.

자, 그럼 이제 setupNextSubsession에서 어떻게 서버 - 클라이언트간 미디어 스트림 데이터 수신 환경을 구축하고 있는지 살펴보자. 아래는 setupNextSubsession이다.

허허.. 쪼매 길다. 코드가

어쨋든 처음부터 차근차근 살펴보자..

다소 복잡해 보이지만, 전체 적인 코드 구조는 아래와 같다.

    1. 인자로 넘겨받은 rtspClient포인터를 전달받아 ourRTSPClient객체를 찾는다.

    2. ourRTSPClient객체의 StreamClietState멤버로부터 MediaSession이 가진 MediaSubsession을 순회

    3. 각 MediaSubSession에 대해 Initiate를 호출해 초기화한다.

    4. 각 MediaSubSession에 대해 sendSetupCommand명령을 전송한다.

    5. 모든 MediaSubSession에 대해 sendSetupCommand를 전송하고 순회가 완료 (NULL)

    6. sendPlayCommand로 Play Command를 RTSP서버로 전송한다.

이 setupNextSubsession함수는 모든 MediaSubsession을 순회하도록 재귀함수 구조로 되어 있는데, MeidaSubsession이 실패한 경우는 이 함수내에서 직접적으로 setupNextSubsession을 247줄과 같이 호출해서, 성공한 경우는 sendSetupCommand의 인자로 전달한 continueAfterSetup 콜백에서 재귀적으로 다시 호출된다.

Live555는 데이터를 처리하기 위해 데이터 파이프라인 구조를 제공하고 있다.

말이 어렵지만 사실 별거 없다.

파이프라인을 제공한다는 말은 물이 파이프를 따라 흐르듯이 데이터도 어떤 순서에 따라 파이프라인의

각 부분을 통과하게 되고, 각 부분에서 필요한 처리가 이뤄진다는 의미이다.

아울러 물이 파이프라인의 한쪽 방향에서 다른 방향으로만 흐르듯이

Live555에서도 데이터는 항상 한쪽 방향으로만 흐른다.

Live555의 파이프라인 구조는

단순히 데이터를 생산해 내다음 단계로 넘기는 Source,

데이터를 다음 단계로 넘기기도 하지만 받기도 하는 Filter

데이터를 받기만 하는 Sink로

이뤄져 있으며

Source -> Filter -> Filter -> Sink 혹은

Source -> Filter -> Sink 또는

Source -> Sink 와 같이 구성 할 수 있다.

Filter는 데이터를 전달하는 특성이 Source와 동일하기 때문에 클래스 구조상 Filter는 Source를 상속받은

클래스 이고 따라서 Filter에 대한 참조를 Source클래스의 포인터로 해도 무방하다. (다형성)

파이프라인을 구성하면 Sink는 자신의 왼쪽에 있는 Source에 대한 포인터를 가지고 있으며

그 포인터를 이용해 해당 Source의 getNextFrame함수를 호출함으로써

아래와 같이 그 Source에 데이터를 받을 Sink의 버퍼

데이터를 받고나서 실행될 콜백함수의 포인터인 afterGettingFunc

Source가 더이상 데이터를 만들어 내지 않을때 실행될 콜백의 함수포인터인 onCloseFunc등을 전달한다.

<코드가 잘 안보이는 건 기분탓이다. =_=>

그러면 Source에서는 전달받은 정보를 모두 자신의 멤버변수에 저장하고

doGetNextFrame을 통해 실제 데이터를 전달 받는 동작을 수행한다.

doGetNextFrame은 virtual로 선언되어 있는 순수 추상함수인데

그 이유는 이 Live555에서 제공하는 Source의 데이터가 여러 데이터원에 기인하기 때문이다.

H.264데이터도 있고, 263도 있고, 데이터 종류에 따라 데이터를 전달하기 이전에 수행해야 할 동작들이 많이 때문에

아래에 보이는 엄청나게 많은 Source원에서 각각 이 doGetNextFrame()을 override해서 필요한 동작들을 수행한다

<겁나게 많다 하지만 모두 다 알 필요는 없다>

아울러 이 doGetNextFrame에는 자신의 앞쪽에 있는 또다른 Source

로부터 다시 데이터를 수신하는 getNextFrame()을 호출하고 이 과정이 계속 반복되면서

최종적으로 Sink에 데이터가 전달된다.

그리고 각 단위마다 데이터를 전달받고 나서 실행되는 afterGettingFrame함수가 있어서

자신의 앞 블록으로부터 데이터를 받으면, 아래 코드와 같이 afterGettingFunc 콜백함수 포인터를

호출해 다음 블록에 데이터가 왔음을 알리게 된다.

(이 함수포인터는 getNextFrame때 자신의 오른쪽 블록으로부터 넘겨 받았었다.)

사실 이런 사항은 그다지 자세히 할 필요는 없다. =_=

소스코드가 잘 구현되어 있기 때문에 그닥 변경할 필요도 없을 뿐더러, 

LGPL라이선스로 이 코드를 사용하고 싶다면 이 소스코드를 변경해서도 안된다.

다만 이런 사항을 잘 알고 있다면, 자신만의 기능을 가지고 있는

Source나 Filter 혹은 Sink등을 만들어 사용할 때 좀더 도움이 될 수 있을 것 같다.

참고로 필자는 H.264데이터를 디코딩해서 글씨를 씌우고 다시 H.264로 인코딩 한 데이터를 RTPSink에 전달하는

Filter를 만들어서 사용하고 있는데 이런 구조를 이해하는게 썩 많은 도움이 되었다.

Live555는 RTSP 관련 기능을 쉽게 사용 할 수 있도록 도와주는 여러 클래스를 제공하는 오픈소스 라이브러리이다. 단, 이 라이브러리에는 미디어 데이터를 디코딩 하거나 인코딩 하는 기능은 없고, 단순히 수신, 전송과 관련 된 기능을 제공하니 미디어 데이터의 인,디코딩 기능을 이용하고 싶다면, FFmpeg이나 quick sync등의 다른 API를 이용해 해당 기능을 구현해야 한다.

이번 포스트에서는 Live555를 Visual Studio 2010에서 사용 할 수 있도록 빌드하는 과정을 설명할 예정이다.

먼저 빌드에 사용할 소스코드를 Live555에서 다운받아보자.

처음 Live555싸이트에 들어가면 위와 같은 화면이 보이는데 우리가 다운받아야 할 소스코드는 LIVE555 Streaming Media 이부분에 들어가 있다. 왼쪽 부분에 Live555  Media Server는 이 LIVE555 Streaming Media를 기반으로 해서 만들어진 콘솔 프로그램으로 로컬폴더의 파일을 읽어 RTSP로 전송하는 기능을 제공한다.

어쨋든 소스 코드는 Live555 Streaming Media 이 부분에 있으니 클릭해서 들어가보자

소스 코드 단락에 보면 .tar.gz 파일을 받으라고 되어 있는 here 부분을  누르면 소스코드, 샘플용 미디어 파일을 다운 받을 수 있는 링크로 이동한다.

뭐 이런 저런 파일들이 많이 있는데 그냥 live555-latest.tar.gz를 다운 받으면 되겠다. 참고로 Live555는  구버전의 소스코드를 제공하지 않고 가장 최신 버전의 소스코드만 다운 받을 수 있다. 이유는 모르겠다. 그냥 live555에서 그런다고 한다. 어차피 Live555의 LGPL라이선스 때문에 이 라이브러리를 활용하는 제품은 항상 최신버전의 Live555를 제공해야 하는 필요성도 있고하니.. 그냥 일단 최신버전의 소스코드를 다운 받자.

다운을 받아 소스코드를 압축 해제해 보면 소스폴더와 이런저런 파일들이 있다. make파일을 생성해 주는 bat파일도 있어서  것 같은데 이 포스트에서는 그냥 직접 Visual Studio 2010에서 프로젝트를 만들어가지고 빌드할 예정이다. (사실 내가 어떻게 make파일 쓰는지를 모름 ㅎㅎ)

따라서 일단 Visual studio 2010에서 솔루션을 하나 맹글자.

그리고나서 아래와 같이 소스코드를 담고 있는 폴더명을 따서 프로젝트를 추가해주자.

정적 라이브러리로 빌드할 거니까

윈도우 32 콘솔프로그램 -> 생성마법사에서 정적 라이브러리 체크

로 해서 정적 라이브러리 빌드용 파일을 만든다.

(미리 컴파일 된 헤더도 체크해제한다.)

취향에 맞게 DLL로 만들어도 뭐.. 무방하다.

아참.. 그 전에 일단 각 소스코드 폴더별로 간단히 설명을 해야 겠다.

먼저 Live555 에서 각종 기능을 제공하는 소스코드. 즉, 라이브러리로 빌드할 소스코드는

UsageEnvironment

BasicUsageEnvironment

groupsock

liveMedia

여기 들어 있는게 전부다.

이 폴더안에 들어 있는 소스코드는 정적라이브러리 빌드용 프로젝트로 빌드하면 되겠다.

그 외에

proxyServer

mediaServer

testProgs

는 콘솔 프로그램으로 Live555에서 만들어서 제공하는 프로그램의 소스코드이다.

따라서 이 소스파일들은 빌드할 때는 console프로그램으로 프로젝트를 만들어 빌드해야 한다.

WindowsAudioInputDevice에 들어 있는 소스코드는 정확히는 모르겠지만 윈도우 OS에 연결된 오디오 장비로부터 음성 데이터를 수신할 수 있도록 해주는 소스코드가 들어 있는 것 같다. 구지 빌드하지 않아도 된다.

어쨋든 아래와 같이 각 소스코드별로 프로젝트를 만들고 각 폴더안에 들어 있는 헤더와 소스코드를 몽창 넣어주자.

그 다음 각 폴더에 대해 아래와 같이 헤더의 위치를 찾을 수 있도록 Include path 를 지정해 준다.

포함시켜야 할 include path는 라이브러리용 소스코드에 들어 있는 헤더파일의 위치로 아래와 같다.

헤더파일 경로

$(SolutionDir)\BasicUsageEnvironment\include;

$(SolutionDir)\UsageEnvironment\include;

$(SolutionDir)\groupsock\include;

$(SolutionDir)\liveMedia\include;

이것으로 라이브러리의 빌드를 위한 설정은 모두 완료 되었다.

UsageEnvironment

BasicUsageEnvironment

groupsock

liveMedia

위 네가지 프로젝트를 모두 Debug모드 Release모드로 빌드하면, 다른 프로젝트에서도 이 라이브러리를 사용 할 수 있도록 lib파일이 생성된다. 빌드해 낸 이 라이브러리를 사용하기 위해서는 아래와 같이 헤더와 추가 종속성을 프로젝트 속성에서 지정해 주면 된다.

헤더파일 경로

$(SolutionDir)\BasicUsageEnvironment\include;

$(SolutionDir)\UsageEnvironment\include;

$(SolutionDir)\groupsock\include;

$(SolutionDir)\liveMedia\include;

라이브러리 패스

이전에 lib파일이 생성 된 폴더

추가종속성

liveMedia.lib
BasicUsageEnvironment.lib
groupsock.lib
UsageEnvironment.lib
wsock32.lib

유념 해야 할것은 추가 종속성에서 swock32.lib파일을 추가해 줘야 하는 것이다. 이 라이브러리는 소켓 동작과 관련된 기능을 제공하는 윈도우 기본 라이브러리로, 이 종속성이 있어야 프로그램이 정상적으로 빌드 된다.

 gStreamer를 한번 써먹어 보겠다고 아웅다웅 한 10여일 정도를 gObject도 공부하고 glib도 공부하고 했는데, 아무래도 좀 무린것 같다. 윈도우 환경에서만 개발하고 리눅스써본거는 거의 한 2년전에 대학원에서 잠깐 써먹어본 것이 전부라 이 선수과목들을 배우는거는 커녕 윈도우에서 돌아가도록 빌드하는 것도 쉽지 않은 일이었다.

결국 깔끔하게 gStreamer는 포기 ㅋㅋ..

코덱이나 RTSP전송, 수신이나 다 한가지 라이브러리 내에서 사용 할 수 있다는 측면에서 gStreamer를 배워 놓으면 좋을것 같긴하지만, 아무래도 glib와 gObject를 기반으로하는 gStreamer를 사용하기에는 배워야 하는것이 너무 많아서 좀 무리였던 것 같다. 다음을 기약하며 일단은 대안으로 생각해 놨던, Live555 라이브러리를 이용하는 방법을 생각해 봐야겠다.

다행히 Live555도 LGPL을 이용하기 때문에 소스코드 수정만 안하면 소스코드 공개 없이 상용배포도 가능하다고 하고, 더군다나 gStreamer수준으로 복잡하지는 않아 좋은 것 같다. 그도 그럴것이 아무래도 Live555에는 코덱과 관련된 기능이 배제되어 있기 때문인데, H.264와 관련된 기능은 나중에 FFmpeg를 통해 구현하기로 하고, 일단은  RTSP의 송수신만 Live555로 구현하는 것을 목표로 해야겠다.

 한 동안 그냥 미뤄두고만 있었던 RTSP 미디어 서버 기능이 현재 진행하고 있는 프로젝트에서 필요하게 되어 더이상 미룰 수 없게 되었다. 원래는 RTSP 표준 문서인 RFC인가 치킨집 이름과 비슷한 표준 규약을 분석해서 직접 소켓으로 구현하고 싶었으나, stackoverflow에 한 글을 보고 관련 라이브러리를 찾아 보게 되었다.

Q) RTSP 미디어 서버를 구현하려고 하는데 어떻게 하면 되나요?

A) RFC 규약을 구현해 본 경험이 있습니다. 왜 스스로 지옥으로 걸어 들어가려고 하나요?

실제답변)

Don't do it yourself if you've never written a networking application before. It's no easy task to write a scalable and robust networking app and it's even harder to implement an existing protocol so that the implementation is fully compatible with the specification

그래서 일단은 미디어 서버를 구현하는데 기존의 라이브러리를 사용하기로 마음먹고, 상용으로 사용 가능한 라이브러리들을 찾아보았다. 구글링 결과 LIVE555 Streaming Media, 다윈 스트리밍 미디어, gStreamer를 찾았는데, 이 세 라이브러리 중에 gStreamer가 훨씬 보기 쉬운 API 문서를 제공하고 있는데다가, 전송, 수신, 코덱처리, 렌더링과 같은 다양한 기능을 모두 제공하고 있어서 배워두면 이곳저곳 여러모로 쓸 수 있을 것 같아 일단은 요걸 좀 살펴보고 잘 안된다 싶으면, LIVE555로 갈아 타야지 하고 마음먹었다.

(Darwin은 안 찾아 봐서 잘 모르겠고, LIVE555 streaming media, gStreamer는 둘다 LGPL을 따르고 있어서 상용으로 쓸 때도 소스코드를 공개할 필요는 없는것으로 보였다.)

그리하야... 학습 목표는

1순위 gStreamer

2순위 LIVE555 streaming media

요렇게 결정이 되었다.