Youtube video stalls, with holes in buffered ranges

RESOLVED FIXED

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: gerald, Assigned: jya)

Tracking

(Blocks: 1 bug)

42 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
(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)]
(Reporter)

Comment 1

4 years ago
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.
(Assignee)

Updated

4 years ago
Assignee: nobody → jyavenard
(Assignee)

Updated

4 years ago
See Also: → bug 1190258
(Assignee)

Updated

4 years ago
Version: 1.0 Branch → 42 Branch
(Assignee)

Comment 2

4 years ago
same issue was reported in Window 7 pro in bug 1190258
OS: Mac OS X → All
Hardware: x86_64 → All

Updated

4 years ago
Duplicate of this bug: 1191612
(Assignee)

Updated

4 years ago
Depends on: 1192097
(Reporter)

Updated

4 years ago
Attachment #8644806 - Flags: review?(gsquelart) → review+
(Assignee)

Comment 5

4 years ago
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)
(Reporter)

Updated

4 years ago
Attachment #8644835 - Flags: review?(gsquelart) → review+
(Assignee)

Updated

4 years ago
Keywords: leave-open
(Assignee)

Comment 8

4 years ago
Gerald reported still having issues.

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

Comment 9

4 years ago
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
Keywords: leave-open
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.