이 를 처리 하 기 위해서 , 비디오 압축기 ( 404 ) 가 해야 하 는 첫 번 째 는 피크 전송 률 ( 941 ) 을 결정 하 는 것 이 고 , 이 는 채널 이 지속 적 으로 다룰 수 있 는 전송 률 이 다 . 이 속도 는 많 은 기술 에 의해서 결정 된다 . 그런 기술 중 하나 는 호스팅 서비스 ( 210 ) 에서 도 4 a 및 4 b 에서 클라이언트 ( 415 ) 로 증가 하 는 높 은 전송 률 테스트 스트림 을 점차 적 으로 보낼 것 이 고 , 클라이언트 가 호스팅 서비스 로 어떤 수준 의 패킷 손실 및 레이턴 시 에 관하 여 피드백 을 제공 할 것 이 다 . 패킷 손실 및 / 또는 레이턴 시 는 날카로운 증가 를 보이 기 시작 할 때 , 그것 은 이용 가능 한 최대 전송 률 ( 922 ) 에 도달 하 고 있 다는 표시 이 다 . 그 후 에 , 호스팅 서비스 ( 210 ) 은 점차 적 으로 클라이언트 ( 415 ) 가 합리 적 인 주기 의 시간 동안 테스트 스트림 이 허용 가능 한 수준 의 패킷 손실 과 레이턴 시 가 거의 최소 로 수신 되 는 때 까지 테스트 스트림 의 전송 률 을 줄일 수 있 다 . 시간 이 지나 면 , 피크 전송 률 ( 941 ) 이 변동 하 게 되 고 ( 예컨대 , 만약 가정 내 에 다른 사용 자 가 과도 하 게 인터넷 연결 을 사용 한다면 ) , 클라이언트 ( 415 ) 는 패킷 손실 또는 레이턴 시 증가 의 여부 , 이용 가능 한 최대 전송 률 ( 922 ) 이 미리 확립 된 피크 전송 률 ( 941 ) 이하 로 떨어지 는지 의 여부 , 그리고 그렇 다면 피크 전송 률 ( 941 ) 인가 의 여부 를 알 도록 그 를 끊임없이 모니터 하 는 것 이 필요 로 된다 . 유사 하 게 , 만약 시간 이 지나 고 클라이언트 ( 415 ) 가 패킷 손실 및 레이턴 시 가 최적 의 수준 에 남 아 있 다는 것 을 발견 하 면 , 그것 은 비디오 압축기 가 천천히 이용 가능 한 최대 전송 률 이 증가 되 었 는지 를 보 기 위해서 전송 률 을 증가 하 도록 요청 할 수 있 고 ( 예컨대 , 만약 가정 내 에 다른 사용 자 가 과도 한 인터넷 연결 의 사용 을 멈춘다면 ) , 다시 패킷 손실 및 / 또는 높 은 레이턴 시 가 이용 가능 한 전송 률 ( 922 ) 이 초과 되 었 다고 지시 할 때 까지 기다리 며 , 다시 낮 은 수준 은 피크 전송 률 ( 941 ) 을 위해 찾 게 되 지만 , 하나 는 아마도 증가 된 전송 률 을 테스트 하 기 전 에 그 수준 보다 더 높 아 진다 . 그래서 , 이러 한 기술 을 사용 함 으로써 ( 그리고 이 와 같 은 다른 기술 ) 피크 전송 률 ( 941 ) 은 찾 을 수 있 고 , 필요 했 던 것 처럼 주기 적 으로 조정 된다 . 피크 전송 률 ( 941 ) 은 사용 자 에게 비디오 를 스트림 하 기 위해 비디오 압축기 ( 404 ) 에 의해서 사용 될 수 있 는 최대 전송 률 로 설정 될 것 이 다 . 피크 전송 률 을 결정 하 기 위한 로직 은 사용 자 구내 ( 211 ) 및 / 또는 호스팅 서비스 ( 210 ) 에서 실행 될 것 이 다 . 사용자 구내 ( 211 ) 에서 클라이언트 ( 415 ) 는 피크 전송 률 을 결정 하 기 위한 연산 을 수행 하 고 이 정보 를 호스팅 서비스 ( 210 ) 로 되돌려 전송 하 고 ; 호스팅 서비스 ( 210 ) 에서 , 호스팅 서비스 에 서버 ( 402 ) 는 클라이언트 ( 415 ) 로부터 수신 한 통계 치 ( 예컨대 , 패킷 손실 , 레이턴 시 , 최대 전송 률 등 ) 를 기초 하 여 피크 전송 률 을 결정 하 기 위한 연산 을 수행 한다 .