제온프로 05-15

아마도 Ai 알고리즘으로 손실된 부분을 보충 한다는 뜻 같습니다.
당연 원 화상과는 쪼끔은 다르겠죠.

dragoune 05-15

음성 통화(zoom phone)에서도 45% 저런다고 하는데 그럼 역시 ai로 음성을 보충하는거려나요...
과연 제대로 된 음성일지도 신경쓰이네요... 음

나로와 05-15

회사에서 줌 사용하는데 끊기지는 않지만 영상은 퀄리티 떨어지고 심해지면 프레임 스킵되고 보이스도 퀄리티 떨어지다가 동일하게 스킵 일어나던데요
심해지면 그냥 끊김니다 45% 손실은 어떤의미 인지 모르겠네요

dragoune 05-15

저희도 외부 미팅 때 가끔 사용하는데, 솔직히 다른것들과 비교해서 그렇게까지 좋다? 는 못 느껴봤는데
저 45%가 무슨 의미인지를 모르겠어요 ㅋㅋㅋ

올닉스 05-15

UDP사용하지 않나요?
음성은 왜곡된 내용으로 전달 할 수도 있겠네요

dragoune 05-15

아마도 WebRTC 일거라고 생각되니 TLS 캡슐링된 UDP일텐데
어떻게 오류 정정을 하는지 상상도 안가서 여쭤봅니다. ㅎㅎ;

올닉스 05-15

캡슐링되어 있다면 상대방 전송된 이후에 뭔가 처리가 될 수밖에 없겠네요

dateno1 05-15

걍 안 끈키고 버틸 수 있다정도로 봐야 합니다

아무리 보정해봤자 45%나 날아가면 원본이랑 완전히 다를테니까요

거기다 대역폭이 충분하면 재전송 (화면이나 음성이 순간 이상해지겠지만)해서 때우기도 하겠죠

dragoune 05-15

그렇죠? 45%나 손실이 발생하면 대체 뭘 어쩌겠다는건지 정말 감도 안잡힙니다.
재전송한다고 해도 재전송 데이터에서도 45% 손실이 발생할 수 있을테고
결국 얼기설기 이어붙여도 손실률이 20%는 나올것 같은데 말이죠

구차니 05-15

셋 중 하나겠죠

손실을 감수하도록 리던던시를 포함해서 두 번 전송(?) 하던가
손실 복원 기능이 쩔어줘서 반쯤 날아가도 나머지 데이터로 복원하던가
혹은 데이터가 겁나 많이 소모하도록(즉, 고품질로 전송해서 데이터가 많으면, 데이터당 단위 시간은 짧으니) 반쯤 잘려도 사람이 듣는데 지장이 없던가..

dragoune 05-15

voip 라면 20ms 단위로 패킷을 전송하니까 물량으로 동일 패킷을 10번쯤 보내고
jitter buffer에 담아뒀다가 재생하면 되긴할...까요? 으허허헛;;

박문형 05-15

저 내용은 그냥 자기네 솔류션이 좋다는 마케팅성의 글로 생각됩니다..

앤디캔디 05-15

우리 차 최대 100키로 나가요
근데 운전하실땐 20으로 고정시켜드려요

dragoune 05-15

어느정도 과장이야 할 수 있겠지만 45%라는건 정말....
5~10%만 손실이 발생해도 음성이 끊겨서 전화 못하겠다는 클레임이 들어오는데 말이죠

술이 05-15

화상 음성통신은 TCP 프레임이 아니라 UDP 입니다. 한쪽이 잠시 끊어져도 그 패킷을 날려버리지 않고 임시적으로 캐쉬에 보관하는게 아닐까 싶네요. TCP는 세션 날라가면 손실인데 UDP는 데이터값이 날라가지 않으면 그대로 보낼수 있는 장점이 있죠. 단점이라면 UDP 캐쉬가 네트워크단에서는 매우 작습니다. 텍스트기반 데이터만 캐쉬로 쓰게 되어 있는데 용량큰 화상 음성 같은건 별도로 캐쉬서버 두는게 아닌가 싶습니다.

dragoune 05-16

