Closed Bug 1137118 Opened 6 years ago Closed 5 years ago

4k DASH sample stalls


(Core :: Audio/Video, defect, P2)

36 Branch





(Reporter: reinhard.grandl, Unassigned)


(Blocks 1 open bug, )


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

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:
	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.
Blocks: MSE
Severity: normal → major
Component: Untriaged → Video/Audio
Product: Firefox → Core
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 (

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.
Flags: needinfo?(reinhard.grandl)
I am using Firefox 36 - works fine on nightly for me as well.
Flags: needinfo?(reinhard.grandl)
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.
Priority: -- → P2
Reinhard - do you still get this with bug 1139271 fixed?
Flags: needinfo?(reinhard.grandl)
Closed: 5 years ago
Resolution: --- → INCOMPLETE
Flags: needinfo?(reinhard.grandl)
You need to log in before you can comment on or make changes to this bug.