(Spawned from bug 1190258) Nightly 42.0a1 (2015-08-04) on Mac OS X 10.10.4. https://www.youtube.com/watch?v=eyU3bRy2x44 Quality: auto 480p Stalls at 49s. About:media: https://www.youtube.com/watch?v=eyU3bRy2x44 mediasource:https://www.youtube.com/4268fd33-7a68-4f40-96c8-537016a52d17 currentTime: 49.609433 SourceBuffer 0 start=0 end=54.984852 SourceBuffer 1 start=49.582866 end=49.6496 start=55.055 end=60.093366 start=80.08 end=90.123366 start=105.105 end=115.148366 start=130.13 end=135.168366 start=155.155 end=160.193366 start=180.18 end=180.213366 start=205.205 end=205.238366 start=230.23 end=230.263366 start=255.255 end=255.321733 start=280.28 end=310.31 Internal Data: Dumping data for demuxer 12932ac00: Dumping Audio Track Buffer(audio/mp4a-latm): - mLastAudioTime: 50.665941 NumSamples:2368 Size:1280198 NextGetSampleIndex:2182 NextInsertionIndex:2368 Buffered: ranges=[(0.000000, 54.984852)] Dumping Video Track Buffer(video/avc) - mLastVideoTime: 49.649600 NumSamples:1962 Size:9329978 NextGetSampleIndex:2 NextInsertionIndex:1962 Buffered: ranges=[(49.582866, 49.649600), (55.055000, 60.093366), (80.080000, 90.123366), (105.105000, 115.148366), (130.130000, 135.168366), (155.155000, 160.193366), (180.180000, 180.213366), (205.205000, 205.238366), (230.230000, 230.263366), (255.255000, 255.321733), (280.280000, 310.310000)]
Note: The first stall changes between runs, I've seen 1:25 and 5:45. Seeking to another position restarts playback, until the next stall.
same issue was reported in Window 7 pro in bug 1190258
OS: Mac OS X → All
Hardware: x86_64 → All
Attachment #8644806 - Flags: review?(gsquelart) → review+
Calculating intersections between two interval sets with different fuzz can lead to useless tiny intervals which could cause CheckNextInsertionIndex to fail.
Attachment #8644835 - Flags: review?(gsquelart)
Attachment #8644835 - Flags: review?(gsquelart) → review+
Gerald reported still having issues. I can't reproduce the problem any longer, hence keeping it opened.
Turned out, the sourcebuffer memory threshold was set to 9MB which would cause eviction in the future and as such holes in the buffered range. http://w3c.github.io/media-source/index.html#sourcebuffer-coded-frame-eviction "Implementations may use different methods for selecting removal ranges so web applications should not depend on a specific behavior. The web application can use the buffered attribute to observe whether portions of the buffered data have been evicted. " this is entirely per spec. Unfortunately, YouTube (and most other DASH player) incorrectly assume that no eviction ever occurs in the future and do not check that data could now be missing. Which is a very interesting behaviour, as YouTube MSE conformance test specifically test that it works that way (and we pass their test).
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.