- 15 May, 2015 2 commits
- 14 May, 2015 1 commit
-
-
Don't use previous segment timestamps to calculate the precise duration of a segment so that we don't have to worry about timestamp discontinuities. Update to contrib-media-sources 1.0.
David LaPalomento committed
-
- 13 May, 2015 1 commit
-
-
If segments are delivered very quickly, it's possible that a segment after a discontinuity will be ready before the previous segment is finished getting processed by the media source. Our current mechanism for signalling discontinuities is synchronous so this could lead to us injecting a discontinuity into the middle of the first segment instead of at the end. Instead, adopt a workflow more closely aligned to how real SourceBuffers work and don't append additional bytes until the previous append has been fully processed.
David LaPalomento committed
-
- 08 May, 2015 3 commits
-
-
- 07 May, 2015 7 commits
-
-
phantom and some other browsers check whether a TypedArray has equivalent data outside of the "view" area and fail deep equality tests when there is a difference.
David LaPalomento committed -
Metadata packets that were not the start of a new payload unit were being silently dropped. Move the handler so that they are correctly routed to the metadata stream. Also, keep track of the number of bytes shifted off of the buffer when processing ID3 frames so that more than a single frame can be processed.
David LaPalomento committed -
If the entire ID3 frame isn't available in a single metadatastream push, store everything up and check with the combined data next time. Ignore tags that do not include at least the tag header in the first TS packet.
David LaPalomento committed -
Pass along the parsed ID3 frame object that corresponds to the genererated VTTCue.
David LaPalomento committed -
- 06 May, 2015 2 commits
-
-
This code uses the presentation timestamp of the ts segment to calculate its exact duration, since this may differ by fractions of a second from what is reported. Using the exact, calculated 'preciseDuration' allows for smoother seeking and calculation of the total playlist duration, which previously (especially in short videos) was reported erroneously and made the play head overrun the end of the progress bar.
Brandon Bay committed
- 05 May, 2015 2 commits
-
-
- 28 Apr, 2015 6 commits
-
-
-
When all multiple variant streams were usable based on bandwidth, resolutionPlusOne could be set to the lowest bandwidth variant on the first pass through the resolution filtering loop.
David LaPalomento committed -
Split up large segments that need AES-128 decryption and hand control back to the browser between segments. Clean up the decryption block loop a bit since it's no longer critical to finish before the next frame is rendered.
David LaPalomento committed
- 27 Apr, 2015 1 commit
-
-
- 21 Apr, 2015 1 commit
-
-
For #218. Use TypedArrays instead of DataViews because they weren't getting optimized very well. Use Int32Arrays instead of Uint32Arrays to avoid v8 deoptimization at runtime when negative values were encountered. Swap byte order in the main loop instead of before-hand. These changes don't get decrypt running in less than 16ms on my machine but they do speed things up an order of magnitude or so. Additional work to make the decryption asynchronous appears necessary.
David LaPalomento committed
-
- 16 Apr, 2015 9 commits
-
-
-
Temporarily use a newer version of videojs-swf then is included in the mainline video.js release.
David LaPalomento committed -
-
Never match media indices on playlist reload based on segment URI because some streams may re-use the same segment in multiple positions. Change fetchKeys() so that it operates on buffered segments instead of directly modifying a version of the playlist. Before that change, live playlists with low segment durations could stall because the key would be applied to the previous version of the live playlist and segments would get blocked up forever in the queue waiting for their key to arrive. Use a much less destructive mechanism for playing across discontinuities. vjs_discontinuity() on the SWF allows us to signal a timestamp discontinuity without flushing the playback buffer. That means we don't have to wait until the buffer is empty when a discontinuity is encountered and feeding data to the SWF doesn't have to block either. Update tests to reflect new key-segment request ordering.
David LaPalomento committed
-
- 15 Apr, 2015 1 commit
-
-
If we have a perfect resolution match for playlist and player, use that playlist. Otherwise, get the next highest resolution matched playlist, even if bigger than the player.
Gary Katsevman committed
-
- 13 Apr, 2015 2 commits
-
-
- 10 Apr, 2015 1 commit
-
-
- 02 Apr, 2015 1 commit
-
-