1191142 - Youtube video stalls, with holes in buffered ranges

Status: RESOLVED FIXED

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

Description

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

(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)]

Comment 1

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

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.

Comment 2

[Jean-Yves Avenard [:jya]]

same issue was reported in Window 7 pro in bug 1190258

Comment 4

[Jean-Yves Avenard [:jya]]

Attachment: [MSE] P1. Don't discard data if we can't detect type.

Comment 5

[Jean-Yves Avenard [:jya]]

Attachment: [MSE] P2. Round removed buffered intervals.

Calculating intersections between two interval sets with different fuzz can lead to useless tiny intervals which could cause CheckNextInsertionIndex to fail.

Comment 6

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/385c98a22e6f
https://hg.mozilla.org/integration/mozilla-inbound/rev/60acd4d4e716

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/385c98a22e6f
https://hg.mozilla.org/mozilla-central/rev/60acd4d4e716

Comment 8

[Jean-Yves Avenard [:jya]]

Gerald reported still having issues.

I can't reproduce the problem any longer, hence keeping it opened.

Comment 9

[Jean-Yves Avenard [:jya]]

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).