유튜브 라이브가 쉬운게 아니네요

퀀트하면서 수십개 종목 틱단위 데이터들을 메시징시스템과 redis, postgrsql timescaledb 로 다뤄봤는데

라이브방송은 게임 시뮬레이션 렌더링 스트림을 파이프로 ffmpeg로 전달하고 영상인코딩 및 rtmp(tcp)로 송출하는건데

n100미니pc와 kt가정용인터넷500mbps라는 한계내에서

1920 1080 30fps를 8mbps로 365 24 지속적으로 라이브방송하는건 또 다른 차원이네요

가정용 인터넷회선은 유동IP이고 특히 야간에 해외트래픽 우선순위도 밀리고 한번씩 불안정하기도 하고

KT정책을 위반하면 QOS 속도제한 가능성이 있고

그래서 다양한 안정성 대책을 세워봤죠

그중 하나가 오라클 인스턴스(san jose) 에 mediamtx나 nginx-rtmp 중개서버를 두고 우리집 서버에서 srt(udp 전송 및 패킷자동복구)로 영상 스트림을 전달하고 mediamtx에서 영상 데이터를 버퍼로 쌓아 우리집서버와 통신 불안정성을 커버하는 동시에 mediamtx가 유튜브서버(san jose 바로근처)로 백본망으로 안정적으로 rtmp 유지 및 전송

이론적으로야 좋죠. 근데 mediamtx 자체의 오버헤드 문제도 있고

KT DPI 패킷검사에 걸려서 의도적인 쓰로틀링으로 방송을 못하게 됐네요

일부러 일반적인 웹데이터인척 443포트로

udp패킷을 aes256 암호화 하고 passphrase 넣어서 못 알아먹게 했더니 오히려 DPI에서 VPN이나 P2P로 인식이 됐는지 24시간만에 쓰로틀링

그래서 렌더링 인코딩 부분과 영상 버퍼 및 유튜브서버와의 RTMP 관리 및 송출부분을 분리하기 위해 내부망 유선공유기로 또다른N100 서버에 중개프로그램 mediamtx를 설치해서 srt relay 를 시도해봤으나 여전히 오버해드 때문에 영상에 지터가 생기는 등 품질저하

워낙 부족한 리소스이다 보니 tcp든 udp든 한단계 거치면 품질저하가 생김

안그래도 ecs + igpu compute shader + zerocopy 구조로 극단적으로 cpu gpu ram 간의 계산 및 메모리 관리를 최적화한 모델이다 보니

렌더링과 인코딩송출 간에 tcp udp는 당연히 오버헤드 생기고 공유메모리도 안되고 pipe 로만 가능해서 단일PC에서 구동되어야만 하고 서버들 여러대에 분산하고 싶어도 못하네요

뭐 대신에 api라든지 db라든지 다른 영역은 서버별로 분산할 수 있겠지만요. 그런 데이터 패킷은 영상 스트림 패킷에 비하면 일단 사용자 눈에 보이지 않기 때문에 에러가 있더라도 여러번 검증 복구한 다음 반영할 수가 있으니 여유롭습니다

영상 스트림은 아주 조금만 어그러져도 즉시 느려지거나 떨리거나 뭉개져버리는게 이미 방송되어버리니까 복구할 기회 자체가 없으니까요