Last Comment Bug 1186943 - Intermittent test_video_playback.py TestVideoPlaybackBase.test_video_playback_full or TestVideoPlaybackBase.test_video_playback_partial
: Intermittent test_video_playback.py TestVideoPlaybackBase.test_video_playback...
Status: RESOLVED FIXED
: intermittent-failure
Product: Core
Classification: Components
Component: Audio/Video: Playback (show other bugs)
: Trunk
: All All
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Anthony Jones (:kentuckyfriedtakahe, :k17e)
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-07-23 08:54 PDT by Ryan VanderMeulen [:RyanVM]
Modified: 2015-08-04 10:34 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
affected


Attachments

Description User image Ryan VanderMeulen [:RyanVM] 2015-07-23 08:54:06 PDT

    
Comment 1 User image Treeherder Robot 2015-07-23 08:54:20 PDT
log: https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-central&job_id=1865594
repository: mozilla-central
start_time: 2015-07-23T08:03:25
who: rvandermeulen[at]mozilla[dot]com
machine: pf-win7-64-02
buildname: non-buildbot windows7-64 test MSE Video Playback
revision: 1f77b78797d6

ERROR test_video_playback.py TestVideoPlaybackBase.test_video_playback_full
ERROR test_video_playback.py TestVideoPlaybackBase.test_video_playback_partial
Comment 2 User image Treeherder Robot 2015-07-23 08:54:22 PDT
log: https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-central&job_id=1865902
repository: mozilla-central
start_time: 2015-07-23T08:14:52
who: rvandermeulen[at]mozilla[dot]com
machine: pf-mac-10-10-02.qa.mtv2.mozilla.com
buildname: non-buildbot osx-10-10 test MSE Video Playback
revision: 1f77b78797d6

ERROR test_video_playback.py TestVideoPlaybackBase.test_video_playback_full
ERROR test_video_playback.py TestVideoPlaybackBase.test_video_playback_partial
Comment 3 User image Treeherder Robot 2015-07-23 08:54:23 PDT
log: https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-central&job_id=1864874
repository: mozilla-central
start_time: 2015-07-23T07:44:54
who: rvandermeulen[at]mozilla[dot]com
machine: pf-win81-64-02
buildname: non-buildbot windows8-64 test MSE Video Playback
revision: 1f77b78797d6

ERROR test_video_playback.py TestVideoPlaybackBase.test_video_playback_full
ERROR test_video_playback.py TestVideoPlaybackBase.test_video_playback_partial
Comment 4 User image Maja Frydrychowicz (:maja_zf) 2015-07-23 15:36:20 PDT
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.
Comment 5 User image Jean-Yves Avenard [:jya] 2015-07-24 06:12:32 PDT
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:

https://www.youtube.com/watch?v=XqLTe8h0-jo
	mediasource:https://www.youtube.com/0f35d4c4-75bd-ee45-a767-0ba8c2aa347c
	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.
Comment 6 User image Syd Polk :sydpolk 2015-07-26 15:00:29 PDT
Pull request: https://github.com/mjzffr/firefox-media-tests/pull/10

:maja_zf, please review.
Comment 7 User image Syd Polk :sydpolk 2015-07-27 10:56:10 PDT
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?
Comment 8 User image Jean-Yves Avenard [:jya] 2015-07-27 15:11:29 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.