실버라이트같은 걸로 묶어 버리는 곳에서는 무용지물…
먼저 캠유저에서 파일 정보를 살펴봅니다.
아래 영상은 감천님이 제작하신 영상입니다.
(원본: http://www.camuser.kr/zbxe/?document_srl=124606)
재생 화면에서 마우스 오른쪽 버튼을 클릭! 아래와 같은 메뉴가 나옵니다.
[속성] 메뉴를 선택하면 아래와 같은 ‘등록 정보’ 화면이 나옵니다.
길이 : 동영상의 재생 시간
비트 전송률 : 압축할 때의 비트레이트를 말합니다. (비디오 + 오디오를 모두 합침)
미디어 유형 : 비디오 인가 오디오 인가 (WMA도 동일한 속성을 가지므로)
비디오 크기 : 실제 원본 화면 크기를 말합니다. (1440×1080, 1920×1080, 1280×720, 960×540 …)
가로 세로 비율 : 원본의 가로 세로 비율을 말합니다. (4:3 또는 16:9)
오디오 코덱 : 오디오 코덱 버전과 오디오의 비트레이트를 볼 수 있습니다. (오디오 비트레이트는 128K, 샘플레이트는 48kHz)
비디오 코덱 : 비디오 코덱을 볼 수 있습니다. (현재까지는 WMV9가 최신)
위치 : 현재 동영상 파일의 위치, URL 등이 표시됩니다. 주소가 HTTP인 경우에는 URL로 바로 다운로드가 가능합니다만, 캠유저에서는
URL에 스크립트를 걸어 두었기 때문에 다운로드가 안됩니다. 즉, 실제 주소는 서버가 가지고 있고, 미디어플레이어가 주소를 요청하면 서버가 그
주소를 해독해서 실제 주소의 파일을 전송해 주는 방식입니다.
다음은… [통계] 메뉴를 클릭했을 때 보여지는 화면입니다.
통계화면은 ‘기본’ 탭과 ‘고급’ 탭으로 구분되는데… ‘고급’ 탭을 살펴봅니다.
미디어
– 최대 비트 전송률 : 인코딩 했을 때의 비트레이트를 말합니다. 비디오 3M + 오디오 128K
– 선택한 비트 전송률 : WMV는 스트림을 용량별로 여러개 만들 수 있습니다. 예를들면, 저용량 1M 짜리 1개와 3M 짜리 1개를
WMV 파일 하나에 모두 넣어 두고, 사용자의 인터넷 속도에 따라서 서버가 골라서 내보 낼 수 있는 기능입니다. 이렇게 멀티 스트림을 만들 수
있는 프로그램은 미디어인코더9 또는 프로코더3 등에서 가능합니다.
연결
– 사용 가능한 대역폭 : 서버에서 대역폭을 제한 한 경우엔 대역폭이 표시 됩니다. 캠유저는 대역폭 제한이 없는가 봅니다.
– 사용 중인 대역폭 : 제 PC에서는 캠유저 서버와의 대역폭은 17Mbps 정도가 나옵니다. 이 사용중인 대역폭이 선택한 비트 전송률
보다 느리다면 버퍼링이 발생되겠지요.
– 프로토콜 : 캠유저는 HTTP로 스트리밍합니다. HTTP는 파일을 통째로 서버에서 내보내는 방법입니다. 따라서 사용 가능한 대역폭으로
데이터를 다 쏟아 보내버립니다. 위 예에서는 3M 짜리 동영상을 초당 17M로 다운로드 하게 됩니다. 이 경우 짧은 시간에 많은 트래픽이
발생하게 됩니다.
비디오
– 건너뛴 프레임 수 : PC사양이 느려서 재생이 순조롭지 않다면 건너뛰는 프레임이 생길 수 있고, 이 경우 끊기는 영상으로
봅입니다.
– 프레임 속도 : 실제 인코딩된 원본의 프레임 수
– 실제 속도 : 재생되는 프레임 수. PC의 사양에 따라서 원본 프레임 수와 재생 프레임 수는 다를 수 있습니다.
패킷 : 전송되는 패킷 수입니다. 패킷 손실이 발생할 경우는 네트워크 선로 상태가 매우 불량한 경우에 발생할 수 있습니다.
이해를 돕기 위해 다른 예를 보여드립니다.
혹성탈출님의 24p로 제작하신 영상입니다.
(원본:http://www.camuser.kr/zbxe/?document_srl=127139)
간편하게 설명하면, 비트전송률은 비디오와 오디오를 합쳐 3.99Mbps 이고, 오디오는 48Kbps 입니다. 비디오 코덱은 WMV9
해상도는 1280×720 으로 16:9 비율을 가지고 있습니다.
통계메뉴를 살펴보면, 원본 전송률은 3992K 이지만, 현재 인터넷 다운로드 속도는 42M 로 나오네요. ^^ 캠유저는 이렇게 속도가
들쑥날쑥 합니다. 이유는 아까도 설명했다 시피, 사용자가 동시에 몰리면 고트래픽이 발생하여 전체 스트리밍 속도가 느려지지요.
이 영상이 24p로 제작되었다는 것은 프레임 속도를 보면 알 수 있듯이 23.9로 나오는데, 정확하게는 23.976fps 인데, 소숫점
뒤에 안보이네요. 24p 제작 방법에는 네이티브 24p나 23.97p 등이 있는데 무엇이 다른지 저도 잘 모르겠군요..
다음 예는 60i 소스를 60p로 디인터레이스하여 60p로 인코딩하여 재생하는 영상입니다.
정토님의 영상입니다.
(원본 http://123.212.99.154/bong/sss/0911.wmv)
WMV 소스가 60p 이고, 재생도 60p로 재생합니다.
인터넷 속도탓에 영상의 처음 부분에서 프레임이 다소 드롭되었습니다.
다음 예는 60i 소스를 60i로 인코딩해서 60p로 재생하는 영상입니다.
(원본 mms://www.camuser.info/laizenti/blog/프로코더AD.wmv)
WMV 소스는 60i이기 때문에 프레임 속도는 29fps로 나옵니다만,
재생할때 디인터레이스 처리를 해서 60p로 보여줍니다.
실제 재생속도는 실시간으로 디인터레이스를 해야하기 때문에 저사양 PC에서는 약간 끊김이 발생합니다.
또 다른 예를 보여드립니다. 오늘의 하일라이트입니다.
이 영상은 1프레임 짜리 WMV 영상입니다.
(원본 http://blog.naver.com/laizenti/40060633379)
등록정보에서는 캠유저의 영상들과 크게 다르지 않습니다.
위치에서 mms 프로토콜을 사용하고 있는 점이 다릅니다. mms 프로토콜은 이제 거의 사용되지 않고 미디어플레이어에서 자동으로 RTSP
프로토콜로 변환해 줍니다. RTSP 프로토콜에 대해서는 아래에서 설명합니다.
통계 메뉴에서 살펴보면, 인코딩된 원본의 비트레이트는 비디오 6M + 오디오 128K 입니다만, 사용중인 대역폭은 달랑 605.9K 밖에
되지 않습니다. 그렇다고 서버가 꼬질려서 속도가 600K 밖에 나오지 않는것이 아니라, 실시간 재생되는 데이터량이 600K 밖에 안된다는
이야기입니다. 즉, 6Mbps 짜리 동영상을 600K로 재생하고 있다는 이야기. 이것은 HTTP와 다른 RTSP 프로토콜을 사용하기 때문인데
RTSP 프로토콜은 HTTP와 다르게, 실재 재생될 비트 전송률만 네트워크로 흘려 보냅니다. 조금씩 조금씩. 한꺼번에 왕창 내보내는 HTTP와
다른점이 이 부분입니다. 따라서 순간적인 고트래픽이 발생되지 않아 안정적인 스트리밍이 가능하다는 것도 장점입니다.
RTSP의 경우, 플레이의 정지 버튼을 누르면 더이상 다운로드를 받지 않습니다. HTTP도 마찬가지지만 영상의 시작 부분만 조금 보다가
그만 볼 경우, RTSP는 재생된 시간까지만 트래픽이 발생하지만, HTTP는 그 짧은 시간동안 내 보낼 수 있는 모든 트래픽을 다 사용해 버리기
때문에 트래픽의 낭비가 심하지요. 또한 RTSP는 건너뛰기 즉, 1시간 짜리 영상의 경우, 중간부터 보고 싶을때 바로 건너 뛸 수 있지만,
HTTP는 다운로드를 다 받아야지만 seek가 가능하다는 것도 차이점이라고 할 수 있겠네요.
또한 6M 짜리가 600K로 재생이 가능한 것은 프레임 속도가 1fps 라는 점 때문입니다. 즉, 1초에 1장의 이미지만 재생하고 있다는
말인데…
보통 동영상을 만들때 30fps 정도를 사용합니다. 이 영상은 1프레임으로 만든 그러니까.. 바로 스틸 사진으로 만든 동영상이
되겠습니다.
동영상이라고 하기엔 좀 그렇지요.. 움직이지도 않아서… 그냥 사진을 슬라이드로 본다는 정도가 되겠습니다. 1프레임짜리로 만들면 화질이
어느정도 나오는지 테스트용으로 만든 것이라… 저용량, 고화질 그런 목적입니다. ㅎㅎ
이 테스트는 24p, 30p, 60p, 60i로 인코딩할때의 트래픽 유용성 검증에 좋은 자료일듯 합니다.
결론
요즘은 추세가 플래쉬로 만들어 버리거나, WMV라 하더라도 실버라이트로 묶어 버리기 때문에 이런 스트리밍 테스트는 해볼 수는 없을 것
같습니다. (플래쉬나 실버라이트에서도 스트리밍 테스트 툴은 있겠지만) 인터넷 영상이 대부분 비트레이트로 결정되는 상황에서 비트레이트나 프레임
수를 자동으로 표기해 주는 센스가 필요하지 않을까 생각됩니다. ^^
[펌] blog.naver.com/laizenti/40062018749