실시간 통신, 미디어 처리, AI 통합에 대한 심층 분석.
Agora SDK를 중심으로 프로덕션 레벨의 구현을 다룹니다.
primary 카테고리 또는 태그로 Media에 속한 글을 모두 표시합니다.
HLS, HTTP-FLV, MP4를 같은 종류의 포맷처럼 비교하면 선택 기준이 흐려집니다. HLS와 HTTP-FLV는 전달 방식이고, FLV와 MP4는 미디어를 담는 컨테이너입니다. 이 글은 HLS가 반드시 .ts만 쓰는지, HTTP-FLV가 Flash 종료와 함께 사라졌는지, 1~3초·10~30초라는 지연 수치를 어디까지 믿어야 하는지 검증하고, ABR·브라우저 호환성·CDN 확장성·실시간성에 따라 무엇을 선택할지 정리합니다.
OBS encoder에서 ingest, transcoding, ABR packaging, CDN, player buffer까지 일반적인 glass-to-glass 경로를 설명합니다. YouTube와 Twitch가 공개한 입력 요구사항과 latency 설정은 공식 문서로 확인하고, 공개되지 않은 내부 topology는 참조 구조와 구분합니다.
stream은 논리적인 미디어 흐름이고 RTP는 그 미디어를 네트워크로 운반하는 패킷 프로토콜입니다. 하지만 WebRTC API의 MediaStream, Agora 운영 문맥의 stream, RTP의 SSRC packet stream은 같은 말이 아닙니다. 이 글은 track, stream, RTP, RTCP의 층위를 분리하고, muteLocalVideoStream, enableLocalVideo, stopPreview, leaveChannel이 Cloud Recording에서 어떻게 다르게 보이는지 검증된 기준으로 정리합니다.
Mesh, SFU, MCU, Hybrid의 media path와 처리 경계를 토폴로지·시퀀스 다이어그램으로 비교합니다. Mesh의 direct path에는 TURN relay 예외가 있고, SFU는 선택 전달, MCU는 서버 합성을 담당합니다. 참가자 수만으로 결론을 내리지 않고 codec·subscription·layout·region·hardware·recording 요구를 함께 검증하는 기준을 제시합니다.
HLS와 DASH를 매니페스트 문법, 세그먼트 형식, ABR, DRM, 저지연 확장 기준으로 비교합니다. 두 프로토콜이 fMP4를 사용할 때 CMAF 미디어 세그먼트를 공유할 수 있는 조건과 Apple 플랫폼의 HLS 요구사항도 함께 설명합니다. LL-HLS는 HTTP/2 Push가 아니라 blocking playlist reload와 preload hint를 사용한다는 점을 현재 사양에 맞춰 정리했습니다.
OBS의 RTMP·RTMPS 출력이 ingest, transcoding, ABR packaging, CDN, player buffer를 거쳐 재생되는 경로를 분해합니다. 전체 지연은 세그먼트 길이 하나가 아니라 인코더, 패키저, 배포망, 플레이어 설정의 합으로 결정됩니다. AWS MediaLive와 MediaConvert의 역할 차이와 상호작용 요구에 따라 HLS 계열과 WebRTC를 선택하는 기준도 다룹니다.
Full Mesh, 단일 SFU, 지역 간 SFU cascading, CDN 기반 방송 구조의 부하 특성을 비교합니다. SFU 용량은 참가자 수만으로 정해지지 않고 publish·subscribe 수, simulcast layer, bitrate, packet rate, 암호화, 하드웨어에 따라 달라집니다. 따라서 예시 계산은 용량 계획의 출발점으로만 사용하고 실제 트래픽 모델로 부하 시험해야 합니다.
Zoom, Discord, LiveKit, Agora, Slack, Meta가 공개한 자료를 바탕으로 표준 WebRTC, libwebrtc, 자체 미디어 계층의 경계를 비교합니다. 클라이언트 엔진과 서버 토폴로지, 전송 최적화, 운영 모델을 분리해 설명하고 공개 자료로 확인되지 않는 내부 구현은 추정하지 않습니다.
카메라 캡처부터 색공간 변환, 인코딩, 디코딩, 렌더링까지 모바일 영상 경로에서 메모리 복사와 CPU·GPU·하드웨어 코덱 사용이 발열에 미치는 영향을 설명합니다. Android SurfaceTexture와 iOS CVPixelBuffer 같은 플랫폼별 버퍼 공유 방식도 비교합니다. 실제 전력 효과는 단말과 코덱 지원에 따라 달라지므로 계측 기준을 함께 제시합니다.
Meta가 공개한 엔지니어링 글을 기준으로 장기 유지한 libwebrtc fork를 upstream 계열로 전환한 과정을 정리합니다. 두 구현의 호출 경계를 shim으로 통제하고 use case별로 이동한 방식, fork가 보안 패치와 기능 추적에 만드는 비용, 공개된 사실과 추정을 구분하는 방법을 다룹니다.
브라우저의 WebRTC API와 코덱 협상 범위, Agora Web SDK가 제공하는 채널·미디어 API, SD-RTN으로 설명되는 서비스 네트워크의 역할을 분리합니다. 네이티브 SDK의 비공개 내부 구현은 단정하지 않고, FEC와 retransmission 같은 손실 대응 기법도 표준과 공개 문서 범위에서 설명합니다.
I·P·B frame과 GOP가 압축과 random access에 맡는 역할을 설명하고, frame 기반 keyint 설정이 실제 시간 길이로 어떻게 환산되는지 살펴봅니다. 입력 frame rate 저하, keyframe 간격, HLS segment duration이 함께 변하는 장애를 log와 ffprobe로 구분하는 절차도 다룹니다.
AI 콜봇의 동시 발신에서 call leg와 dialog 상태가 분리되지 않을 때 나타나는 증상을 SIP 메시지 흐름으로 분석합니다. 특정 장비의 Bridge·IVR 명칭을 표준 용어로 일반화하지 않고, B2BUA의 세션 제어와 180 Ringing·183 Session Progress·200 OK 시점이 미디어 재생에 미치는 영향을 구분합니다.
HLS, LL-HLS, WebRTC를 지연 구성 요소, 호환성, 상호작용, 배포 방식, 운영 비용으로 비교합니다. 고정된 지연 수치로 프로토콜을 선택하지 않고 목표 latency와 audience 규모, 양방향 media 요구, device 지원 범위를 측정해 결정하는 절차를 제시합니다.
H.264·H.265 SEI NAL unit의 payload type과 payload size를 읽는 방법을 설명합니다. Agora Media Push가 제공하는 metadata 형식은 공식 계약에 맞춰 처리하고, Annex B와 AVCC 입력을 구분해 emulation-prevention byte 제거, payload type 100·송출 경로·JSON schema를 확인합니다.
ABR 전환을 위해 rendition 간 segment boundary와 random access point를 맞추는 이유를 설명합니다. FFmpeg의 GOP·force_key_frames·scene-cut 설정은 입력 timestamp와 encoder 동작까지 함께 확인해야 하며, 최종 정렬 여부는 ffprobe와 Apple media tooling 등으로 산출물을 검증합니다.
Encoder GOP와 streaming platform의 keyframe 요구사항, HLS segment 경계가 서로 영향을 주는 지점을 정리합니다. 플랫폼별 권장값을 보편 규칙으로 일반화하지 않고, frame rate와 keyframe interval 단위를 확인한 뒤 실제 manifest와 frame timestamp로 결과를 검증하는 방법을 다룹니다.
PushKit 수신, CallKit transaction, AVAudioSession activation, RTC SDK audio module의 책임을 네 계층으로 나눕니다. `didActivate`와 `didDeactivate`, interruption·route change callback을 어떤 상태 전이에 연결할지 설명하며, channel join 시점과 audio module 제어는 사용 중인 SDK 계약에 맞춰 검증합니다.
녹화 파일을 중간 위치로 탐색할 때 멈추는 문제를 MP4 index, HLS playlist 종료 상태, timestamp discontinuity 관점에서 진단합니다. `ffprobe`, manifest 검사, ffmpeg remux가 각각 확인하거나 복구할 수 있는 범위를 구분하고, 원본 segment 누락처럼 후처리로 복구할 수 없는 경우도 명시합니다.
SIP·RTSP의 signaling/control message와 RTP·RTCP media 흐름을 분리해 설명합니다. 협상이 성공해도 NAT, firewall, address advertisement, codec 조건 때문에 한쪽 media만 실패할 수 있습니다. packet capture와 SDP를 대조해 control plane과 media plane을 따로 진단하는 순서를 정리했습니다.
RTSP 등 live input의 연결 상태, stream metadata, packet·frame timestamp를 ffprobe와 GStreamer 도구로 확인합니다. timeout을 둔 probe, PTS·DTS 출력, frame CSV 추출, `gst-discoverer-1.0` 사용법을 나누고 각 명령이 실제 media 수신까지 보장하는지 여부도 구분합니다.
x264의 reference frame 수, tune, keyint, scenecut 설정이 압축 효율·encoder latency·random access에 미치는 영향을 설명합니다. 실시간 통신과 HLS·VOD의 요구사항을 구분하고, 특정 값을 보편적인 정답으로 제시하지 않고 수신기 호환성과 실제 frame output으로 검증합니다.
H.264 profile과 packetization mode, software·hardware encoder, bitrate control이 WebRTC 호환성과 품질에 미치는 영향을 정리합니다. 해상도만으로 bitrate를 고정하지 않고 frame rate, 화면 움직임, codec implementation, network 조건을 포함해 시험하는 절차와 browser stats·bitstream 검사 항목을 제시합니다.
RTMP ingest를 WebRTC로 변환하는 경로에서 timestamp rollback과 freeze가 나타난 사례를 진단합니다. B-frame 재정렬, PTS·DTS 변환, transcoder·gateway 처리 경계를 각각 격리하며, 특정 H.264 profile을 원인으로 단정하기 전에 bitstream과 단계별 timestamp를 비교하는 절차를 설명합니다.
RTC 품질 문제를 패킷 캡처로 확인하는 절차를 정리했습니다. TCP 재전송과 Zero Window, RTP sequence number와 timestamp, RTCP 품질 보고서, TLS·DTLS handshake를 Wireshark에서 찾는 방법을 설명하고 서버에서는 tcpdump로 캡처한 뒤 로컬에서 분석하는 흐름까지 다룹니다.
Bitrate는 해상도·frame rate·codec·장면 복잡도와 함께 압축 화질을 좌우합니다. 이 글은 송출 설정, 네트워크 적응, Cloud Recording 출력 설정을 구분하고 `ffprobe`로 실제 결과를 측정하는 절차를 설명합니다. 출력 bitrate를 높여도 원본에서 이미 잃은 디테일은 복원되지 않으므로 실제 콘텐츠로 품질을 비교해야 합니다.
Individual recording 결과를 참가자별 VOD나 하나의 composite 화면으로 후처리하는 FFmpeg 파이프라인을 설명합니다. M3U8과 TS를 점검하고 기록된 track의 시작 시각을 맞춘 뒤, audio-only·video-only 입력과 참가자 수를 검증해 레이아웃을 구성합니다. 입력값 제한, 경로 검증, 실패 복구를 포함한 자동화 기준도 함께 다룹니다.
FFmpeg에서 컨테이너, 코덱, 스트림을 구분하고 probe·demux·decode·filter·encode·mux 단계가 어떻게 연결되는지 설명합니다. `-c copy`는 입력 코덱과 출력 컨테이너, timestamp와 keyframe 조건이 맞을 때만 안전합니다. remux, transcoding, stream mapping, seek, concat을 선택하는 기준을 실제 명령으로 정리했습니다.
Cloud Recording 결과에 포함된 M3U8 재생목록과 MPEG-TS 세그먼트를 읽는 방법을 설명합니다. MP4의 `moov` 위치와 fragmented MP4를 구분하고, TS packet·PES·codec frame의 관계, HLS 태그, target duration 규칙을 살펴봅니다. Agora의 track event와 slice 파일명은 공식 형식에 맞춰 해석합니다.
Individual, Composite(`mix`), Web page recording의 출력과 처리 범위를 비교합니다. Individual은 참가자별 track 후처리에, Composite는 서버 합성과 고정 레이아웃 출력에, Web page recording은 웹 화면 캡처에 맞습니다. 과금은 모드 이름이 아니라 스트림 수·시간·합산 해상도 등 공식 가격 기준으로 확인해야 합니다.
데이터 위치·처리자·보유 방식에 대한 계약이나 규제 요구가 Cloud Recording의 데이터 흐름과 맞지 않을 때 On-Premise Recording을 검토할 수 있습니다. 이 글은 배포 위치, 운영 책임, 후처리 통제 범위를 Cloud 방식과 비교하고 raw-data callback은 사용하는 SDK 버전의 API 계약으로 확인해야 한다는 기준을 제시합니다.
WebRTC는 미디어 저장 방식을 정의하지 않으므로 녹화가 필요하면 별도 파이프라인을 설계해야 합니다. 이 글은 브라우저 `MediaRecorder`, 자체 미디어 서버, Agora Cloud Recording의 통제 범위와 운영 부담을 비교합니다. Cloud Recording의 non-streaming client 모델, `acquire → start → query → stop` 수명주기, REST 인증과 RTC token의 역할도 구분합니다.
제한된 enterprise network에서 Agora RTC에 필요한 domain·port allowlist와 Cloud Proxy를 비교합니다. UDP 차단, 고정 outbound 정책, TLS inspection 같은 조건에 따라 적용 범위가 달라지며 어느 방식도 모든 방화벽 통과를 보장하지 않습니다. 운영망에서 join·publish·subscribe를 검증하는 절차를 함께 제시합니다.
NAT mapping과 filtering 동작 때문에 endpoint끼리 직접 연결되지 않는 경우를 설명합니다. ICE agent가 host·server-reflexive·relay candidate pair를 검사하고 STUN binding과 TURN relay를 사용하는 흐름을 현재 RFC 기준으로 정리합니다. 오래된 NAT 네 가지 분류는 진단의 참고 모델로만 다룹니다.
WebRTC의 media·data 연결과 signaling의 경계를 소개하고, NAT와 firewall 환경에서 ICE가 candidate pair를 검사하는 과정을 설명합니다. STUN으로 server-reflexive candidate를 얻고 TURN relay를 사용하는 경우를 구분하며, Agora Web SDK가 제공하는 channel·track API와 browser WebRTC 구현의 관계도 정리합니다.