김상진 2014-08

말씀하신 500메가는 초당이 아닌 분당같네요
-->60hz때문에 곱한  60때문 아닐까요?

미크로틱 2014-08

에 또 60hz 면...초당 60이 맞는거 같은데요..

김상진 2014-08

아 제가 잘못 생각했네요

김은호 2014-08

알파값을 사용하여 8/8/8/8 총 32비트로 계산할 때 무압축 데이터량 (오버헤드값 무시)
1920x1080x32bit/8byte*60Hz = 474MByte/sec

RGB값만 사용하여 8/8/8 총 24비트로 계산할 때 무압축 데이터량(오버헤드값 무시)
1920x1080x24bit/8byte*60Hz = 356MByte/sec

RGB가 아닌 YUV420형식 1920x1080 60Hz 캡쳐형식의 경우 무압축 데이터량(오버헤드값 무시)
1920x1080x12bit/8byte*60Hz = 178MByte/sec

알파값 사용여부를 떠나서 실제 h.264로 데스크탑화면을 캡쳐해다가 충분한 화질로 전송할 경우
1080p60f 기준으로 움직임이 거의 없는 정적화면일 때는 3~5Mbps로도 충분합니다. 움직임이 심한 게임화면
등을 5Mbps 수준으로 전송했다간 화면에 박스들이 신나게 펼쳐질 것이고, 15~30Mbps 정도로요구량이 껑충
뜁니다.

WiDi가 만약 h.264 압축영상형식으로 보내게 되면 사실 현 무선기술에서는 껌에 가까운 속도며, 벽, 다른 종류의
근접주파수 전파로 인한 노이즈로 패킷 드랍이 생기지 않는 이상 802.11g 로도 될 것 같습니다. HEVC로 압축하면
대략 H.264대비 60%수준으로 압축이 가능하다고 하니 WiDi같은 기술에 코덱칩만 적용되면 더 수월하겠죠.

김상일 2014-08

좋은 내용 감사합니다..

김은호 2014-08

정적 화면 기준으로 RGB 색상 무압축데이터가 거의 1/560 비율인 700KByte/sec(5Mbps)수준까지 압축이 되는 이유는 움직임이 거의 없으니 압축알고리즘에서 "이미지 하나"로 인식하고 그 이미지가 "정해진 시간까지 그 자리 그대로 있음"이라 지정만 하면 일일이 장면마다 화면을 저장할 필요없이 이미지하나와 위치정보만 기억해두면 되니 압축률이 획기적으로 향상되는 원리입니다. 더 복잡하게 들어가면 이럴 때는 이렇게 저럴 때는 저렇게, 온갖 조건을 대입하여 데이터량을 절약할 수 있는 방법은 다 쥐어짜네서 압축하게되지요. 손실압축이기에 이런 것이 가능한 것이고요, 비손실압축의 대표적인 zip, rar, 7z 등 압축파일묶음은 압축풀면(비디오에서는 재생하면) 원본 그대로 나오게끔 해야하기 때문에 압축한도가 한계가 있습니다. 비디오의 경우도 무손실압축모드가 있긴한데 50% 줄이는 게 한계죠. 손실모드야 비스무리하게끔 보이면 되니 뺄 건 다 빼고 별의별 트릭을 다 겁니다.
 컬러도 RGB888이 아닌 인간의 눈에서 구분하기 힘든 영역의 색상데이터를 줄여서 더 빡빡하게 압축하는 게 보통입니다. 흑백티비 시대부터 이어져내려온 휘도신호 Y(검은색부터 흰색까지 그레이스케일)에 컬러티비시절부터 추가된 색차신호 Pb/Pr 또는 Cb/Cr 방식으로 변환하고, 여기서 인간의 눈으로 그냥 봐서는 구분하기 힘든 색차영역의 데이터를 줄여서 압축효율을 향상시킵니다. 합쳐서 YUV라 부르는데 YUV444가 RGB888과 동일하게 24비트 데이터량입니다. YUV422로 색차부분을 각각 4비트씩 8비트 줄여 16비트데이터량으로 만들고(YUV422), 색상 손해를 보더라도 압축을 위해 더 줄이면 YUV420으로 12비트까지 내려가니 순수데이터량으로만 따져도 원본에서 반으로 줄어드는데 화면자체는 일반인이 그냥 봐서는 별 티가 안납니다. 둘 다 갖다놓고 비교해봐야 그제서야 알 수 있을 정도이지요. 블루레이가 보통 이 color depth모드를 씁니다. 코덱은 h.264나 VP7인가 8인가하고 VC-1인가 몇 개인가 쓰는 것 같고요. 코덱이 무엇이던간에 기본적인 원리는 비슷비슷하게 동작합니다.

송상병 2014-08

Windows 8.1 에는 기본적으로 무선 기능 프로젝터에 확장 가능하도록 쓸 수 있습니다.

인텔 WIDI 가 상위로 가면서 미라 캐스트로 통합 된 것 같네요.