전체 글 (1252) 썸네일형 리스트형 실험 : RTSP 기반 스트리밍 파이프라인 레이턴시 및 QoE 분석 Media Server ----- (RTSP Stream) ---> RTSP ingest -> Decoder -> Processing -> Encoder -> File Output Measurement Layer - timestamp- latency- jitter- frame drop- buffering- CPU / GPU- recovery time- QoEQueue 배치 전략source, decode, process, encode, sink 각 모듈 구현체에 queue 엘리먼트를 포함시키지 않고, 컨트롤러에서 각 모듈의 bin을 조합하여 파이프를 생성할 때, 중간 중간에 queue를 끼워넣는 구조로 변경그리고 GstPadProbe를 해당 queue를 타겟으로 작성callback을 통해 각 단계의 정확.. zero-copy frame processing GStreamer에서 버퍼를 가로채는 3가지 방식 비교Pad Probe (gst_pad_add_probe)identity 같은 통과용 엘리먼트나 특정 Pad에 콜백(Probe)을 등록기존 파이프라인 구조를 해치지 않고 제로카피(In-place) 수정 가능포맷/해상도 변경(Caps 변경) 없이 동일 규격 픽셀 수정에 최적appsink + appsrc 브릿지디코더 출력을 appsink로 뽑아 처리 후 appsrc로 다시 주입GStreamer 스레드와 완전 분리 가능, 비동기 큐/외부 렌더 루프 연동 용이버퍼 풀 재할당 및 약간의 파이프라인 오버헤드GstVideoFilter 커스텀 플러그인GStreamer 기반의 C/C++ 필터 엘리먼트를 직접 작성GStreamer 표준 방식, Caps 협상 완벽 지원GObj.. QoS (Quality of Service) QoS 달성을 위한 대표 전략 두 가지1. 데이터 스트림과 상호 작용하며 자원 할당을 조절2. 엔드 투 엔드 스트림 경로의 모든 리소스에 필요 자원을 미리 고려하여 예약실시간 시스템이란?- 주어진 시간 범위내에서 결과를 처리해서 전달하는 프로세스실시간 시스템의 주 성질은 정확성이고 이것은 에러 없는 것만 의미하지 않고, 결과가 제시되는 시간도 의미속도나 효율성은 실시간 시스템의 주 성질이 아님실시간 시스템의 데드라인에는 soft와 hard가 존재함 - soft : 기한을 놓쳐도 용납할 수 없는 결과를 초래하지 않는 경우 - hard : 기한 놓치면 시스템 오류로 이어지는 경우 실시간 시스템의 보증은 처리 기계가 붕괴되거나, 도착 시간이 알려지지 않은 무작위 간격으로 발생하는 사건은 불가능실시간 시스템의.. Multimedia Systems 보호되어 있는 글입니다. latency optimization in interactive multimedia streaming 보호되어 있는 글입니다. Real-Time Systems Design and Analysis 보호되어 있는 글입니다. RTSP 정리 RTSP를 통한 스트리밍 단계1. 서버는 DESCRIBE 요청 받으면 미디어 상세 규격을 SDP (Session Description Protocol) 포맷으로 반환함2. 클라이언트와 서버가 RTP 데이터를 주고받을 전송 방식과 포트 번호 협상하고 세션 ID 결정하는 SETUP 요청 전송3. PLAY 요청 시 서버가 지정된 포트로 RTP 패킷 송출4. 이후 UDP/TCP로 구분되어 RTCP 주기적 전송TCP의 경우 RTP를 전송하는 포트의 단일 파이프라인에서 RTP와 RTCP를 인터리브드로 전송 / TCP의 경우는 연결형이므로 포트하나 열기 위해서 handshake를 RTSP, RTP, RTCP 용으로 3번 맺어야 함UDP의 경우 RTP 전용과 RTCP 전용을 따로 구분해서 전송gstreamer rtsp.. Gstreamer Tracing RTSP 수신 -> (pad) -> depay -> (pad) -> parse -> (pad) -> decode -> (pad) -> convert -> (pad) -> sink위와 같은 동작에서 예를 들어 디코더가 프레임 출력할 때는 내부적으로 아래와 같은 흐름임decoder src pad -> gst_pad_push(buffer) -> 다음 element의 sink pad여기에서 gst_pad_push는 버퍼 하나를 다음 요소로 전달하는 gstreamer의 핵심 동작,core tracing은 이와 같은 핵심 경로에 hook을 둬서 아래처럼 진행하게 함gst_pad_push(buffer) 실행 ├─ 원래의 버퍼 전달 처리 └─ 활성화된 tracer가 있으면 “pad-push 발생”을 tracer에 .. WebrtcSource / WebrtcSink Module WebRtcVideoSink[입력] -> [h264/265 NALU 파싱] -> [RTP 패킷화] -> [RTP Caps 설정] -> [Queue (지연 제어/ 드롭)] -> [WebrtcBin (암호화 및 ICE 전송)]17: struct WebrtcSinkOptions {18: std::string stun_server = "";19: std::string turn_server = "";20: std::string codec = "h264"; // "h264" or "h265"21: 22: // 지연(Latency) 관련 옵션23: bool sync = false; // 프레임 동기화 여부 (false면 초저지연 즉시 전송)24: .. 필독 공식 문서 및 기술 레퍼런스 GStreamer Design: Latency and Synchronization핵심 내용: 라이브 소스(is-live=true)가 레이턴시 쿼리를 보내는 원리, 파이프라인이 전역 지연시간을 계산하여 싱크 엘리먼트에 분배하는 메커니즘, sync=false의 내부 동작 원리가 상세히 설명된 핵심 설계 문서입니다.GStreamer Design: Tracing Subsystem Guide핵심 내용: 코드 수정 없이 GST_TRACERS="latency" 환경변수로 각 엘리먼트 간 버퍼 체류 시간을 나노초 단위로 계측하는 공식 트레이서 매뉴얼입니다.RidgeRun GstShark Profiler Wiki핵심 내용: GStreamer 파이프라인 내부의 구간별 레이턴시와 프레임레이트를 실시간 그래프로 시각화해 주는.. 스프링 컨테이너 ApplicationContext 보호되어 있는 글입니다. DB 접근 기술 보호되어 있는 글입니다. 이전 1 2 3 4 ··· 105 다음
