Transcript
YouTube 비디오 요청 및 전달 방식 분석 : YouTube Video Delivery Process (360p, 720p)
2012.11.21
(Last Updated 2012.11.22)
NMC Consulting Group
tech@netmanias.com
www.netmanias.com/www.nmcgroups.com
YouTube 비디오 전달 방식 (PC) - 싸이 강남스타일
360p (default)
비디오 파일 요청 및 전달
16번의 Chunk 요청 (16 HTTP GETs)
임의의 지점으로 이동
Byte Range Request (URI Parameter)
요청방식
분할 요청 (Byte Range Request)
720p
비디오 파일 요청 및 전달
한번에 전체 파일 요청 (Single HTTP GET)
임의의 지점으로 이동
Begin Request (URI Parameter)
요청방식
전부 요청
1. YouTube 360p (강남스타일)
Video Request and Response
Video Traffic Delivery Pattern
비디오 전달 방식 특징
①Range Request 기반의 HTTP Progressive Download 방식임: 1.78MB씩 계속 요청하여 컨텐츠를 받아옴.
②각 Chunk의 요청은 Request URI의 range parameter를 사용하여 요청함 (HTTP Header의 Range를 사용하지 않음)
③초기에 4개의 Chunk를 연속적(Back-to-Back)으로 요청하고 이후 대략 15~20초 간격으로 요청함
④마지막 Chunk(짜투리)도 1.78MB로 요청함
⑤시청 도중에 Pause를 누르면 다음 Chunk에 대한 GET이 나가지 않기 때문에 추가적인 컨텐츠 다운로드는 발생하지 않음. 이는 HTTP Adaptive Streaming과 유사한 스트리밍 효과-비디오를 시청할 때만 파일이 다운로드되어 안 보면 안주는-를 제공한다.
⑥하나의 TCP Session으로 한 동영상의 전체 Chunk를 나름
⑦360p 화질 요청은 Request URI의 itag parameter를 사용하여 요청함 (360p: itag=34)
YouTube 360p (강남스타일)
비디오 요청 및 전달 절차 - Chunk Concept - Range Request
YouTube 360p (강남스타일) - HTTP GET 메시지
2. YouTube 360p (강남스타일) - Jump
Video Request and Response
Video Traffic Delivery Pattern
비디오 전달 방식 특징
①4번째 Chunk를 받고 나서 이동을 하면 11번째 Chunk에 대한 요청이 YouTube 서버로 보내지는 데 이 때 Request URI의 요청 range는 19,014,386-19,599,359로 1,781,760바이트가 아닌 584,974바이트를 요청한다 (TCP 세션은 그대로 유지됨).
②이후 Chunk들은 원래대로 1,781,760바이트씩 요청한다.
③[참고] Chunk 4를 받고 있는 시점에서 Jump를 하면 Chunk 4를 받고 있던 TCP 세션을 끊어 다운로드를 중단시키고 이동 지점부터 시작되는 Chunk를 받기 위해 새 TCP 세션을 맞는다 (안 그러면 Chunk 4가 계속 다운로드 되므로).
YouTube 360p (강남스타일) - Jump
비디오 요청 및 전달 절차 - Chunk Concept - Range Request
YouTube 360p (강남스타일) - Jump - HTTP GET 메시지
임의의 지점으로 이동시 HTTP GET 메시지
3. YouTube 720p (강남스타일)
Video Request and Response Process
Video Traffic Delivery Pattern
비디오 전달 방식 특징
①HTTP Progressive Download 방식임: 한 번의 요청 (HTTP GET)으로 파일 전체를 다운로드 받음
②이 HTTP GET에는 Request URL에 range parameter, begin parameter가 없고 HTT Header 필드에도 range 필드가 없음 (파일의 처음부터 끝까지 다 달라는 의미임)
③TCP Session은 하나임
④720p 화질 요청은 Request URI의 itag parameter를 사용하여 요청함 (720p: itag=22)
4. YouTube 720p (강남스타일) - Jump
Video Request and Response
Video Traffic Delivery Pattern
비디오 전달 방식 특징
①최초 요청시
- 요청: TCP 세션 (1756)을 Setup하고 이 TCP 세션을 통해 HTTP GET 전송. 비디오 파일 사이즈를 모르니 다 달라 (이 때는 URI에도 HTTP Header에도 Byte Range 정보 및 시작 시점 정보 없음)
- 응답: HTTP 200 OK (Content-Length: 93MB). 비디오 데이터 다운로드
②Jump (2분 지점으로 이동)
- 단말이 현재 다운로드 중이던 TCP 세션(1756)을 Termination (안 끊으면 계속 다운로드될 것이므로)
- 요청: 새 TCP 세션 (1757)을 Setup하고 이 TCP 세션을 통해 HTTP GET 전송. 이 때 Request URI에 이동한 지점에 대한 시간 정보가 begin parameter (begin=120793, 2분)에 실려 전달됨.
- 응답: HTTP 200 OK (Content-Length = 50MB). 비디오 데이터 다운로드
YouTube 720p (강남스타일) - Jump - HTTP GET 메시지
최초 요청
1차 이동 (2분 지점)
5. YouTube 화질 변경 (360p → 720p)
Video Request and Response
Video Traffic Delivery Pattern
비디오 전달 방식 특징
①360p 화질로 시청하는 동안 단말은 1.78MB 단위로 Byte Range Request를 보냄. 위 캡춰 예에서 Chunk 4까지 수신함.
②[화질변경] 16초쯤 시청하다가 720p로 변경하면 새로운 TCP 세션을 Setup되고 이 세션을 통해 HTTP GET이 전송됨
- 화질변경: 이 URI에 요청화질 (itag)이 34(320p)에서 22(720p)로 바뀜.
- 이동지점: 이 URI에 begin=15845로 코딩하여 15.8초부터 끝까지 비디오 파일을 전송해줄 것을 요청함.
- 15.8초부터 끝까지 비디오 파일을 다운로드함
- 서버는 마지막 Packet을 전달하면서 FIN을 보내어 TCP 세션(1861)을 Termination함
③[화질 변경 후 360p는 ?] 단말에서는 추가적인 Chunk 요청이 발생하지 않음. 처음 생성된 360p 파일 다운로드를 위한 TCP 세션은 화질 변경 요청시 바로 끊지 않고 360p 파일의 마지막 Packet을 단말로 전달해준 후 30초 지나면 Timeout되어 서버가 FIN을 보내 TCP 세션(1846)을 해제함
YouTube 화질 변경 (360p → 720p) - HTTP GET 메시지
Analysis of YouTube Video Delivery (360p, 720p)
2012.12.04
(Last Updated 2012.12.04)
NMC Consulting Group
tech@netmanias.com
www.netmanias.com
www.nmcgroups.com
Summary of YouTube Video Delivery on the PC - PSY Gangnam Style
360p (default)
Video File Request and Delivery
16 HTTP GETs (byte range)
Jump to Any Part of a Video
Byte Range Request (URI Parameter): Request from the selected point to the end of chunk
Request Method
Multiple Chunk Requests (Byte Range Request)
720p
Video File Request and Delivery
Single HTTP GET
Jump to Any Part of a Video
Begin Request (URI Parameter): Request from the selected point to the end of file
Request Method
Single Request
1. YouTube 360p (PSY Gangnam Style)
Video Request and Response
Video Traffic Delivery Pattern
Features of Video Request & Delivery
①HTTP Progressive Download based on Byte Range request : Download video data by requesting 1.78MB chunk continuously
②Chunk request uses range parameter of Request URI (It does not use Range header of HTTP)
③Four burst requests(Chunk 1 ~ Chunk 4) at the beginning, and then request at interval of 15 ~ 20 seconds
④Last chunk is also requested with 1.78MB (even though last chunk is smaller than 1.78MB)
⑤When user pauses during watching the video, next chunk request(HTTP GET) is not sent to the YouTube server, which means additional video downloading is not happened. That is similar with HTTP adaptive streaming (Downloading video only when watching a video)
⑥Deliver the entire chunks of the video by single TCP session
⑦Video quality is specified by itag parameter of Request URI (360p: itag=34)
YouTube 360p (PSY Gangnam Style)
Video Request and Delivery Procedure: Chunk Concept - Range Request
YouTube 360p (PSY Gangnam Style) - HTTP Message
2. YouTube 360p (PSY Gangnam Style): Jump
Video Request and Response
Video Traffic Delivery Pattern
Features of Video Request & Delivery
①When user jumps after receiving 4th chunk data, request of 11th chunk is sent to the YouTube server in this example. This chunk request includes range=19014386-19599359 in Request URI, which means device requests 585,974 bytes chunk, not 1,78MB
②After receiving part of 11th chunk (585,974 bytes), device requests next 1.78MB chunk
③[NOTE] When user jumps during receiving chunk data, device terminates TCP session for stop downloading. After then, device creates new TCP session with YouTube server to download chunk from the selected point
YouTube 360p (PSY Gangnam Style): Jump
Video Request and Delivery Procedure: Chunk Concept - Range Request
YouTube 360p (PSY Gangnam Style): Jump - HTTP GET Message
HTTP GET Header: Jump to any part of video
3. YouTube 720p (PSY Gangnam Style)
Video Request and Response Process
Video Traffic Delivery Pattern
Features of Video Request & Delivery
①HTTP Progressive Download: Download entire file by single request (HTTP GET)
②In this HTTP GET message, range and begin parameter are not included in Request URI (Device requests video data from the beginning to the end)
③Deliver the video file by single TCP session
④Video quality is specified by itag parameter of Request URI (720p: itag=22)
4. YouTube 720p (PSY Gangnam Style): Jump
Video Request and Response
Video Traffic Delivery Pattern
Features of Video Request & Delivery
①Initial Request
-Request: Device creates TCP session(1756) and sends HTTP GET. Device requests entire video file (There are no range and begin parameter in Request URI)
-Response: HTTP 200 OK (Content-Length: 93MB) message and video data
②Jump to 2 minutes point
-Device terminates TCP session(1756) to prevent downloading a video file
-Request: Device creates new TCP session(1757) and sends HTTP GET message, which includes time information about jump point with begin parameter(begin=120793) in Request URI
-Response: HTTP 200 OK (Content-Length = 50MB) message and video data
YouTube 720p (PSY Gangnam Style): Jump - HTTP Message
Initial Request
Jump to 2 minutes point
5. YouTube Video Quality Change (360p → 720p)
Video Request and Response
Video Traffic Delivery Pattern
Features of Video Request & Delivery
①While user watches a 360p video, device sends 1.78MB Range Request (In this example, chunk 1 ~ 4 are downloaded to the device)
②[Quality Change to 720p] When user changes video quality to 720p, device setups new TCP session with YouTube server and sends HTTP GET message
-Quality Change: itag=22(720p) of Request URI in HTTP GET
-Starting Point: begin=15845(15.8 seconds) of Request URI in HTTP GET
-Device downloads video file from 15.8 seconds point to the end
-YouTube server sends the last video data packet with FIN flag to terminate TCP session(1861)
③[What about 360p after Quality Change?] 360p video chunk is not downloaded to the device any more because device does not send Chunk Request (HTTP GET). TCP session(1846) is not terminated right after quality change, but it is terminated after 30 seconds by sending TCP FIN packet by YouTube server
YouTube Video Quality Change (360p → 720p): HTTP Message
Page 7, 이동지점 숫자표시 오타있습니다. 19,014,38 ==> 19,014,386
Page 12, 질문 있습니다. 360p 에서 720p로 Jump 하게되면, 360p 때처럼 360p 관련 TCP 세션 Termination이 바로 일어나지 않고 720p 전송이 완료된 이후에나 Termination 되나요? 그렇다면, 720p로 Jump 후 720p 비디오 수신과 병행하여 320p 비디오도 수신이 되는 것 아닌가요?
우측 상단 Video Traffic Delivery Pattern에서는 지속적인 360p 트래픽은 720p Jump 후 없는 것으로 보이는데, 답변/설명 부탁드립니다.
좋은 자료 잘 보았습니다.
감사합니다.
질문하신 내용을에 대해 답변을 드리겠습니다.
[Page 6]
Jump 전/후 TCP 세션 Termination과 New TCP 세션 Setup이 좌측 플로우 그림에서 빠진 것 같은데, 맞나요?
=> Jump 테스트시 Chunk 1-4를 받은 상태에서 Jump를 했기 때문에 Chunk 1-4를 받고 있던 최초 TCP 세션은 그대로 유지되며 이 TCP 세션을 통해 Jump 이후의 Chunk들을 다운로드 받습니다.
=> 만약 Chunk 4를 받던 중에 Jump를 하면 Chunk 4를 받고 있던 TCP 세션은 Termination되고 이동 지점부터 시작되는 Chunk들을 다운로드 받기 위해 새 TCP 세션이 설정됩니다.
[Page 7]
이동지점 숫자표시 오타있습니다. 19,014,38 ==> 19,014,386
=> 수정하였습니다. 매의 눈 정말 감사드립니다.
[Page 12]
질문 있습니다. 360p에서 720p로 Jump 하게되면, 360p 때처럼 360p 관련 TCP 세션 Termination이 바로 일어나지 않고 720p 전송이 완료된 이후에나 Termination 되나요?
=> 720p의 전송 완료와 상관없이 30초간 추가적인 GET이 없으면 YouTube 서버가 TCP 세션을 끊어버립니다.
그렇다면, 720p로 Jump 후 720p 비디오 수신과 병행하여 320p 비디오도 수신이 되는 것 아닌가요?
우측 상단 Video Traffic Delivery Pattern에서는 지속적인 360p 트래픽은 720p Jump 후 없는 것으로 보이는데, 답변/설명 부탁드립니다.
=> 이 번 테스트에서는 360p Chunk 4개를 모두 다운로드 받은 상태에서 화질 변경을 했기 때문에 360p에 대한 TCP Termination없어도 두 화질의 비디오가 동시에 수신되는 상황은 발생하지 않습니다 (화질변경을 하면 그 순간부터 추가적인 360p Chunk 요청은 발생하지 않습니다).
만약에 360p의 Chunk 4를 수신하는 도중에 화질 변경 요청이 발생하면 360p Chunk를 수신하던 TCP 세션은 단말이 끊고 720p 비디오 파일을 수신하기 위한 새 TCP 세션을 맺기 때문에 역시 360p와 720p의 두 화질의 비디오를 동시에 수신하지는 않습니다.
추가적인 질문이 있으면 편하게 올려주세요.
그리고 제가 test 해본 결과 Youtube 동영상 시청 시 사용자가 이동하지 않아도 Session이 동영상 중간, 중간에 종료 되어 새로운 TCP Session(Client Port만 증가) 을 이용하여 206 Partial Content로 전송 되는 경우가 다반사 였는데, 206이 발생 하는 원인이 궁금 합니다.
항상 좋은 자료 감사하게 생각 합니다.
YouTube 트래픽 전달 특성이 PC냐, 모바일이냐 (iDevice냐/Android냐,App이냐/Mobile Web이냐 등등)에 따라 다릅니다.
이 기술문서에서는 유선 PC 환경에서 테스트한 결과입니다.
테스트 환경을 좀 자세히 설명해주세요.
감사합니다.
갤럭시S3나 옵티머스 LTE2도 동일 한 결과 였습니다. 안드로이드 환경이지요.
제생각으로는 분할 전송을 하는 것으로 생각 되었습니다. 자원을 위해서 10이라는 Data를 받을 경우 우선 3을 받고,
2에 가까이 플레이가 되면 3->6을 다운 받고, 5에 가까이 되면 10까지 다운하게 하는 방법으로 생각 되었습니다.
마침..페루프로젝트에서 youTube 이슈가 부각 되고 있습니다.
사업자에서는 Youtube Proxy서버를 (Google Cache) 두었다가 기능동작이 잘 되지 않는다고 사용하지 않고 있습니다.
Wimax Dongle을 사용하여 Youtube stream을 360P로 땡겨 보았습니다.. Wireshark도 함께 걸어 놓았지요..
역시나, 위의 언급한 Flow로 동작을 합니다..
넷메니아즈 홈피에 나와 있는 Youtube는 오늘 하루종일 몇 번 본것 같네요.
나름 패킷을 잡아가며, 검증도 함께 하였지요..
궁금한 사항이 있습니다.
1개의 Stream을 시청하기까지 Range는 13 ~ 21381119로, 총 12개의 Chunk가 있었습니다.
1) 1개의 Chunk는 1360Byte패킷이 n개 다운로드 됩니다..(몇개인지 세다가 wireshark가 죽어서 저장을 못했네요)
2) 1번 의 Chunk(TCP 패킷) n개의 Window Size가 = 7878
2번 Chunk n개모두 window size= 9226
3번 window size = 10544
4번 window size = 13180
........
12번 window size = 34320 로 표시됩니다.
3) 여기서 질문
- 1개의 Chunk의 Window Size는 TCP packet마다 틀린게 아니고, 통틀어 1개의 Chunk (n개의 TCP)패킷은
Window Size가 Fix되어 전송되나요??
- 360P의 재생율은 어느정도 인가요? (1080P = 6Mbps, 720P=3Mbps, 360P = ?? Mbps)
늘, 많은 정보와 속시원한 답변 감사합니다.
덕분에 다른 사람들에게 잘난체좀 하고 있습니다. ^^
안녕하세요.
넷매니아즈에서 다양한 단말 환경에서 YouTube 비디오 전달 패턴을 테스트 했습니다.
결과가 복잡한 데요.
일단 Mobile의 경우 (유선 PC 말고) 3개의 비디오 품질을 지원합니다.
(싸이 강남 스타일의 경우)
- 240p (320x240): 232 Kbps
- 360p (640x360): 729 Kbps
- 720p (1280x720): 3.149 Mbps
YouTube를 테스트해보니 단말 (PC, Smart TV, Mobile Device, iDevice, Android, App, Web, 등등별)로 전송 방식 (Delivery Protocol, Traffic Pattern, and 인코딩율이 매우 다르더군요.
또 동일 플랫폼이라고 해도 몇 개월만에 또 바뀌고요...
(Such as Wi-Fi Performance different location and angle,...)
향후 천천히 테스트 내용을 전달하도록 하겠습니다.
감사합니다.
넷매니아즈....
WiMAX dongle을 사용하셨다면 아마도 유선 PC의 특성을 따라가지 않을까 싶네요. (PC 브라우저를 사용하므로)
YouTube 동영상 다운로딩이라면 아마 YouTube 서버가 단말로 보내는 TCP Window Size를 말씀하시는 것 같은데요.
이게 Chunk별로 사이즈가 정의되어 있다고 생각하기는 좀 힘들어 보입니다.
확인하신 Window Size는 수신측(단말)이 송신측(YouTube) 서버에게 알려주는 "ACK 없이 수신 가능한 최대 bytes 수"일 것 같은데요. YouTube 서버가 비디오 전달 시 현재 얼마의 Window Size(Congestion Window라 부름)로 패킷을 전달하는지는 패킷에 나와 있지 않습니다.
제 생각에 TCP Windows Size, RTT로 인해 동영상 재생시 버퍼링 문제가 발생하는 듯 한데요. 다음과 같이 확인해 보세요.
1. TCP Window Size 확인
단말에서 YouTube 서버로 보내는 TCP 패킷의 Window Size를 확인해 보세요. YouTube 서버는 이 이상의 크기로 보내지 못합니다. (TCP 표준이므로)
2. RTT 확인
동영상을 다운로드하는 YouTube 서버의 IP 주소로 ping을 하여 RTT를 측정하세요.
3. 만약 TCP Window Size = 64KB, RTT = 200ms라면,
단말이 수신할 수 있는 TCP 최대 대역폭(YouTube 서버가 전송할 수 있는 최대 대역폭)은 아래와 같이 계산됩니다.
TCP Max Throughput = TCP Window Size(bit) / RTT(s) = (64 x 1024 x 8) / (200 x 0.001) = 2.6Mbps
4. Wireshark IO graph를 통해 확인하시면 동영상 전달시의 대역폭을 확인하실 수 있으며 최대 대역폭은 2.6Mbps를 넘지 못할 것입니다.
5. 이제 마지막으로 YouTube 동영상 다운로드 프로그램(예. YTD)을 이용하여 테스트 하시는 동영상을 PC로 다운로드 후, 동영상 재생기를 이용하여 Encoding Rate를 확인(또는 "동영상 파일 크기(bit) / 재생시간(s)"으로도 간단히 계산 가능)하시기 바랍니다. 만약 Encoding Rate가 2.6Mbps 보다 크면 버퍼링이 발생할 수 없을 것입니다.
360p 의 경우, 왜 각 chunk 단위로 짤라서 반복적인 요청을 하나요.. ?
어차피 밑에 layer 에서 packet segmentation 이 이루어져서 segmentation 의 이득은 별로 없을 것 같은데 말입니다.. ;;
혹시, 분산 서버 환경때문에 어떤 seq # 기반으로 분산적으로 chunk 데이터를 받을 수 있는 메카니즘이 있어서 인지요..
분명, 360p 에만 그런걸 보면, 가용 rate 이 작아서 생기는 문제를 해결하려는것 같은데요..
■ 현재의 720p 방식에서는 동영상 play 버튼을 누름과 동시에 HTTP GET이 하나 나가고, 이후 동영상 파일 전체가 순식간에(망 품질에 따라 다르겠지만요) 단말로 다운로드 됩니다. (3분 시청동안 20분 분량의 전체 비디오 파일이 다운로딩됨)
즉, 이용자가 일정 부분 보다가 stop을 해도 이미 파일은 내 단말로 다 다운로드 된 상태입니다. 즉, 의미 없는 데이터로 인해 대역폭을 낭비해 버린 결과가 발생한 것이죠.
■ 하지만 360p 방식의 경우, play 버튼을 누름과 동시에 4개의 HTTP GET을 통해 약 7MB(4 x 1.78MB) 정도만 단말로 다운로드 되고, 이후 이용자가 계속 동영상 시청을 해야만(즉, stop/pause를 누르지 않아야만) 이후 chunk가 다운로드 됩니다. (3분 시청하면 3분 분량의 비디오 파일만 다운로딩됨!)
따라서 720p 보다는 chunk 기반의 360p 방식이 효율적입니다.
YouTube에 720p 영상도 모두 chunk 방식으로 바뀌게 되지 않을까... 하는 생각입니다. (확인된 사실은 아님)
그리고 이성진 님께서 말씀하신 것 처럼 분산적으로 chunk 데이터를 수신할 수 있는 것이라면 720p 보다는 360p 컨텐츠 이용자가 훨씬 많아서가 아닐지 모르겠습니다. (이것도 사실이 아닌 의견입니다 ^^;)
Youtube 모바일은 어떤 방법으로 확인하신건가요?
fiddler연결해서 pc WireShark에서 패킷을 잡으려고 시도해도
모바일상의 youtube data 패킷이 제대로 안잡히네요.
조언 부탁드립니다^^
감사합니다!
아래와 같이 하시면 됩니다.
1. 모바일 단말에 루트 권한을 획득한다. (루팅한다.)
2. 모바일 단말에 tcpdump를 설치한다.
3. tcpdump로 패킷을 캡쳐한다.
4. 캡쳐된 파일을 PC로 옮겨 Wireshark으로 확인한다.
[1안] 지난 번에 말씀드린 단말을 탈옥해서 패킷 캡쳐
1) 이 경우 모바일 단말이 보내는 HTTP GET 메시지내의 User-Agent는 모바일 단말 모델명과 브라우저명이 들어가게 됩니다. YouTube 서버의 경우 이 User-Agent 필드를 통해 단말 타입(PC, Pad, Phone...)을 구별하고 그에 따라 서로 다른 전달 방식을 사용합니다.
2) 단말의 Player는 자신이 접속한 Access Network이 3G 혹은 LTE임을 알고, 그에 맞는 화질을 요청합니다. (예전에 시험을 했을때 동일 모바일 단말로 Wi-Fi에 접속했을때와 3G에 접속했을때 서로 다른 화질이 재생되었던 기억이 납니다.)
[2안] 모바일 단말 테더링 설정 후 USB 혹은 Wi-Fi를 통해 PC(노트북) 연결 (Yoo님 의견)
1) 이 경우 PC에 브라우저를 사용하게 되므로 HTTP GET내에 User-Agent가 모바일 단말이 아닌 PC것으로 들어가게 되어 YouTube 전달 특성이 [1안]과 달라 질 수 있습니다.
2) 역시 PC에 Player를 사용하게 되므로 Player는 그 결과가 [1안]과 달라질 수 있습니다.
감사합니다.
와이파이 핫스팟으로는 모바일 패킷 캡쳐가 불가능한가요?
YouTube 비디오 트래픽 패턴에 대한 내용 잘 읽어 보았습니다. 감사합니다.
몇 가지 궁금한 점이 있어 질문을 드립니다.
Q1. 위의 12년 12월 3일, 넷메니아즈 답변을 보니
다양한 단말 환경에서 Youtube 비디오 전달 패턴 테스트 내용을 향후 알려주신다고 하셨는데,
이번기회에 알려주실 수 있는지요?
Q2. 넷메니아즈 Qwilt - 벤더 솔루션 리포트를 보면,
- 갤럭시 노트는 비디오를 다운받을때 전체 비디오 분량의 1/2, 1/4, 1/4에 해당하는 분량으로 3번 요청함
- 갤럭시 노트(동일 단말)에서 동일 컨텐츠를 재 다운받을때도 매번 1/2, 1/4, 1/4에 해당하는 비디오 분량이
다르다고 되어있습니다.
Mobile 단말과 유선 단말이 Youtube 비디오를 요청시 몇 번에 걸쳐 몇 byte씩 요청하는지를 결정해야 할텐데,
결정하게 되는 절차와 방법이 궁금합니다.
Q3. Q2의 갤럭시 노트는 매번 요청하는 비디오 분량이 다 다른데,
본 기술 문서에서는 PC 환경이기는 하지만 Chunk의 size가 1.78M로 고정되어 있습니다.
이런 차이는 왜 발생하는 것인가요?
감사합니다.
1. "GET/ ... &range=13-1781799 "의 URI의 range parameter에서 단말이 range를 정하는 것인가요? 아님 Youtube가 어느 크기씩(즉 각 청크의 크기) 요청하라고 지정해주는 것인가요? HAS같이 metafile을 제공하여 주나요?
2. range 요청을 위하여는 전체 비디오의 크기를 알아야 끝을 알수 있을것 같은데, 전체 비디오의 크기는 청크의 요청 전에 Youtube에서 알려주나요?
항상 넷매니아스 자료에 도움을 많이 받고 있습니다. 감사합니다
우와 정말 좋은 자료 많네요~ 넷매니아 최고입니다....
대부분 전문가들만 모여있으시네요 많이 배우고갑니다.