FMUSER Wirless Transmit Video And Audio More Easier !
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org ->Afrikaans
sq.fmuser.org ->Albanian
ar.fmuser.org ->Arabic
hy.fmuser.org ->Armenian
az.fmuser.org ->Azerbaijani
eu.fmuser.org ->Basque
be.fmuser.org ->Belarusian
bg.fmuser.org ->Bulgarian
ca.fmuser.org ->Catalan
zh-CN.fmuser.org ->Chinese (Simplified)
zh-TW.fmuser.org ->Chinese (Traditional)
hr.fmuser.org ->Croatian
cs.fmuser.org ->Czech
da.fmuser.org ->Danish
nl.fmuser.org ->Dutch
et.fmuser.org ->Estonian
tl.fmuser.org ->Filipino
fi.fmuser.org ->Finnish
fr.fmuser.org ->French
gl.fmuser.org ->Galician
ka.fmuser.org ->Georgian
de.fmuser.org ->German
el.fmuser.org ->Greek
ht.fmuser.org ->Haitian Creole
iw.fmuser.org ->Hebrew
hi.fmuser.org ->Hindi
hu.fmuser.org ->Hungarian
is.fmuser.org ->Icelandic
id.fmuser.org ->Indonesian
ga.fmuser.org ->Irish
it.fmuser.org ->Italian
ja.fmuser.org ->Japanese
ko.fmuser.org ->Korean
lv.fmuser.org ->Latvian
lt.fmuser.org ->Lithuanian
mk.fmuser.org ->Macedonian
ms.fmuser.org ->Malay
mt.fmuser.org ->Maltese
no.fmuser.org ->Norwegian
fa.fmuser.org ->Persian
pl.fmuser.org ->Polish
pt.fmuser.org ->Portuguese
ro.fmuser.org ->Romanian
ru.fmuser.org ->Russian
sr.fmuser.org ->Serbian
sk.fmuser.org ->Slovak
sl.fmuser.org ->Slovenian
es.fmuser.org ->Spanish
sw.fmuser.org ->Swahili
sv.fmuser.org ->Swedish
th.fmuser.org ->Thai
tr.fmuser.org ->Turkish
uk.fmuser.org ->Ukrainian
ur.fmuser.org ->Urdu
vi.fmuser.org ->Vietnamese
cy.fmuser.org ->Welsh
yi.fmuser.org ->Yiddish
Today I will introduce the HLS agreement, which was proposed and promoted by Apple. Here is a definition from Wikipedia.
HTTP Live Streaming (abbreviated as HLS) is an HTTP-based streaming media network transmission protocol proposed by Apple. It is part of Apple's QuickTime X and iPhone software systems. It works by dividing the entire stream into small HTTP-based files to download, and downloading only a few at a time. When the media stream is playing, the client can choose to download the same resource at different rates from many different alternate sources, allowing the streaming media session to adapt to different data rates. When starting a streaming media session, the client will download an extended M3U (m3u8) playlist file containing metadata to find available media streams.
HLS only requests basic HTTP messages. Unlike Real Time Transport Protocol (RTP), HLS can pass through any firewall or proxy server that allows HTTP data to pass through. It is also easy to use content distribution networks to transmit media streams.
Apple regards the HLS protocol as an Internet draft (submitted step by step), which has been submitted to the IETF as an informal standard in the first phase. However, even though Apple occasionally submits some minor updates, the IETF has not taken any further action regarding the development of this standard. [1]
1. Introduction to the agreement
The HLS agreement stipulates:
(1) The packaging format of the video is TS.
(2) The video encoding format is H264, and the audio encoding format is MP3, AAC or AC-3.
(3) In addition to the TS video file itself, an m3u8 file (text file) used to control playback is also defined.
Why does Apple propose the HLS protocol? In fact, it is mainly to solve some of the problems in the RTMP protocol. For example, the RTMP protocol does not use a standard HTTP interface to transmit data, so it may be blocked by a firewall in some special network environments. However, because HLS uses the HTTP protocol to transmit data, it will not encounter the situation of being shielded by the firewall (there is no firewall that will not let the 80 interface pass).
In addition to the load, RTMP is a stateful protocol, and it is difficult to smoothly extend the video server because it needs to maintain the state for each client that plays the video stream. While HLS is based on the stateless protocol (HTTP), the client just downloads the ordinary TS files stored in the server in order, and the balance is as simple as the load balancing of the ordinary HTTP file server.
In addition, the HLS protocol itself implements bit rate adaptation, and devices with different bandwidths can automatically switch to the video playback that best suits their bit rate. In fact, the biggest advantage of HLS is that his father is Apple. Apple only provides native support for HLS on its own IOS devices and abandoned flash. Android is also forced by Pingguo's "exotic prestige" to natively support HLS. In this way, Adobe's video solutions such as flv and rtmp require extra work to be played on mobile devices. Of course, the high performance pressure caused by flash on mobile devices is indeed its own problem. However, HLS also has some pitfalls that cannot be overcome. For example, the delay time of live video using the HLS protocol cannot be lowered to less than 10 seconds, while the delay of the RTMP protocol can be as low as 3 or 4 seconds. Therefore, please use HLS with caution for services that are more sensitive to live broadcast delays.
Let me explain this picture. From left to right, it doesn’t matter what format the video source of the inputs on the bottom left is. The communication protocol between him and the server can also be arbitrary (such as RTMP). In short, just transmit the video data to the server. Just go. This video is converted into HLS format video (both TS and m3u8 files) files on the server server. In detail, the Media encoder in the server is a transcoding module responsible for transcoding the video data in the video source to the video data of the target encoding format (H264). The encoding format of the video source can be any video encoding format ( Refer to "Video Technology Fundamentals"). After transcoding into H264 video data, the video is sliced in the stream segmenter module, and the result of the slice is the index file (m3u8) and ts file. The Distribution in the picture is actually just an ordinary HTTP file server, and then the client only needs to access the path of the first-level index file and it will automatically play the HLS video stream.
2. HLS index file
The so-called index file is the m3u8 text file mentioned earlier.
As shown in the figure above, the logic of the client to play HLS video stream is actually very simple. First download the first-level Index file, which records the address of the second-level index file (Alternate-A, Alternate-B, Alternate-C), and then the client The client then downloads the secondary index file, and the download address of the TS file is recorded in the secondary index file, so that the client can download the TS video files in order and play them continuously.
(1) First level index file
Video source: https://dco4urblvsasc.cloudfront.net/811/81095_ywfZjAuP/game/index.m3u8
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1064000
1000kbps.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=564000
500kbps.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=282000
250kbps.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2128000
2000kbps.m3u8
bandwidth specifies the bit rate of the video stream. The PROGRAM-ID is useless and no need to pay attention. The next line of each #EXT-X-STREAM-INF is the path of the secondary index file. You can use a relative path or an absolute path. The relative path is used in the example. This file records the secondary index file path of different bitrate video streams. The client can judge its own current network bandwidth to decide which video stream to play. It can also smoothly switch to a video stream that matches the bandwidth when the network bandwidth changes.
#EXTM3U
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:10
#EXTINF:10,
2000kbps-00001.ts
#EXTINF:10,
2000kbps-00002.ts
#EXTINF:10,
2000kbps-00003.ts
#EXTINF:10,
2000kbps-00004.ts
#EXTINF:10,
... ...
#EXTINF:10,
2000kbps-00096.ts
#EXTINF:10,
2000kbps-00097.ts
#EXTINF:10,
2000kbps-00098.ts
#EXTINF:10,
2000kbps-00099.ts
#EXTINF:10,
2000kbps-00100.ts
#ZEN-TOTAL-DURATION:999.66667
#ZEN-AVERAGE-BANDWIDTH:2190954
#ZEN-MAXIMUM-BANDWIDTH:3536205
#EXT-X-ENDLIST
The secondary file is actually responsible for giving the download address of the ts file, and the relative path is also used here. #EXTINF represents the duration of each ts slice video file. #EXT-X-TARGETDURATION specifies the maximum duration of the slice file in the current video stream, which means that the duration of these ts slices cannot be greater than the value of #EXT-X-TARGETDURATION. #EXT-X-PLAYLIST-TYPE: VOD means that the current video stream is not a live stream, but an on-demand stream. In other words, all the ts files of the video have been generated, #EXT-X- ENDLIST indicates the end of the video. Having this mark also indicates that the current stream is a non-live stream.
3. Play mode
The feature of VOD on demand is that all index files and ts files can be obtained at the current time point, and the addresses of all ts files are recorded in the secondary index file. This mode allows clients to access all content. The above example is the structure of m3u8 in on-demand mode.
Live mode is to generate M3u8 and ts files in real time. Its index file is always changing dynamically, and it needs to download the secondary index file continuously during playback to obtain the latest generated ts file to play the video. If there is no #EXT-X-ENDLIST mark at the end of a secondary index file, it means that it is a Live video stream.
When the client is playing a video in VOD mode, it actually only needs to download the first-level index file and the second-level index file once to get the download addresses of all ts files. Unless the client switches the bitrate, there is no need to download any index files. Just download and play ts files in sequence. But the Live mode is slightly different, because while playing, the new ts file is also being generated, so the client actually downloads the second-level index file once, then downloads the ts file, and then downloads the second-level index file (this time this The secondary index file has been rewritten, the download address of the newly generated ts file is recorded), and then the new ts file is downloaded, and the playback is repeated in this way.
|
Enter email to get a surprise
es.fmuser.org
it.fmuser.org
fr.fmuser.org
de.fmuser.org
af.fmuser.org ->Afrikaans
sq.fmuser.org ->Albanian
ar.fmuser.org ->Arabic
hy.fmuser.org ->Armenian
az.fmuser.org ->Azerbaijani
eu.fmuser.org ->Basque
be.fmuser.org ->Belarusian
bg.fmuser.org ->Bulgarian
ca.fmuser.org ->Catalan
zh-CN.fmuser.org ->Chinese (Simplified)
zh-TW.fmuser.org ->Chinese (Traditional)
hr.fmuser.org ->Croatian
cs.fmuser.org ->Czech
da.fmuser.org ->Danish
nl.fmuser.org ->Dutch
et.fmuser.org ->Estonian
tl.fmuser.org ->Filipino
fi.fmuser.org ->Finnish
fr.fmuser.org ->French
gl.fmuser.org ->Galician
ka.fmuser.org ->Georgian
de.fmuser.org ->German
el.fmuser.org ->Greek
ht.fmuser.org ->Haitian Creole
iw.fmuser.org ->Hebrew
hi.fmuser.org ->Hindi
hu.fmuser.org ->Hungarian
is.fmuser.org ->Icelandic
id.fmuser.org ->Indonesian
ga.fmuser.org ->Irish
it.fmuser.org ->Italian
ja.fmuser.org ->Japanese
ko.fmuser.org ->Korean
lv.fmuser.org ->Latvian
lt.fmuser.org ->Lithuanian
mk.fmuser.org ->Macedonian
ms.fmuser.org ->Malay
mt.fmuser.org ->Maltese
no.fmuser.org ->Norwegian
fa.fmuser.org ->Persian
pl.fmuser.org ->Polish
pt.fmuser.org ->Portuguese
ro.fmuser.org ->Romanian
ru.fmuser.org ->Russian
sr.fmuser.org ->Serbian
sk.fmuser.org ->Slovak
sl.fmuser.org ->Slovenian
es.fmuser.org ->Spanish
sw.fmuser.org ->Swahili
sv.fmuser.org ->Swedish
th.fmuser.org ->Thai
tr.fmuser.org ->Turkish
uk.fmuser.org ->Ukrainian
ur.fmuser.org ->Urdu
vi.fmuser.org ->Vietnamese
cy.fmuser.org ->Welsh
yi.fmuser.org ->Yiddish
FMUSER Wirless Transmit Video And Audio More Easier !
Contact
Address:
No.305 Room HuiLan Building No.273 Huanpu Road Guangzhou China 510620
Categories
Newsletter