라이브 구현 계획

프로토콜

 

- webRTC:웹 브라우져 간에 플러그인 도움 없이 서로 통신할 수 있게 설계된 API 그러나 다른 프로토콜에 비해 많은 사용자를 받기 힘든 구조이므로 다수의 사용자를 받기 힘들다. 따라서 영상통화, 음성통화, P2P 파일 공유에 사용되는 중

=> 라이브 방송 구현이므로 다수의 시청자가 사용해야하므로 탈락

 

 

-MPEC-DASH: TCP기반 영상 전송 프로토콜, 최대 4K해상도 지원, RTMP랑 비교하자면 품질을 더 신경 쓰지만 레이턴시가 조금 더 소요된다. DASH 프로토콜 사용, RTMP보다 비용 저렴, 방화벽도 그냥 통과,(RTMP는 방화벽 통과하려면 수동으로 포트 열어야함)

 => 기존에 HLS프로토콜을 사용해서 영상 전송 기능을 구현했기에 DASH 방식으로 라이브 기능을 구현하는 것은 일관성있지 않으며 2가지 방식을 사용하는 것 자체가 관리도 2가지 방법으로 해야한다고 판단됨. 탈락 

 

 

 

- RTMP :스트리밍 서버어 adobe flasg player 간에 오디오 및 비디오 파일을 전송하기 위해 Adobe 에서 만든 프로토콜 

 

장점: 1) 많은 서비스에서 사용 중이기에 참고 자료가 많음

         2) Nginx-Rtmp 같은 라이브러리가 존재

단점: 1) 어도비가 flash 지원 중단해서 발전 가능성 x 

특징: TCP 기반 

 

-SRT : 오픈 소스 비디오 전송 프로토콜 레이턴시가 짧은 비디오 (속보, 스포츠 중계)및 미디어 스트림을 제공하기 위해 설계됨 보안성도 다른 프로토콜 보다 높으며 대부분 장치에서 호환이 가능하다. 그러나 참고자료가 부족하단 단점 존재 

특징: UDP 기반 

비교	rtmp	SRT
속도	빠름(TCP)	더 빠름(rtmp 2배, UDP)
대역폭	송수신자가 같은 대륙에 있어야함 2Mbps 이상 비트레이트 전송 시 장거리 전송 실패율 높음	전 세계 20Mbps 비트레이트 까지 가능
보안 , 안정성	좀 취약	AES 128/256 암호화 기반으로 전송중인 콘텐츠가 안전하게 보호됨 오류 수정 메커니즘(자동 반복 요청, 패킷 손실 캐싱, 전방 오류 수정) 이 있음
사용자 환경에 최적화	HLS 프로토콜로 가능함	적응형 비트레이트스트리밍으로 사용자 환경에 따라 영상 품질 최적화
호환성	참고 자료 많고, 접근성 높음 소규모 인스턴스에서도 활용가능! 메모리 사용량 낮음(t3 small 가능, 720p, 시청자 20명 이하라는 전제 하 ㅜㅜ)	시작하려면 고성능 서버, 충분한 대역폭 필요 최소 aws c5 large 이상 필요.....

 

 

결론: SRT가 고성능이긴 하나 프로젝트 개발 비용 문제와 규모 고려시 RTMP가 적합 

 

RTMP의 라이브러리(무료)

- NginX-RTMP: 많은 시청자를 웹서버에서 로드벨런싱 하기 위해 사용 또한 로드밸런싱기능 뿐만 아니라 프록시 서버에서 FFMpeg 으로HLS 변환 작업 이뤄짐, 자료 많음, OBS 가능

 

 

- mistserver:앞서 나온 프로토콜 전부 지원가능, GUI 지원, 자료도 많음, OBS가능

https://mediaserver.tistory.com/2

윈도우 MistServer 구축 및 사용방법 (부제:OBS로 VRChat에 영상 전송하기)

 

베포환경인 t3 small에서의 적합성

	mistserver	NginX-RTMP
CPU 및 메모리 사용량	상대적으로 높음	매우 낮음
동시 접속자 처리	적당한 튜닝 필요	기본적으로 동시 사용자 수에 강점
프로토콜 지원	HLS, DASH, RTMP, WebRTC 등 다수 지원	RTMP, HLS만 기본 지원
설치 및 설정	복잡하나 GUI 제공	간단한 설정 파일로 동작
리소스 효율성	높은 수준의 자원 활용	경량화 설계, 제한적 리소스 사용

 

결론: 향후 트래픽 증가시 로드밸런싱이 가능하며 메모리 사용량이 낮은 NginX-RTMP가 적합하다고 판단