User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36 Steps to reproduce: Open the URL http://www.dash-player.com/demo/4k/ Actual results: The playback works fine, until the switch to the first 4k representation (3840x1608) - the video stalls. In the following you can find the HTMLMediaElement debug data: http://www.dash-player.com/demo/4k/ mediasource:http://www.dash-player.com/4885f9ac-c61f-6749-91db-3c585a945fe9 currentTime: 34.446812 SourceBuffer 0 start=18.75 end=34.5 start=63.041666 end=68.041666 start=68.083333 end=115.666666 start=115.708333 end=144.75 SourceBuffer 1 start=0 end=79.552 Internal Data: Dumping data for reader 125f9ec00: Dumping Audio Track Decoders: - mLastAudioTime: 35.498666 Reader 0: 126566800 ranges=[(0.000000, 79.552000)] active=true size=1637674 Dumping Video Track Decoders - mLastVideoTime: 34.500000 Reader 7: 125f97000 ranges=[(119.833333, 144.750000)] active=false size=3508275 Reader 6: 125ea9000 ranges=[(115.708333, 119.833333)] active=false size=1307443 Reader 5: 125ea9400 ranges=[(110.708333, 115.666666)] active=false size=1464886 Reader 4: 124935400 ranges=[(79.625000, 110.750000)] active=false size=11376191 Reader 3: 11fe0e000 ranges=[(72.500000, 79.625000)] active=false size=1651288 Reader 2: 1185d7400 ranges=[(68.083333, 72.500000)] active=false size=14582884 Reader 1: 118905c00 ranges=[(63.041666, 68.041666)] active=false size=8046674 Reader 0: 12afce000 ranges=[(18.750000, 34.500000)] active=true size=9218236 As it can be seen, the video buffer ends at about 34 seconds (thats also where the playback stops) and there is a gap till about 63 seconds. Expected results: The stream (audio and video) plays without stalls.
3 years ago
Severity: normal → major
Component: Untriaged → Video/Audio
Product: Firefox → Core
3 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Which version of FF are you using ? play fine with nightly. By fine I mean it gets to the end. It pauses often when choosing 4K @ 12Mbit/s as it takes a while to buffer (the video buffer length is only about 0.5-1s during playback), but nothing out of the ordinary there. I played with our eviction threshold to test your code, reducing the sourcebuffer size to 30MB. You may not care because our threshold is 75MB by default but here are my observations: I restarted playback and then attempted seeking to a portion of video that I knew had been evicted (looked at about:media to check). The player then attempted to append a big buffer (18MB) as by this stage the source buffer is full and we can't evict anything (our current MSE implementation prevent us from evicting less than a total MOOF+MDAT). The current sourcebuffer contains a single MOOF+MDAT of 17MB which we can't evict so we can't make free space to accomodate the extra 18MB. So an exception QuotaExceededError is thrown as per spec (http://w3c.github.io/media-source/#sourcebuffer-prepare-append) From that point on, your player simply attempt to append the same data over and over. This will never succeed. Per spec: "This is the signal that the implementation was unable to evict enough data to accomodate the append or the append is too big. The web application should use remove() to explicitly free up space and/or reduce the size of the append." It is then up to your code to evict data. Please note that sourcebuffer.remove(a,b) only works with these two scenarios: 1- a <= sourcebuffer.buffered.start(0) 2- b >= sourcebuffer.buffered.end(sourcebuffer.buffered.length-1) FWIW, under those same circumstances, YouTube calls remove on the entire sourcebuffer. I suggest you do the same :) I would also suggest that you break down the size of your media segments, to say 5s long. We have a stall within the last 3s, but we are aware of this issue where we go into waiting mode in the last few seconds under some circumstances.
I am using Firefox 36 - works fine on nightly for me as well.
Quick update. The video stops at 141s because it's cut short. While the moof indicates we have 145s of video, there's only 141s in the mdat.
Reinhard - do you still get this with bug 1139271 fixed?
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.