본 블로그에서는 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 요청이 반복 된다.
위 그림에서 보이듯이 처음엔 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 스위칭을 지원함을 확인할 수 있었다.
상호: (주)엔앰씨컨설팅그룹 주소: 서울시 강남구 테헤란로 128, 3층 387호 대표이사: 손장우 전화: 02-3444-5747 메일: webmaster@netmanias.com 등록번호: 서울 아03722 제호: 넷매니아즈 등록일자: 2015년 5월 4일 발행/편집인: 손장우 청소년보호책임자: 이수정
주소: 본사: 서울시 강남구 테헤란로 128, 3층 387호 Netmanias USA: 5214 36th Ave. NE Seattle, WA 98105 USA
Copyright ⓒ 2002-2023 NMC Consulting Group. All rights reserved.
|
Google에서 "안드로이드", "루팅", "tcpdump" 단어로 검색하시면 관련 글을 확인하실 수 있습니다.
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
11번 과정에서 첫번째 chunk가 다운로드 완료 되어야 play를 시작하는 것인지요?
YouTube 방식이 chunk가 다운로드 완료 되기 전에 play 시작이 가능한지 궁금합니다.
와이파이와 LTE에서의 동작이 동일하다고 가정했을 때, 유투브는 Chunk 다운로드가 완료된 이후 재생이 되는것 같습니다. (모바일 단말을 와이파이에 붙여서 대역폭을 제한한 후 테스트를 해보면 다운로드가 완료되기 전엔 재생이 되지 않는 것을 볼수있습니다.) 또한 Adaptive Streaming 이라는 재생 방식은 여러개로 나뉜 Chunk를 Download & Play 하는 방법을 기반으로 동작하기 때문에 이러한 동작이 맞다고 생각됩니다.