WebRTCHacks에 ‘Comparing WebRTC video codecs with a proper dataset’이라는 글이 올라왔어. Microsoft의 화상회의 데이터셋인 VCD(Video Conferencing Dataset)를 쓰고, Claude한테 libWebRTC(WebRTC의 네이티브 구현체)가 제공하는 도구로 코덱 비교를 시켰다는 내용이야. 그러니까 이건 그냥 코덱 스펙 비교가 아니라, 실제 화상회의 영상, 그것도 P2P 연결에서 주로 쓰는 WebRTC 툴링으로 돌린 결과라는 뜻이야. 글에서 가장 놀라웠던 결과로 꼽은 건 배경 블러를 켰을 때 H.264가 훨씬 효율적으로 나온다는 점이었어. 적어도 ‘어떤 데이터로 비교했는지’가 명확해진 건 의미가 있어. 자세한 내용은 webrtcHacks 원문에서 볼 수 있어.
이 뉴스가 흥미로운 건, 코덱 선택이 곧 P2P 실시간 통신의 비용 문제와 직결되기 때문이야. WebRTC는 브라우저끼리 직접 미디어를 주고받는 구조라서 중앙 서버가 대역폭을 보장해주지 않아. 그러니까 같은 화질을 더 적은 비트레이트로 보내는 코덱이 곧 더 나은 연결 성공률, 더 적은 지연, 더 낮은 서버 비용으로 이어져. 배경 블러 같은 클라이언트 측 필터가 화면에서 불필요한 텍스처를 줄여주면, 인코더가 덜 바빠지고 그 여유가 실제로 코덱 효율로 나타난다면, 이건 ‘기능 추가’가 아니라 ‘네트워크 비용 절감’으로 읽어야 해. PonsLink에서도 영상 전송을 직접 다뤄보면서, 클라이언트 처리를 어떻게 설계하느냐가 서버 부담을 크게 좌우한다는 걸 실감했어.
VCD 같은 실제 화상회의 데이터셋이 중요한 이유는, P2P 미디어 최적화가 ‘합성 영상’으로는 검증이 어렵기 때문이야. 조명, 카메라 노이즈, 사람의 움직임, 배경 복잡도가 다 다른 실제 회의 장면이 필요해. 그 점에서 VCD는 꽤 반가운 재료야. libWebRTC를 돌리는 스크립트는 에코 제거나 네트워크 적응 같은 웹 실시간 통신의 핵심 요소까지 함께 흉내 내주니까, 단순한 인코더 벤치마크보다 P2P 운영에 가까운 결과를 보여줘. PonsWarp 같은 초기 MVP도 결국 이런 ‘실제 조건’을 얼마나 빨리 재현해내느냐가 관건이야. 코덱 파라미터를 바꿔가며 네트워크 변화에 어떻게 반응하는지, 그걸 데이터로 확인하는 습관이 없으면 분산 시스템은 감으로 굴러가기 쉬워.
앞으로 두 가지를 지켜보면 좋을 것 같아. 첫째, 이 비교가 VCD의 어떤 조건에서 반복될 수 있는지야. 같은 데이터셋이라도 해상도, 프레임률, 네트워크 손실 프로파일에 따라 순위가 바뀔 수 있어. 둘째, 배경 블러-코덱 효율 관계가 다른 코덱 조합에서도 같은 방향으로 나오는지야. H.264만이 아니라 VP9, AV1 같은 최신 코덱도 같은 실험을 돌려보면 P2P 클라이언트 설계에 바로 참고할 수 있을 거야. 우리도 다음엔 이 데이터셋을 실제 WebRTC 테스트에 붙여보고, 나오는 수치를 우리 운영 관점에서 해석해볼 생각이야. 좋은 비교는 ‘누가 이겼나’보다 ‘어떤 조건에서 무엇이 유리한가’를 알려줄 때 의미가 있으니까.
댓글