Διακίνηση Διακίνηση Video με χρήση του HTTP 8 1201 5 Β Μάγκλαρης ltmaglarisnetmodentuagrgt Μ Γραμματικού lt marynetmodentuagr ID: 156847
Download Presentation The PPT/PDF document "Πολυμεσικό Υλικό στο I..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Πολυμεσικό Υλικό στο Internet: Συγχρονισμός, Επεξεργασία και ΔιακίνησηΔιακίνηση Video με χρήση του HTTP8/1/2015
Β. Μάγκλαρης
<maglaris@netmode.ntua.gr>
Μ. Γραμματικού
<
mary@netmode.ntua.gr
>
Δ.
Καλογεράς
<dkalo@noc.ntua.ge>
www.netmode.ntua.gr
Slide2
OutlineStreaming over Internet1st Generation Progressive2nd Generation
UDP based Real-Time
Protocols
(RTP,
RTCP, RTSP
)
3
rd
Generation
TCP based
Proprietary – Adobe
Adaptive HTTP basedSlide3
ChallengesTCP/UDP/IP , best-effort, with no guarantees on expectation or variance of packet delayStreaming applications delay of 5 to 10 seconds is typical and has been acceptable, but performance deteriorate if links are congested
Real
-Time Interactive requirements on delay and its jitter have been satisfied by over-provisioning (providing plenty of bandwidth), what will happen when the load increases?...Slide4
4
On-Demand
Streaming
Important and growing application due to reduction of storage costs, increase in high speed net access from homes, enhancements to caching
Interactive control by user
(but often with long response time)
Ubiquitous on the web:
YouTube, Netflix,
Vimeo
Television networks, Hollywood, etc.
Most local radio & TV stations
Virtually everywhere on websitesSlide5
First Generation: HTTP Download
A simple architecture is to have the Browser request the object(s) and after their reception pass them to the player
for display
No pipeliningSlide6
Helper Application – i.e. media playerDisplays content, which is typically requested via a Web browser; typical functions:DecompressionJitter removalError correction: use redundant packets to be used for reconstruction of original stream
GUI for user control
Examples:
RealPlayer
Adobe Flash Player
Windows Media Player
QuickTimeDivX Web PlayerSlide7
First Gen: HTTP Progressive Download (2)Alternative: set up connection between server and player; player takes overWeb browser requests and receives a Meta File
(a file describing the object) instead of receiving the file itself;
Browser launches the appropriate Player and passes it the
Meta File
;
Player sets up a TCP connection with Web Server and downloads or
streams the fileSlide8
8
Meta file requestsSlide9
HTTP Progressive DownloadWith helper application doing the download, playback can start immediately...Or after sufficient bytes are bufferedSender sends at maximum possible rate under TCP; retransmit when error is encountered; Player uses a much larger buffer to smooth delivery rate of TCPSlide10
HTTP Progressive DownloadSlide11
Buffering Continuous MediaJitter = variation from ideal timingMedia delivery must have very low jitter Video frames every 30ms or soAudio: ultimately samples need < 128ms
jitter
But network packets have much more jitter that that!
Solution: buffers
Fill them with best effort
Drain them via low-latency, local access Slide12
Streaming, Buffers and Timing
Time
Max Buffer Duration
= allowable jitter
File Position
Max Buffer Size
Smooth Playback Time
Buffer almost empty
"Good" Region:
smooth playback
"Bad": Buffer underflows and
playback stops
"Bad": Buffer overrflows
Buffer
Duration
Buffer
SizeSlide13
The myth of SBRAny single bitrate you choose for a video is by definition the wrong video for 99% of users.
These users will
rebuffer
These have lower quality than they could
sustainSlide14
Drawbacks of HTTP Progressive Download (2)HTTP connection keeps data flowing as fast as possible to user's local bufferMay download lots of extra data if you do not watch the videoTCP file transfer can use more bandwidth than necessary
Mismatch between whole file transfer and stop/start/seek playback controls.
However: use file range requests to seek to video position
Cannot change video quality (bit rate) to adapt to network congestion Slide15
2nd Generation: Real-Time StreamingThis gets us around HTTP, allows a choice of UDP vs. TCP and the application layer protocol can be better tailored to Streaming; many enhancements options are possibleSlide16
RTSP and RTP
Legacy Video Streaming ApproachesSlide17
Example: Real Time Streaming Protocol (RTSP)For user to control display: rewind, fast forward, pause, resume, etc…Out-of-band protocol (uses two connections, one for control messages (Port 554) and one for media stream)RFC 2326 permits use of either TCP or UDP for the control messages connection, sometimes called the RTSP ChannelAs before, meta file is communicated to web browser which then launches the Player; Player sets up an RTSP connection for control messages in addition to the connection for the streaming mediaSlide18
18
RTSP OperationSlide19
19
RTSP Media Stream
Stateful
Server keeps track of client's state
Client issues Play, Pause, ..., Close
Steady stream of packets
UDP - lower latency
TCP - may get through more firewalls, reliable
Credit: some content adapted from Alex ZambelliSlide20
20
RTSP Exchange Example
C: SETUP rtsp://audio.example.com/xena/audio RTSP/1.0
Transport:
rtp
/
udp
; compression; port=3056; mode=PLAY
S: RTSP/1.0 200 1 OK
Session 4231
C: PLAY rtsp://audio.example.com/xena/audio.en/lofi RTSP/1.0
Session: 4231
Range:
npt
=0 (
npt
= normal play time)
C: PAUSE rtsp://audio.example.com/xena/audio.en/lofi RTSP/1.0
Session: 4231
Range:
npt
=37
C: TEARDOWN rtsp://audio.example.com/xena/audio.en/lofi RTSP/1.0
Session: 4231
S: 200 3 OKSlide21
21
Example 2: RTMP
- Real-Time Messaging Protocol
Proprietary Adobe protocol
Runs over TCP
Manages audio, video, and other
Multiplex multiple streams over TCP connectionSlide22
Flash Streaming ServerFlash Streaming Server communicates with its clients using the Adobe patented RTMP over TCP, which manages a two-way connection, allowing the server to send and receive,video, audio and
data between client and server
Typically used with FLV encoded filesSlide23
Variations of RTMPRTMP- Standard,unencrypted RTMP.
The default port is 1935.
RTMPT-
RTMP “tunneled” over HTTP
The default port is 80
RTMPS- RTMP sent over an SSL. SSL enables secure
TCP/IP connections. The default port is 443RTMPE- Enhanced and encrypted version of RTMP.
RTMPTE- Encrypts the communication channel, tunneling over HTTPSlide24
24
Drawbacks of RTSP, RTMP
Web downloads are typically cheaper than streaming services offered by CDNs and hosting providers
Streaming often blocked by routers
UDP itself often blocked by firewalls
HTTP delivery can use ordinary proxies and caches
Conclusion: rather than adapt Internet to streaming, adapt media delivery to the InternetSlide25
Bandwidth is never constantEven preselecting bitrates will lead to rebuffering problems as bandwidth fluctuates over the duration of the vide, especially for long form contentIdeally we would like to switch bitrates constantly to always give the user the highest quality they can sustain at any point in time.
BufferingSlide26
Bandwidth is never constantEven preselecting bitrates will lead to rebuffering problems as bandwidth fluctuates over the duration of the vide, especially for long form contentIdeally we would like to switch bitrates constantly to always give the user the highest quality they can sustain at any point in time.
Buffering
500kbps
1000kbps
1500kbps
Adaptive deliverySlide27
3rd Generation: HTTP StreamingOther terms for similar concepts: Adaptive Streaming, Smooth Streaming, HTTP ChunkingClient-centric architecture with stateful client and stateless server Standard server: Web serversStandard Protocol: HTTP
Session state and logic maintained at server
Video is broken into multiple chunks
Chunks begin with
keyframe
so independent of other chunks
A series of HTTP progressive downloads of chunksPlaying chunks in sequence gives seamless videoSlide28
Adaptive Bit Rate with HTTP Streaming Encode video at different levels of quality/bandwidthClient can adapt by requesting different sized chunksChunks of different bit rates must be
synchronized
All
encodings have the same chunk boundaries and all chunks start with
keyframes
, so you can make smooth splices to chunks of higher or lower bit
ratesSlide29
How does segmentation work?
Incoming video
1
3
into multiple short blocks. Each block holds the same section of video, encoded at a different size and bitrate.
500 kbps
2000 kbps
1000 kbps
is split by an
encoder
2Slide30
How does adaptive delivery work?
The segmented video is stored on a server, along with a text file which describes the names of each segment. This text file is called a
manifest
.
A player downloads the manifest and then begins requesting individual segments of video.
It makes its choice based on bandwidth conditions, grabbing the best quality it can at the time.
SERVER
CLOUD
PLAYERSlide31
Media Source Extension – the future of browser videoA W3C standard - https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html Supported today by Chrome, IE11 and Opera
MSE allows JavaScript to
fetch and parse a manifest
r
etrieve video, audio and text segments using XHR
f
eed them to the <video> tag to be decoded and rendered.
MSE gives developers incredible control over playback,
buffering and adaption logic of in-page video.Slide32
Pareto principle in video popularityAlso known as the “80-20” (or 90-10) rule [http://en.wikipedia.org/wiki/Pareto_principle]Associated with highly skewed distributions
Caused by positive-feedback effects (“the rich get richer”)
Does non-UGC content (say movies from
NetFlix
) follow a similar pattern?
A practical implication of this
skewness: caching applies!Slide33
Caching works…Let’s build CDNsTake advantage of locality and relativityA practical implication of this skewness: caching works
!
Akamai
You tube
Netflix based on Amazon
infrastractureSlide34
Adaptive HTTP Streaming System (Protocol)ServerCan be standard web serverMedia segment can be prepared in-line or off-line
Client
Sends series of HTTP GET segment requests and receives segments
Performs rate adaptation before sending a new GET segment requestSlide35
35
Advantages of HTTP Streaming
Easy to deploy: it's just HTTP, work with
existing
caches/proxies/CDN/Firewall
Fast startup by downloading lowest quality/smallest chunk
Bitrate switching is seamless
Many small files
Small with respect to the movie size
Large with respect to TCP
5-10 seconds of 1Mbps – 3Mbps
0.5MB – 4MB per chunkSlide36
Which adaptive streaming formats exist today?HTTP Live Streaming (HLS)
Controlled by Apple
Known as HLS, it is supported well by
iOS
, Safari and half-heartedly by Android.
HTTP Dynamic Streaming (HDS)
Controlled by AdobeKnown as HDS, it is played back only by Flash clients with custom apps.Smooth Streaming (SMOOTH)Controlled by Microsoft
Played back via Silverlight clients, Xbox, MPEG-DASH (DASH)
An ISO standard
Playback via MSE in browsers, native apps on
iOS
, Android and
WInOS
. Slide37
Simple HLS example <video id="player" controls poster="sintel.jpg" preload="none" style="width:480px;height:204px"> <source src="
http://multiplatform-
f.akamaihd.net
/
i
/multi/april11/
sintel/sintel-hd_,512x288_450_b,640x360_700_b,768x432_1000_b,.mp4.csmil/master.m3u8" type='application/x-mpegURL' /> <source src
="http://akamaicorp-pmd.edgesuite.net/flashvod
/video/mp4/sintel.mp4" type='video/mp4'/>
<source
src
="http://
akamaicorp-pmd.edgesuite.net
/
flashvod
/video/mp4/
sintel.webm
" type='video/
webm
' />
</video>Slide38
Example of HLS Meta Data Slide39
RTMP
Other Video Streaming ApproachesSlide40
Several players support itSeveral commercial content providers use itMicrosoft Smooth Streaming PlayerNetflix Player
Adobe OSMF/
Zeri
Player
Apple Player
Adaptive video streaming
over HTTPSlide41
HTTP Adaptive Video StreamingSlide42
HTTP Adaptive Video Streaming: Manifest File and FragmentsSlide43
Smooth Streaming PlayerSlide44
Smooth Streaming PlayerSample HTTP Request:GET /mediadl/iisnet/smoothmedia/Experience/BigBuckBunny720p.ism/QualityLevels
(2040000)/Fragments(video=400000000) HTTP/1.1Slide45
Adobe OSMF/Zeri PlayerSlide46
Adobe OSMF PlayerSample HTTP Request:GET /content/inoutedit-mbr/inoutedit\_h264\_3000Seg1-Frag5 HTTP/1.1Slide47
What Makes Netflix Interesting?Commercial, feature-length movies and TV shows
and not free; subscription-based
Nonetheless, Netflix is huge!
25 million subscribers
and
~20,000 titles (and growing)
consumes 30% of peak-time downstream bandwidth in North America
A prime example of
cloud-sourced
architecture
Maintains only a small “in-house” facility for key functions
e.g., subscriber management (account creation, payment, …)
Majority of functions are sourced to Amazon cloud (EC2/S3)
user authentication, video search, video storage, …
DNS service is sourced to UltraDNS
Leverage multiple CDNs (content-distribution networks) for video delivery
Akamai, Level 3 and LimelightSlide48
Netflix Architecture
Netflix has its own “data center” for certain crucial operations (e.g., user registration, billing, …)
Most web-based user-video interaction, computation/storage operations are cloud-sourced to Amazon AWS
Video delivery is out/cloud-sourced to 3 CDNs
Users need to use MS Silverlight player for video streamingSlide49
Netflix Videos and Video Chunks Netflix uses a numeric ID to identify each movieIDs are variable length (6-8 digits): 213530, 1001192, 70221086video IDs do not seem to be evenly distributed in the ID space
these video IDs are
not
used in playback operations
Each
movie is
encoded in multiple quality levels, each is identified by a numeric ID (9 digits)various numeric IDs associated with the same movie appear to have no obvious relations
49Slide50
Netflix PlayerSlide51
Netflix PlayerSample HTTP Request:GET /sa2/946/1876632946.wmv/range/2212059-2252058?token=1283923056\_d6f6112068075f1fb60cc48eab59ea55\&random=1799513140 HTTP/1.1Slide52
Netflix Videos and Video Chunks Videos are divided in “chunks” (of roughly 4 secs), specified using (byte) “range/xxx-xxx?” in the URL path:
Limelight:
http://netflix-094.vo.llnwd.net/s/stor3/
384/
534975384
.ismv/range/
0-57689?p=58&e=1311456547&h=2caca6fb4cc2c522e657006cf69d4ace
Akamai:
http://netflix094.as.nflximg.com.edgesuite.net/sa53/
384/
534975384
.ismv/
range/0-57689?
token=1311456547_411862e41a33dc93ee71e2e3b3fd8534
Level3:
http://nflx.i.ad483241.x.lcdn.nflximg.com/
384/
534975384
.ismv/
range/0-57689?
etime=20110723212907&movieHash=094&encoded=06847414df0656e697cbd
Netflix uses a version of (MPEG-)
DASH
for video streaming
52Slide53
Terms and Definitions of Adaptive HTTP StreamingNeed Media Presentation Description (MDP) which provides metadata For requesting (GET request) media segmentsFor rate adaptation purposeSegment
which may include media data or metadata to decode
Use DASH an example in the few slides Slide54
Example: DASH Client
Thomas Stockhammer, Qualcomm,
“
DASH – Design Principles and Standards ,
Presentation at MMSys 2011 Slide55
Meta DataDASH uses MPD (Media Presentation Descriptor) and Index Information as metadata for DASH Access ClientInitialization and Media Segments for Media Engine
Reuse of existing conta
iner format
Source: Stockhammer, Qualcomm,
“
DASH – Design Principles and Standards , Presentation at MMSys 2011 Slide56
Media Presentation Data Model
MDP - description of accessible segments and corresponding timing
Source: Stockhammer, Qualcomm,
“
DASH – Design Principles and Standards , Presentation at MMSys 2011