milas/jellyfish-web
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

update components

Browse source
This commit is contained in:
Luke Pulverenti 2016-06-25 02:04:53 -04:00
parent 2d86f49653
commit ab58f98cc1
27 changed files with 276 additions and 129 deletions
Download patch file Download diff file Expand all files Collapse all files

10
dashboard-ui/bower_components/hls.js/design.md vendored
View file

@ -22,10 +22,6 @@ design idea is pretty simple :
- if there are holes in video.buffered, smaller than config.maxBufferHole, they will be ignored.
- retrieve URL of fragment matching with this media position, and appropriate quality level
- trigger FRAG_LOADING event
- **monitor fragment loading speed** (by monitoring data received from FRAG_LOAD_PROGRESS event)
- "expected time of fragment load completion" is computed using "fragment loading instant bandwidth".
- this time is compared to the "expected time of buffer starvation".
- if we have less than 2 fragments buffered and if "expected time of fragment load completion" is bigger than "expected time of buffer starvation" and also bigger than duration needed to load fragment at next quality level (determined by auto quality switch algorithm), current fragment loading is aborted, stream-controller will **trigger an emergency switch down**.
- **trigger fragment demuxing** on FRAG_LOADED
- trigger BUFFER_RESET on MANIFEST_PARSED or startLoad()
- trigger BUFFER_CODECS on FRAG_PARSING_INIT_SEGMENT
@ -52,7 +48,11 @@ design idea is pretty simple :
- [src/controller/abr-controller.js][]
- in charge of determining auto quality level.
- auto quality switch algorithm is pretty naive and simple ATM and similar to the one that could be found in google [StageFright](https://android.googlesource.com/platform/frameworks/av/+/master/media/libstagefright/httplive/LiveSession.cpp)
- auto quality switch algorithm is bitrate based : fragment loading bitrate is monitored and smoothed using 2 exponential weighted moving average (a fast one, to adapt quickly on bandwidth drop and a slow one, to avoid ramping up to quickly on bandwidth increase)
- in charge of **monitoring fragment loading speed** (by monitoring data received from FRAG_LOAD_PROGRESS event)
- "expected time of fragment load completion" is computed using "fragment loading instant bandwidth".
- this time is compared to the "expected time of buffer starvation".
- if we have less than 2 fragments buffered and if "expected time of fragment load completion" is bigger than "expected time of buffer starvation" and also bigger than duration needed to load fragment at next quality level (determined by auto quality switch algorithm), current fragment loading is aborted, stream-controller will **trigger an emergency switch down**.
- [src/controller/cap-level-controller.js][]
- in charge of determining best quality level to actual size (dimensions: width and height) of the player
- [src/crypt/aes.js][]