| 리포트 | 기술문서 | 테크-블로그 | 글로벌 블로그 | 원샷 갤러리 | 통신 방송 통계  | 한국 ICT 기업 총람 |

제품 검색

| 네트워크/통신 뉴스 | 기술자료실 | 자유게시판 |  
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 
스폰서채널 |

 

  스폰서채널 서비스란?
모바일 단말에서 YouTube Live TV 스트리밍 방식 분석 - HLS & Adaptive
Analysis on YouTube Mobile Live TV Streaming- HLS & Adaptive
October 30, 2013 | By 양수열, 손장우 (tech@netmanias.com)
banner
코멘트 (7)
20

본 블로그에서는 YouTube가 제공하고 있는 Mobile Live TV의 스트리밍 방식을 LTE-A망과 Wi-Fi망에서 실측을 통해 분석해 본다.

 

모바일 단말에서 YouTube Live TV 스트리밍 분석: HLS & Adaptive

 

먼저, LTE-A 망으로 접속하여 테스트 !

 

모바일 환경 (Galaxy S4 with LTE-A)에서 YouTube APP을 이용하여 YouTube에 접속한 뒤 SPOTV Live 채널을 시청하며 실제 HTTP 트래픽을 캡쳐 후 분석하였다. 아래의 그림은 SPOTV Live 채널을 시청시 컨텐츠 요청 및 전달 과정이다. 스트리밍 프로토콜로 애플의 HLS (HTTP Live Streaming)을 사용하고 있었고 Chunk duration은 5초였고 코덱은 H.264였다.

 

 

1. 사용자는 모바일 단말에서 YouTube APP을 실행한 후 SPOTV Live 채널을 선택한다.

 

2. 단말은 SPOTV Live 채널에 대한 Variant Playlist 파일 요청 메시지를 YouTube 서버로 보낸다. 

 

3. YouTube 서버는 요청한 단말로 Variant Playlist 파일을 전달한다. 이 파일에는 SPOTV Live 채널에 대한 화질 정보(Bandwidth, Resolution 등)가 포함되어 있다. SPOTV 라이브 채널은 64Kbps(128x72)부터 2.8Mbps (1280x720)까지 6개의 화질 등급을 제공하며 itag값으로 화질 등급을 식별한다.  

 

4. 단말은 Variant Playlist 파일에 있는 화질 중에 가장 낮은 화질 (itag=151, 64Kbps, 128x72)을 선택하고 이 화질의 영상에 대한 Playlist 파일 요청 메시지를 YouTube 서버로 보낸다.

 

5. YouTube 서버는 요청한 단말로 Playlist 파일을 전달한다. 이 파일에는 영상 재생을 위한 Chunk 파일들의 정보(Duration, Sequence, 각 Chunk 파일의 URI 등)가 포함되어 있다.

 