그렇죠 TCP로는 불가능한 부분으로 인식하고 있습니다.
아무리 생각해도 45% 패킷손실에서 제대로 통화가 가능할리가 없는데 말이죠
OS에서 캐시를 늘려봤자 한계가 있을거고, 캐시를 미친듯이 늘려서 재전송을 한다고 해도
받는 쪽에서 패킷손실로 제대로 못 받으면 아무리 다시 보내봤자 한계가 있고
그 한계를 극복하기 위해 재전송을 반복하면 이미 실시간통화가 아니게 되니까요

epowergate 05-16

기술적으로는 78%던가 87% 던가 수준의 에러를 보정하는 기술이 있습니다.
이미 90년대에 완성된 기술일 겁니다
RDS와 비슷한 Protocol들이 있습니다.
Reliable Datagram Service인텐데 UDP처럼 Datagram 방식이지만 TCP처럼 Reliable 한 프로토콜 입니다.

결론은 방법은 많습니다

사누스 05-16

에러 보정과 패킷 드랍 처리는 완전 다른 이야기죠. 미디어 스트림에서 패킷이 중간에 빠지면 여러가지 방법으로 어떻게든 그걸 보완하려고 하지만 그걸 에러 보정이라고 표현하지는 않습니다.
RDS라는건 결국 UDP 위에 TCP와 유사한 기능을 하는 레이어를 하나 추가해서 connection-oriented는 아니지만 TCP와 유사한 기능을 추가한거지 그게 일반적인 줌 회의 같은데서 패킷 드랍 45% 일어날 때 지연 없이 회의를 정상적으로 할 수 있게 뭘 해줄수 있는건 아니죠.

epowergate 05-16

Error는 Modified / Missing / Add 3가지를 모두 포함합니다.
Packet Drop도 에러의 한 종류이지 다른 카타고리가 아닙니다

사누스 05-16

Error correction은 발생한 에러를 FEC를 사용하건 패킷 재전송이건 어떠한 방법을 사용해 원래 데이터를 복원 해 내는걸 말하죠. 지금 줌 회의같은 미디어 스트림에서는 패킷로스로 인해 발생하는 문제를 완화하기 위해 사람들의 인지를 속이는(?) 방법들일 뿐 그걸 에러를 보정한다는 표현을 쓰지는 않죠.

epowergate 05-16

통신 관점에서는 보정과 복구가 거의 차이가 없습니다.
Error correction을 하다가 실패하면 push건 pull이건 resend를 해서 복원을 합니다.
데이터 관점에서의 보정은 복구와 차이가 있습니다.
복구는 Resend없이 다양한 데이터로부터 오류난 정보를 100% 복구하는 것이고
보정은 오류 난 데이터 복구가 실패 했을때 주변의 정보로 데이터를 만들어 내는 것을 포함합니다.
어차피 source-dest의 데이터가 100% 정합성을 요구하지 않는 ZOOM등의 프로그램에선 쉽게 복원이 가능합니다.
그런데 보정은 100% 정확도를 보장하지는 않습니다.

그것보다 Zoom에서 말하는 것은  45%는 패킷 drop이 있어도 서비스가 가능하다  수준으로 써있습니다.
어디에도 잃어버린 45%를 복원한 정보를 다른 회의 참석자들에게 제공한다고 나와있지 않습니다.

사누스 05-16

저건 그냥 사기수준의 과장광고일 뿐입니다. 저런 환경에서도 세션이 끊어지지는 않아요하고 그래도 불구하고 쓸만하게 회의(대화)가 가능해요는 하늘과 땅 차이입니다.
저 수치를 어떻게 얻었는지 몰라도 다른분들 말씀대로 랩 환경에서 설정은 최고 품질(예를 들어 10Mbps정도)로 해 놓고 패킷 45%정도 드랍되면 자동으로 품질 팍 낮춰 최저(128Kbps 정도)로 바꾸고 동일 패킷 여려번 재전송하면 가능할수는 있겠지만요.

dragoune 05-16

그러면 시차가 생기니까 실시간 화상회의가 성립하지 않는게 아닌가 싶은데
Zoom이 작은 회사도 아닌데 홈페이지에 저렇게 당당하게 걸어두니까 어? 진짠가?? 싶기도 하고
혼란스럽니다. @_@