|
|
목차 인터넷 트래픽 모바일 인터넷 트래픽 HTTP Adaptive Streaming HTTP Adaptive Streaming의 문제 HTTP Progressive Download HTTP Progressive Download의 문제 3. Mobile Video Optimization 기술 Video Pacing Online Transrating/Transcoding Dynamic Bit Rate Adaptation |
2. OTT 비디오 전달기술과 무선망 환경에서 문제점
자기 통신망을 소유하고 있지 않아 IP 네트워크 QoS를 제공받을 수 없는 OTT 사업자는 이용자에게 비디오 품질(끊김 없는 화면)을 보장해주기 위해 HTTP PDL (HTTP Progressive Download)이나 HTTP Adaptive Streaming 방식을 사용하고 있다. HTTP Adaptive Streaming은 애초부터 단말과 스트리밍 서버간에 가용대역폭이 가변적인 상황을 전제로 만들어낸 스트리밍 방식이므로 모바일 단말에 적용하는 것이 자연스러운 반면에 HTTP PDL는 비디오 컨텐츠의 인코딩율보다 빠르게 가능한 최대한 빠르게 다운로드 해주는 방식이어서 무선망 환경에서는 단말과 서버간에 가용 대역폭이 높아도 낮아도 가변적이어도 모두 문제가 발생한다.
HTTP Adaptive Streaming: HTTP Adaptive Streaming은 클라이언트가 네트워크 상황-매 청크의 Download Speed-과 단말 상황-단말의 Video Rendering Capability (CPU/RAM 부하상태), 단말의 스크린 해상도, 화면상황(백그라운드 or 풀스크린)-을 고려하여 다음 요청할 청크의 비디오 품질 레벨 (해상도, 인코딩율)을 결정하고 웹서버로 요청한다. 따라서 단말과 서버간에 가용 대역폭이 감소하면 비디오 품질을 낮추고 증가하면 비디오 품질을 높여 가면서 끊김 없는 시청이 가능하다(망적응성). 즉 HTTP Adaptive Download는 QoE 보장형 기술이다.
HTTP Adaptive Streaming은 HTTP PDL와 달리 가용한 최대 대역폭으로 파일 전체를 한번에 다운로드받는 것이 아니라 클라이언트가 서버로 2초에 한번씩 지속적으로 청크를 요청하여 받아가기 때문에 딱 보고 있는 만큼의 비디오 파일이 단말로 전달된다(스트리밍). 따라서 정액제여도 통신사업자는 망대역폭 낭비가 없으므로 문제가 없고 종량제이어도 이용자는 시청한 분량만큼만 통신 비용을 지불하면 되므로 억울함이 없다.
HTTP Adaptive Streaming의 문제: 그러나 이 좋은 HTTP Adaptive Streaming도 문제가 있는 데 Adaptive Streaming을 위해 OTT 오리짂 서버에 비디오 품질 레벨 수만큼의 트랜스코딩된 비디오 파일을 생성해야 하며 또한 현재는 HSS, HLS, HDS의 서로 다른 포맷으로 패키징을 해야 한다. 예를 들어 한 컨텐츠당 18개 (3 포맷 x 6개 비디오 품질)의 파일을 물리적으로 생성해야 하며 논리적으로는 수천 개의 청크를 관리해야 한다. 따라서 OTT의 비용 (트랜스코딩/패키징 비용, 스토리지 비용)이 크다. Netflix같은 대형 유료 OTT의 경우는 이 것이 가능하지만(Netflix는 Microsoft HTTP Smooth Streaming을 사용함. 또 Netflix는 트랜스코딩과 패키징은 자기가 직접 하지 않고 아마존의 AWS(Amazon Web Service)를 홗용함), 소규모 OTT나 특히 YouTube처럼 무료 서비스를 제공하면서 UCC 기반이라 매주 수십만 개의 새로운 동영상이 업로드되는 OTT의 경우 트랜스코딩 및 스토리지 비용이 상대적으로 저렴한 HTTP PDL 방식을 여전히 고수하고 있다.
HTTP Progressive Download: HTTP PDL는 비디오 컨텐츠의 단말로의 전달을 PC에서 일반 데이터 파일을 다운로드(HTTP/TCP)하는 것과 동일하게 취급한다. 스트리밍이 아니고 다운로드이다. 딱 하나 다른 점은 일반적으로 파일을 다운로드할 때는 다운로드가 완료되어야 그 컨텐츠를 볼 수 있는 데 PDL는 비디오 파일을 다운로드하면서 초기 일정량이 다운로드되면 바로 재생에 들어가면서 다운로드를 계속한다는 점이다. 파일을 다운로드할 때의 속도는 서버와 클라이언트간에 가용한 최대 속도(TCP이므로)로 다운로드를 하며 네트워크 상황이 좋으면 비디오의 재생율보다 훨씬 빠른 속도로 다운로드를 받는다(그림 3의 a). 일정량이 채워지고 재생에 들어가면 이후의 패킷 수신은 손실이 있거나 지터가 커도 아무런 문제가 되지 않고 끊김 없는 화면이 제공된다(패킷 손실이 발생해도 화면 재생 전에 TCP로 재전송 받아와도 문제가 안될 만큼 충분한 시간적 여유가 있으므로).
HTTP Adaptive Streaming과 달리 HTTP PDL는 망상황 적응력이 없어(재생 중에 비디오 비트율을 스위칭할 수 없어) 다운로드 속도가 인코딩율보다 빠르면 재생되나 늦으면 로딩이 발생한다. 즉, HTTP PDL는 QoE 보장형 기술이 아니다(복불복). 그래도 유선 액세스망 환경이 이미 광대역화되어 있고 비디오 컨텐츠의 생성 및 운영 비용(트랜스코딩, 스토리지 비용)이 작아서 맋은 OTT들이 HTTP PDL 방식을 사용하고 있다.
HTTP Progressive Download의 문제: OTT 사업자들(예, YouTube3)이 서비스 단말을 모바일로 확장하면서 모바일 단말로의 비디오 컨텐츠 전달을 유선 PC로 전달하던 HTTP PDL 방식을 그대로 적용하고 있다. 그런데 무선망 환경은 유선망과 달리 단말의 가용대역폭이 지극히 가변적이고 무선 구간 대역폭의 희소성으로 인해 정액제뿐만 아니라 다양한 요금제가 적용되고 있어 HTTP PDL 방식으로 모바일 단말에 비디오를 전달하면 단말과 서버간에 가용 대역폭이 높아도 낮아도 가변적이어도 모두 문제가 발생한다(그림 3).
그림 3. HTTP PDL: 가용 대역폭과 인코딩율
먼저 단말의 가용 대역폭이 높은 상황(그림 3의 a: 비혼잡 시간대 또는 최근 우리나라의 경우처럼 4G LTE 초기 가입자수가 적을 때) 발생하는 문제를 살펴보자. 여러 통계 자료에 따르면 인터넷 비디오의 평균 재생시간은 5분 정도인데 50% 이상의 이용자가 평균적으로 60초 정도 보고 시청을 중단한다(다른 거 볼려고). 단말과 서버간에 가용 대역폭이 충분한 경우에는 60초 이내에 5분 분량의 전체 비디오 파일이 다운로드된다(그림 4).
그림 4. HTTP PDL의 문제점: 대역폭 낭비 이슈
이용자가 가입한 요금제가 정액제 (Sprint 3G, KT 3G)인 경우 가입자는 보지 않은 비디오 분량이 단말에 빨리 다운로드되어도 그 만큼 돈을 더 내는 것이 아니므로 문제가 없지만 통신사업자 입장에서는 아까운 무선 구간 대역폭이 아무 의미없이 낭비되는 것이고 이로 인해 무선망 전체 품질이 떨어지게 된다. 종량제라면 통신사업자가 오히려 좋겠지만 이용자 입장에서는 보지도 않은 비디오 분량에 대한 통신 비용을 통신사업자에게 지불해야 하므로 억울하다(불안해서 보겠나).
다음으로 단말의 가용 대역폭이 낮거나 가변적인 상황(그림 3의 b: 혼잡 시간대 또는 이동 중 음영지역/혼잡지역으로 짂입) 발생하는 문제를 살펴보자. OTT가 알 수 있는 이용자 단말 정보(HTTP Header의 User-Agent)는 브라우저 타입/버전, OS 타입/버전, 모바일 단말 모델명이다. 단말의 네트워크 인터페이스 정보, 즉 이 단말이 현재 3G로 인터넷에 접속되어 있는 지, Wi-Fi인지, 4G인지, 유선 이더넷인지 알 수가 없다. 또한 현재 이 단말이 접속되어 있는 네트워크가 혼잡상태인 지, 가용 대역폭이 충분한 상태인지도 알 수 없다. 따라서 단말 상황에 맞는 비디오 품질 레벨 (해상도, 인코딩율)을 결정해서 해당 비디오 파일을 다운로드해줄 수가 없다.
이용자가 비디오를 선택하면 특정 비트율로 인코딩된 비디오 파일 하나 (Single Bit Rate File Download)가 단말로 다운로드되고 다운로드 속도가 인코딩율보다 느리면 로딩이 발생하게 된다. 무선 액세스망은 유선망보다 훨씬 대역폭이 작고 또 가용 대역폭의 변화가 심하여 망 상황에 따라 이용자 화면은 로딩과 재생을 반복하게 된다. HTTP PDL는 이용자가 일단 재생 버튺을 누르면 망 상황에 따라 비디오 비트율을 변경할 방법이 없다. 통계에 따르면 5명 중 4명이 로딩 상태로 들어가면 시청을 포기한다고 한다.
표 1. HTTP Adaptive Streaming과 HTTP PDL의 비교
이상에서 살펴본 바와 같이 HTTP PDL는 비디오 컨텐츠의 생성 및 운영 비용(트랜스코딩, 스토리지 비용)이 저렴하여 YouTube를 비롯한 많은 OTT 사업자들이 채택하여 사용하고 있으나 무선망 환경에서는 무선 대역폭 낭비, 과금이슈, 이용자 QoE 이슈 등의 문제를 가지고 있다.
통신사업자 입장에서는 OTT 사업자들이 “Streaming 방식”이라 무선 대역폭낭비 이슈가 없고 “Adaptive 방식”이라 화면이 끊기지 않도록 망 상황에 적응하여 비디오를 전달해주는 HTTP Adaptive Streaming 방식을 사용하길 희망하지만 모든 OTT가 비싼 비용이 소요되는 이 방식을 채택할 지 불투명하고 특히 무료이며 매일 업로드되는 신규 동영상 수가 수십만 개인 YouTube가 HTTP Adaptive Streaming 방식으로 전환할 확률은 필자 판단으로는 없다.
그렇다면 HTTP PDL 방식의 OTT 트래픽을 자사 모바일 네트워크를 통해 이용자에게 전달해주는 통신 사업자 입장에서는 이 OTT 트래픽에 대해 뭔가 가공을 해 무선대역폭 낭비도 없애고 이용자 QoE를 개선시켜주는 기능이 필요하게 되고 이러한 기능들을 모바일 비디오 최적화 (MVO: Mobile Video Optimization) 기술이라고 부른다.
모바일 비디오 최적화 기술은 최근에 상용망에 적용되고 있으며 미국의 경우 2011년에 Sprint와 Verizon Wireless가 MVO 장비를 도입하였다. 다음 장에서는 이 모바일 비디오 최적화 기술에 관해 살펴본다.
질문이 있어서 아래와 같이 남깁니다.
MVO 기술을 제공하는 장비는 OTT Origin Server로부터 전달받은 비디오 파일을 장비 내부적으로 Caching 하나요?
이후, 다른 단말로부터 동일한 비디오 파일에 대한 요청을 받으면 TIC 장비처럼 동작을 하나요?
TIC은 OTT의 원본 비디오 파일을 그대로 캐싱하고
MVO 장비는 그대로 캐싱을 하거나 또는 모바일 단말의 화면 사이즈에 맞게
Transcoding/Transrating한 후 저장할 수도 있습니다.
If your paper is available in complete English I would be grateful if its possible to share to me.
Thank you for your help in this matter.
We have plan to provide English version for all documents in netmanias.com site.
However, I'm sorry there's no English version at this moment.
Dynamic Bit rate adapation에 대한 질문인데요. MVO에서 실시간 Transrating이나 Transcoding하여 내려줄경우 Client쪽에서 문제없이 재생이 가능한것인지요? 아님 특수한 경우에 한해 DBRA가 동작하는것인지요? 기본적으로 Bit rate이나 frame rate이 바뀌어서 client쪽에 이를 알려줘야 할것 같은데 아님 바뀌어도 client가 재생하는데 문제가 없는 것인지요?
화질이 떨어지는 대신 끊김없이 시청하게 하려는 것이죠.
감사합니다.
예를들어 bytemobile의 경우 (이젠 Citrix죠, < https://www.netmanias.com/bbs/view.php?id=cshare&no=209 > Table 1 참조하세요),
Video Pacing (bytemobile 용어: Just-in-Time Delivery)은 flash, MP4, RTMP (laptops, smartphone, tablet)를 지원하고,
DBRA (bytemobile 용어: Dynamic Bandwidth Shaping)는 flash, RTMP (laptop) 만을 지원합니다.
수고스러우시겠지만, 벤더별 사이트를 찾아 확인해보셔야 겠어요..
감사합니다.