Closed Bug 1186943 Opened 6 years ago Closed 6 years ago

Intermittent TestVideoPlaybackBase.test_video_playback_full or TestVideoPlaybackBase.test_video_playback_partial


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

Not set



Tracking Status
firefox42 --- affected


(Reporter: RyanVM, Unassigned)


(Keywords: intermittent-failure)

No description provided.
I have temporarily disabled these tests.

This failure is a result of "new MSE" implementation being enabled by default in Nightly. These tests depend on the the notion of an "active stream" (as reported by mozMediaSourceObject.mozDebugReaderData) which no longer makes sense in the new MSE. Instead, we need a test that checks whether NextGetSampleIndex and NextInsertionIndex are both 0 when we detect a playback stall, for example.

needinfo to :jya to confirm that my description of the new test is accurate.
Flags: needinfo?(jyavenard)
A stall would more likely be linked to NextGetSampleIndex being 0. This would indicate an internal failure (but only if there's an actual stall)

Also of interest, would be if the currentTime is contained in the buffered range.

Here is what it would typically display:
	currentTime: 129.844222
		SourceBuffer 0
			start=0 end=97.128594
			start=120.000725 end=169.0639
		SourceBuffer 1
			start=0 end=97.2
			start=124.2 end=168.96
	Internal Data:
	Dumping data for demuxer 141ea5000:
		Dumping Audio Track Buffer(audio/mp4a-latm): - mLastAudioTime: 131.076598
			NumSamples:6296 Size:3402996 NextGetSampleIndex:4660 NextInsertionIndex:6296
			Buffered: ranges=[(0.000000, 97.128594), (120.000725, 169.063900)]
		Dumping Video Track Buffer(video/avc) - mLastVideoTime: 130.760000
			NumSamples:3416 Size:21207069 NextGetSampleIndex:2461 NextInsertionIndex:3416
			Buffered: ranges=[(0.000000, 97.200000), (124.200000, 168.960000)]

Here you can notice that the buffered ranges have a discontinuity, that's because we just seeked to a non-buffered position.

mLastAudioTime is the expected time of the next audio sample we are about to demux from the audio track buffer.
mLastVideoTime is the expected time of the next video sample we are about to demux from the video track buffer.

It really should be mNextAudioTime/mNextVideoTime but I wanted to keep small consistency with the previous MSE.
if mLastAudioTime or mLastVideoTime isn't found in the respective buffered ranges: a stall will happen as soon as currentTime has caught up.
Flags: needinfo?(jyavenard)
Pull request:

:maja_zf, please review.
So, what is the logic for detecting a stall, then? How would I know the video is stalled looking at this output? Is "NextGetSampleIndex == 0" a sufficient test?
Flags: needinfo?(jyavenard)
Component: Audio/Video → Audio/Video: Playback
The only way to tell if we have a genuine stall is currentTime value not progressing.

The index being 0 may indicate a stall, but they can also just indicate a temporary state where we've been unable to retrieve data. But that situation is recoverable.

Value will be set to 0 when data is evicted (either through self-eviction or an explicit call to sourcebuffer.remove) and the data being evicted overlaps with the data we are currently reading from.

When that happens, and if no new data is appended, there will be a stall.
Flags: needinfo?(jyavenard)
You need to log in before you can comment on or make changes to this bug.