1901;팔리면 1656;문Ȣ16;1648; 맙시다. 소1473;한 NJ13;변 댓글1012; 삭1228;Ȣ16;lj16;,148; ǥ12;-124;러운 1068; 1077;니다 
요1608; 개1064;1201;1004;/196; ipmi/ip kvm1012; 만들Ǻ12;보고 1080;습니다.
서버lj16; linux vm1060;고, 1064;텔내1109;그래픽1060; pass through .104;Ǻ12; 1080;습니다.(vaapi 사용가능합니다)
hdmi capture board가 1109;착.104;Ǻ12;1080;Ǻ12; yuyv, mjepg/196; 영상 신호를 0155;아Ꮢ1;니다.
그런데 처1020;ǥ12;터 문1228;에 봉착했습니다. gstreamer/196; h264/vp9 1004;/196; tcp/196; 송출Ȣ16;lj16;데, 720p에서도 latency가 3초-5초나 .121;니다
도움1012; 요청드립니다 ㅠㅠ
송출/전송/디코딩에는 그렇게 많은 지연이 발생하지는 않았고 (이것도 하드웨어 도움 없이는 1-2초는 나오더라구요)
저의 경우에는 제일 문제는 캡쳐카드였습니다. 로컬로 캡쳐카드를 바로 봐도 몇초 차이가 나서..
전문적인 캡쳐카드 (PCIe 기반) 을 사용해야 IPKVM 정도의 레이턴시가 맞춰지는것 같습니다.
vlc 등에서 mjpeg / 버퍼링 30ms 정도로 하면 크게 지연이 느껴지지 않게 사용이 가능합니다.
버퍼링이 짧을수록 끊어질 가능성이 높아지긴 하지만 3~5초 레이턴시라면 다른쪽 버퍼링을 의심해 보시는게 좋지 않을까 합니다.
근데 h.264/vp9이 먼가요? vp9은 코덱이지 컨테이너가 아닐텐데요..
yuyv를 h264/vp9으로 인코딩해서 webm으로 전송했다는 의미였습니다
usb2.0 으로 되어있는 녀석은 yuv로 하면 FHD 에서 초당 5프레임 겨우 받는것 같더라구요.
캡쳐 장치에서 제공하는 압축 방식 그대로 전송하는게 레이턴시 측면에서는 가장 좋을 것이고
그 이후에는 하드웨어 인코더를 제공할 경우 제공하는 비디오 코덱으로 변환하는게 그나마 적은 레이턴시를 얻지 않을까 합니다.
gstermaer로 테스트 해보신다면 udp로 일단 테스트 해보시면 좋을것 같습니다.