6. 단말은 가장 낮은 화질의 첫번째 Chunk 파일(#74753)를 YouTube 서버로 요청한다(※ 이때 요청하는 가장 낮은 화질의 Chunk는 재생을 위한 요청이 아니라 단말과 YouTube 서버간의 품질을 측정하는 것으로 추정된다).

 

7. YouTube 서버는 요청된 가장 낮은 화질의 첫번째 Chunk 파일(#74753)를 단말로 전송한다. 

 

8. 단말은 현재 접속 환경에서 재생 할 수 있는 최적의 화질을 자동으로 선택하고 해당 화질의 Playlist 파일 요청 메시지를 YouTube 서버로 보낸다(실측된 결과 가장 높은 Bit Rate의 화질이 선택되었다).

 

9. YouTube 서버는 요청한 단말로 Playlist 파일을 전달한다. 이 파일에는 영상 재생을 위한 Chunk 파일들의 정보(Duration, Sequence, 각 Chunk 파일의 URI 등)가 포함되어 있다. 

 

10. 단말은 재생을 위한 첫번째 Chunk(#74753)를 YouTube 서버로 요청한다(단말과 YouTube 서버간의 품질 측정을 위해 요청했을 때와 동일한 Sequence를 가진 Chunk 파일를 요청하였다.)

 

11. YouTube 서버는 요청된 Chunk 파일을 전송한다. 단말은 수신한 Chunk를 재생하기 시작한다.

 

12-17. 단말은 3개의 Chunk(#74754, #74755, #74756)를 계속 요청하여 수신한다. 

 

단말은 위와 같은 Initial Buffering 과정(10~17)을 이용하여 빠르게 여러개의 Chunk들을 버퍼링한다. 

 

18. 이후 단말은 약 3~7초 정도 동안에는 Chunk를 요청하지 않는다(배부르니까).

 

19. 단말은 다음 Chunk를 요청하기 위하여 Playlist 파일을 YouTube 서버로 요청한다(만약 네트워크 품질이 변하여 다른 화질의 Chunk가 필요하다면 해당 화질의 Playlist를 요청한다).

 

20. YouTube 서버는 요청한 단말로 Playlist 파일을 전달한다. 

 

21-22. 단말은 다음 Chunk(#74757)를 요청하고 수신한다. 

 

이 후 18-22의 절차가 시청을 마칠 때 까지 계속된다. 

 

단말은 위와 같은 Initial Buffering 과정(10~17) 이후 단말의 환경이 큰 변화가 없는 한 Steady State 모드가 되어 끊기지 않는 재생을 위한 최소한의 Chunk만을 주기적으로 요청한다. 이후 사용자가 재생을 멈추거나 방송이 끝날때까지 Chunk 요청이 반복 된다.

 

LTE-A 망에 접속하여 테스트를 했을 때는 시청시간내내 2.8Mbps의 화질이 유지되었고 화질 등급간 자동 스위칭은 발생하지 않았다(이는 LTE-A망의 대역폭이 충분하기 때문이다). 
 
Bit-Rate 스위칭이 지원되는 지 확인하기 위해 네트워크 대역폭이 LTE-A보다는 열악한 Wi-Fi로 접속하여 다시 테스트를 해보았다. 동일 단말 (Galaxy S4)로 Wi-Fi망에 접속하자 바로 Bit-Rate 스위칭이 발생하였다. 
 

 

위 그림에서 보이듯이 처음엔 64 Kbps 화질 (itag 151)을 요청하고 이후 2.8Mbps (itag 95), 758Kbps (itag 93), 1.47Mbps (itag 94),...로 계속해서 요청되는 chunk의 화질 등급이 다름을 볼 수 있다. 

 

일반적인 ABR (Adaptive Bit Rate) 스트리밍의 경우 최초의 Chunk 요청시에 가장 낮은 화질을 요청하여 해당 영상을 재생 시작한 후 영상이 재생되는 동안 순차적으로 화질의 등급을 높이며 단말과 네트워크 상황에 맞는 최적의 화질을 찾는다. 하지만 두 차례 테스트(LTE-A, Wi-Fi)에서 보듯이 YouTube Live TV에서 제공하는 ABR 스트리밍의 경우 순차적으로 화질의 등급을 올리는 방식을 사용하지 않고 망 상황이 좋다고 판단되면 최고 화질의 Chunk를 바로 요청함을 알 수 있었다. 

 

LTE-A로 접속했을 때 Bit-Rate 스위칭을 목격하지 못한 것은 아쉬우나 Wi-Fi 접속으로 YouTube Live TV 서비스가 Bit-Rate 스위칭을 지원함을 확인할 수 있었다. 

 
조대성 2013-11-01 15:30:07
LTE-A 망에서 패킷은 어떻게 캡쳐 하셨는지 알려 주실 수 있나요 ~?
서원석 2013-11-01 20:13:57
감사히 잘보았습니다. 일반 유튜브 영상을 보았을때에도 요청메시지부분에서도 chunk크기를 알수있나요?
박근백 2013-11-04 02:03:26
모바일에서 PD방식으로 알고 있었는데 HLS로 바뀌엇나보네요...감사합니다^^
넷매니아즈 2013-11-04 10:03:29
안드로이드 단말 루팅 후 tcpdump(설치 필요)를 이용하여 패킷을 캡쳐할 수 있습니다.
Google에서 "안드로이드", "루팅", "tcpdump" 단어로 검색하시면 관련 글을 확인하실 수 있습니다.
넷매니아즈 2013-11-13 12:36:35
서원석님,

YouTube의 경우 단말 타입과 컨텐츠 유형 (VoD or Live)에 따라서 비디오 파일을 요청하는 방식이 다릅니다.

1. 예를 들어 VoD, PC의 경우 HTTP GET 메시지내에 "range=4227072-8454143"를 명시하여 비디오 파일의 조각(Chunk)을 받아옵니다.
다음 글을 참고하세요.
YouTube의 비디오 전달 방식 변경 (1): Progressive Download의 종말
(https://www.netmanias.com/bbs/view.php?id=blog&no=377)

2. 또 다른 예로 Mobile (Android), Live의 경우는 URI parameter내에

- Content ID: LrvSViSz75Q.1 (SPOTV Live)
- 화질: itag = 95 (720p, 약 3Mbps)
- Chunk 번호: 348762
- Chunk Size: 1,663,612 B
- Duration: 5초

이 기록되어 있습니다.

아래 메시지를 참고하세요.

GET /videoplayback/id/LrvSViSz75Q.1/itag/95/source/yt_live_broadcast/sq/348762?ratebypass=yes&cmbypass=yes&newshard=yes&hls_chunk_host=www.youtube.com&gir=yes&dg_shard=LrvSViSz75Q.1_95&playlist_type=LIVE&pmbypass=yes&upn=pNDfy3vC2Dc&sver=3&fexp=900359,936120,902548,924616,924610,907231&dnc=1&cpn=fZOhBIjqX12L2yn4&ip=223.62.173.196&ipbits=0&expire=1382433498&sparams=ip,ipbits,expire,id,itag,source,ratebypass,live,cmbypass,newshard,hls_chunk_host,gir,dg_shard,playlist_type,pmbypass&signature=5C33B831EC4A762CBE246D47F7AAB7CFDE9934BC.6F587640CF3811B306D12E063F70DC2CF4E65D3C&key=dg_yt0&live=1&lmt=1382409705488585&clen=1663612&dur=5.005
김길호 2014-04-03 20:07:25
상세한 설명에 감사드립니다.
11번 과정에서 첫번째 chunk가 다운로드 완료 되어야 play를 시작하는 것인지요?
YouTube 방식이 chunk가 다운로드 완료 되기 전에 play 시작이 가능한지 궁금합니다.
양수열 2014-04-04 10:39:07
//김길호님

와이파이와 LTE에서의 동작이 동일하다고 가정했을 때, 유투브는 Chunk 다운로드가 완료된 이후 재생이 되는것 같습니다. (모바일 단말을 와이파이에 붙여서 대역폭을 제한한 후 테스트를 해보면 다운로드가 완료되기 전엔 재생이 되지 않는 것을 볼수있습니다.) 또한 Adaptive Streaming 이라는 재생 방식은 여러개로 나뉜 Chunk를 Download & Play 하는 방법을 기반으로 동작하기 때문에 이러한 동작이 맞다고 생각됩니다.
Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (969)
5G (67) AI (5) ALTO (1) AR (2) ARP (6) AT&T (1) Akamai (5) Authentication (5) BT (1) Backhaul (2) Big Data (2) Bridging (5) C-RAN/Fronthaul (17) CDN (20) CIoT (2) CPRI (6) Carrier Aggregation (5) Charging (2) China Mobile (2) Cisco (6) CoMP (3) Comcast (1) DHCP (6) DNS (15) Data Center (15) EDGE (10) EMM (1) EPS Bearer (7) Ethernet (3) FTTH (8) GSLB (5) Gigabit Internet (17) Google (17) Google Global Cache (8) Google TV (1) HLS (5) HTTP (5) HTTP Adaptive Streaming (7) HTTP Progressive Download (2) Handover (5) Huawei (1) IGMP (3) IP (6) IP Allocation (8) IP Routing (20) IPSec (4) IPTV (25) IoST (2) IoT (44) KT (45) Korea (8) Korea ICT Vendor (1) L3 Switch (5) LG U+ (24) LTE (99) LTE-A (10) LTE-A Pro (1) LTE-M (1) LTE-U (3) LoRa (5) MEC (10) MPLS (3) MWC 2013 (1) MWC 2015 (3) MWC 2016 (2) MWC 2017 (1) Mobile IPTV (1) Multi-Screen (1) Multicast (2) NAT (9) NB-IoT (6) NTT Docomo (1) Netflix (5) Network Protocol (49) Network Slicing (3) OSPF (3) OTT (20) Operator CDN (1) P2P (3) PS-LTE (3) Pooq (2) QoS (5) RCS (1) RRH (1) Request Routing (3) SD-WAN (8) SDN/NFV (34) SK Broadband (1) SK Telecom (38) Samsung (2) Security (8) Self-Driving (3) Shortest Path Tree (2) Small Cell (3) Spectrum Sharing (1) TAU (2) Transparent Caching (9) UHD (7) VLAN (2) VPN (3) VR (3) Video Streaming (22) VoLTE (1) VoWiFi (1) WAN Optimization (1) Wi-Fi (30) WiBro(WiMAX) (2) YouTube (16) eICIC (1) eMBMS (1) ePDG (6) u+ tv G (4) 로컬 5G (1)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2019년 1월 현재 넷매니아즈 회원은 49,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호