<div id="readability-page-1" class="page"><div><div aria-hidden="false"><a rel="noopener follow" href="/?source=post_page---byline--07f4ec6d0519---------------------------------------"><div><p><img alt="이상문" src="https://miro.medium.com/v2/resize:fill:88:88/1*PdFTYwkEj-ebxhH52VWJ8w.png" width="44" height="44" loading="lazy" data-testid="authorPhoto"></p></div></a></div><h2 id="88c4">1. GStreamer RTSP 구성 요소 개요</h2><figure><figcaption><em>GstRTSPMediaFactory와 GstRTSPMedia의 관계도. factory는 요청에 따라 media 인스턴스를 생성하며, media-configure는 그 직후 호출되어 초기화를 담당.</em></figcaption></figure><h2 id="8094">RTSP 세션이란?</h2><p id="f8a2"><strong>RTSP 세션</strong>은 클라이언트와 서버 간의 스트리밍 연결 상태를 추상화한 개념이다. 클라이언트가 RTSP URI에 접속하면, 서버는 해당 요청에 대한 고유한 세션을 생성하며, 이 세션은 다음을 포함한다.</p><ul><li id="82e8">클라이언트 연결 상태 및 세션 ID</li><li id="1f94">미디어 스트림별 트랜스포트 정보 (RTP 포트, 프로토콜 등)</li><li id="b2f0"><code>GstRTSPMedia</code>와 연결된 내부 파이프라인</li><li id="7221">세션 유지 시간(<code>rtsp-session-timeout</code>) 관리</li></ul><p id="0564">일반적으로 세션은 클라이언트가 <code>TEARDOWN</code> 요청을 보내거나 타임아웃이 발생할 때 종료된다. 서버 입장에서는 하나의 세션이 종료되기 전까지 관련 리소스(GstPipeline 등)를 유지하게 된다.</p><h2 id="ebbf">GstRTSPMediaFactory란?</h2><p id="62fd"><strong>역할</strong>: RTSP 클라이언트의 요청에 따라 새로운 <code>GstRTSPMedia</code> 인스턴스를 생성하는 <strong>factory</strong> 역할</p><p id="0596"><strong>기능</strong>:</p><ul><li id="304a">스트림 파이프라인을 정의 (launch string 또는 사용자 정의 방식)</li><li id="f76e">세션 공유 여부, 재사용 가능 여부 설정</li><li id="717d"><code>media-configure</code> 콜백을 통해 개별 미디어 인스턴스 초기화</li></ul><h2 id="9624">GstRTSPMedia란?</h2><p id="deae"><strong>역할</strong>: 실제 스트리밍 파이프라인을 구성하고, 클라이언트와의 세션을 관리하는 <strong>RTSP 미디어 객체</strong></p><p id="3e6d"><strong>기능</strong>:</p><ul><li id="37a5">내부적으로 GStreamer 파이프라인을 포함</li><li id="58e0"><code>prepare()</code>, <code>unprepare()</code>, <code>suspend()</code> 등을 통해 파이프라인 라이프사이클 관리</li><li id="c90f">클라이언트와의 세션 및 전송 상태 유지</li></ul><h2 id="de20">GstRTSPMedia의 라이프사이클 요약</h2><ol><li id="0dd1"><strong>생성 (Creation)</strong>: <code>GstRTSPMediaFactory</code>에 의해 <code>GstRTSPMedia</code> 인스턴스가 생성됨 (<code>media-configure</code> 콜백 시점)</li><li id="f917"><strong>준비 (Preparation)</strong>: 내부 GStreamer 파이프라인이 생성 및 구성됨 (<code>gst_rtsp_media_prepare()</code>)</li><li id="fe37"><strong>활성화 (Streaming)</strong>: 클라이언트 요청에 따라 실제 스트리밍이 시작됨</li><li id="a191"><strong>중지 또는 해제 (Suspension/Unprepare)</strong>:</li></ol><ul><li id="0c79"><code>gst_rtsp_media_suspend()</code>: 스트리밍을 일시 중단</li><li id="7ddc"><code>gst_rtsp_media_unprepare()</code>: 파이프라인 정리 및 리소스 해제</li></ul><p id="9f1c"><strong>5. 삭제 (Finalization)</strong>: 세션 종료 또는 오류 발생 시 media 객체가 파괴되고 자원이 해제됨</p><h2 id="e23a">관계 요약</h2><p id="ace7"><code>GstRTSPMediaFactory</code>는 <code>GstRTSPMedia</code>를 <strong>생성</strong>하며, <code>media-configure</code>는 이 <strong>생성 직후</strong> 호출되어 사용자 정의 초기화 작업을 수행하는 지점이다.</p><h2 id="f029">2. <code>media-configure</code> 콜백 개요</h2><p id="3653"><code>media-configure</code>는 <code>GstRTSPMediaFactory</code>가 <code>GstRTSPMedia</code> 인스턴스를 생성한 직후 호출되는 콜백이다. 이 시점은 RTSP 클라이언트가 세션을 시작하고, RTSP 서버가 스트림 전송을 위한 파이프라인을 구성하려는 단계이다. 해당 콜백에서는 다음과 같은 작업을 수행할 수 있다.</p><ul><li id="bebe">스트림 준비 상태 확인</li><li id="fd9d">appsrc 같은 요소에 외부 데이터 공급자 연결</li><li id="f644">필요 시 파이프라인 초기화 또는 조정</li><li id="0db6">비정상 상태인 경우 스트림 준비 중단</li></ul><h2 id="a991">3. 개선이 필요하다고 판단한 상황</h2><p id="4cca">RTSP 클라이언트가 연결될 때, 비디오 소스가 비활성화된 경우에도 연결이 일정 시간(약 30초) 유지되다가 타임아웃 후 종료되는 문제가 있었다. 이로 인해 클라이언트는 영상이 없는 상태로 대기하게 되어 UX 측면에서 부정적인 영향을 주는 상황이었다.</p><h2 id="f93c">4. 바로 해제되지 않는 이유</h2><p id="3b61"><code>GstRTSPMedia</code>는 <code>prepare()</code> 단계에서 파이프라인을 구성하지만, 입력 소스가 없더라도 파이프라인이 정상적으로 준비된 것으로 간주된다. 이 상태에서는 실제 데이터가 전송되지 않지만, 클라이언트는 여전히 연결된 상태로 유지된다.</p><p id="d9dd">내부적으로는 <code>rtsp-session-timeout</code> 설정에 따라 일정 시간이 지나야 연결이 끊어지므로, 즉각적인 반응을 기대할 수 없다.</p><p id="3864">또한 주목할 점은 <strong>첫 번째 접속 시도 중 30초 동안</strong>, 다른 RTSP 스트림에 대한 새로운 연결 요청도 지연되는 문제이다. 이 경우 해당 스트림에 대한 <code>media-configure</code> 콜백 자체가 호출되지 않다가, 기존 세션이 타임아웃 후 해제된 이후에야 다음 스트림에 대한 처리가 시작된다.</p><p id="8296"><strong>추측되는 원인:</strong> 내부적으로 RTSP 서버가 동시 처리 가능한 미디어 수를 제한하거나, 특정 상태에서 <code>GstRTSPMediaFactory</code> 또는 세션 풀에 의해 후속 처리가 차단되는 것으로 보인다. 즉, 비활성 상태의 스트림이 시스템 자원을 점유한 채 해제되지 않으면서, 이후 요청에 대한 처리가 지연되는 것이 아닐까 추측해볼 수 있다.</p><h2 id="5ca4">5. 개선된 처리 방식</h2><pre><span id="5558">void onMediaConfigure(GstRTSPMediaFactory *factory, GstRTSPMedia *media, void* userData) {<br>    // 필요 시 'unprepared' 시그널 연결<br>    g_signal_connect(media, "unprepared", (GCallback)onMediaUnprepared, userData);<br>    // 외부 조건에 따라 스트림 소스가 준비되지 않은 경우<br>    if (!isVideoSourceActive()) {<br>        // 세션 중단 및 파이프라인 초기화<br>        gst_rtsp_media_suspend(media);<br>        gst_rtsp_media_unprepare(media);<br>        GstElement *pipeline = gst_rtsp_media_get_element(media);<br>        if (pipeline) {<br>            gst_element_set_state(pipeline, GST_STATE_NULL);<br>            // 에러 메시지 생성 및 전송<br>            GError *error = g_error_new(GST_RESOURCE_ERROR, GST_RESOURCE_ERROR_NOT_FOUND, "No input stream available");<br>            GstMessage *msg = gst_message_new_error(GST_OBJECT(pipeline), error, "Input stream not available");<br>            GstBus *bus = gst_element_get_bus(pipeline);<br>            gst_bus_post(bus, msg);<br>            gst_object_unref(bus);<br>            g_error_free(error);<br>        }<br>        return;<br>    }<br>    // (이하 일반적인 스트림 구성 로직)<br>    // GstRTSPMedia에 AppSrc 등 연결<br>    // 타임스탬프 초기화 및 데이터 공급자 연결<br>    // ...<br>}</span></pre><h2 id="0f22">6. 적용된 개선 처리의 효과</h2><ul><li id="a586"><strong>즉시 세션 종료:</strong> <code>gst_rtsp_media_suspend()</code> 및 <code>gst_rtsp_media_unprepare()</code> 호출로 스트림 준비를 중단한다.</li><li id="a947"><strong>파이프라인 상태 초기화:</strong> <code>gst_element_set_state(..., GST_STATE_NULL)</code>을 통해 자원 해제를 유도한다.</li><li id="b0e1"><strong>에러 메시지 전송:</strong> <code>GstMessage</code>를 사용해 클라이언트 측에 오류 상황을 즉시 알린다.</li><li id="75e4"><strong>결과:</strong> 클라이언트는 스트림이 준비되지 않았음을 즉시 인지하고, 연결을 빠르게 종료할 수 있다.</li></ul><h2 id="2b7d">7. 결론</h2><p id="4651">GStreamer RTSP 서버에서 스트림 준비 상태를 명시적으로 제어함으로써 비정상적인 대기를 줄이고, 클라이언트 UX 및 시스템 리소스 효율성을 개선할 수 있다. 소스가 활성화되지 않은 상황에서는 준비 단계에서 세션을 중지하고 파이프라인을 명확히 종료하는 것이 바람직하다.</p></div></div>

Stories by 이상문 on Medium

1. GStreamer RTSP 구성 요소 개요
RTSP 세션이란?
RTSP 세션은 클라이언트와 서버 간의 스트리밍 연결 상태를 추상화한 개념이다. 클라이언트가 RTSP URI에 접속하면, 서버는 해당 요청에 대한 고유한 세션을 생성하며, 이 세션은 다음을 포함한다.
클라이언트 연결 상태 및 세션 ID
미디어 스트림별 트랜스포트 정보 (RTP 포트, 프로토콜 등)
GstRTSPMedia와 연결된 내부 파이프라인
세션 유지 시간(rtsp-session-timeout) 관리
일반적으로 세션은 클라이언트가 TEARDOWN 요청을 보내거나 타임아웃이 발생할 때 종료된다. 서버 입장에서는 하나의 세션이 종료되기 전까지 관련 리소스(GstPipeline 등)를 유지하게 된다.
GstRTSPMediaFactory란?
역할: RTSP 클라이언트의 요청에 따라 새로운 GstRTSPMedia 인스턴스를 생성하는 factory 역할
기능:
스트림 파이프라인을 정의 (launch string 또는 사용자 정의 방식)
세션 공유 여부, 재사용 가능 여부 설정
media-configure 콜백을 통해 개별 미디어 인스턴스 초기화
GstRTSPMedia란?
역할: 실제 스트리밍 파이프라인을 구성하고, 클라이언트와의 세션을 관리하는 RTSP 미디어 객체
기능:
내부적으로 GStreamer 파이프라인을 포함
prepare(), unprepare(), suspend() 등을 통해 파이프라인 라이프사이클 관리
클라이언트와의 세션 및 전송 상태 유지
GstRTSPMedia의 라이프사이클 요약
생성 (Creation): GstRTSPMediaFactory에 의해 GstRTSPMedia 인스턴스가 생성됨 (media-configure 콜백 시점)
준비 (Preparation): 내부 GStreamer 파이프라인이 생성 및 구성됨 (gst_rtsp_media_prepare())
활성화 (Streaming): 클라이언트 요청에 따라 실제 스트리밍이 시작됨
중지 또는 해제 (Suspension/Unprepare):
gst_rtsp_media_suspend(): 스트리밍을 일시 중단
gst_rtsp_media_unprepare(): 파이프라인 정리 및 리소스 해제
5. 삭제 (Finalization): 세션 종료 또는 오류 발생 시 media 객체가 파괴되고 자원이 해제됨
관계 요약
GstRTSPMediaFactory는 GstRTSPMedia를 생성하며, media-configure는 이 생성 직후 호출되어 사용자 정의 초기화 작업을 수행하는 지점이다.
2. media-configure 콜백 개요
media-configure는 GstRTSPMediaFactory가 GstRTSPMedia 인스턴스를 생성한 직후 호출되는 콜백이다. 이 시점은 RTSP 클라이언트가 세션을 시작하고, RTSP 서버가 스트림 전송을 위한 파이프라인을 구성하려는 단계이다. 해당 콜백에서는 다음과 같은 작업을 수행할 수 있다.
스트림 준비 상태 확인
appsrc 같은 요소에 외부 데이터 공급자 연결
필요 시 파이프라인 초기화 또는 조정
비정상 상태인 경우 스트림 준비 중단
3. 개선이 필요하다고 판단한 상황
RTSP 클라이언트가 연결될 때, 비디오 소스가 비활성화된 경우에도 연결이 일정 시간(약 30초) 유지되다가 타임아웃 후 종료되는 문제가 있었다. 이로 인해 클라이언트는 영상이 없는 상태로 대기하게 되어 UX 측면에서 부정적인 영향을 주는 상황이었다.
4. 바로 해제되지 않는 이유
GstRTSPMedia는 prepare() 단계에서 파이프라인을 구성하지만, 입력 소스가 없더라도 파이프라인이 정상적으로 준비된 것으로 간주된다. 이 상태에서는 실제 데이터가 전송되지 않지만, 클라이언트는 여전히 연결된 상태로 유지된다.
내부적으로는 rtsp-session-timeout 설정에 따라 일정 시간이 지나야 연결이 끊어지므로, 즉각적인 반응을 기대할 수 없다.
또한 주목할 점은 첫 번째 접속 시도 중 30초 동안, 다른 RTSP 스트림에 대한 새로운 연결 요청도 지연되는 문제이다. 이 경우 해당 스트림에 대한 media-configure 콜백 자체가 호출되지 않다가, 기존 세션이 타임아웃 후 해제된 이후에야 다음 스트림에 대한 처리가 시작된다.
추측되는 원인: 내부적으로 RTSP 서버가 동시 처리 가능한 미디어 수를 제한하거나, 특정 상태에서 GstRTSPMediaFactory 또는 세션 풀에 의해 후속 처리가 차단되는 것으로 보인다. 즉, 비활성 상태의 스트림이 시스템 자원을 점유한 채 해제되지 않으면서, 이후 요청에 대한 처리가 지연되는 것이 아닐까 추측해볼 수 있다.
5. 개선된 처리 방식
void onMediaConfigure(GstRTSPMediaFactory *factory, GstRTSPMedia *media, void* userData) {
    // 필요 시 'unprepared' 시그널 연결
    g_signal_connect(media, "unprepared", (GCallback)onMediaUnprepared, userData);
    // 외부 조건에 따라 스트림 소스가 준비되지 않은 경우
    if (!isVideoSourceActive()) {
        // 세션 중단 및 파이프라인 초기화
        gst_rtsp_media_suspend(media);
        gst_rtsp_media_unprepare(media);
        GstElement *pipeline = gst_rtsp_media_get_element(media);
        if (pipeline) {
            gst_element_set_state(pipeline, GST_STATE_NULL);
            // 에러 메시지 생성 및 전송
            GError *error = g_error_new(GST_RESOURCE_ERROR, GST_RESOURCE_ERROR_NOT_FOUND, "No input stream available");
            GstMessage *msg = gst_message_new_error(GST_OBJECT(pipeline), error, "Input stream not available");
            GstBus *bus = gst_element_get_bus(pipeline);
            gst_bus_post(bus, msg);
            gst_object_unref(bus);
            g_error_free(error);
        }
        return;
    }
    // (이하 일반적인 스트림 구성 로직)
    // GstRTSPMedia에 AppSrc 등 연결
    // 타임스탬프 초기화 및 데이터 공급자 연결
    // ...
}
6. 적용된 개선 처리의 효과
즉시 세션 종료: gst_rtsp_media_suspend() 및 gst_rtsp_media_unprepare() 호출로 스트림 준비를 중단한다.
파이프라인 상태 초기화: gst_element_set_state(..., GST_STATE_NULL)을 통해 자원 해제를 유도한다.
에러 메시지 전송: GstMessage를 사용해 클라이언트 측에 오류 상황을 즉시 알린다.
결과: 클라이언트는 스트림이 준비되지 않았음을 즉시 인지하고, 연결을 빠르게 종료할 수 있다.
7. 결론
GStreamer RTSP 서버에서 스트림 준비 상태를 명시적으로 제어함으로써 비정상적인 대기를 줄이고, 클라이언트 UX 및 시스템 리소스 효율성을 개선할 수 있다. 소스가 활성화되지 않은 상황에서는 준비 단계에서 세션을 중지하고 파이프라인을 명확히 종료하는 것이 바람직하다.

GStreamer RTSP Server media-configure 콜백 처리 및 media 원소 준비 상태 관리

댓글